From nobody Thu Mar 1 00:49:49 2018 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 17FB012E03F for ; Thu, 1 Mar 2018 00:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 brf-usd7sxms for ; Thu, 1 Mar 2018 00:49:45 -0800 (PST) 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 F058812E042 for ; Thu, 1 Mar 2018 00:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519894179; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UFM4/bdT4Kb3PqtBzb/VviAY8bduC8rpNDw+/qquL2Y=; b=QjsQbGQxaTlnP9aa1aeWsRGV6SQcZ1q5KVDctbnuehNzoMfAvhOC47z7p8cGM13k RgB3YzODaky+d9gqlqOjNY5bqUNWA++RiBit6k6EPhXKEr926KEhbyiKZO56H+li j3JnujmdZSxLjbdEMvUVOj3gKHo68wR1iImnbOW0Epo=; X-AuditID: c1b4fb30-399ff70000004778-1b-5a97bea2dc62 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 32.57.18296.2AEB79A5; Thu, 1 Mar 2018 09:49:39 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Thu, 1 Mar 2018 09:49:38 +0100 From: Christer Holmberg To: =?Windows-1252?Q?Ari_Ker=E4nen?= , "Black, David" , "ice@ietf.org" , "jri@google.com" , Nils Ohlmeier CC: "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" Thread-Topic: [Ice] 5245bis: STUN/TURN transaction timeout timer Thread-Index: AdOuOI+oEAiBXZOTQm+Dl/LRxGi/pAA0o/rgAAMPdYAAAXfKMAACL39QAAosVoAAACltgAACbt+AAHQHYYAABs/iAA== Date: Thu, 1 Mar 2018 08:49:38 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C19C90C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1A8CC5@ESESSMB109.ericsson.se> <143496D8-1304-49C3-B12F-5EF3A116E1BD@mozilla.com> <1A521409-0DF9-42B7-B1D9-0F8FB6FA7008@mozilla.com> <748F125A-EE65-49B9-99D9-C64AB428CD3A@ericsson.com> In-Reply-To: <748F125A-EE65-49B9-99D9-C64AB428CD3A@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.18] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3602746952_69656932" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUyM2K7pe7ifdOjDGbOZLX4OGsxi8X8k9eZ LS7Omsxm8e1CrcWkowtZLK7Pm8zowOYxaeYMZo8Fm0o9liz5yeTRd6CLNYAlissmJTUnsyy1 SN8ugSvj5pInLAXfcyref+xgaWC8n9jFyMkhIWAicfPffvYuRi4OIYHDjBJPL+1jhXAWMUos +TSXsYuRg4NNwEKi+582SFxE4DKjxPdns5lBupkFaiSu3d0PZgsL2EusmNDGCGKLCDhIPNjT wARhZ0msnzsBzGYRUJGY/O0GO4jNK2AtcXfDYSaIZetZJG7u/8sKkuAEau5d8RTMZhQQk/h+ ag0TxDJxiVtP5jNBnC0i8fDiaTYIW1Ti5eN/YPWiAnoSG07cZoeIK0p8fLWPEaK3UuL0d4iD eAUEJU7OfMIygVF0FpKxs5CUzUJSBhE3kPiz+BQrhK0t8eTdBSjbWmLGr4NsELaixJTuh+wQ tqnE66MfGRcwcqxiFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIzhg1t+G+xgfPnc8RCjAAej Eg+v9d7pUUKsiWXFlbmHGFWA5jzasPoCoxRLXn5eqpII7+nt06KEeFMSK6tSi/Lji0pzUosP MUpzsCiJ85705I0SEkhPLEnNTk0tSC2CyTJxcEo1MJasX2us9eXyxx9X+H7XSL5+Nm2Fis7l mSKGUndfTogw9OorLdg1e/YLvdQP3Ew5XK4nk4unV80/5nLnUtsKuZaO7aG9c5xFk0947EiV Ybn+ZOu/BZs9bzy7mSFu65ezQcFuubb5K7eHh976JSw+Ev7WYWX6r3+FJs/8sq5PUemakLfO tGX/m+lKLMUZiYZazEXFiQAK8L8Z6QIAAA== Archived-At: Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer 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, 01 Mar 2018 08:49:47 -0000 --B_3602746952_69656932 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, When re-reading section 14.2, I actually don=B9t think that ICE agents use the HTO timer. The important text is the following: "Regardless of the Ta value chosen for each agent, the combination of all transactions from all agents (if a given implementation runs several concurrent agents) MUST NOT be sent more often than once every 5ms (as though there were one global Ta value for pacing all agents).=B2 The rest of the text in the section is then a justification/background for the statement above, and in that justification/background HTO is used as one parameter. But, again, ICE agents never implement and use HTO for anything - ICE agents just make sure that the global Ta value is not smaller than 5ms. Regards, Christer On 01/03/18 09:47, "Ari Ker=E4nen" wrote: >Hi, > >I had a look at the Ti timer in 5389 >(https://tools.ietf.org/search/rfc5389#section-7.2.2) and it seems that >it is defined to be in line with the time it takes for (UDP) STUN >transaction that includes all re-transmissions to timeout: >> Reliability of STUN over TCP and TLS-over-TCP is handled by TCP >> itself, and there are no retransmissions at the STUN protocol level. >> However, for a request/response transaction, if the client has not >> received a response by Ti seconds after it sent the SYN to establish >> the connection, it considers the transaction to have timed out. > > >However the HTO timer is for transaction pacing and is roughly what one >successful connectivity check should take (2*RTT). > >Therefore these are two different things and I don't think it make sense >to mention Ti here at all. I suggest we remove the note completely. > > >Cheers, >Ari (hat off) > >> On 27 Feb 2018, at 2.25, Nils Ohlmeier wrote: >>=20 >> Yes you are right. Somehow I managed to read Christer=B9s Note the >>opposite way of what I now think he intends to point out. >>=20 >> Sorry for the confusion. >>=20 >> Nils >>=20 >>=20 >>> On Feb 26, 2018, at 15:15, Black, David wrote: >>>=20 >>> Isn=B9t it the other way around =AD ICE HTO is much shorter than STUN or >>>TURN Ti? >>> =20 >>> Thanks, --David >>> =20 >>> From: Nils Ohlmeier [mailto:nohlmeier@mozilla.com] >>> Sent: Monday, February 26, 2018 6:11 PM >>> To: Christer Holmberg >>> Cc: Black, David ; ice@ietf.org; >>>draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org; jri@google.com >>> Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer >>> =20 >>> =20 >>> On Feb 26, 2018, at 07:48, Christer Holmberg >>> wrote: >>> =20 >>> Maybe adding the following note to the existing Timer HTO definition: >>> =20 >>> Timer HTO: The timeout timer for a given STUN or TURN transaction. >>> =20 >>> =B3NOTE: When STUN and TURN are used with ICE, timer HTO is used >>>instead of timer Ti [RFC5389] as transaction timeout timer.=B2 >>> =20 >>> My initial thought was: yes sounds good. >>> =20 >>> But one of the side effects know from real world deployments is that >>>results in the end-of-candidates indication coming in after a long time >>>if one of the STUN or TURN servers is not reachable. >>> I don=B9t want to make this a last minute change, but your indication >>>that Ti explicitly got made shorter made me wonder if everyone in WG is >>>aware of this usage of the long HTO value. >>> =20 >>> Best >>> Nils Ohlmeier >>>=20 >>>=20 >>> =20 >>> Regards, >>> =20 >>> Christer >>> =20 >>> From: Black, David [mailto:David.Black@dell.com] >>> Sent: 26 February 2018 16:54 >>> To: Christer Holmberg ;ice@ietf.org; >>>draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org >>> Cc: jri@google.com; Black, David >>> Subject: RE: 5245bis: STUN/TURN transaction timeout timer >>> =20 >>> That would be a fine thing to do, Thanks, --David >>> =20 >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Monday, February 26, 2018 9:22 AM >>> To: Black, David ; ice@ietf.org; >>>draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org >>> Cc: jri@google.com >>> Subject: Re: 5245bis: STUN/TURN transaction timeout timer >>> =20 >>> Hi, >>> =20 >>> >> But, still, is there a reason we couldn=B9t use =8CTi=B9 also in 5245bis, >>>and point out the big value difference when used with ICE? >>> >=20 >>> >Given the nearly 2-orders-of-magnitude difference in the time >>>periods, I=B9d be concerned that using the same name risks leaving an >>>incorrect impression on an implementer who >>> >is familiar with one protocol, but new to the other. Different >>>names may also improve clarity in other documents that describe how >>>STUN and ICE work together. >>> =20 >>> Fair enough. But, should we then point out that Ti isn=B9t used with ICE? >>> =20 >>> Regards, >>> =20 >>> Christer >>> =20 >>> =20 >>> =20 >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Sunday, February 25, 2018 8:00 AM >>> To: ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; >>>ice-chairs@ietf.org >>> Cc: Black, David ; jri@google.com >>> Subject: 5245bis: STUN/TURN transaction timeout timer >>> =20 >>> Hi, >>> =20 >>> In draft-5245bis, the name of the STUN/TURN transaction timeout timer >>>is =8CHTO=B9. >>> =20 >>> As part of the IESG review, I have been asked what the =8CH=B9 stands for. >>>After some digging in the mail archives (2016-09-14), I figured out it >>>stands for =B3handshake=B2: >>> =20 >>> https://www.ietf.org/mail-archive/web/ice/current/msg00378.html >>> =20 >>> =B32. A timeout for request packets, call it handshake timeout or >>>HTO which SHOULD be 2*RTT if the RTT is known and 500ms otherwise.=B2 >>> =20 >>> Now, in RFC 5389, the transaction timeout timer is called =8CTi=B9. >>>However, the default value for that SHOULD be 39,5 seconds =AD which is >>>quite different from 500ms. >>> =20 >>> But, still, is there a reason we couldn=B9t use =8CTi=B9 also in 5245bis, >>>and point out the big value difference when used with ICE? >>> =20 >>> Regards, >>> =20 >>> Christer >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>=20 > --B_3602746952_69656932 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOQYJKoZIhvcNAQcCoIIUKjCCFCYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIMMIIGBjCCA+6gAwIBAgIQN4YipkcuAr1/ZKbsw+1eMTANBgkqhkiG9w0BAQsFADBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTAzMDgwODMyWhcNMjAxMTAzMDgwODMxWjBvMREw DwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRQ2hyaXN0ZXIgSG9sbWJlcmcxLTArBgkqhkiG 9w0BCQEWHmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTEPMA0GA1UEBRMGTE1GQ0hI MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy0z3dlyw+ybHo7PhlkBY00QOJB5T NOXcMdxiQ0nL5uM1C/0xQ7/T3uuHJRjD8nvqTqnlmfJ2VCZRKD3W8LJAUXGFd8JqwLJmGGZt cS3Jp+2WBAxBR6TjtcMwDGQNYD85YCKIuqcsarOxVhzXhwISp750JC1UmR4xxX1gbSkVb8S8 DsPsBioQ/Enkiad/rP0huQFb56Ocxu2Fy2aEW06ezyxU9My4Jh/vMDh+0DBb8EfN8ovAFmMH Qj3SxVUDwnTYbPdA1v3RipF/HH0NBsNOUS8RFct6OxHG1JDbMrkY9ErEKkrHmu3JyNM1hxmy 8rJl/yDID2n6vyxkh5QFcsvOdwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0 cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCB ggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEu Y29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNz c29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEeY2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEW LGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUESOe8HpdLQz1aZdNgbOPnJlysTIw HwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqG SIb3DQEBCwUAA4ICAQBdN30YKQsw+ow1tjR6gBDuNpQagWRw7DSkYXg4ZE5k76jyXPOTa9VE 8x3MbNIbsyuVLYiVIN/lePTPi4qyt1CNBGPn4roUOuGeGQ7/dABYWNGmT0nKjjeXmqs9bt5z CrxPfVS4xeEU7D64OJtD47f069jsG5E6qENdPmrjaKmTrllfM1S9HvWeco8PwBQC5ixpiXUq t3Dyq3K0GmCgs1P7dJqup+Dt6UNF+DwgSZZeBjo3l+BtAv7StrvWdUQCqJpjUttIwzmtqsx2 NUWa1oSoqvUJ6XnJUZdT/UF390/6Uo4rnTeOWao9dkKQCaE3KvtCHBNZRv1MW0Ot3KSKnE+4 iZeUZgg1KAVQ5dhjjtXmjYoZMYoN4lE4OB2ae8LRbOrj0PE7Wvbuhs5eOyei7e6lYDHPzpLn cfcLpQmOoHal11JqympoeJQENtQl2i1p2j5KmsfUQiqD1HQaGcpH9OKXEclLCOpQ/6zafNW3 nSYFBwADNpHMNiQXxcXKxiPCfiZa2UK5RRWohIz9kY8HXvX/1E2pvtOZoymiXJviR3g2BFvM 21+LIVu3dtoEWWxtD7MyDtOe1dEZTfxLUPMpQa66znWbEQ736mmv5n/z+Aaq7OidNuOIFfO2 HbE+LBHIWhKAy9Ttqa+RqpPONMkvz3kth+G4IOBaTYEPWWHLrqXe2zCCBsIwggSqoAMCAQIC EFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25l cmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4IC DwAwggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs 0zfSTm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9 ZVbXILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvS xlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eN o4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWq g5t2H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4 TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1 MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYv SBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaG K5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoG CCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25l cmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNV HSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRv cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8v Y3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMS MA0GCSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gV LtDUJQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyo EBHGvw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50Zk BqYnnl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEO rPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1Ur RIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKX e4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNO xdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaH KWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyE G/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDCCBTgwggMg oAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEy MDA1MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMM FlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQDCvusn8CGj82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1 gouuSLasANxldewqTV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/te uuSPl2e+S46NZAdXOFVpNDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv41 4e1Qe6kwjRnTCY5oZ12/PJcYU7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1s OTlzgBbIUrAjzeA+3N08R6C7NYrimGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1v gPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdf Y2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCDLrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2 WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt6 0H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKSL2LUP2lDfA3W/Fh1AYidWBZL3rqQ /0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8wPTAPBgNVHRMBAf8EBTADAQH/ MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA389ZoG5XcUkeudQXuZ KoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyywqODAQDc19oRc XOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr7cQZ5qtM ETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65XI0G SK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI 6wzWJoi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2H dqkXlrfPDZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/ xFZT+mNl0PMcDhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjU kL8Ws9nprFlhVMgcusrByuG5IEyPOpOJpaDMv9P2daR1lm1WMYIB8TCCAe0CAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMCEDeGIqZHLgK9f2Sm7MPtXjEwDQYJYIZIAWUDBAIBBQCgaTAvBgkq hkiG9w0BCQQxIgQgJ5+o8m0yRfKca9k7h7PR+EOYARU1YLqMRGuegfM/b/AwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMzAxMDkwMjMyWjANBgkqhkiG 9w0BAQEFAASCAQCFMbNqOH0IT8WnFb+tVRgy1r6fr37fZTElO4rYLBCgP/kV3Oz56W8DZQ9h IeNCGChEzN17yOXYl6Ou0F0WuVJig7eNuLHA8I7PnQHoQ0+PWBNM7gwdBUTpykbXKS8YGuqA /PJdXNF74BmZx7+tGhOzeCV0NQG0h4NDy2ULFwumP3WhoS7z3ISlM3oHvGARjVc5IURkQfLi QCf/j43gYR74G5yGhqvo1VTjrSfmsL4v1X9MUaz58RI96zrOaJaOl4JBm4ST5sA/3sMDAcB6 JAj+CAcnui/9+8nkUnVm3aJ2YHOemHQSl5+iQ5ETxq8qdMANClQKXKLkm9nCRM1saGfl --B_3602746952_69656932-- From nobody Thu Mar 1 00:52:17 2018 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 0BBFB12E042 for ; Thu, 1 Mar 2018 00:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 AaD9LX5t_X31 for ; Thu, 1 Mar 2018 00:52:15 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23AF12DA40 for ; Thu, 1 Mar 2018 00:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519894332; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kW4XpUUWjT6cgtF1QKYNMIbMig8FZ/ba1J28yJyNkLo=; b=KVJ+7A7Pcee6PmPLKqiT3PbAm6kVDQq/dW/r5+HRaO8I2PrWYY7ju3nwf8s0VBQR NhvXb38YUFZneoDGHA9F+XazmrwP/gM9LLqnMwM5qDQzoz9SGlfphosvILunwXpD HAgB+z42DeHlXfesfJrg2YXgf3e2xSrcypo1PJC7254=; X-AuditID: c1b4fb2d-87c029c000005540-0e-5a97bf3c1357 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B8.E2.21824.C3FB79A5; Thu, 1 Mar 2018 09:52:12 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Thu, 1 Mar 2018 09:52:11 +0100 From: Christer Holmberg To: Christer Holmberg , =?utf-8?B?QXJpIEtlcsOkbmVu?= , "Black, David" , "ice@ietf.org" , Nils Ohlmeier CC: "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" Thread-Topic: [Ice] 5245bis: STUN/TURN transaction timeout timer Thread-Index: AdOuOI+oEAiBXZOTQm+Dl/LRxGi/pAA0o/rgAAMPdYAAAXfKMAACL39QAAosVoAAACltgAACbt+AAHQHYYAABs/iAAAAFsyA Date: Thu, 1 Mar 2018 08:52:10 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C19C90C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1A8CC5@ESESSMB109.ericsson.se> <143496D8-1304-49C3-B12F-5EF3A116E1BD@mozilla.com> <1A521409-0DF9-42B7-B1D9-0F8FB6FA7008@mozilla.com> <748F125A-EE65-49B9-99D9-C64AB428CD3A@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3602747105_69682922" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUyM2K7pa7N/ulRBndeCFl8nLWYxWL+yevM FhdnTWaz+Hah1uL6vMmMDqwek2bOYPZYsuQnk0ffgS7WAOYoLpuU1JzMstQifbsErozFbfOZ CloKK7YePcfcwLg1tYuRk0NCwETi0t7fjF2MXBxCAocZJW4+PckK4SxilOj5upCti5GDg03A QqL7nzZIXETgEaPE+5YJzCDdzAI1Etfu7gezhQXsJVZMaGMEsUUEHCQe7GlggrDzJLofb2QH sVkEVCRWndzBAmLzClhLvJ12gA1i2UMWiUebNoI1cArYSCxe1w1WxCggJvH91BomiGXiEree zGeCOFtE4uHF02wQtqjEy8f/WEFsUQE9iQ0nbrNDxBUl2p82MEL0VkosXg8xn1dAUOLkzCcs ExhFZyEZOwtJ2SwkZRBxbYk9t7Yyw9hP3l1ghbCtJWb8OsgGYStKTOl+yA5hm0q8PvqRcQEj xypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwIg9uOW37g7G1a8dDzEKcDAq8fC6L50eJcSa WFZcmXuIUQVozqMNqy8wSrHk5eelKonwnt4+LUqINyWxsiq1KD++qDQntfgQozQHi5I470lP 3ighgfTEktTs1NSC1CKYLBMHp1QD4/K3y6ZNfzyZd83BbeZ70hnZUlvPBTAuvxFtk/1OzkGM o/03p9rHK641XJ9esOpvexySam6V8PRKwCp/V713V/IjtbK2vr56oIktLshg97Odly1adQ1s 9todyjjWfVhg0tQ3Scc15ijauE9adYJNdtKhNVtDpFvbdtZsYW7ryw8rsn5WpGQsocRSnJFo qMVcVJwIALawIHngAgAA Archived-At: Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer 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, 01 Mar 2018 08:52:17 -0000 --B_3602747105_69682922 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable =E2=80=A6so, my suggestion would be to move the text about HTO etc to Appendix B.2, and only keep the 3 first paragraphs in Section 14.2. Regards, Christer On 01/03/18 10:49, "Christer Holmberg" wrote: > >Hi, > >When re-reading section 14.2, I actually don=C2=B9t think that ICE agents use >the HTO timer. > >The important text is the following: > > "Regardless of the Ta value chosen for each agent, the combination of > all transactions from all agents (if a given implementation runs > several concurrent agents) MUST NOT be sent more often than once > every 5ms (as though there were one global Ta value for pacing all > agents).=C2=B2 > > >The rest of the text in the section is then a justification/background for >the statement above, and in that justification/background HTO is used as >one parameter. > >But, again, ICE agents never implement and use HTO for anything - ICE >agents just make sure that the global Ta value is not smaller than 5ms. > >Regards, > >Christer > > > > > > > >On 01/03/18 09:47, "Ari Ker=C3=A4nen" wrote: > >>Hi, >> >>I had a look at the Ti timer in 5389 >>(https://tools.ietf.org/search/rfc5389#section-7.2.2) and it seems that >>it is defined to be in line with the time it takes for (UDP) STUN >>transaction that includes all re-transmissions to timeout: >>> Reliability of STUN over TCP and TLS-over-TCP is handled by TCP >>> itself, and there are no retransmissions at the STUN protocol level. >>> However, for a request/response transaction, if the client has not >>> received a response by Ti seconds after it sent the SYN to establish >>> the connection, it considers the transaction to have timed out. >> >> >>However the HTO timer is for transaction pacing and is roughly what one >>successful connectivity check should take (2*RTT). >> >>Therefore these are two different things and I don't think it make sense >>to mention Ti here at all. I suggest we remove the note completely. >> >> >>Cheers, >>Ari (hat off) >> >>> On 27 Feb 2018, at 2.25, Nils Ohlmeier wrote: >>>=20 >>> Yes you are right. Somehow I managed to read Christer=C2=B9s Note the >>>opposite way of what I now think he intends to point out. >>>=20 >>> Sorry for the confusion. >>>=20 >>> Nils >>>=20 >>>=20 >>>> On Feb 26, 2018, at 15:15, Black, David wrote: >>>>=20 >>>> Isn=C2=B9t it the other way around =C2=AD ICE HTO is much shorter than STUN or >>>>TURN Ti? >>>> =20 >>>> Thanks, --David >>>> =20 >>>> From: Nils Ohlmeier [mailto:nohlmeier@mozilla.com] >>>> Sent: Monday, February 26, 2018 6:11 PM >>>> To: Christer Holmberg >>>> Cc: Black, David ; ice@ietf.org; >>>>draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org; jri@google.com >>>> Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer >>>> =20 >>>> =20 >>>> On Feb 26, 2018, at 07:48, Christer Holmberg >>>> wrote: >>>> =20 >>>> Maybe adding the following note to the existing Timer HTO definition: >>>> =20 >>>> Timer HTO: The timeout timer for a given STUN or TURN transaction. >>>> =20 >>>> =C2=B3NOTE: When STUN and TURN are used with ICE, timer HTO is used >>>>instead of timer Ti [RFC5389] as transaction timeout timer.=C2=B2 >>>> =20 >>>> My initial thought was: yes sounds good. >>>> =20 >>>> But one of the side effects know from real world deployments is that >>>>results in the end-of-candidates indication coming in after a long time >>>>if one of the STUN or TURN servers is not reachable. >>>> I don=C2=B9t want to make this a last minute change, but your indication >>>>that Ti explicitly got made shorter made me wonder if everyone in WG is >>>>aware of this usage of the long HTO value. >>>> =20 >>>> Best >>>> Nils Ohlmeier >>>>=20 >>>>=20 >>>> =20 >>>> Regards, >>>> =20 >>>> Christer >>>> =20 >>>> From: Black, David [mailto:David.Black@dell.com] >>>> Sent: 26 February 2018 16:54 >>>> To: Christer Holmberg ;ice@ietf.org; >>>>draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org >>>> Cc: jri@google.com; Black, David >>>> Subject: RE: 5245bis: STUN/TURN transaction timeout timer >>>> =20 >>>> That would be a fine thing to do, Thanks, --David >>>> =20 >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Monday, February 26, 2018 9:22 AM >>>> To: Black, David ; ice@ietf.org; >>>>draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org >>>> Cc: jri@google.com >>>> Subject: Re: 5245bis: STUN/TURN transaction timeout timer >>>> =20 >>>> Hi, >>>> =20 >>>> >> But, still, is there a reason we couldn=C2=B9t use =C2=8CTi=C2=B9 also in 5245b= is, >>>>and point out the big value difference when used with ICE? >>>> >=20 >>>> >Given the nearly 2-orders-of-magnitude difference in the time >>>>periods, I=C2=B9d be concerned that using the same name risks leaving an >>>>incorrect impression on an implementer who >>>> >is familiar with one protocol, but new to the other. Different >>>>names may also improve clarity in other documents that describe how >>>>STUN and ICE work together. >>>> =20 >>>> Fair enough. But, should we then point out that Ti isn=C2=B9t used with >>>>ICE? >>>> =20 >>>> Regards, >>>> =20 >>>> Christer >>>> =20 >>>> =20 >>>> =20 >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Sunday, February 25, 2018 8:00 AM >>>> To: ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; >>>>ice-chairs@ietf.org >>>> Cc: Black, David ; jri@google.com >>>> Subject: 5245bis: STUN/TURN transaction timeout timer >>>> =20 >>>> Hi, >>>> =20 >>>> In draft-5245bis, the name of the STUN/TURN transaction timeout timer >>>>is =C2=8CHTO=C2=B9. >>>> =20 >>>> As part of the IESG review, I have been asked what the =C2=8CH=C2=B9 stands fo= r. >>>>After some digging in the mail archives (2016-09-14), I figured out it >>>>stands for =C2=B3handshake=C2=B2: >>>> =20 >>>> https://www.ietf.org/mail-archive/web/ice/current/msg00378.html >>>> =20 >>>> =C2=B32. A timeout for request packets, call it handshake timeout o= r >>>>HTO which SHOULD be 2*RTT if the RTT is known and 500ms otherwise.=C2=B2 >>>> =20 >>>> Now, in RFC 5389, the transaction timeout timer is called =C2=8CTi=C2=B9. >>>>However, the default value for that SHOULD be 39,5 seconds =C2=AD which is >>>>quite different from 500ms. >>>> =20 >>>> But, still, is there a reason we couldn=C2=B9t use =C2=8CTi=C2=B9 also in 5245bis, >>>>and point out the big value difference when used with ICE? >>>> =20 >>>> Regards, >>>> =20 >>>> Christer >>>> _______________________________________________ >>>> Ice mailing list >>>> Ice@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ice >>>=20 >> --B_3602747105_69682922 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOQYJKoZIhvcNAQcCoIIUKjCCFCYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIMMIIGBjCCA+6gAwIBAgIQN4YipkcuAr1/ZKbsw+1eMTANBgkqhkiG9w0BAQsFADBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTAzMDgwODMyWhcNMjAxMTAzMDgwODMxWjBvMREw DwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRQ2hyaXN0ZXIgSG9sbWJlcmcxLTArBgkqhkiG 9w0BCQEWHmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTEPMA0GA1UEBRMGTE1GQ0hI MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy0z3dlyw+ybHo7PhlkBY00QOJB5T NOXcMdxiQ0nL5uM1C/0xQ7/T3uuHJRjD8nvqTqnlmfJ2VCZRKD3W8LJAUXGFd8JqwLJmGGZt cS3Jp+2WBAxBR6TjtcMwDGQNYD85YCKIuqcsarOxVhzXhwISp750JC1UmR4xxX1gbSkVb8S8 DsPsBioQ/Enkiad/rP0huQFb56Ocxu2Fy2aEW06ezyxU9My4Jh/vMDh+0DBb8EfN8ovAFmMH Qj3SxVUDwnTYbPdA1v3RipF/HH0NBsNOUS8RFct6OxHG1JDbMrkY9ErEKkrHmu3JyNM1hxmy 8rJl/yDID2n6vyxkh5QFcsvOdwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0 cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCB ggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEu Y29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNz c29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEeY2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEW LGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUESOe8HpdLQz1aZdNgbOPnJlysTIw HwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqG SIb3DQEBCwUAA4ICAQBdN30YKQsw+ow1tjR6gBDuNpQagWRw7DSkYXg4ZE5k76jyXPOTa9VE 8x3MbNIbsyuVLYiVIN/lePTPi4qyt1CNBGPn4roUOuGeGQ7/dABYWNGmT0nKjjeXmqs9bt5z CrxPfVS4xeEU7D64OJtD47f069jsG5E6qENdPmrjaKmTrllfM1S9HvWeco8PwBQC5ixpiXUq t3Dyq3K0GmCgs1P7dJqup+Dt6UNF+DwgSZZeBjo3l+BtAv7StrvWdUQCqJpjUttIwzmtqsx2 NUWa1oSoqvUJ6XnJUZdT/UF390/6Uo4rnTeOWao9dkKQCaE3KvtCHBNZRv1MW0Ot3KSKnE+4 iZeUZgg1KAVQ5dhjjtXmjYoZMYoN4lE4OB2ae8LRbOrj0PE7Wvbuhs5eOyei7e6lYDHPzpLn cfcLpQmOoHal11JqympoeJQENtQl2i1p2j5KmsfUQiqD1HQaGcpH9OKXEclLCOpQ/6zafNW3 nSYFBwADNpHMNiQXxcXKxiPCfiZa2UK5RRWohIz9kY8HXvX/1E2pvtOZoymiXJviR3g2BFvM 21+LIVu3dtoEWWxtD7MyDtOe1dEZTfxLUPMpQa66znWbEQ736mmv5n/z+Aaq7OidNuOIFfO2 HbE+LBHIWhKAy9Ttqa+RqpPONMkvz3kth+G4IOBaTYEPWWHLrqXe2zCCBsIwggSqoAMCAQIC EFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25l cmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4IC DwAwggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs 0zfSTm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9 ZVbXILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvS xlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eN o4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWq g5t2H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4 TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1 MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYv SBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaG K5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoG CCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25l cmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNV HSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRv cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8v Y3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMS MA0GCSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gV LtDUJQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyo EBHGvw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50Zk BqYnnl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEO rPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1Ur RIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKX e4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNO xdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaH KWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyE G/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDCCBTgwggMg oAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEy MDA1MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMM FlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQDCvusn8CGj82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1 gouuSLasANxldewqTV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/te uuSPl2e+S46NZAdXOFVpNDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv41 4e1Qe6kwjRnTCY5oZ12/PJcYU7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1s OTlzgBbIUrAjzeA+3N08R6C7NYrimGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1v gPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdf Y2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCDLrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2 WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt6 0H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKSL2LUP2lDfA3W/Fh1AYidWBZL3rqQ /0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8wPTAPBgNVHRMBAf8EBTADAQH/ MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA389ZoG5XcUkeudQXuZ KoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyywqODAQDc19oRc XOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr7cQZ5qtM ETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65XI0G SK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI 6wzWJoi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2H dqkXlrfPDZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/ xFZT+mNl0PMcDhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjU kL8Ws9nprFlhVMgcusrByuG5IEyPOpOJpaDMv9P2daR1lm1WMYIB8TCCAe0CAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMCEDeGIqZHLgK9f2Sm7MPtXjEwDQYJYIZIAWUDBAIBBQCgaTAvBgkq hkiG9w0BCQQxIgQgFlCI26v7AblM4Ta9c5+NqwJdabugszBhCEpnej9A/r4wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMzAxMDkwNTA1WjANBgkqhkiG 9w0BAQEFAASCAQBbsZFxpREqiWgfgfWgJ69jpxF/y1T/TcrHGVWLCl7NsKIb4bkVJpfgVz6A 6m2E9ZS4BQb3qoHuxEeUsOSt/kpmkU1auWkfZaRqZ2aAw6XKak9948sXbD+fyVP/aUAcp8xh MLsm37L2Zu/kTG7JV4yKkOJ/N4j3rQX5B7EZgxPK7EmrPF0CqJTTdrC0hyWD0TZjtjB+Cprd XQobwH8VddCwtpNBodYxFjcejZQRb5eicGSIpuAcAm+EEy5/D0uQdsHP3Qr4XGBsqyBvT8oD sycacWMSX1B+h33XS2gAGtCHGl6PRNXqQkwaUNnS7XMs2TqqYh7eySvCaAyoHpVCyEN0 --B_3602747105_69682922-- From nobody Thu Mar 1 00:59:06 2018 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 F2FB112E03F for ; Thu, 1 Mar 2018 00:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 HiEbJ6JNpnQS for ; Thu, 1 Mar 2018 00:59:02 -0800 (PST) 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 0FAFB120725 for ; Thu, 1 Mar 2018 00:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519894740; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nkH7UT1b3eDfCcxz2SPwyB1E98VoOIJNT3R0dNE6Lws=; b=c8t9pl+Uj2MrGmxSCqbwTp9v0WN6GVULD+bPQejpY8ksNKV8DUKvnlb/BcJH7dGP xf9w1aPx32vcelJSV9G3MXdt9LdR1JsafdWnjMT9tEORNLOmoWuoc/GxBE1dDV73 tTL/gb07Lu3klA7CSpNY1uze1QQhDKY0SQL7h5+etao=; X-AuditID: c1b4fb25-44ba69c000002d5f-91-5a97c0d49d4d Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D1.C6.11615.4D0C79A5; Thu, 1 Mar 2018 09:59:00 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Thu, 1 Mar 2018 09:58:58 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Eric Rescorla , Christer Holmberg CC: The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , Peter Thatcher , "ice@ietf.org" Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) Thread-Index: AdOpa677O8VqdAW5ThyXNM/NhWOUGQAG8xsAAerqwYA= Date: Thu, 1 Mar 2018 08:58:58 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [193.234.218.122] Content-Type: multipart/signed; boundary="Apple-Mail=_D12588A5-EE25-4C4E-A643-23B5245EA1BF"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUyM2K7ru6VA9OjDC5fFLOYf/I6s8WK1+fY LS7Omsxm8e1CrcWMPxOZLa4tf83qwOaxYFOpx5IlP5k8Jj9uYw5gjuKySUnNySxLLdK3S+DK 2HH6HVPBQ+uKVSclGhg3m3cxcnBICJhIXDsb3MXIxSEkcJhR4vnKX0wQziJGidVbvwE5nBxs AvYSk9d8ZARpEBEIk1h7lh+khlngAaPE3r3/wWqEBeolZi44zgqSEBFoYJT4cmkKK0hCRMBK 4tcsCJtFQEXi1bxbjCA2L9DQuQ33GSG2TWGU2LeilRkkwSkQKPHicy8biM0oICbx/dQasA3M AuISt57MB7MlBEQkHl48zQZhi0q8fPyPFcJWllj34AkjxHlAQ3s3trFBbBOUODnzCcsERpFZ SGbNQlY3C0kdRJG2xLKFr5lnAb3NLKAjMXkhI0TYVOL10Y9QtrXEjF8H2SBsRYkp3Q/ZFzBy rGIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjNCDW36r7mC8/MbxEKMAB6MSD+/PfdOjhFgT y4orcw8xqgDNebRh9QVGKZa8/LxUJRHe09unRQnxpiRWVqUW5ccXleakFh9ilOZgURLnnSPc HiUkkJ5YkpqdmlqQWgSTZeLglGpg9HE6sqlWbc3byiUFe61slm3z9b+/u5DnauRnRRUXDynf V2mXq03Xv1p5Qvtqc/PaVek334Wklt048/o1z21uHQf5JbeuOavVbeB3EN45p+MNw9qDEdzL gr3Zp12++Zr1XT/DUf8Fa7QMdp053pkuW2PFdqfIqo5DQ/b1Zv/N3Wrldt8UV23JUGIpzkg0 1GIuKk4EAHkz/CPYAgAA Archived-At: Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) 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, 01 Mar 2018 08:59:05 -0000 --Apple-Mail=_D12588A5-EE25-4C4E-A643-23B5245EA1BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Eric & Christer, > On 19 Feb 2018, at 16.42, Eric Rescorla wrote: >=20 > =20 >=20 > > in-progress transaction. Cancellation means that the agent > > will not retransmit the request, will not treat the lack of > > response to be a failure, but will wait the duration of the > > > > Why are you cancelling In-Progress checks when you receive a = peer-reflective check? > > If you receive two in a row, then it seems like this delays a = successful check. >=20 > True. >=20 > So, I will remove the cancel part. >=20 > Do you still think it should create a new binding request, or is the = ongoing In-Progress check enough to check the pair? >=20 > My initial reaction is you don't need to do anything extra, but I = could easily be wrong here. I'm afraid this is one of the parts of the spec that solves a corner = case in an interesting but non-obvious way. For context, here's the = original text: https://tools.ietf.org/html/rfc5245#section-7.2.1.4 IIRC, one of the reasons for this is that an agent might have started = the transaction a while ago, perhaps even sent a few re-transmissions. = Now, if you don't cancel that transaction, but just keep that going and = send the remaining re-transmission(s) and those are lost due to bad = network connectivity, you end up marking that pair as failed. However, = if you cancel and start a new transaction, you have full amount of fast = retransmissions to go. And if you receive a reply to a cancelled check, = it is still a success. I remember this was unintuitive but eventually = made sense when I implemented it. So, I'd recommend we keep this text as such. Cheers, Ari (hat off)= --Apple-Mail=_D12588A5-EE25-4C4E-A643-23B5245EA1BF Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMwDCCBfYw ggPeoAMCAQICEDcTcXMuXOfOJx3rdG/2/hgwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE3MTIwNDE0MTM0NFoXDTIwMTIwNDE0MTM0M1owZTERMA8GA1UECgwIRXJpY3Nzb24xFTAT BgNVBAMMDEFyaSBLZXLDpG5lbjEnMCUGCSqGSIb3DQEJARYYYXJpLmtlcmFuZW5AZXJpY3Nzb24u Y29tMRAwDgYDVQQFEwdlYXJpa2VyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhSVX rojnPX+oZh2GIgZ/K+/xppl7EN60UI+Vq5SHm6C2ns9/vKek9EgrUV5Zqgqz4gncT1H/3BMA8XOP ONemPIcegFR2nxkG4v+S3rRxRMdMPgBJwkZQcSDLvT9R/ZgSPckmOtMFsWeoNxdZMUXWfZh52aFk MF3NlAnXy2UiMmbGAAkHVyUjScSDWAGeGXyZV1Cn5qvoaO/Fd9G4DX646nFrfLjNSnMX6FouZoLh rkBs6xE62vtRp3z+kLO6UC8CY9e8Qn/cm6xp9B+KrE2/Un99PpbuxLx0GMXq+/cuB4CdiPn+Ka2X 0E66sWiXRoiJz4COm182hV/akOGBjGfzTwIDAQABo4IBvjCCAbowSAYDVR0fBEEwPzA9oDugOYY3 aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCB ggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29t MEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxp bmRpdmlkdWFsY2F2My5jZXIwIwYDVR0RBBwwGoEYYXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9y eS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcD AjAdBgNVHQ4EFgQU0dBcPI0/9JLIXr4Qwu+jTumFvcUwHwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc 45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBVWCBhZPB3PkGIx4FF guinomjcmL1iZ+icJEWLJ/DyF7559hzn0jDNT14gFEVKJZ/zt6pxlkmNzBaMe6O7cy/NaynWoeeK uzM61w2tR+UUGhjs3evX20b7PZsT9uONk+K25IiAKhfbwiAtkukhydiDueJZefBHfEaKmGwQ87eZ Hent/5cu13L7WpT+sCNmhbfqZm5iTWVXqci30Z+G4fX/IhB3mnFMOPniPdM4u/8qsQrAIVBguSGj rOs6JykmTsOSNgY0vCZoNNHG56ExAcoNb59eLXGLv95JxXRicQuPFca4TceiMSQsHw5999r/lMgJ 8E3YdMBJcnRixumcDE9PKMTGYrOXea51DPrHnA/pMeEzSyW1fzAdVASFTnDS7It9P3KpZVgpOr70 YjTZL2TMP67UBa1+1tYrYJAgZQATjd9pkasJyGRP5+djPlvU+nJ/kfjmv+myawD0nreIULOeKUqW j0zjt9A8SyqkVa8N8TiN2hupKZBen9orty9igASFyPm86pH9s826bvBZ6BBl0Ox/Lfm9mXz6+1Gs oCT/puZR9qJrOpCgar4MXU4vuxCVvUdsyaQluWusF/wKyHrB0RUV7Lq96AFIjC06eZwAU33Y2Uqn bh/ysnEzXsz2lY0bo6yYIaHHKjiTUEefr2dddB9I3tB2oukZ+FB+kkvcuDCCBsIwggSqoAMCAQIC EFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUxMDI3 MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDs 8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkqUXkL 7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhVW4Le o0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RSBSAwqBsh ZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v 9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocyBmpC+zJA mKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUML ky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtlj HWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6 nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwID AQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIB ADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8v Y3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7GZ6X nHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3 DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5QtaZi ObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj0uKv dASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQysshU cqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1uJGx6ELP OiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvE A155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7j ewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2 zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2 x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgft Yug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhA3E3FzLlznzicd63Rv9v4Y MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE4MDMwMTA4NTg1OFowIwYJKoZIhvcNAQkEMRYEFPRbHrW0sTaOXivcC0ckqo9QxxZnMGoGCSsG AQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhA3E3FzLlznzicd63Rv9v4YMGwGCyqGSIb3DQEJ EAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEDcTcXMuXOfOJx3rdG/2/hgwDQYJKoZIhvcNAQEBBQAE ggEAEq3+1NnfBQHKZ3n5M7kgOLVlPq8kaTw64ayrf7EbYLorKkdeQzwrzxtOjj16mxmNu7uhMKW8 uahsHd07RmqtZUWPs7PqdfZuRN9uxdoWRqHyjnVrkJcHJ9m50NKhDOBXQu1mAQXawlx5lt4oHTsX whQh6W2Yo8gsN6LaqQVB0GNou65+HIUFHFRu9O8waMRefsX+Aei5z6ZcEuB0/Xnj5uUEPE7NRAZo f1o7ceczBL/IBYi7TK3MwG4PkF26d9B/Yzh9g/OPdx2nTces2Yp2cDKSXG3L8IVxEQ4LJVuOQ8J1 aFuEvNipId84gDfNK5Bfd4w6XVXREY9sepUOk1yYQwAAAAAAAA== --Apple-Mail=_D12588A5-EE25-4C4E-A643-23B5245EA1BF-- From nobody Thu Mar 1 05:32:26 2018 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 DE97D1270B4 for ; Thu, 1 Mar 2018 05:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaDe6e-bsVqd for ; Thu, 1 Mar 2018 05:32:19 -0800 (PST) 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 1ED00126DCA for ; Thu, 1 Mar 2018 05:32:19 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id n12so7474488qtl.5 for ; Thu, 01 Mar 2018 05:32:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IZbloZ3N4OYMHrg2mk0i0xZ8qd8DQi8wdWEN+RDpfdA=; b=DLDVeNYlKwiL63llEKzsEInjAxsFIHmnMeIn0MWiKNNdivonA3Rmb/CfPvwOgPDxwi 3LBPF09z1Z4cF48pdYteamR5bo5G2R9vn95pZJ7db+3C66ur4XnM7ctqI8eKJY/GyjWy f3omy7P4+b48QQ/7X8cpegQEdW2UKQcr9dUzXfERAm8inNnDPGwl+xrys95l7nOWn88C /wJ6zG6rlR7eZKo1encFfR4Hkj5hPEdGz9birnBbpcjlvYG4lBWX9oG1kHIdYrRQalh4 zxtRXjUp4Q2vvm/1zb4Td/hLsDbJzXMPUDhBfmt5TpYL0cS0gmMD6xD4kfwmcxOPZeNR SoMA== 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=IZbloZ3N4OYMHrg2mk0i0xZ8qd8DQi8wdWEN+RDpfdA=; b=Is9zZeXh1bDOGpt8OZMWKYgEvnhe1pA+ENJ3Jq18UMw+XHgsXOCQvZqp+wFKAOd5Sf LNpd7DSfhaYCZpeoeT7afZoERMKHQPdE34s6rhDaXq0YJKRIU8PdDbOSn3twaTYNqUjx IMIduO+EM7et2JrPe9T00l6RG6nGTsR7bMIm5K1qSZj7sCHZWDNh/hdFNDDyPGxd76B6 WtJAfLi+NhieeVFHLQmk+qEKkbQGlyXA1vpqz7nr3g3qsUZEw4/G7fn1GJlUFmV0buCb UKeAOL3KzWby4atCOhd0BTA8Ef8H+4uxnCSbyIux/gkMNnhfDEnUepUg2fnU/0VO1MzJ O9PQ== X-Gm-Message-State: AElRT7HwiZCwUHleIuOpbW86XkjLt0dKa+dsenPxrWvnSs25949yRqSo /BuI6vnB5vludB/CCTW2eDJd2YrViRqUuRPEWRpgEw== X-Google-Smtp-Source: AG47ELvlZHYUbF5CW4uVmciorrgBMFkZZAkBxiym5J8/sjdxYCWSnYK1JYeD8CaqyOG1IhsWfSVuIiBGlmWyhdtNe10= X-Received: by 10.200.42.177 with SMTP id b46mr2947537qta.321.1519911138117; Thu, 01 Mar 2018 05:32:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Thu, 1 Mar 2018 05:31:37 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Thu, 1 Mar 2018 05:31:37 -0800 Message-ID: To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Cc: Christer Holmberg , The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , Peter Thatcher , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a113b03287a6256056659e3b7" Archived-At: Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) 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, 01 Mar 2018 13:32:22 -0000 --001a113b03287a6256056659e3b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 1, 2018 at 12:58 AM, Ari Ker=C3=A4nen wrote: > Hi Eric & Christer, > > > On 19 Feb 2018, at 16.42, Eric Rescorla wrote: > > > > > > > > > in-progress transaction. Cancellation means that the agent > > > will not retransmit the request, will not treat the lack of > > > response to be a failure, but will wait the duration of the > > > > > > Why are you cancelling In-Progress checks when you receive a > peer-reflective check? > > > If you receive two in a row, then it seems like this delays a > successful check. > > > > True. > > > > So, I will remove the cancel part. > > > > Do you still think it should create a new binding request, or is the > ongoing In-Progress check enough to check the pair? > > > > My initial reaction is you don't need to do anything extra, but I could > easily be wrong here. > > I'm afraid this is one of the parts of the spec that solves a corner case > in an interesting but non-obvious way. For context, here's the original > text: > https://tools.ietf.org/html/rfc5245#section-7.2.1.4 > > IIRC, one of the reasons for this is that an agent might have started the > transaction a while ago, perhaps even sent a few re-transmissions. Now, i= f > you don't cancel that transaction, but just keep that going and send the > remaining re-transmission(s) and those are lost due to bad network > connectivity, you end up marking that pair as failed. However, if you > cancel and start a new transaction, you have full amount of fast > retransmissions to go. And if you receive a reply to a cancelled check, i= t > is still a success. I remember this was unintuitive but eventually made > sense when I implemented it. > > So, I'd recommend we keep this text as such. > Why is this different from any other case of transient failure? -Ekr > > Cheers, > Ari (hat off) --001a113b03287a6256056659e3b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 1, 2018 at 12:58 AM, Ari Ker=C3=A4nen <= ;ari.keranen@= ericsson.com> wrote:
Hi Eri= c & Christer,

> On 19 Feb 2018, at 16.42, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in-progress transaction.=C2=A0 C= ancellation means that the agent
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will not retransmit the request,= will not treat the lack of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0response to be a failure, but wi= ll wait the duration of the
> >
> > Why are you cancelling In-Progress checks when you receive a peer= -reflective check?
> > If you receive two in a row, then it seems like this delays a suc= cessful check.
>
> True.
>
> So, I will remove the cancel part.
>
> Do you still think it should create a new binding request, or is the o= ngoing In-Progress check enough to check the pair?
>
> My initial reaction is you don't need to do anything extra, but I = could easily be wrong here.

I'm afraid this is one of the parts of the spec that solves a co= rner case in an interesting but non-obvious way. For context, here's th= e original text:
https://tools.ietf.org/html/rfc5245#section-= 7.2.1.4

IIRC, one of the reasons for this is that an agent might have started the t= ransaction a while ago, perhaps even sent a few re-transmissions. Now, if y= ou don't cancel that transaction, but just keep that going and send the= remaining re-transmission(s) and those are lost due to bad network connect= ivity, you end up marking that pair as failed. However, if you cancel and s= tart a new transaction, you have full amount of fast retransmissions to go.= And if you receive a reply to a cancelled check, it is still a success. I = remember this was unintuitive but eventually made sense when I implemented = it.

So, I'd recommend we keep this text as such.

<= /div>
Why is this different from any other case of transient failure?

-Ekr



Cheers,
Ari (hat off)

--001a113b03287a6256056659e3b7-- From nobody Thu Mar 1 06:01:34 2018 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 171CA129C59 for ; Thu, 1 Mar 2018 06:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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_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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ENIa_QvM75oj for ; Thu, 1 Mar 2018 06:01:29 -0800 (PST) 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 43EDA1200F1 for ; Thu, 1 Mar 2018 06:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519912887; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MB18URHs7K4R8opjA2Fjwkw+64W6Isl+Xf78pUXIcSE=; b=VwehB0+3IVriNUKH8+FChLd1F+yrFJ3X97MgVU1KxWukp7WGBK0TxAUhiDNK4Lf4 0lgWsTmAyl7KKXzrXVSaUqwPrktoUkCFhIQNrdDZkUpx3Wdcccw6OU6z2JEDpc6A kp3iqvFjEuoRnontj8yTu2J0HUvgz51w2Q3ANovSlgo=; X-AuditID: c1b4fb30-399ff70000004778-0b-5a9807b70494 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6F.FB.18296.7B7089A5; Thu, 1 Mar 2018 15:01:27 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Thu, 1 Mar 2018 15:01:26 +0100 From: Christer Holmberg To: Taylor Brandstetter CC: "ice@ietf.org" Thread-Topic: [Ice] Trickle: What is Section 16 about? Thread-Index: AQHTsGOwLjmDpDpE6ESJTIumIw+YtaO6E/aAgAFrNYA= Date: Thu, 1 Mar 2018 14:01:26 +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.17] Content-Type: multipart/alternative; boundary="_000_D6BDD6A72BD5Cchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7pe529hlRBssPSFhcXvGQ1eLbhVoH Jo8Fm0o9liz5yRTAFMVlk5Kak1mWWqRvl8CVcaJJpeBdP2PFur7lzA2M/7sZuxg5OSQETCR+ TzjE1sXIxSEkcJhR4uGHxcwQziJGie+7dzJ1MXJwsAlYSHT/0wZpEBHQlbj5dSEbSJhZQFHi 5V41kLCwgKnEmdO72CFKzCROvN3LBGFbSex9eh0sziKgItE7/x0ziM0rYC1x+vR5dohVTYwS fxdPYQeZySkQKHFkSgZIDaOAmMT3U2vA5jALiEvcejKfCeJmAYkle84zQ9iiEi8f/2MFsUUF 9CQ2nLgNNkYC6LTl/XIQrQkSU15NYoNYKyhxcuYTlgmMorOQTJ2FpGwWkjKIuJbElx/72CBs RYkp3Q/ZZ4E9rynx5mEtRNhaYsWZXczIShYwcqxiFC1OLU7KTTcy0kstykwuLs7P08tLLdnE CIy/g1t+G+xgfPnc8RCjAAejEg9vAOOMKCHWxLLiytxDjBIczEoivKe3T4sS4k1JrKxKLcqP LyrNSS0+xCjNwaIkznvSkzdKSCA9sSQ1OzW1ILUIJsvEwSnVwGjy4nLmtJp+LlMWmzdbhLcn +C5PzClkezSDd84imxtK24q2fvyzSfHS39srsuXsPry/1sEnn6QxW+Jv2V8WnaOd1+pj/53x vJDCLdfl/eFp4m4Jxvt1ZRLfry70yrtTE3y5rb2/VL3hUXxEa9PiBYn/7/AsUcrvX8W19Jag 3Xuvmi0rLqV88FBiKc5INNRiLipOBAAECPsouwIAAA== Archived-At: Subject: Re: [Ice] Trickle: What is Section 16 about? 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, 01 Mar 2018 14:01:32 -0000 --_000_D6BDD6A72BD5Cchristerholmbergericssoncom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGksDQoNCk9rLCBJIGdldCBpdCB3aHkgY29tcG9uZW50cyBuZWVkIHRvIGJlIHRyaWNrbGVkIGlu IG9yZGVyLg0KDQpCdXQsIHRoZSB0ZXh0IGFsc28gdGFsa3MgYWJvdXQgobBzdHJlYW1zobEuIEkg ZG9uoa90IHRoaW5rIHlvdSBuZWVkIHRvIHdhaXQgdW50aWwgYWxsIGNhbmRpZGF0ZXMgZm9yIG9u ZSBzdHJlYW0gaGF2ZSBiZWVuIHRyaWNrbGVkIHVudGlsIHlvdSB0cmlja2xlIHRoZSBjYW5kaWRh dGVzIGZvciBhbm90aGVyIHN0cmVhbS4NCg0KQWxzbywgdGhlIFNEUCBleGFtcGxlIHNlZW0gdG8g YXNzdW1lIHRoYXQgdGhlIG9yZGVyIG9mIFNEUCBjYW5kaWRhdGUgYXR0cmlidXRlcyBtYXR0ZXIu IEJ1dCwgaW4gU0RQIHRoZSBvcmRlciBkb2VzIG5vdCBtYXR0ZXIsIGFuZCBpbnRlcm1lZGlhcmll cyBjb3VsZCBldmVuIGNoYW5nZSB0aGUgb3JkZXIgYmV0d2VlbiBwYXJzaW5nIGFuZCBpbmNvbWlu ZyBhbmQgZ2VuZXJhdGluZyBhbiBvdXRnb2luZyBtZXNzYWdloaYNCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KRnJvbTogVGF5bG9yIEJyYW5kc3RldHRlciA8ZGVhZGJlZWZAZ29vZ2xlLmNvbTxt YWlsdG86ZGVhZGJlZWZAZ29vZ2xlLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXkgMjggRmVicnVhcnkg MjAxOCBhdCAyMDozNA0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+DQpDYzog ImljZUBpZXRmLm9yZzxtYWlsdG86aWNlQGlldGYub3JnPiIgPGljZUBpZXRmLm9yZzxtYWlsdG86 aWNlQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWNlXSBUcmlja2xlOiBXaGF0IGlzIFNlY3Rp b24gMTYgYWJvdXQ/DQoNCkRvZXMgaXQgbWVhbiB0aGF0LCB3aGVuIGFuIGFnZW50IGdhdGhlcnMg YSBuZXcgY2FuZGlkYXRlLCBpdCBtdXN0IG5vdCBzZW5kDQppdCB0byB0aGUgcGVlciBpbiBjYXNl IHRoZXJlIHdpbGwgbGF0ZXIgYmUgYSBjYW5kaWRhdGUgd2l0aCBhIGxvd2VyIElEDQp3aXRoaW4g dGhlIHNhbWUgZm91bmRhdGlvbj8NCg0KVGhhdCdzIGhvdyBJIGludGVycHJldCBpdDsgdGhlIGV4 YW1wbGUgYmVsb3cgZXhwbGFpbnMgaG93IGFuIFJUQ1AgY2FuZGlkYXRlIGZvciBhIHBhcnRpY3Vs YXIgZm91bmRhdGlvbiBtdXN0IGJlIGNvbnZleWVkIGFmdGVyIChvciBzaW11bHRhbmVvdXNseSB3 aXRoKSB0aGUgUlRQIGNhbmRpZGF0ZS4NCg0KQXMgZm9yICJ3aHkiLCBJIHRoaW5rIHRoYXQncyBl eHBsYWluZWQgYnkgdGhlIHBhcmFncmFwaCBhYm92ZToNCg0KDQogICBPbmUgaW1wb3J0YW50IGFz cGVjdCBvZiByZWd1bGFyIElDRSBpcyB0aGF0IGNvbm5lY3Rpdml0eSBjaGVja3MgZm9yIGENCiAg IHNwZWNpZmljIGZvdW5kYXRpb24gYW5kIGNvbXBvbmVudCBhcmUgYXR0ZW1wdGVkIHNpbXVsdGFu ZW91c2x5IGJ5DQogICBib3RoIGFnZW50cywgc28gdGhhdCBhbnkgZmlyZXdhbGxzIG9yIE5BVHMg ZnJvbnRpbmcgdGhlIGFnZW50cyB3b3VsZA0KICAgd2hpdGVsaXN0IGJvdGggZW5kcG9pbnRzIGFu ZCBhbGxvdyBhbGwgZXhjZXB0IGZvciB0aGUgZmlyc3QNCiAgICgic3VpY2lkZSIpIHBhY2tldHMg dG8gZ28gdGhyb3VnaC4gIFRoaXMgaXMgYWxzbyBpbXBvcnRhbnQgdG8NCiAgIHVuZnJlZXppbmcg Y2FuZGlkYXRlcyBhdCB0aGUgcmlnaHQgdGltZS4gIFdoaWxlIG5vdCBjcnVjaWFsLA0KICAgcHJl c2VydmluZyB0aGlzIGJlaGF2aW9yIGluIFRyaWNrbGUgSUNFIGlzIGxpa2VseSB0byBpbXByb3Zl IElDRQ0KICAgcGVyZm9ybWFuY2UuDQoNClRyaWNrbGluZyBjYW5kaWRhdGVzIGluIGEgc3BlY2lm aWMgb3JkZXIgaGVscHMgZ3VhcmFudGVlIHRoYXQgcGFpcnMgYXJlIGZvcm1lZCBpbiB0aGUgc2Ft ZSBvcmRlciBieSBib3RoIHBlZXJzLCBzbyB0aGF0IHRoZXknbGwgcGVyZm9ybSBjb25uZWN0aXZp dHkgY2hlY2tzIGZvciB0aGUgc2FtZSBwYWlycyBzaW11bHRhbmVvdXNseS4NCg0KVGhvdWdoIGdp dmVuIHRoZSB1cGRhdGVzIHRvIHNlY3Rpb24gOC4xLjEgKEluc2VydGluZyBhIE5ldyBQYWlyIGlu IGEgQ2hlY2sgTGlzdCksIHRoaXMgbWF5IG5vdCBiZSBhcyBpbXBvcnRhbnQgYXMgaXQgdXNlZCB0 byBiZS4gVGhlIHJ1bGVzIGluIDguMS4xIGd1YXJhbnRlZSB0aGF0IHRoZSAidG9wbW9zdCIgcGFp ciBmb3IgZWFjaCBmb3VuZGF0aW9uIHdpbGwgYWx3YXlzIGJlIHVuZnJvemVuLiBTbyBJIGJlbGll dmUgaWYgY2FuZGlkYXRlcyB3ZXJlIHRyaWNrbGVkIG91dCBvZiBvcmRlciwgdGhlIHdvcnN0IHRo YXQgY291bGQgaGFwcGVuIGlzIHRoYXQgb25lIHBlZXIgZW5kcyB1cCB3aXRoIG1vcmUgcGFpcnMg dW5mcm96ZW4gdGhhbiB0aGUgb3RoZXIuIEZvciBleGFtcGxlOg0KDQoxLiBCb2IgdHJpY2tsZXMg UlRDUCBjYW5kaWRhdGUsIHRoZW4gUlRQLg0KMi4gQWxpY2UgdHJpY2tsZXMgUlRQIGNhbmRpZGF0 ZSwgdGhlbiBSVENQLg0KMy4gQWxpY2UgcmVjZWl2ZXMgQm9iJ3MgY2FuZGlkYXRlcywgZm9ybWlu ZyBSVENQIHBhaXIgZmlyc3QgKHVuZnJlZXppbmcgaXQpLCB0aGVuIFJUUCBwYWlyICh1bmZyZWV6 aW5nIGl0IHRvbywgc2luY2UgaXQgYmVjb21lcyB0aGUgbmV3ICJ0b3Btb3N0IiBwYWlyKS4NCjQu IEJvYiByZWNlaXZlcyBBbGljZSdzIGNhbmRpZGF0ZXMsIGZvcm1pbmcgUlRQIHBhaXIgZmlyc3Qg KHVuZnJlZXppbmcgaXQpLCB0aGVuIFJUQ1AgcGFpciAobGVhdmluZyBpdCBmcm96ZW4pLg0KNS4g QWxpY2Ugbm93IGhhcyBib3RoIHBhaXJzIHVuZnJvemVuLCB3aGlsZSBCb2Igb25seSBoYXMgdGhl IFJUUCBwYWlyIHVuZnJvemVuLg0KDQpPbiBUdWUsIEZlYiAyNywgMjAxOCBhdCAxMToxMyBQTSwg Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KU2VjdGlvbiAx NiBzYXlzIHRoZSBmb2xsb3dpbmc6DQoNCiAgICJUbyBhY2hpZXZlIHRoaXMsIHdoZW4gdHJpY2ts aW5nIGNhbmRpZGF0ZXMsIGFnZW50cyBNVVNUIHJlc3BlY3QgdGhlDQogICBvcmRlciBpbiB3aGlj aCB0aGUgY29tcG9uZW50cyBhbmQgc3RyZWFtcyBhcHBlYXIgKGltcGxpY2l0bHkgb3INCiAgIGV4 cGxpY2l0bHkpIGFzIHRoZXkgaGF2ZSBiZWVuIG5lZ290aWF0ZWQgYnkgbWVhbnMgb2YgdGhlIHJl bGV2YW50DQogICBjYW5kaWRhdGUgaW5mb3JtYXRpb24uqfcNCg0KSSBjYW6p9nQgcGFyc2UgdGhp cyBzZW50ZW5jZS4gV2hhdCCp+G9yZGVyqfcgaXMgdGhlIHRleHQgdGFsa2luZyBhYm91dD8NCg0K ICAgIlRoZXJlZm9yZSBjYW5kaWRhdGVzIGZvciBhIGdpdmVuIGNvbXBvbmVudCBNVVNUIE5PVCBi ZSBjb252ZXllZCBwcmlvcg0KdG8NCiAgICBjYW5kaWRhdGVzIGZvciBhIGNvbXBvbmVudCB3aXRo IGEgbG93ZXIgSUQgbnVtYmVyIHdpdGhpbiB0aGUgc2FtZQ0KZm91bmRhdGlvbi6p9w0KDQpEb2Vz IGl0IG1lYW4gdGhhdCwgd2hlbiBhbiBhZ2VudCBnYXRoZXJzIGEgbmV3IGNhbmRpZGF0ZSwgaXQg bXVzdCBub3Qgc2VuZA0KaXQgdG8gdGhlIHBlZXIgaW4gY2FzZSB0aGVyZSB3aWxsIGxhdGVyIGJl IGEgY2FuZGlkYXRlIHdpdGggYSBsb3dlciBJRA0Kd2l0aGluIHRoZSBzYW1lIGZvdW5kYXRpb24/ IEkgdGhvdWdodCB0aGUgd2hvbGUgaWRlYSBvZiB0cmlja2xlIHdhcyB0bw0KcHJvdmlkZSBjYW5k aWRhdGVzIHRvIHRoZSBwZWVyIGluIKn4cmVhbC10aW1lqfcsIG9uY2UgdGhleSBiZWNvbWUgYXZh aWxhYmxlLg0KDQpJZiB0aGUgb3JkZXIgaW4gd2hpY2ggY2FuZGlkYXRlcyBhcmUgcGxhY2VkIGlu IFNEUCBtYXR0ZXJzLCB0aGF0IHNob3VsZCBiZQ0KZGVzY3JpYmVkIGluIHRyaWNrbGUtaWNlLXNk cC4NCg0KTXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byByZW1vdmUgU2VjdGlvbiAxNiBjb21wbGV0 ZWx5LCBidXQgSSB3b3VsZCBsaWtlDQpzb21lb25lIHRvIHRlbGwgbWUgd2h5IHdlIG5lZWQgaXQs IGFuZCB3aGF0IGV4YWN0bHkgaXQgaXMgdHJ5aW5nIHRvIHNheSA6KQ0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KSWNlIG1haWxpbmcgbGlzdA0KSWNlQGlldGYub3JnPG1haWx0bzpJY2VAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0KDQo= --_000_D6BDD6A72BD5Cchristerholmbergericssoncom_ Content-Type: text/html; charset="euc-kr" Content-ID: <4358F29EBE4AB54890165CC08A69AED9@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+SGksPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5PaywgSSBnZXQgaXQgd2h5IGNvbXBvbmVudHMgbmVl ZCB0byBiZSB0cmlja2xlZCBpbiBvcmRlci48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PkJ1dCwgdGhlIHRleHQgYWxzbyB0YWxrcyBhYm91dCChsHN0cmVhbXOhsS4gSSBkb26hr3QgdGhp bmsgeW91IG5lZWQgdG8gd2FpdCB1bnRpbCBhbGwgY2FuZGlkYXRlcyBmb3Igb25lIHN0cmVhbSBo YXZlIGJlZW4gdHJpY2tsZWQgdW50aWwgeW91IHRyaWNrbGUgdGhlIGNhbmRpZGF0ZXMgZm9yIGFu b3RoZXIgc3RyZWFtLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QWxzbywgdGhlIFNE UCBleGFtcGxlIHNlZW0gdG8gYXNzdW1lIHRoYXQgdGhlIG9yZGVyIG9mIFNEUCBjYW5kaWRhdGUg YXR0cmlidXRlcyBtYXR0ZXIuIEJ1dCwgaW4gU0RQIHRoZSBvcmRlciBkb2VzIG5vdCBtYXR0ZXIs IGFuZCBpbnRlcm1lZGlhcmllcyBjb3VsZCBldmVuIGNoYW5nZSB0aGUgb3JkZXIgYmV0d2VlbiBw YXJzaW5nIGFuZCBpbmNvbWluZyBhbmQgZ2VuZXJhdGluZyBhbiBvdXRnb2luZyBtZXNzYWdloaY8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5DaHJpc3RlcjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp OyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJP VFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RU T006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRP UDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkct VE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5U YXlsb3IgQnJhbmRzdGV0dGVyICZsdDs8YSBocmVmPSJtYWlsdG86ZGVhZGJlZWZAZ29vZ2xlLmNv bSI+ZGVhZGJlZWZAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXkgMjggRmVicnVhcnkgMjAxOCBhdCAyMDoz NDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkNocmlzdGVy IEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpp Y2VAaWV0Zi5vcmciPmljZUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpp Y2VAaWV0Zi5vcmciPmljZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0ljZV0gVHJpY2tsZTogV2hhdCBpcyBT ZWN0aW9uIDE2IGFib3V0Pzxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigy MDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8Zm9udCBmYWNlPSJhcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigzNCwzNCwzNCk7Zm9udC1zaXpl OjEyLjhweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6NDAwO2xldHRlci1zcGFjaW5nOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25l O3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O2JhY2tncm91bmQtY29sb3I6cmdi KDI1NSwyNTUsMjU1KTt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRp b24tY29sb3I6aW5pdGlhbDtmbG9hdDpub25lO2Rpc3BsYXk6aW5saW5lIj5Eb2VzDQogaXQgbWVh biB0aGF0LCB3aGVuIGFuIGFnZW50IGdhdGhlcnMgYSBuZXcgY2FuZGlkYXRlLCBpdCBtdXN0IG5v dCBzZW5kPC9zcGFuPjxiciBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LXNpemU6MTIu OHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDo0MDA7bGV0dGVyLXNwYWNpbmc6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hp dGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1 LDI1NSwyNTUpO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1j b2xvcjppbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtc2l6 ZToxMi44cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDtsZXR0ZXItc3BhY2luZzpu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9u ZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNvbG9yOnJn YigyNTUsMjU1LDI1NSk7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0 aW9uLWNvbG9yOmluaXRpYWw7ZmxvYXQ6bm9uZTtkaXNwbGF5OmlubGluZSI+aXQNCiB0byB0aGUg cGVlciBpbiBjYXNlIHRoZXJlIHdpbGwgbGF0ZXIgYmUgYSBjYW5kaWRhdGUgd2l0aCBhIGxvd2Vy IElEPC9zcGFuPjxiciBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LXNpemU6MTIuOHB4 O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDo0MDA7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUt c3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1 NSwyNTUpO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xv cjppbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtc2l6ZTox Mi44cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDtsZXR0ZXItc3BhY2luZzpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3 aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigy NTUsMjU1LDI1NSk7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9u LWNvbG9yOmluaXRpYWw7ZmxvYXQ6bm9uZTtkaXNwbGF5OmlubGluZSI+d2l0aGluDQogdGhlIHNh bWUgZm91bmRhdGlvbj88L3NwYW4+PGJyPg0KPC9mb250PjwvYmxvY2txdW90ZT4NCjxkaXY+PGZv bnQgZmFjZT0iYXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPlRoYXQncyBob3cg SSBpbnRlcnByZXQgaXQ7IHRoZSBleGFtcGxlIGJlbG93IGV4cGxhaW5zIGhvdyBhbiBSVENQIGNh bmRpZGF0ZSBmb3IgYSBwYXJ0aWN1bGFyIGZvdW5kYXRpb24gbXVzdCBiZSBjb252ZXllZCBhZnRl ciAob3Igc2ltdWx0YW5lb3VzbHkgd2l0aCkgdGhlIFJUUCBjYW5kaWRhdGUuPC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJhcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+PGJyPg0KPC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJhcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+ QXMgZm9yICZxdW90O3doeSZxdW90OywgSSB0aGluayB0aGF0J3MgZXhwbGFpbmVkIGJ5IHRoZSBw YXJhZ3JhcGggYWJvdmU6PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJhcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZiI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0 OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPHByZSBjbGFz cz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDow cHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAsMCwwKTtmb250LXN0eWxlOm5vcm1hbDtm b250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9u dC13ZWlnaHQ6NDAwO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQt aW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3dvcmQtc3BhY2luZzowcHg7dGV4dC1kZWNv cmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWwiPjxmb250 IGZhY2U9ImFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj4gICBPbmUgaW1wb3J0YW50IGFzcGVj dCBvZiByZWd1bGFyIElDRSBpcyB0aGF0IGNvbm5lY3Rpdml0eSBjaGVja3MgZm9yIGENCiAgIHNw ZWNpZmljIGZvdW5kYXRpb24gYW5kIGNvbXBvbmVudCBhcmUgYXR0ZW1wdGVkIHNpbXVsdGFuZW91 c2x5IGJ5DQogICBib3RoIGFnZW50cywgc28gdGhhdCBhbnkgZmlyZXdhbGxzIG9yIE5BVHMgZnJv bnRpbmcgdGhlIGFnZW50cyB3b3VsZA0KICAgd2hpdGVsaXN0IGJvdGggZW5kcG9pbnRzIGFuZCBh bGxvdyBhbGwgZXhjZXB0IGZvciB0aGUgZmlyc3QNCiAgICgmcXVvdDtzdWljaWRlJnF1b3Q7KSBw YWNrZXRzIHRvIGdvIHRocm91Z2guICBUaGlzIGlzIGFsc28gaW1wb3J0YW50IHRvDQogICB1bmZy ZWV6aW5nIGNhbmRpZGF0ZXMgYXQgdGhlIHJpZ2h0IHRpbWUuICBXaGlsZSBub3QgY3J1Y2lhbCwN CiAgIHByZXNlcnZpbmcgdGhpcyBiZWhhdmlvciBpbiBUcmlja2xlIElDRSBpcyBsaWtlbHkgdG8g aW1wcm92ZSBJQ0UNCiAgIHBlcmZvcm1hbmNlLjwvZm9udD48L3ByZT4NCjwvYmxvY2txdW90ZT4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRyaWNrbGluZyBjYW5kaWRhdGVzIGluIGEgc3BlY2lm aWMgb3JkZXIgaGVscHMgZ3VhcmFudGVlIHRoYXQgcGFpcnMgYXJlIGZvcm1lZCBpbiB0aGUgc2Ft ZSBvcmRlciBieSBib3RoIHBlZXJzLCBzbyB0aGF0IHRoZXknbGwgcGVyZm9ybSBjb25uZWN0aXZp dHkgY2hlY2tzIGZvciB0aGUgc2FtZSBwYWlycyBzaW11bHRhbmVvdXNseS48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PlRob3VnaCBnaXZlbiB0aGUgdXBkYXRlcyB0byBzZWN0aW9uIDgu MS4xIChJbnNlcnRpbmcgYSBOZXcgUGFpciBpbiBhIENoZWNrIExpc3QpLCB0aGlzIG1heSBub3Qg YmUgYXMgaW1wb3J0YW50IGFzIGl0IHVzZWQgdG8gYmUuIFRoZSBydWxlcyBpbiA4LjEuMSBndWFy YW50ZWUgdGhhdCB0aGUgJnF1b3Q7dG9wbW9zdCZxdW90OyBwYWlyIGZvciBlYWNoIGZvdW5kYXRp b24gd2lsbCBhbHdheXMgYmUgdW5mcm96ZW4uIFNvIEkgYmVsaWV2ZSBpZiBjYW5kaWRhdGVzDQog d2VyZSB0cmlja2xlZCBvdXQgb2Ygb3JkZXIsIHRoZSB3b3JzdCB0aGF0IGNvdWxkIGhhcHBlbiBp cyB0aGF0IG9uZSBwZWVyIGVuZHMgdXAgd2l0aCBtb3JlIHBhaXJzIHVuZnJvemVuIHRoYW4gdGhl IG90aGVyLiBGb3IgZXhhbXBsZTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjEuIEJv YiB0cmlja2xlcyBSVENQIGNhbmRpZGF0ZSwgdGhlbiBSVFAuPC9kaXY+DQo8ZGl2PjIuIEFsaWNl IHRyaWNrbGVzIFJUUCBjYW5kaWRhdGUsIHRoZW4gUlRDUC48L2Rpdj4NCjxkaXY+My4gQWxpY2Ug cmVjZWl2ZXMgQm9iJ3MgY2FuZGlkYXRlcywgZm9ybWluZyBSVENQIHBhaXIgZmlyc3QgKHVuZnJl ZXppbmcgaXQpLCB0aGVuIFJUUCBwYWlyICh1bmZyZWV6aW5nIGl0IHRvbywgc2luY2UgaXQgYmVj b21lcyB0aGUgbmV3ICZxdW90O3RvcG1vc3QmcXVvdDsgcGFpcikuPC9kaXY+DQo8ZGl2PjQuIEJv YiByZWNlaXZlcyBBbGljZSdzIGNhbmRpZGF0ZXMsIGZvcm1pbmcgUlRQIHBhaXIgZmlyc3QgKHVu ZnJlZXppbmcgaXQpLCB0aGVuIFJUQ1AgcGFpciAobGVhdmluZyBpdCBmcm96ZW4pLjwvZGl2Pg0K PGRpdj41LiBBbGljZSBub3cgaGFzIGJvdGggcGFpcnMgdW5mcm96ZW4sIHdoaWxlIEJvYiBvbmx5 IGhhcyB0aGUgUlRQIHBhaXIgdW5mcm96ZW4uPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRy YSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFR1ZSwgRmViIDI3LCAyMDE4IGF0 IDExOjEzIFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJl Zj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+ DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAw cHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1s ZWZ0OjFleCI+DQpIaSw8YnI+DQo8YnI+DQpTZWN0aW9uIDE2IHNheXMgdGhlIGZvbGxvd2luZzo8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7JnF1b3Q7VG8gYWNoaWV2ZSB0aGlzLCB3aGVuIHRyaWNr bGluZyBjYW5kaWRhdGVzLCBhZ2VudHMgTVVTVCByZXNwZWN0IHRoZTxicj4NCiZuYnNwOyAmbmJz cDtvcmRlciBpbiB3aGljaCB0aGUgY29tcG9uZW50cyBhbmQgc3RyZWFtcyBhcHBlYXIgKGltcGxp Y2l0bHkgb3I8YnI+DQombmJzcDsgJm5ic3A7ZXhwbGljaXRseSkgYXMgdGhleSBoYXZlIGJlZW4g bmVnb3RpYXRlZCBieSBtZWFucyBvZiB0aGUgcmVsZXZhbnQ8YnI+DQombmJzcDsgJm5ic3A7Y2Fu ZGlkYXRlIGluZm9ybWF0aW9uLqn3PGJyPg0KPGJyPg0KSSBjYW6p9nQgcGFyc2UgdGhpcyBzZW50 ZW5jZS4gV2hhdCCp+G9yZGVyqfcgaXMgdGhlIHRleHQgdGFsa2luZyBhYm91dD88YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7JnF1b3Q7VGhlcmVmb3JlIGNhbmRpZGF0ZXMgZm9yIGEgZ2l2ZW4gY29t cG9uZW50IE1VU1QgTk9UIGJlIGNvbnZleWVkIHByaW9yPGJyPg0KdG88YnI+DQombmJzcDsgJm5i c3A7IGNhbmRpZGF0ZXMgZm9yIGEgY29tcG9uZW50IHdpdGggYSBsb3dlciBJRCBudW1iZXIgd2l0 aGluIHRoZSBzYW1lPGJyPg0KZm91bmRhdGlvbi6p9zxicj4NCjxicj4NCkRvZXMgaXQgbWVhbiB0 aGF0LCB3aGVuIGFuIGFnZW50IGdhdGhlcnMgYSBuZXcgY2FuZGlkYXRlLCBpdCBtdXN0IG5vdCBz ZW5kPGJyPg0KaXQgdG8gdGhlIHBlZXIgaW4gY2FzZSB0aGVyZSB3aWxsIGxhdGVyIGJlIGEgY2Fu ZGlkYXRlIHdpdGggYSBsb3dlciBJRDxicj4NCndpdGhpbiB0aGUgc2FtZSBmb3VuZGF0aW9uPyBJ IHRob3VnaHQgdGhlIHdob2xlIGlkZWEgb2YgdHJpY2tsZSB3YXMgdG88YnI+DQpwcm92aWRlIGNh bmRpZGF0ZXMgdG8gdGhlIHBlZXIgaW4gqfhyZWFsLXRpbWWp9ywgb25jZSB0aGV5IGJlY29tZSBh dmFpbGFibGUuPGJyPg0KPGJyPg0KSWYgdGhlIG9yZGVyIGluIHdoaWNoIGNhbmRpZGF0ZXMgYXJl IHBsYWNlZCBpbiBTRFAgbWF0dGVycywgdGhhdCBzaG91bGQgYmU8YnI+DQpkZXNjcmliZWQgaW4g dHJpY2tsZS1pY2Utc2RwLjxicj4NCjxicj4NCk15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gcmVt b3ZlIFNlY3Rpb24gMTYgY29tcGxldGVseSwgYnV0IEkgd291bGQgbGlrZTxicj4NCnNvbWVvbmUg dG8gdGVsbCBtZSB3aHkgd2UgbmVlZCBpdCwgYW5kIHdoYXQgZXhhY3RseSBpdCBpcyB0cnlpbmcg dG8gc2F5IDopPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpDaHJpc3Rlcjxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19fX188 YnI+DQpJY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkljZUBpZXRmLm9yZyI+ SWNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWNlIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGluZm8vaWNlPC9hPjxicj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3Nw YW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D6BDD6A72BD5Cchristerholmbergericssoncom_-- From nobody Thu Mar 1 06:09:54 2018 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 BC9B7124BAC for ; Thu, 1 Mar 2018 06:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 X2D5MYqXwIUj for ; Thu, 1 Mar 2018 06:09:46 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD4D1200F1 for ; Thu, 1 Mar 2018 06:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519913384; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2B86qDu9hJy/w6lcTeBLictIyB+IXAqODI+tpgjRYZ8=; b=MygTj3CUOIuG12ia1fDiJ6GjZQkhXHgPqsdyEM65YzYA65S1GzpWCu098YRW/0zF PwpVky5MTVe8apdrTcZc4Ij5SI1PH1ir7CMxJ5vNLWZ4uRvJOdrDvKCaFXJ//ixO ZJLrDBCzdkyPTg9J7DjppexaJ59bDI27pBTtThHBXfQ=; X-AuditID: c1b4fb2d-499ff70000005540-e5-5a9809a87695 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8E.B8.21824.8A9089A5; Thu, 1 Mar 2018 15:09:44 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Thu, 1 Mar 2018 15:09:43 +0100 From: Christer Holmberg To: Eric Rescorla , =?iso-8859-1?Q?Ari_Ker=E4nen?= CC: The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , Peter Thatcher , "ice@ietf.org" Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) Thread-Index: AdOpa677O8VqdAW5ThyXNM/NhWOUGQAG8xsAAerqwYAACYXUgAAF+QMA Date: Thu, 1 Mar 2018 14:09:43 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C17768D@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.7.170905 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D6BDD8092BD66christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUyM2K7n+4KzhlRBnf3iFvMP3md2WLF63Ps FhdnTWaz+Hah1mLGn4nMFteWv2Z1YPNYsKnUY8mSn0wekx+3MQcwR3HZpKTmZJalFunbJXBl zDt+l7XgiW/FpClt7A2MU5y6GDk5JARMJGYev8DUxcjFISRwmFHi3LmXjBDOIkaJWR97gRwO DjYBC4nuf9ogDSICsRJn53exgdQwCzxglNi79z8TSEJYoF5i5oLjrCAJEYEGRokvl6awQnS4 SazcspQZxGYRUJHYe+8HWJxXwFri0Mm9LCC2kMBEJom1M9VAbE6BQInXbzayg9iMAmIS30+t AVvALCAucevJfCaIswUkluw5zwxhi0q8fPwPbKaogJ7EhhO32SHiShI/NlxigehNkDj2dT8T xF5BiZMzn7BMYBSdhWTsLCRls5CUQcT1JG5MncIGYWtLLFv4mhnC1pWY8e8QVI21xI6br5iQ 1Sxg5FjFKFqcWlycm25krJdalJlcXJyfp5eXWrKJERi5B7f81t3BuPq14yFGAQ5GJR7eawwz ooRYE8uKK3MPMUpwMCuJ8J7ePi1KiDclsbIqtSg/vqg0J7X4EKM0B4uSOO9JT94oIYH0xJLU 7NTUgtQimCwTB6dUA2NYU9xnLrbE9DVKITsM89vOZx0WnlBzNrusJT2YTfAEk3/0HI58bV4u /q08h4/LcCn3K7z9dkNofnHflrXqBziU36kYcIWfXlIwxzBv24ayA63ud3mz4yaxMO2Z2OdR /lLlplS7j5O/ZvaBDI2zZ3YzT3seVXHbUjXBrO2ox7WLiUvW33geqcRSnJFoqMVcVJwIAHUl /hjYAgAA Archived-At: Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) 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, 01 Mar 2018 14:09:49 -0000 --_000_D6BDD8092BD66christerholmbergericssoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I guess Ari will reply, but my understanding is that, since triggered check= s have high priority, we want the triggered binding requests to be sent asa= p. But, if the ongoing transaction (In-Progress) has already been going on = for a while, and all transmitted/re-transmitted binding requests so far for= whatever reason have got dropped in the network, due to the current re-tra= nsmission timer (which grows after each re-transmission) it may take a whil= e before binding check is re-transmitted again. (Of course, even if we create a new transaction, there may be other checks = waiting in the triggered check queue, so it may still take a while before t= he new binding check is sent.) Regards, Christer From: Eric Rescorla > Date: Thursday 1 March 2018 at 15:31 To: Ari Ker=E4nen > Cc: Christer Holmberg >, "iesg@ietf.org" >, "draft-ietf-ice-rfc5245bis@ietf.org" >, "ice-chairs@ietf.org" >, "pthatcher@googl= e.com" >, "ice@ietf.org" > Subject: Re: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: = (with COMMENT) (excluding Security Considerations) On Thu, Mar 1, 2018 at 12:58 AM, Ari Ker=E4nen > wrote: Hi Eric & Christer, > On 19 Feb 2018, at 16.42, Eric Rescorla > wrote: > > > > > in-progress transaction. Cancellation means that the agent > > will not retransmit the request, will not treat the lack of > > response to be a failure, but will wait the duration of the > > > > Why are you cancelling In-Progress checks when you receive a peer-refle= ctive check? > > If you receive two in a row, then it seems like this delays a successfu= l check. > > True. > > So, I will remove the cancel part. > > Do you still think it should create a new binding request, or is the ongo= ing In-Progress check enough to check the pair? > > My initial reaction is you don't need to do anything extra, but I could e= asily be wrong here. I'm afraid this is one of the parts of the spec that solves a corner case i= n an interesting but non-obvious way. For context, here's the original text= : https://tools.ietf.org/html/rfc5245#section-7.2.1.4 IIRC, one of the reasons for this is that an agent might have started the t= ransaction a while ago, perhaps even sent a few re-transmissions. Now, if y= ou don't cancel that transaction, but just keep that going and send the rem= aining re-transmission(s) and those are lost due to bad network connectivit= y, you end up marking that pair as failed. However, if you cancel and start= a new transaction, you have full amount of fast retransmissions to go. And= if you receive a reply to a cancelled check, it is still a success. I reme= mber this was unintuitive but eventually made sense when I implemented it. So, I'd recommend we keep this text as such. Why is this different from any other case of transient failure? -Ekr Cheers, Ari (hat off) --_000_D6BDD8092BD66christerholmbergericssoncom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <4AC1E8C3DD3C384F815AA7FC65C69601@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I guess Ari will reply, but my understanding is that, since triggered = checks have high priority, we want the triggered binding requests to be sen= t asap. But, if the ongoing transaction (In-Progress) has already been goin= g on for a while, and all transmitted/re-transmitted binding requests so far for whatever reason have got dropped in the networ= k, due to the current re-transmission timer (which grows after each re-tran= smission) it may take a while before binding check is re-transmitted again.=  

(Of course, even if we create a new transaction, there may be other ch= ecks waiting in the triggered check queue, so it may still take a while bef= ore the new binding check is sent.)

Regards,

Christer

From: Eric Rescorla <ekr@rtfm.com>
Date: Thursday 1 March 2018 at 15:3= 1
To: Ari Ker=E4nen <ari.keranen@ericsson.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "iesg@ietf.org" <= iesg@ietf.org>, "draft-ietf-ice-rfc5245bis@ietf.org= " <draft-ietf-ice-r= fc5245bis@ietf.org>, "ic= e-chairs@ietf.org" <ice-= chairs@ietf.org>, "ptha= tcher@google.com" <pthatcher@google.com>, = "ice@ietf.org" <ice@ietf.org>
Subject: Re: Eric Rescorla's No Obj= ection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security = Considerations)



On Thu, Mar 1, 2018 at 12:58 AM, Ari Ker=E4nen <= span dir=3D"ltr"> <ari.keran= en@ericsson.com> wrote:
Hi Eric & Christer,

> On 19 Feb 2018, at 16.42, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> >         in-progress transaction.  C= ancellation means that the agent
> >         will not retransmit the request,= will not treat the lack of
> >         response to be a failure, but wi= ll wait the duration of the
> >
> > Why are you cancelling In-Progress checks when you receive a peer= -reflective check?
> > If you receive two in a row, then it seems like this delays a suc= cessful check.
>
> True.
>
> So, I will remove the cancel part.
>
> Do you still think it should create a new binding request, or is the o= ngoing In-Progress check enough to check the pair?
>
> My initial reaction is you don't need to do anything extra, but I coul= d easily be wrong here.

I'm afraid this is one of the parts of the spec that solves a corner= case in an interesting but non-obvious way. For context, here's the origin= al text:
https://tools.ietf.org/html/rfc5245#section-= 7.2.1.4

IIRC, one of the reasons for this is that an agent might have started the t= ransaction a while ago, perhaps even sent a few re-transmissions. Now, if y= ou don't cancel that transaction, but just keep that going and send the rem= aining re-transmission(s) and those are lost due to bad network connectivity, you end up marking that pair as = failed. However, if you cancel and start a new transaction, you have full a= mount of fast retransmissions to go. And if you receive a reply to a cancel= led check, it is still a success. I remember this was unintuitive but eventually made sense when I implement= ed it.

So, I'd recommend we keep this text as such.

Why is this different from any other case of transient failure?

-Ekr



Cheers,
Ari (hat off)

 --_000_D6BDD8092BD66christerholmbergericssoncom_-- From nobody Thu Mar 1 09:04:09 2018 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 C6D3612EB69 for ; Thu, 1 Mar 2018 09:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 gO0Xyu4qA1AT for ; Thu, 1 Mar 2018 09:04:04 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F095112DA3D for ; Thu, 1 Mar 2018 09:04:03 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id u200so4106806vke.4 for ; Thu, 01 Mar 2018 09:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hF62P2l+xAtuRQgmoZsiUlugxYzU1diah3PW3WrZOEg=; b=hRt+lWsJhPRq4xNII8g4Qde44fWMi6IYW1cDTLqtM4YVvhwlDbkZ/TskFkWCGeui3E lnVuSS1LV60DX6fItAj08A2qQdKO2D/eWAdnaQg3etuU5LQvOhiV2UhPiglxro5M4v+O 3Z7LVpC+3reLlMkwpnphaNwJQbx10rlk06hp6rAEVijmJuhafXsjamjyMiaKBHVm5yb7 XuSeIFZJ2qnJpz0dJFcc3/ue+3611y7ZN92VZWE/pb3mXBExxBRL1FCX+dxxvE34EVXT PPGS42llNFVYCA+hYcSDOlcdprU2h4HmLXbwCTtkR5ryLWsvXTfx2MH7OzMFAp79OW9V k8Fw== 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=hF62P2l+xAtuRQgmoZsiUlugxYzU1diah3PW3WrZOEg=; b=XsgB8tB2OYiu8ZTQKc7sYziDLlRvCHNx8OZfnlNL7TMZ+8fv8+mDLE9UpOpdJhYpSn a3iKSMy/rz46fbkAs2S8VkVVD2+siVEW9mNoJ3jwg98j20s23jVwuGflEEZxyu43JQUS KWqbUs5YtE/c+ixG7o+Qb4Xpj9/DvcyymX+d/CTpydV46xA44ZWKRhhiarccBPm7LYKt +d7x0Qb/UmCBS/b8179JknHEDo3HV7sF0XTaIuIaIEapFEygxHnlruHUGEQc8Y27MyUS jDpS7KWQLDGOu0XFtd8wZTSFBEL9W95Bn6ZU7IvmWc5BKbsOkvwqrXpQ8F7mZ1CqY6Oo k95Q== X-Gm-Message-State: APf1xPCQr2TuM14m9nG+pHI9SHxdFT2k1dstV8fxY7jWgt7eAbKHZp2W QPjz8UxMv8QVFOb9cvLqomdYyRWGl8NAWbU0OSvqRw== X-Google-Smtp-Source: AG47ELsMDVB4xWPNmNV8hOIUQLbADmf2A0bcEDoJH4sIkjfrbRQVCDR/W8y2skVr1Rrk5nbdnPoHvBXvszidU2rtUtk= X-Received: by 10.31.10.200 with SMTP id 191mr1721782vkk.46.1519923842534; Thu, 01 Mar 2018 09:04:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.114.66 with HTTP; Thu, 1 Mar 2018 09:04:01 -0800 (PST) In-Reply-To: References: From: Taylor Brandstetter Date: Thu, 1 Mar 2018 09:04:01 -0800 Message-ID: To: Christer Holmberg Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a11458b12b96b9805665cd8a0" Archived-At: Subject: Re: [Ice] Trickle: What is Section 16 about? 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, 01 Mar 2018 17:04:08 -0000 --001a11458b12b96b9805665cd8a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > I don=E2=80=99t think you need to wait until all candidates for one strea= m have > been trickled until you trickle the candidates for another stream. > What makes "streams" different than "components" in this regard? Both determine what pair is unfrozen first. You can take the example above and replace "RTP" with "stream 1" and "RTCP" with "stream 2" and it still applies. It doesn't say you need to wait for *all* candidates for one stream before trickling *any* candidate for another stream, though. This is only talking about candidates "within the same foundation". It would be fine to legal them in the order "stream 1 host", "stream 2 host", "stream 1 srflx", "stream 2 srflx". On Thu, Mar 1, 2018 at 6:01 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Ok, I get it why components need to be trickled in order. > > But, the text also talks about =E2=80=9Cstreams=E2=80=9D. I don=E2=80=99t= think you need to wait > until all candidates for one stream have been trickled until you trickle > the candidates for another stream. > > Also, the SDP example seem to assume that the order of SDP candidate > attributes matter. But, in SDP the order does not matter, and > intermediaries could even change the order between parsing and incoming a= nd > generating an outgoing message=E2=80=A6 > > Regards, > > Christer > > From: Taylor Brandstetter > Date: Wednesday 28 February 2018 at 20:34 > To: Christer Holmberg > Cc: "ice@ietf.org" > Subject: Re: [Ice] Trickle: What is Section 16 about? > > Does it mean that, when an agent gathers a new candidate, it must not sen= d >> it to the peer in case there will later be a candidate with a lower ID >> within the same foundation? >> > > That's how I interpret it; the example below explains how an RTCP > candidate for a particular foundation must be conveyed after (or > simultaneously with) the RTP candidate. > > As for "why", I think that's explained by the paragraph above: > > One important aspect of regular ICE is that connectivity checks for a >> specific foundation and component are attempted simultaneously by >> both agents, so that any firewalls or NATs fronting the agents would >> whitelist both endpoints and allow all except for the first >> ("suicide") packets to go through. This is also important to >> unfreezing candidates at the right time. While not crucial, >> preserving this behavior in Trickle ICE is likely to improve ICE >> performance. >> >> > Trickling candidates in a specific order helps guarantee that pairs are > formed in the same order by both peers, so that they'll perform > connectivity checks for the same pairs simultaneously. > > Though given the updates to section 8.1.1 (Inserting a New Pair in a Chec= k > List), this may not be as important as it used to be. The rules in 8.1.1 > guarantee that the "topmost" pair for each foundation will always be > unfrozen. So I believe if candidates were trickled out of order, the wors= t > that could happen is that one peer ends up with more pairs unfrozen than > the other. For example: > > 1. Bob trickles RTCP candidate, then RTP. > 2. Alice trickles RTP candidate, then RTCP. > 3. Alice receives Bob's candidates, forming RTCP pair first (unfreezing > it), then RTP pair (unfreezing it too, since it becomes the new "topmost" > pair). > 4. Bob receives Alice's candidates, forming RTP pair first (unfreezing > it), then RTCP pair (leaving it frozen). > 5. Alice now has both pairs unfrozen, while Bob only has the RTP pair > unfrozen. > > On Tue, Feb 27, 2018 at 11:13 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> Section 16 says the following: >> >> "To achieve this, when trickling candidates, agents MUST respect the >> order in which the components and streams appear (implicitly or >> explicitly) as they have been negotiated by means of the relevant >> candidate information.=C2=B2 >> >> I can=C2=B9t parse this sentence. What =C2=B3order=C2=B2 is the text tal= king about? >> >> "Therefore candidates for a given component MUST NOT be conveyed prio= r >> to >> candidates for a component with a lower ID number within the same >> foundation.=C2=B2 >> >> Does it mean that, when an agent gathers a new candidate, it must not se= nd >> it to the peer in case there will later be a candidate with a lower ID >> within the same foundation? I thought the whole idea of trickle was to >> provide candidates to the peer in =C2=B3real-time=C2=B2, once they becom= e available. >> >> If the order in which candidates are placed in SDP matters, that should = be >> described in trickle-ice-sdp. >> >> My suggestion would be to remove Section 16 completely, but I would like >> someone to tell me why we need it, and what exactly it is trying to say = :) >> >> Regards, >> >> Christer >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> > > --001a11458b12b96b9805665cd8a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don=E2=80=99t think you need to wait until all candidates= for one stream have been trickled until you trickle the candidates for ano= ther stream.

What makes "st= reams" different than "components" in this regard? Both dete= rmine what pair is unfrozen first. You can take the example above and repla= ce "RTP" with "stream 1" and "RTCP" with &quo= t;stream 2" and it still applies.

It does= n't say you need to wait for all=C2=A0candidates for one stream = before trickling any=C2=A0candidate for another stream, though. This= is only talking about candidates "within the same foundation". I= t would be fine to legal them in the order "stream 1 host", "= ;stream 2 host", "stream 1 srflx", "stream 2 srflx"= ;.

On = Thu, Mar 1, 2018 at 6:01 AM, Christer Holmberg <christer.holm= berg@ericsson.com> wrote:
Hi,

Ok, I get it why components need to be trickled in order.

But, the text also talks about =E2=80=9Cstreams=E2=80=9D. I don=E2=80= =99t think you need to wait until all candidates for one stream have been t= rickled until you trickle the candidates for another stream.

Also, the SDP example seem to assume that the order of SDP candidate a= ttributes matter. But, in SDP the order does not matter, and intermediaries= could even change the order between parsing and incoming and generating an= outgoing message=E2=80=A6

Regards,

Christer

From: Taylor Brandstetter <deadbeef@google.com= >
Date: Wednesday 28 February 2018 at= 20:34
To: Christer Holmberg <christer.holmb= erg@ericsson.com>
Cc: "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Trickle: What is= Section 16 about?

Does it mean that, when an agent gathers a new candidate, it must not send
it to the peer in case there will later be a candidate with a lower ID=
wi= thin the same foundation?

That's how I interpret i= t; the example below explains how an RTCP candidate for a particular founda= tion must be conveyed after (or simultaneously with) the RTP candidate.

As for "why", I th= ink that's explained by the paragraph above:

   One important aspect of regular I=
CE is that connectivity checks for a
   specific foundation and component are attempted simultaneously by
   both agents, so that any firewalls or NATs fronting the agents would
   whitelist both endpoints and allow all except for the first
   ("suicide") packets to go through.  This is also important to
   unfreezing candidates at the right time.  While not crucial,
   preserving this behavior in Trickle ICE is likely to improve ICE
   performance.

Trickling candidates in a specific order helps guarantee that pairs ar= e formed in the same order by both peers, so that they'll perform conne= ctivity checks for the same pairs simultaneously.

Though given the updates to section 8.1.1 (Inserting a New Pair in a C= heck List), this may not be as important as it used to be. The rules in 8.1= .1 guarantee that the "topmost" pair for each foundation will alw= ays be unfrozen. So I believe if candidates were trickled out of order, the worst that could happen is that one peer e= nds up with more pairs unfrozen than the other. For example:

1. Bob trickles RTCP candidate, then RTP.
2. Alice trickles RTP candidate, then RTCP.
3. Alice receives Bob's candidates, forming RTCP pair first (unfre= ezing it), then RTP pair (unfreezing it too, since it becomes the new "= ;topmost" pair).
4. Bob receives Alice's candidates, forming RTP pair first (unfree= zing it), then RTCP pair (leaving it frozen).
5. Alice now has both pairs unfrozen, while Bob only has the RTP pair = unfrozen.

On Tue, Feb 27, 2018 at 11:13 PM, Christer Holmb= erg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

Section 16 says the following:

=C2=A0 =C2=A0"To achieve this, when trickling candidates, agents MUST = respect the
=C2=A0 =C2=A0order in which the components and streams appear (implicitly o= r
=C2=A0 =C2=A0explicitly) as they have been negotiated by means of the relev= ant
=C2=A0 =C2=A0candidate information.=C2=B2

I can=C2=B9t parse this sentence. What =C2=B3order=C2=B2 is the text talkin= g about?

=C2=A0 =C2=A0"Therefore candidates for a given component MUST NOT be c= onveyed prior
to
=C2=A0 =C2=A0 candidates for a component with a lower ID number within the = same
foundation.=C2=B2

Does it mean that, when an agent gathers a new candidate, it must not send<= br> it to the peer in case there will later be a candidate with a lower ID
within the same foundation? I thought the whole idea of trickle was to
provide candidates to the peer in =C2=B3real-time=C2=B2, once they become a= vailable.

If the order in which candidates are placed in SDP matters, that should be<= br> described in trickle-ice-sdp.

My suggestion would be to remove Section 16 completely, but I would like someone to tell me why we need it, and what exactly it is trying to say :)<= br>
Regards,

Christer

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

--001a11458b12b96b9805665cd8a0-- From nobody Thu Mar 1 09:05:51 2018 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 0BC1512EAE9 for ; Thu, 1 Mar 2018 09:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Q_R2F-h1Nsvg for ; Thu, 1 Mar 2018 09:05:40 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DEF12EBD1 for ; Thu, 1 Mar 2018 09:05:39 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id s1so4114187vke.5 for ; Thu, 01 Mar 2018 09:05:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c5n4XjKgKYlGKwicUN0a17Xy0/dP03LsCQbfQApkf7w=; b=mE9WBUa+xs+i2mGJs0KMB7AfY9kCbjquw7Bpkonoqo3pddH1mkVP5yTxL99Sn0KS1T 6tnVYsDNB0Smq22EYkkd4jr6TEH7K6QPpKpAMFHaMKtUQxyKeMJ4av627mOvRJASpfre 2EqDqc66D/RAxBNFpAwAbPV9gpGbhdZ6sttUaJfO2tUuVO1RABlO2cypguBWQ6qllTQ/ /MwZL4tWNP2c+oDYObSjRgnp+w524XRHQbsQzS9d8cwZgN5kACb/4UXGrZhku60kYBrT 2SSc3LIPjBffPQjwixoc6CGv1Hyh8rVa4XsDyigOYcQcuEL6LjG1DXKtyLkqUQmmrIOX 9hkA== 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=c5n4XjKgKYlGKwicUN0a17Xy0/dP03LsCQbfQApkf7w=; b=duOqxNyzqow1S9is5s+RwUpsLwvkPK8jOOEJHgRcKNh46ZwWhoYWL2CCMGnNV1fzGu BMGB8UTIT7BEv0i8uEuduxmJGbYY6ZLxzBFtzSNtCLU9gXtKTTM0mnQBV7Y5d9u16B9O W3jEIitbi4aZdWHKVAh0Vnm7RDJ8OiZJOeRoBHYE28y1Us5Vwl6OWSp+H25NfeljU3kp oUTv2jC/fhIo/GsyWP959jb9y/GJvFwvwDaEyeP6BQa/JuGDpsBIh9WivxuGMobEiNtv VrLZNr3Ao0YEfqKR3cZpWTJjb4djxlZNzrwtQJPHaM4Gx9n6n8MtBi9vmk49GceYngGy 6HTw== X-Gm-Message-State: APf1xPCCA9YiveejpEbC8psLaRqzUlZhdSTIGSOS3S1qjjWRmIO5w9Dv JuLZlpLppj+5EYbRxIiA6+ClxFjcZqTbJGpdC1fJJ6PJNhI= X-Google-Smtp-Source: AG47ELuBscwlIbBZRO17j4F5isIi2JeSttlRrNxSLFK/l0Qj0+wg9rS2fAJkNEGmRH9CuMeqHEHTU8xZNR0u9Ke/yws= X-Received: by 10.31.209.69 with SMTP id i66mr1728408vkg.95.1519923938040; Thu, 01 Mar 2018 09:05:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.114.66 with HTTP; Thu, 1 Mar 2018 09:05:37 -0800 (PST) In-Reply-To: References: From: Taylor Brandstetter Date: Thu, 1 Mar 2018 09:05:37 -0800 Message-ID: To: Christer Holmberg Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a114e50b06a3b6005665cde8b" Archived-At: Subject: Re: [Ice] Trickle: What is Section 16 about? 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, 01 Mar 2018 17:05:50 -0000 --001a114e50b06a3b6005665cde8b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (Meant to say "fine to *trickle* them"...) On Thu, Mar 1, 2018 at 9:04 AM, Taylor Brandstetter wrote: > I don=E2=80=99t think you need to wait until all candidates for one strea= m have >> been trickled until you trickle the candidates for another stream. >> > > What makes "streams" different than "components" in this regard? Both > determine what pair is unfrozen first. You can take the example above and > replace "RTP" with "stream 1" and "RTCP" with "stream 2" and it still > applies. > > It doesn't say you need to wait for *all* candidates for one stream > before trickling *any* candidate for another stream, though. This is only > talking about candidates "within the same foundation". It would be fine t= o > legal them in the order "stream 1 host", "stream 2 host", "stream 1 srflx= ", > "stream 2 srflx". > > On Thu, Mar 1, 2018 at 6:01 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> Ok, I get it why components need to be trickled in order. >> >> But, the text also talks about =E2=80=9Cstreams=E2=80=9D. I don=E2=80=99= t think you need to wait >> until all candidates for one stream have been trickled until you trickle >> the candidates for another stream. >> >> Also, the SDP example seem to assume that the order of SDP candidate >> attributes matter. But, in SDP the order does not matter, and >> intermediaries could even change the order between parsing and incoming = and >> generating an outgoing message=E2=80=A6 >> >> Regards, >> >> Christer >> >> From: Taylor Brandstetter >> Date: Wednesday 28 February 2018 at 20:34 >> To: Christer Holmberg >> Cc: "ice@ietf.org" >> Subject: Re: [Ice] Trickle: What is Section 16 about? >> >> Does it mean that, when an agent gathers a new candidate, it must not se= nd >>> it to the peer in case there will later be a candidate with a lower ID >>> within the same foundation? >>> >> >> That's how I interpret it; the example below explains how an RTCP >> candidate for a particular foundation must be conveyed after (or >> simultaneously with) the RTP candidate. >> >> As for "why", I think that's explained by the paragraph above: >> >> One important aspect of regular ICE is that connectivity checks for a >>> specific foundation and component are attempted simultaneously by >>> both agents, so that any firewalls or NATs fronting the agents would >>> whitelist both endpoints and allow all except for the first >>> ("suicide") packets to go through. This is also important to >>> unfreezing candidates at the right time. While not crucial, >>> preserving this behavior in Trickle ICE is likely to improve ICE >>> performance. >>> >>> >> Trickling candidates in a specific order helps guarantee that pairs are >> formed in the same order by both peers, so that they'll perform >> connectivity checks for the same pairs simultaneously. >> >> Though given the updates to section 8.1.1 (Inserting a New Pair in a >> Check List), this may not be as important as it used to be. The rules in >> 8.1.1 guarantee that the "topmost" pair for each foundation will always = be >> unfrozen. So I believe if candidates were trickled out of order, the wor= st >> that could happen is that one peer ends up with more pairs unfrozen than >> the other. For example: >> >> 1. Bob trickles RTCP candidate, then RTP. >> 2. Alice trickles RTP candidate, then RTCP. >> 3. Alice receives Bob's candidates, forming RTCP pair first (unfreezing >> it), then RTP pair (unfreezing it too, since it becomes the new "topmost= " >> pair). >> 4. Bob receives Alice's candidates, forming RTP pair first (unfreezing >> it), then RTCP pair (leaving it frozen). >> 5. Alice now has both pairs unfrozen, while Bob only has the RTP pair >> unfrozen. >> >> On Tue, Feb 27, 2018 at 11:13 PM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Hi, >>> >>> Section 16 says the following: >>> >>> "To achieve this, when trickling candidates, agents MUST respect the >>> order in which the components and streams appear (implicitly or >>> explicitly) as they have been negotiated by means of the relevant >>> candidate information.=C2=B2 >>> >>> I can=C2=B9t parse this sentence. What =C2=B3order=C2=B2 is the text ta= lking about? >>> >>> "Therefore candidates for a given component MUST NOT be conveyed pri= or >>> to >>> candidates for a component with a lower ID number within the same >>> foundation.=C2=B2 >>> >>> Does it mean that, when an agent gathers a new candidate, it must not >>> send >>> it to the peer in case there will later be a candidate with a lower ID >>> within the same foundation? I thought the whole idea of trickle was to >>> provide candidates to the peer in =C2=B3real-time=C2=B2, once they beco= me >>> available. >>> >>> If the order in which candidates are placed in SDP matters, that should >>> be >>> described in trickle-ice-sdp. >>> >>> My suggestion would be to remove Section 16 completely, but I would lik= e >>> someone to tell me why we need it, and what exactly it is trying to say >>> :) >>> >>> Regards, >>> >>> Christer >>> >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >> >> > --001a114e50b06a3b6005665cde8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Meant to say "fine to=C2=A0trickle= =C2=A0them"...)

On Thu, Mar 1, 2018 at 9:= 04 AM, Taylor Brandstetter <deadbeef@google.com> wrote:
I don=E2= =80=99t think you need to wait until all candidates for one stream have bee= n trickled until you trickle the candidates for another stream.
<= /blockquote>

What makes "streams" diffe= rent than "components" in this regard? Both determine what pair i= s unfrozen first. You can take the example above and replace "RTP"= ; with "stream 1" and "RTCP" with "stream 2" = and it still applies.

It doesn't say you n= eed to wait for all=C2=A0candidates for one stream before trickling = any=C2=A0candidate for another stream, though. This is only talking = about candidates "within the same foundation". It would be fine t= o legal them in the order "stream 1 host", "stream 2 host&qu= ot;, "stream 1 srflx", "stream 2 srflx".

On Thu, Mar 1, 2018 at 6:01 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

Ok, I get it why components need to be trickled in order.

But, the text also talks about =E2=80=9Cstreams=E2=80=9D. I don=E2=80= =99t think you need to wait until all candidates for one stream have been t= rickled until you trickle the candidates for another stream.

Also, the SDP example seem to assume that the order of SDP candidate a= ttributes matter. But, in SDP the order does not matter, and intermediaries= could even change the order between parsing and incoming and generating an= outgoing message=E2=80=A6

Regards,

Christer

From: Taylor Brandstetter <deadbeef@google.com= >
Date: Wednesday 28 February 2018 at= 20:34
To: Christer Holmberg <christer.holmb= erg@ericsson.com>
Cc: "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Trickle: What is= Section 16 about?

Does it mean that, when an agent gathers a new candidate, it must not send
it to the peer in case there will later be a candidate with a lower ID=
wi= thin the same foundation?

That's how I interpret i= t; the example below explains how an RTCP candidate for a particular founda= tion must be conveyed after (or simultaneously with) the RTP candidate.

As for "why", I th= ink that's explained by the paragraph above:

   One importan=
t aspect of regular ICE is that connectivity checks for a
   specific foundation and component are attempted simultaneously by
   both agents, so that any firewalls or NATs fronting the agents would
   whitelist both endpoints and allow all except for the first
   ("suicide") packets to go through.  This is also important to
   unfreezing candidates at the right time.  While not crucial,
   preserving this behavior in Trickle ICE is likely to improve ICE
   performance.

Trickling candidates in a specific order helps guarantee that pairs ar= e formed in the same order by both peers, so that they'll perform conne= ctivity checks for the same pairs simultaneously.

Though given the updates to section 8.1.1 (Inserting a New Pair in a C= heck List), this may not be as important as it used to be. The rules in 8.1= .1 guarantee that the "topmost" pair for each foundation will alw= ays be unfrozen. So I believe if candidates were trickled out of order, the worst that could happen is that one peer e= nds up with more pairs unfrozen than the other. For example:

1. Bob trickles RTCP candidate, then RTP.
2. Alice trickles RTP candidate, then RTCP.
3. Alice receives Bob's candidates, forming RTCP pair first (unfre= ezing it), then RTP pair (unfreezing it too, since it becomes the new "= ;topmost" pair).
4. Bob receives Alice's candidates, forming RTP pair first (unfree= zing it), then RTCP pair (leaving it frozen).
5. Alice now has both pairs unfrozen, while Bob only has the RTP pair = unfrozen.

On Tue, Feb 27, 2018 at 11:13 PM, Christer Holmb= erg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

Section 16 says the following:

=C2=A0 =C2=A0"To achieve this, when trickling candidates, agents MUST = respect the
=C2=A0 =C2=A0order in which the components and streams appear (implicitly o= r
=C2=A0 =C2=A0explicitly) as they have been negotiated by means of the relev= ant
=C2=A0 =C2=A0candidate information.=C2=B2

I can=C2=B9t parse this sentence. What =C2=B3order=C2=B2 is the text talkin= g about?

=C2=A0 =C2=A0"Therefore candidates for a given component MUST NOT be c= onveyed prior
to
=C2=A0 =C2=A0 candidates for a component with a lower ID number within the = same
foundation.=C2=B2

Does it mean that, when an agent gathers a new candidate, it must not send<= br> it to the peer in case there will later be a candidate with a lower ID
within the same foundation? I thought the whole idea of trickle was to
provide candidates to the peer in =C2=B3real-time=C2=B2, once they become a= vailable.

If the order in which candidates are placed in SDP matters, that should be<= br> described in trickle-ice-sdp.

My suggestion would be to remove Section 16 completely, but I would like someone to tell me why we need it, and what exactly it is trying to say :)<= br>
Regards,

Christer

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


--001a114e50b06a3b6005665cde8b-- From nobody Thu Mar 1 09:26:25 2018 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 4ED7312EBE2 for ; Thu, 1 Mar 2018 09:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 24koURKI8ds4 for ; Thu, 1 Mar 2018 09:26:14 -0800 (PST) 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 B9FE612EB9C for ; Thu, 1 Mar 2018 09:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519925166; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=osm7aACfu4t/8NznA1iSuM2JEjgZxSQ73QWHVqaO4VQ=; b=BfaPLUlYBbN2cYR3rTuQwJ25qX6M/tOo9ALIdy96JRPpkZHVch/JLLs5y26jeHne pXKqHQsgGnk08dZiL8ykKBwAgyXtxFdIREqB81oDV0gtNhjFIgpseBwxHcWcO+yQ 3PPBQAB12Q30HgRcpIZ3hT9/YsMpTEGmdoteZ2Jyyto=; X-AuditID: c1b4fb25-083ff70000002d5f-17-5a9837ad3bc9 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EC.2D.11615.DA7389A5; Thu, 1 Mar 2018 18:26:06 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0352.000; Thu, 1 Mar 2018 18:26:05 +0100 From: Christer Holmberg To: Taylor Brandstetter CC: "ice@ietf.org" Thread-Topic: [Ice] Trickle: What is Section 16 about? Thread-Index: AQHTsGOwLjmDpDpE6ESJTIumIw+YtaO6E/aAgAFrNYCAAA3hgIAAAHKAgAAUBGA= Date: Thu, 1 Mar 2018 17:26:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1B8FEE@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.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7t+468xlRBrdOs1hcXvGQ1eLbhVoH Jo8Fm0o9liz5yRTAFMVlk5Kak1mWWqRvl8CV8Xn9FZaCDQ4Vq37bNzDeseti5OSQEDCRuLr/ MmsXIxeHkMBhRont8zcygySEBBYxStzeE9nFyMHBJmAh0f1PGyQsIqArcfPrQjaQMLOAosTL vWogYWEBU4nmxkNMECVmEife7mUCKRER8JPYtUQZxGQRUJG4dQBsNq+Ar8SGbTfZIJYeYpK4 fukAO0iCUyBQ4uWfR2BjGAXEJL6fWgNmMwuIS9x6Mp8J4mIBiSV7zjND2KISLx//Y4WwlSSW T9vCDnGZpsT6XfoQrYoSU7ofskPsFZQ4OfMJywRG0VlIps5C6JiFpGMWko4FjCyrGEWLU4uT ctONjPVSizKTi4vz8/TyUks2MQLj4uCW36o7GC+/cTzEKMDBqMTD+19rRpQQa2JZcWXuIUYJ DmYlEd7T26dFCfGmJFZWpRblxxeV5qQWH2KU5mBREuedI9weJSSQnliSmp2aWpBaBJNl4uCU amBMf3a2gTe8LHBd/paXcj1JqvVOHF63NHs8X9hf+NfekfD5g/zdkBrWDz/KLjUdZFvq8vGl 4bzrmxZvuRbLOPMGY73NvS1Xk3w4rPnzrnAZyrQLCldLn3m0x7mOkVOR2eFd46QdLmdXcjOe /NLyheGp28WIKWZ6/d86F04+nPM9Iqns5nFJ0wVKLMUZiYZazEXFiQBqIOfLhwIAAA== Archived-At: Subject: Re: [Ice] Trickle: What is Section 16 about? 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, 01 Mar 2018 17:26:19 -0000 SGksDQoNCj4oTWVhbnQgdG8gc2F5ICJmaW5lIHRvwqB0cmlja2xlwqB0aGVtIi4uLikNCg0KSSd2 ZSBmaXhlZCB0aGUgdGV4dCBiZWxvdyA6KQ0KDQo+SSBkb27igJl0IHRoaW5rIHlvdSBuZWVkIHRv IHdhaXQgdW50aWwgYWxsIGNhbmRpZGF0ZXMgZm9yIG9uZSBzdHJlYW0gaGF2ZSBiZWVuIHRyaWNr bGVkIHVudGlsIHlvdSB0cmlja2xlIHRoZSBjYW5kaWRhdGVzIGZvciBhbm90aGVyIHN0cmVhbS4N Cj4NCj5XaGF0IG1ha2VzICJzdHJlYW1zIiBkaWZmZXJlbnQgdGhhbiAiY29tcG9uZW50cyIgaW4g dGhpcyByZWdhcmQ/IA0KPg0KPkJvdGggZGV0ZXJtaW5lIHdoYXQgcGFpciBpcyB1bmZyb3plbiBm aXJzdC4gWW91IGNhbiB0YWtlIHRoZSBleGFtcGxlIGFib3ZlIGFuZCByZXBsYWNlICJSVFAiIHdp dGggInN0cmVhbSAxIiBhbmQgIlJUQ1AiIHdpdGggInN0cmVhbSAyIiBhbmQgaXQgc3RpbGwgYXBw bGllcy4NCg0KSWYgeW91IGdldCBhIGNhbmRpZGF0ZSBmb3IgY29tcG9uZW50IDIsIHlvdSBLTk9X IHRoYXQgeW91IGF0IHNvbWUgcG9pbnQgd2lsbCBnZXQgYSBjYW5kaWRhdGUgZm9yIGNvbXBvbmVu dCAxICAob3RoZXJ3aXNlIHRoaW5ncyB3b24ndCB3b3JrKSwgc28geW91IGNhbiB3YWl0IGZvciB0 aGF0Lg0KDQpCdXQsIHlvdSBkb24ndCBrbm93IGhvdyBtYW55IGNhbmRpZGF0ZXMgeW91IGFyZSBn b2luZyB0byBnZXQgZm9yIGVhY2ggc3RyZWFtLCBzbyBJIGRvbid0IHNlZSBob3cgeW91IHdvdWxk IGRldGVybWluZSB3aGV0aGVyIHRvIHRyaWNrbGUgYSBjYW5kaWRhdGUgb3Igbm90IGJhc2VkIG9u IHdoYXQgaXMgaGFwcGVuaW5nIG9uIG90aGVyIHN0cmVhbXMuIEFsc28sIHRoZSB0ZXh0IGRvZXNu J3Qgc2F5IGhvdy93aGVuIHlvdSBhcmUgc3VwcG9zZWQgdG8gd2FpdCB3aGVuIGl0IGNvbWVzIHRv IHN0cmVhbXMuDQoNCj5JdCBkb2Vzbid0IHNheSB5b3UgbmVlZCB0byB3YWl0IGZvciBhbGzCoGNh bmRpZGF0ZXMgZm9yIG9uZSBzdHJlYW0gYmVmb3JlIHRyaWNrbGluZyBhbnnCoGNhbmRpZGF0ZSBm b3IgYW5vdGhlciBzdHJlYW0sIHRob3VnaC4gVGhpcyBpcyBvbmx5IHRhbGtpbmcgYWJvdXQgY2Fu ZGlkYXRlcyAid2l0aGluIHRoZSA+c2FtZSBmb3VuZGF0aW9uIi4gSXQgd291bGQgYmUgZmluZSB0 byB0cmlja2xlIHRoZW0gaW4gdGhlIG9yZGVyICJzdHJlYW0gMSBob3N0IiwgInN0cmVhbSAyIGhv c3QiLCAic3RyZWFtIDEgc3JmbHgiLCAic3RyZWFtIDIgc3JmbHgiLg0KDQpBc3N1bWUgdGhlIGFn ZW50IGdldHMgInN0cmVhbSAxIGhvc3QiLCAic3RyZWFtIDIgaG9zdCIgYW5kICJzdHJlYW0gMiBz cmZseCIuIFNob3VsZCBpdCB3YWl0IGZvciAic3RyZWFtIDEgc3JmbHgiIGJlZm9yZSB0cmlja2xp bmcgInN0cmVhbSAyIHNyZmx4Ij8gSG93IGRvZXMgdGhlIGFnZW50IGV2ZW4ga25vdyB0aGF0IGl0 IHdpbGwgZ2V0ICJzdHJlYW0gMSBzcmZseCI/DQoNCk15IHBvaW50IGlzIHRoYXQgaXMgaWYgeW91 IGhhdmUgdGhlIGZvbGxvd2luZyB0ZXh0Og0KDQogICAiYWNoaWV2ZSB0aGlzLCB3aGVuIHRyaWNr bGluZyBjYW5kaWRhdGVzLCBhZ2VudHMgTVVTVCByZXNwZWN0IHRoZQ0KICAgb3JkZXIgaW4gd2hp Y2ggdGhlIGNvbXBvbmVudHMgYW5kIHN0cmVhbXMgYXBwZWFyIChpbXBsaWNpdGx5IG9yDQogICBl eHBsaWNpdGx5KSBhcyB0aGV5IGhhdmUgYmVlbiBuZWdvdGlhdGVkIGJ5IG1lYW5zIG9mIHRoZSBy ZWxldmFudA0KICAgY2FuZGlkYXRlIGluZm9ybWF0aW9uLiINCg0KLi4ueW91IHNob3VsZCBleHBs YWluIGhvdyBpdCBpbXBhY3RzIHN0cmVhbXMuIEN1cnJlbnRseSB0aGUgdGV4dCBvbmx5IHRhbGtz IGFib3V0IGNvbXBvbmVudHMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpPbiBUaHUs IE1hciAxLCAyMDE4IGF0IDY6MDEgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KSGksDQoNCk9rLCBJIGdldCBpdCB3aHkgY29tcG9u ZW50cyBuZWVkIHRvIGJlIHRyaWNrbGVkIGluIG9yZGVyLg0KDQpCdXQsIHRoZSB0ZXh0IGFsc28g dGFsa3MgYWJvdXQg4oCcc3RyZWFtc+KAnS4gSSBkb27igJl0IHRoaW5rIHlvdSBuZWVkIHRvIHdh aXQgdW50aWwgYWxsIGNhbmRpZGF0ZXMgZm9yIG9uZSBzdHJlYW0gaGF2ZSBiZWVuIHRyaWNrbGVk IHVudGlsIHlvdSB0cmlja2xlIHRoZSBjYW5kaWRhdGVzIGZvciBhbm90aGVyIHN0cmVhbS4NCg0K QWxzbywgdGhlIFNEUCBleGFtcGxlIHNlZW0gdG8gYXNzdW1lIHRoYXQgdGhlIG9yZGVyIG9mIFNE UCBjYW5kaWRhdGUgYXR0cmlidXRlcyBtYXR0ZXIuIEJ1dCwgaW4gU0RQIHRoZSBvcmRlciBkb2Vz IG5vdCBtYXR0ZXIsIGFuZCBpbnRlcm1lZGlhcmllcyBjb3VsZCBldmVuIGNoYW5nZSB0aGUgb3Jk ZXIgYmV0d2VlbiBwYXJzaW5nIGFuZCBpbmNvbWluZyBhbmQgZ2VuZXJhdGluZyBhbiBvdXRnb2lu ZyBtZXNzYWdl4oCmDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IFRheWxvciBCcmFu ZHN0ZXR0ZXIgPGRlYWRiZWVmQGdvb2dsZS5jb20+DQpEYXRlOiBXZWRuZXNkYXkgMjggRmVicnVh cnkgMjAxOCBhdCAyMDozNA0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+DQpDYzogImljZUBpZXRmLm9yZyIgPGljZUBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbSWNlXSBUcmlja2xlOiBXaGF0IGlzIFNlY3Rpb24gMTYgYWJvdXQ/DQoNCkRvZXMg aXQgbWVhbiB0aGF0LCB3aGVuIGFuIGFnZW50IGdhdGhlcnMgYSBuZXcgY2FuZGlkYXRlLCBpdCBt dXN0IG5vdCBzZW5kDQppdCB0byB0aGUgcGVlciBpbiBjYXNlIHRoZXJlIHdpbGwgbGF0ZXIgYmUg YSBjYW5kaWRhdGUgd2l0aCBhIGxvd2VyIElEDQp3aXRoaW4gdGhlIHNhbWUgZm91bmRhdGlvbj8N Cg0KVGhhdCdzIGhvdyBJIGludGVycHJldCBpdDsgdGhlIGV4YW1wbGUgYmVsb3cgZXhwbGFpbnMg aG93IGFuIFJUQ1AgY2FuZGlkYXRlIGZvciBhIHBhcnRpY3VsYXIgZm91bmRhdGlvbiBtdXN0IGJl IGNvbnZleWVkIGFmdGVyIChvciBzaW11bHRhbmVvdXNseSB3aXRoKSB0aGUgUlRQIGNhbmRpZGF0 ZS4NCg0KQXMgZm9yICJ3aHkiLCBJIHRoaW5rIHRoYXQncyBleHBsYWluZWQgYnkgdGhlIHBhcmFn cmFwaCBhYm92ZToNCg0KICAgT25lIGltcG9ydGFudCBhc3BlY3Qgb2YgcmVndWxhciBJQ0UgaXMg dGhhdCBjb25uZWN0aXZpdHkgY2hlY2tzIGZvciBhDQogICBzcGVjaWZpYyBmb3VuZGF0aW9uIGFu ZCBjb21wb25lbnQgYXJlIGF0dGVtcHRlZCBzaW11bHRhbmVvdXNseSBieQ0KICAgYm90aCBhZ2Vu dHMsIHNvIHRoYXQgYW55IGZpcmV3YWxscyBvciBOQVRzIGZyb250aW5nIHRoZSBhZ2VudHMgd291 bGQNCiAgIHdoaXRlbGlzdCBib3RoIGVuZHBvaW50cyBhbmQgYWxsb3cgYWxsIGV4Y2VwdCBmb3Ig dGhlIGZpcnN0DQogICAoInN1aWNpZGUiKSBwYWNrZXRzIHRvIGdvIHRocm91Z2guICBUaGlzIGlz IGFsc28gaW1wb3J0YW50IHRvDQogICB1bmZyZWV6aW5nIGNhbmRpZGF0ZXMgYXQgdGhlIHJpZ2h0 IHRpbWUuICBXaGlsZSBub3QgY3J1Y2lhbCwNCiAgIHByZXNlcnZpbmcgdGhpcyBiZWhhdmlvciBp biBUcmlja2xlIElDRSBpcyBsaWtlbHkgdG8gaW1wcm92ZSBJQ0UNCiAgIHBlcmZvcm1hbmNlLg0K DQpUcmlja2xpbmcgY2FuZGlkYXRlcyBpbiBhIHNwZWNpZmljIG9yZGVyIGhlbHBzIGd1YXJhbnRl ZSB0aGF0IHBhaXJzIGFyZSBmb3JtZWQgaW4gdGhlIHNhbWUgb3JkZXIgYnkgYm90aCBwZWVycywg c28gdGhhdCB0aGV5J2xsIHBlcmZvcm0gY29ubmVjdGl2aXR5IGNoZWNrcyBmb3IgdGhlIHNhbWUg cGFpcnMgc2ltdWx0YW5lb3VzbHkuDQoNClRob3VnaCBnaXZlbiB0aGUgdXBkYXRlcyB0byBzZWN0 aW9uIDguMS4xIChJbnNlcnRpbmcgYSBOZXcgUGFpciBpbiBhIENoZWNrIExpc3QpLCB0aGlzIG1h eSBub3QgYmUgYXMgaW1wb3J0YW50IGFzIGl0IHVzZWQgdG8gYmUuIFRoZSBydWxlcyBpbiA4LjEu MSBndWFyYW50ZWUgdGhhdCB0aGUgInRvcG1vc3QiIHBhaXIgZm9yIGVhY2ggZm91bmRhdGlvbiB3 aWxsIGFsd2F5cyBiZSB1bmZyb3plbi4gU28gSSBiZWxpZXZlIGlmIGNhbmRpZGF0ZXMgd2VyZSB0 cmlja2xlZCBvdXQgb2Ygb3JkZXIsIHRoZSB3b3JzdCB0aGF0IGNvdWxkIGhhcHBlbiBpcyB0aGF0 IG9uZSBwZWVyIGVuZHMgdXAgd2l0aCBtb3JlIHBhaXJzIHVuZnJvemVuIHRoYW4gdGhlIG90aGVy LiBGb3IgZXhhbXBsZToNCg0KMS4gQm9iIHRyaWNrbGVzIFJUQ1AgY2FuZGlkYXRlLCB0aGVuIFJU UC4NCjIuIEFsaWNlIHRyaWNrbGVzIFJUUCBjYW5kaWRhdGUsIHRoZW4gUlRDUC4NCjMuIEFsaWNl IHJlY2VpdmVzIEJvYidzIGNhbmRpZGF0ZXMsIGZvcm1pbmcgUlRDUCBwYWlyIGZpcnN0ICh1bmZy ZWV6aW5nIGl0KSwgdGhlbiBSVFAgcGFpciAodW5mcmVlemluZyBpdCB0b28sIHNpbmNlIGl0IGJl Y29tZXMgdGhlIG5ldyAidG9wbW9zdCIgcGFpcikuDQo0LiBCb2IgcmVjZWl2ZXMgQWxpY2UncyBj YW5kaWRhdGVzLCBmb3JtaW5nIFJUUCBwYWlyIGZpcnN0ICh1bmZyZWV6aW5nIGl0KSwgdGhlbiBS VENQIHBhaXIgKGxlYXZpbmcgaXQgZnJvemVuKS4NCjUuIEFsaWNlIG5vdyBoYXMgYm90aCBwYWly cyB1bmZyb3plbiwgd2hpbGUgQm9iIG9ubHkgaGFzIHRoZSBSVFAgcGFpciB1bmZyb3plbi4NCg0K T24gVHVlLCBGZWIgMjcsIDIwMTggYXQgMTE6MTMgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KSGksDQoNClNlY3Rpb24gMTYgc2F5 cyB0aGUgZm9sbG93aW5nOg0KDQrCoCDCoCJUbyBhY2hpZXZlIHRoaXMsIHdoZW4gdHJpY2tsaW5n IGNhbmRpZGF0ZXMsIGFnZW50cyBNVVNUIHJlc3BlY3QgdGhlDQrCoCDCoG9yZGVyIGluIHdoaWNo IHRoZSBjb21wb25lbnRzIGFuZCBzdHJlYW1zIGFwcGVhciAoaW1wbGljaXRseSBvcg0KwqAgwqBl eHBsaWNpdGx5KSBhcyB0aGV5IGhhdmUgYmVlbiBuZWdvdGlhdGVkIGJ5IG1lYW5zIG9mIHRoZSBy ZWxldmFudA0KwqAgwqBjYW5kaWRhdGUgaW5mb3JtYXRpb24uwrINCg0KSSBjYW7CuXQgcGFyc2Ug dGhpcyBzZW50ZW5jZS4gV2hhdCDCs29yZGVywrIgaXMgdGhlIHRleHQgdGFsa2luZyBhYm91dD8N Cg0KwqAgwqAiVGhlcmVmb3JlIGNhbmRpZGF0ZXMgZm9yIGEgZ2l2ZW4gY29tcG9uZW50IE1VU1Qg Tk9UIGJlIGNvbnZleWVkIHByaW9yDQp0bw0KwqAgwqAgY2FuZGlkYXRlcyBmb3IgYSBjb21wb25l bnQgd2l0aCBhIGxvd2VyIElEIG51bWJlciB3aXRoaW4gdGhlIHNhbWUNCmZvdW5kYXRpb24uwrIN Cg0KRG9lcyBpdCBtZWFuIHRoYXQsIHdoZW4gYW4gYWdlbnQgZ2F0aGVycyBhIG5ldyBjYW5kaWRh dGUsIGl0IG11c3Qgbm90IHNlbmQNCml0IHRvIHRoZSBwZWVyIGluIGNhc2UgdGhlcmUgd2lsbCBs YXRlciBiZSBhIGNhbmRpZGF0ZSB3aXRoIGEgbG93ZXIgSUQNCndpdGhpbiB0aGUgc2FtZSBmb3Vu ZGF0aW9uPyBJIHRob3VnaHQgdGhlIHdob2xlIGlkZWEgb2YgdHJpY2tsZSB3YXMgdG8NCnByb3Zp ZGUgY2FuZGlkYXRlcyB0byB0aGUgcGVlciBpbiDCs3JlYWwtdGltZcKyLCBvbmNlIHRoZXkgYmVj b21lIGF2YWlsYWJsZS4NCg0KSWYgdGhlIG9yZGVyIGluIHdoaWNoIGNhbmRpZGF0ZXMgYXJlIHBs YWNlZCBpbiBTRFAgbWF0dGVycywgdGhhdCBzaG91bGQgYmUNCmRlc2NyaWJlZCBpbiB0cmlja2xl LWljZS1zZHAuDQoNCk15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gcmVtb3ZlIFNlY3Rpb24gMTYg Y29tcGxldGVseSwgYnV0IEkgd291bGQgbGlrZQ0Kc29tZW9uZSB0byB0ZWxsIG1lIHdoeSB3ZSBu ZWVkIGl0LCBhbmQgd2hhdCBleGFjdGx5IGl0IGlzIHRyeWluZyB0byBzYXkgOikNCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkljZSBtYWlsaW5nIGxpc3QNCkljZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCg0KDQoNCg== From nobody Thu Mar 1 10:52:27 2018 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 1DC9912EC8F for ; Thu, 1 Mar 2018 10:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dszq5BXGvi2q for ; Thu, 1 Mar 2018 10:52:22 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 93E7A12EC8A for ; Thu, 1 Mar 2018 10:52:21 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id u99so4547808uau.8 for ; Thu, 01 Mar 2018 10:52:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=326plr2mnANzh0N85c9ETB3VP9kbizNlBKZPRIfCdEc=; b=KmHFsmB5u6VL8mfRoTdh6Mhxo8Y8cXsg1t5p++VWX7XfTCr3vQYMUcp8J/q6/TW78m Y7sxlKuQaXeQfVG3uwS1aNqq/1MFJO9xgDym70BUWEanamsTcfenwstTL2ZL4/bodYSc cFnkf6ppb0oCRQSL88FXSEWiPZqm9LNiQcRPrVIKBFt+P7w+Jmcr0o1jV6lS1IH66vOK 7v2G+7WNCAxqdzAbsIm6bJRHHeKNnVwVxs6//oIWdPVTbsmoxVWNEgqVIvBjnV+WoMVS GpJ0lEP/nKkWT4iJMsa31fAg/AinYyhlTMd27Nrh/aly2qe5FODX0vK/ifFeIFZfuklZ ZWPQ== 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=326plr2mnANzh0N85c9ETB3VP9kbizNlBKZPRIfCdEc=; b=M0WBEjSYoN1LV1k6vEnh3KVkHG9JgLOsrVBBgyNKgrZr2mzuc4HQkuPzVMUrUkvkvk vuUE+rn8uBQp8P+7ekc+iA0vB3ovHxKA6jm9yKJKG2w+IG0sfCWr09vY99O9eqRmBFgn aqQcT9aiihdZdlPMvMO4xvrIrn6e7Rn1NRtVW4fUfrdZdmDPXE/ZUz8hae5SlGVfrgVo 5ii3KwW7t8pgbtSo6TZdvjZ0dU/vn+l1O/ll1pqLH330ukbA1WaZLKb+/GVmZ97N5YTY nIDbNWiLddHCwY1CvoDQ0RiAlShZSSGZvQcH0A+ljg5Jti5/BnDeYkpIcOUN23BuMteI apWw== X-Gm-Message-State: AElRT7GNlSLhPz9GjjcTUGHomkHIi3XQB+qg5QeS2x8j2dCrhoBGiCHr T3HDFPLgfnkyS5ygc8kIyLo3tFHGlrxQiO0VDU/RMA== X-Google-Smtp-Source: AG47ELvvUvMZah0Eyn0VAgRLB330veMO/SaurcqM8Spsq3U8jsuUkJCrcN21X4yXJq5PYuJuajYHZr+Rpsj1K6/Apig= X-Received: by 10.176.6.10 with SMTP id f10mr2028059uaf.181.1519930340119; Thu, 01 Mar 2018 10:52:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.114.66 with HTTP; Thu, 1 Mar 2018 10:52:19 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1B8FEE@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C1B8FEE@ESESSMB109.ericsson.se> From: Taylor Brandstetter Date: Thu, 1 Mar 2018 10:52:19 -0800 Message-ID: To: Christer Holmberg Cc: "ice@ietf.org" , Peter Saint-Andre Content-Type: multipart/alternative; boundary="94eb2c122e6c025b4405665e5cc3" Archived-At: Subject: Re: [Ice] Trickle: What is Section 16 about? 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, 01 Mar 2018 18:52:25 -0000 --94eb2c122e6c025b4405665e5cc3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Assume the agent gets "stream 1 host", "stream 2 host" and "stream 2 > srflx". Should it wait for "stream 1 srflx" before trickling "stream 2 > srflx"? That was my interpretation. > How does the agent even know that it will get "stream 1 srflx"? If one candidate of a particular foundation was gathered successfully, the agent can expect the rest of the candidates with that foundation to be gathered successfully as well. Again, I don't see the difference between streams and components here. You could ask the same question of components: "How does the agent know it will get 'RTP srflx' if it gets 'RTCP srflx'?" My point is that is if you have the following text: > > "achieve this, when trickling candidates, agents MUST respect the > order in which the components and streams appear (implicitly or > explicitly) as they have been negotiated by means of the relevant > candidate information." > > ...you should explain how it impacts streams. Currently the text only > talks about components. > Ah, so is the issue that the next sentence only mentions components? > Therefore candidates for a given component > MUST NOT be conveyed prior to candidates for a component with a lower > ID number within the same foundation. Streams are mentioned further below: Similar considerations apply at the level of media streams in > addition to foundations; this is covered by the requirement to always > > start unfreezing candidates starting from the first media stream as > > described under Section 5.2 . > > But this appears out of date. Section 5.2 used to say: If [the first] > checklist is still empty however, agents will hold off further > processing until this is no longer the case. .... Which ensures the first stream is always unfrozen first. But now it says: If that first component of the first media stream does > not contain candidates for one or more of the currently known pair > foundations, and if candidate pairs already exist for that foundation > in one of the following components or media streams, then the agent > unfreezes the first of those candidate pairs. Meaning section 5.2 no longer enforces the stream ordering requirement. So, I'd suggest: - Removing the outdated "Similar considerations apply..." paragraph. - Updating the rest of Section 16 to make it clear that candidates should be trickled in both stream and component order. On Thu, Mar 1, 2018 at 9:26 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >(Meant to say "fine to trickle them"...) > > I've fixed the text below :) > > >I don=E2=80=99t think you need to wait until all candidates for one stre= am have > been trickled until you trickle the candidates for another stream. > > > >What makes "streams" different than "components" in this regard? > > > >Both determine what pair is unfrozen first. You can take the example > above and replace "RTP" with "stream 1" and "RTCP" with "stream 2" and it > still applies. > > If you get a candidate for component 2, you KNOW that you at some point > will get a candidate for component 1 (otherwise things won't work), so y= ou > can wait for that. > > But, you don't know how many candidates you are going to get for each > stream, so I don't see how you would determine whether to trickle a > candidate or not based on what is happening on other streams. Also, the > text doesn't say how/when you are supposed to wait when it comes to strea= ms. > > >It doesn't say you need to wait for all candidates for one stream before > trickling any candidate for another stream, though. This is only talking > about candidates "within the >same foundation". It would be fine to trick= le > them in the order "stream 1 host", "stream 2 host", "stream 1 srflx", > "stream 2 srflx". > > Assume the agent gets "stream 1 host", "stream 2 host" and "stream 2 > srflx". Should it wait for "stream 1 srflx" before trickling "stream 2 > srflx"? How does the agent even know that it will get "stream 1 srflx"? > > My point is that is if you have the following text: > > "achieve this, when trickling candidates, agents MUST respect the > order in which the components and streams appear (implicitly or > explicitly) as they have been negotiated by means of the relevant > candidate information." > > ...you should explain how it impacts streams. Currently the text only > talks about components. > > Regards, > > Christer > > > > On Thu, Mar 1, 2018 at 6:01 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > Hi, > > Ok, I get it why components need to be trickled in order. > > But, the text also talks about =E2=80=9Cstreams=E2=80=9D. I don=E2=80=99t= think you need to wait > until all candidates for one stream have been trickled until you trickle > the candidates for another stream. > > Also, the SDP example seem to assume that the order of SDP candidate > attributes matter. But, in SDP the order does not matter, and > intermediaries could even change the order between parsing and incoming a= nd > generating an outgoing message=E2=80=A6 > > Regards, > > Christer > > From: Taylor Brandstetter > Date: Wednesday 28 February 2018 at 20:34 > To: Christer Holmberg > Cc: "ice@ietf.org" > Subject: Re: [Ice] Trickle: What is Section 16 about? > > Does it mean that, when an agent gathers a new candidate, it must not sen= d > it to the peer in case there will later be a candidate with a lower ID > within the same foundation? > > That's how I interpret it; the example below explains how an RTCP > candidate for a particular foundation must be conveyed after (or > simultaneously with) the RTP candidate. > > As for "why", I think that's explained by the paragraph above: > > One important aspect of regular ICE is that connectivity checks for a > specific foundation and component are attempted simultaneously by > both agents, so that any firewalls or NATs fronting the agents would > whitelist both endpoints and allow all except for the first > ("suicide") packets to go through. This is also important to > unfreezing candidates at the right time. While not crucial, > preserving this behavior in Trickle ICE is likely to improve ICE > performance. > > Trickling candidates in a specific order helps guarantee that pairs are > formed in the same order by both peers, so that they'll perform > connectivity checks for the same pairs simultaneously. > > Though given the updates to section 8.1.1 (Inserting a New Pair in a Chec= k > List), this may not be as important as it used to be. The rules in 8.1.1 > guarantee that the "topmost" pair for each foundation will always be > unfrozen. So I believe if candidates were trickled out of order, the wors= t > that could happen is that one peer ends up with more pairs unfrozen than > the other. For example: > > 1. Bob trickles RTCP candidate, then RTP. > 2. Alice trickles RTP candidate, then RTCP. > 3. Alice receives Bob's candidates, forming RTCP pair first (unfreezing > it), then RTP pair (unfreezing it too, since it becomes the new "topmost" > pair). > 4. Bob receives Alice's candidates, forming RTP pair first (unfreezing > it), then RTCP pair (leaving it frozen). > 5. Alice now has both pairs unfrozen, while Bob only has the RTP pair > unfrozen. > > On Tue, Feb 27, 2018 at 11:13 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > Hi, > > Section 16 says the following: > > "To achieve this, when trickling candidates, agents MUST respect the > order in which the components and streams appear (implicitly or > explicitly) as they have been negotiated by means of the relevant > candidate information.=C2=B2 > > I can=C2=B9t parse this sentence. What =C2=B3order=C2=B2 is the text talk= ing about? > > "Therefore candidates for a given component MUST NOT be conveyed prior > to > candidates for a component with a lower ID number within the same > foundation.=C2=B2 > > Does it mean that, when an agent gathers a new candidate, it must not sen= d > it to the peer in case there will later be a candidate with a lower ID > within the same foundation? I thought the whole idea of trickle was to > provide candidates to the peer in =C2=B3real-time=C2=B2, once they become= available. > > If the order in which candidates are placed in SDP matters, that should b= e > described in trickle-ice-sdp. > > My suggestion would be to remove Section 16 completely, but I would like > someone to tell me why we need it, and what exactly it is trying to say := ) > > Regards, > > Christer > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > > > --94eb2c122e6c025b4405665e5cc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Assume the agent gets "stream 1 host", "s= tream 2 host" and "stream 2 srflx". Should it wait for "= ;stream 1 srflx" before trickling "stream 2 srflx"?

That was my interpretation.
=C2=A0=
How does the agent even know that it will get "stream 1 srflx&= quot;?

If one candidate of a particu= lar foundation was gathered successfully, the agent can expect the rest of = the candidates with that foundation to be gathered successfully as well.

Again, I don't see the difference between stream= s and components here. You could ask the same question of components: "= ;How does the agent know it will get 'RTP srflx' if it gets 'RT= CP srflx'?"

My point is that is if you have = the following text:

=C2=A0 =C2=A0"achieve = this, when trickling candidates, agents MUST respect the
=C2=A0 =C2=A0or= der in which the components and streams appear (implicitly or
=C2=A0 =C2= =A0explicitly) as they have been negotiated by means of the relevant
=C2= =A0 =C2=A0candidate information."

...you should explain how it impacts streams. Currently the text only = talks about components.

Ah, so i= s the issue that the next sentence only mentions components?
=C2= =A0
=C2=A0 =C2=A0The= refore candidates for a given component
=C2=A0 =C2=A0MUST NOT be conveyed prior to candidates for a com= ponent with a lower
=C2=A0 =C2=A0ID number within the same foundation.

Streams are menti= oned further below:

   Simil=
ar considerations apply at the level of media streams in
   addition to foundations; this is covered by the requirement to always=C2=
=A0
   start unfreezing candidates sta=
rting from the first media stream as

   described under Section 5.2.

But th= is appears out of date. Section 5.2 used to say:

If [the first]
checklist is still empty h= owever, agents will hold off further
 processing until this is no longer the case.
.... Which ensures th= e first stream is always unfrozen first. But now it says:
=
=C2=A0 =C2=A0If that first component of the first media stream d= oes
=C2=A0 =C2=A0not contain candidates for one or more of the currently= known pair
=C2=A0 =C2=A0foundations, and if candidate pairs already exi= st for that foundation
=C2=A0 =C2=A0in one of the following components o= r media streams, then the agent
=C2=A0 =C2=A0unfreezes the first of thos= e candidate pairs.

Meaning section 5.2 no l= onger enforces the stream ordering requirement.

So= , I'd suggest:
  • Removing the outdated "Similar co= nsiderations apply..." paragraph.
  • Updating the rest of Section= 16 to make it clear that candidates should be trickled in both stream and = component order.

On Thu, Mar 1, 2018 at 9:26 AM, Christer = Holmberg <christer.holmberg@ericsson.com> wrote= :
Hi,

>(Meant to say "fine to=C2=A0trickle=C2=A0them"...)

I've fixed the text below :)

>I don=E2=80=99t think you need to wait until all candidates for one str= eam have been trickled until you trickle the candidates for another stream.=
>
>What makes "streams" different than "components" in= this regard?
>
>Both determine what pair is unfrozen first. You can take the example ab= ove and replace "RTP" with "stream 1" and "RTCP&qu= ot; with "stream 2" and it still applies.

If you get a candidate for component 2, you KNOW that you at some po= int will get a candidate for component 1=C2=A0 (otherwise things won't = work), so you can wait for that.

But, you don't know how many candidates you are going to get for each s= tream, so I don't see how you would determine whether to trickle a cand= idate or not based on what is happening on other streams. Also, the text do= esn't say how/when you are supposed to wait when it comes to streams.
>It doesn't say you need to wait for all=C2=A0candidates for one str= eam before trickling any=C2=A0candidate for another stream, though. This is= only talking about candidates "within the >same foundation". = It would be fine to trickle them in the order "stream 1 host", &q= uot;stream 2 host", "stream 1 srflx", "stream 2 srflx&q= uot;.

Assume the agent gets "stream 1 host", "stream 2 host" = and "stream 2 srflx". Should it wait for "stream 1 srflx&quo= t; before trickling "stream 2 srflx"? How does the agent even kno= w that it will get "stream 1 srflx"?

My point is that is if you have the following text:

=C2=A0 =C2=A0"achieve this, when trickling candidates, agents MUST res= pect the
=C2=A0 =C2=A0order in which the components and streams appear (implicitly o= r
=C2=A0 =C2=A0explicitly) as they have been negotiated by means of the relev= ant
=C2=A0 =C2=A0candidate information."

...you should explain how it impacts streams. Currently the text onl= y talks about components.

Regards,

Christer



On Thu, Mar 1, 2018 at 6:01 AM, Christer Holmberg <christer.holmberg@ericsson.com> wr= ote:
Hi,

Ok, I get it why components need to be trickled in order.

But, the text also talks about =E2=80=9Cstreams=E2=80=9D. I don=E2=80=99t t= hink you need to wait until all candidates for one stream have been trickle= d until you trickle the candidates for another stream.

Also, the SDP example seem to assume that the order of SDP candidate attrib= utes matter. But, in SDP the order does not matter, and intermediaries coul= d even change the order between parsing and incoming and generating an outg= oing message=E2=80=A6

Regards,

Christer

From: Taylor Brandstetter <deadbe= ef@google.com>
Date: Wednesday 28 February 2018 at 20:34
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Trickle: What is Section 16 about?

Does it mean that, when an agent gathers a new candidate, it must not send<= br> it to the peer in case there will later be a candidate with a lower ID
within the same foundation?

That's how I interpret it; the example below explains how an RTCP candi= date for a particular foundation must be conveyed after (or simultaneously = with) the RTP candidate.

As for "why", I think that's explained by the paragraph above= :

=C2=A0 =C2=A0One important aspect of regular ICE is that connectivity check= s for a
=C2=A0 =C2=A0specific foundation and component are attempted simultaneously= by
=C2=A0 =C2=A0both agents, so that any firewalls or NATs fronting the agents= would
=C2=A0 =C2=A0whitelist both endpoints and allow all except for the first =C2=A0 =C2=A0("suicide") packets to go through.=C2=A0 This is als= o important to
=C2=A0 =C2=A0unfreezing candidates at the right time.=C2=A0 While not cruci= al,
=C2=A0 =C2=A0preserving this behavior in Trickle ICE is likely to improve I= CE
=C2=A0 =C2=A0performance.

Trickling candidates in a specific order helps guarantee that pairs are for= med in the same order by both peers, so that they'll perform connectivi= ty checks for the same pairs simultaneously.

Though given the updates to section 8.1.1 (Inserting a New Pair in a Check = List), this may not be as important as it used to be. The rules in 8.1.1 gu= arantee that the "topmost" pair for each foundation will always b= e unfrozen. So I believe if candidates were trickled out of order, the wors= t that could happen is that one peer ends up with more pairs unfrozen than = the other. For example:

1. Bob trickles RTCP candidate, then RTP.
2. Alice trickles RTP candidate, then RTCP.
3. Alice receives Bob's candidates, forming RTCP pair first (unfreezing= it), then RTP pair (unfreezing it too, since it becomes the new "topm= ost" pair).
4. Bob receives Alice's candidates, forming RTP pair first (unfreezing = it), then RTCP pair (leaving it frozen).
5. Alice now has both pairs unfrozen, while Bob only has the RTP pair unfro= zen.

On Tue, Feb 27, 2018 at 11:13 PM, Christer Holmberg <christer.holmberg@ericsson.com> = wrote:
Hi,

Section 16 says the following:

=C2=A0 =C2=A0"To achieve this, when trickling candidates, agents MUST = respect the
=C2=A0 =C2=A0order in which the components and streams appear (implicitly o= r
=C2=A0 =C2=A0explicitly) as they have been negotiated by means of the relev= ant
=C2=A0 =C2=A0candidate information.=C2=B2

I can=C2=B9t parse this sentence. What =C2=B3order=C2=B2 is the text talkin= g about?

=C2=A0 =C2=A0"Therefore candidates for a given component MUST NOT be c= onveyed prior
to
=C2=A0 =C2=A0 candidates for a component with a lower ID number within the = same
foundation.=C2=B2

Does it mean that, when an agent gathers a new candidate, it must not send<= br> it to the peer in case there will later be a candidate with a lower ID
within the same foundation? I thought the whole idea of trickle was to
provide candidates to the peer in =C2=B3real-time=C2=B2, once they become a= vailable.

If the order in which candidates are placed in SDP matters, that should be<= br> described in trickle-ice-sdp.

My suggestion would be to remove Section 16 completely, but I would like someone to tell me why we need it, and what exactly it is trying to say :)<= br>
Regards,

Christer

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




--94eb2c122e6c025b4405665e5cc3-- From nobody Thu Mar 1 11:20:03 2018 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 E8B3712F251 for ; Thu, 1 Mar 2018 11:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=ericsson.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 2xVw_SIm-MZv for ; Thu, 1 Mar 2018 11:20:00 -0800 (PST) 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 0588312EE46 for ; Thu, 1 Mar 2018 11:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519931989; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KxBX2OVxZXc1ubARooGkrBK/SAP4eGxXjb0nfOMOung=; b=IFyr1i06B/0TppxpSO1JqxTZHlOg2qCorWVR8Wd20GJwLVVWpKtnMd5Qp44cJHQO GAkuUke5Ky87vfX2Rplka8ZXZLu8WkjBzdBDMkaomUroSJMbmHnfobl8zOHHt+kP 5WGosHKfEZYNq5lbv1W5tg0lchj1KRpWlsfthvKRI0o=; X-AuditID: c1b4fb3a-347ff700000067b4-c3-5a985255b337 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 94.36.26548.552589A5; Thu, 1 Mar 2018 20:19:49 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Thu, 1 Mar 2018 20:19:48 +0100 From: Christer Holmberg To: Taylor Brandstetter CC: "ice@ietf.org" , Peter Saint-Andre Thread-Topic: [Ice] Trickle: What is Section 16 about? Thread-Index: AQHTsGOwLjmDpDpE6ESJTIumIw+YtaO6E/aAgAFrNYCAAA3hgIAAAHKAgAAUBGCAAAnMgIAAFajw Date: Thu, 1 Mar 2018 19:19:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1B9583@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C1B8FEE@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbFdWjc0aEaUwYbvYhaXVzxktfh2odbi 2J5+ZgdmjwWbSj2WLPnJ5DF3zwvmAOYoLpuU1JzMstQifbsEroxH21eyFbxJrfj0/zxLA+Oc 5C5GTg4JAROJT6f+snYxcnEICRxmlPjzdBcLhLOIUeLxlOuMXYwcHGwCFhLd/7RBGkQEdCVu fl3IBmIzC3hKPDh7iBXEFhYwlWhuPMQEUWMmceLtXig7SmJlWxdYPYuAisSfeZ0sIDavgK/E qVVboRafZZa4uXQqWBGnQKDE/G2nwGxGATGJ76fWMEEsE5e49WQ+E8TVAhJL9pxnhrBFJV4+ /scKYStJLJ+2hR3kZmYBTYn1u/QhWhUlpnQ/ZIfYKyhxcuYTlgmMorOQTJ2F0DELSccsJB0L GFlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRGzcEtv612MB587niIUYCDUYmHt8FlRpQQ a2JZcWXuIUYJDmYlEd7T26dFCfGmJFZWpRblxxeV5qQWH2KU5mBREud1SrOIEhJITyxJzU5N LUgtgskycXBKNTAmVpvt08vdlfS4eaX3iw1smg1/wjR2xxyQvNvNdP7XSZbMuyn3zBQN+00r JL1UXqcJBtU8u+4V853/50SOjg1aXI6HRRb/2yaxfXE+++7i/l7/g8uNIxNu7e5/ubnm7u/M 77uN5uo8uBj8VGENwwRmq8fbGjUvh+h7rZriVrGJUYPxzaKgwJ9KLMUZiYZazEXFiQDxDE8O lgIAAA== Archived-At: Subject: Re: [Ice] Trickle: What is Section 16 about? 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, 01 Mar 2018 19:20:02 -0000 SGksDQoNCj4+IEFzc3VtZSB0aGUgYWdlbnQgZ2V0cyAic3RyZWFtIDEgaG9zdCIsICJzdHJlYW0g MiBob3N0IiBhbmQgInN0cmVhbSAyIHNyZmx4Ii4gU2hvdWxkIGl0IHdhaXQgZm9yICJzdHJlYW0g MSBzcmZseCIgYmVmb3JlIHRyaWNrbGluZyAic3RyZWFtIDIgc3JmbHgiPw0KPg0KPiBUaGF0IHdh cyBteSBpbnRlcnByZXRhdGlvbi4NCj7CoA0KPj4gSG93IGRvZXMgdGhlIGFnZW50IGV2ZW4ga25v dyB0aGF0IGl0IHdpbGwgZ2V0ICJzdHJlYW0gMSBzcmZseCI/DQo+DQo+IElmIG9uZSBjYW5kaWRh dGUgb2YgYSBwYXJ0aWN1bGFyIGZvdW5kYXRpb24gd2FzIGdhdGhlcmVkIHN1Y2Nlc3NmdWxseSwg dGhlIGFnZW50IGNhbiBleHBlY3QgdGhlIHJlc3Qgb2YgdGhlIA0KPiBjYW5kaWRhdGVzIHdpdGgg dGhhdCBmb3VuZGF0aW9uIHRvIGJlIGdhdGhlcmVkIHN1Y2Nlc3NmdWxseSBhcyB3ZWxsLg0KDQpJ IGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueSBydWxlIHNheWluZyB0aGF0LCBmb3IgYSBnaXZlbiBm b3VuZGF0aW9uLCB5b3Ugd2lsbCBnZXQgY2FuZGlkYXRlcyBmb3IgYWxsIHN0cmVhbXMgKHNlZSBl eGFtcGxlIGluIHNlY3Rpb24gNi4xLjIuNi4gb2YgNTI0NWJpcykuIEZvciBleGFtcGxlLCBwZXJo YXBzIHlvdSBnYXRoZXIgcmVsYXkgY2FuZGlkYXRlcyBvbmx5IGZvciB0aGUgYXVkaW8gc3RyZWFt cywgYmVjYXVzZSB5b3Ugd2FudCB0byB1c2UgYSByZWxheSBmb3IgeW91ciB2aWRlbyAoeW91IHJh dGhlciBkb24ndCB1c2UgdmlkZW8sIGlmIGl0IHdvbid0IHdvcmsgd2l0aG91dCBhIHJlbGF5KS4N Cg0KPiBBZ2FpbiwgSSBkb24ndCBzZWUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBzdHJlYW1zIGFu ZCBjb21wb25lbnRzIGhlcmUuIFlvdSBjb3VsZCBhc2sgdGhlIHNhbWUgcXVlc3Rpb24gb2YgY29t cG9uZW50czogIkhvdyANCj4gZG9lcyB0aGUgYWdlbnQga25vdyBpdCB3aWxsIGdldCAnUlRQIHNy Zmx4JyBpZiBpdCBnZXRzICdSVENQIHNyZmx4Jz8iDQoNCllvdSBkb24ndCBrbm93IC0gdW5sZXNz IHRyaWNrbGUgbWFuZGF0ZXMgaXQgKDUyNDViaXMgZG9lcyBub3QgbWFuZGF0ZSBpdCwgYXMgZmFy IGFzIEkga25vdykuDQoNCj4+TXkgcG9pbnQgaXMgdGhhdCBpcyBpZiB5b3UgaGF2ZSB0aGUgZm9s bG93aW5nIHRleHQ6DQo+Pg0KPj7CoCDCoCJhY2hpZXZlIHRoaXMsIHdoZW4gdHJpY2tsaW5nIGNh bmRpZGF0ZXMsIGFnZW50cyBNVVNUIHJlc3BlY3QgdGhlDQo+PsKgIMKgb3JkZXIgaW4gd2hpY2gg dGhlIGNvbXBvbmVudHMgYW5kIHN0cmVhbXMgYXBwZWFyIChpbXBsaWNpdGx5IG9yDQo+PsKgIMKg ZXhwbGljaXRseSkgYXMgdGhleSBoYXZlIGJlZW4gbmVnb3RpYXRlZCBieSBtZWFucyBvZiB0aGUg cmVsZXZhbnQNCj4+IMKgY2FuZGlkYXRlIGluZm9ybWF0aW9uLiINCj4+DQo+Pi4uLnlvdSBzaG91 bGQgZXhwbGFpbiBob3cgaXQgaW1wYWN0cyBzdHJlYW1zLiBDdXJyZW50bHkgdGhlIHRleHQgb25s eSB0YWxrcyBhYm91dCBjb21wb25lbnRzLg0KPg0KPiBBaCwgc28gaXMgdGhlIGlzc3VlIHRoYXQg dGhlIG5leHQgc2VudGVuY2Ugb25seSBtZW50aW9ucyBjb21wb25lbnRzPw0KwqANCkNvcnJlY3Qu DQoNCj7CoCDCoFRoZXJlZm9yZSBjYW5kaWRhdGVzIGZvciBhIGdpdmVuIGNvbXBvbmVudA0KPsKg IMKgTVVTVCBOT1QgYmUgY29udmV5ZWQgcHJpb3IgdG8gY2FuZGlkYXRlcyBmb3IgYSBjb21wb25l bnQgd2l0aCBhIGxvd2VyDQo+wqAgwqBJRCBudW1iZXIgd2l0aGluIHRoZSBzYW1lIGZvdW5kYXRp b24uDQo+DQo+IFN0cmVhbXMgYXJlIG1lbnRpb25lZCBmdXJ0aGVyIGJlbG93Og0KPg0KPiAgIFNp bWlsYXIgY29uc2lkZXJhdGlvbnMgYXBwbHkgYXQgdGhlIGxldmVsIG9mIG1lZGlhIHN0cmVhbXMg aW4NCj4gICBhZGRpdGlvbiB0byBmb3VuZGF0aW9uczsgdGhpcyBpcyBjb3ZlcmVkIGJ5IHRoZSBy ZXF1aXJlbWVudCB0byBhbHdheXPCoA0KPiAgIHN0YXJ0IHVuZnJlZXppbmcgY2FuZGlkYXRlcyBz dGFydGluZyBmcm9tIHRoZSBmaXJzdCBtZWRpYSBzdHJlYW0gYXMNCj4gICBkZXNjcmliZWQgdW5k ZXIgU2VjdGlvbiA1LjIuDQo+DQo+IEJ1dCB0aGlzIGFwcGVhcnMgb3V0IG9mIGRhdGUuIFNlY3Rp b24gNS4yIHVzZWQgdG8gc2F5Og0KPg0KPiBJZiBbdGhlIGZpcnN0XQ0KPiBjaGVja2xpc3QgaXMg c3RpbGwgZW1wdHkgaG93ZXZlciwgYWdlbnRzIHdpbGwgaG9sZCBvZmYgZnVydGhlcg0KPiBwcm9j ZXNzaW5nIHVudGlsIHRoaXMgaXMgbm8gbG9uZ2VyIHRoZSBjYXNlLg0KPg0KPiAuLi4uIFdoaWNo IGVuc3VyZXMgdGhlIGZpcnN0IHN0cmVhbSBpcyBhbHdheXMgdW5mcm96ZW4gZmlyc3QuIEJ1dCBu b3cgaXQgc2F5czoNCj4NCj7CoCDCoElmIHRoYXQgZmlyc3QgY29tcG9uZW50IG9mIHRoZSBmaXJz dCBtZWRpYSBzdHJlYW0gZG9lcw0KPsKgIMKgbm90IGNvbnRhaW4gY2FuZGlkYXRlcyBmb3Igb25l IG9yIG1vcmUgb2YgdGhlIGN1cnJlbnRseSBrbm93biBwYWlyDQo+wqAgwqBmb3VuZGF0aW9ucywg YW5kIGlmIGNhbmRpZGF0ZSBwYWlycyBhbHJlYWR5IGV4aXN0IGZvciB0aGF0IGZvdW5kYXRpb24N Cj7CoCDCoGluIG9uZSBvZiB0aGUgZm9sbG93aW5nIGNvbXBvbmVudHMgb3IgbWVkaWEgc3RyZWFt cywgdGhlbiB0aGUgYWdlbnQNCj7CoCDCoHVuZnJlZXplcyB0aGUgZmlyc3Qgb2YgdGhvc2UgY2Fu ZGlkYXRlIHBhaXJzLg0KPg0KPiBNZWFuaW5nIHNlY3Rpb24gNS4yIG5vIGxvbmdlciBlbmZvcmNl cyB0aGUgc3RyZWFtIG9yZGVyaW5nIHJlcXVpcmVtZW50Lg0KPg0KPiBTbywgSSdkIHN1Z2dlc3Q6 DQo+IOKAoiBSZW1vdmluZyB0aGUgb3V0ZGF0ZWQgIlNpbWlsYXIgY29uc2lkZXJhdGlvbnMgYXBw bHkuLi4iIHBhcmFncmFwaC4NCj4g4oCiIFVwZGF0aW5nIHRoZSByZXN0IG9mIFNlY3Rpb24gMTYg dG8gbWFrZSBpdCBjbGVhciB0aGF0IGNhbmRpZGF0ZXMgc2hvdWxkIGJlIHRyaWNrbGVkIGluIGJv dGggc3RyZWFtIGFuZCBjb21wb25lbnQgb3JkZXIuDQoNCllvdSB3b3VsZCBoYXZlIHRvIGV4cGxh aW4gd2hhdCAic3RyZWFtIG9yZGVyIiByZWFsbHkgbWVhbnMuIEJlY2F1c2UsIGl0IGRvZXMgbm90 IG1lYW4gdGhhdCB5b3UgZmlyc3QgdHJpY2tsZSBhbGwgY2FuZGlkYXRlcyBmb3Igc3RyZWFtIDEs IHRoZW4gYWxsIGNhbmRpZGF0ZXMgZm9yIHN0cmVhbSAyLCBldGMuDQoNCkFzIEkgc2FpZCBhYm92 ZSwgeW91IHNlZW0gdG8gc3VnZ2VzdCB0aGF0LCBmb3IgZWFjaCBzdHJlYW0gYW5kIGVhY2ggZm91 bmRhdGlvbiwgdGhlcmUgd2lsbCBiZSB0aGUgc2FtZSBzZXQgb2YgY2FuZGlkYXRlcy4gVGhlcmUg aXMgbm8gc3VjaCByZXF1aXJlbWVudCBhbnl3aGVyZSwgYXMgZmFyIGFzIEkga25vdy4gDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpPbiBUaHUsIE1hciAxLCAyMDE4IGF0IDk6MjYgQU0s IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3Rl Og0KSGksDQoNCj4oTWVhbnQgdG8gc2F5ICJmaW5lIHRvwqB0cmlja2xlwqB0aGVtIi4uLikNCg0K SSd2ZSBmaXhlZCB0aGUgdGV4dCBiZWxvdyA6KQ0KDQo+SSBkb27igJl0IHRoaW5rIHlvdSBuZWVk IHRvIHdhaXQgdW50aWwgYWxsIGNhbmRpZGF0ZXMgZm9yIG9uZSBzdHJlYW0gaGF2ZSBiZWVuIHRy aWNrbGVkIHVudGlsIHlvdSB0cmlja2xlIHRoZSBjYW5kaWRhdGVzIGZvciBhbm90aGVyIHN0cmVh bS4NCj4NCj5XaGF0IG1ha2VzICJzdHJlYW1zIiBkaWZmZXJlbnQgdGhhbiAiY29tcG9uZW50cyIg aW4gdGhpcyByZWdhcmQ/DQo+DQo+Qm90aCBkZXRlcm1pbmUgd2hhdCBwYWlyIGlzIHVuZnJvemVu IGZpcnN0LiBZb3UgY2FuIHRha2UgdGhlIGV4YW1wbGUgYWJvdmUgYW5kIHJlcGxhY2UgIlJUUCIg d2l0aCAic3RyZWFtIDEiIGFuZCAiUlRDUCIgd2l0aCAic3RyZWFtIDIiIGFuZCBpdCBzdGlsbCBh cHBsaWVzLg0KDQpJZiB5b3UgZ2V0IGEgY2FuZGlkYXRlIGZvciBjb21wb25lbnQgMiwgeW91IEtO T1cgdGhhdCB5b3UgYXQgc29tZSBwb2ludCB3aWxsIGdldCBhIGNhbmRpZGF0ZSBmb3IgY29tcG9u ZW50IDHCoCAob3RoZXJ3aXNlIHRoaW5ncyB3b24ndCB3b3JrKSwgc28geW91IGNhbiB3YWl0IGZv ciB0aGF0Lg0KDQpCdXQsIHlvdSBkb24ndCBrbm93IGhvdyBtYW55IGNhbmRpZGF0ZXMgeW91IGFy ZSBnb2luZyB0byBnZXQgZm9yIGVhY2ggc3RyZWFtLCBzbyBJIGRvbid0IHNlZSBob3cgeW91IHdv dWxkIGRldGVybWluZSB3aGV0aGVyIHRvIHRyaWNrbGUgYSBjYW5kaWRhdGUgb3Igbm90IGJhc2Vk IG9uIHdoYXQgaXMgaGFwcGVuaW5nIG9uIG90aGVyIHN0cmVhbXMuIEFsc28sIHRoZSB0ZXh0IGRv ZXNuJ3Qgc2F5IGhvdy93aGVuIHlvdSBhcmUgc3VwcG9zZWQgdG8gd2FpdCB3aGVuIGl0IGNvbWVz IHRvIHN0cmVhbXMuDQoNCj5JdCBkb2Vzbid0IHNheSB5b3UgbmVlZCB0byB3YWl0IGZvciBhbGzC oGNhbmRpZGF0ZXMgZm9yIG9uZSBzdHJlYW0gYmVmb3JlIHRyaWNrbGluZyBhbnnCoGNhbmRpZGF0 ZSBmb3IgYW5vdGhlciBzdHJlYW0sIHRob3VnaC4gVGhpcyBpcyBvbmx5IHRhbGtpbmcgYWJvdXQg Y2FuZGlkYXRlcyAid2l0aGluIHRoZSA+c2FtZSBmb3VuZGF0aW9uIi4gSXQgd291bGQgYmUgZmlu ZSB0byB0cmlja2xlIHRoZW0gaW4gdGhlIG9yZGVyICJzdHJlYW0gMSBob3N0IiwgInN0cmVhbSAy IGhvc3QiLCAic3RyZWFtIDEgc3JmbHgiLCAic3RyZWFtIDIgc3JmbHgiLg0KDQpBc3N1bWUgdGhl IGFnZW50IGdldHMgInN0cmVhbSAxIGhvc3QiLCAic3RyZWFtIDIgaG9zdCIgYW5kICJzdHJlYW0g MiBzcmZseCIuIFNob3VsZCBpdCB3YWl0IGZvciAic3RyZWFtIDEgc3JmbHgiIGJlZm9yZSB0cmlj a2xpbmcgInN0cmVhbSAyIHNyZmx4Ij8gSG93IGRvZXMgdGhlIGFnZW50IGV2ZW4ga25vdyB0aGF0 IGl0IHdpbGwgZ2V0ICJzdHJlYW0gMSBzcmZseCI/DQoNCk15IHBvaW50IGlzIHRoYXQgaXMgaWYg eW91IGhhdmUgdGhlIGZvbGxvd2luZyB0ZXh0Og0KDQrCoCDCoCJhY2hpZXZlIHRoaXMsIHdoZW4g dHJpY2tsaW5nIGNhbmRpZGF0ZXMsIGFnZW50cyBNVVNUIHJlc3BlY3QgdGhlDQrCoCDCoG9yZGVy IGluIHdoaWNoIHRoZSBjb21wb25lbnRzIGFuZCBzdHJlYW1zIGFwcGVhciAoaW1wbGljaXRseSBv cg0KwqAgwqBleHBsaWNpdGx5KSBhcyB0aGV5IGhhdmUgYmVlbiBuZWdvdGlhdGVkIGJ5IG1lYW5z IG9mIHRoZSByZWxldmFudA0KwqAgwqBjYW5kaWRhdGUgaW5mb3JtYXRpb24uIg0KDQouLi55b3Ug c2hvdWxkIGV4cGxhaW4gaG93IGl0IGltcGFjdHMgc3RyZWFtcy4gQ3VycmVudGx5IHRoZSB0ZXh0 IG9ubHkgdGFsa3MgYWJvdXQgY29tcG9uZW50cy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K DQoNCk9uIFRodSwgTWFyIDEsIDIwMTggYXQgNjowMSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQpIaSwNCg0KT2ssIEkgZ2V0IGl0 IHdoeSBjb21wb25lbnRzIG5lZWQgdG8gYmUgdHJpY2tsZWQgaW4gb3JkZXIuDQoNCkJ1dCwgdGhl IHRleHQgYWxzbyB0YWxrcyBhYm91dCDigJxzdHJlYW1z4oCdLiBJIGRvbuKAmXQgdGhpbmsgeW91 IG5lZWQgdG8gd2FpdCB1bnRpbCBhbGwgY2FuZGlkYXRlcyBmb3Igb25lIHN0cmVhbSBoYXZlIGJl ZW4gdHJpY2tsZWQgdW50aWwgeW91IHRyaWNrbGUgdGhlIGNhbmRpZGF0ZXMgZm9yIGFub3RoZXIg c3RyZWFtLg0KDQpBbHNvLCB0aGUgU0RQIGV4YW1wbGUgc2VlbSB0byBhc3N1bWUgdGhhdCB0aGUg b3JkZXIgb2YgU0RQIGNhbmRpZGF0ZSBhdHRyaWJ1dGVzIG1hdHRlci4gQnV0LCBpbiBTRFAgdGhl IG9yZGVyIGRvZXMgbm90IG1hdHRlciwgYW5kIGludGVybWVkaWFyaWVzIGNvdWxkIGV2ZW4gY2hh bmdlIHRoZSBvcmRlciBiZXR3ZWVuIHBhcnNpbmcgYW5kIGluY29taW5nIGFuZCBnZW5lcmF0aW5n IGFuIG91dGdvaW5nIG1lc3NhZ2XigKYNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTog VGF5bG9yIEJyYW5kc3RldHRlciA8ZGVhZGJlZWZAZ29vZ2xlLmNvbT4NCkRhdGU6IFdlZG5lc2Rh eSAyOCBGZWJydWFyeSAyMDE4IGF0IDIwOjM0DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNjOiAiaWNlQGlldGYub3JnIiA8aWNlQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtJY2VdIFRyaWNrbGU6IFdoYXQgaXMgU2VjdGlvbiAxNiBhYm91 dD8NCg0KRG9lcyBpdCBtZWFuIHRoYXQsIHdoZW4gYW4gYWdlbnQgZ2F0aGVycyBhIG5ldyBjYW5k aWRhdGUsIGl0IG11c3Qgbm90IHNlbmQNCml0IHRvIHRoZSBwZWVyIGluIGNhc2UgdGhlcmUgd2ls bCBsYXRlciBiZSBhIGNhbmRpZGF0ZSB3aXRoIGEgbG93ZXIgSUQNCndpdGhpbiB0aGUgc2FtZSBm b3VuZGF0aW9uPw0KDQpUaGF0J3MgaG93IEkgaW50ZXJwcmV0IGl0OyB0aGUgZXhhbXBsZSBiZWxv dyBleHBsYWlucyBob3cgYW4gUlRDUCBjYW5kaWRhdGUgZm9yIGEgcGFydGljdWxhciBmb3VuZGF0 aW9uIG11c3QgYmUgY29udmV5ZWQgYWZ0ZXIgKG9yIHNpbXVsdGFuZW91c2x5IHdpdGgpIHRoZSBS VFAgY2FuZGlkYXRlLg0KDQpBcyBmb3IgIndoeSIsIEkgdGhpbmsgdGhhdCdzIGV4cGxhaW5lZCBi eSB0aGUgcGFyYWdyYXBoIGFib3ZlOg0KDQrCoCDCoE9uZSBpbXBvcnRhbnQgYXNwZWN0IG9mIHJl Z3VsYXIgSUNFIGlzIHRoYXQgY29ubmVjdGl2aXR5IGNoZWNrcyBmb3IgYQ0KwqAgwqBzcGVjaWZp YyBmb3VuZGF0aW9uIGFuZCBjb21wb25lbnQgYXJlIGF0dGVtcHRlZCBzaW11bHRhbmVvdXNseSBi eQ0KwqAgwqBib3RoIGFnZW50cywgc28gdGhhdCBhbnkgZmlyZXdhbGxzIG9yIE5BVHMgZnJvbnRp bmcgdGhlIGFnZW50cyB3b3VsZA0KwqAgwqB3aGl0ZWxpc3QgYm90aCBlbmRwb2ludHMgYW5kIGFs bG93IGFsbCBleGNlcHQgZm9yIHRoZSBmaXJzdA0KwqAgwqAoInN1aWNpZGUiKSBwYWNrZXRzIHRv IGdvIHRocm91Z2guwqAgVGhpcyBpcyBhbHNvIGltcG9ydGFudCB0bw0KwqAgwqB1bmZyZWV6aW5n IGNhbmRpZGF0ZXMgYXQgdGhlIHJpZ2h0IHRpbWUuwqAgV2hpbGUgbm90IGNydWNpYWwsDQrCoCDC oHByZXNlcnZpbmcgdGhpcyBiZWhhdmlvciBpbiBUcmlja2xlIElDRSBpcyBsaWtlbHkgdG8gaW1w cm92ZSBJQ0UNCsKgIMKgcGVyZm9ybWFuY2UuDQoNClRyaWNrbGluZyBjYW5kaWRhdGVzIGluIGEg c3BlY2lmaWMgb3JkZXIgaGVscHMgZ3VhcmFudGVlIHRoYXQgcGFpcnMgYXJlIGZvcm1lZCBpbiB0 aGUgc2FtZSBvcmRlciBieSBib3RoIHBlZXJzLCBzbyB0aGF0IHRoZXknbGwgcGVyZm9ybSBjb25u ZWN0aXZpdHkgY2hlY2tzIGZvciB0aGUgc2FtZSBwYWlycyBzaW11bHRhbmVvdXNseS4NCg0KVGhv dWdoIGdpdmVuIHRoZSB1cGRhdGVzIHRvIHNlY3Rpb24gOC4xLjEgKEluc2VydGluZyBhIE5ldyBQ YWlyIGluIGEgQ2hlY2sgTGlzdCksIHRoaXMgbWF5IG5vdCBiZSBhcyBpbXBvcnRhbnQgYXMgaXQg dXNlZCB0byBiZS4gVGhlIHJ1bGVzIGluIDguMS4xIGd1YXJhbnRlZSB0aGF0IHRoZSAidG9wbW9z dCIgcGFpciBmb3IgZWFjaCBmb3VuZGF0aW9uIHdpbGwgYWx3YXlzIGJlIHVuZnJvemVuLiBTbyBJ IGJlbGlldmUgaWYgY2FuZGlkYXRlcyB3ZXJlIHRyaWNrbGVkIG91dCBvZiBvcmRlciwgdGhlIHdv cnN0IHRoYXQgY291bGQgaGFwcGVuIGlzIHRoYXQgb25lIHBlZXIgZW5kcyB1cCB3aXRoIG1vcmUg cGFpcnMgdW5mcm96ZW4gdGhhbiB0aGUgb3RoZXIuIEZvciBleGFtcGxlOg0KDQoxLiBCb2IgdHJp Y2tsZXMgUlRDUCBjYW5kaWRhdGUsIHRoZW4gUlRQLg0KMi4gQWxpY2UgdHJpY2tsZXMgUlRQIGNh bmRpZGF0ZSwgdGhlbiBSVENQLg0KMy4gQWxpY2UgcmVjZWl2ZXMgQm9iJ3MgY2FuZGlkYXRlcywg Zm9ybWluZyBSVENQIHBhaXIgZmlyc3QgKHVuZnJlZXppbmcgaXQpLCB0aGVuIFJUUCBwYWlyICh1 bmZyZWV6aW5nIGl0IHRvbywgc2luY2UgaXQgYmVjb21lcyB0aGUgbmV3ICJ0b3Btb3N0IiBwYWly KS4NCjQuIEJvYiByZWNlaXZlcyBBbGljZSdzIGNhbmRpZGF0ZXMsIGZvcm1pbmcgUlRQIHBhaXIg Zmlyc3QgKHVuZnJlZXppbmcgaXQpLCB0aGVuIFJUQ1AgcGFpciAobGVhdmluZyBpdCBmcm96ZW4p Lg0KNS4gQWxpY2Ugbm93IGhhcyBib3RoIHBhaXJzIHVuZnJvemVuLCB3aGlsZSBCb2Igb25seSBo YXMgdGhlIFJUUCBwYWlyIHVuZnJvemVuLg0KDQpPbiBUdWUsIEZlYiAyNywgMjAxOCBhdCAxMTox MyBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4g d3JvdGU6DQpIaSwNCg0KU2VjdGlvbiAxNiBzYXlzIHRoZSBmb2xsb3dpbmc6DQoNCsKgIMKgIlRv IGFjaGlldmUgdGhpcywgd2hlbiB0cmlja2xpbmcgY2FuZGlkYXRlcywgYWdlbnRzIE1VU1QgcmVz cGVjdCB0aGUNCsKgIMKgb3JkZXIgaW4gd2hpY2ggdGhlIGNvbXBvbmVudHMgYW5kIHN0cmVhbXMg YXBwZWFyIChpbXBsaWNpdGx5IG9yDQrCoCDCoGV4cGxpY2l0bHkpIGFzIHRoZXkgaGF2ZSBiZWVu IG5lZ290aWF0ZWQgYnkgbWVhbnMgb2YgdGhlIHJlbGV2YW50DQrCoCDCoGNhbmRpZGF0ZSBpbmZv cm1hdGlvbi7Csg0KDQpJIGNhbsK5dCBwYXJzZSB0aGlzIHNlbnRlbmNlLiBXaGF0IMKzb3JkZXLC siBpcyB0aGUgdGV4dCB0YWxraW5nIGFib3V0Pw0KDQrCoCDCoCJUaGVyZWZvcmUgY2FuZGlkYXRl cyBmb3IgYSBnaXZlbiBjb21wb25lbnQgTVVTVCBOT1QgYmUgY29udmV5ZWQgcHJpb3INCnRvDQrC oCDCoCBjYW5kaWRhdGVzIGZvciBhIGNvbXBvbmVudCB3aXRoIGEgbG93ZXIgSUQgbnVtYmVyIHdp dGhpbiB0aGUgc2FtZQ0KZm91bmRhdGlvbi7Csg0KDQpEb2VzIGl0IG1lYW4gdGhhdCwgd2hlbiBh biBhZ2VudCBnYXRoZXJzIGEgbmV3IGNhbmRpZGF0ZSwgaXQgbXVzdCBub3Qgc2VuZA0KaXQgdG8g dGhlIHBlZXIgaW4gY2FzZSB0aGVyZSB3aWxsIGxhdGVyIGJlIGEgY2FuZGlkYXRlIHdpdGggYSBs b3dlciBJRA0Kd2l0aGluIHRoZSBzYW1lIGZvdW5kYXRpb24/IEkgdGhvdWdodCB0aGUgd2hvbGUg aWRlYSBvZiB0cmlja2xlIHdhcyB0bw0KcHJvdmlkZSBjYW5kaWRhdGVzIHRvIHRoZSBwZWVyIGlu IMKzcmVhbC10aW1lwrIsIG9uY2UgdGhleSBiZWNvbWUgYXZhaWxhYmxlLg0KDQpJZiB0aGUgb3Jk ZXIgaW4gd2hpY2ggY2FuZGlkYXRlcyBhcmUgcGxhY2VkIGluIFNEUCBtYXR0ZXJzLCB0aGF0IHNo b3VsZCBiZQ0KZGVzY3JpYmVkIGluIHRyaWNrbGUtaWNlLXNkcC4NCg0KTXkgc3VnZ2VzdGlvbiB3 b3VsZCBiZSB0byByZW1vdmUgU2VjdGlvbiAxNiBjb21wbGV0ZWx5LCBidXQgSSB3b3VsZCBsaWtl DQpzb21lb25lIHRvIHRlbGwgbWUgd2h5IHdlIG5lZWQgaXQsIGFuZCB3aGF0IGV4YWN0bHkgaXQg aXMgdHJ5aW5nIHRvIHNheSA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWNlIG1haWxpbmcgbGlzdA0K SWNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0K DQoNCg0K From nobody Thu Mar 1 12:24:32 2018 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 971DD12FA8A; Thu, 1 Mar 2018 12:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 qE-sTUSLHqMf; Thu, 1 Mar 2018 12:24:24 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A3212FA88; Thu, 1 Mar 2018 12:24:24 -0800 (PST) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w21KOHAh083507 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 1 Mar 2018 14:24:18 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Christer Holmberg , The IESG Cc: "draft-ietf-ice-rfc5245bis@ietf.org" , Peter Thatcher , "ice-chairs@ietf.org" , "ice@ietf.org" References: <151920498287.9799.11602055137725027840.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C17B247@ESESSMB109.ericsson.se> <21c57c7c-6ba7-25d0-31a1-8cafbd42f3cd@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6C192F5D@ESESSMB109.ericsson.se> From: Adam Roach Message-ID: <2661ea85-ec00-244b-1817-78e49d3432b1@nostrum.com> Date: Thu, 1 Mar 2018 14:24:17 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C192F5D@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT) 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, 01 Mar 2018 20:24:26 -0000 On 2/24/18 5:14 AM, Christer Holmberg wrote: > >>>> The document currently appears to contain normative statements that, while not literally contradictory, certainly point implementors in conflicting directions. >>>> §5.1.1.1 says: >>>> >>>> o Host candidates corresponding to IPv6 link-local addresses MUST >>>> NOT be gathered. >>>> >>>> Further down, §6.1.2.2 says: >>>> >>>> To keep the amount of resulting candidate pairs reasonable and to >>>> avoid candidate pairs that are highly unlikely to work, IPv6 >>>> link-local addresses [RFC4291] MUST NOT be paired with other than >>>> link-local addresses. >>>> >>>> This second passage is nonsensical if IPv6 link local addresses MUST >>>> NOT be gathered. Please remove or amend one of these normative statements. If the first statement is retained, please add rationale. >>> Ben had the same comment. My suggestion was to remove the text in 6.1.2.2. >>> >>> I guess the rationale is since a local-link address may not be valid for communicating with the peer. >> Well, it is if they're on the same link. For example, when I ssh from one machine in my house to another, it generally uses an >> IPv6 link-local address. WebRTC is explicitly expected to use this optimal path if it exists. I think the fix that Ari proposes makes more sense. > I agree. I will fix as suggested by Ari. I reviewed the text in the -18 version of the document, and it doesn't seem to correctly reflect the suggestion -- or at least, it is ambiguous. What is in there now is: > o If one or more host candidates corresponding to an IPv6 address > generated using a mechanism that prevents location tracking > [RFC7721] are gathered, host candidates corresponding to IPv6 > addresses that do allow location tracking that are configured on > the same interface and are part of the same network prefix MUST > NOT be gathered; and host candidates corresponding to IPv6 link- > local addresses [RFC4291] MUST NOT be gathered. The problematic phrase still appears; it's just after a semicolon now. It seems highly likely that impelementors will read the phrase as being unqualified rather than only applying when RFC 7721 addresses are used. Perhaps:    o  If one or more host candidates corresponding to an IPv6 address       generated using a mechanism that prevents location tracking       [RFC7721] are gathered, host candidates corresponding to IPv6       addresses that do allow location tracking that are configured on       the same interface and are part of the same network prefix MUST       NOT be gathered. Similarly, when host candidates corresponding       to an IPv6 address generated using a mechanism that prevents       location tracking are gathered, then host candidates corresponding       to IPv6 link-local addresses [RFC4291] MUST NOT be gathered. /a From nobody Thu Mar 1 12:28:35 2018 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 6412A12FA87 for ; Thu, 1 Mar 2018 12:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 yVtBQ3ItJHfZ for ; Thu, 1 Mar 2018 12:28:33 -0800 (PST) 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 146DB12FA8F for ; Thu, 1 Mar 2018 12:28:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519936110; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ij6gh1Kiqy8h3wh0FbDkO/3zITk1tb2uMPfsBYNj7hk=; b=EscXPkZ/mO++jIKFMhOngRd8JG6ozFOfkUm7NFf5gT+fq3uVjQM1BcxARv9m2eFz 6Y8FepqhLvymk2CSW48Vsn5JruDxS8g47vXmMcwFU0h30GCmSS397G98Zfj3QQ/c 7rgIvy2K//WrWgLSYYgfqCM2lGhveuQTe6Ls3gHIMrs=; X-AuditID: c1b4fb3a-347ff700000067b4-12-5a98626eb7e2 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 31.3E.26548.E62689A5; Thu, 1 Mar 2018 21:28:30 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Thu, 1 Mar 2018 21:28:29 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Adam Roach CC: Christer Holmberg , The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , Peter Thatcher , "ice-chairs@ietf.org" , "ice@ietf.org" Thread-Topic: Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT) Thread-Index: AQHTqvWUL4RerSy9UUOb/HLkf/KDiqOvQUQAgANPaICAAMnTgIAIdV2AgAABKwA= Date: Thu, 1 Mar 2018 20:28:29 +0000 Message-ID: References: <151920498287.9799.11602055137725027840.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C17B247@ESESSMB109.ericsson.se> <21c57c7c-6ba7-25d0-31a1-8cafbd42f3cd@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6C192F5D@ESESSMB109.ericsson.se> <2661ea85-ec00-244b-1817-78e49d3432b1@nostrum.com> In-Reply-To: <2661ea85-ec00-244b-1817-78e49d3432b1@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.95.226.8] Content-Type: text/plain; charset="utf-8" Content-ID: <4B31CDDD72E341409B045794E386A40A@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7rm5e0owog7YlChZ7/i5it5h/8jqz xcVZk9ksvl2otZjxZyKzxbXlr1kd2DwWbCr1WLLkJ5PHrJ1PWAKYo7hsUlJzMstSi/TtErgy jq9UKpikWDFp6TzWBsYlCl2MnBwSAiYS99dvZuti5OIQEjjMKPHm/VdmCGcRo8TTC79YQarY BGwlnrTuA7NFBBQl2g7fBCtiFpjCJLHxFEgHJ4ewQLzEzm1dTBBFCRJ9vUdZIGw/iWfNZ8Ca WQRUJG4fms0GYvMK2Et0rrjJCrFtP5PEoX1bwIo4gRKntn9mBLEZBcQkvp9aAzaUWUBc4taT +UwQdwtILNlznhnCFpV4+fgfK4QtLzHj7C2gGg6gek2J9bv0IVqtJT53f2GBsBUlpnQ/ZIe4 QVDi5MwnLBMYxWYh2TALoXsWku5ZSLpnIelewMi6ilG0OLW4ODfdyEgvtSgzubg4P08vL7Vk EyMwCg9u+W21g/Hgc8dDjAIcjEo8vL+jZ0QJsSaWFVfmHmKU4GBWEuE9vX1alBBvSmJlVWpR fnxRaU5q8SFGaQ4WJXFepzSLKCGB9MSS1OzU1ILUIpgsEwenVANjmMR3nYVuNt9uyUhe9542 9a4J19mv6ufZUhJVJbdvFc9aH1cV2P54ceFJL0+XywpHqifuTbsc1DyjQ87MPEI2dkOgUMWb ip/Cd7XfuimeSXYSkAjOK1I4ZfqCvSV2ya2NcYFh2s+uvAjbwXmH85f2ordZhe9FJ85h/G// 93o468wjTKwCNjeUWIozEg21mIuKEwEyTevmvgIAAA== Archived-At: Subject: Re: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT) 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, 01 Mar 2018 20:28:34 -0000 DQoNCj4gT24gMSBNYXIgMjAxOCwgYXQgMjIuMjQsIEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5j b20+IHdyb3RlOg0KPiANCj4gT24gMi8yNC8xOCA1OjE0IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3 cm90ZToNCj4+IA0KPj4+Pj4gVGhlIGRvY3VtZW50IGN1cnJlbnRseSBhcHBlYXJzIHRvIGNvbnRh aW4gbm9ybWF0aXZlIHN0YXRlbWVudHMgdGhhdCwgd2hpbGUgbm90IGxpdGVyYWxseSBjb250cmFk aWN0b3J5LCBjZXJ0YWlubHkgcG9pbnQgaW1wbGVtZW50b3JzIGluIGNvbmZsaWN0aW5nIGRpcmVj dGlvbnMuDQo+Pj4+PiDCpzUuMS4xLjEgc2F5czoNCj4+Pj4+IA0KPj4+Pj4gICBvICBIb3N0IGNh bmRpZGF0ZXMgY29ycmVzcG9uZGluZyB0byBJUHY2IGxpbmstbG9jYWwgYWRkcmVzc2VzIE1VU1QN Cj4+Pj4+ICAgICAgTk9UIGJlIGdhdGhlcmVkLg0KPj4+Pj4gDQo+Pj4+PiBGdXJ0aGVyIGRvd24s IMKnNi4xLjIuMiBzYXlzOg0KPj4+Pj4gDQo+Pj4+PiAgIFRvIGtlZXAgdGhlIGFtb3VudCBvZiBy ZXN1bHRpbmcgY2FuZGlkYXRlIHBhaXJzICByZWFzb25hYmxlIGFuZCB0bw0KPj4+Pj4gYXZvaWQg Y2FuZGlkYXRlIHBhaXJzIHRoYXQgYXJlIGhpZ2hseSB1bmxpa2VseSB0byAgd29yaywgSVB2Ng0K Pj4+Pj4gbGluay1sb2NhbCBhZGRyZXNzZXMgW1JGQzQyOTFdIE1VU1QgTk9UIGJlIHBhaXJlZCB3 aXRoICBvdGhlciB0aGFuDQo+Pj4+PiBsaW5rLWxvY2FsIGFkZHJlc3Nlcy4NCj4+Pj4+IA0KPj4+ Pj4gVGhpcyBzZWNvbmQgcGFzc2FnZSBpcyBub25zZW5zaWNhbCBpZiBJUHY2IGxpbmsgbG9jYWwg YWRkcmVzc2VzIE1VU1QNCj4+Pj4+IE5PVCBiZSBnYXRoZXJlZC4gUGxlYXNlIHJlbW92ZSBvciBh bWVuZCBvbmUgb2YgdGhlc2Ugbm9ybWF0aXZlIHN0YXRlbWVudHMuIElmIHRoZSBmaXJzdCBzdGF0 ZW1lbnQgaXMgcmV0YWluZWQsIHBsZWFzZSBhZGQgcmF0aW9uYWxlLg0KPj4+PiBCZW4gaGFkIHRo ZSBzYW1lIGNvbW1lbnQuIE15IHN1Z2dlc3Rpb24gd2FzIHRvIHJlbW92ZSB0aGUgdGV4dCBpbiA2 LjEuMi4yLg0KPj4+PiANCj4+Pj4gSSBndWVzcyB0aGUgcmF0aW9uYWxlIGlzIHNpbmNlIGEgbG9j YWwtbGluayBhZGRyZXNzIG1heSBub3QgYmUgdmFsaWQgZm9yIGNvbW11bmljYXRpbmcgd2l0aCB0 aGUgcGVlci4NCj4+PiBXZWxsLCBpdCBpcyBpZiB0aGV5J3JlIG9uIHRoZSBzYW1lIGxpbmsuIEZv ciBleGFtcGxlLCB3aGVuIEkgc3NoIGZyb20gb25lIG1hY2hpbmUgaW4gbXkgaG91c2UgdG8gYW5v dGhlciwgaXQgZ2VuZXJhbGx5IHVzZXMgYW4NCj4+PiBJUHY2IGxpbmstbG9jYWwgYWRkcmVzcy4g V2ViUlRDIGlzIGV4cGxpY2l0bHkgZXhwZWN0ZWQgdG8gdXNlIHRoaXMgb3B0aW1hbCBwYXRoIGlm IGl0IGV4aXN0cy4gSSB0aGluayB0aGUgZml4IHRoYXQgQXJpIHByb3Bvc2VzIG1ha2VzIG1vcmUg c2Vuc2UuDQo+PiBJIGFncmVlLiBJIHdpbGwgZml4IGFzIHN1Z2dlc3RlZCBieSBBcmkuDQo+IA0K PiBJIHJldmlld2VkIHRoZSB0ZXh0IGluIHRoZSAtMTggdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQs IGFuZCBpdCBkb2Vzbid0IHNlZW0gdG8gY29ycmVjdGx5IHJlZmxlY3QgdGhlIHN1Z2dlc3Rpb24g LS0gb3IgYXQgbGVhc3QsIGl0IGlzIGFtYmlndW91cy4gV2hhdCBpcyBpbiB0aGVyZSBub3cgaXM6 DQo+IA0KPj4gICAgbyAgSWYgb25lIG9yIG1vcmUgaG9zdCBjYW5kaWRhdGVzIGNvcnJlc3BvbmRp bmcgdG8gYW4gSVB2NiBhZGRyZXNzDQo+PiAgICAgICBnZW5lcmF0ZWQgdXNpbmcgYSBtZWNoYW5p c20gdGhhdCBwcmV2ZW50cyBsb2NhdGlvbiB0cmFja2luZw0KPj4gICAgICAgW1JGQzc3MjFdIGFy ZSBnYXRoZXJlZCwgaG9zdCBjYW5kaWRhdGVzIGNvcnJlc3BvbmRpbmcgdG8gSVB2Ng0KPj4gICAg ICAgYWRkcmVzc2VzIHRoYXQgZG8gYWxsb3cgbG9jYXRpb24gdHJhY2tpbmcgdGhhdCBhcmUgY29u ZmlndXJlZCBvbg0KPj4gICAgICAgdGhlIHNhbWUgaW50ZXJmYWNlIGFuZCBhcmUgcGFydCBvZiB0 aGUgc2FtZSBuZXR3b3JrIHByZWZpeCBNVVNUDQo+PiAgICAgICBOT1QgYmUgZ2F0aGVyZWQ7IGFu ZCBob3N0IGNhbmRpZGF0ZXMgY29ycmVzcG9uZGluZyB0byBJUHY2IGxpbmstDQo+PiAgICAgICBs b2NhbCBhZGRyZXNzZXMgW1JGQzQyOTFdIE1VU1QgTk9UIGJlIGdhdGhlcmVkLg0KPiANCj4gVGhl IHByb2JsZW1hdGljIHBocmFzZSBzdGlsbCBhcHBlYXJzOyBpdCdzIGp1c3QgYWZ0ZXIgYSBzZW1p Y29sb24gbm93LiBJdCBzZWVtcyBoaWdobHkgbGlrZWx5IHRoYXQgaW1wZWxlbWVudG9ycyB3aWxs IHJlYWQgdGhlIHBocmFzZSBhcyBiZWluZyB1bnF1YWxpZmllZCByYXRoZXIgdGhhbiBvbmx5IGFw cGx5aW5nIHdoZW4gUkZDIDc3MjEgYWRkcmVzc2VzIGFyZSB1c2VkLiBQZXJoYXBzOg0KPiANCj4g DQo+ICAgIG8gIElmIG9uZSBvciBtb3JlIGhvc3QgY2FuZGlkYXRlcyBjb3JyZXNwb25kaW5nIHRv IGFuIElQdjYgYWRkcmVzcw0KPiAgICAgICBnZW5lcmF0ZWQgdXNpbmcgYSBtZWNoYW5pc20gdGhh dCBwcmV2ZW50cyBsb2NhdGlvbiB0cmFja2luZw0KPiAgICAgICBbUkZDNzcyMV0gYXJlIGdhdGhl cmVkLCBob3N0IGNhbmRpZGF0ZXMgY29ycmVzcG9uZGluZyB0byBJUHY2DQo+ICAgICAgIGFkZHJl c3NlcyB0aGF0IGRvIGFsbG93IGxvY2F0aW9uIHRyYWNraW5nIHRoYXQgYXJlIGNvbmZpZ3VyZWQg b24NCj4gICAgICAgdGhlIHNhbWUgaW50ZXJmYWNlIGFuZCBhcmUgcGFydCBvZiB0aGUgc2FtZSBu ZXR3b3JrIHByZWZpeCBNVVNUDQo+ICAgICAgIE5PVCBiZSBnYXRoZXJlZC4gU2ltaWxhcmx5LCB3 aGVuIGhvc3QgY2FuZGlkYXRlcyBjb3JyZXNwb25kaW5nDQo+ICAgICAgIHRvIGFuIElQdjYgYWRk cmVzcyBnZW5lcmF0ZWQgdXNpbmcgYSBtZWNoYW5pc20gdGhhdCBwcmV2ZW50cw0KPiAgICAgICBs b2NhdGlvbiB0cmFja2luZyBhcmUgZ2F0aGVyZWQsIHRoZW4gaG9zdCBjYW5kaWRhdGVzIGNvcnJl c3BvbmRpbmcNCj4gICAgICAgdG8gSVB2NiBsaW5rLWxvY2FsIGFkZHJlc3NlcyBbUkZDNDI5MV0g TVVTVCBOT1QgYmUgZ2F0aGVyZWQuDQoNClRoaXMgbG9va3MgZ29vZCB0byBtZS4gVGhhbmtzIQ0K DQoNCkNoZWVycywNCkFyaQ0KDQo= From nobody Thu Mar 1 12:56:23 2018 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 4FEA512FADB for ; Thu, 1 Mar 2018 12:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 1w-q1eFNKrpn for ; Thu, 1 Mar 2018 12:56:14 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0437512FAB1 for ; Thu, 1 Mar 2018 12:56:14 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id l12so8570565ioc.10 for ; Thu, 01 Mar 2018 12:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=RXCTRTo4wWFXpRMbOzEq+KjE3NZW9A1Mpho9rak1chA=; b=WLKj6/JwFMhfJG77a4y40XFI9WoEMRWD3kIPPp+s1twnC0Xj8VhMz8BPhK/8AaOgsB ehhYtdpxdcq2a2ycST9e3MGkba0EjH9abQO/rWynNEMJB0evmLLVwGvVQh7n3heieVYR zh3xTe20svU8aCc5vGOzlknVQT2moPrwqxwng= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=RXCTRTo4wWFXpRMbOzEq+KjE3NZW9A1Mpho9rak1chA=; b=G+tf+2n9dfW1Z0AChrj4rOtVdc8PNTdMjySK7pZtUs3Lm+ihlhUg/5lEwaftn8fejN DqnDDwrsONJrUdbWDF2bNrXd88Scsf+hfE92DqsoCjpbJAG1OBW8FqaF+0YG59MNokXR nQdp/QEPIkIhkMy+46Wo93O8ZlbcexRadSSRJU2ZFkph8URCPv7aLmUc9RwKk14QDvRk 6jAu+URPFDEQ9+c8aR7yslgjtaQY9xXw3yQbOvLPBnukZiPXqz3Cebzs5zbLLlXIrHDb zonOUVS+PAGe4tZlkcja1V66ReZ5p65Jt0u5mIJ7YDPzHVT+mP4DCE2vUukfjA+IZqWV UGUw== X-Gm-Message-State: APf1xPCUUqJiGoFrjesChfLW507UlwSpiNFokv6mfQC778uzteUssznq z2Wsggk1SWRZE1K0zgPD3FTYnw== X-Google-Smtp-Source: AG47ELs1o2xVI0pesqN+ArvkBuyflUdavcGQv6GLa22wXCvmPPX02EFRCodNb0nTBAhFD7sW9Ln18Q== X-Received: by 10.107.143.210 with SMTP id r201mr3608518iod.115.1519937773269; Thu, 01 Mar 2018 12:56:13 -0800 (PST) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id x186sm3777061itb.6.2018.03.01.12.56.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 12:56:12 -0800 (PST) To: Christer Holmberg , Taylor Brandstetter Cc: Peter Saint-Andre , "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C1B8FEE@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1B9583@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: <70af5888-1927-1f62-ba3f-8d6fd4614c87@mozilla.com> Date: Thu, 1 Mar 2018 13:56:11 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1B9583@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x2ZvX2NgeSrkfR8bNGCSxsiFd84ggg5O3" Archived-At: Subject: Re: [Ice] Trickle: What is Section 16 about? 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, 01 Mar 2018 20:56:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x2ZvX2NgeSrkfR8bNGCSxsiFd84ggg5O3 Content-Type: multipart/mixed; boundary="obwznD0F1uaJkMTreVRlkhfZbPngvnNvu"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , Taylor Brandstetter Cc: Peter Saint-Andre , "ice@ietf.org" Message-ID: <70af5888-1927-1f62-ba3f-8d6fd4614c87@mozilla.com> Subject: Re: [Ice] Trickle: What is Section 16 about? References: <7594FB04B1934943A5C02806D1A2204B6C1B8FEE@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1B9583@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1B9583@ESESSMB109.ericsson.se> --obwznD0F1uaJkMTreVRlkhfZbPngvnNvu Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/1/18 12:19 PM, Christer Holmberg wrote: > Hi, >=20 >>> Assume the agent gets "stream 1 host", "stream 2 host" and "stream 2 = srflx". Should it wait for "stream 1 srflx" before trickling "stream 2 sr= flx"? >> >> That was my interpretation. >> =C2=A0 >>> How does the agent even know that it will get "stream 1 srflx"? >> >> If one candidate of a particular foundation was gathered successfully,= the agent can expect the rest of the=20 >> candidates with that foundation to be gathered successfully as well. >=20 > I don't think there is any rule saying that, for a given foundation, yo= u will get candidates for all streams (see example in section 6.1.2.6. of= 5245bis). For example, perhaps you gather relay candidates only for the = audio streams, because you want to use a relay for your video (you rather= don't use video, if it won't work without a relay). >=20 >> Again, I don't see the difference between streams and components here.= You could ask the same question of components: "How=20 >> does the agent know it will get 'RTP srflx' if it gets 'RTCP srflx'?" >=20 > You don't know - unless trickle mandates it (5245bis does not mandate i= t, as far as I know). >=20 >>> My point is that is if you have the following text: >>> >>> =C2=A0 =C2=A0"achieve this, when trickling candidates, agents MUST re= spect the >>> =C2=A0 =C2=A0order in which the components and streams appear (implic= itly or >>> =C2=A0 =C2=A0explicitly) as they have been negotiated by means of the= relevant >>> =C2=A0candidate information." >>> >>> ...you should explain how it impacts streams. Currently the text only= talks about components. >> >> Ah, so is the issue that the next sentence only mentions components? > =C2=A0 > Correct. >=20 >> =C2=A0 =C2=A0Therefore candidates for a given component >> =C2=A0 =C2=A0MUST NOT be conveyed prior to candidates for a component = with a lower >> =C2=A0 =C2=A0ID number within the same foundation. >> >> Streams are mentioned further below: >> >> Similar considerations apply at the level of media streams in >> addition to foundations; this is covered by the requirement to alway= s=C2=A0 >> start unfreezing candidates starting from the first media stream as >> described under Section 5.2. >> >> But this appears out of date. Section 5.2 used to say: >> >> If [the first] >> checklist is still empty however, agents will hold off further >> processing until this is no longer the case. >> >> .... Which ensures the first stream is always unfrozen first. But now = it says: >> >> =C2=A0 =C2=A0If that first component of the first media stream does >> =C2=A0 =C2=A0not contain candidates for one or more of the currently k= nown pair >> =C2=A0 =C2=A0foundations, and if candidate pairs already exist for tha= t foundation >> =C2=A0 =C2=A0in one of the following components or media streams, then= the agent >> =C2=A0 =C2=A0unfreezes the first of those candidate pairs. >> >> Meaning section 5.2 no longer enforces the stream ordering requirement= =2E >> >> So, I'd suggest: >> =E2=80=A2 Removing the outdated "Similar considerations apply..." para= graph. >> =E2=80=A2 Updating the rest of Section 16 to make it clear that candid= ates should be trickled in both stream and component order. >=20 > You would have to explain what "stream order" really means. Because, it= does not mean that you first trickle all candidates for stream 1, then a= ll candidates for stream 2, etc. >=20 > As I said above, you seem to suggest that, for each stream and each fou= ndation, there will be the same set of candidates. There is no such requi= rement anywhere, as far as I know.=20 I suggest that we remove all references to the poorly defined concept of "stream order". But if Emil thinks this is crucial then I'll defer to him. (I did connect with him offlist and he promises to weigh in soon.) Peter --obwznD0F1uaJkMTreVRlkhfZbPngvnNvu-- --x2ZvX2NgeSrkfR8bNGCSxsiFd84ggg5O3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqYaOsACgkQZWGMGH9o FKnEphAA6LWlJ/5AxiuAYCTXHcsuUPOZqgMrsVP8wZ8RQfnnO4mX7nv04jEu0iNa RGbgUzB/1TALsyZQdih26R+US1uIpgShxYEqF1PsQ6/PmwQU/rGYCcNU1U+bMWHJ 4bvdKnBdGGoKvi169H/im1Iofg1tllMAbeqB+/WQsbW6sDoi145F9n7mMIzumsv9 4nFOAgkdDu/MZVnIMu02QIfoXpsMufCOhrFjdSjN65MH82djZj/PZozbijI4aXYa 1BI85YWw1RU6oaxRcywOVlF35q9w/QpdRiubza/Wgt3uKbOk3aPTLp6fplRFFW4Y Z6cFgQLc34p/FKiN1VPTe41s55OukUN3Rx/fY5oqCZz18iMH9ZEWmpKtDpSsfvNc /ZR4fQIVEB0LRfKvfvX475TVYBs99J+uawl387vzdkH44TNwhoyUALhDt3rVxgLt wZdmw2Hd5ldob006BsC9artvwHe9ynDT8uok5Cj28QQjbblbPQzlPzbAD28Ym4ES wPJVYk310USAtUVqX++i7+ZFgXwhGKnxEj1E7vKTwG7hgJxyet0FOPC0sFP8ENI6 NndklykiGrO37S+nAvpMGM530G37vu7YZXPKBJVX6bAOtYlMcFX95VprDaeu0hy9 ooUGAIgQqE/m5aaRqrt9wM4kbucYZZ+XyHod/VSHOY99/AoX5/E= =TnJh -----END PGP SIGNATURE----- --x2ZvX2NgeSrkfR8bNGCSxsiFd84ggg5O3-- From nobody Thu Mar 1 13:18:18 2018 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 A13A012FABA for ; Thu, 1 Mar 2018 13:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01] 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 06BhQJRLZdCy for ; Thu, 1 Mar 2018 13:18:13 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA8212FAB3 for ; Thu, 1 Mar 2018 13:18:13 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id x4so4816628uaj.11 for ; Thu, 01 Mar 2018 13:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B4uiix/n25/wNYXZ8/pcDm71E/Jmjlgvolf6V/Wd+00=; b=ulOtGPGVyGDQ9zjAgCRmZTI0OzSs8B0C+3UX1OnxLKLj1iaGXGglXARvZprsIyj2cl BsKYVLv9tAFY363K8vsAo+pWkAgvmuHqwIePTxyP1+35SYSoIAEu7F6gk7lw8WkqV+Ci DxytZrH+GIWM6Xv2vEscRyBtj4MmfZPismYyptMI2c3JFPj38pyObgcBCSjMEJpmopIU XdvnhdxEechsCeevVRNj3xid12/rx0z/kpxK43JeSmRi2afGQS8B534wvjvPE284WjOs E1kA6sLztMSGDiZOwAYZNHhqu7HsrZkbfW6zkmacC3mxTG/TWpXW1wHivCY6FWqxAkoI E2gQ== 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=B4uiix/n25/wNYXZ8/pcDm71E/Jmjlgvolf6V/Wd+00=; b=fTzvaPpPW266VPiY4FUhx0POukZedZvJENRQhLRrdPzcRG9XUHeSggsrlSRFGIdSvE Bu1PDo6/Ae7989sOMZPjBIW5vM6lKw1Dt7/vXR/oqJl0CWak5zPiYemyDOuP/Q2I4uhw UZ2ya0qFcgnHAd8HDKfN34sOIamJolfnLryzbwkcjTMKODNp3TcqGRQJe6dwUAoFkEgr icFNaBX/WM1B6KEdz8TrjS+Ixfe61h/2Wy6bnsC+YZTZvsg47vnm6L91b+Fkj+kMAM/J ThOeWsy4ckEmfoN5ZWr7VO4nye4qUMVu+WhWtrxbVtvsWVsZoYvMQKCxiKaeIisebXy4 Bc0g== X-Gm-Message-State: APf1xPD2CpkPGMA/YjyyK5NNuRmkMPBf+LYSI7OcKtuqaoRRBRDfkryq hESo/Zehs1hToH37QtaxtFZh0a0utK+2w88CaAWNXg== X-Google-Smtp-Source: AG47ELv07DAR5y3LjY7TJbwaGtb7uCDP9hc7eIVeEU3SD8CT6vJHFTOEwoUdbiEqjof3TGeTwwnECiYPzfKB9HqB2Nk= X-Received: by 10.159.58.215 with SMTP id q23mr2262896uag.129.1519939092162; Thu, 01 Mar 2018 13:18:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.114.66 with HTTP; Thu, 1 Mar 2018 13:18:11 -0800 (PST) In-Reply-To: <70af5888-1927-1f62-ba3f-8d6fd4614c87@mozilla.com> References: <7594FB04B1934943A5C02806D1A2204B6C1B8FEE@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1B9583@ESESSMB109.ericsson.se> <70af5888-1927-1f62-ba3f-8d6fd4614c87@mozilla.com> From: Taylor Brandstetter Date: Thu, 1 Mar 2018 13:18:11 -0800 Message-ID: To: Peter Saint-Andre Cc: Christer Holmberg , Peter Saint-Andre , "ice@ietf.org" Content-Type: multipart/alternative; boundary="f40304366014abdcff05666065c6" Archived-At: Subject: Re: [Ice] Trickle: What is Section 16 about? 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, 01 Mar 2018 21:18:16 -0000 --f40304366014abdcff05666065c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > For example, perhaps you gather relay candidates only for the audio > streams, because you want to use a relay for your video (you rather don't > use video, if it won't work without a relay). > I agree there's nothing preventing this. In this case the ICE agent would be able to trickle the audio relay candidate immediately. > Again, I don't see the difference between streams and components here. > You could ask the same question of components: "How > > does the agent know it will get 'RTP srflx' if it gets 'RTCP srflx'?" > > You don't know - unless trickle mandates it (5245bis does not mandate it, > as far as I know). > The ICE agent doesn't know what candidates it's attempting to gather? Or it doesn't know whether the pending STUN transaction will fail? You would have to explain what "stream order" really means. > It would be the order of the rows in section 8.1; ordered first by stream then by component. As I said above, you seem to suggest that, for each stream and each > foundation, there will be the same set of candidates. There is no such > requirement anywhere, as far as I know. > I didn't mean to suggest that. Section 16 allows one foundation to have a smaller set of candidates as long as they're trickled in order. I suggest that we remove all references to the poorly defined concept of > "stream order". So keep the component order but not stream order? Just because it's better defined, or is there another reason? On Thu, Mar 1, 2018 at 12:56 PM, Peter Saint-Andre wrote: > On 3/1/18 12:19 PM, Christer Holmberg wrote: > > Hi, > > > >>> Assume the agent gets "stream 1 host", "stream 2 host" and "stream 2 > srflx". Should it wait for "stream 1 srflx" before trickling "stream 2 > srflx"? > >> > >> That was my interpretation. > >> > >>> How does the agent even know that it will get "stream 1 srflx"? > >> > >> If one candidate of a particular foundation was gathered successfully, > the agent can expect the rest of the > >> candidates with that foundation to be gathered successfully as well. > > > > I don't think there is any rule saying that, for a given foundation, yo= u > will get candidates for all streams (see example in section 6.1.2.6. of > 5245bis). For example, perhaps you gather relay candidates only for the > audio streams, because you want to use a relay for your video (you rather > don't use video, if it won't work without a relay). > > > >> Again, I don't see the difference between streams and components here. > You could ask the same question of components: "How > >> does the agent know it will get 'RTP srflx' if it gets 'RTCP srflx'?" > > > > You don't know - unless trickle mandates it (5245bis does not mandate > it, as far as I know). > > > >>> My point is that is if you have the following text: > >>> > >>> "achieve this, when trickling candidates, agents MUST respect the > >>> order in which the components and streams appear (implicitly or > >>> explicitly) as they have been negotiated by means of the relevant > >>> candidate information." > >>> > >>> ...you should explain how it impacts streams. Currently the text only > talks about components. > >> > >> Ah, so is the issue that the next sentence only mentions components? > > > > Correct. > > > >> Therefore candidates for a given component > >> MUST NOT be conveyed prior to candidates for a component with a low= er > >> ID number within the same foundation. > >> > >> Streams are mentioned further below: > >> > >> Similar considerations apply at the level of media streams in > >> addition to foundations; this is covered by the requirement to alway= s > >> start unfreezing candidates starting from the first media stream as > >> described under Section 5.2. > >> > >> But this appears out of date. Section 5.2 used to say: > >> > >> If [the first] > >> checklist is still empty however, agents will hold off further > >> processing until this is no longer the case. > >> > >> .... Which ensures the first stream is always unfrozen first. But now > it says: > >> > >> If that first component of the first media stream does > >> not contain candidates for one or more of the currently known pair > >> foundations, and if candidate pairs already exist for that foundati= on > >> in one of the following components or media streams, then the agent > >> unfreezes the first of those candidate pairs. > >> > >> Meaning section 5.2 no longer enforces the stream ordering requirement= . > >> > >> So, I'd suggest: > >> =E2=80=A2 Removing the outdated "Similar considerations apply..." para= graph. > >> =E2=80=A2 Updating the rest of Section 16 to make it clear that candid= ates > should be trickled in both stream and component order. > > > > You would have to explain what "stream order" really means. Because, it > does not mean that you first trickle all candidates for stream 1, then al= l > candidates for stream 2, etc. > > > > As I said above, you seem to suggest that, for each stream and each > foundation, there will be the same set of candidates. There is no such > requirement anywhere, as far as I know. > > I suggest that we remove all references to the poorly defined concept of > "stream order". But if Emil thinks this is crucial then I'll defer to > him. (I did connect with him offlist and he promises to weigh in soon.) > > Peter > > --f40304366014abdcff05666065c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For example, perhaps you gather= relay candidates only for the audio streams, because you want to use a rel= ay for your video (you rather don't use video, if it won't work wit= hout a relay).

I agree there's no= thing preventing this. In this case the ICE agent would be able to trickle = the audio relay candidate immediately.

> Again, I don't see the d= ifference between streams and components here. You could ask the same quest= ion of components: "How
> does the agent know it will get 'R= TP srflx' if it gets 'RTCP srflx'?"

You don't know - unless trickle mandates it (5245bis= does not mandate it, as far as I know).

The ICE agent doesn't know what candidates it's attempting to = gather? Or it doesn't know whether the pending STUN transaction will fa= il?

You would have to explain what "stream order" really m= eans.

It would be the order of the ro= ws in section 8.1; ordered first by stream then by component.=C2=A0

= As I said above, you seem to suggest that, for each stream and each foundat= ion, there will be the same set of candidates. There is no such requirement= anywhere, as far as I know.

=C2=A0I = didn't mean to suggest that. Section 16 allows one foundation to have a= smaller set of candidates as long as they're trickled in order.
<= br>
I suggest that we remove all references to the poorly defined concept = of
"stream order".

So keep the component order but not stream order? = Just because it's better defined, or is there another reason?

On Thu, Mar 1, = 2018 at 12:56 PM, Peter Saint-Andre <stpeter@mozilla.com> = wrote:
On 3/1/18 12:19 PM, Christer Holmberg wrote:
> Hi,
>
>>> Assume the agent gets "stream 1 host", "stream = 2 host" and "stream 2 srflx". Should it wait for "strea= m 1 srflx" before trickling "stream 2 srflx"?
>>
>> That was my interpretation.
>> =C2=A0
>>> How does the agent even know that it will get "stream 1 s= rflx"?
>>
>> If one candidate of a particular foundation was gathered successfu= lly, the agent can expect the rest of the
>> candidates with that foundation to be gathered successfully as wel= l.
>
> I don't think there is any rule saying that, for a given foundatio= n, you will get candidates for all streams (see example in section 6.1.2.6.= of 5245bis). For example, perhaps you gather relay candidates only for the= audio streams, because you want to use a relay for your video (you rather = don't use video, if it won't work without a relay).
>
>> Again, I don't see the difference between streams and componen= ts here. You could ask the same question of components: "How
>> does the agent know it will get 'RTP srflx' if it gets = 9;RTCP srflx'?"
>
> You don't know - unless trickle mandates it (5245bis does not mand= ate it, as far as I know).
>
>>> My point is that is if you have the following text:
>>>
>>> =C2=A0 =C2=A0"achieve this, when trickling candidates, ag= ents MUST respect the
>>> =C2=A0 =C2=A0order in which the components and streams appear = (implicitly or
>>> =C2=A0 =C2=A0explicitly) as they have been negotiated by means= of the relevant
>>> =C2=A0candidate information."
>>>
>>> ...you should explain how it impacts streams. Currently the te= xt only talks about components.
>>
>> Ah, so is the issue that the next sentence only mentions component= s?
> =C2=A0
> Correct.
>
>> =C2=A0 =C2=A0Therefore candidates for a given component
>> =C2=A0 =C2=A0MUST NOT be conveyed prior to candidates for a compon= ent with a lower
>> =C2=A0 =C2=A0ID number within the same foundation.
>>
>> Streams are mentioned further below:
>>
>>=C2=A0 =C2=A0Similar considerations apply at the level of media str= eams in
>>=C2=A0 =C2=A0addition to foundations; this is covered by the requir= ement to always=C2=A0
>>=C2=A0 =C2=A0start unfreezing candidates starting from the first me= dia stream as
>>=C2=A0 =C2=A0described under Section 5.2.
>>
>> But this appears out of date. Section 5.2 used to say:
>>
>> If [the first]
>> checklist is still empty however, agents will hold off further
>> processing until this is no longer the case.
>>
>> .... Which ensures the first stream is always unfrozen first. But = now it says:
>>
>> =C2=A0 =C2=A0If that first component of the first media stream doe= s
>> =C2=A0 =C2=A0not contain candidates for one or more of the current= ly known pair
>> =C2=A0 =C2=A0foundations, and if candidate pairs already exist for= that foundation
>> =C2=A0 =C2=A0in one of the following components or media streams, = then the agent
>> =C2=A0 =C2=A0unfreezes the first of those candidate pairs.
>>
>> Meaning section 5.2 no longer enforces the stream ordering require= ment.
>>
>> So, I'd suggest:
>> =E2=80=A2 Removing the outdated "Similar considerations apply= ..." paragraph.
>> =E2=80=A2 Updating the rest of Section 16 to make it clear that ca= ndidates should be trickled in both stream and component order.
>
> You would have to explain what "stream order" really means. = Because, it does not mean that you first trickle all candidates for stream = 1, then all candidates for stream 2, etc.
>
> As I said above, you seem to suggest that, for each stream and each fo= undation, there will be the same set of candidates. There is no such requir= ement anywhere, as far as I know.

I suggest that we remove all references to the poorly defined c= oncept of
"stream order". But if Emil thinks this is crucial then I'll = defer to
him. (I did connect with him offlist and he promises to weigh in soon.)

Peter


--f40304366014abdcff05666065c6-- From nobody Thu Mar 1 13:23:55 2018 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 7A12E12FAB3 for ; Thu, 1 Mar 2018 13:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 dON4X4AlWvls for ; Thu, 1 Mar 2018 13:23:53 -0800 (PST) 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 23D2212EE46 for ; Thu, 1 Mar 2018 13:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519939431; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0RsVzFnOOK8XLxDJuVrIj7IMBqiD848JQ/S0p1k0Gio=; b=K5F15sKJjSdglObYXStRW+YqxgmGk69VgY08YaEpirZDuLloBcOc6B29kU9HsmV+ 0SvyM5E/LBijL/1CVmLpD6SzugpwEPO2d2hXBA0Zs4IDILYZIvVxNO2A+X2nTmm8 1BRGkdKMWOqBu1Up4j2r31z6gAcc98BhXrdqD7dIyTg=; X-AuditID: c1b4fb25-083ff70000002d5f-eb-5a986f6793ab Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 37.F8.11615.76F689A5; Thu, 1 Mar 2018 22:23:51 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Thu, 1 Mar 2018 22:23:50 +0100 From: Christer Holmberg To: Peter Saint-Andre , Taylor Brandstetter CC: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] Trickle: What is Section 16 about? Thread-Index: AQHTsGOwLjmDpDpE6ESJTIumIw+YtaO6E/aAgAFrNYCAAA3hgIAAAHKAgAAUBGCAAAnMgIAAFajwgAAM9ICAABW58A== Date: Thu, 1 Mar 2018 21:23:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1B9899@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C1B8FEE@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1B9583@ESESSMB109.ericsson.se> <70af5888-1927-1f62-ba3f-8d6fd4614c87@mozilla.com> In-Reply-To: <70af5888-1927-1f62-ba3f-8d6fd4614c87@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbFdWjc9f0aUwZsWQYvLKx6yWny7UGvx bOUpRotje/qZHVg8Fmwq9Viy5CeTR9+BLlaPuXteMAewRHHZpKTmZJalFunbJXBldC9YwFzQ oVvx+9YuxgbGL9pdjJwcEgImEk9PPGHuYuTiEBI4zCix/sYKRghnEaPEhpOLWboYOTjYBCwk uv+BNYgIREhcfHGWGcRmFvCUeHx8FxOILSxgKtHceIgJosZM4sTbvVB2lsTzYy8ZQWwWARWJ 6b972UBG8gr4Sry4EQOx6hiLxNsn19hBajgF7CXO71sPNp9RQEzi+6k1TBC7xCVuPZnPBHG0 gMSSPeeZIWxRiZeP/7FC2EoSy6dtYQeZzyygKbF+lz5Eq6LElO6HYON5BQQlTs58wjKBUXQW kqmzEDpmIemYhaRjASPLKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAODq45bfqDsbLbxwP MQpwMCrx8AbEzIgSYk0sK67MPcQowcGsJMJ7evu0KCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8 c4Tbo4QE0hNLUrNTUwtSi2CyTBycUg2M3VvSDgX7ZTBcN9eR3V5Q+qhFrUCo7MdkqTWb539S mSacvMvw5mfLc5ErW/7Fd56zPOtwh+VLTady+fwjfyuOHjNbNK2mjPOjwLZzD23r13Tyb9jl r83qcFLo34bOHXuCNx3qKtq5zFC869TZ2h+vjDNT3B/EvXj6SyJyLfvtWTPt5TzmMUYWKbEU ZyQaajEXFScCAHkEUy+fAgAA Archived-At: Subject: Re: [Ice] Trickle: What is Section 16 about? 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, 01 Mar 2018 21:23:54 -0000 SGksDQoNCj4+Pj4gQXNzdW1lIHRoZSBhZ2VudCBnZXRzICJzdHJlYW0gMSBob3N0IiwgInN0cmVh bSAyIGhvc3QiIGFuZCAic3RyZWFtIDIgc3JmbHgiLiBTaG91bGQgaXQgd2FpdCBmb3IgInN0cmVh bSAxIHNyZmx4IiBiZWZvcmUgdHJpY2tsaW5nICJzdHJlYW0gMiBzcmZseCI/DQo+Pj4NCj4+PiBU aGF0IHdhcyBteSBpbnRlcnByZXRhdGlvbi4NCj4+PiDCoA0KPj4+PiBIb3cgZG9lcyB0aGUgYWdl bnQgZXZlbiBrbm93IHRoYXQgaXQgd2lsbCBnZXQgInN0cmVhbSAxIHNyZmx4Ij8NCj4+Pg0KPj4+ IElmIG9uZSBjYW5kaWRhdGUgb2YgYSBwYXJ0aWN1bGFyIGZvdW5kYXRpb24gd2FzIGdhdGhlcmVk IA0KPj4+IHN1Y2Nlc3NmdWxseSwgdGhlIGFnZW50IGNhbiBleHBlY3QgdGhlIHJlc3Qgb2YgdGhl IGNhbmRpZGF0ZXMgd2l0aCB0aGF0IGZvdW5kYXRpb24gdG8gYmUgZ2F0aGVyZWQgc3VjY2Vzc2Z1 bGx5IGFzIHdlbGwuDQo+PiANCj4+IEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYW55IHJ1bGUgc2F5 aW5nIHRoYXQsIGZvciBhIGdpdmVuIGZvdW5kYXRpb24sIHlvdSB3aWxsIGdldCBjYW5kaWRhdGVz IGZvciBhbGwgc3RyZWFtcyANCj4+IChzZWUgZXhhbXBsZSBpbiBzZWN0aW9uIDYuMS4yLjYuIG9m IDUyNDViaXMpLiBGb3IgZXhhbXBsZSwgcGVyaGFwcyB5b3UgZ2F0aGVyIHJlbGF5IGNhbmRpZGF0 ZXMgb25seSBmb3IgdGhlIA0KPj4gYXVkaW8gc3RyZWFtcywgYmVjYXVzZSB5b3Ugd2FudCB0byB1 c2UgYSByZWxheSBmb3IgeW91ciB2aWRlbyAoeW91IHJhdGhlciBkb24ndCB1c2UgdmlkZW8sIGlm IGl0IHdvbid0IHdvcmsgd2l0aG91dCBhIHJlbGF5KS4NCj4+IA0KPj4+IEFnYWluLCBJIGRvbid0 IHNlZSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHN0cmVhbXMgYW5kIGNvbXBvbmVudHMgDQo+Pj4g aGVyZS4gWW91IGNvdWxkIGFzayB0aGUgc2FtZSBxdWVzdGlvbiBvZiBjb21wb25lbnRzOiAiSG93 IGRvZXMgdGhlIGFnZW50IGtub3cgaXQgd2lsbCBnZXQgJ1JUUCBzcmZseCcgaWYgaXQgZ2V0cyAn UlRDUCBzcmZseCc/Ig0KPj4gDQo+PiBZb3UgZG9uJ3Qga25vdyAtIHVubGVzcyB0cmlja2xlIG1h bmRhdGVzIGl0ICg1MjQ1YmlzIGRvZXMgbm90IG1hbmRhdGUgaXQsIGFzIGZhciBhcyBJIGtub3cp Lg0KPj4gDQo+Pj4+IE15IHBvaW50IGlzIHRoYXQgaXMgaWYgeW91IGhhdmUgdGhlIGZvbGxvd2lu ZyB0ZXh0Og0KPj4+Pg0KPj4+PiDCoCDCoCJhY2hpZXZlIHRoaXMsIHdoZW4gdHJpY2tsaW5nIGNh bmRpZGF0ZXMsIGFnZW50cyBNVVNUIHJlc3BlY3QgdGhlDQo+Pj4+IMKgIMKgb3JkZXIgaW4gd2hp Y2ggdGhlIGNvbXBvbmVudHMgYW5kIHN0cmVhbXMgYXBwZWFyIChpbXBsaWNpdGx5IG9yDQo+Pj4+ IMKgIMKgZXhwbGljaXRseSkgYXMgdGhleSBoYXZlIGJlZW4gbmVnb3RpYXRlZCBieSBtZWFucyBv ZiB0aGUgcmVsZXZhbnQNCj4+Pj4gwqBjYW5kaWRhdGUgaW5mb3JtYXRpb24uIg0KPj4+Pg0KPj4+ PiAuLi55b3Ugc2hvdWxkIGV4cGxhaW4gaG93IGl0IGltcGFjdHMgc3RyZWFtcy4gQ3VycmVudGx5 IHRoZSB0ZXh0IG9ubHkgdGFsa3MgYWJvdXQgY29tcG9uZW50cy4NCj4+Pg0KPj4+IEFoLCBzbyBp cyB0aGUgaXNzdWUgdGhhdCB0aGUgbmV4dCBzZW50ZW5jZSBvbmx5IG1lbnRpb25zIGNvbXBvbmVu dHM/DQo+PiDCoA0KPj4gQ29ycmVjdC4NCj4+IA0KPj4+IMKgIMKgVGhlcmVmb3JlIGNhbmRpZGF0 ZXMgZm9yIGEgZ2l2ZW4gY29tcG9uZW50DQo+Pj4gwqAgwqBNVVNUIE5PVCBiZSBjb252ZXllZCBw cmlvciB0byBjYW5kaWRhdGVzIGZvciBhIGNvbXBvbmVudCB3aXRoIGEgDQo+Pj4gICAgbG93ZXIg SUQgbnVtYmVyIHdpdGhpbiB0aGUgc2FtZSBmb3VuZGF0aW9uLg0KPj4+DQo+Pj4gU3RyZWFtcyBh cmUgbWVudGlvbmVkIGZ1cnRoZXIgYmVsb3c6DQo+Pj4NCj4+PiAgIFNpbWlsYXIgY29uc2lkZXJh dGlvbnMgYXBwbHkgYXQgdGhlIGxldmVsIG9mIG1lZGlhIHN0cmVhbXMgaW4NCj4+PiAgIGFkZGl0 aW9uIHRvIGZvdW5kYXRpb25zOyB0aGlzIGlzIGNvdmVyZWQgYnkgdGhlIHJlcXVpcmVtZW50IHRv IGFsd2F5c8KgDQo+Pj4gICBzdGFydCB1bmZyZWV6aW5nIGNhbmRpZGF0ZXMgc3RhcnRpbmcgZnJv bSB0aGUgZmlyc3QgbWVkaWEgc3RyZWFtIGFzDQo+Pj4gICBkZXNjcmliZWQgdW5kZXIgU2VjdGlv biA1LjIuDQo+Pj4NCj4+PiBCdXQgdGhpcyBhcHBlYXJzIG91dCBvZiBkYXRlLiBTZWN0aW9uIDUu MiB1c2VkIHRvIHNheToNCj4+Pg0KPj4+IElmIFt0aGUgZmlyc3RdIGNoZWNrbGlzdCBpcyBzdGls bCBlbXB0eSBob3dldmVyLCBhZ2VudHMgd2lsbCBob2xkIG9mZiBmdXJ0aGVyIA0KPj4+IHByb2Nl c3NpbmcgdW50aWwgdGhpcyBpcyBubyBsb25nZXIgdGhlIGNhc2UuDQo+Pj4NCj4+PiAuLi4uIFdo aWNoIGVuc3VyZXMgdGhlIGZpcnN0IHN0cmVhbSBpcyBhbHdheXMgdW5mcm96ZW4gZmlyc3QuIEJ1 dCBub3cgaXQgc2F5czoNCj4+Pg0KPj4+IMKgIMKgSWYgdGhhdCBmaXJzdCBjb21wb25lbnQgb2Yg dGhlIGZpcnN0IG1lZGlhIHN0cmVhbSBkb2VzDQo+Pj4gwqAgwqBub3QgY29udGFpbiBjYW5kaWRh dGVzIGZvciBvbmUgb3IgbW9yZSBvZiB0aGUgY3VycmVudGx5IGtub3duIHBhaXINCj4+PiDCoCDC oGZvdW5kYXRpb25zLCBhbmQgaWYgY2FuZGlkYXRlIHBhaXJzIGFscmVhZHkgZXhpc3QgZm9yIHRo YXQgDQo+Pj4gZm91bmRhdGlvbg0KPj4+IMKgIMKgaW4gb25lIG9mIHRoZSBmb2xsb3dpbmcgY29t cG9uZW50cyBvciBtZWRpYSBzdHJlYW1zLCB0aGVuIHRoZSANCj4+PiBhZ2VudA0KPj4+IMKgIMKg dW5mcmVlemVzIHRoZSBmaXJzdCBvZiB0aG9zZSBjYW5kaWRhdGUgcGFpcnMuDQo+Pj4NCj4+PiBN ZWFuaW5nIHNlY3Rpb24gNS4yIG5vIGxvbmdlciBlbmZvcmNlcyB0aGUgc3RyZWFtIG9yZGVyaW5n IHJlcXVpcmVtZW50Lg0KPj4+DQo+Pj4gU28sIEknZCBzdWdnZXN0Og0KPj4+IOKAoiBSZW1vdmlu ZyB0aGUgb3V0ZGF0ZWQgIlNpbWlsYXIgY29uc2lkZXJhdGlvbnMgYXBwbHkuLi4iIHBhcmFncmFw aC4NCj4+PiDigKIgVXBkYXRpbmcgdGhlIHJlc3Qgb2YgU2VjdGlvbiAxNiB0byBtYWtlIGl0IGNs ZWFyIHRoYXQgY2FuZGlkYXRlcyBzaG91bGQgYmUgdHJpY2tsZWQgaW4gYm90aCBzdHJlYW0gYW5k IGNvbXBvbmVudCBvcmRlci4NCj4+IA0KPj4gWW91IHdvdWxkIGhhdmUgdG8gZXhwbGFpbiB3aGF0 ICJzdHJlYW0gb3JkZXIiIHJlYWxseSBtZWFucy4gQmVjYXVzZSwgaXQgZG9lcyBub3QgbWVhbiB0 aGF0IHlvdSBmaXJzdCB0cmlja2xlIA0KPj5hbGwgY2FuZGlkYXRlcyBmb3Igc3RyZWFtIDEsIHRo ZW4gYWxsIGNhbmRpZGF0ZXMgZm9yIHN0cmVhbSAyLCA+PiBldGMuDQo+PiANCj4+IEFzIEkgc2Fp ZCBhYm92ZSwgeW91IHNlZW0gdG8gc3VnZ2VzdCB0aGF0LCBmb3IgZWFjaCBzdHJlYW0gYW5kIGVh Y2ggZm91bmRhdGlvbiwgdGhlcmUgd2lsbCBiZSB0aGUgc2FtZSBzZXQgb2YgDQo+PiBjYW5kaWRh dGVzLiBUaGVyZSBpcyBubyBzdWNoIHJlcXVpcmVtZW50IGFueXdoZXJlLCBhcyBmYXIgYXMgSSBr bm93LiANCj4NCj4gSSBzdWdnZXN0IHRoYXQgd2UgcmVtb3ZlIGFsbCByZWZlcmVuY2VzIHRvIHRo ZSBwb29ybHkgZGVmaW5lZCBjb25jZXB0IG9mICJzdHJlYW0gb3JkZXIiLiBCdXQgaWYgRW1pbCB0 aGlua3MgdGhpcyBpcyBjcnVjaWFsIA0KPiB0aGVuIEknbGwgZGVmZXIgdG8gaGltLiAoSSBkaWQg Y29ubmVjdCB3aXRoIGhpbSBvZmZsaXN0IGFuZCBoZSBwcm9taXNlcyB0byB3ZWlnaCBpbiBzb29u LikNCg0KTWF5YmUgdGhlcmUgaXMgc29tZXRoaW5nIGltcG9ydGFudCBiZWhpbmQgaXQsIGJ1dCB3 ZSBuZWVkIHRvIHVuZGVyc3RhbmQgd2hhdCBpdCBtZWFucy4NCg0KTUFZQkUgaXQgbWVhbnMgdGhh dCwgdGhyb3VnaG91dCBhbGwgc3RyZWFtcywgYWxsIGZvdW5kYXRpb25zIGFyZSB0cmlja2xlZCBp biB0aGUgc2FtZSBvcmRlciAoYW5kIGZvciBlYWNoIGZvdW5kYXRpb24gdGhlIGNvbXBvbmVudHMg YXJlIHRyaWNrbGVkIGluIHRoZSBzYW1lIG9yZGVyKS4gQnV0LCBhZ2FpbiwgdGhhdCBhc3N1bWVz IHRoYXQgeW91IGFjdHVhbGx5IGtub3cgd2hhdCBmb3VuZGF0aW9ucyB5b3UgYXJlIGdvaW5nIHRv IGhhdmUgZm9yIGVhY2ggc3RyZWFtIHdoZW4geW91IHN0YXJ0LCBhbmQgSSdtIG5vdCBzdXJlIHdl IGNhbiBtYWtlIHN1Y2ggYXNzdW1wdGlvbi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Thu Mar 1 13:40:09 2018 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 5043C12FABF for ; Thu, 1 Mar 2018 13:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 p1-MIVHYZE95 for ; Thu, 1 Mar 2018 13:40:06 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604C112FAB8 for ; Thu, 1 Mar 2018 13:40:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519940404; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=E7tKCpU/wgQtScBsTt+7ZvAkDxp5+B25GOPxW8fynuA=; b=QkhWdLIebRYw3ZClEYSTg9lVBaSNMBZX5CuW8FR+Q7LNKMtj2JEQbo53LkW71MWp dJarXFYxVEjFqBrChynDzvl/gMYR+5EGX0KwQuYe6GB/RPvIbyi7wOmx0xNhc4Wz TqdfxMYhI8KcI8jqifw72yHknD/gHJnkYa5YenEJ63o=; X-AuditID: c1b4fb2d-4b1ff70000005540-b8-5a9873342967 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F1.8B.21824.433789A5; Thu, 1 Mar 2018 22:40:04 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Thu, 1 Mar 2018 22:40:04 +0100 From: Christer Holmberg To: Taylor Brandstetter , Peter Saint-Andre CC: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] Trickle: What is Section 16 about? Thread-Index: AQHTsGOwLjmDpDpE6ESJTIumIw+YtaO6E/aAgAFrNYCAAA3hgIAAAHKAgAAUBGCAAAnMgIAAFajwgAAM9ICAAAYlgIAAEn8g Date: Thu, 1 Mar 2018 21:40:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1B9921@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C1B8FEE@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1B9583@ESESSMB109.ericsson.se> <70af5888-1927-1f62-ba3f-8d6fd4614c87@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbFdV9ekeEaUwZRlOhaXVzxktfh2odbi 2cpTjBbH9vQzO7B4LNhU6rFkyU8mj74DXawec/e8YA5gieKySUnNySxLLdK3S+DKeN6bVPDB pmL2ObUGxhXWXYycHBICJhI7Wx+wdzFycQgJHGaUOHroJJSziFFixdUjbF2MHBxsAhYS3f+0 QRpEBCIkfjy6ygRiMwt4Sjw+vgvMFhYwlWhuPMQEUWMmceLtXig7T+LnyXvMIDaLgIrElkUr 2UBsXgFfiUfLpjFD7Oplldi09ytYA6dAoMSxE6dYQGxGATGJ76fWQC0Tl7j1ZD4TxNUCEkv2 nGeGsEUlXj7+xwphK0ksn7aFHeRmZgFNifW79CFaFSWmdD9kh9grKHFy5hOWCYyis5BMnYXQ MQtJxywkHQsYWVYxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBEbRwS2/dXcwrn7teIhRgINR iYc3I2ZGlBBrYllxZe4hRgkOZiUR3tPbp0UJ8aYkVlalFuXHF5XmpBYfYpTmYFES5z3pyRsl JJCeWJKanZpakFoEk2Xi4JRqYAxXu3SBe1vv3f69xdwHZEwVPsmcW7ByX+bpm3VBa74enNiw Kzu26fEDV1M7hT1qW05M7vJfmXYs4OnvT+08WxU4ztWdEtCdOEWLuVpkXsgch7uL103e/fhH 7do/N0xPTFVStP42e8dkgcjWrxcEbi5y/KVhGpTfUfr4SLrEOpuH0aw/1NfGnj+oxFKckWio xVxUnAgAhB0DK54CAAA= Archived-At: Subject: Re: [Ice] Trickle: What is Section 16 about? 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, 01 Mar 2018 21:40:08 -0000 SGksDQoNCj4+IEZvciBleGFtcGxlLCBwZXJoYXBzIHlvdSBnYXRoZXIgcmVsYXkgY2FuZGlkYXRl cyBvbmx5IGZvciB0aGUgYXVkaW8gc3RyZWFtcywgYmVjYXVzZSB5b3UgZG9uJ3Qgd2FudCB0byB1 c2UgDQo+PiBhIHJlbGF5IGZvciB5b3VyIHZpZGVvICh5b3UgcmF0aGVyIGRvbid0IHVzZSB2aWRl bywgaWYgaXQgd29uJ3Qgd29yayB3aXRob3V0IGEgcmVsYXkpLg0KPg0KPiBJIGFncmVlIHRoZXJl J3Mgbm90aGluZyBwcmV2ZW50aW5nIHRoaXMuIEluIHRoaXMgY2FzZSB0aGUgSUNFIGFnZW50IHdv dWxkIGJlIGFibGUgdG8gdHJpY2tsZSB0aGUgYXVkaW8gcmVsYXkgY2FuZGlkYXRlIGltbWVkaWF0 ZWx5Lg0KDQpZZXMsIGJ1dCBpbiB0aGlzIGNhc2UgaXQgaXMgYXNzdW1lZCB0aGF0IHRoZSBJQ0Ug YWdlbnQga25vd3MgdGhhdCBpdCB3aWxsIG5ldmVyIGdldCBhIHJlbGF5IGNhbmRpZGF0ZSBmb3Ig dmlkZW8gKG9yLCBpZiBpdCBnZXRzIG9uZSwgaXQgd2lsbCBub3QgdHJpY2tsZSBpdCkuDQoNCj4+ IEFnYWluLCBJIGRvbid0IHNlZSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHN0cmVhbXMgYW5kIGNv bXBvbmVudHMgaGVyZS4gWW91IGNvdWxkIGFzayB0aGUgc2FtZSBxdWVzdGlvbiBvZiBjb21wb25l bnRzOiAiSG93DQo+PiBkb2VzIHRoZSBhZ2VudCBrbm93IGl0IHdpbGwgZ2V0ICdSVFAgc3JmbHgn IGlmIGl0IGdldHMgJ1JUQ1Agc3JmbHgnPyINCj4NCj4gWW91IGRvbid0IGtub3cgLSB1bmxlc3Mg dHJpY2tsZSBtYW5kYXRlcyBpdCAoNTI0NWJpcyBkb2VzIG5vdCBtYW5kYXRlIGl0LCBhcyBmYXIg YXMgSSBrbm93KS4NCj4NCj4+IFRoZSBJQ0UgYWdlbnQgZG9lc24ndCBrbm93IHdoYXQgY2FuZGlk YXRlcyBpdCdzIGF0dGVtcHRpbmcgdG8gZ2F0aGVyPyBPciBpdCBkb2Vzbid0IGtub3cgd2hldGhl ciB0aGUgcGVuZGluZyBTVFVOIHRyYW5zYWN0aW9uIHdpbGwgZmFpbD8NCg0KVGhlIElDRSBhZ2Vu dCBkb2VzIG5vdCBrbm93IHdoYXQgY2FuZGlkYXRlcyBpdCB3aWxsIGV2ZW50dWFsbHkgZ2V0LiBN YXliZSBpdCBjYW4gaW5kaWNhdGUgKHVzaW5nIGFuIEFQSSBvciBjb25maWd1cmF0aW9uKSB3aGF0 IGl0IHdhbnRzLCBtYXliZSBpdCB3aWxsIGdldCB3aGF0ZXZlciBpcyBhdmFpbGFibGUsIGJ1dCBJ IGRvbid0IHRoaW5rIHdlIGNhbiBhc3N1bWUgdGhhdCBpdCBrbm93cyB3aGF0IGl0IHdpbGwgZXZl bnR1YWxseSBnZXQuIA0KDQo+PllvdSB3b3VsZCBoYXZlIHRvIGV4cGxhaW4gd2hhdCAic3RyZWFt IG9yZGVyIiByZWFsbHkgbWVhbnMuDQo+DQo+SXQgd291bGQgYmUgdGhlIG9yZGVyIG9mIHRoZSBy b3dzIGluIHNlY3Rpb24gOC4xOyBvcmRlcmVkIGZpcnN0IGJ5IHN0cmVhbSB0aGVuIGJ5IGNvbXBv bmVudC7CoA0KDQpJZiB5b3UgYXJlIHVzaW5nIFNEUCwgdGhlIGluaXRpYWwgb2ZmZXIgd2lsbCBv YnZpb3VzbHkgb3JkZXIgdGhlIHN0cmVhbXMgKG0tIGxpbmVzKSBpbiBhIGNlcnRhaW4gb3JkZXIu IA0KDQpCdXQsIHdoZW4geW91IHRoZW4gc3RhcnQgdG8gdHJpY2tsZSwgSSBkb24ndCB1bmRlcnN0 YW5kIHdoYXQgInN0cmVhbSBvcmRlciIgbWVhbnMuIEFzc3VtZSB0aGUgYWdlbnQgZ2V0cyBjYW5k aWRhdGVzIGZvciBvbmx5IG9uZSBzdHJlYW0uIEhvdyBkbyB5b3UgdHJpY2tsZSB0aG9zZSBpbiAi c3RyZWFtIG9yZGVyIj8gQWdhaW4sIGlmIHlvdSBrbm93IHRoYXQgeW91IGFyZSBnb2luZyB0byBn ZXQgdGhlIHNhbWUgdHlwZSBvZiBjYW5kaWRhdGVzIGFsc28gZm9yIHRoZSAicHJldmlvdXMiIHN0 cmVhbXMsIHlvdSBjYW4gd2FpdC4gQnV0IGlmIHlvdSBkb24ndCBrbm93PyBIb3cgbG9uZyB3aWxs IHlvdSB3YWl0IHVudGlsIHlvdSB0cmlja2xlPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN Cg0KDQpPbiBUaHUsIE1hciAxLCAyMDE4IGF0IDEyOjU2IFBNLCBQZXRlciBTYWludC1BbmRyZSA8 c3RwZXRlckBtb3ppbGxhLmNvbT4gd3JvdGU6DQpPbiAzLzEvMTggMTI6MTkgUE0sIENocmlzdGVy IEhvbG1iZXJnIHdyb3RlOg0KPiBIaSwNCj4NCj4+PiBBc3N1bWUgdGhlIGFnZW50IGdldHMgInN0 cmVhbSAxIGhvc3QiLCAic3RyZWFtIDIgaG9zdCIgYW5kICJzdHJlYW0gMiBzcmZseCIuIFNob3Vs ZCBpdCB3YWl0IGZvciAic3RyZWFtIDEgc3JmbHgiIGJlZm9yZSB0cmlja2xpbmcgInN0cmVhbSAy IHNyZmx4Ij8NCj4+DQo+PiBUaGF0IHdhcyBteSBpbnRlcnByZXRhdGlvbi4NCj4+IMKgDQo+Pj4g SG93IGRvZXMgdGhlIGFnZW50IGV2ZW4ga25vdyB0aGF0IGl0IHdpbGwgZ2V0ICJzdHJlYW0gMSBz cmZseCI/DQo+Pg0KPj4gSWYgb25lIGNhbmRpZGF0ZSBvZiBhIHBhcnRpY3VsYXIgZm91bmRhdGlv biB3YXMgZ2F0aGVyZWQgc3VjY2Vzc2Z1bGx5LCB0aGUgYWdlbnQgY2FuIGV4cGVjdCB0aGUgcmVz dCBvZiB0aGUNCj4+IGNhbmRpZGF0ZXMgd2l0aCB0aGF0IGZvdW5kYXRpb24gdG8gYmUgZ2F0aGVy ZWQgc3VjY2Vzc2Z1bGx5IGFzIHdlbGwuDQo+DQo+IEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYW55 IHJ1bGUgc2F5aW5nIHRoYXQsIGZvciBhIGdpdmVuIGZvdW5kYXRpb24sIHlvdSB3aWxsIGdldCBj YW5kaWRhdGVzIGZvciBhbGwgc3RyZWFtcyAoc2VlIGV4YW1wbGUgaW4gc2VjdGlvbiA2LjEuMi42 LiBvZiA1MjQ1YmlzKS4gRm9yIGV4YW1wbGUsIHBlcmhhcHMgeW91IGdhdGhlciByZWxheSBjYW5k aWRhdGVzIG9ubHkgZm9yIHRoZSBhdWRpbyBzdHJlYW1zLCBiZWNhdXNlIHlvdSB3YW50IHRvIHVz ZSBhIHJlbGF5IGZvciB5b3VyIHZpZGVvICh5b3UgcmF0aGVyIGRvbid0IHVzZSB2aWRlbywgaWYg aXQgd29uJ3Qgd29yayB3aXRob3V0IGEgcmVsYXkpLg0KPg0KPj4gQWdhaW4sIEkgZG9uJ3Qgc2Vl IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gc3RyZWFtcyBhbmQgY29tcG9uZW50cyBoZXJlLiBZb3Ug Y291bGQgYXNrIHRoZSBzYW1lIHF1ZXN0aW9uIG9mIGNvbXBvbmVudHM6ICJIb3cNCj4+IGRvZXMg dGhlIGFnZW50IGtub3cgaXQgd2lsbCBnZXQgJ1JUUCBzcmZseCcgaWYgaXQgZ2V0cyAnUlRDUCBz cmZseCc/Ig0KPg0KPiBZb3UgZG9uJ3Qga25vdyAtIHVubGVzcyB0cmlja2xlIG1hbmRhdGVzIGl0 ICg1MjQ1YmlzIGRvZXMgbm90IG1hbmRhdGUgaXQsIGFzIGZhciBhcyBJIGtub3cpLg0KPg0KPj4+ IE15IHBvaW50IGlzIHRoYXQgaXMgaWYgeW91IGhhdmUgdGhlIGZvbGxvd2luZyB0ZXh0Og0KPj4+ DQo+Pj4gwqAgwqAiYWNoaWV2ZSB0aGlzLCB3aGVuIHRyaWNrbGluZyBjYW5kaWRhdGVzLCBhZ2Vu dHMgTVVTVCByZXNwZWN0IHRoZQ0KPj4+IMKgIMKgb3JkZXIgaW4gd2hpY2ggdGhlIGNvbXBvbmVu dHMgYW5kIHN0cmVhbXMgYXBwZWFyIChpbXBsaWNpdGx5IG9yDQo+Pj4gwqAgwqBleHBsaWNpdGx5 KSBhcyB0aGV5IGhhdmUgYmVlbiBuZWdvdGlhdGVkIGJ5IG1lYW5zIG9mIHRoZSByZWxldmFudA0K Pj4+IMKgY2FuZGlkYXRlIGluZm9ybWF0aW9uLiINCj4+Pg0KPj4+IC4uLnlvdSBzaG91bGQgZXhw bGFpbiBob3cgaXQgaW1wYWN0cyBzdHJlYW1zLiBDdXJyZW50bHkgdGhlIHRleHQgb25seSB0YWxr cyBhYm91dCBjb21wb25lbnRzLg0KPj4NCj4+IEFoLCBzbyBpcyB0aGUgaXNzdWUgdGhhdCB0aGUg bmV4dCBzZW50ZW5jZSBvbmx5IG1lbnRpb25zIGNvbXBvbmVudHM/DQo+IMKgDQo+IENvcnJlY3Qu DQo+DQo+PiDCoCDCoFRoZXJlZm9yZSBjYW5kaWRhdGVzIGZvciBhIGdpdmVuIGNvbXBvbmVudA0K Pj4gwqAgwqBNVVNUIE5PVCBiZSBjb252ZXllZCBwcmlvciB0byBjYW5kaWRhdGVzIGZvciBhIGNv bXBvbmVudCB3aXRoIGEgbG93ZXINCj4+IMKgIMKgSUQgbnVtYmVyIHdpdGhpbiB0aGUgc2FtZSBm b3VuZGF0aW9uLg0KPj4NCj4+IFN0cmVhbXMgYXJlIG1lbnRpb25lZCBmdXJ0aGVyIGJlbG93Og0K Pj4NCj4+wqAgwqBTaW1pbGFyIGNvbnNpZGVyYXRpb25zIGFwcGx5IGF0IHRoZSBsZXZlbCBvZiBt ZWRpYSBzdHJlYW1zIGluDQo+PsKgIMKgYWRkaXRpb24gdG8gZm91bmRhdGlvbnM7IHRoaXMgaXMg Y292ZXJlZCBieSB0aGUgcmVxdWlyZW1lbnQgdG8gYWx3YXlzwqANCj4+wqAgwqBzdGFydCB1bmZy ZWV6aW5nIGNhbmRpZGF0ZXMgc3RhcnRpbmcgZnJvbSB0aGUgZmlyc3QgbWVkaWEgc3RyZWFtIGFz DQo+PsKgIMKgZGVzY3JpYmVkIHVuZGVyIFNlY3Rpb24gNS4yLg0KPj4NCj4+IEJ1dCB0aGlzIGFw cGVhcnMgb3V0IG9mIGRhdGUuIFNlY3Rpb24gNS4yIHVzZWQgdG8gc2F5Og0KPj4NCj4+IElmIFt0 aGUgZmlyc3RdDQo+PiBjaGVja2xpc3QgaXMgc3RpbGwgZW1wdHkgaG93ZXZlciwgYWdlbnRzIHdp bGwgaG9sZCBvZmYgZnVydGhlcg0KPj4gcHJvY2Vzc2luZyB1bnRpbCB0aGlzIGlzIG5vIGxvbmdl ciB0aGUgY2FzZS4NCj4+DQo+PiAuLi4uIFdoaWNoIGVuc3VyZXMgdGhlIGZpcnN0IHN0cmVhbSBp cyBhbHdheXMgdW5mcm96ZW4gZmlyc3QuIEJ1dCBub3cgaXQgc2F5czoNCj4+DQo+PiDCoCDCoElm IHRoYXQgZmlyc3QgY29tcG9uZW50IG9mIHRoZSBmaXJzdCBtZWRpYSBzdHJlYW0gZG9lcw0KPj4g wqAgwqBub3QgY29udGFpbiBjYW5kaWRhdGVzIGZvciBvbmUgb3IgbW9yZSBvZiB0aGUgY3VycmVu dGx5IGtub3duIHBhaXINCj4+IMKgIMKgZm91bmRhdGlvbnMsIGFuZCBpZiBjYW5kaWRhdGUgcGFp cnMgYWxyZWFkeSBleGlzdCBmb3IgdGhhdCBmb3VuZGF0aW9uDQo+PiDCoCDCoGluIG9uZSBvZiB0 aGUgZm9sbG93aW5nIGNvbXBvbmVudHMgb3IgbWVkaWEgc3RyZWFtcywgdGhlbiB0aGUgYWdlbnQN Cj4+IMKgIMKgdW5mcmVlemVzIHRoZSBmaXJzdCBvZiB0aG9zZSBjYW5kaWRhdGUgcGFpcnMuDQo+ Pg0KPj4gTWVhbmluZyBzZWN0aW9uIDUuMiBubyBsb25nZXIgZW5mb3JjZXMgdGhlIHN0cmVhbSBv cmRlcmluZyByZXF1aXJlbWVudC4NCj4+DQo+PiBTbywgSSdkIHN1Z2dlc3Q6DQo+PiDigKIgUmVt b3ZpbmcgdGhlIG91dGRhdGVkICJTaW1pbGFyIGNvbnNpZGVyYXRpb25zIGFwcGx5Li4uIiBwYXJh Z3JhcGguDQo+PiDigKIgVXBkYXRpbmcgdGhlIHJlc3Qgb2YgU2VjdGlvbiAxNiB0byBtYWtlIGl0 IGNsZWFyIHRoYXQgY2FuZGlkYXRlcyBzaG91bGQgYmUgdHJpY2tsZWQgaW4gYm90aCBzdHJlYW0g YW5kIGNvbXBvbmVudCBvcmRlci4NCj4NCj4gWW91IHdvdWxkIGhhdmUgdG8gZXhwbGFpbiB3aGF0 ICJzdHJlYW0gb3JkZXIiIHJlYWxseSBtZWFucy4gQmVjYXVzZSwgaXQgZG9lcyBub3QgbWVhbiB0 aGF0IHlvdSBmaXJzdCB0cmlja2xlIGFsbCBjYW5kaWRhdGVzIGZvciBzdHJlYW0gMSwgdGhlbiBh bGwgY2FuZGlkYXRlcyBmb3Igc3RyZWFtIDIsIGV0Yy4NCj4NCj4gQXMgSSBzYWlkIGFib3ZlLCB5 b3Ugc2VlbSB0byBzdWdnZXN0IHRoYXQsIGZvciBlYWNoIHN0cmVhbSBhbmQgZWFjaCBmb3VuZGF0 aW9uLCB0aGVyZSB3aWxsIGJlIHRoZSBzYW1lIHNldCBvZiBjYW5kaWRhdGVzLiBUaGVyZSBpcyBu byBzdWNoIHJlcXVpcmVtZW50IGFueXdoZXJlLCBhcyBmYXIgYXMgSSBrbm93Lg0KSSBzdWdnZXN0 IHRoYXQgd2UgcmVtb3ZlIGFsbCByZWZlcmVuY2VzIHRvIHRoZSBwb29ybHkgZGVmaW5lZCBjb25j ZXB0IG9mDQoic3RyZWFtIG9yZGVyIi4gQnV0IGlmIEVtaWwgdGhpbmtzIHRoaXMgaXMgY3J1Y2lh bCB0aGVuIEknbGwgZGVmZXIgdG8NCmhpbS4gKEkgZGlkIGNvbm5lY3Qgd2l0aCBoaW0gb2ZmbGlz dCBhbmQgaGUgcHJvbWlzZXMgdG8gd2VpZ2ggaW4gc29vbi4pDQoNClBldGVyDQoNCg== From nobody Thu Mar 1 13:44:33 2018 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 CA3CA12FAC2 for ; Thu, 1 Mar 2018 13:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 UX21lx5wpgSv for ; Thu, 1 Mar 2018 13:44:24 -0800 (PST) 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 EE5B312FAC6 for ; Thu, 1 Mar 2018 13:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519940662; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WoGQW7ZC3i5IURIgG43+xwVJ3C+sKYmb7akfbD/87DI=; b=Chq8Z/OlUoap4REU5s82VqQy23VX0O2Ig4KXOf71jFuTEe71n2K1eVu49rcn24JO SNbu3Z3wCKAldDNs2XmbXY3sef0G0XkWX8pWATYVrkvIZ+INx9NLvN8DQRk1IgQA J6XW7HLPSaK0JxBHjAvEHLQHoRPfIx+vCiHeyFIugOc=; X-AuditID: c1b4fb30-399ff70000004778-c4-5a9874364b24 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 76.01.18296.634789A5; Thu, 1 Mar 2018 22:44:22 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Thu, 1 Mar 2018 22:44:21 +0100 From: Christer Holmberg To: =?utf-8?B?QXJpIEtlcsOkbmVu?= , Adam Roach CC: The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , Peter Thatcher , "ice-chairs@ietf.org" , "ice@ietf.org" Thread-Topic: Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT) Thread-Index: AQHTqvWUaf7qEwtdZ0KrkPtHSF2TaKOvQY5ggANPHoCAANh/EIAIZrGAgAABLICAACVy4A== Date: Thu, 1 Mar 2018 21:44:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1B99E3@ESESSMB109.ericsson.se> References: <151920498287.9799.11602055137725027840.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C17B247@ESESSMB109.ericsson.se> <21c57c7c-6ba7-25d0-31a1-8cafbd42f3cd@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6C192F5D@ESESSMB109.ericsson.se> <2661ea85-ec00-244b-1817-78e49d3432b1@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbHdUtesZEaUwdk3AhZ7/i5it5h/8jqz xcVZk9ksvl2otZjxZyKzxbXlr1kd2DwWbCr1WLLkJ5PHrJ1PWAKYo7hsUlJzMstSi/TtErgy rvc0shT0KFWc/naLqYFxjmIXIyeHhICJxKXDP1m7GLk4hAQOM0qsv3KPHSQhJLCIUaLviksX IwcHm4CFRPc/bZCwiECMRO/86Ywg9cwC9xglZh5pZAZJCAvES7w5N58doihBoq/3KAtIr4hA mMTlb1UgJouAisTaVTIgFbwCvhIPNx9gglj7lUni+pWPjCA1nAIOEjPbwKYwCohJfD+1hgnE ZhYQl7j1ZD4TxMkCEkv2nGeGsEUlXj7+xwphK0ksn7aFHWQMs4CmxPpd+hCtihJTuh+yQ6wV lDg58wnLBEbRWUimzkLomIWkYxaSjgWMLKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAqPp 4JbfBjsYXz53PMQowMGoxMP7KmZGlBBrYllxZe4hRgkOZiUR3tPbp0UJ8aYkVlalFuXHF5Xm pBYfYpTmYFES5z3pyRslJJCeWJKanZpakFoEk2Xi4JRqYOxPeur+yNG4M9nRoLmKw/TN/wPm JgdeOTn+P67M80L8t5Ulxxnvst3CrqnLnxdWHr7+TbvQMLXizOqf+g+bJ12Yryn1YufpnYrr pPdd6Vd5+mT+5mJL5smVIn0zdx5ra3Wv+f7kzo20iXIp22t28xUxbDXUyGwNb8u//0bSdxZr R3lgU1YMoxJLcUaioRZzUXEiAKdMTHWiAgAA Archived-At: Subject: Re: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT) 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, 01 Mar 2018 21:44:31 -0000 SGksDQoNCj4+Pj4+PiBUaGUgZG9jdW1lbnQgY3VycmVudGx5IGFwcGVhcnMgdG8gY29udGFpbiBu b3JtYXRpdmUgc3RhdGVtZW50cyB0aGF0LCB3aGlsZSBub3QgbGl0ZXJhbGx5IGNvbnRyYWRpY3Rv cnksIGNlcnRhaW5seSBwb2ludCBpbXBsZW1lbnRvcnMgaW4gY29uZmxpY3RpbmcgZGlyZWN0aW9u cy4NCj4+Pj4+PiDCpzUuMS4xLjEgc2F5czoNCj4+Pj4+PiANCj4+Pj4+PiAgIG8gIEhvc3QgY2Fu ZGlkYXRlcyBjb3JyZXNwb25kaW5nIHRvIElQdjYgbGluay1sb2NhbCBhZGRyZXNzZXMgTVVTVA0K Pj4+Pj4+ICAgICAgTk9UIGJlIGdhdGhlcmVkLg0KPj4+Pj4+IA0KPj4+Pj4+IEZ1cnRoZXIgZG93 biwgwqc2LjEuMi4yIHNheXM6DQo+Pj4+Pj4gDQo+Pj4+Pj4gICBUbyBrZWVwIHRoZSBhbW91bnQg b2YgcmVzdWx0aW5nIGNhbmRpZGF0ZSBwYWlycyAgcmVhc29uYWJsZSBhbmQgDQo+Pj4+Pj4gdG8g YXZvaWQgY2FuZGlkYXRlIHBhaXJzIHRoYXQgYXJlIGhpZ2hseSB1bmxpa2VseSB0byAgd29yaywg SVB2NiANCj4+Pj4+PiBsaW5rLWxvY2FsIGFkZHJlc3NlcyBbUkZDNDI5MV0gTVVTVCBOT1QgYmUg cGFpcmVkIHdpdGggIG90aGVyIHRoYW4gDQo+Pj4+Pj4gbGluay1sb2NhbCBhZGRyZXNzZXMuDQo+ Pj4+Pj4gDQo+Pj4+Pj4gVGhpcyBzZWNvbmQgcGFzc2FnZSBpcyBub25zZW5zaWNhbCBpZiBJUHY2 IGxpbmsgbG9jYWwgYWRkcmVzc2VzIA0KPj4+Pj4+IE1VU1QgTk9UIGJlIGdhdGhlcmVkLiBQbGVh c2UgcmVtb3ZlIG9yIGFtZW5kIG9uZSBvZiB0aGVzZSBub3JtYXRpdmUgc3RhdGVtZW50cy4gSWYg dGhlIGZpcnN0IHN0YXRlbWVudCBpcyByZXRhaW5lZCwgcGxlYXNlIGFkZCByYXRpb25hbGUuDQo+ Pj4+PiBCZW4gaGFkIHRoZSBzYW1lIGNvbW1lbnQuIE15IHN1Z2dlc3Rpb24gd2FzIHRvIHJlbW92 ZSB0aGUgdGV4dCBpbiA2LjEuMi4yLg0KPj4+Pj4gDQo+Pj4+PiBJIGd1ZXNzIHRoZSByYXRpb25h bGUgaXMgc2luY2UgYSBsb2NhbC1saW5rIGFkZHJlc3MgbWF5IG5vdCBiZSB2YWxpZCBmb3IgY29t bXVuaWNhdGluZyB3aXRoIHRoZSBwZWVyLg0KPj4+PiBXZWxsLCBpdCBpcyBpZiB0aGV5J3JlIG9u IHRoZSBzYW1lIGxpbmsuIEZvciBleGFtcGxlLCB3aGVuIEkgc3NoIA0KPj4+PiBmcm9tIG9uZSBt YWNoaW5lIGluIG15IGhvdXNlIHRvIGFub3RoZXIsIGl0IGdlbmVyYWxseSB1c2VzIGFuDQo+Pj4+ IElQdjYgbGluay1sb2NhbCBhZGRyZXNzLiBXZWJSVEMgaXMgZXhwbGljaXRseSBleHBlY3RlZCB0 byB1c2UgdGhpcyBvcHRpbWFsIHBhdGggaWYgaXQgZXhpc3RzLiBJIHRoaW5rIHRoZSBmaXggdGhh dCBBcmkgcHJvcG9zZXMgbWFrZXMgbW9yZSBzZW5zZS4NCj4+PiBJIGFncmVlLiBJIHdpbGwgZml4 IGFzIHN1Z2dlc3RlZCBieSBBcmkuDQo+PiANCj4+IEkgcmV2aWV3ZWQgdGhlIHRleHQgaW4gdGhl IC0xOCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCwgYW5kIGl0IGRvZXNuJ3Qgc2VlbSB0byBjb3Jy ZWN0bHkgcmVmbGVjdCB0aGUgc3VnZ2VzdGlvbiAtLSBvciBhdCBsZWFzdCwgaXQgaXMgYW1iaWd1 b3VzLiBXaGF0IGlzIGluIHRoZXJlIG5vdyBpczoNCj4+IA0KPj4+ICAgIG8gIElmIG9uZSBvciBt b3JlIGhvc3QgY2FuZGlkYXRlcyBjb3JyZXNwb25kaW5nIHRvIGFuIElQdjYgYWRkcmVzcw0KPj4+ ICAgICAgIGdlbmVyYXRlZCB1c2luZyBhIG1lY2hhbmlzbSB0aGF0IHByZXZlbnRzIGxvY2F0aW9u IHRyYWNraW5nDQo+Pj4gICAgICAgW1JGQzc3MjFdIGFyZSBnYXRoZXJlZCwgaG9zdCBjYW5kaWRh dGVzIGNvcnJlc3BvbmRpbmcgdG8gSVB2Ng0KPj4+ICAgICAgIGFkZHJlc3NlcyB0aGF0IGRvIGFs bG93IGxvY2F0aW9uIHRyYWNraW5nIHRoYXQgYXJlIGNvbmZpZ3VyZWQgb24NCj4+PiAgICAgICB0 aGUgc2FtZSBpbnRlcmZhY2UgYW5kIGFyZSBwYXJ0IG9mIHRoZSBzYW1lIG5ldHdvcmsgcHJlZml4 IE1VU1QNCj4+PiAgICAgICBOT1QgYmUgZ2F0aGVyZWQ7IGFuZCBob3N0IGNhbmRpZGF0ZXMgY29y cmVzcG9uZGluZyB0byBJUHY2IGxpbmstDQo+Pj4gICAgICAgbG9jYWwgYWRkcmVzc2VzIFtSRkM0 MjkxXSBNVVNUIE5PVCBiZSBnYXRoZXJlZC4NCj4+IA0KPj4gVGhlIHByb2JsZW1hdGljIHBocmFz ZSBzdGlsbCBhcHBlYXJzOyBpdCdzIGp1c3QgYWZ0ZXIgYSBzZW1pY29sb24gbm93LiBJdCBzZWVt cyBoaWdobHkgbGlrZWx5IHRoYXQgaW1wZWxlbWVudG9ycyB3aWxsIHJlYWQgdGhlIHBocmFzZSBh cyBiZWluZyB1bnF1YWxpZmllZCByYXRoZXIgdGhhbiBvbmx5ID5hcHBseWluZyB3aGVuIFJGQyA3 NzIxIGFkZHJlc3NlcyBhcmUgdXNlZC4gUGVyaGFwczoNCj4+IA0KPj4gDQo+PiAgICBvICBJZiBv bmUgb3IgbW9yZSBob3N0IGNhbmRpZGF0ZXMgY29ycmVzcG9uZGluZyB0byBhbiBJUHY2IGFkZHJl c3MNCj4+ICAgICAgIGdlbmVyYXRlZCB1c2luZyBhIG1lY2hhbmlzbSB0aGF0IHByZXZlbnRzIGxv Y2F0aW9uIHRyYWNraW5nDQo+PiAgICAgICBbUkZDNzcyMV0gYXJlIGdhdGhlcmVkLCBob3N0IGNh bmRpZGF0ZXMgY29ycmVzcG9uZGluZyB0byBJUHY2DQo+PiAgICAgICBhZGRyZXNzZXMgdGhhdCBk byBhbGxvdyBsb2NhdGlvbiB0cmFja2luZyB0aGF0IGFyZSBjb25maWd1cmVkIG9uDQo+PiAgICAg ICB0aGUgc2FtZSBpbnRlcmZhY2UgYW5kIGFyZSBwYXJ0IG9mIHRoZSBzYW1lIG5ldHdvcmsgcHJl Zml4IE1VU1QNCj4+ICAgICAgIE5PVCBiZSBnYXRoZXJlZC4gU2ltaWxhcmx5LCB3aGVuIGhvc3Qg Y2FuZGlkYXRlcyBjb3JyZXNwb25kaW5nDQo+PiAgICAgICB0byBhbiBJUHY2IGFkZHJlc3MgZ2Vu ZXJhdGVkIHVzaW5nIGEgbWVjaGFuaXNtIHRoYXQgcHJldmVudHMNCj4+ICAgICAgIGxvY2F0aW9u IHRyYWNraW5nIGFyZSBnYXRoZXJlZCwgdGhlbiBob3N0IGNhbmRpZGF0ZXMgY29ycmVzcG9uZGlu Zw0KPj4gICAgICAgdG8gSVB2NiBsaW5rLWxvY2FsIGFkZHJlc3NlcyBbUkZDNDI5MV0gTVVTVCBO T1QgYmUgZ2F0aGVyZWQuDQo+DQo+IFRoaXMgbG9va3MgZ29vZCB0byBtZS4gVGhhbmtzIQ0KDQpJ IGNyZWF0ZWQgYSBwdWxsIHJlcXVlc3QgKGFsc28gY29udGFpbnMgc29tZSBvdGhlciBlZGl0b3Jp YWwgbml0cywgYmFzZWQgb24gY29tbWVudHMgZnJvbSBBcmkpOg0KDQpodHRwczovL2dpdGh1Yi5j b20vaWNlLXdnL3JmYzUyNDViaXMvcHVsbC82Mg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K From nobody Thu Mar 1 14:54:42 2018 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 C5F9B126CD6 for ; Thu, 1 Mar 2018 14:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 PQrdaqzab9ZZ for ; Thu, 1 Mar 2018 14:54:38 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 E513F126C0F for ; Thu, 1 Mar 2018 14:54:37 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id d1so4050707ual.13 for ; Thu, 01 Mar 2018 14:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yzl711bxyA5leiFu5WczBmS/C1I6mqaCjRm0ltf0RMA=; b=c2vVVKteRdDVGFM0xsrE7jOMocG0Yv79PZp3Hfp4dKtYD9Ri4IZkh5/SjDMsJjwakJ MioD4eY/tnc7CPJQ6JoPtuFCZUGmCf+LS42kl6mi3zjzf1vgk24d6O5lUpdvLh34tViD 0QB5a6iQVK5JDnqlczlNVZSl5SLGUTF1eaVsYRi2PlmpR9i6TI7PfNQq0d5E0yZSC9sU lrJZsnnMmtq9BSGQ1/m8fF2zaIXUhm2SbP2r/Saq37kyiNBsR9RN+clY9XbxLbj/H8vB SugLvFz0bzLE7y/GIUEq3g9/T0r34tXxYvtN70OA2HJP3OUxZnzT/vgp4m5rNIrn/iWY kclA== 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=Yzl711bxyA5leiFu5WczBmS/C1I6mqaCjRm0ltf0RMA=; b=C+OJGfsb4FuJbloK1CVq3Mbchy14PSnsicnAJviGcDzXAp9yRo1qSrBFRphA1ov4sH 82yhhDbr9k8tip56PLlJoEZNZGu9/4HNHuPiWa/O/HGcNADvnrufK3RAIGVTqjfkWh3A ZdEeUfSXwreqh0nRqMVDWF65wTyhC4pBL0SuJyDlxNUCo+GKFa8hiXbjwb0+iXF+rb4v zkk8hobrsUzIuuLWAiEwULZ9p+t+gcl8PT1gq2h7qrxh57PUdHFF6ivVKferi0Y0PEBe L4mgaAWXgpoovdIvEf3G/iRcYBVRjz72vOcbvwo6agMGDEXr0O3CsTJu4PHN/Ui/e41r KwTg== X-Gm-Message-State: APf1xPChOEdYFdl/d4ok307zvYAcjo7sZYlg+A5ZF+6rdNa5swwWcO9B NIJhFIKo2XiqDT0AF+9ZGRNazbG4v1cRxyEVKqRHiA== X-Google-Smtp-Source: AG47ELtN19tgA5EaWbWBHHwSQ+iyhB02AYia9JcecuhJhtDcs3ASXMZA4pSxlJUeQr/uG1KF86tIGMCtIySz1hYz5x8= X-Received: by 10.159.62.129 with SMTP id x1mr2364594uai.175.1519944876609; Thu, 01 Mar 2018 14:54:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.114.66 with HTTP; Thu, 1 Mar 2018 14:54:35 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1B9921@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C1B8FEE@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1B9583@ESESSMB109.ericsson.se> <70af5888-1927-1f62-ba3f-8d6fd4614c87@mozilla.com> <7594FB04B1934943A5C02806D1A2204B6C1B9921@ESESSMB109.ericsson.se> From: Taylor Brandstetter Date: Thu, 1 Mar 2018 14:54:35 -0800 Message-ID: To: Christer Holmberg Cc: Peter Saint-Andre , Peter Saint-Andre , "ice@ietf.org" Content-Type: multipart/alternative; boundary="f403043e8038734723056661be93" Archived-At: Subject: Re: [Ice] Trickle: What is Section 16 about? 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, 01 Mar 2018 22:54:41 -0000 --f403043e8038734723056661be93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > The ICE agent does not know what candidates it will eventually get. > I think this is the root of our misunderstanding. But can you clarify, do you mean that the ICE agent doesn't know what candidates it will *attempt* = to gather? Or that it doesn't know whether a pending STUN transaction will fail? If you're talking about the former case, then I think we have a different concept of what the "ICE agent" is. I interpreted the ICE agent as being responsible for candidate gathering (including deciding which candidates it will attempt to gather). If you're talking about the latter case, then I agree there's a question of "how long do I wait for the pending STUN transaction before giving up and trickling the candidates I have?" Which I assumed would be an implementation choice. On Thu, Mar 1, 2018 at 1:40 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >> For example, perhaps you gather relay candidates only for the audio > streams, because you don't want to use > >> a relay for your video (you rather don't use video, if it won't work > without a relay). > > > > I agree there's nothing preventing this. In this case the ICE agent > would be able to trickle the audio relay candidate immediately. > > Yes, but in this case it is assumed that the ICE agent knows that it will > never get a relay candidate for video (or, if it gets one, it will not > trickle it). > > >> Again, I don't see the difference between streams and components here. > You could ask the same question of components: "How > >> does the agent know it will get 'RTP srflx' if it gets 'RTCP srflx'?" > > > > You don't know - unless trickle mandates it (5245bis does not mandate > it, as far as I know). > > > >> The ICE agent doesn't know what candidates it's attempting to gather? > Or it doesn't know whether the pending STUN transaction will fail? > > The ICE agent does not know what candidates it will eventually get. Maybe > it can indicate (using an API or configuration) what it wants, maybe it > will get whatever is available, but I don't think we can assume that it > knows what it will eventually get. > > >>You would have to explain what "stream order" really means. > > > >It would be the order of the rows in section 8.1; ordered first by strea= m > then by component. > > If you are using SDP, the initial offer will obviously order the streams > (m- lines) in a certain order. > > But, when you then start to trickle, I don't understand what "stream > order" means. Assume the agent gets candidates for only one stream. How d= o > you trickle those in "stream order"? Again, if you know that you are goin= g > to get the same type of candidates also for the "previous" streams, you c= an > wait. But if you don't know? How long will you wait until you trickle? > > Regards, > > Christer > > > > > On Thu, Mar 1, 2018 at 12:56 PM, Peter Saint-Andre > wrote: > On 3/1/18 12:19 PM, Christer Holmberg wrote: > > Hi, > > > >>> Assume the agent gets "stream 1 host", "stream 2 host" and "stream 2 > srflx". Should it wait for "stream 1 srflx" before trickling "stream 2 > srflx"? > >> > >> That was my interpretation. > >> > >>> How does the agent even know that it will get "stream 1 srflx"? > >> > >> If one candidate of a particular foundation was gathered successfully, > the agent can expect the rest of the > >> candidates with that foundation to be gathered successfully as well. > > > > I don't think there is any rule saying that, for a given foundation, yo= u > will get candidates for all streams (see example in section 6.1.2.6. of > 5245bis). For example, perhaps you gather relay candidates only for the > audio streams, because you want to use a relay for your video (you rather > don't use video, if it won't work without a relay). > > > >> Again, I don't see the difference between streams and components here. > You could ask the same question of components: "How > >> does the agent know it will get 'RTP srflx' if it gets 'RTCP srflx'?" > > > > You don't know - unless trickle mandates it (5245bis does not mandate > it, as far as I know). > > > >>> My point is that is if you have the following text: > >>> > >>> "achieve this, when trickling candidates, agents MUST respect the > >>> order in which the components and streams appear (implicitly or > >>> explicitly) as they have been negotiated by means of the relevant > >>> candidate information." > >>> > >>> ...you should explain how it impacts streams. Currently the text only > talks about components. > >> > >> Ah, so is the issue that the next sentence only mentions components? > > > > Correct. > > > >> Therefore candidates for a given component > >> MUST NOT be conveyed prior to candidates for a component with a low= er > >> ID number within the same foundation. > >> > >> Streams are mentioned further below: > >> > >> Similar considerations apply at the level of media streams in > >> addition to foundations; this is covered by the requirement to alway= s > >> start unfreezing candidates starting from the first media stream as > >> described under Section 5.2. > >> > >> But this appears out of date. Section 5.2 used to say: > >> > >> If [the first] > >> checklist is still empty however, agents will hold off further > >> processing until this is no longer the case. > >> > >> .... Which ensures the first stream is always unfrozen first. But now > it says: > >> > >> If that first component of the first media stream does > >> not contain candidates for one or more of the currently known pair > >> foundations, and if candidate pairs already exist for that foundati= on > >> in one of the following components or media streams, then the agent > >> unfreezes the first of those candidate pairs. > >> > >> Meaning section 5.2 no longer enforces the stream ordering requirement= . > >> > >> So, I'd suggest: > >> =E2=80=A2 Removing the outdated "Similar considerations apply..." para= graph. > >> =E2=80=A2 Updating the rest of Section 16 to make it clear that candid= ates > should be trickled in both stream and component order. > > > > You would have to explain what "stream order" really means. Because, it > does not mean that you first trickle all candidates for stream 1, then al= l > candidates for stream 2, etc. > > > > As I said above, you seem to suggest that, for each stream and each > foundation, there will be the same set of candidates. There is no such > requirement anywhere, as far as I know. > I suggest that we remove all references to the poorly defined concept of > "stream order". But if Emil thinks this is crucial then I'll defer to > him. (I did connect with him offlist and he promises to weigh in soon.) > > Peter > > --f403043e8038734723056661be93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The ICE agent does not know what candidates it will even= tually get.

I think this is the = root of our misunderstanding. But can you clarify, do you mean that the ICE= agent doesn't know what candidates it will attempt=C2=A0to gath= er? Or that it doesn't know whether a pending STUN transaction will fai= l?

If you're talking about the former case, th= en I think we have a different concept of what the "ICE agent" is= . I interpreted the ICE agent as being responsible for candidate gathering = (including deciding which candidates it will attempt to gather).
=
If you're talking about the latter case, then I agree th= ere's a question of "how long do I wait for the pending STUN trans= action before giving up and trickling the candidates I have?" Which I = assumed would be an implementation choice.

On Thu, Mar 1, 2018 at 1:40 PM, Christ= er Holmberg <christer.holmberg@ericsson.com> wr= ote:
Hi,

>> For example, perhaps you gather relay candidates only for the audi= o streams, because you don't want to use
>> a relay for your video (you rather don't use = video, if it won't work without a relay).
>
> I agree there's nothing preventing this. In this case the ICE agen= t would be able to trickle the audio relay candidate immediately.

Yes, but in this case it is assumed that the ICE agent knows that it= will never get a relay candidate for video (or, if it gets one, it will no= t trickle it).

>> Again, I don't see the difference between streams and componen= ts here. You could ask the same question of components: "How
>> does the agent know it will get 'RTP srflx' if it gets = 9;RTCP srflx'?"
>
> You don't know - unless trickle mandates it (5245bis does not mand= ate it, as far as I know).
>
>> The ICE agent doesn't know what candidates it's attempting= to gather? Or it doesn't know whether the pending STUN transaction wil= l fail?

The ICE agent does not know what candidates it will eventually get. = Maybe it can indicate (using an API or configuration) what it wants, maybe = it will get whatever is available, but I don't think we can assume that= it knows what it will eventually get.

>>You would have to explain what "stream order" really mean= s.
>
>It would be the order of the rows in section 8.1; ordered first by stre= am then by component.=C2=A0

If you are using SDP, the initial offer will obviously order the str= eams (m- lines) in a certain order.

But, when you then start to trickle, I don't understand what "stre= am order" means. Assume the agent gets candidates for only one stream.= How do you trickle those in "stream order"? Again, if you know t= hat you are going to get the same type of candidates also for the "pre= vious" streams, you can wait. But if you don't know? How long will= you wait until you trickle?

Regards,

Christer




On Thu, Mar 1, 2018 at 12:56 PM, Peter Saint-Andre <stpeter@mozilla.com> wrote:
On 3/1/18 12:19 PM, Christer Holmberg wrote:
> Hi,
>
>>> Assume the agent gets "stream 1 host", "stream = 2 host" and "stream 2 srflx". Should it wait for "strea= m 1 srflx" before trickling "stream 2 srflx"?
>>
>> That was my interpretation.
>> =C2=A0
>>> How does the agent even know that it will get "stream 1 s= rflx"?
>>
>> If one candidate of a particular foundation was gathered successfu= lly, the agent can expect the rest of the
>> candidates with that foundation to be gathered successfully as wel= l.
>
> I don't think there is any rule saying that, for a given foundatio= n, you will get candidates for all streams (see example in section 6.1.2.6.= of 5245bis). For example, perhaps you gather relay candidates only for the= audio streams, because you want to use a relay for your video (you rather = don't use video, if it won't work without a relay).
>
>> Again, I don't see the difference between streams and componen= ts here. You could ask the same question of components: "How
>> does the agent know it will get 'RTP srflx' if it gets = 9;RTCP srflx'?"
>
> You don't know - unless trickle mandates it (5245bis does not mand= ate it, as far as I know).
>
>>> My point is that is if you have the following text:
>>>
>>> =C2=A0 =C2=A0"achieve this, when trickling candidates, ag= ents MUST respect the
>>> =C2=A0 =C2=A0order in which the components and streams appear = (implicitly or
>>> =C2=A0 =C2=A0explicitly) as they have been negotiated by means= of the relevant
>>> =C2=A0candidate information."
>>>
>>> ...you should explain how it impacts streams. Currently the te= xt only talks about components.
>>
>> Ah, so is the issue that the next sentence only mentions component= s?
> =C2=A0
> Correct.
>
>> =C2=A0 =C2=A0Therefore candidates for a given component
>> =C2=A0 =C2=A0MUST NOT be conveyed prior to candidates for a compon= ent with a lower
>> =C2=A0 =C2=A0ID number within the same foundation.
>>
>> Streams are mentioned further below:
>>
>>=C2=A0 =C2=A0Similar considerations apply at the level of media str= eams in
>>=C2=A0 =C2=A0addition to foundations; this is covered by the requir= ement to always=C2=A0
>>=C2=A0 =C2=A0start unfreezing candidates starting from the first me= dia stream as
>>=C2=A0 =C2=A0described under Section 5.2.
>>
>> But this appears out of date. Section 5.2 used to say:
>>
>> If [the first]
>> checklist is still empty however, agents will hold off further
>> processing until this is no longer the case.
>>
>> .... Which ensures the first stream is always unfrozen first. But = now it says:
>>
>> =C2=A0 =C2=A0If that first component of the first media stream doe= s
>> =C2=A0 =C2=A0not contain candidates for one or more of the current= ly known pair
>> =C2=A0 =C2=A0foundations, and if candidate pairs already exist for= that foundation
>> =C2=A0 =C2=A0in one of the following components or media streams, = then the agent
>> =C2=A0 =C2=A0unfreezes the first of those candidate pairs.
>>
>> Meaning section 5.2 no longer enforces the stream ordering require= ment.
>>
>> So, I'd suggest:
>> =E2=80=A2 Removing the outdated "Similar considerations apply= ..." paragraph.
>> =E2=80=A2 Updating the rest of Section 16 to make it clear that ca= ndidates should be trickled in both stream and component order.
>
> You would have to explain what "stream order" really means. = Because, it does not mean that you first trickle all candidates for stream = 1, then all candidates for stream 2, etc.
>
> As I said above, you seem to suggest that, for each stream and each fo= undation, there will be the same set of candidates. There is no such requir= ement anywhere, as far as I know.
I suggest that we remove all references to the poorly defined concept of "stream order". But if Emil thinks this is crucial then I'll = defer to
him. (I did connect with him offlist and he promises to weigh in soon.)

Peter


--f403043e8038734723056661be93-- From nobody Thu Mar 1 23:36:58 2018 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 549741270AE for ; Thu, 1 Mar 2018 23:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=ericsson.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 W7_11B7nHRlH for ; Thu, 1 Mar 2018 23:36:55 -0800 (PST) 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 42955127342 for ; Thu, 1 Mar 2018 23:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519976210; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1RgawsXzDkzUDbARUzehfVO7LtqsjVBuQo0pEqpwCa8=; b=DZuE82LisrRFuJboPiMTAkWytmR4vJ5y7rg/N9UmbociFl61OTu04WYXdk19X7bg /M8Df3E49LF6Wh5yZzCKgkDOm621o9lU6qzJwdMC0EnKpOtjgpdLGdG0nx1a4Xmt pOj4xwOrbYX3lnuQsf1uqguC+yJeU4h+AQ97vqIsUbs=; X-AuditID: c1b4fb3a-728f89c0000067b4-64-5a98ff117157 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8F.18.26548.11FF89A5; Fri, 2 Mar 2018 08:36:50 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Fri, 2 Mar 2018 08:36:48 +0100 From: Christer Holmberg To: Taylor Brandstetter CC: Peter Saint-Andre , Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] Trickle: What is Section 16 about? Thread-Index: AQHTsGOwLjmDpDpE6ESJTIumIw+YtaO6E/aAgAFrNYCAAA3hgIAAAHKAgAAUBGCAAAnMgIAAFajwgAAM9ICAAAYlgIAAEn8ggAAIcICAALcNgA== Date: Fri, 2 Mar 2018 07:36:48 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C1B8FEE@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1B9583@ESESSMB109.ericsson.se> <70af5888-1927-1f62-ba3f-8d6fd4614c87@mozilla.com> <7594FB04B1934943A5C02806D1A2204B6C1B9921@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.7.170905 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="Windows-1252" Content-ID: <15147CDB37D6C140A94B493ABB4FB440@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7n67Q/xlRBl+ncFlcXvGQ1eLbhVqL ZytPMVoc29PP7MDisWBTqceSJT+ZPPoOdLF6zN3zgjmAJYrLJiU1J7MstUjfLoEr4+X7DpaC uRYVCy42MTYwntHpYuTkkBAwkTg67TNTFyMXh5DAYUaJNQuvsUA4ixglFv69wdzFyMHBJmAh 0f1PG6RBREBX4ubXhWwgNrNAicTiU9PBbGEBU4kzp3exQ9SYSZx4u5cJwq6TOH91JlicRUBF YtKr2YwgNq+AtUTvlEfMELtmsEl8/3WIFSTBKRAo8Wz3JLAGRgExie+n1jBBLBOXuPVkPhPE 1QISS/acZ4awRSVePv4H1isqoCex4cRtdoi4osTOs+3MEL0GEu/PzYeyrSV239kCNVNbYtnC 18wQBwlKnJz5hGUCo/gsJOtmIWmfhaR9FpL2WUjaFzCyrmIULU4tLs5NNzLSSy3KTC4uzs/T y0st2cQIjMqDW35b7WA8+NzxEKMAB6MSD6/ppxlRQqyJZcWVuYcYJTiYlUR4Wz4AhXhTEiur Uovy44tKc1KLDzFKc7AoifM6pVlECQmkJ5akZqemFqQWwWSZODilGhilHvXO7a55ZmeSHnq+ 833L6TWJ95xmW5psCRLS2681YXdVlsvSXTNWNWzoUzJ3WRSV46989nO8/uMnP7v01zC8D2l7 79yjEs+nm/e2YrOonoLmbcNZbkdFrB8bPddpCYi9karRdHDOUobDK//8F3xVsf9swD4egSil tZKbLv69fviI3QndHX+VWIozEg21mIuKEwHEsvbzxgIAAA== Archived-At: Subject: Re: [Ice] Trickle: What is Section 16 about? 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, 02 Mar 2018 07:36:57 -0000 Hi, >>ICE agent does not know what candidates it will eventually get. > >I think this is the root of our misunderstanding. But can you clarify, do >you mean that the ICE agent doesn't know what candidates it will >attempt to gather? Or that it doesn't know whether a pending STUN >transaction will fail? The agent probably knows what candidates it TRIES to gather. But, as you say, a pending STUN transaction may fail. The STUN/TURN server might be overloaded, or out-of-service for some other reason. > If you're talking about the former case, then I think we have a >different concept of what the "ICE agent" is. I interpreted the ICE agent >as being responsible for candidate gathering (including deciding which >candidates it will attempt to gather). > > If you're talking about the latter case, then I agree there's a question >of "how long do I wait for the pending STUN transaction before giving up >and trickling the candidates I have?" Which I assumed would be an >implementation choice. Perhaps, but then we need to document it. Based on our discussion, I assume =B3stream order" actually means =B3foundation order throughout all streams=B2. I.e., you need to trickle all available f1 candidates before yo= u trickle any f2 candidates, before you trickle any f3 candidates, etc etc. Regards, Christer On Thu, Mar 1, 2018 at 1:40 PM, Christer Holmberg wrote: Hi, >> For example, perhaps you gather relay candidates only for the audio >>streams, because you don't want to use >> a relay for your video (you rather don't use video, if it won't work >>without a relay). > > I agree there's nothing preventing this. In this case the ICE agent >would be able to trickle the audio relay candidate immediately. Yes, but in this case it is assumed that the ICE agent knows that it will never get a relay candidate for video (or, if it gets one, it will not trickle it). >> Again, I don't see the difference between streams and components here. >>You could ask the same question of components: "How >> does the agent know it will get 'RTP srflx' if it gets 'RTCP srflx'?" > > You don't know - unless trickle mandates it (5245bis does not mandate >it, as far as I know). > >> The ICE agent doesn't know what candidates it's attempting to gather? >>Or it doesn't know whether the pending STUN transaction will fail? The ICE agent does not know what candidates it will eventually get. Maybe it can indicate (using an API or configuration) what it wants, maybe it will get whatever is available, but I don't think we can assume that it knows what it will eventually get. >>You would have to explain what "stream order" really means. > >It would be the order of the rows in section 8.1; ordered first by stream >then by component. If you are using SDP, the initial offer will obviously order the streams (m- lines) in a certain order. But, when you then start to trickle, I don't understand what "stream order" means. Assume the agent gets candidates for only one stream. How do you trickle those in "stream order"? Again, if you know that you are going to get the same type of candidates also for the "previous" streams, you can wait. But if you don't know? How long will you wait until you trickle? Regards, Christer On Thu, Mar 1, 2018 at 12:56 PM, Peter Saint-Andre wrote: On 3/1/18 12:19 PM, Christer Holmberg wrote: > Hi, > >>> Assume the agent gets "stream 1 host", "stream 2 host" and "stream 2 >>>srflx". Should it wait for "stream 1 srflx" before trickling "stream 2 >>>srflx"? >> >> That was my interpretation. >> =20 >>> How does the agent even know that it will get "stream 1 srflx"? >> >> If one candidate of a particular foundation was gathered successfully, >>the agent can expect the rest of the >> candidates with that foundation to be gathered successfully as well. > > I don't think there is any rule saying that, for a given foundation, you >will get candidates for all streams (see example in section 6.1.2.6. of >5245bis). For example, perhaps you gather relay candidates only for the >audio streams, because you want to use a relay for your video (you rather don't use video, if it won't work without a relay). > >> Again, I don't see the difference between streams and components here. >>You could ask the same question of components: "How >> does the agent know it will get 'RTP srflx' if it gets 'RTCP srflx'?" > > You don't know - unless trickle mandates it (5245bis does not mandate >it, as far as I know). > >>> My point is that is if you have the following text: >>> >>> "achieve this, when trickling candidates, agents MUST respect the >>> order in which the components and streams appear (implicitly or >>> explicitly) as they have been negotiated by means of the relevant >>> candidate information." >>> >>> ...you should explain how it impacts streams. Currently the text only >>>talks about components. >> >> Ah, so is the issue that the next sentence only mentions components? > =20 > Correct. > >> Therefore candidates for a given component >> MUST NOT be conveyed prior to candidates for a component with a lower >> ID number within the same foundation. >> >> Streams are mentioned further below: >> >> Similar considerations apply at the level of media streams in >> addition to foundations; this is covered by the requirement to always >> start unfreezing candidates starting from the first media stream as >> described under Section 5.2. >> >> But this appears out of date. Section 5.2 used to say: >> >> If [the first] >> checklist is still empty however, agents will hold off further >> processing until this is no longer the case. >> >> .... Which ensures the first stream is always unfrozen first. But now >>it says: >> >> If that first component of the first media stream does >> not contain candidates for one or more of the currently known pair >> foundations, and if candidate pairs already exist for that foundation >> in one of the following components or media streams, then the agent >> unfreezes the first of those candidate pairs. >> >> Meaning section 5.2 no longer enforces the stream ordering requirement. >> >> So, I'd suggest: >> =80 Removing the outdated "Similar considerations apply..." paragraph. >> =80 Updating the rest of Section 16 to make it clear that candidates >>should be trickled in both stream and component order. > > You would have to explain what "stream order" really means. Because, it >does not mean that you first trickle all candidates for stream 1, then >all candidates for stream 2, etc. > > As I said above, you seem to suggest that, for each stream and each >foundation, there will be the same set of candidates. There is no such >requirement anywhere, as far as I know. I suggest that we remove all references to the poorly defined concept of "stream order". But if Emil thinks this is crucial then I'll defer to him. (I did connect with him offlist and he promises to weigh in soon.) Peter From nobody Fri Mar 2 05:12:55 2018 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 F0675127867 for ; Fri, 2 Mar 2018 05:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=ericsson.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 6FpVvySqkh-l for ; Fri, 2 Mar 2018 05:12:52 -0800 (PST) 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 431E3124E15 for ; Fri, 2 Mar 2018 05:12:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519996370; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xJQgjZNFiZqBR86W17SlLckX/WXWcx0BPsU/hnl0fLQ=; b=Tou/cbHAwqlghwiE1uNwbZLnCt1+sCI/cI4Mx9t9HaLnq8TGS5cqgVgKg5nw5Bhw amo/1Ysupl+5lWAVyVixn+fEYlQJj5vpjxHig81EKzVFyUFTg/6+HL0ZlS7AOo2t zu3t/Pces2NNikq0sf5kdbVxXOHhXJTfCdOdW2oqRC4=; X-AuditID: c1b4fb3a-728f89c0000067b4-8a-5a994dd280ec Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F2.55.26548.2DD499A5; Fri, 2 Mar 2018 14:12:50 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Fri, 2 Mar 2018 14:12:35 +0100 From: Christer Holmberg To: Christer Holmberg , =?utf-8?B?QXJpIEtlcsOkbmVu?= , "Black, David" , "ice@ietf.org" , Nils Ohlmeier CC: "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" Thread-Topic: [Ice] 5245bis: STUN/TURN transaction timeout timer Thread-Index: AdOuOI+oEAiBXZOTQm+Dl/LRxGi/pAA0o/rgAAMPdYAAAXfKMAACL39QAAosVoAAACltgAACbt+AAHQHYYAABs/iAAAAFsyAADtjNQA= Date: Fri, 2 Mar 2018 13:12:34 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C19C90C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1A8CC5@ESESSMB109.ericsson.se> <143496D8-1304-49C3-B12F-5EF3A116E1BD@mozilla.com> <1A521409-0DF9-42B7-B1D9-0F8FB6FA7008@mozilla.com> <748F125A-EE65-49B9-99D9-C64AB428CD3A@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.20] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3602849132_71969763" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUyM2J7lO4l35lRBt+f8Vp8nLWYxWL+yevM FhdnTWaz+Hah1uL6vMmMDqwek2bOYPZYsuQnk0ffgS7WAOYoLpuU1JzMstQifbsErozWK7fY C7pKK66e/MDcwNic2cXIySEhYCIx5dA75i5GLg4hgcOMEgt3zGOCcBYxSvRO6QLKcHCwCVhI dP/TBomLCDxilHjfMoEZpJtZoEbi2t39YLawgL3EigltjCC2iICDxIM9DUwQdpnE9WkvWUBs FgEViTft+8BsXgFriWtfuqGWTWaVmDH7GztIglPARuL5+pNggxgFxCS+n1rDBLFMXOLWk/lM EGeLSDy8eJoNwhaVePn4HyuILSqgJ7HhxG12iLiixNXpy6F6KyVuLH0KtVhQ4uTMJywTGEVn IRk7C0nZLCRlEHFtiT23tjLD2E/eXWCFsK0lZvw6yAZhK0pM6X7IDmGbSrw++pFxASPHKkbR 4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAiD245bfVDsaDzx0PMQpwMCrx8O61mBklxJpYVlyZ e4hRBWjOow2rLzBKseTl56UqifC2fJgRJcSbklhZlVqUH19UmpNafIhRmoNFSZzXKc0iSkgg PbEkNTs1tSC1CCbLxMEp1cDo8YnhmYX2bhkR0+unpj+zSbxmtPaK39vG3MD66y8Cmk/kr1mY G5u1gaOQV+Koa1WifUp823K9x9eOzLzOt+n2pPS2id69Fz4k9nBLmO+MCZtQH+M/ZcurJptl q9yDL2yf7lC0R/z1FztH5/U54rMq3xw+Pueu4rspx595qjSrt9oWHi34WVetxFKckWioxVxU nAgA/mRJOeACAAA= Archived-At: Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer 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, 02 Mar 2018 13:12:55 -0000 --B_3602849132_71969763 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi, I have created a pull request that moves the thinking-behind-global-pacing-value-of-5ms text to Appendix B. https://github.com/ice-wg/rfc5245bis/pull/63 Regards, Christer On 01/03/18 10:52, "Christer Holmberg" wrote: >=E2=80=A6so, my suggestion would be to move the text about HTO etc to Appendix >B.2, and only keep the 3 first paragraphs in Section 14.2. > >Regards, > >Christer > >On 01/03/18 10:49, "Christer Holmberg" >wrote: > >> >>Hi, >> >>When re-reading section 14.2, I actually don=C2=B9t think that ICE agents use >>the HTO timer. >> >>The important text is the following: >> >> "Regardless of the Ta value chosen for each agent, the combination of >> all transactions from all agents (if a given implementation runs >> several concurrent agents) MUST NOT be sent more often than once >> every 5ms (as though there were one global Ta value for pacing all >> agents).=C2=B2 >> >> >>The rest of the text in the section is then a justification/background >>for >>the statement above, and in that justification/background HTO is used as >>one parameter. >> >>But, again, ICE agents never implement and use HTO for anything - ICE >>agents just make sure that the global Ta value is not smaller than 5ms. >> >>Regards, >> >>Christer >> >> >> >> >> >> >> >>On 01/03/18 09:47, "Ari Ker=C3=A4nen" wrote: >> >>>Hi, >>> >>>I had a look at the Ti timer in 5389 >>>(https://tools.ietf.org/search/rfc5389#section-7.2.2) and it seems that >>>it is defined to be in line with the time it takes for (UDP) STUN >>>transaction that includes all re-transmissions to timeout: >>>> Reliability of STUN over TCP and TLS-over-TCP is handled by TCP >>>> itself, and there are no retransmissions at the STUN protocol >>>>level. >>>> However, for a request/response transaction, if the client has not >>>> received a response by Ti seconds after it sent the SYN to >>>>establish >>>> the connection, it considers the transaction to have timed out. >>> >>> >>>However the HTO timer is for transaction pacing and is roughly what one >>>successful connectivity check should take (2*RTT). >>> >>>Therefore these are two different things and I don't think it make sense >>>to mention Ti here at all. I suggest we remove the note completely. >>> >>> >>>Cheers, >>>Ari (hat off) >>> >>>> On 27 Feb 2018, at 2.25, Nils Ohlmeier wrote: >>>>=20 >>>> Yes you are right. Somehow I managed to read Christer=C2=B9s Note the >>>>opposite way of what I now think he intends to point out. >>>>=20 >>>> Sorry for the confusion. >>>>=20 >>>> Nils >>>>=20 >>>>=20 >>>>> On Feb 26, 2018, at 15:15, Black, David wrote: >>>>>=20 >>>>> Isn=C2=B9t it the other way around =C2=AD ICE HTO is much shorter than STUN o= r >>>>>TURN Ti? >>>>> =20 >>>>> Thanks, --David >>>>> =20 >>>>> From: Nils Ohlmeier [mailto:nohlmeier@mozilla.com] >>>>> Sent: Monday, February 26, 2018 6:11 PM >>>>> To: Christer Holmberg >>>>> Cc: Black, David ; ice@ietf.org; >>>>>draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org; >>>>>jri@google.com >>>>> Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer >>>>> =20 >>>>> =20 >>>>> On Feb 26, 2018, at 07:48, Christer Holmberg >>>>> wrote: >>>>> =20 >>>>> Maybe adding the following note to the existing Timer HTO definition: >>>>> =20 >>>>> Timer HTO: The timeout timer for a given STUN or TURN transaction. >>>>> =20 >>>>> =C2=B3NOTE: When STUN and TURN are used with ICE, timer HTO is used >>>>>instead of timer Ti [RFC5389] as transaction timeout timer.=C2=B2 >>>>> =20 >>>>> My initial thought was: yes sounds good. >>>>> =20 >>>>> But one of the side effects know from real world deployments is that >>>>>results in the end-of-candidates indication coming in after a long >>>>>time >>>>>if one of the STUN or TURN servers is not reachable. >>>>> I don=C2=B9t want to make this a last minute change, but your indication >>>>>that Ti explicitly got made shorter made me wonder if everyone in WG >>>>>is >>>>>aware of this usage of the long HTO value. >>>>> =20 >>>>> Best >>>>> Nils Ohlmeier >>>>>=20 >>>>>=20 >>>>> =20 >>>>> Regards, >>>>> =20 >>>>> Christer >>>>> =20 >>>>> From: Black, David [mailto:David.Black@dell.com] >>>>> Sent: 26 February 2018 16:54 >>>>> To: Christer Holmberg ;ice@ietf.org; >>>>>draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org >>>>> Cc: jri@google.com; Black, David >>>>> Subject: RE: 5245bis: STUN/TURN transaction timeout timer >>>>> =20 >>>>> That would be a fine thing to do, Thanks, --David >>>>> =20 >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>> Sent: Monday, February 26, 2018 9:22 AM >>>>> To: Black, David ; ice@ietf.org; >>>>>draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org >>>>> Cc: jri@google.com >>>>> Subject: Re: 5245bis: STUN/TURN transaction timeout timer >>>>> =20 >>>>> Hi, >>>>> =20 >>>>> >> But, still, is there a reason we couldn=C2=B9t use =C2=8CTi=C2=B9 also in >>>>>5245bis, >>>>>and point out the big value difference when used with ICE? >>>>> >=20 >>>>> >Given the nearly 2-orders-of-magnitude difference in the time >>>>>periods, I=C2=B9d be concerned that using the same name risks leaving an >>>>>incorrect impression on an implementer who >>>>> >is familiar with one protocol, but new to the other. Different >>>>>names may also improve clarity in other documents that describe how >>>>>STUN and ICE work together. >>>>> =20 >>>>> Fair enough. But, should we then point out that Ti isn=C2=B9t used with >>>>>ICE? >>>>> =20 >>>>> Regards, >>>>> =20 >>>>> Christer >>>>> =20 >>>>> =20 >>>>> =20 >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>> Sent: Sunday, February 25, 2018 8:00 AM >>>>> To: ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; >>>>>ice-chairs@ietf.org >>>>> Cc: Black, David ; jri@google.com >>>>> Subject: 5245bis: STUN/TURN transaction timeout timer >>>>> =20 >>>>> Hi, >>>>> =20 >>>>> In draft-5245bis, the name of the STUN/TURN transaction timeout timer >>>>>is =C2=8CHTO=C2=B9. >>>>> =20 >>>>> As part of the IESG review, I have been asked what the =C2=8CH=C2=B9 stands >>>>>for. >>>>>After some digging in the mail archives (2016-09-14), I figured out it >>>>>stands for =C2=B3handshake=C2=B2: >>>>> =20 >>>>> https://www.ietf.org/mail-archive/web/ice/current/msg00378.html >>>>> =20 >>>>> =C2=B32. A timeout for request packets, call it handshake timeout >>>>>or >>>>>HTO which SHOULD be 2*RTT if the RTT is known and 500ms otherwise.=C2=B2 >>>>> =20 >>>>> Now, in RFC 5389, the transaction timeout timer is called =C2=8CTi=C2=B9. >>>>>However, the default value for that SHOULD be 39,5 seconds =C2=AD which is >>>>>quite different from 500ms. >>>>> =20 >>>>> But, still, is there a reason we couldn=C2=B9t use =C2=8CTi=C2=B9 also in 5245bis= , >>>>>and point out the big value difference when used with ICE? >>>>> =20 >>>>> Regards, >>>>> =20 >>>>> Christer >>>>> _______________________________________________ >>>>> Ice mailing list >>>>> Ice@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ice >>>>=20 >>> --B_3602849132_71969763 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOQYJKoZIhvcNAQcCoIIUKjCCFCYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIMMIIGBjCCA+6gAwIBAgIQN4YipkcuAr1/ZKbsw+1eMTANBgkqhkiG9w0BAQsFADBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTAzMDgwODMyWhcNMjAxMTAzMDgwODMxWjBvMREw DwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRQ2hyaXN0ZXIgSG9sbWJlcmcxLTArBgkqhkiG 9w0BCQEWHmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTEPMA0GA1UEBRMGTE1GQ0hI MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy0z3dlyw+ybHo7PhlkBY00QOJB5T NOXcMdxiQ0nL5uM1C/0xQ7/T3uuHJRjD8nvqTqnlmfJ2VCZRKD3W8LJAUXGFd8JqwLJmGGZt cS3Jp+2WBAxBR6TjtcMwDGQNYD85YCKIuqcsarOxVhzXhwISp750JC1UmR4xxX1gbSkVb8S8 DsPsBioQ/Enkiad/rP0huQFb56Ocxu2Fy2aEW06ezyxU9My4Jh/vMDh+0DBb8EfN8ovAFmMH Qj3SxVUDwnTYbPdA1v3RipF/HH0NBsNOUS8RFct6OxHG1JDbMrkY9ErEKkrHmu3JyNM1hxmy 8rJl/yDID2n6vyxkh5QFcsvOdwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0 cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCB ggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEu Y29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNz c29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEeY2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEW LGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUESOe8HpdLQz1aZdNgbOPnJlysTIw HwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqG SIb3DQEBCwUAA4ICAQBdN30YKQsw+ow1tjR6gBDuNpQagWRw7DSkYXg4ZE5k76jyXPOTa9VE 8x3MbNIbsyuVLYiVIN/lePTPi4qyt1CNBGPn4roUOuGeGQ7/dABYWNGmT0nKjjeXmqs9bt5z CrxPfVS4xeEU7D64OJtD47f069jsG5E6qENdPmrjaKmTrllfM1S9HvWeco8PwBQC5ixpiXUq t3Dyq3K0GmCgs1P7dJqup+Dt6UNF+DwgSZZeBjo3l+BtAv7StrvWdUQCqJpjUttIwzmtqsx2 NUWa1oSoqvUJ6XnJUZdT/UF390/6Uo4rnTeOWao9dkKQCaE3KvtCHBNZRv1MW0Ot3KSKnE+4 iZeUZgg1KAVQ5dhjjtXmjYoZMYoN4lE4OB2ae8LRbOrj0PE7Wvbuhs5eOyei7e6lYDHPzpLn cfcLpQmOoHal11JqympoeJQENtQl2i1p2j5KmsfUQiqD1HQaGcpH9OKXEclLCOpQ/6zafNW3 nSYFBwADNpHMNiQXxcXKxiPCfiZa2UK5RRWohIz9kY8HXvX/1E2pvtOZoymiXJviR3g2BFvM 21+LIVu3dtoEWWxtD7MyDtOe1dEZTfxLUPMpQa66znWbEQ736mmv5n/z+Aaq7OidNuOIFfO2 HbE+LBHIWhKAy9Ttqa+RqpPONMkvz3kth+G4IOBaTYEPWWHLrqXe2zCCBsIwggSqoAMCAQIC EFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25l cmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4IC DwAwggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs 0zfSTm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9 ZVbXILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvS xlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eN o4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWq g5t2H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4 TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1 MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYv SBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaG K5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoG CCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25l cmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNV HSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRv cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8v Y3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMS MA0GCSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gV LtDUJQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyo EBHGvw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50Zk BqYnnl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEO rPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1Ur RIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKX e4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNO xdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaH KWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyE G/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDCCBTgwggMg oAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEy MDA1MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMM FlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQDCvusn8CGj82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1 gouuSLasANxldewqTV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/te uuSPl2e+S46NZAdXOFVpNDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv41 4e1Qe6kwjRnTCY5oZ12/PJcYU7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1s OTlzgBbIUrAjzeA+3N08R6C7NYrimGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1v gPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdf Y2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCDLrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2 WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt6 0H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKSL2LUP2lDfA3W/Fh1AYidWBZL3rqQ /0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8wPTAPBgNVHRMBAf8EBTADAQH/ MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA389ZoG5XcUkeudQXuZ KoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyywqODAQDc19oRc XOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr7cQZ5qtM ETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65XI0G SK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI 6wzWJoi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2H dqkXlrfPDZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/ xFZT+mNl0PMcDhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjU kL8Ws9nprFlhVMgcusrByuG5IEyPOpOJpaDMv9P2daR1lm1WMYIB8TCCAe0CAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMCEDeGIqZHLgK9f2Sm7MPtXjEwDQYJYIZIAWUDBAIBBQCgaTAvBgkq hkiG9w0BCQQxIgQgI/HR6S7AB08qF+6OQmlm5/l7TzUeUKbIAV9gjG734v0wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMzAyMTMyNTMyWjANBgkqhkiG 9w0BAQEFAASCAQBRYolDKFXWOxoIqO71Ecsnti7rKA3JjHcPi/dAIUjaNfOVzIiNBag912oJ MzknTsW6zFm65PIXC/gyqp5kj1a7d8rLvlWkga9eDYG13PLYgh8obZQduXUieQnyp3PgbVSE T6XRh4Z2HTF3Gqrj9tpf2okZkShUgi75YyAZAvukmV3saOB+Q650nRGr0WoPZAmF842wkwk8 DbGSdihW7Vz6JYcBaLftwCa7x7XWKPnUDEnKVqlm7lYqr1OqFQfIIXOdL94dfpiMO9NVCAlj fYnBV3ixdRPuii+nIrS9o1tWZpJjn68QV7LRUSQ8tMj9UV7+mYpBkYt33z97EBbkkHKB --B_3602849132_71969763-- From nobody Fri Mar 2 05:18:01 2018 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 DD31F126BF6 for ; Fri, 2 Mar 2018 05:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 CCQarVW5IfPy for ; Fri, 2 Mar 2018 05:17:55 -0800 (PST) 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 26C6F127AD4 for ; Fri, 2 Mar 2018 05:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519996670; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fqWYCn8D675+l62cPFYRThThuH0Xg6fHtxQyJSha6As=; b=JA8WZ2Lmpgyq4jBlNk38Y0pl9j2x7IsQzaGmG2qemvareNrPd7NcOY+PCYqKH8WI QLQRSfi2W9VzsdlSyKpTm5URZ9FqiO62qVL6FxRV0hOD8IYFaYWUdBfaN8vhT+gp /XEqmmIoBIkG1+2iDglnjz01ifSjUynvaigwlncpRLo=; X-AuditID: c1b4fb25-083ff70000002d5f-f7-5a994efe140d Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 81.5B.11615.EFE499A5; Fri, 2 Mar 2018 14:17:50 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Fri, 2 Mar 2018 14:17:50 +0100 From: Christer Holmberg To: Christer Holmberg , Eric Rescorla , =?iso-8859-1?Q?Ari_Ker=E4nen?= CC: The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , Peter Thatcher , "ice@ietf.org" Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) Thread-Index: AdOpa677O8VqdAW5ThyXNM/NhWOUGQAG8xsAAerqwYAACYXUgAAF+QMAADB64QA= Date: Fri, 2 Mar 2018 13:17:49 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C17768D@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.7.170905 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D6BF1EA02BEB0christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCIsWRmVeSWpSXmKPExsUyM2K7tO4/v5lRBntPylnMP3md2WLF63Ps FhdnTWaz+Hah1mLGn4nMFteWv2Z1YPNYsKnUY8mSn0wekx+3MQcwR3HZpKTmZJalFunbJXBl /D67jLHgaW7F0+Y9zA2MV+K7GDk5JARMJC6vbmXpYuTiEBI4zCjx9t0DKGcRo8SdOduBHA4O NgELie5/2iBxEYGJjBLzp6xgBHGYBR4wSuzd+58JZJSwQL3EzAXHWSGqGhglvlyawgrSLSLg J7GuKRDEZBFQkdg/jxmknFfAWuLfxF1sUJuZJN60XWABSXAK2Egs2/mfHcRmFBCT+H5qDdh8 ZgFxiVtP5jNBnC0gsWTPeWYIW1Ti5eN/rCC2qICexIYTt9lBdkkIKEos75eDaE2QmP5oGzvE XkGJkzOfsExgFJ2FZOosJGWzkJRBxPUkbkydwgZha0ssW/iaGcLWlZjx7xBUjbXEvMOvmZDV LGDkWMUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGLcHt/xW3cF4+Y3jIUYBDkYlHt73FjOj hFgTy4orcw8xSnAwK4nwtnyYESXEm5JYWZValB9fVJqTWnyIUZqDRUmcd45we5SQQHpiSWp2 ampBahFMlomDU6qBcWJ55v0rqifyJXUaUg1FV9p+P1l8ckKj+fTcJPefs9bp917X2SIv2fzO ovNk78S05795uLj6LfZbz4z2MGqfbPJ82nHmy2w3SjK/dndt++dxsle9zfHJ3f+9Yqe/qyxN nc1V+v/CnKbHP94FmK6Ou3hrM1PqplsPmtxe37m043rvoZ+pUZtf3FViKc5INNRiLipOBAAL 3p7/1wIAAA== Archived-At: Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) 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, 02 Mar 2018 13:17:57 -0000 --_000_D6BF1EA02BEB0christerholmbergericssoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So, what to do? From: Christer Holmberg > Date: Thursday 1 March 2018 at 16:09 To: Eric Rescorla >, Ari Ker=E4nen > Cc: "iesg@ietf.org" >, "draft-ietf-ice-rfc5245bis@ietf.org" >, "ice-chairs@ietf.org" >, "pthatcher@google.com" >, "i= ce@ietf.org" > Subject: Re: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: = (with COMMENT) (excluding Security Considerations) Resent-From: > Resent-To: Ari Ker=E4nen >, Christer Holmberg >, "jdrosen@jdrosen.net= " > Resent-Date: Thursday 1 March 2018 at 16:09 Hi, I guess Ari will reply, but my understanding is that, since triggered check= s have high priority, we want the triggered binding requests to be sent asa= p. But, if the ongoing transaction (In-Progress) has already been going on = for a while, and all transmitted/re-transmitted binding requests so far for= whatever reason have got dropped in the network, due to the current re-tra= nsmission timer (which grows after each re-transmission) it may take a whil= e before binding check is re-transmitted again. (Of course, even if we create a new transaction, there may be other checks = waiting in the triggered check queue, so it may still take a while before t= he new binding check is sent.) Regards, Christer From: Eric Rescorla > Date: Thursday 1 March 2018 at 15:31 To: Ari Ker=E4nen > Cc: Christer Holmberg >, "iesg@ietf.org" >, "draft-ietf-ice-rfc5245bis@ietf.org" >, "ice-chairs@ietf.org" >, "pthatcher@googl= e.com" >, "ice@ietf.org" > Subject: Re: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: = (with COMMENT) (excluding Security Considerations) On Thu, Mar 1, 2018 at 12:58 AM, Ari Ker=E4nen > wrote: Hi Eric & Christer, > On 19 Feb 2018, at 16.42, Eric Rescorla > wrote: > > > > > in-progress transaction. Cancellation means that the agent > > will not retransmit the request, will not treat the lack of > > response to be a failure, but will wait the duration of the > > > > Why are you cancelling In-Progress checks when you receive a peer-refle= ctive check? > > If you receive two in a row, then it seems like this delays a successfu= l check. > > True. > > So, I will remove the cancel part. > > Do you still think it should create a new binding request, or is the ongo= ing In-Progress check enough to check the pair? > > My initial reaction is you don't need to do anything extra, but I could e= asily be wrong here. I'm afraid this is one of the parts of the spec that solves a corner case i= n an interesting but non-obvious way. For context, here's the original text= : https://tools.ietf.org/html/rfc5245#section-7.2.1.4 IIRC, one of the reasons for this is that an agent might have started the t= ransaction a while ago, perhaps even sent a few re-transmissions. Now, if y= ou don't cancel that transaction, but just keep that going and send the rem= aining re-transmission(s) and those are lost due to bad network connectivit= y, you end up marking that pair as failed. However, if you cancel and start= a new transaction, you have full amount of fast retransmissions to go. And= if you receive a reply to a cancelled check, it is still a success. I reme= mber this was unintuitive but eventually made sense when I implemented it. So, I'd recommend we keep this text as such. Why is this different from any other case of transient failure? -Ekr Cheers, Ari (hat off) --_000_D6BF1EA02BEB0christerholmbergericssoncom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
So, what to do?

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Thursday 1 March 2018 at 16:0= 9
To: Eric Rescorla <ekr@rtfm.com>, Ari Ker=E4nen <ari.keranen@ericsson.com>
Cc: "iesg@ietf.org" <iesg@i= etf.org>, "draft-ietf-ice-rfc5245bis@ietf.org" <draft-ietf-ice-rfc5245bis@ietf.org>, "ice-chairs@ietf.org"= <ice-chairs@ietf.org>, &q= uot;pthatcher@google.com" = <pthatcher@google.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: Eric Rescorla's No Obj= ection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security = Considerations)
Resent-From: <alias-bounces@ietf.org>
Resent-To: Ari Ker=E4nen <ari.keranen@ericsson.com>, Chr= ister Holmberg <christ= er.holmberg@ericsson.com>, "jdrosen@jdrosen.net" <jdrosen@jdrosen.net>
Resent-Date: Thursday 1 March 2018 = at 16:09

Hi,

I guess Ari will reply, but my understanding is that, since triggered = checks have high priority, we want the triggered binding requests to be sen= t asap. But, if the ongoing transaction (In-Progress) has already been goin= g on for a while, and all transmitted/re-transmitted binding requests so far for whatever reason have got dropped in the networ= k, due to the current re-transmission timer (which grows after each re-tran= smission) it may take a while before binding check is re-transmitted again.=  

(Of course, even if we create a new transaction, there may be other ch= ecks waiting in the triggered check queue, so it may still take a while bef= ore the new binding check is sent.)

Regards,

Christer

From: Eric Rescorla <ekr@rtfm.com>
Date: Thursday 1 March 2018 at 15:3= 1
To: Ari Ker=E4nen <ari.keranen@ericsson.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "iesg@ietf.org" <= iesg@ietf.org>, "draft-ietf-ice-rfc5245bis@ietf.org= " <draft-ietf-ice-r= fc5245bis@ietf.org>, "ic= e-chairs@ietf.org" <ice-= chairs@ietf.org>, "ptha= tcher@google.com" <pthatcher@google.com>, = "ice@ietf.org" <ice@ietf.org>
Subject: Re: Eric Rescorla's No Obj= ection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security = Considerations)



On Thu, Mar 1, 2018 at 12:58 AM, Ari Ker=E4nen <= span dir=3D"ltr"> <ari.keran= en@ericsson.com> wrote:
Hi Eric & Christer,

> On 19 Feb 2018, at 16.42, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> >         in-progress transaction.  C= ancellation means that the agent
> >         will not retransmit the request,= will not treat the lack of
> >         response to be a failure, but wi= ll wait the duration of the
> >
> > Why are you cancelling In-Progress checks when you receive a peer= -reflective check?
> > If you receive two in a row, then it seems like this delays a suc= cessful check.
>
> True.
>
> So, I will remove the cancel part.
>
> Do you still think it should create a new binding request, or is the o= ngoing In-Progress check enough to check the pair?
>
> My initial reaction is you don't need to do anything extra, but I coul= d easily be wrong here.

I'm afraid this is one of the parts of the spec that solves a corner= case in an interesting but non-obvious way. For context, here's the origin= al text:
https://tools.ietf.org/html/rfc5245#section-= 7.2.1.4

IIRC, one of the reasons for this is that an agent might have started the t= ransaction a while ago, perhaps even sent a few re-transmissions. Now, if y= ou don't cancel that transaction, but just keep that going and send the rem= aining re-transmission(s) and those are lost due to bad network connectivity, you end up marking that pair as = failed. However, if you cancel and start a new transaction, you have full a= mount of fast retransmissions to go. And if you receive a reply to a cancel= led check, it is still a success. I remember this was unintuitive but eventually made sense when I implement= ed it.

So, I'd recommend we keep this text as such.

Why is this different from any other case of transient failure?

-Ekr



Cheers,
Ari (hat off)

 --_000_D6BF1EA02BEB0christerholmbergericssoncom_-- From nobody Fri Mar 2 06:24:30 2018 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 522D4126BF6 for ; Fri, 2 Mar 2018 06:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 gflQ6-01M_yW for ; Fri, 2 Mar 2018 06:24:16 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86ECA12D956 for ; Fri, 2 Mar 2018 06:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520000654; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=q013qQVkO41GB9Xzve3R3JznmmNRXbXWC72cwmybmXU=; b=I4SoRL3c+4vz8jnrVraOqAjkvvU4ybI0ygeKicS5v/CyQj9NhsdNtfvHN79r8/LV fIEVN6/J01u8jFEEBcpm1HCJgBBCdzBp3LCMpRX545SluO/ioITdRNQciCoDO2dW eJA650x+5NPz0SU3mnkreSjlYBg8DvMCaLZxq6bM2LY=; X-AuditID: c1b4fb2d-4b1ff70000005540-81-5a995e8e6776 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 97.F5.21824.E8E599A5; Fri, 2 Mar 2018 15:24:14 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Fri, 2 Mar 2018 15:24:14 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Christer Holmberg , Eric Rescorla CC: The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , Peter Thatcher , "ice@ietf.org" Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) Thread-Index: AdOpa677O8VqdAW5ThyXNM/NhWOUGQAG8xsAAerqwYAACYXUgAAF+QMAADB64QD//+1mAA== Date: Fri, 2 Mar 2018 14:24:13 +0000 Message-ID: <809A44FC-84EF-49FE-8DFA-4F2552140C39@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.95.226.8] Content-Type: text/plain; charset="utf-8" Content-ID: <70DFFABC47EA5C4FA24B949CB94F46D4@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2K7q25f3MwogxNrtCzmn7zObLHi9Tl2 i4uzJrNZfLtQazHjz0Rmi2vLX7M6sHks2FTqsWTJTyaPyY/bmAOYo7hsUlJzMstSi/TtErgy pr3sYitYoV9xYf9TpgbGHr0uRk4OCQETiQ3Ht7F2MXJxCAkcZpT4//4GG4SziFHi9tPnbCBV bAK2Ek9a9wFVcXCICIRJXNvMBVLDLPCAUWLv3v9MIDXCAvUSMxccB5skItDAKPHl0hRWkARI w79fC9hBbBYBFYmLLyczgti8AvYSrzdtZYfY9pVJYsHe7WANnAI2Ej23p4JtZhQQk/h+ag3Y BmYBcYlbT+YzQdwtILFkz3lmCFtU4uXjf6wQtrzEjLO3mEAuZRbQlFi/Sx+i1Vri9bzHjBC2 osSU7ofsEDcISpyc+YRlAqPYLCQbZiF0z0LSPQtJ9ywk3QsYWVcxihanFhfnphsZ66UWZSYX F+fn6eWllmxiBMbhwS2/dXcwrn7teIhRgINRiYe3LmBmlBBrYllxZe4hRgkOZiUR3pYPM6KE eFMSK6tSi/Lji0pzUosPMUpzsCiJ85705I0SEkhPLEnNTk0tSC2CyTJxcEo1ME6f4nNx+hej ODYBs1PZVTaLEq5xHDvVuXbWUtm3E4tY1ygJfgquMQsoeqwwufXjbrU/ShO/Ns7MXSr0qFIs 6LBLsMimjJ1mbB6zeu9xMr/22nFh1VJOXjUf21OcFx4HeXNP35CivLDr1YnlLzU7j13Tvnc8 86MIg8Kv1If7JHelxa6LusgkyKrEUpyRaKjFXFScCADHxJB7vwIAAA== Archived-At: Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) 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, 02 Mar 2018 14:24:25 -0000 SSBhZ3JlZSB3aXRoIHdoYXQgeW91IHdyb3RlIGJlbG93LiBJIHRoaW5rIHRoZSBiZXN0IHdheSBm b3J3YXJkIGlzIHRvIGtlZXAgdGhlIHRleHQgYXMgaXQgd2FzIGluIC0xNy4gQW55d2F5IGl0IHdh cyBwYXJ0IG9mIHRoZSBvcmlnaW5hbCBSRkM1MjQ1IHRleHQgYW5kIGFzIGRpc2N1c3NlZCBlYXJs aWVyLCB3aGVuIGluIGRvdWJ0LCBpdCdzIGJldHRlciB3ZSBkb24ndCBjaGFuZ2UgdGhlIHRleHQg YW5kIGFjY2lkZW50YWxseSBjaGFuZ2UgdGhlIGJlaGF2aW9yIGZvciB0aGUgd29yc2UuDQoNCg0K Q2hlZXJzLA0KQXJpDQoNCj4gT24gMiBNYXIgMjAxOCwgYXQgMTUuMTcsIENocmlzdGVyIEhvbG1i ZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gU28sIHdo YXQgdG8gZG8/DQo+IA0KPiBGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPg0KPiBEYXRlOiBUaHVyc2RheSAxIE1hcmNoIDIwMTggYXQgMTY6MDkN Cj4gVG86IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4sIEFyaSBLZXLDpG5lbiA8YXJpLmtl cmFuZW5AZXJpY3Nzb24uY29tPg0KPiBDYzogImllc2dAaWV0Zi5vcmciIDxpZXNnQGlldGYub3Jn PiwgImRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLWljZS1y ZmM1MjQ1YmlzQGlldGYub3JnPiwgImljZS1jaGFpcnNAaWV0Zi5vcmciIDxpY2UtY2hhaXJzQGll dGYub3JnPiwgInB0aGF0Y2hlckBnb29nbGUuY29tIiA8cHRoYXRjaGVyQGdvb2dsZS5jb20+LCAi aWNlQGlldGYub3JnIiA8aWNlQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogRXJpYyBSZXNjb3Js YSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLTE3OiAod2l0aCBD T01NRU5UKSAoZXhjbHVkaW5nIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKQ0KPiBSZXNlbnQtRnJv bTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQo+IFJlc2VudC1UbzogQXJpIEtlcsOkbmVuIDxh cmkua2VyYW5lbkBlcmljc3Nvbi5jb20+LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPiwgImpkcm9zZW5AamRyb3Nlbi5uZXQiIDxqZHJvc2VuQGpkcm9z ZW4ubmV0Pg0KPiBSZXNlbnQtRGF0ZTogVGh1cnNkYXkgMSBNYXJjaCAyMDE4IGF0IDE2OjA5DQo+ IA0KPiBIaSwNCj4gDQo+IEkgZ3Vlc3MgQXJpIHdpbGwgcmVwbHksIGJ1dCBteSB1bmRlcnN0YW5k aW5nIGlzIHRoYXQsIHNpbmNlIHRyaWdnZXJlZCBjaGVja3MgaGF2ZSBoaWdoIHByaW9yaXR5LCB3 ZSB3YW50IHRoZSB0cmlnZ2VyZWQgYmluZGluZyByZXF1ZXN0cyB0byBiZSBzZW50IGFzYXAuIEJ1 dCwgaWYgdGhlIG9uZ29pbmcgdHJhbnNhY3Rpb24gKEluLVByb2dyZXNzKSBoYXMgYWxyZWFkeSBi ZWVuIGdvaW5nIG9uIGZvciBhIHdoaWxlLCBhbmQgYWxsIHRyYW5zbWl0dGVkL3JlLXRyYW5zbWl0 dGVkIGJpbmRpbmcgcmVxdWVzdHMgc28gZmFyIGZvciB3aGF0ZXZlciByZWFzb24gaGF2ZSBnb3Qg ZHJvcHBlZCBpbiB0aGUgbmV0d29yaywgZHVlIHRvIHRoZSBjdXJyZW50IHJlLXRyYW5zbWlzc2lv biB0aW1lciAod2hpY2ggZ3Jvd3MgYWZ0ZXIgZWFjaCByZS10cmFuc21pc3Npb24pIGl0IG1heSB0 YWtlIGEgd2hpbGUgYmVmb3JlIGJpbmRpbmcgY2hlY2sgaXMgcmUtdHJhbnNtaXR0ZWQgYWdhaW4u IA0KPiANCj4gKE9mIGNvdXJzZSwgZXZlbiBpZiB3ZSBjcmVhdGUgYSBuZXcgdHJhbnNhY3Rpb24s IHRoZXJlIG1heSBiZSBvdGhlciBjaGVja3Mgd2FpdGluZyBpbiB0aGUgdHJpZ2dlcmVkIGNoZWNr IHF1ZXVlLCBzbyBpdCBtYXkgc3RpbGwgdGFrZSBhIHdoaWxlIGJlZm9yZSB0aGUgbmV3IGJpbmRp bmcgY2hlY2sgaXMgc2VudC4pDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCj4gDQo+ IEZyb206IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4NCj4gRGF0ZTogVGh1cnNkYXkgMSBN YXJjaCAyMDE4IGF0IDE1OjMxDQo+IFRvOiBBcmkgS2Vyw6RuZW4gPGFyaS5rZXJhbmVuQGVyaWNz c29uLmNvbT4NCj4gQ2M6IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20+LCAiaWVzZ0BpZXRmLm9yZyIgPGllc2dAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1p Y2UtcmZjNTI0NWJpc0BpZXRmLm9yZyIgPGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5v cmc+LCAiaWNlLWNoYWlyc0BpZXRmLm9yZyIgPGljZS1jaGFpcnNAaWV0Zi5vcmc+LCAicHRoYXRj aGVyQGdvb2dsZS5jb20iIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbT4sICJpY2VAaWV0Zi5vcmciIDxp Y2VAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBFcmljIFJlc2NvcmxhJ3MgTm8gT2JqZWN0aW9u IG9uIGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMtMTc6ICh3aXRoIENPTU1FTlQpIChleGNsdWRp bmcgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMpDQo+IA0KPiANCj4gDQo+IE9uIFRodSwgTWFyIDEs IDIwMTggYXQgMTI6NTggQU0sIEFyaSBLZXLDpG5lbiA8YXJpLmtlcmFuZW5AZXJpY3Nzb24uY29t PiB3cm90ZToNCj4+IEhpIEVyaWMgJiBDaHJpc3RlciwNCj4+IA0KPj4gPiBPbiAxOSBGZWIgMjAx OCwgYXQgMTYuNDIsIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4gd3JvdGU6DQo+PiA+DQo+ PiA+DQo+PiA+DQo+PiA+ID4gICAgICAgICBpbi1wcm9ncmVzcyB0cmFuc2FjdGlvbi4gIENhbmNl bGxhdGlvbiBtZWFucyB0aGF0IHRoZSBhZ2VudA0KPj4gPiA+ICAgICAgICAgd2lsbCBub3QgcmV0 cmFuc21pdCB0aGUgcmVxdWVzdCwgd2lsbCBub3QgdHJlYXQgdGhlIGxhY2sgb2YNCj4+ID4gPiAg ICAgICAgIHJlc3BvbnNlIHRvIGJlIGEgZmFpbHVyZSwgYnV0IHdpbGwgd2FpdCB0aGUgZHVyYXRp b24gb2YgdGhlDQo+PiA+ID4NCj4+ID4gPiBXaHkgYXJlIHlvdSBjYW5jZWxsaW5nIEluLVByb2dy ZXNzIGNoZWNrcyB3aGVuIHlvdSByZWNlaXZlIGEgcGVlci1yZWZsZWN0aXZlIGNoZWNrPw0KPj4g PiA+IElmIHlvdSByZWNlaXZlIHR3byBpbiBhIHJvdywgdGhlbiBpdCBzZWVtcyBsaWtlIHRoaXMg ZGVsYXlzIGEgc3VjY2Vzc2Z1bCBjaGVjay4NCj4+ID4NCj4+ID4gVHJ1ZS4NCj4+ID4NCj4+ID4g U28sIEkgd2lsbCByZW1vdmUgdGhlIGNhbmNlbCBwYXJ0Lg0KPj4gPg0KPj4gPiBEbyB5b3Ugc3Rp bGwgdGhpbmsgaXQgc2hvdWxkIGNyZWF0ZSBhIG5ldyBiaW5kaW5nIHJlcXVlc3QsIG9yIGlzIHRo ZSBvbmdvaW5nIEluLVByb2dyZXNzIGNoZWNrIGVub3VnaCB0byBjaGVjayB0aGUgcGFpcj8NCj4+ ID4NCj4+ID4gTXkgaW5pdGlhbCByZWFjdGlvbiBpcyB5b3UgZG9uJ3QgbmVlZCB0byBkbyBhbnl0 aGluZyBleHRyYSwgYnV0IEkgY291bGQgZWFzaWx5IGJlIHdyb25nIGhlcmUuDQo+PiANCj4+IEkn bSBhZnJhaWQgdGhpcyBpcyBvbmUgb2YgdGhlIHBhcnRzIG9mIHRoZSBzcGVjIHRoYXQgc29sdmVz IGEgY29ybmVyIGNhc2UgaW4gYW4gaW50ZXJlc3RpbmcgYnV0IG5vbi1vYnZpb3VzIHdheS4gRm9y IGNvbnRleHQsIGhlcmUncyB0aGUgb3JpZ2luYWwgdGV4dDoNCj4+IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1MjQ1I3NlY3Rpb24tNy4yLjEuNA0KPj4gDQo+PiBJSVJDLCBvbmUgb2Yg dGhlIHJlYXNvbnMgZm9yIHRoaXMgaXMgdGhhdCBhbiBhZ2VudCBtaWdodCBoYXZlIHN0YXJ0ZWQg dGhlIHRyYW5zYWN0aW9uIGEgd2hpbGUgYWdvLCBwZXJoYXBzIGV2ZW4gc2VudCBhIGZldyByZS10 cmFuc21pc3Npb25zLiBOb3csIGlmIHlvdSBkb24ndCBjYW5jZWwgdGhhdCB0cmFuc2FjdGlvbiwg YnV0IGp1c3Qga2VlcCB0aGF0IGdvaW5nIGFuZCBzZW5kIHRoZSByZW1haW5pbmcgcmUtdHJhbnNt aXNzaW9uKHMpIGFuZCB0aG9zZSBhcmUgbG9zdCBkdWUgdG8gYmFkIG5ldHdvcmsgY29ubmVjdGl2 aXR5LCB5b3UgZW5kIHVwIG1hcmtpbmcgdGhhdCBwYWlyIGFzIGZhaWxlZC4gSG93ZXZlciwgaWYg eW91IGNhbmNlbCBhbmQgc3RhcnQgYSBuZXcgdHJhbnNhY3Rpb24sIHlvdSBoYXZlIGZ1bGwgYW1v dW50IG9mIGZhc3QgcmV0cmFuc21pc3Npb25zIHRvIGdvLiBBbmQgaWYgeW91IHJlY2VpdmUgYSBy ZXBseSB0byBhIGNhbmNlbGxlZCBjaGVjaywgaXQgaXMgc3RpbGwgYSBzdWNjZXNzLiBJIHJlbWVt YmVyIHRoaXMgd2FzIHVuaW50dWl0aXZlIGJ1dCBldmVudHVhbGx5IG1hZGUgc2Vuc2Ugd2hlbiBJ IGltcGxlbWVudGVkIGl0Lg0KPj4gDQo+PiBTbywgSSdkIHJlY29tbWVuZCB3ZSBrZWVwIHRoaXMg dGV4dCBhcyBzdWNoLg0KPiANCj4gV2h5IGlzIHRoaXMgZGlmZmVyZW50IGZyb20gYW55IG90aGVy IGNhc2Ugb2YgdHJhbnNpZW50IGZhaWx1cmU/DQo+IA0KPiAtRWtyDQo+IA0KPj4gDQo+PiANCj4+ IENoZWVycywNCj4+IEFyaSAoaGF0IG9mZikNCj4gDQoNCg== From nobody Fri Mar 2 06:48:32 2018 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 909F8129C6B for ; Fri, 2 Mar 2018 06:48:22 -0800 (PST) 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isHsKRQZUMwv for ; Fri, 2 Mar 2018 06:48:20 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35D412DA18 for ; Fri, 2 Mar 2018 06:48:12 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id d26so12130311qtk.10 for ; Fri, 02 Mar 2018 06:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fd1RN/OCUmU3URjlQnMvTbKjNCmw8+wXd5gHMMK+wGU=; b=Qf/b70viNVELwNNbkz9iLU36emH8Quzhbg4HMnunDRPqYF1+IaGiaZ2mStiG4yHVA+ lXcbpCw960rQX1ieMlGnCkGkkx1eaTbXmOHNTV/ZRlOlfOAlyFtWsS6iGFZRFn9EOw2a xQJCpp0+b35lV0XmCgwhG0eEmCVxCrutERNyag2be4hF87hjsVLNis+p4Q7wEpQZkapf 4UivoFaO4l5C24Sx+l7HifNb5mciu9ndHvcuYJRbTe1EiOhA92YSonNrb12v7J8U/JEG 77N4etyiEGBDhD2GVvDCkQjqTthARdkaTc/0bC95XCVYfdVqcEbFVnT+PUB/j3d1DzHY IlEA== 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=Fd1RN/OCUmU3URjlQnMvTbKjNCmw8+wXd5gHMMK+wGU=; b=pdL/LKlng15JVjgfb1pexWqpakaKGfAfZ5zCDP1jDtBiSfs06MZcH0LgxD+yngVcm5 O7hLX6Gxh6KQ86e2WTqThJ1yJEyZZ2qawiIav0WvQOypzu6aVHg9tidVHzBc/MF1mdAp +a0kujAwjz6IZ9DQthuVPi6lbIRvK/cAlv/QUCSZ66xqzflUfnoTXZyCZaGcwr/UroC/ h3qzBpMU1WJMXkTDbXfXSdpy/tBGiGoYl3nyLaeuFXP5XdqRxbguW9VGjofp7sJmza0l 1GW72QbVG9BbM9NjxjN749xMGoPbZJh11a1FiEuRFECRrdBaFUxpoY8duhM43EkhcTHq AFfA== X-Gm-Message-State: AElRT7FVUCvNW5WTJ0ITkWtpvxjCRlwAWu0/tWfcfqVsq0WXK5ZQ2pPq C/PFsWNZ1RgdV/998HTFj/eWsykdudXvWbfCQ2dKEw== X-Google-Smtp-Source: AG47ELtS6sn+LOTHw6voacyOuB9hAXrhrAS3BJaJLUPaOUHWtwcG+QPpxMLM7pfmtm/LeNrD7HsEQrgMqojzDapDjQc= X-Received: by 10.237.56.34 with SMTP id j31mr9072858qte.208.1520002091827; Fri, 02 Mar 2018 06:48:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Fri, 2 Mar 2018 06:47:31 -0800 (PST) In-Reply-To: <809A44FC-84EF-49FE-8DFA-4F2552140C39@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se> <809A44FC-84EF-49FE-8DFA-4F2552140C39@ericsson.com> From: Eric Rescorla Date: Fri, 2 Mar 2018 06:47:31 -0800 Message-ID: To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Cc: Christer Holmberg , The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , Peter Thatcher , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a113b7f18bea82a05666f103b" Archived-At: Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) 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, 02 Mar 2018 14:48:26 -0000 --001a113b7f18bea82a05666f103b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ari Well, this is a nonblocking comment, so fo as you please, but I think that at minimum this is a confusing behavior and it's the job of the document to explain it. On Fri, Mar 2, 2018 at 6:24 AM, Ari Ker=C3=A4nen wrote: > I agree with what you wrote below. I think the best way forward is to kee= p > the text as it was in -17. Anyway it was part of the original RFC5245 tex= t > and as discussed earlier, when in doubt, it's better we don't change the > text and accidentally change the behavior for the worse. > > > Cheers, > Ari > > > On 2 Mar 2018, at 15.17, Christer Holmberg com> wrote: > > > > So, what to do? > > > > From: Christer Holmberg > > Date: Thursday 1 March 2018 at 16:09 > > To: Eric Rescorla , Ari Ker=C3=A4nen > > Cc: "iesg@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.or= g" > , "ice-chairs@ietf.org" < > ice-chairs@ietf.org>, "pthatcher@google.com" , " > ice@ietf.org" > > Subject: Re: Eric Rescorla's No Objection on > draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security > Considerations) > > Resent-From: > > Resent-To: Ari Ker=C3=A4nen , Christer Holmbe= rg < > christer.holmberg@ericsson.com>, "jdrosen@jdrosen.net" < > jdrosen@jdrosen.net> > > Resent-Date: Thursday 1 March 2018 at 16:09 > > > > Hi, > > > > I guess Ari will reply, but my understanding is that, since triggered > checks have high priority, we want the triggered binding requests to be > sent asap. But, if the ongoing transaction (In-Progress) has already been > going on for a while, and all transmitted/re-transmitted binding requests > so far for whatever reason have got dropped in the network, due to the > current re-transmission timer (which grows after each re-transmission) it > may take a while before binding check is re-transmitted again. > > > > (Of course, even if we create a new transaction, there may be other > checks waiting in the triggered check queue, so it may still take a while > before the new binding check is sent.) > > > > Regards, > > > > Christer > > > > From: Eric Rescorla > > Date: Thursday 1 March 2018 at 15:31 > > To: Ari Ker=C3=A4nen > > Cc: Christer Holmberg , "iesg@ietf.org" > , "draft-ietf-ice-rfc5245bis@ietf.org" < > draft-ietf-ice-rfc5245bis@ietf.org>, "ice-chairs@ietf.org" < > ice-chairs@ietf.org>, "pthatcher@google.com" , " > ice@ietf.org" > > Subject: Re: Eric Rescorla's No Objection on > draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security > Considerations) > > > > > > > > On Thu, Mar 1, 2018 at 12:58 AM, Ari Ker=C3=A4nen > wrote: > >> Hi Eric & Christer, > >> > >> > On 19 Feb 2018, at 16.42, Eric Rescorla wrote: > >> > > >> > > >> > > >> > > in-progress transaction. Cancellation means that the agen= t > >> > > will not retransmit the request, will not treat the lack o= f > >> > > response to be a failure, but will wait the duration of th= e > >> > > > >> > > Why are you cancelling In-Progress checks when you receive a > peer-reflective check? > >> > > If you receive two in a row, then it seems like this delays a > successful check. > >> > > >> > True. > >> > > >> > So, I will remove the cancel part. > >> > > >> > Do you still think it should create a new binding request, or is the > ongoing In-Progress check enough to check the pair? > >> > > >> > My initial reaction is you don't need to do anything extra, but I > could easily be wrong here. > >> > >> I'm afraid this is one of the parts of the spec that solves a corner > case in an interesting but non-obvious way. For context, here's the > original text: > >> https://tools.ietf.org/html/rfc5245#section-7.2.1.4 > >> > >> IIRC, one of the reasons for this is that an agent might have started > the transaction a while ago, perhaps even sent a few re-transmissions. No= w, > if you don't cancel that transaction, but just keep that going and send t= he > remaining re-transmission(s) and those are lost due to bad network > connectivity, you end up marking that pair as failed. However, if you > cancel and start a new transaction, you have full amount of fast > retransmissions to go. And if you receive a reply to a cancelled check, i= t > is still a success. I remember this was unintuitive but eventually made > sense when I implemented it. > >> > >> So, I'd recommend we keep this text as such. > > > > Why is this different from any other case of transient failure? > > > > -Ekr > > > >> > >> > >> Cheers, > >> Ari (hat off) > > > > --001a113b7f18bea82a05666f103b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ari

Well, this is a nonblock= ing comment, so fo as you please, but I think that at minimum this is a con= fusing behavior and it's the job of the document to explain it.

On Fri, Mar 2= , 2018 at 6:24 AM, Ari Ker=C3=A4nen <ari.keranen@ericsson.com&g= t; wrote:
I agree with what you wr= ote below. I think the best way forward is to keep the text as it was in -1= 7. Anyway it was part of the original RFC5245 text and as discussed earlier= , when in doubt, it's better we don't change the text and accidenta= lly change the behavior for the worse.


Cheers,
Ari

> On 2 Mar 2018, at 15.17, Christer Holmberg <christer.holmberg@ericsson.com> wrot= e:
>
> So, what to do?
>
> From: Christer Holmberg <christer.holmberg@ericsson.com>
> Date: Thursday 1 March 2018 at 16:09
> To: Eric Rescorla <ekr@rtfm.com= >, Ari Ker=C3=A4nen <ari.= keranen@ericsson.com>
> Cc: "iesg@ietf.org" <= ;iesg@ietf.org>, "draft-ietf-ice-rfc5245bis@ie= tf.org" <= draft-ietf-ice-rfc5245bis@ietf.org>, "ice-chairs@ietf.org" <ice-chairs@ietf.org>, "pthatcher@google.com" <pthatcher@google.com>, "ice@ietf.org" <ice@ie= tf.org>
> Subject: Re: Eric Rescorla's No Objection on draft-ietf-ice-rfc524= 5bis-17: (with COMMENT) (excluding Security Considerations)
> Resent-From: <alias-bounc= es@ietf.org>
> Resent-To: Ari Ker=C3=A4nen <ari.keranen@ericsson.com>, Christer Holmberg <christer.holmberg@ericsson.com>, "jdrosen@jdrosen.net= " <jdrosen@jdrosen.net&g= t;
> Resent-Date: Thursday 1 March 2018 at 16:09
>
> Hi,
>
> I guess Ari will reply, but my understanding is that, since triggered = checks have high priority, we want the triggered binding requests to be sen= t asap. But, if the ongoing transaction (In-Progress) has already been goin= g on for a while, and all transmitted/re-transmitted binding requests so fa= r for whatever reason have got dropped in the network, due to the current r= e-transmission timer (which grows after each re-transmission) it may take a= while before binding check is re-transmitted again.
>
> (Of course, even if we create a new transaction, there may be other ch= ecks waiting in the triggered check queue, so it may still take a while bef= ore the new binding check is sent.)
>
> Regards,
>
> Christer
>
> From: Eric Rescorla <ekr@rtfm.com>
> Date: Thursday 1 March 2018 at 15:31
> To: Ari Ker=C3=A4nen <a= ri.keranen@ericsson.com>
> Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ice-rfc5245bis@ietf.org" <draft-ietf-ice-rfc5245bis@ie= tf.org>, "ice-chairs@iet= f.org" <ice-chairs@ietf.= org>, "pthatcher@google= .com" <pthatcher@google= .com>, "ice@ietf.org" = <ice@ietf.org>
> Subject: Re: Eric Rescorla's No Objection on draft-ietf-ice-rfc524= 5bis-17: (with COMMENT) (excluding Security Considerations)
>
>
>
> On Thu, Mar 1, 2018 at 12:58 AM, Ari Ker=C3=A4nen <ari.keranen@ericsson.com> wrote:
>> Hi Eric & Christer,
>>
>> > On 19 Feb 2018, at 16.42, Eric Rescorla <ekr@rtfm.com> wrote:
>> >
>> >
>> >
>> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in-progress transaction= .=C2=A0 Cancellation means that the agent
>> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will not retransmit the= request, will not treat the lack of
>> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0response to be a failur= e, but will wait the duration of the
>> > >
>> > > Why are you cancelling In-Progress checks when you recei= ve a peer-reflective check?
>> > > If you receive two in a row, then it seems like this del= ays a successful check.
>> >
>> > True.
>> >
>> > So, I will remove the cancel part.
>> >
>> > Do you still think it should create a new binding request, or= is the ongoing In-Progress check enough to check the pair?
>> >
>> > My initial reaction is you don't need to do anything extr= a, but I could easily be wrong here.
>>
>> I'm afraid this is one of the parts of the spec that solves a = corner case in an interesting but non-obvious way. For context, here's = the original text:
>> https://tools.ietf.org/html/rfc5245= #section-7.2.1.4
>>
>> IIRC, one of the reasons for this is that an agent might have star= ted the transaction a while ago, perhaps even sent a few re-transmissions. = Now, if you don't cancel that transaction, but just keep that going and= send the remaining re-transmission(s) and those are lost due to bad networ= k connectivity, you end up marking that pair as failed. However, if you can= cel and start a new transaction, you have full amount of fast retransmissio= ns to go. And if you receive a reply to a cancelled check, it is still a su= ccess. I remember this was unintuitive but eventually made sense when I imp= lemented it.
>>
>> So, I'd recommend we keep this text as such.
>
> Why is this different from any other case of transient failure?
>
> -Ekr
>
>>
>>
>> Cheers,
>> Ari (hat off)
>


--001a113b7f18bea82a05666f103b-- From nobody Fri Mar 2 07:40:35 2018 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 AB94E12DA70 for ; Fri, 2 Mar 2018 07:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 exBTe5VN-ZLA for ; Fri, 2 Mar 2018 07:40:22 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF1E212DA6D for ; Fri, 2 Mar 2018 07:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520005219; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NR1nuSxZbyi2FV3xvK8LrOgZJmq54s65tx6Q8XSGZXo=; b=LAGf7CY9LImCa9oB+YTCaZPQcaGoYt2nXVrnqh0VGbwWBMIsxKz1TYBsuTwGHeWH aEV+jtMQCRtPL7A/0vYoNlzrEcBJCjo6ilpnGf5ZXs4MFHd3WXSXVy0E7Vx20hrC q0buMOf57avpVj8yb2tNgElIPhvLjqAYtsSIMkrNx14=; X-AuditID: c1b4fb2d-4b1ff70000005540-7d-5a9970637700 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 87.13.21824.360799A5; Fri, 2 Mar 2018 16:40:19 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Fri, 2 Mar 2018 16:40:18 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Eric Rescorla CC: Christer Holmberg , The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , Peter Thatcher , "ice@ietf.org" Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) Thread-Index: AdOpa677O8VqdAW5ThyXNM/NhWOUGQAG8xsAAerqwYAACYXUgAAF+QMAADB64QD//+1mAIAABoSAgAAOvoA= Date: Fri, 2 Mar 2018 15:40:17 +0000 Message-ID: <84116E2C-C1AA-4560-92CA-B8CA3A07CB78@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se> <809A44FC-84EF-49FE-8DFA-4F2552140C39@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.95.226.8] Content-Type: text/plain; charset="utf-8" Content-ID: <66A511CB47D0934398E210A6F64CB627@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2K7h25ywcwog6WPTCzmn7zObLHi9Tl2 i4uzJrNZfLtQazHjz0Rmi2vLX7M6sHks2FTqsWTJTyaPyY/bmAOYo7hsUlJzMstSi/TtErgy 5i3vYyvYY13x+cYNxgbGH5ZdjJwcEgImEnc3r2XvYuTiEBI4zCjx7vcpFghnEaPEzaWtrCBV bAK2Ek9a94HZIgIKEr/+nAArYhaYxiRx4PwuRpCEsEC9xMwFx1lBEiICDYwSXy5NgepIkpiw fQsTiM0ioCLR9ncTC4jNK2AvsfLRAmaIdZ+YJT7e/g5WxCkQKHHiG8RURgExie+n1oDFmQXE JW49mc8EcbiAxJI955khbFGJl4//sULY8hIzzt4CquEAqteUWL9LH6LVWuLahx3MELaixJTu h+wQNwhKnJz5hGUCo9gsJBtmIXTPQtI9C0n3LCTdCxhZVzGKFqcWF+emGxnrpRZlJhcX5+fp 5aWWbGIERuLBLb91dzCufu14iFGAg1GJhzcwa2aUEGtiWXFl7iFGCQ5mJRHelg8zooR4UxIr q1KL8uOLSnNSiw8xSnOwKInznvTkjRISSE8sSc1OTS1ILYLJMnFwSjUwTua3blPTMt3Q2+np WjdHXkhiOpfTPU/OO9/mdv2ILPDr5/gk8+XZhdkO/z5M3v09ply7UURv8Q/1p9K3WBpeFTgm V/JO/DPnvfnytIPugl3sq1XO2mx3aDt/bc1K+6zgy1Ln4k95+6ZYHFarXP53PdfECpttkh3S 16ste5erPP208WzaQkVfJZbijERDLeai4kQAEY2dxsACAAA= Archived-At: Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) 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, 02 Mar 2018 15:40:33 -0000 SGkgRXJpYywNCg0KTWF5YmUgdGhlIHNwZWNpZmljIGJ1bGxldCBjb3VsZCBhbHNvIGJlIGF1Z21l bnRlZCB3aXRoIHNvbWV0aGluZyBsaWtlOiAiVGhpcyBlbmFibGVzIHZhbGlkYXRpbmcgSW4tUHJv Z3Jlc3MgcGFpcnMgYXMgc29vbiBhcyBwb3NzaWJsZSwgd2l0aG91dCBoYXZpbmcgdG8gd2FpdCBm b3IgcmUtdHJhbnNtaXNzaW9ucyBvZiB0aGUgb3JpZ2luYWwgdHJhbnNhY3Rpb24uIg0KDQpXb3Vs ZCB0aGF0IGNsYXJpZnkgdGhpcyBzdWZmaWNpZW50bHk/DQoNCk5vdGUgdGhhdCBhIHJlc3BvbnNl IHRvIGEgY2FuY2VsbGVkIGNoZWNrIGFsc28gc3RpbGwgcXVhbGlmaWVzIGFzIGEgc3VjY2Vzc2Z1 bCBjaGVjay4gT25seSB0aGUgcmV0cmFuc21pc3Npb25zIGFuZCAiZmFpbCB0aGlzIGNhbmRpZGF0 ZSBpZiBubyBhbnN3ZXIiIGJlaGF2aW9yIGlzIGNhbmNlbGxlZCwgc28gdGhlcmUgaXMgbm8gZXh0 cmEgZGVsYXkgYmVjYXVzZSBvZiB0aGlzIGJlaGF2aW9yIGV2ZW4gaWYgdGhlIG9yaWdpbmFsIGNo ZWNrIHdvdWxkIGV2ZW50dWFsbHkgc3VjY2VlZC4gVGhlIHRleHQgc2F5cyBhYm91dCBjYW5jZWwg Y2FzZTogIlsuLi5dIGJ1dCB3aWxsIHdhaXQgdGhlIGR1cmF0aW9uIG9mIHRyYW5zYWN0aW9uIHRp bWVvdXQgZm9yIGEgcmVzcG9uc2UiLg0KDQoNCkNoZWVycywNCkFyaQ0KDQo+IE9uIDIgTWFyIDIw MTgsIGF0IDE2LjQ3LCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+IHdyb3RlOg0KPiANCj4g QXJpDQo+IA0KPiBXZWxsLCB0aGlzIGlzIGEgbm9uYmxvY2tpbmcgY29tbWVudCwgc28gZm8gYXMg eW91IHBsZWFzZSwgYnV0IEkgdGhpbmsgdGhhdCBhdCBtaW5pbXVtIHRoaXMgaXMgYSBjb25mdXNp bmcgYmVoYXZpb3IgYW5kIGl0J3MgdGhlIGpvYiBvZiB0aGUgZG9jdW1lbnQgdG8gZXhwbGFpbiBp dC4NCj4gDQo+IE9uIEZyaSwgTWFyIDIsIDIwMTggYXQgNjoyNCBBTSwgQXJpIEtlcsOkbmVuIDxh cmkua2VyYW5lbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPiBJIGFncmVlIHdpdGggd2hhdCB5b3Ug d3JvdGUgYmVsb3cuIEkgdGhpbmsgdGhlIGJlc3Qgd2F5IGZvcndhcmQgaXMgdG8ga2VlcCB0aGUg dGV4dCBhcyBpdCB3YXMgaW4gLTE3LiBBbnl3YXkgaXQgd2FzIHBhcnQgb2YgdGhlIG9yaWdpbmFs IFJGQzUyNDUgdGV4dCBhbmQgYXMgZGlzY3Vzc2VkIGVhcmxpZXIsIHdoZW4gaW4gZG91YnQsIGl0 J3MgYmV0dGVyIHdlIGRvbid0IGNoYW5nZSB0aGUgdGV4dCBhbmQgYWNjaWRlbnRhbGx5IGNoYW5n ZSB0aGUgYmVoYXZpb3IgZm9yIHRoZSB3b3JzZS4NCj4gDQo+IA0KPiBDaGVlcnMsDQo+IEFyaQ0K PiANCj4gPiBPbiAyIE1hciAyMDE4LCBhdCAxNS4xNywgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBTbywgd2hhdCB0byBk bz8NCj4gPg0KPiA+IEZyb206IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20+DQo+ID4gRGF0ZTogVGh1cnNkYXkgMSBNYXJjaCAyMDE4IGF0IDE2OjA5DQo+ ID4gVG86IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4sIEFyaSBLZXLDpG5lbiA8YXJpLmtl cmFuZW5AZXJpY3Nzb24uY29tPg0KPiA+IENjOiAiaWVzZ0BpZXRmLm9yZyIgPGllc2dAaWV0Zi5v cmc+LCAiZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpc0BpZXRmLm9yZyIgPGRyYWZ0LWlldGYtaWNl LXJmYzUyNDViaXNAaWV0Zi5vcmc+LCAiaWNlLWNoYWlyc0BpZXRmLm9yZyIgPGljZS1jaGFpcnNA aWV0Zi5vcmc+LCAicHRoYXRjaGVyQGdvb2dsZS5jb20iIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbT4s ICJpY2VAaWV0Zi5vcmciIDxpY2VAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IEVyaWMgUmVz Y29ybGEncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcy0xNzogKHdp dGggQ09NTUVOVCkgKGV4Y2x1ZGluZyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucykNCj4gPiBSZXNl bnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQo+ID4gUmVzZW50LVRvOiBBcmkgS2Vy w6RuZW4gPGFyaS5rZXJhbmVuQGVyaWNzc29uLmNvbT4sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+LCAiamRyb3NlbkBqZHJvc2VuLm5ldCIgPGpkcm9z ZW5AamRyb3Nlbi5uZXQ+DQo+ID4gUmVzZW50LURhdGU6IFRodXJzZGF5IDEgTWFyY2ggMjAxOCBh dCAxNjowOQ0KPiA+DQo+ID4gSGksDQo+ID4NCj4gPiBJIGd1ZXNzIEFyaSB3aWxsIHJlcGx5LCBi dXQgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0LCBzaW5jZSB0cmlnZ2VyZWQgY2hlY2tzIGhhdmUg aGlnaCBwcmlvcml0eSwgd2Ugd2FudCB0aGUgdHJpZ2dlcmVkIGJpbmRpbmcgcmVxdWVzdHMgdG8g YmUgc2VudCBhc2FwLiBCdXQsIGlmIHRoZSBvbmdvaW5nIHRyYW5zYWN0aW9uIChJbi1Qcm9ncmVz cykgaGFzIGFscmVhZHkgYmVlbiBnb2luZyBvbiBmb3IgYSB3aGlsZSwgYW5kIGFsbCB0cmFuc21p dHRlZC9yZS10cmFuc21pdHRlZCBiaW5kaW5nIHJlcXVlc3RzIHNvIGZhciBmb3Igd2hhdGV2ZXIg cmVhc29uIGhhdmUgZ290IGRyb3BwZWQgaW4gdGhlIG5ldHdvcmssIGR1ZSB0byB0aGUgY3VycmVu dCByZS10cmFuc21pc3Npb24gdGltZXIgKHdoaWNoIGdyb3dzIGFmdGVyIGVhY2ggcmUtdHJhbnNt aXNzaW9uKSBpdCBtYXkgdGFrZSBhIHdoaWxlIGJlZm9yZSBiaW5kaW5nIGNoZWNrIGlzIHJlLXRy YW5zbWl0dGVkIGFnYWluLg0KPiA+DQo+ID4gKE9mIGNvdXJzZSwgZXZlbiBpZiB3ZSBjcmVhdGUg YSBuZXcgdHJhbnNhY3Rpb24sIHRoZXJlIG1heSBiZSBvdGhlciBjaGVja3Mgd2FpdGluZyBpbiB0 aGUgdHJpZ2dlcmVkIGNoZWNrIHF1ZXVlLCBzbyBpdCBtYXkgc3RpbGwgdGFrZSBhIHdoaWxlIGJl Zm9yZSB0aGUgbmV3IGJpbmRpbmcgY2hlY2sgaXMgc2VudC4pDQo+ID4NCj4gPiBSZWdhcmRzLA0K PiA+DQo+ID4gQ2hyaXN0ZXINCj4gPg0KPiA+IEZyb206IEVyaWMgUmVzY29ybGEgPGVrckBydGZt LmNvbT4NCj4gPiBEYXRlOiBUaHVyc2RheSAxIE1hcmNoIDIwMTggYXQgMTU6MzENCj4gPiBUbzog QXJpIEtlcsOkbmVuIDxhcmkua2VyYW5lbkBlcmljc3Nvbi5jb20+DQo+ID4gQ2M6IENocmlzdGVy IEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+LCAiaWVzZ0BpZXRmLm9y ZyIgPGllc2dAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpc0BpZXRmLm9yZyIg PGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmc+LCAiaWNlLWNoYWlyc0BpZXRmLm9y ZyIgPGljZS1jaGFpcnNAaWV0Zi5vcmc+LCAicHRoYXRjaGVyQGdvb2dsZS5jb20iIDxwdGhhdGNo ZXJAZ29vZ2xlLmNvbT4sICJpY2VAaWV0Zi5vcmciIDxpY2VAaWV0Zi5vcmc+DQo+ID4gU3ViamVj dDogUmU6IEVyaWMgUmVzY29ybGEncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1pY2UtcmZj NTI0NWJpcy0xNzogKHdpdGggQ09NTUVOVCkgKGV4Y2x1ZGluZyBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucykNCj4gPg0KPiA+DQo+ID4NCj4gPiBPbiBUaHUsIE1hciAxLCAyMDE4IGF0IDEyOjU4IEFN LCBBcmkgS2Vyw6RuZW4gPGFyaS5rZXJhbmVuQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+ID4+IEhp IEVyaWMgJiBDaHJpc3RlciwNCj4gPj4NCj4gPj4gPiBPbiAxOSBGZWIgMjAxOCwgYXQgMTYuNDIs IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4gd3JvdGU6DQo+ID4+ID4NCj4gPj4gPg0KPiA+ PiA+DQo+ID4+ID4gPiAgICAgICAgIGluLXByb2dyZXNzIHRyYW5zYWN0aW9uLiAgQ2FuY2VsbGF0 aW9uIG1lYW5zIHRoYXQgdGhlIGFnZW50DQo+ID4+ID4gPiAgICAgICAgIHdpbGwgbm90IHJldHJh bnNtaXQgdGhlIHJlcXVlc3QsIHdpbGwgbm90IHRyZWF0IHRoZSBsYWNrIG9mDQo+ID4+ID4gPiAg ICAgICAgIHJlc3BvbnNlIHRvIGJlIGEgZmFpbHVyZSwgYnV0IHdpbGwgd2FpdCB0aGUgZHVyYXRp b24gb2YgdGhlDQo+ID4+ID4gPg0KPiA+PiA+ID4gV2h5IGFyZSB5b3UgY2FuY2VsbGluZyBJbi1Q cm9ncmVzcyBjaGVja3Mgd2hlbiB5b3UgcmVjZWl2ZSBhIHBlZXItcmVmbGVjdGl2ZSBjaGVjaz8N Cj4gPj4gPiA+IElmIHlvdSByZWNlaXZlIHR3byBpbiBhIHJvdywgdGhlbiBpdCBzZWVtcyBsaWtl IHRoaXMgZGVsYXlzIGEgc3VjY2Vzc2Z1bCBjaGVjay4NCj4gPj4gPg0KPiA+PiA+IFRydWUuDQo+ ID4+ID4NCj4gPj4gPiBTbywgSSB3aWxsIHJlbW92ZSB0aGUgY2FuY2VsIHBhcnQuDQo+ID4+ID4N Cj4gPj4gPiBEbyB5b3Ugc3RpbGwgdGhpbmsgaXQgc2hvdWxkIGNyZWF0ZSBhIG5ldyBiaW5kaW5n IHJlcXVlc3QsIG9yIGlzIHRoZSBvbmdvaW5nIEluLVByb2dyZXNzIGNoZWNrIGVub3VnaCB0byBj aGVjayB0aGUgcGFpcj8NCj4gPj4gPg0KPiA+PiA+IE15IGluaXRpYWwgcmVhY3Rpb24gaXMgeW91 IGRvbid0IG5lZWQgdG8gZG8gYW55dGhpbmcgZXh0cmEsIGJ1dCBJIGNvdWxkIGVhc2lseSBiZSB3 cm9uZyBoZXJlLg0KPiA+Pg0KPiA+PiBJJ20gYWZyYWlkIHRoaXMgaXMgb25lIG9mIHRoZSBwYXJ0 cyBvZiB0aGUgc3BlYyB0aGF0IHNvbHZlcyBhIGNvcm5lciBjYXNlIGluIGFuIGludGVyZXN0aW5n IGJ1dCBub24tb2J2aW91cyB3YXkuIEZvciBjb250ZXh0LCBoZXJlJ3MgdGhlIG9yaWdpbmFsIHRl eHQ6DQo+ID4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ1I3NlY3Rpb24tNy4y LjEuNA0KPiA+Pg0KPiA+PiBJSVJDLCBvbmUgb2YgdGhlIHJlYXNvbnMgZm9yIHRoaXMgaXMgdGhh dCBhbiBhZ2VudCBtaWdodCBoYXZlIHN0YXJ0ZWQgdGhlIHRyYW5zYWN0aW9uIGEgd2hpbGUgYWdv LCBwZXJoYXBzIGV2ZW4gc2VudCBhIGZldyByZS10cmFuc21pc3Npb25zLiBOb3csIGlmIHlvdSBk b24ndCBjYW5jZWwgdGhhdCB0cmFuc2FjdGlvbiwgYnV0IGp1c3Qga2VlcCB0aGF0IGdvaW5nIGFu ZCBzZW5kIHRoZSByZW1haW5pbmcgcmUtdHJhbnNtaXNzaW9uKHMpIGFuZCB0aG9zZSBhcmUgbG9z dCBkdWUgdG8gYmFkIG5ldHdvcmsgY29ubmVjdGl2aXR5LCB5b3UgZW5kIHVwIG1hcmtpbmcgdGhh dCBwYWlyIGFzIGZhaWxlZC4gSG93ZXZlciwgaWYgeW91IGNhbmNlbCBhbmQgc3RhcnQgYSBuZXcg dHJhbnNhY3Rpb24sIHlvdSBoYXZlIGZ1bGwgYW1vdW50IG9mIGZhc3QgcmV0cmFuc21pc3Npb25z IHRvIGdvLiBBbmQgaWYgeW91IHJlY2VpdmUgYSByZXBseSB0byBhIGNhbmNlbGxlZCBjaGVjaywg aXQgaXMgc3RpbGwgYSBzdWNjZXNzLiBJIHJlbWVtYmVyIHRoaXMgd2FzIHVuaW50dWl0aXZlIGJ1 dCBldmVudHVhbGx5IG1hZGUgc2Vuc2Ugd2hlbiBJIGltcGxlbWVudGVkIGl0Lg0KPiA+Pg0KPiA+ PiBTbywgSSdkIHJlY29tbWVuZCB3ZSBrZWVwIHRoaXMgdGV4dCBhcyBzdWNoLg0KPiA+DQo+ID4g V2h5IGlzIHRoaXMgZGlmZmVyZW50IGZyb20gYW55IG90aGVyIGNhc2Ugb2YgdHJhbnNpZW50IGZh aWx1cmU/DQo+ID4NCj4gPiAtRWtyDQo+ID4NCj4gPj4NCj4gPj4NCj4gPj4gQ2hlZXJzLA0KPiA+ PiBBcmkgKGhhdCBvZmYpDQo+ID4NCj4gDQo+IA0KDQo= From nobody Fri Mar 2 07:52:31 2018 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 35C7C129C6D for ; Fri, 2 Mar 2018 07:52:26 -0800 (PST) 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qmWmEWglWAC for ; Fri, 2 Mar 2018 07:52:24 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 E0173128959 for ; Fri, 2 Mar 2018 07:52:21 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id r16so12400519qtm.4 for ; Fri, 02 Mar 2018 07:52:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jKeAXuom9y5AXgcOfHVeb7TMZmVL59hsQa0P0jizgrw=; b=G/vHthjYNl90U8I7pYF6TmBGT5NkixTA9bw/M/sa3pkdKAh3i2HFkm/BOMRxqHnXzB hzYniWKOs9v0p1n7IN1o1YZkeZkiXYEG9s243Ea1eIV/z/8+L3moMcs5hFnaM+gyqTxI kNPWhB7Pg8D7VGCpCkSXKgiavyi8YIV2ual5b+4ZUdVYxVtYn2d/vEo00T6NIQfgVGNu Fm9BaswVRVNT1fu+mFXF2DkVGOljkR8tLzbVY4GkY7kx3uhQ9g+HI9TLbtdQu94bfMk2 6ScNHhJEcvJI3ZfFOWSGstH6aqg2BSgprSq2enXWX+U7t2m/W7t01HrWDp/nzK9k+vH+ a2pQ== 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=jKeAXuom9y5AXgcOfHVeb7TMZmVL59hsQa0P0jizgrw=; b=UpDkAhKsx9gePzF388/6Q4g+1UAF+k8yemEUVZm//vYGpYrnsWCkJeFqheGbLjRaZl MUvbdGcwh4N69MF7tAnNVBC/HRLKXasVI+eyofAlgVhUZKoCa+xx8mBVGhYnrI4t4Zxc OInKVGj4j2y2f2gvSIwAxZzku6gVti0HveLm3XP1qREvN1uvILAqMnzcamhtA5NaHGG6 ic3C+6W8RMeRoAbGYItpQKY+nQ37HXFcAVf2aFSxZYa7rB7c/zLLeT287YigoaUaABnl Nf9DVLrT9kUx0xeNrt3Hr64FjOyeBJDO+LrZU7sGLuprYFuaY04ngjvNPMH+KCANnAFm 2PoQ== X-Gm-Message-State: AElRT7EJT5PlOwljB1XSh2lHWcbSyMxmage1XV6ecLs7lfOpWf9OE6mu V7CWMx7K47+fGjfq2kGOzX89/jHEdh5GMdn6trJgJg== X-Google-Smtp-Source: AG47ELuFQqyheTQn4QoJ0K0XYJeYGU27zqDw74I6tY7DyuhcnVG9A8MsdOUQ/nMGhnfYywQSqNR6QY/nj2mVNWXAMCg= X-Received: by 10.200.42.177 with SMTP id b46mr9258339qta.321.1520005940978; Fri, 02 Mar 2018 07:52:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Fri, 2 Mar 2018 07:51:40 -0800 (PST) In-Reply-To: <84116E2C-C1AA-4560-92CA-B8CA3A07CB78@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se> <809A44FC-84EF-49FE-8DFA-4F2552140C39@ericsson.com> <84116E2C-C1AA-4560-92CA-B8CA3A07CB78@ericsson.com> From: Eric Rescorla Date: Fri, 2 Mar 2018 07:51:40 -0800 Message-ID: To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Cc: Christer Holmberg , The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , Peter Thatcher , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a113b03282b44bc05666ff61c" Archived-At: Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) 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, 02 Mar 2018 15:52:26 -0000 --001a113b03282b44bc05666ff61c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 2, 2018 at 7:40 AM, Ari Ker=C3=A4nen wrote: > Hi Eric, > > Maybe the specific bullet could also be augmented with something like: > "This enables validating In-Progress pairs as soon as possible, without > having to wait for re-transmissions of the original transaction." > Yes, that would be fine -Ekr > > Would that clarify this sufficiently? > > Note that a response to a cancelled check also still qualifies as a > successful check. Only the retransmissions and "fail this candidate if no > answer" behavior is cancelled, so there is no extra delay because of this > behavior even if the original check would eventually succeed. The text sa= ys > about cancel case: "[...] but will wait the duration of transaction timeo= ut > for a response". > > > Cheers, > Ari > > > On 2 Mar 2018, at 16.47, Eric Rescorla wrote: > > > > Ari > > > > Well, this is a nonblocking comment, so fo as you please, but I think > that at minimum this is a confusing behavior and it's the job of the > document to explain it. > > > > On Fri, Mar 2, 2018 at 6:24 AM, Ari Ker=C3=A4nen > wrote: > > I agree with what you wrote below. I think the best way forward is to > keep the text as it was in -17. Anyway it was part of the original RFC524= 5 > text and as discussed earlier, when in doubt, it's better we don't change > the text and accidentally change the behavior for the worse. > > > > > > Cheers, > > Ari > > > > > On 2 Mar 2018, at 15.17, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > > > So, what to do? > > > > > > From: Christer Holmberg > > > Date: Thursday 1 March 2018 at 16:09 > > > To: Eric Rescorla , Ari Ker=C3=A4nen < > ari.keranen@ericsson.com> > > > Cc: "iesg@ietf.org" , "draft-ietf-ice-rfc5245bis@ > ietf.org" , "ice-chairs@ietf.org" < > ice-chairs@ietf.org>, "pthatcher@google.com" , " > ice@ietf.org" > > > Subject: Re: Eric Rescorla's No Objection on > draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security > Considerations) > > > Resent-From: > > > Resent-To: Ari Ker=C3=A4nen , Christer Holm= berg < > christer.holmberg@ericsson.com>, "jdrosen@jdrosen.net" < > jdrosen@jdrosen.net> > > > Resent-Date: Thursday 1 March 2018 at 16:09 > > > > > > Hi, > > > > > > I guess Ari will reply, but my understanding is that, since triggered > checks have high priority, we want the triggered binding requests to be > sent asap. But, if the ongoing transaction (In-Progress) has already been > going on for a while, and all transmitted/re-transmitted binding requests > so far for whatever reason have got dropped in the network, due to the > current re-transmission timer (which grows after each re-transmission) it > may take a while before binding check is re-transmitted again. > > > > > > (Of course, even if we create a new transaction, there may be other > checks waiting in the triggered check queue, so it may still take a while > before the new binding check is sent.) > > > > > > Regards, > > > > > > Christer > > > > > > From: Eric Rescorla > > > Date: Thursday 1 March 2018 at 15:31 > > > To: Ari Ker=C3=A4nen > > > Cc: Christer Holmberg , "iesg@ietf.or= g" > , "draft-ietf-ice-rfc5245bis@ietf.org" < > draft-ietf-ice-rfc5245bis@ietf.org>, "ice-chairs@ietf.org" < > ice-chairs@ietf.org>, "pthatcher@google.com" , " > ice@ietf.org" > > > Subject: Re: Eric Rescorla's No Objection on > draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security > Considerations) > > > > > > > > > > > > On Thu, Mar 1, 2018 at 12:58 AM, Ari Ker=C3=A4nen > wrote: > > >> Hi Eric & Christer, > > >> > > >> > On 19 Feb 2018, at 16.42, Eric Rescorla wrote: > > >> > > > >> > > > >> > > > >> > > in-progress transaction. Cancellation means that the > agent > > >> > > will not retransmit the request, will not treat the lack > of > > >> > > response to be a failure, but will wait the duration of > the > > >> > > > > >> > > Why are you cancelling In-Progress checks when you receive a > peer-reflective check? > > >> > > If you receive two in a row, then it seems like this delays a > successful check. > > >> > > > >> > True. > > >> > > > >> > So, I will remove the cancel part. > > >> > > > >> > Do you still think it should create a new binding request, or is > the ongoing In-Progress check enough to check the pair? > > >> > > > >> > My initial reaction is you don't need to do anything extra, but I > could easily be wrong here. > > >> > > >> I'm afraid this is one of the parts of the spec that solves a corner > case in an interesting but non-obvious way. For context, here's the > original text: > > >> https://tools.ietf.org/html/rfc5245#section-7.2.1.4 > > >> > > >> IIRC, one of the reasons for this is that an agent might have starte= d > the transaction a while ago, perhaps even sent a few re-transmissions. No= w, > if you don't cancel that transaction, but just keep that going and send t= he > remaining re-transmission(s) and those are lost due to bad network > connectivity, you end up marking that pair as failed. However, if you > cancel and start a new transaction, you have full amount of fast > retransmissions to go. And if you receive a reply to a cancelled check, i= t > is still a success. I remember this was unintuitive but eventually made > sense when I implemented it. > > >> > > >> So, I'd recommend we keep this text as such. > > > > > > Why is this different from any other case of transient failure? > > > > > > -Ekr > > > > > >> > > >> > > >> Cheers, > > >> Ari (hat off) > > > > > > > > > --001a113b03282b44bc05666ff61c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Mar 2, 2018 at 7:40 AM, Ari Ker=C3=A4nen <= ari.keranen@e= ricsson.com> wrote:
Hi Eric= ,

Maybe the specific bullet could also be augmented with something like: &quo= t;This enables validating In-Progress pairs as soon as possible, without ha= ving to wait for re-transmissions of the original transaction."

Yes, that would be fine

<= div>-Ekr
=C2=A0

Would that clarify this sufficiently?

Note that a response to a cancelled check also still qualifies as a success= ful check. Only the retransmissions and "fail this candidate if no ans= wer" behavior is cancelled, so there is no extra delay because of this= behavior even if the original check would eventually succeed. The text say= s about cancel case: "[...] but will wait the duration of transaction = timeout for a response".


Cheers,
Ari

> On 2 Mar 2018, at 16.47, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Ari
>
> Well, this is a nonblocking comment, so fo as you please, but I think = that at minimum this is a confusing behavior and it's the job of the do= cument to explain it.
>
> On Fri, Mar 2, 2018 at 6:24 AM, Ari Ker=C3=A4nen <ari.keranen@ericsson.com> wrote:
> I agree with what you wrote below. I think the best way forward is to = keep the text as it was in -17. Anyway it was part of the original RFC5245 = text and as discussed earlier, when in doubt, it's better we don't = change the text and accidentally change the behavior for the worse.
>
>
> Cheers,
> Ari
>
> > On 2 Mar 2018, at 15.17, Christer Holmberg <christer.holmberg@ericsson.com>= wrote:
> >
> > So, what to do?
> >
> > From: Christer Holmberg <christer.holmberg@ericsson.com>
> > Date: Thursday 1 March 2018 at 16:09
> > To: Eric Rescorla <ekr@rtfm.co= m>, Ari Ker=C3=A4nen <ari.keranen@ericsson.com>
> > Cc: "iesg@ietf.org"= ; <iesg@ietf.org>, "draft-ietf-ice-rfc5245bis@ietf.org" <draft-ietf-ice-rfc5245bis@ietf.org>, "ice-chairs@ietf.org" <ice-chairs@ietf.org>, "pthatcher@google.com" <pthatcher@google.com>, "ice@ietf.org" <i= ce@ietf.org>
> > Subject: Re: Eric Rescorla's No Objection on draft-ietf-ice-r= fc5245bis-17: (with COMMENT) (excluding Security Considerations)
> > Resent-From: <alias-= bounces@ietf.org>
> > Resent-To: Ari Ker=C3=A4nen <ari.keranen@ericsson.com>, Christer Holmberg <christer.holmberg@ericsson.= com>, "jdrosen@jdrosen.n= et" <jdrosen@jdrosen.net= >
> > Resent-Date: Thursday 1 March 2018 at 16:09
> >
> > Hi,
> >
> > I guess Ari will reply, but my understanding is that, since trigg= ered checks have high priority, we want the triggered binding requests to b= e sent asap. But, if the ongoing transaction (In-Progress) has already been= going on for a while, and all transmitted/re-transmitted binding requests = so far for whatever reason have got dropped in the network, due to the curr= ent re-transmission timer (which grows after each re-transmission) it may t= ake a while before binding check is re-transmitted again.
> >
> > (Of course, even if we create a new transaction, there may be oth= er checks waiting in the triggered check queue, so it may still take a whil= e before the new binding check is sent.)
> >
> > Regards,
> >
> > Christer
> >
> > From: Eric Rescorla <ekr@rtfm.= com>
> > Date: Thursday 1 March 2018 at 15:31
> > To: Ari Ker=C3=A4nen <ari.keranen@ericsson.com>
> > Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ice-rfc5245bis@ietf.org" <draft-ietf-ice-rfc5245bis@ietf.org>, "ice-chair= s@ietf.org" <ice-chairs@= ietf.org>, "pthatcher@g= oogle.com" <pthatcher@g= oogle.com>, "ice@ietf.org&q= uot; <ice@ietf.org>
> > Subject: Re: Eric Rescorla's No Objection on draft-ietf-ice-r= fc5245bis-17: (with COMMENT) (excluding Security Considerations)
> >
> >
> >
> > On Thu, Mar 1, 2018 at 12:58 AM, Ari Ker=C3=A4nen <ari.keranen@ericsson.com> wrote: > >> Hi Eric & Christer,
> >>
> >> > On 19 Feb 2018, at 16.42, Eric Rescorla <ekr@rtfm.com> wrote:
> >> >
> >> >
> >> >
> >> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in-progress transa= ction.=C2=A0 Cancellation means that the agent
> >> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will not retransmi= t the request, will not treat the lack of
> >> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0response to be a f= ailure, but will wait the duration of the
> >> > >
> >> > > Why are you cancelling In-Progress checks when you = receive a peer-reflective check?
> >> > > If you receive two in a row, then it seems like thi= s delays a successful check.
> >> >
> >> > True.
> >> >
> >> > So, I will remove the cancel part.
> >> >
> >> > Do you still think it should create a new binding reques= t, or is the ongoing In-Progress check enough to check the pair?
> >> >
> >> > My initial reaction is you don't need to do anything= extra, but I could easily be wrong here.
> >>
> >> I'm afraid this is one of the parts of the spec that solv= es a corner case in an interesting but non-obvious way. For context, here&#= 39;s the original text:
> >> https://tools.ietf.org/html/rf= c5245#section-7.2.1.4
> >>
> >> IIRC, one of the reasons for this is that an agent might have= started the transaction a while ago, perhaps even sent a few re-transmissi= ons. Now, if you don't cancel that transaction, but just keep that goin= g and send the remaining re-transmission(s) and those are lost due to bad n= etwork connectivity, you end up marking that pair as failed. However, if yo= u cancel and start a new transaction, you have full amount of fast retransm= issions to go. And if you receive a reply to a cancelled check, it is still= a success. I remember this was unintuitive but eventually made sense when = I implemented it.
> >>
> >> So, I'd recommend we keep this text as such.
> >
> > Why is this different from any other case of transient failure? > >
> > -Ekr
> >
> >>
> >>
> >> Cheers,
> >> Ari (hat off)
> >
>
>


--001a113b03282b44bc05666ff61c-- From nobody Fri Mar 2 10:20:34 2018 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 9FA7612D7F2 for ; Fri, 2 Mar 2018 10:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 GR9uCH27x2CS for ; Fri, 2 Mar 2018 10:20:31 -0800 (PST) Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::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 3D595126C25 for ; Fri, 2 Mar 2018 10:20:31 -0800 (PST) Received: by mail-pl0-x230.google.com with SMTP id v9-v6so6130996plp.12 for ; Fri, 02 Mar 2018 10:20:31 -0800 (PST) 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=S2MxSqndKI+tthZ3lUCn/+SAi6G2mHXq+gkso4c65kI=; b=c1CTRUU4jgsoCSaAgN9UIf0umRae+0u9t0/fjYCdkseMcasmj6VgQWCnJ+zQa8UXIU PN/Vof4U8nWGZRoN26e3CK1OvvMcGlzXaSvDCIvqIeoSox/8fwj3a+XQm16o/qYxcPb4 Oe8rXCWuJcdjNtc0TchNR12Zr1JmwAK1S3NzE= 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=S2MxSqndKI+tthZ3lUCn/+SAi6G2mHXq+gkso4c65kI=; b=rrU+yUSdgl2aUZIfD0L/1OGm/q/K89i21I0j3+EjozbnrLGQZrNdxcxN9sSh39BetH LlVqEVkey4e2qb9330qeznkQDLXbZ2sxPTL+RxJxjR27gL1x6JziltsYFUwH5PuL++oW YuaYTnAhPblxoapLMWP+bz8opaC9+z4xooSLLbUUoCemFGGXaVgKw17902ZAH4KV2TyR uUJNxKyGmHWsVUbTNyrYl0zL2qJ2m0UahdpzXZfL9jdzjsHG/ialij7n9OgDcfT2Y+Wn 3SxHhXpaq79Q1+EmkY14Lk20ZUJWRgxH72vWV+ytgz4PYWy7r7t49+wDaDCXoTyeT3l6 9s2g== X-Gm-Message-State: APf1xPDbpLr7c2HiK8g9ZMbsZtutWPzYee/S9QdoYZ03qzqkeyv69TmR 5Vqe8MHpd5RdXlz+g8iaodoE7w== X-Google-Smtp-Source: AG47ELsQBFOGwjeIWbY71h5VFYsmDTUq3SchdWpOHoW1Sj5r0YM8gcop08+Nqt83CfunC7AHdKm1ZQ== X-Received: by 2002:a17:902:4222:: with SMTP id g31-v6mr5849216pld.335.1520014830679; Fri, 02 Mar 2018 10:20:30 -0800 (PST) Received: from ?IPv6:2601:647:4600:3f31:cce9:92f8:a22e:fd66? ([2601:647:4600:3f31:cce9:92f8:a22e:fd66]) by smtp.gmail.com with ESMTPSA id w24sm12116918pfl.14.2018.03.02.10.20.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Mar 2018 10:20:29 -0800 (PST) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_370CFBF3-A812-4B27-95B7-977F7BBECC11"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 2 Mar 2018 10:20:26 -0800 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se> Cc: Peter Saint-Andre , "ice@ietf.org" To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 02 Mar 2018 18:20:32 -0000 --Apple-Mail=_370CFBF3-A812-4B27-95B7-977F7BBECC11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 27, 2018, at 11:29, Christer Holmberg = wrote: >>=20 >>>>> *Q1:* >>>>>=20 >>>>> Section 7.1 says: >>>>>=20 >>>>> "The ICE specification [rfc5245bis], Section 6.1.4.2, specifies >>>>> that an agent will terminate the timer for a triggered check in >>>>> relation to a check list once the agent has exhausted all = frozen pairs in >>>>> the check list. This will not work with Trickle ICE, because = more >>>>> pairs will be added to the check list incrementally." >>>>>=20 >>>>> Exactly what procedure in 5245bis dos this text refer to? >>>>=20 >>>> Hmm, good question. Emil wrote that text so we might want to check >>>> with him, but looking at 5245bis I'd say it refers to the last >>>> sentence in Step 4 of =C2=A76.1.4.2: >>>>=20 >>>> 4. If this step is reached, no check could be performed for the >>>> picked check list. So, without waiting for timer Ta to expire >>>> again, select the next check list in the Running state and = return >>>> to step #1. If this happens for every single check list in = the >>>> Running state, meaning there are no remaining candidate pairs = to >>>> perform connectivity checks for, abort these steps. >>>>=20 >>>> However, that refers to exhausting all the candidate pairs to be >>>> checked for all check lists, not to "terminat[ing] the timer for a >>>> triggered check in relation to a check list once the agent has >>>> exhausted all frozen pairs in the check list". So we might want to = ping Emil. >>>=20 >>> I think "terminate the timer" is misleading wording. Timer Ta is not >>> terminated as long as there is at least one check list in "Running" = mode. >>>=20 >>> It is true that, whenever timer Ta fires, check lists that are not = in >>> the "Running" mode will not be checked. But, even with legacy ICE, a >>> check list may put back in "Running" mode if e.g., a triggered check >>> changes that status of a failed pair, and if that pair state change >>> affects the state of the check list. >>>=20 >>> So, unless I=C2=B9ve missed something, I don=C2=B9t think that = trickle changes >>> how check lists are checked when Ta fires. If additional candidates >>> have been gathered, and added to a check list, step 4) in section >>> 6.1.4.2 will not be reached. >>=20 >> I suspect that Emil might have been thinking about trickling of = candidates after nomination of a >> candidate pair, but we'll drag him into the conversation one way or = another. ;-) >=20 > I think you raise an important point. Once you have nominated a pair, = you can't nominate another pair (that would be "continuous nomination", = which is outside the scope of trickle). I think you should add text = about that, because I don't think it is currently mentioned. The draft = does say that "ICE processing" might end before end-of-candidates have = been conveyed, but that's a separate thing. I guess nomination would = also implicitly mean end-of-candidates, and neither agent should trickle = any more candidates after nomination is done. Stopping to trickle is one aspect of it. But there can also be still = trickled candidates in flight over the signaling path which arrive after = nomination has concluded on the ICE layer. I think it makes more sense = to address this on the receiving end and advise that ICE agents which = still receive candidates after nomination has concluded, should ignore = these new candidates. Another aspect might be continuous nomination in the future. If we = demand that the emitting agents stops trickling it might be harder to = open it up for continuous nomination again. Where if we only tell the = receiving agent to ignore candidates which arrive after nomination has = concluded it should be trivial for continuous nomination to lift/change = that part of the spec. Best regards Nils Ohlmeier --Apple-Mail=_370CFBF3-A812-4B27-95B7-977F7BBECC11 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----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlqZlesACgkQY2o/VmzJ +KEt9A//aIEcexsWzf/B7ZlxhTX/lfHB8KEBjhMEacoFc3lH9TZlIsWkTc2kuxPv rZ0FHLqkYsubqMfHHGy3/4RrmgxRwEvSeLpAMPNd3ijJLQFS8K+uqRHgpqJNEN4r WmQUWPtibddiUMsYxGjfwbeeAXS8SgJY+Vsx8ZSAhxwJ1Tx7rngzDoftBJwPq9PM iaBiPS1bhvgeiFwrBtdtqIN2K1qwz8QqeXo94XgPoQFkWgMVhDgrxwaXnMJ7D7D7 8v9/aJgxUZjLVjpo7Ndmc4+9U/QUdoxQMrXMKzVx8NTLTdbiD2jNEo85+Um5LDzr SOIATTmY0Y6NafMSynDLb/Jr/smkO5KPABVKgg3vLiJqQ0a/E8HwoMMYqwQ04SXz eS/H0Q6pt444KUglaBlDsmoYOvbX0UemMEw8Q3ZR+5L8v+kEFpUs93yneWU3D2gc OWeHybo8/G9R6pdQlgPbSl3kIhIVlraL2XUT/Y92EkYn1sENuXSEvBErXCZpO+dM yEFw9ycabzW47aN/GuP4LtZ0zQIYNk6RBgBuDa5fTn6rpjaxnVYbBdeNHW81xg98 X1uBSQi12yjwUDsCWTNuad92PfG4NA2d4m0X2JhSo7qPi/3T/GyXzq6Zb9cBRw1U 6de32oM8cXOo80Ita7LXusBuaaSdXA75PFJsg7B4ZoJI5UKA7Yc= =nF/8 -----END PGP SIGNATURE----- --Apple-Mail=_370CFBF3-A812-4B27-95B7-977F7BBECC11-- From nobody Fri Mar 2 10:29:36 2018 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 0561412E852 for ; Fri, 2 Mar 2018 10:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01] 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 M6AFWG4Lt7xv for ; Fri, 2 Mar 2018 10:29:22 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 20CAF12E3AE for ; Fri, 2 Mar 2018 10:29:22 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id x125so6272905vkc.13 for ; Fri, 02 Mar 2018 10:29:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5WmgN5ZzZsBFCorI8lojNs+Wq6YZWIxn8Li3ExwI5fY=; b=YaW9+wg29m/bx1h1VhaJO165jTFjvRBxD13aiVdtoP2Km+PSuqxcUZiAargxEXbUNs XSj0GtKX0TDIOHTHdq97pi+FNii7RfidNmw/Xmq4eSj/SlaC4P3MqOZ19cZ9sJEzPcq0 NJk3vNUc6K0HknHs3kzNG0Op/6EOb90XHbAezyqDB6fuGFOQrqp9vm4JfNxKkbd8qYHh qsKEoLZTXzjYW+nzfzc+UuLACyEWb37J5ayYgxryjF2hU6ZhJwJo1A3uj1+68+ghI/2j z0Ewxh9u4DPJ3267PMJSi8guRbq+c4mlz2xOqPwUgMZt/D/F3PqOjjUvV21Ln6knbcdH q+0A== 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=5WmgN5ZzZsBFCorI8lojNs+Wq6YZWIxn8Li3ExwI5fY=; b=O/CIHawY+bFTKKkjA5UV/VjmvEUTj7AVaAZgb2FD1Xi3SkqXhFa6+L/QoMQg5bxgaD ukDV9FJ9sFhFDeo3/kG0Cjl5QAYgZmyWDOY9v+bJIpT7IFFZAbLAUkMbkJY76xPolk6z b4qoV2F/zcBx31el84DyDpO7e4MpoFWBTA5QsKKTBilXwnAyvsYllXR1MXO9Y2aUYQmT Cgpx4WrjH6dkvcO3E/EW5EWGExLyUZFHlp7JlpBda36fmNb0QrrPg9DcNz/WVzSERwOq 8OytLMj1Te/ITdx8ti4VBmkOGL2w3in07i332P5DWQuksWD9vcUfPeb2UGxCUc7KTTR8 Sa4w== X-Gm-Message-State: APf1xPAv/rw9i7R7rfPA7KdU3H51HE8Q4AfSgEajujJON/jTCxJev/jK zah6uwOCFuyTg3Swq2eHiUvQwa96TbL1BCYn4iMeGQ== X-Google-Smtp-Source: AG47ELvfm+Ml8yT3AEtWHlqfd1+6Zo8rhAxL+Jc5Y8Vt10Q7f/OEQa5ngOn3RxwtWmEbfNwV9fblbLHYVS+tWBup9fU= X-Received: by 10.31.107.145 with SMTP id k17mr4366468vki.198.1520015360723; Fri, 02 Mar 2018 10:29:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.114.66 with HTTP; Fri, 2 Mar 2018 10:29:19 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B6C1B8FEE@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1B9583@ESESSMB109.ericsson.se> <70af5888-1927-1f62-ba3f-8d6fd4614c87@mozilla.com> <7594FB04B1934943A5C02806D1A2204B6C1B9921@ESESSMB109.ericsson.se> From: Taylor Brandstetter Date: Fri, 2 Mar 2018 10:29:19 -0800 Message-ID: To: Christer Holmberg Cc: Peter Saint-Andre , Peter Saint-Andre , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a11478e44a1b21e05667227fe" Archived-At: Subject: Re: [Ice] Trickle: What is Section 16 about? 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, 02 Mar 2018 18:29:34 -0000 --001a11478e44a1b21e05667227fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Based on our discussion, I > assume =C2=B3stream order" actually means =C2=B3foundation order througho= ut all > streams=C2=B2. I.e., you need to trickle all available f1 candidates befo= re you > trickle any f2 candidates, before you trickle any f3 candidates, etc etc. > It would be the other way around: the order of the rows in Section 8.1.1, not the columns. Pairs for different foundations are meant to be attempted simultaneously. On Thu, Mar 1, 2018 at 11:36 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>ICE agent does not know what candidates it will eventually get. > > > >I think this is the root of our misunderstanding. But can you clarify, d= o > >you mean that the ICE agent doesn't know what candidates it will > >attempt to gather? Or that it doesn't know whether a pending STUN > >transaction will fail? > > The agent probably knows what candidates it TRIES to gather. But, as you > say, a pending STUN transaction may fail. The STUN/TURN server might be > overloaded, or out-of-service for some other reason. > > > If you're talking about the former case, then I think we have a > >different concept of what the "ICE agent" is. I interpreted the ICE agen= t > >as being responsible for candidate gathering (including deciding which > >candidates it will attempt to gather). > > > > If you're talking about the latter case, then I agree there's a questio= n > >of "how long do I wait for the pending STUN transaction before giving up > >and trickling the candidates I have?" Which I assumed would be an > >implementation choice. > > Perhaps, but then we need to document it. Based on our discussion, I > assume =C2=B3stream order" actually means =C2=B3foundation order througho= ut all > streams=C2=B2. I.e., you need to trickle all available f1 candidates befo= re you > trickle any f2 candidates, before you trickle any f3 candidates, etc etc. > > Regards, > > Christer > > > > > > On Thu, Mar 1, 2018 at 1:40 PM, Christer Holmberg > wrote: > > Hi, > > >> For example, perhaps you gather relay candidates only for the audio > >>streams, because you don't want to use > >> a relay for your video (you rather don't use video, if it won't work > >>without a relay). > > > > I agree there's nothing preventing this. In this case the ICE agent > >would be able to trickle the audio relay candidate immediately. > > Yes, but in this case it is assumed that the ICE agent knows that it will > never get a relay candidate for video (or, if it gets one, it will not > trickle it). > > >> Again, I don't see the difference between streams and components here. > >>You could ask the same question of components: "How > >> does the agent know it will get 'RTP srflx' if it gets 'RTCP srflx'?" > > > > You don't know - unless trickle mandates it (5245bis does not mandate > >it, as far as I know). > > > >> The ICE agent doesn't know what candidates it's attempting to gather? > >>Or it doesn't know whether the pending STUN transaction will fail? > > The ICE agent does not know what candidates it will eventually get. Maybe > it can indicate (using an API or configuration) what it wants, maybe it > will get whatever is available, but I don't think we can assume that it > knows what it will eventually get. > > >>You would have to explain what "stream order" really means. > > > >It would be the order of the rows in section 8.1; ordered first by strea= m > >then by component. > > If you are using SDP, the initial offer will obviously order the streams > (m- lines) in a certain order. > > But, when you then start to trickle, I don't understand what "stream > order" means. Assume the agent gets candidates for only one stream. How d= o > you trickle those in "stream order"? Again, if you know that you are goin= g > to get the same type of candidates also > for the "previous" streams, you can wait. But if you don't know? How lon= g > will you wait until you trickle? > > Regards, > > Christer > > > > > On Thu, Mar 1, 2018 at 12:56 PM, Peter Saint-Andre > wrote: > On 3/1/18 12:19 PM, Christer Holmberg wrote: > > Hi, > > > >>> Assume the agent gets "stream 1 host", "stream 2 host" and "stream 2 > >>>srflx". Should it wait for "stream 1 srflx" before trickling "stream 2 > >>>srflx"? > >> > >> That was my interpretation. > >> > >>> How does the agent even know that it will get "stream 1 srflx"? > >> > >> If one candidate of a particular foundation was gathered successfully, > >>the agent can expect the rest of the > >> candidates with that foundation to be gathered successfully as well. > > > > I don't think there is any rule saying that, for a given foundation, yo= u > >will get candidates for all streams (see example in section 6.1.2.6. of > >5245bis). For example, perhaps you gather relay candidates only for the > >audio streams, because you want to use > a relay for your video (you rather don't use video, if it won't work > without a relay). > > > >> Again, I don't see the difference between streams and components here. > >>You could ask the same question of components: "How > >> does the agent know it will get 'RTP srflx' if it gets 'RTCP srflx'?" > > > > You don't know - unless trickle mandates it (5245bis does not mandate > >it, as far as I know). > > > >>> My point is that is if you have the following text: > >>> > >>> "achieve this, when trickling candidates, agents MUST respect the > >>> order in which the components and streams appear (implicitly or > >>> explicitly) as they have been negotiated by means of the relevant > >>> candidate information." > >>> > >>> ...you should explain how it impacts streams. Currently the text only > >>>talks about components. > >> > >> Ah, so is the issue that the next sentence only mentions components? > > > > Correct. > > > >> Therefore candidates for a given component > >> MUST NOT be conveyed prior to candidates for a component with a low= er > >> ID number within the same foundation. > >> > >> Streams are mentioned further below: > >> > >> Similar considerations apply at the level of media streams in > >> addition to foundations; this is covered by the requirement to alway= s > >> start unfreezing candidates starting from the first media stream as > >> described under Section 5.2. > >> > >> But this appears out of date. Section 5.2 used to say: > >> > >> If [the first] > >> checklist is still empty however, agents will hold off further > >> processing until this is no longer the case. > >> > >> .... Which ensures the first stream is always unfrozen first. But now > >>it says: > >> > >> If that first component of the first media stream does > >> not contain candidates for one or more of the currently known pair > >> foundations, and if candidate pairs already exist for that foundati= on > >> in one of the following components or media streams, then the agent > >> unfreezes the first of those candidate pairs. > >> > >> Meaning section 5.2 no longer enforces the stream ordering requirement= . > >> > >> So, I'd suggest: > >> =E2=82=AC Removing the outdated "Similar considerations apply..." para= graph. > >> =E2=82=AC Updating the rest of Section 16 to make it clear that candid= ates > >>should be trickled in both stream and component order. > > > > You would have to explain what "stream order" really means. Because, it > >does not mean that you first trickle all candidates for stream 1, then > >all candidates for stream 2, etc. > > > > As I said above, you seem to suggest that, for each stream and each > >foundation, there will be the same set of candidates. There is no such > >requirement anywhere, as far as I know. > I suggest that we remove all references to the poorly defined concept of > "stream order". But if Emil thinks this is crucial then I'll defer to > him. (I did connect with him offlist and he promises to weigh in soon.) > > Peter > > > > > > > > > --001a11478e44a1b21e05667227fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Based on our discussion, I
assume =C2=B3stream order" actually means =C2=B3foundation order th= roughout all
streams=C2=B2. I.e., you need = to trickle all available f1 candidates before you
trickle any f2 candidates, before you trickle any f3 candidates, etc= etc.

It would be the other way = around: the order of the rows in Section 8.1.1, not the columns. Pairs for = different foundations are meant to be attempted simultaneously.
=

On Thu, Mar 1, 20= 18 at 11:36 PM, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:
Hi,

>>ICE agent does not know what candidates it will eventually get.
>
>I think this is the root of our misunderstanding. But can you clarify, = do
>you mean that the ICE agent doesn't know what candidates it will >attempt to gather? Or that it doesn't know whether a pending STUN >transaction will fail?

The agent probably knows what candidates it TRIES to gather. But, as= you
say, a pending STUN transaction may fail. The STUN/TURN server might be
overloaded, or out-of-service for some other reason.

> If you're talking about the former case, then I think we have a >different concept of what the "ICE agent" is. I interpreted t= he ICE agent
>as being responsible for candidate gathering (including deciding which<= br> >candidates it will attempt to gather).
>
> If you're talking about the latter case, then I agree there's = a question
>of "how long do I wait for the pending STUN transaction before giv= ing up
>and trickling the candidates I have?" Which I assumed would be an<= br> >implementation choice.

Perhaps, but then we need to document it. Based on our discussion, I=
assume =C2=B3stream order" actually means =C2=B3foundation order throu= ghout all
streams=C2=B2. I.e., you need to trickle all available f1 candidates before= you
trickle any f2 candidates, before you trickle any f3 candidates, etc etc.

Regards,

Christer





On Thu, Mar 1, 2018 at 1:40 PM, Christer Holmberg
<christer.holmberg@eri= csson.com> wrote:

Hi,

>> For example, perhaps you gather relay candidates only for the audi= o
>>streams, because you don't want to use
>> a relay for your video (you rather don't use video, if it won&= #39;t work
>>without a relay).
>
> I agree there's nothing preventing this. In this case the ICE agen= t
>would be able to trickle the audio relay candidate immediately.

Yes, but in this case it is assumed that the ICE agent knows that it will never get a relay candidate for video (or, if it gets one, it will not
trickle it).

>> Again, I don't see the difference between streams and componen= ts here.
>>You could ask the same question of components: "How
>> does the agent know it will get 'RTP srflx' if it gets = 9;RTCP srflx'?"
>
> You don't know - unless trickle mandates it (5245bis does not mand= ate
>it, as far as I know).
>
>> The ICE agent doesn't know what candidates it's attempting= to gather?
>>Or it doesn't know whether the pending STUN transaction will fa= il?

The ICE agent does not know what candidates it will eventually get. Maybe it can indicate (using an API or configuration) what it wants, maybe it
will get whatever is available, but I don't think we can assume that it=
knows what it will eventually get.

>>You would have to explain what "stream order" really mean= s.
>
>It would be the order of the rows in section 8.1; ordered first by stre= am
>then by component.

If you are using SDP, the initial offer will obviously order the streams (m- lines) in a certain order.

But, when you then start to trickle, I don't understand what "stre= am
order" means. Assume the agent gets candidates for only one stream. Ho= w do
you trickle those in "stream order"? Again, if you know that you = are going
to get the same type of candidates also
=C2=A0for the "previous" streams, you can wait. But if you don= 9;t know? How long
will you wait until you trickle?

Regards,

Christer




On Thu, Mar 1, 2018 at 12:56 PM, Peter Saint-Andre <stpeter@mozilla.com>
wrote:
On 3/1/18 12:19 PM, Christer Holmberg wrote:
> Hi,
>
>>> Assume the agent gets "stream 1 host", "stream = 2 host" and "stream 2
>>>srflx". Should it wait for "stream 1 srflx" befo= re trickling "stream 2
>>>srflx"?
>>
>> That was my interpretation.
>>
>>> How does the agent even know that it will get "stream 1 s= rflx"?
>>
>> If one candidate of a particular foundation was gathered successfu= lly,
>>the agent can expect the rest of the
>> candidates with that foundation to be gathered successfully as wel= l.
>
> I don't think there is any rule saying that, for a given foundatio= n, you
>will get candidates for all streams (see example in section 6.1.2.6. of=
>5245bis). For example, perhaps you gather relay candidates only for the=
>audio streams, because you want to use
=C2=A0a relay for your video (you rather don't use video, if it won'= ;t work
without a relay).
>
>> Again, I don't see the difference between streams and componen= ts here.
>>You could ask the same question of components: "How
>> does the agent know it will get 'RTP srflx' if it gets = 9;RTCP srflx'?"
>
> You don't know - unless trickle mandates it (5245bis does not mand= ate
>it, as far as I know).
>
>>> My point is that is if you have the following text:
>>>
>>>=C2=A0 =C2=A0 "achieve this, when trickling candidates, ag= ents MUST respect the
>>>=C2=A0 =C2=A0 order in which the components and streams appear = (implicitly or
>>>=C2=A0 =C2=A0 explicitly) as they have been negotiated by means= of the relevant
>>>=C2=A0 candidate information."
>>>
>>> ...you should explain how it impacts streams. Currently the te= xt only
>>>talks about components.
>>
>> Ah, so is the issue that the next sentence only mentions component= s?
>
> Correct.
>
>>=C2=A0 =C2=A0 Therefore candidates for a given component
>>=C2=A0 =C2=A0 MUST NOT be conveyed prior to candidates for a compon= ent with a lower
>>=C2=A0 =C2=A0 ID number within the same foundation.
>>
>> Streams are mentioned further below:
>>
>>=C2=A0 =C2=A0Similar considerations apply at the level of media str= eams in
>>=C2=A0 =C2=A0addition to foundations; this is covered by the requir= ement to always
>>=C2=A0 =C2=A0start unfreezing candidates starting from the first me= dia stream as
>>=C2=A0 =C2=A0described under Section 5.2.
>>
>> But this appears out of date. Section 5.2 used to say:
>>
>> If [the first]
>> checklist is still empty however, agents will hold off further
>> processing until this is no longer the case.
>>
>> .... Which ensures the first stream is always unfrozen first. But = now
>>it says:
>>
>>=C2=A0 =C2=A0 If that first component of the first media stream doe= s
>>=C2=A0 =C2=A0 not contain candidates for one or more of the current= ly known pair
>>=C2=A0 =C2=A0 foundations, and if candidate pairs already exist for= that foundation
>>=C2=A0 =C2=A0 in one of the following components or media streams, = then the agent
>>=C2=A0 =C2=A0 unfreezes the first of those candidate pairs.
>>
>> Meaning section 5.2 no longer enforces the stream ordering require= ment.
>>
>> So, I'd suggest:
>> =E2=82=AC Removing the outdated "Similar considerations apply= ..." paragraph.
>> =E2=82=AC Updating the rest of Section 16 to make it clear that ca= ndidates
>>should be trickled in both stream and component order.
>
> You would have to explain what "stream order" really means. = Because, it
>does not mean that you first trickle all candidates for stream 1, then<= br> >all candidates for stream 2, etc.
>
> As I said above, you seem to suggest that, for each stream and each >foundation, there will be the same set of candidates. There is no such<= br> >requirement anywhere, as far as I know.
I suggest that we remove all references to the poorly defined concept of "stream order". But if Emil thinks this is crucial then I'll = defer to
him. (I did connect with him offlist and he promises to weigh in soon.)

Peter









--001a11478e44a1b21e05667227fe-- From nobody Fri Mar 2 13:03:14 2018 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 0AEC312D7F1 for ; Fri, 2 Mar 2018 13:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=ericsson.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 bn2Ja4qRYgU6 for ; Fri, 2 Mar 2018 13:03:08 -0800 (PST) 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 D749512EAD1 for ; Fri, 2 Mar 2018 13:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520024576; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dhSSwxzsT+iuhwD2n1aQuIBZhXdp9ViB7tqTgyqiwwM=; b=AsGWN9djrAAH4uB5r03/QUZLkoi0rDpnN2SUeOdU9N0+FwZspldSI5qrvIkviajp G1yStWhx3wOA/pGE69oFLMyMIYMJjfnNyVOGsziiN/Qr5VlLwijbhYZp80BtJ+SS nbyKfmYW+apWdx1hlc//1RCnHEzTAU4mLOqzmHGzGjU=; X-AuditID: c1b4fb3a-35fff700000067b4-dd-5a99bbff305e Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.A4.26548.FFBB99A5; Fri, 2 Mar 2018 22:02:56 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Fri, 2 Mar 2018 22:02:55 +0100 From: Christer Holmberg To: Eric Rescorla , =?utf-8?B?QXJpIEtlcsOkbmVu?= CC: The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , Peter Thatcher , "ice@ietf.org" Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) Thread-Index: AdOpa677O8VqdAW5ThyXNM/NhWOUGQAG8xsAAerqwYAACYXUgAAF+QMAADB64QD//+1mAIAABoSAgAAOvoCAAAMuAP//mM4Q Date: Fri, 2 Mar 2018 21:02:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1BC5B3@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se> <809A44FC-84EF-49FE-8DFA-4F2552140C39@ericsson.com> <84116E2C-C1AA-4560-92CA-B8CA3A07CB78@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.163] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C1BC5B3ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2K7qy7DnplRBk/fcFrMP3md2WLF63Ps FhdnTWaz+Hah1mLGn4nMFteWv2Z1YPNYsKnUY8mSn0wekx+3MQcwR3HZpKTmZJalFunbJXBl bPp1nr1gwTvGirfrtzE1MP55ztjFyMkhIWAi8b5jD5DNxSEkcJhR4seuuSwQziJGiT07JgBl ODjYBCwkuv9pg5giAtESG5vDQUqYBR4wSuzd+58JZJCwQL3Eo1X9bCAJEYEGRokvl6awQjTk Sbxd4AJSwyKgInF21Q+wxbwCvhKdN85D7XrPIjF74W+wQZwCgRJ7p/9mB7EZBcQkvp9aAxZn FhCXuPVkPhPE1QISS/acZ4awRSVePv7HCmErSSyftoUdoj5f4sH3TUwQywQlTs58wjKBUWQW klGzkJTNQlI2C+hsZgFNifW79CFKFCWmdD9kh7A1JFrnzGVHFl/AyL6KUbQ4tbg4N93ISC+1 KDO5uDg/Ty8vtWQTIzASD275bbWD8eBzx0OMAhyMSjy8PDtmRgmxJpYVV+YeYpTgYFYS4W35 MCNKiDclsbIqtSg/vqg0J7X4EKM0B4uSOK9TmkWUkEB6YklqdmpqQWoRTJaJg1OqgXHRnNTr t+YvdprzL9FmUa3/8xmMPGculH7SydIul4sW/vA881Ov25Iw8Y2dhU5LJfQ+n3fOn2WtU3Dj w70tOjqifOu368xy/F0mIqyuM3WTebo1q5nrfNumIxtbevI6p51xXj1jR1Sd3NHW3yecnLr/ a1kd32/ft3ITY9HtHbIps3mEbnxPPKXEUpyRaKjFXFScCAC+Xh5KwAIAAA== Archived-At: Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) 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, 02 Mar 2018 21:03:12 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C1BC5B3ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCknigJl2ZSB1cGRhdGVkIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBwdWxsIHJl cXVlc3Q6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9pY2Utd2cvcmZjNTI0NWJpcy9wdWxsLzYxL2Nv bW1pdHMvYTE0MDAxY2FmZDYyMjIzNWM3YmMyMjQ0M2RiNGFhMGQ4MjY5ZmVmMg0KDQpJIGRpZCBz b21lIGVkaXRvcmlhbCBjbGVhbi11cHMgYW5kIHRlcm1pbm9sb2d5IGFsaWdubWVudHMgaW4gdGhl IHRleHQgb2YgdGhlIGJ1bGxldHMsIGJ1dCB0ZWNobmljYWxseSBpdCBpcyBub3cgYXMgaW4gdmVy c2lvbiAtMTcuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEVyaWMgUmVzY29ybGEg W21haWx0bzpla3JAcnRmbS5jb21dDQpTZW50OiAwMiBNYXJjaCAyMDE4IDE3OjUyDQpUbzogQXJp IEtlcsOkbmVuIDxhcmkua2VyYW5lbkBlcmljc3Nvbi5jb20+DQpDYzogQ2hyaXN0ZXIgSG9sbWJl cmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT47IFRoZSBJRVNHIDxpZXNnQGlldGYu b3JnPjsgZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpc0BpZXRmLm9yZzsgaWNlLWNoYWlyc0BpZXRm Lm9yZzsgUGV0ZXIgVGhhdGNoZXIgPHB0aGF0Y2hlckBnb29nbGUuY29tPjsgaWNlQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogRXJpYyBSZXNjb3JsYSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm LWljZS1yZmM1MjQ1YmlzLTE3OiAod2l0aCBDT01NRU5UKSAoZXhjbHVkaW5nIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zKQ0KDQoNCg0KT24gRnJpLCBNYXIgMiwgMjAxOCBhdCA3OjQwIEFNLCBBcmkg S2Vyw6RuZW4gPGFyaS5rZXJhbmVuQGVyaWNzc29uLmNvbTxtYWlsdG86YXJpLmtlcmFuZW5AZXJp Y3Nzb24uY29tPj4gd3JvdGU6DQpIaSBFcmljLA0KDQpNYXliZSB0aGUgc3BlY2lmaWMgYnVsbGV0 IGNvdWxkIGFsc28gYmUgYXVnbWVudGVkIHdpdGggc29tZXRoaW5nIGxpa2U6ICJUaGlzIGVuYWJs ZXMgdmFsaWRhdGluZyBJbi1Qcm9ncmVzcyBwYWlycyBhcyBzb29uIGFzIHBvc3NpYmxlLCB3aXRo b3V0IGhhdmluZyB0byB3YWl0IGZvciByZS10cmFuc21pc3Npb25zIG9mIHRoZSBvcmlnaW5hbCB0 cmFuc2FjdGlvbi4iDQoNClllcywgdGhhdCB3b3VsZCBiZSBmaW5lDQoNCi1Fa3INCg0KDQpXb3Vs ZCB0aGF0IGNsYXJpZnkgdGhpcyBzdWZmaWNpZW50bHk/DQoNCk5vdGUgdGhhdCBhIHJlc3BvbnNl IHRvIGEgY2FuY2VsbGVkIGNoZWNrIGFsc28gc3RpbGwgcXVhbGlmaWVzIGFzIGEgc3VjY2Vzc2Z1 bCBjaGVjay4gT25seSB0aGUgcmV0cmFuc21pc3Npb25zIGFuZCAiZmFpbCB0aGlzIGNhbmRpZGF0 ZSBpZiBubyBhbnN3ZXIiIGJlaGF2aW9yIGlzIGNhbmNlbGxlZCwgc28gdGhlcmUgaXMgbm8gZXh0 cmEgZGVsYXkgYmVjYXVzZSBvZiB0aGlzIGJlaGF2aW9yIGV2ZW4gaWYgdGhlIG9yaWdpbmFsIGNo ZWNrIHdvdWxkIGV2ZW50dWFsbHkgc3VjY2VlZC4gVGhlIHRleHQgc2F5cyBhYm91dCBjYW5jZWwg Y2FzZTogIlsuLi5dIGJ1dCB3aWxsIHdhaXQgdGhlIGR1cmF0aW9uIG9mIHRyYW5zYWN0aW9uIHRp bWVvdXQgZm9yIGEgcmVzcG9uc2UiLg0KDQoNCkNoZWVycywNCkFyaQ0KDQo+IE9uIDIgTWFyIDIw MTgsIGF0IDE2LjQ3LCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZt LmNvbT4+IHdyb3RlOg0KPg0KPiBBcmkNCj4NCj4gV2VsbCwgdGhpcyBpcyBhIG5vbmJsb2NraW5n IGNvbW1lbnQsIHNvIGZvIGFzIHlvdSBwbGVhc2UsIGJ1dCBJIHRoaW5rIHRoYXQgYXQgbWluaW11 bSB0aGlzIGlzIGEgY29uZnVzaW5nIGJlaGF2aW9yIGFuZCBpdCdzIHRoZSBqb2Igb2YgdGhlIGRv Y3VtZW50IHRvIGV4cGxhaW4gaXQuDQo+DQo+IE9uIEZyaSwgTWFyIDIsIDIwMTggYXQgNjoyNCBB TSwgQXJpIEtlcsOkbmVuIDxhcmkua2VyYW5lbkBlcmljc3Nvbi5jb208bWFpbHRvOmFyaS5rZXJh bmVuQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KPiBJIGFncmVlIHdpdGggd2hhdCB5b3Ugd3JvdGUg YmVsb3cuIEkgdGhpbmsgdGhlIGJlc3Qgd2F5IGZvcndhcmQgaXMgdG8ga2VlcCB0aGUgdGV4dCBh cyBpdCB3YXMgaW4gLTE3LiBBbnl3YXkgaXQgd2FzIHBhcnQgb2YgdGhlIG9yaWdpbmFsIFJGQzUy NDUgdGV4dCBhbmQgYXMgZGlzY3Vzc2VkIGVhcmxpZXIsIHdoZW4gaW4gZG91YnQsIGl0J3MgYmV0 dGVyIHdlIGRvbid0IGNoYW5nZSB0aGUgdGV4dCBhbmQgYWNjaWRlbnRhbGx5IGNoYW5nZSB0aGUg YmVoYXZpb3IgZm9yIHRoZSB3b3JzZS4NCj4NCj4NCj4gQ2hlZXJzLA0KPiBBcmkNCj4NCj4gPiBP biAyIE1hciAyMDE4LCBhdCAxNS4xNywgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4g d3JvdGU6DQo+ID4NCj4gPiBTbywgd2hhdCB0byBkbz8NCj4gPg0KPiA+IEZyb206IENocmlzdGVy IEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+DQo+ID4gRGF0ZTogVGh1cnNkYXkgMSBNYXJjaCAyMDE4 IGF0IDE2OjA5DQo+ID4gVG86IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWty QHJ0Zm0uY29tPj4sIEFyaSBLZXLDpG5lbiA8YXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tPG1haWx0 bzphcmkua2VyYW5lbkBlcmljc3Nvbi5jb20+Pg0KPiA+IENjOiAiaWVzZ0BpZXRmLm9yZzxtYWls dG86aWVzZ0BpZXRmLm9yZz4iIDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPj4s ICJkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWlj ZS1yZmM1MjQ1YmlzQGlldGYub3JnPiIgPGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5v cmc8bWFpbHRvOmRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmc+PiwgImljZS1jaGFp cnNAaWV0Zi5vcmc8bWFpbHRvOmljZS1jaGFpcnNAaWV0Zi5vcmc+IiA8aWNlLWNoYWlyc0BpZXRm Lm9yZzxtYWlsdG86aWNlLWNoYWlyc0BpZXRmLm9yZz4+LCAicHRoYXRjaGVyQGdvb2dsZS5jb208 bWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tPiIgPHB0aGF0Y2hlckBnb29nbGUuY29tPG1haWx0 bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbT4+LCAiaWNlQGlldGYub3JnPG1haWx0bzppY2VAaWV0Zi5v cmc+IiA8aWNlQGlldGYub3JnPG1haWx0bzppY2VAaWV0Zi5vcmc+Pg0KPiA+IFN1YmplY3Q6IFJl OiBFcmljIFJlc2NvcmxhJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtaWNlLXJmYzUyNDVi aXMtMTc6ICh3aXRoIENPTU1FTlQpIChleGNsdWRpbmcgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMp DQo+ID4gUmVzZW50LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphbGlhcy1i b3VuY2VzQGlldGYub3JnPj4NCj4gPiBSZXNlbnQtVG86IEFyaSBLZXLDpG5lbiA8YXJpLmtlcmFu ZW5AZXJpY3Nzb24uY29tPG1haWx0bzphcmkua2VyYW5lbkBlcmljc3Nvbi5jb20+PiwgQ2hyaXN0 ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4sICJqZHJvc2VuQGpkcm9zZW4ubmV0PG1haWx0bzpq ZHJvc2VuQGpkcm9zZW4ubmV0PiIgPGpkcm9zZW5AamRyb3Nlbi5uZXQ8bWFpbHRvOmpkcm9zZW5A amRyb3Nlbi5uZXQ+Pg0KPiA+IFJlc2VudC1EYXRlOiBUaHVyc2RheSAxIE1hcmNoIDIwMTggYXQg MTY6MDkNCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gSSBndWVzcyBBcmkgd2lsbCByZXBseSwgYnV0 IG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCwgc2luY2UgdHJpZ2dlcmVkIGNoZWNrcyBoYXZlIGhp Z2ggcHJpb3JpdHksIHdlIHdhbnQgdGhlIHRyaWdnZXJlZCBiaW5kaW5nIHJlcXVlc3RzIHRvIGJl IHNlbnQgYXNhcC4gQnV0LCBpZiB0aGUgb25nb2luZyB0cmFuc2FjdGlvbiAoSW4tUHJvZ3Jlc3Mp IGhhcyBhbHJlYWR5IGJlZW4gZ29pbmcgb24gZm9yIGEgd2hpbGUsIGFuZCBhbGwgdHJhbnNtaXR0 ZWQvcmUtdHJhbnNtaXR0ZWQgYmluZGluZyByZXF1ZXN0cyBzbyBmYXIgZm9yIHdoYXRldmVyIHJl YXNvbiBoYXZlIGdvdCBkcm9wcGVkIGluIHRoZSBuZXR3b3JrLCBkdWUgdG8gdGhlIGN1cnJlbnQg cmUtdHJhbnNtaXNzaW9uIHRpbWVyICh3aGljaCBncm93cyBhZnRlciBlYWNoIHJlLXRyYW5zbWlz c2lvbikgaXQgbWF5IHRha2UgYSB3aGlsZSBiZWZvcmUgYmluZGluZyBjaGVjayBpcyByZS10cmFu c21pdHRlZCBhZ2Fpbi4NCj4gPg0KPiA+IChPZiBjb3Vyc2UsIGV2ZW4gaWYgd2UgY3JlYXRlIGEg bmV3IHRyYW5zYWN0aW9uLCB0aGVyZSBtYXkgYmUgb3RoZXIgY2hlY2tzIHdhaXRpbmcgaW4gdGhl IHRyaWdnZXJlZCBjaGVjayBxdWV1ZSwgc28gaXQgbWF5IHN0aWxsIHRha2UgYSB3aGlsZSBiZWZv cmUgdGhlIG5ldyBiaW5kaW5nIGNoZWNrIGlzIHNlbnQuKQ0KPiA+DQo+ID4gUmVnYXJkcywNCj4g Pg0KPiA+IENocmlzdGVyDQo+ID4NCj4gPiBGcm9tOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5j b208bWFpbHRvOmVrckBydGZtLmNvbT4+DQo+ID4gRGF0ZTogVGh1cnNkYXkgMSBNYXJjaCAyMDE4 IGF0IDE1OjMxDQo+ID4gVG86IEFyaSBLZXLDpG5lbiA8YXJpLmtlcmFuZW5AZXJpY3Nzb24uY29t PG1haWx0bzphcmkua2VyYW5lbkBlcmljc3Nvbi5jb20+Pg0KPiA+IENjOiBDaHJpc3RlciBIb2xt YmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+PiwgImllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+ IiA8aWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4+LCAiZHJhZnQtaWV0Zi1pY2Ut cmZjNTI0NWJpc0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpc0BpZXRm Lm9yZz4iIDxkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnPG1haWx0bzpkcmFmdC1p ZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnPj4sICJpY2UtY2hhaXJzQGlldGYub3JnPG1haWx0 bzppY2UtY2hhaXJzQGlldGYub3JnPiIgPGljZS1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmljZS1j aGFpcnNAaWV0Zi5vcmc+PiwgInB0aGF0Y2hlckBnb29nbGUuY29tPG1haWx0bzpwdGhhdGNoZXJA Z29vZ2xlLmNvbT4iIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbTxtYWlsdG86cHRoYXRjaGVyQGdvb2ds ZS5jb20+PiwgImljZUBpZXRmLm9yZzxtYWlsdG86aWNlQGlldGYub3JnPiIgPGljZUBpZXRmLm9y ZzxtYWlsdG86aWNlQGlldGYub3JnPj4NCj4gPiBTdWJqZWN0OiBSZTogRXJpYyBSZXNjb3JsYSdz IE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLTE3OiAod2l0aCBDT01N RU5UKSAoZXhjbHVkaW5nIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKQ0KPiA+DQo+ID4NCj4gPg0K PiA+IE9uIFRodSwgTWFyIDEsIDIwMTggYXQgMTI6NTggQU0sIEFyaSBLZXLDpG5lbiA8YXJpLmtl cmFuZW5AZXJpY3Nzb24uY29tPG1haWx0bzphcmkua2VyYW5lbkBlcmljc3Nvbi5jb20+PiB3cm90 ZToNCj4gPj4gSGkgRXJpYyAmIENocmlzdGVyLA0KPiA+Pg0KPiA+PiA+IE9uIDE5IEZlYiAyMDE4 LCBhdCAxNi40MiwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5j b20+PiB3cm90ZToNCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiA+ICAgICAgICAgaW4t cHJvZ3Jlc3MgdHJhbnNhY3Rpb24uICBDYW5jZWxsYXRpb24gbWVhbnMgdGhhdCB0aGUgYWdlbnQN Cj4gPj4gPiA+ICAgICAgICAgd2lsbCBub3QgcmV0cmFuc21pdCB0aGUgcmVxdWVzdCwgd2lsbCBu b3QgdHJlYXQgdGhlIGxhY2sgb2YNCj4gPj4gPiA+ICAgICAgICAgcmVzcG9uc2UgdG8gYmUgYSBm YWlsdXJlLCBidXQgd2lsbCB3YWl0IHRoZSBkdXJhdGlvbiBvZiB0aGUNCj4gPj4gPiA+DQo+ID4+ ID4gPiBXaHkgYXJlIHlvdSBjYW5jZWxsaW5nIEluLVByb2dyZXNzIGNoZWNrcyB3aGVuIHlvdSBy ZWNlaXZlIGEgcGVlci1yZWZsZWN0aXZlIGNoZWNrPw0KPiA+PiA+ID4gSWYgeW91IHJlY2VpdmUg dHdvIGluIGEgcm93LCB0aGVuIGl0IHNlZW1zIGxpa2UgdGhpcyBkZWxheXMgYSBzdWNjZXNzZnVs IGNoZWNrLg0KPiA+PiA+DQo+ID4+ID4gVHJ1ZS4NCj4gPj4gPg0KPiA+PiA+IFNvLCBJIHdpbGwg cmVtb3ZlIHRoZSBjYW5jZWwgcGFydC4NCj4gPj4gPg0KPiA+PiA+IERvIHlvdSBzdGlsbCB0aGlu ayBpdCBzaG91bGQgY3JlYXRlIGEgbmV3IGJpbmRpbmcgcmVxdWVzdCwgb3IgaXMgdGhlIG9uZ29p bmcgSW4tUHJvZ3Jlc3MgY2hlY2sgZW5vdWdoIHRvIGNoZWNrIHRoZSBwYWlyPw0KPiA+PiA+DQo+ ID4+ID4gTXkgaW5pdGlhbCByZWFjdGlvbiBpcyB5b3UgZG9uJ3QgbmVlZCB0byBkbyBhbnl0aGlu ZyBleHRyYSwgYnV0IEkgY291bGQgZWFzaWx5IGJlIHdyb25nIGhlcmUuDQo+ID4+DQo+ID4+IEkn bSBhZnJhaWQgdGhpcyBpcyBvbmUgb2YgdGhlIHBhcnRzIG9mIHRoZSBzcGVjIHRoYXQgc29sdmVz IGEgY29ybmVyIGNhc2UgaW4gYW4gaW50ZXJlc3RpbmcgYnV0IG5vbi1vYnZpb3VzIHdheS4gRm9y IGNvbnRleHQsIGhlcmUncyB0aGUgb3JpZ2luYWwgdGV4dDoNCj4gPj4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzUyNDUjc2VjdGlvbi03LjIuMS40DQo+ID4+DQo+ID4+IElJUkMsIG9u ZSBvZiB0aGUgcmVhc29ucyBmb3IgdGhpcyBpcyB0aGF0IGFuIGFnZW50IG1pZ2h0IGhhdmUgc3Rh cnRlZCB0aGUgdHJhbnNhY3Rpb24gYSB3aGlsZSBhZ28sIHBlcmhhcHMgZXZlbiBzZW50IGEgZmV3 IHJlLXRyYW5zbWlzc2lvbnMuIE5vdywgaWYgeW91IGRvbid0IGNhbmNlbCB0aGF0IHRyYW5zYWN0 aW9uLCBidXQganVzdCBrZWVwIHRoYXQgZ29pbmcgYW5kIHNlbmQgdGhlIHJlbWFpbmluZyByZS10 cmFuc21pc3Npb24ocykgYW5kIHRob3NlIGFyZSBsb3N0IGR1ZSB0byBiYWQgbmV0d29yayBjb25u ZWN0aXZpdHksIHlvdSBlbmQgdXAgbWFya2luZyB0aGF0IHBhaXIgYXMgZmFpbGVkLiBIb3dldmVy LCBpZiB5b3UgY2FuY2VsIGFuZCBzdGFydCBhIG5ldyB0cmFuc2FjdGlvbiwgeW91IGhhdmUgZnVs bCBhbW91bnQgb2YgZmFzdCByZXRyYW5zbWlzc2lvbnMgdG8gZ28uIEFuZCBpZiB5b3UgcmVjZWl2 ZSBhIHJlcGx5IHRvIGEgY2FuY2VsbGVkIGNoZWNrLCBpdCBpcyBzdGlsbCBhIHN1Y2Nlc3MuIEkg cmVtZW1iZXIgdGhpcyB3YXMgdW5pbnR1aXRpdmUgYnV0IGV2ZW50dWFsbHkgbWFkZSBzZW5zZSB3 aGVuIEkgaW1wbGVtZW50ZWQgaXQuDQo+ID4+DQo+ID4+IFNvLCBJJ2QgcmVjb21tZW5kIHdlIGtl ZXAgdGhpcyB0ZXh0IGFzIHN1Y2guDQo+ID4NCj4gPiBXaHkgaXMgdGhpcyBkaWZmZXJlbnQgZnJv bSBhbnkgb3RoZXIgY2FzZSBvZiB0cmFuc2llbnQgZmFpbHVyZT8NCj4gPg0KPiA+IC1Fa3INCj4g Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBDaGVlcnMsDQo+ID4+IEFyaSAoaGF0IG9mZikNCj4gPg0KPg0K Pg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B6C1BC5B3ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPknigJl2ZSB1cGRhdGVkIHRoZSBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBwdWxsIHJlcXVlc3Q6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vaWNlLXdnL3JmYzUyNDViaXMvcHVs bC82MS9jb21taXRzL2ExNDAwMWNhZmQ2MjIyMzVjN2JjMjI0NDNkYjRhYTBkODI2OWZlZjIiPmh0 dHBzOi8vZ2l0aHViLmNvbS9pY2Utd2cvcmZjNTI0NWJpcy9wdWxsLzYxL2NvbW1pdHMvYTE0MDAx Y2FmZDYyMjIzNWM3YmMyMjQ0M2RiNGFhMGQ4MjY5ZmVmMjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgZGlkIHNvbWUgZWRpdG9yaWFsIGNsZWFuLXVwcyBhbmQg dGVybWlub2xvZ3kgYWxpZ25tZW50cyBpbiB0aGUgdGV4dCBvZiB0aGUgYnVsbGV0cywgYnV0IHRl Y2huaWNhbGx5IGl0IGlzIG5vdyBhcyBpbiB2ZXJzaW9uIC0xNy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g MDIgTWFyY2ggMjAxOCAxNzo1Mjxicj4NCjxiPlRvOjwvYj4gQXJpIEtlcsOkbmVuICZsdDthcmku a2VyYW5lbkBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBDaHJpc3RlciBIb2xtYmVy ZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OzsgVGhlIElFU0cgJmx0O2ll c2dAaWV0Zi5vcmcmZ3Q7OyBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnOyBpY2Ut Y2hhaXJzQGlldGYub3JnOyBQZXRlciBUaGF0Y2hlciAmbHQ7cHRoYXRjaGVyQGdvb2dsZS5jb20m Z3Q7OyBpY2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEVyaWMgUmVzY29ybGEn cyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcy0xNzogKHdpdGggQ09N TUVOVCkgKGV4Y2x1ZGluZyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBGcmksIE1hciAyLCAyMDE4IGF0IDc6NDAgQU0sIEFyaSBLZXLDpG5lbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFyaS5rZXJhbmVuQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmFyaS5rZXJhbmVuQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEVyaWMsPGJyPg0KPGJyPg0K TWF5YmUgdGhlIHNwZWNpZmljIGJ1bGxldCBjb3VsZCBhbHNvIGJlIGF1Z21lbnRlZCB3aXRoIHNv bWV0aGluZyBsaWtlOiAmcXVvdDtUaGlzIGVuYWJsZXMgdmFsaWRhdGluZyBJbi1Qcm9ncmVzcyBw YWlycyBhcyBzb29uIGFzIHBvc3NpYmxlLCB3aXRob3V0IGhhdmluZyB0byB3YWl0IGZvciByZS10 cmFuc21pc3Npb25zIG9mIHRoZSBvcmlnaW5hbCB0cmFuc2FjdGlvbi4mcXVvdDs8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywg dGhhdCB3b3VsZCBiZSBmaW5lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KV291bGQgdGhhdCBjbGFyaWZ5IHRoaXMgc3Vm ZmljaWVudGx5Pzxicj4NCjxicj4NCk5vdGUgdGhhdCBhIHJlc3BvbnNlIHRvIGEgY2FuY2VsbGVk IGNoZWNrIGFsc28gc3RpbGwgcXVhbGlmaWVzIGFzIGEgc3VjY2Vzc2Z1bCBjaGVjay4gT25seSB0 aGUgcmV0cmFuc21pc3Npb25zIGFuZCAmcXVvdDtmYWlsIHRoaXMgY2FuZGlkYXRlIGlmIG5vIGFu c3dlciZxdW90OyBiZWhhdmlvciBpcyBjYW5jZWxsZWQsIHNvIHRoZXJlIGlzIG5vIGV4dHJhIGRl bGF5IGJlY2F1c2Ugb2YgdGhpcyBiZWhhdmlvciBldmVuIGlmIHRoZSBvcmlnaW5hbCBjaGVjayB3 b3VsZA0KIGV2ZW50dWFsbHkgc3VjY2VlZC4gVGhlIHRleHQgc2F5cyBhYm91dCBjYW5jZWwgY2Fz ZTogJnF1b3Q7Wy4uLl0gYnV0IHdpbGwgd2FpdCB0aGUgZHVyYXRpb24gb2YgdHJhbnNhY3Rpb24g dGltZW91dCBmb3IgYSByZXNwb25zZSZxdW90Oy48YnI+DQo8YnI+DQo8YnI+DQpDaGVlcnMsPGJy Pg0KQXJpPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KJmd0OyBPbiAyIE1hciAyMDE4LCBh dCAxNi40NywgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+ ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgQXJpPGJyPg0K Jmd0Ozxicj4NCiZndDsgV2VsbCwgdGhpcyBpcyBhIG5vbmJsb2NraW5nIGNvbW1lbnQsIHNvIGZv IGFzIHlvdSBwbGVhc2UsIGJ1dCBJIHRoaW5rIHRoYXQgYXQgbWluaW11bSB0aGlzIGlzIGEgY29u ZnVzaW5nIGJlaGF2aW9yIGFuZCBpdCdzIHRoZSBqb2Igb2YgdGhlIGRvY3VtZW50IHRvIGV4cGxh aW4gaXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gRnJpLCBNYXIgMiwgMjAxOCBhdCA2OjI0IEFN LCBBcmkgS2Vyw6RuZW4gJmx0OzxhIGhyZWY9Im1haWx0bzphcmkua2VyYW5lbkBlcmljc3Nvbi5j b20iPmFyaS5rZXJhbmVuQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgSSBh Z3JlZSB3aXRoIHdoYXQgeW91IHdyb3RlIGJlbG93LiBJIHRoaW5rIHRoZSBiZXN0IHdheSBmb3J3 YXJkIGlzIHRvIGtlZXAgdGhlIHRleHQgYXMgaXQgd2FzIGluIC0xNy4gQW55d2F5IGl0IHdhcyBw YXJ0IG9mIHRoZSBvcmlnaW5hbCBSRkM1MjQ1IHRleHQgYW5kIGFzIGRpc2N1c3NlZCBlYXJsaWVy LCB3aGVuIGluIGRvdWJ0LCBpdCdzIGJldHRlciB3ZSBkb24ndCBjaGFuZ2UgdGhlIHRleHQgYW5k IGFjY2lkZW50YWxseSBjaGFuZ2UgdGhlDQogYmVoYXZpb3IgZm9yIHRoZSB3b3JzZS48YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQ2hlZXJzLDxicj4NCiZndDsgQXJpPGJyPg0KJmd0Ozxi cj4NCiZndDsgJmd0OyBPbiAyIE1hciAyMDE4LCBhdCAxNS4xNywgQ2hyaXN0ZXIgSG9sbWJlcmcg Jmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBTbywgd2hhdCB0byBkbz88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4m Z3Q7PGJyPg0KJmd0OyAmZ3Q7IERhdGU6IFRodXJzZGF5IDEgTWFyY2ggMjAxOCBhdCAxNjowOTxi cj4NCiZndDsgJmd0OyBUbzogRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBy dGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDssIEFyaSBLZXLDpG5lbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmFyaS5rZXJhbmVuQGVyaWNzc29uLmNvbSI+YXJpLmtlcmFuZW5AZXJpY3Nzb24uY29t PC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgQ2M6ICZxdW90OzxhIGhyZWY9Im1haWx0bzppZXNnQGll dGYub3JnIj5pZXNnQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2dA aWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRy YWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmciPmRyYWZ0LWlldGYtaWNlLXJmYzUyNDVi aXNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1pY2Ut cmZjNTI0NWJpc0BpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpc0BpZXRmLm9yZzwv YT4mZ3Q7LA0KICZxdW90OzxhIGhyZWY9Im1haWx0bzppY2UtY2hhaXJzQGlldGYub3JnIj5pY2Ut Y2hhaXJzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmljZS1jaGFpcnNA aWV0Zi5vcmciPmljZS1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFp bHRvOnB0aGF0Y2hlckBnb29nbGUuY29tIj5wdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbSI+cHRoYXRjaGVyQGdvb2ds ZS5jb208L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86aWNlQGlldGYub3JnIj5pY2VA aWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWNlQGlldGYub3JnIj5pY2VA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBSZTogRXJpYyBSZXNjb3Js YSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLTE3OiAod2l0aCBD T01NRU5UKSAoZXhjbHVkaW5nIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKTxicj4NCiZndDsgJmd0 OyBSZXNlbnQtRnJvbTogJmx0OzxhIGhyZWY9Im1haWx0bzphbGlhcy1ib3VuY2VzQGlldGYub3Jn Ij5hbGlhcy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgUmVzZW50LVRv OiBBcmkgS2Vyw6RuZW4gJmx0OzxhIGhyZWY9Im1haWx0bzphcmkua2VyYW5lbkBlcmljc3Nvbi5j b20iPmFyaS5rZXJhbmVuQGVyaWNzc29uLmNvbTwvYT4mZ3Q7LCBDaHJpc3RlciBIb2xtYmVyZyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpq ZHJvc2VuQGpkcm9zZW4ubmV0Ij5qZHJvc2VuQGpkcm9zZW4ubmV0PC9hPiZxdW90Ow0KICZsdDs8 YSBocmVmPSJtYWlsdG86amRyb3NlbkBqZHJvc2VuLm5ldCI+amRyb3NlbkBqZHJvc2VuLm5ldDwv YT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFJlc2VudC1EYXRlOiBUaHVyc2RheSAxIE1hcmNoIDIwMTgg YXQgMTY6MDk8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSGksPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IEkgZ3Vlc3MgQXJpIHdpbGwgcmVwbHksIGJ1dCBteSB1bmRlcnN0YW5k aW5nIGlzIHRoYXQsIHNpbmNlIHRyaWdnZXJlZCBjaGVja3MgaGF2ZSBoaWdoIHByaW9yaXR5LCB3 ZSB3YW50IHRoZSB0cmlnZ2VyZWQgYmluZGluZyByZXF1ZXN0cyB0byBiZSBzZW50IGFzYXAuIEJ1 dCwgaWYgdGhlIG9uZ29pbmcgdHJhbnNhY3Rpb24gKEluLVByb2dyZXNzKSBoYXMgYWxyZWFkeSBi ZWVuIGdvaW5nIG9uIGZvciBhIHdoaWxlLCBhbmQgYWxsIHRyYW5zbWl0dGVkL3JlLXRyYW5zbWl0 dGVkDQogYmluZGluZyByZXF1ZXN0cyBzbyBmYXIgZm9yIHdoYXRldmVyIHJlYXNvbiBoYXZlIGdv dCBkcm9wcGVkIGluIHRoZSBuZXR3b3JrLCBkdWUgdG8gdGhlIGN1cnJlbnQgcmUtdHJhbnNtaXNz aW9uIHRpbWVyICh3aGljaCBncm93cyBhZnRlciBlYWNoIHJlLXRyYW5zbWlzc2lvbikgaXQgbWF5 IHRha2UgYSB3aGlsZSBiZWZvcmUgYmluZGluZyBjaGVjayBpcyByZS10cmFuc21pdHRlZCBhZ2Fp bi48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgKE9mIGNvdXJzZSwgZXZlbiBpZiB3ZSBj cmVhdGUgYSBuZXcgdHJhbnNhY3Rpb24sIHRoZXJlIG1heSBiZSBvdGhlciBjaGVja3Mgd2FpdGlu ZyBpbiB0aGUgdHJpZ2dlcmVkIGNoZWNrIHF1ZXVlLCBzbyBpdCBtYXkgc3RpbGwgdGFrZSBhIHdo aWxlIGJlZm9yZSB0aGUgbmV3IGJpbmRpbmcgY2hlY2sgaXMgc2VudC4pPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IENo cmlzdGVyPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEZyb206IEVyaWMgUmVzY29ybGEg Jmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZtLmNvbTwvYT4mZ3Q7PGJy Pg0KJmd0OyAmZ3Q7IERhdGU6IFRodXJzZGF5IDEgTWFyY2ggMjAxOCBhdCAxNTozMTxicj4NCiZn dDsgJmd0OyBUbzogQXJpIEtlcsOkbmVuICZsdDs8YSBocmVmPSJtYWlsdG86YXJpLmtlcmFuZW5A ZXJpY3Nzb24uY29tIj5hcmkua2VyYW5lbkBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCiZndDsg Jmd0OyBDYzogQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4m Z3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+aWVzZ0BpZXRmLm9yZzwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3Jn PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWljZS1yZmM1MjQ1Ymlz QGlldGYub3JnIj5kcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnPC9hPiZxdW90Ow0K ICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpc0BpZXRmLm9yZyI+ ZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpc0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVm PSJtYWlsdG86aWNlLWNoYWlyc0BpZXRmLm9yZyI+aWNlLWNoYWlyc0BpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzppY2UtY2hhaXJzQGlldGYub3JnIj5pY2UtY2hhaXJzQGll dGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNv bSI+cHRoYXRjaGVyQGdvb2dsZS5jb208L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpw dGhhdGNoZXJAZ29vZ2xlLmNvbSI+cHRoYXRjaGVyQGdvb2dsZS5jb208L2E+Jmd0OywgJnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOmljZUBpZXRmLm9yZyI+aWNlQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmljZUBpZXRmLm9yZyI+aWNlQGlldGYub3JnPC9hPiZndDs8YnI+DQom Z3Q7ICZndDsgU3ViamVjdDogUmU6IEVyaWMgUmVzY29ybGEncyBObyBPYmplY3Rpb24gb24gZHJh ZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcy0xNzogKHdpdGggQ09NTUVOVCkgKGV4Y2x1ZGluZyBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyk8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgT24gVGh1LCBNYXIgMSwgMjAxOCBhdCAxMjo1OCBBTSwg QXJpIEtlcsOkbmVuICZsdDs8YSBocmVmPSJtYWlsdG86YXJpLmtlcmFuZW5AZXJpY3Nzb24uY29t Ij5hcmkua2VyYW5lbkBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsm Z3Q7IEhpIEVyaWMgJmFtcDsgQ2hyaXN0ZXIsPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsgJmd0OyBPbiAxOSBGZWIgMjAxOCwgYXQgMTYuNDIsIEVyaWMgUmVzY29ybGEgJmx0 OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCiZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luLXByb2dyZXNzIHRyYW5zYWN0aW9uLiZuYnNwOyBDYW5j ZWxsYXRpb24gbWVhbnMgdGhhdCB0aGUgYWdlbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3aWxsIG5vdCByZXRyYW5zbWl0IHRo ZSByZXF1ZXN0LCB3aWxsIG5vdCB0cmVhdCB0aGUgbGFjayBvZjxicj4NCiZndDsgJmd0OyZndDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Jlc3BvbnNlIHRvIGJl IGEgZmFpbHVyZSwgYnV0IHdpbGwgd2FpdCB0aGUgZHVyYXRpb24gb2YgdGhlPGJyPg0KJmd0OyAm Z3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBXaHkgYXJlIHlv dSBjYW5jZWxsaW5nIEluLVByb2dyZXNzIGNoZWNrcyB3aGVuIHlvdSByZWNlaXZlIGEgcGVlci1y ZWZsZWN0aXZlIGNoZWNrPzxicj4NCiZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7IElmIHlvdSByZWNl aXZlIHR3byBpbiBhIHJvdywgdGhlbiBpdCBzZWVtcyBsaWtlIHRoaXMgZGVsYXlzIGEgc3VjY2Vz c2Z1bCBjaGVjay48YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZn dDsgVHJ1ZS48YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsg U28sIEkgd2lsbCByZW1vdmUgdGhlIGNhbmNlbCBwYXJ0Ljxicj4NCiZndDsgJmd0OyZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyBEbyB5b3Ugc3RpbGwgdGhpbmsgaXQgc2hvdWxkIGNy ZWF0ZSBhIG5ldyBiaW5kaW5nIHJlcXVlc3QsIG9yIGlzIHRoZSBvbmdvaW5nIEluLVByb2dyZXNz IGNoZWNrIGVub3VnaCB0byBjaGVjayB0aGUgcGFpcj88YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgTXkgaW5pdGlhbCByZWFjdGlvbiBpcyB5b3UgZG9uJ3Qg bmVlZCB0byBkbyBhbnl0aGluZyBleHRyYSwgYnV0IEkgY291bGQgZWFzaWx5IGJlIHdyb25nIGhl cmUuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSSdtIGFmcmFpZCB0aGlz IGlzIG9uZSBvZiB0aGUgcGFydHMgb2YgdGhlIHNwZWMgdGhhdCBzb2x2ZXMgYSBjb3JuZXIgY2Fz ZSBpbiBhbiBpbnRlcmVzdGluZyBidXQgbm9uLW9idmlvdXMgd2F5LiBGb3IgY29udGV4dCwgaGVy ZSdzIHRoZSBvcmlnaW5hbCB0ZXh0Ojxicj4NCiZndDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyNDUjc2VjdGlvbi03LjIuMS40IiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NSNzZWN0aW9uLTcuMi4x LjQ8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSUlSQywgb25lIG9m IHRoZSByZWFzb25zIGZvciB0aGlzIGlzIHRoYXQgYW4gYWdlbnQgbWlnaHQgaGF2ZSBzdGFydGVk IHRoZSB0cmFuc2FjdGlvbiBhIHdoaWxlIGFnbywgcGVyaGFwcyBldmVuIHNlbnQgYSBmZXcgcmUt dHJhbnNtaXNzaW9ucy4gTm93LCBpZiB5b3UgZG9uJ3QgY2FuY2VsIHRoYXQgdHJhbnNhY3Rpb24s IGJ1dCBqdXN0IGtlZXAgdGhhdCBnb2luZyBhbmQgc2VuZCB0aGUgcmVtYWluaW5nIHJlLXRyYW5z bWlzc2lvbihzKSBhbmQNCiB0aG9zZSBhcmUgbG9zdCBkdWUgdG8gYmFkIG5ldHdvcmsgY29ubmVj dGl2aXR5LCB5b3UgZW5kIHVwIG1hcmtpbmcgdGhhdCBwYWlyIGFzIGZhaWxlZC4gSG93ZXZlciwg aWYgeW91IGNhbmNlbCBhbmQgc3RhcnQgYSBuZXcgdHJhbnNhY3Rpb24sIHlvdSBoYXZlIGZ1bGwg YW1vdW50IG9mIGZhc3QgcmV0cmFuc21pc3Npb25zIHRvIGdvLiBBbmQgaWYgeW91IHJlY2VpdmUg YSByZXBseSB0byBhIGNhbmNlbGxlZCBjaGVjaywgaXQgaXMgc3RpbGwgYSBzdWNjZXNzLg0KIEkg cmVtZW1iZXIgdGhpcyB3YXMgdW5pbnR1aXRpdmUgYnV0IGV2ZW50dWFsbHkgbWFkZSBzZW5zZSB3 aGVuIEkgaW1wbGVtZW50ZWQgaXQuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsgU28sIEknZCByZWNvbW1lbmQgd2Uga2VlcCB0aGlzIHRleHQgYXMgc3VjaC48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgV2h5IGlzIHRoaXMgZGlmZmVyZW50IGZyb20gYW55IG90aGVy IGNhc2Ugb2YgdHJhbnNpZW50IGZhaWx1cmU/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IC1Fa3I8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsgQ2hlZXJzLDxicj4NCiZndDsgJmd0OyZndDsgQXJpIChoYXQg b2ZmKTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B6C1BC5B3ESESSMB109erics_-- From nobody Fri Mar 2 13:17:05 2018 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 DAC92124239 for ; Fri, 2 Mar 2018 13:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 1oyPSX4ArEzV for ; Fri, 2 Mar 2018 13:17:02 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 768D712025C for ; Fri, 2 Mar 2018 13:17:02 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id v194so3456311itb.0 for ; Fri, 02 Mar 2018 13:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=NJ6Z+rKEDzoUukl3RO647bFYQG0ma/TXXK0MfrXdCcs=; b=TPfQP/UxQhaObvyp2sQrAYM3pLombH3u4xmCYl8xPmLrPG09XCxsI2dG3mdXy64xNh h/X0BAWcGExS0TmajjCK2iGXV8oa0aVffcPi4SlY6ImNRinEPxb43WCN5gWAt3qABeVk kXYxD3d8Nlkn9y1WK/1Zx5AjI0r56Zvb0XY6A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=NJ6Z+rKEDzoUukl3RO647bFYQG0ma/TXXK0MfrXdCcs=; b=gLKv+s8tlIhlIwDrZOze4iPyHMEYpelA0Mh2IEjJl38DWeG9j0SOv5lbD3Zivkm7+o ZNai1g5AzWyfJprC1pjcGjAh1qge7xbF47Yya0RiFJZzxv9jVlQu3/vUXJhfwUBuvazA 1XdYcU6Ic83ynD6AjT10SiTms59cKzoVH1UnwKOLSCBHFzNHYbd1BoJnejmPnGpa4rkk L3GVAvLDRJEjMij8m83acQ2V9b2mGESDyt4NVWjIFuxoyXMt7eieHuwbC0MlD89jds/t g7UPs0NO7MkTUL2/tcs0AnqIz5jMVVP/BTkOVU5p7bCyqZFJ7pukdXdAvtrA1q72MIqM d0QA== X-Gm-Message-State: AElRT7Gx4VbIikEzlOrH01qnzwsKLWXl2zXct7szh245xqDnxzPw7wlh RFF/RcPaQT2JsivI+30JdDdLtg== X-Google-Smtp-Source: AG47ELtuDgCPty4S+We+HYdtYL0Ta+bLYrceCbSs7xeAkGmenLUA91J2F96LjutxclQnyYo5/Eu1Qg== X-Received: by 10.36.238.65 with SMTP id b62mr4273465iti.122.1520025421856; Fri, 02 Mar 2018 13:17:01 -0800 (PST) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id 33sm4726163ioj.71.2018.03.02.13.17.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Mar 2018 13:17:01 -0800 (PST) To: Christer Holmberg , "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: <3d8c74e3-57cf-3044-585b-f044bd534c2a@mozilla.com> Date: Fri, 2 Mar 2018 14:16:59 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f52v81qn2E1JDSJiJYWEMkwjN58ARlvyf" Archived-At: Subject: Re: [Ice] Trickle: Example in Section 17 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, 02 Mar 2018 21:17:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f52v81qn2E1JDSJiJYWEMkwjN58ARlvyf Content-Type: multipart/mixed; boundary="NatKBNAfq49e0JNrAKGmjKRRFnaCLvzee"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , "ice@ietf.org" Message-ID: <3d8c74e3-57cf-3044-585b-f044bd534c2a@mozilla.com> Subject: Re: [Ice] Trickle: Example in Section 17 References: In-Reply-To: --NatKBNAfq49e0JNrAKGmjKRRFnaCLvzee Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2/28/18 12:02 AM, Christer Holmberg wrote: > Hi, >=20 > I think the example in Section 17 should be more detailed. Currently I > wouldn=92t even consider the flow an example =96 it=92s just a high-lev= el > visualisation of trickle :) It's not an example, it's an "example flow", i.e., a visualization. This probably belongs in the introduction. > Perhaps using the example in Section 15 of 5245bis as base, and then ad= d > some trickle stuff there? Right, that would be a true example, instead of the flow visualization. We'll look into adding this. (An actual protocol example is more appropriate for draft-ietf-mmusic-trickle-ice-sip.) Peter --NatKBNAfq49e0JNrAKGmjKRRFnaCLvzee-- --f52v81qn2E1JDSJiJYWEMkwjN58ARlvyf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqZv0sACgkQZWGMGH9o FKl22w/+I6wPIoMprgctndsfTT6DhXlD6iA5cF6iOf5H+gyhpAoBBCBdzyb2BDC6 Slq9dTs2SNb8tFP662KFI8a1n6Hx4jfWcuVaSL1uoUvooTUTx2qwRX0iXAdwSCou F9pzQETQ2U+PlIEb4AVO8nz5ESdfQprMwXWz45622VElsyGSPbBvLJrpxqVqj36G OjpNvrKfteU8axadIiu8mRsamOEtt/6FFMyCxYhzfIfEh9gUk1Ykf7SecUmFYFCo pIFjZumlh+LRXPII+xUQp/7Epnh1z5oS32rXaVC5FPqMeT3Mt23Mmuel4/W98pho 6F1aLK7NWtRqJjg4rwKHcLZ6yZrDfuEfJzgD51VHihK4razZqIbMz9uvFDJkkYsI Y/G9Afs4Un2C6ybCCzRnPiqXeZngkQME7SSQa3hdViSsKrnnduWVC5SB3y9QCNoW brMxT7TeDFz/L7tqTO94hF5Esl7Y/2zq0ZWPdKquEtZ1rILE1xoidqfUx8jJrufB a6yEPRkW7AnvbMl3hLUjKuSNe0RfMTYRQtKtR4rRneZJPNajC877WLoBILGhnsgf eoIvjN4Ulbxy3EoWdk+2p2MrDekIY6k+h/IizgVtJZu0g/uoUVoFt3P+MqwGSWt4 4yK0c92gG5n/dNYFVkWkWLLqntn6xoe4rUR+8ww/2XSQ8smN7U0= =HvWC -----END PGP SIGNATURE----- --f52v81qn2E1JDSJiJYWEMkwjN58ARlvyf-- From nobody Fri Mar 2 13:17:39 2018 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 A9358124239 for ; Fri, 2 Mar 2018 13:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 GDkV2SVJFaom for ; Fri, 2 Mar 2018 13:17:37 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 6337112025C for ; Fri, 2 Mar 2018 13:17:37 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id l187so3442889ith.4 for ; Fri, 02 Mar 2018 13:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=WrYn8JPsRia8VRaC+RRIe2EOx6V9UDqN52RF57K+e/Y=; b=YfGMkg/AVlcSyIyCpKhMfw30Bmgl1Bx91LMAuc/Zm3EVzE5bcj5AOvv9/P+aqWRFOb ewHLNuXokXu1eTYQuNu1ZzHtj+kt4HJfV84HsPfcHb5eHZVCGtcD4vcjYOdEGq+0KZ+I NdQnUEuKcosyY4zZv7s3UCIH3y16Wf45xjGfc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=WrYn8JPsRia8VRaC+RRIe2EOx6V9UDqN52RF57K+e/Y=; b=aTYz8O/yC15pu3dbJDvK7wzXKJetnwhK+nMsO2ylhe8GbUA5i7NA3F3Q5LWFur7mZB b5KmcvXsMMx9yH8zRuf3+0N8fPvKowA2Rp83A1EbrT80oqVsYZeysrRuVrjShmCq3A1a YXJwqxpSdKFJYQX0ZmIpuvpXOLoQHDXaUNLGe9xoAAeC1zNoUdQgO0nJ8tbzZgY/IH9w WfNHf6R7efQrtVVG/tLYlSTSzv9ffsWebY0IbhLfLPJ6k40M9V68pyedBMGWpIZRTkA2 5+Px7dnJMjK2e/fkw2WUlsZQthmNgXS8nAHeFb6LSXoROhmIZTqKAe91Bc54pIlWKqCS Hkpg== X-Gm-Message-State: AElRT7G+gg6+GCfga7j24mHRKDcuat8+a7wi13mV8SG0dGDUp+Uyoxok eG/thWBHXFhBK7awhZtsdRkRLxLid3s= X-Google-Smtp-Source: AG47ELsbQ9o3MvA47Vdhu8f3c3UtyG3w4kZxFW7UxzNnVwUyEKyc+h6V7CcrdBXHmAAJMtb4yLc/dg== X-Received: by 10.36.135.137 with SMTP id f131mr4271387ite.142.1520025456838; Fri, 02 Mar 2018 13:17:36 -0800 (PST) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id m203sm1186226itd.26.2018.03.02.13.17.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Mar 2018 13:17:36 -0800 (PST) To: Christer Holmberg , "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: Date: Fri, 2 Mar 2018 14:17:35 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IOegpmBaJKSjCNFrMAuzfpSDb9pU7gmgo" Archived-At: Subject: Re: [Ice] Trickle: Section 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: Fri, 02 Mar 2018 21:17:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IOegpmBaJKSjCNFrMAuzfpSDb9pU7gmgo Content-Type: multipart/mixed; boundary="ktxAGUPazHiv1DNqS5BgY3kRh1xNrmTLD"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , "ice@ietf.org" Message-ID: Subject: Re: [Ice] Trickle: Section 12 References: In-Reply-To: --ktxAGUPazHiv1DNqS5BgY3kRh1xNrmTLD Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2/28/18 12:17 AM, Christer Holmberg wrote: > Hi, >=20 > The text says: >=20 > "This specification does not directly modify the procedures for endi= ng > ICE processing described in Section 8 of [rfc5245bis], and Trickle > ICE implementations follow the same rules.=C2=B2 >=20 > If this text is to be kept, I suggest removing =C2=B3directly=C2=B2. >=20 > But, in general I think that the draft doesn=C2=B9t need to mention 524= 5bis > procedures that are unchanged. Instead there could be a generic stateme= nt > in the beginning of the document, saying that unless otherwise stated t= he > procedures in 5245bis apply. WFM. Peter --ktxAGUPazHiv1DNqS5BgY3kRh1xNrmTLD-- --IOegpmBaJKSjCNFrMAuzfpSDb9pU7gmgo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqZv28ACgkQZWGMGH9o FKmgoQ/9EhQ3MZ3aDT3+bFi3cQZ164OlQgCwbwKAsW+i9iLjfECyT26HIdAGve7+ PxRkNuJKkPmzUCHe78Ejqg8BCdYEspTHk7lxzET6EdkwoHhMPaYlvnc7KqXJNaME jmfK1aojDnfLzhj3jTM0Us5ClH0oyrnbWu2DEM9WwgcMaHNOmhhU7IsK1W83iha6 ZXYRCkvJF+aRKCZsI/y9Rvi6IQU535XRMR0y2TYTviRpw6flr39ZjI0U0LUsqrY5 TK6uVYAySqiN0bmDSdNcf5WTEWsfQt837HrX6qtu7C0coH8RIS/ctqMuTWMukpnt 4ePvG6DVuguSZ1apr67ujg/V87jSomWHEn9n33JYXe9jHSZIOGSySTAPF+CzUGlB QJSma1uZ/55wB3rNuC+TopNoiu14kTDeTe8YjUhkwCfAAexHXN/TZLNDYtlbOxJg ivTmhZI58a7pdyzxtQlTJtffkSu+Nurak+p9yTFcOgQkcZn/ZiifwjZ5H3jaBJuY B8SqzBHvKJ4kvDfvutqA643sFoNOl5Zv9IlDkB+7vJ7JivR+NIAQ2z/87g2Xzs4f AGKjlqiuLKyjzEVsLehilElI4fVSncCs+k4gsBbFfR8VvfDwWjsUPIuZOp6/1zdd GyKs0PjIomtuLMBGCQiUvPBXQiaVEH44TTh8x9GPlo1rrBwToRU= =r7yS -----END PGP SIGNATURE----- --IOegpmBaJKSjCNFrMAuzfpSDb9pU7gmgo-- From nobody Fri Mar 2 13:21:38 2018 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 C4706124F57 for ; Fri, 2 Mar 2018 13:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 1_63fm1g-f2U for ; Fri, 2 Mar 2018 13:21:34 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 AE9C112025C for ; Fri, 2 Mar 2018 13:21:34 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id p78so12014673iod.13 for ; Fri, 02 Mar 2018 13:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=nARVgp+ZzpuUvT+71byOEpx0y1AqLouY7el6OUFNcXA=; b=EwBsVPfUnIPMVPjPhm5q8lUyaSOkK+YZwvICPng97DBAOCKK4VNgqE3CmDnE3azjHR ay82vGiOcxnq4SW/+dDN2lpkL6iupxq6Vj6BCzTi3Mi14h6zAVJFYPnwkv0OXjVn2tb9 u+vvAGuxQFba6+DdUWcv2T0THrYO3hPXSKnek= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=nARVgp+ZzpuUvT+71byOEpx0y1AqLouY7el6OUFNcXA=; b=tb5xvEJC504ofzlEzxclPELv1dfS0xzWssiYTLKH8ghytm59UOe1I2t4NVO5sqbdK0 jVkCmXuKPnmAgx0JKyfOAdgL3LcguvwycKjOS3hW2WED1/ksReT6tbXKXaRmXvpBhQV9 lbUKMqCrHJBwON525mWG4YTn6LK5SPbp7fzqUPXu+8XmYwiLOOkP63CiIyl8/t5dcetf jWBvel8NTdXxMC59VMXUIQidXYABw0nsqhYBFJa4rFjPte5d0izcYpFFF17wu+bCgtJs 8Ci7NKtzuNoPKWzFU9fT3qDidMXtO0aVwGitxiIZOM2vKXU7nyj9+9nHnYVqGBg6NyTA 6rgg== X-Gm-Message-State: AElRT7GFndfKwi5RlqLcmuuBQZQljOap2xNtm8vipsZRFJAXPIHM0KLR mhlHldMJqSzPIQaeF+5mTpWVVg== X-Google-Smtp-Source: AG47ELsQ31tUZk0hXkEImQI9GA9r4M1o0f6TSR4ZUS2+e+8hjjeRlrdKDP4+yyez7gvEdNiy0KKbGA== X-Received: by 10.107.160.74 with SMTP id j71mr8148156ioe.10.1520025693981; Fri, 02 Mar 2018 13:21:33 -0800 (PST) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id 12sm1190384itm.8.2018.03.02.13.21.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Mar 2018 13:21:33 -0800 (PST) To: Nils Ohlmeier , Christer Holmberg Cc: "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: Date: Fri, 2 Mar 2018 14:21:31 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ypfKztf4qk5yzbLdNi7LCnhkOtvPakrTg" Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 02 Mar 2018 21:21:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ypfKztf4qk5yzbLdNi7LCnhkOtvPakrTg Content-Type: multipart/mixed; boundary="XxJBF8FKYWLOtnDIMZKpQsxGjwEHzYkhQ"; protected-headers="v1" From: Peter Saint-Andre To: Nils Ohlmeier , Christer Holmberg Cc: "ice@ietf.org" Message-ID: Subject: Re: [Ice] Trickle: A couple of questions on section 7 References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se> In-Reply-To: --XxJBF8FKYWLOtnDIMZKpQsxGjwEHzYkhQ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/2/18 11:20 AM, Nils Ohlmeier wrote: >=20 >=20 >> On Feb 27, 2018, at 11:29, Christer Holmberg wrote: >>> >>>>>> *Q1:* >>>>>> >>>>>> Section 7.1 says: >>>>>> >>>>>> "The ICE specification [rfc5245bis], Section 6.1.4.2, specifies >>>>>> that an agent will terminate the timer for a triggered check in= >>>>>> relation to a check list once the agent has exhausted all froze= n pairs in >>>>>> the check list. This will not work with Trickle ICE, because m= ore >>>>>> pairs will be added to the check list incrementally." >>>>>> >>>>>> Exactly what procedure in 5245bis dos this text refer to? >>>>> >>>>> Hmm, good question. Emil wrote that text so we might want to check >>>>> with him, but looking at 5245bis I'd say it refers to the last >>>>> sentence in Step 4 of =C2=A76.1.4.2: >>>>> >>>>> 4. If this step is reached, no check could be performed for the >>>>> picked check list. So, without waiting for timer Ta to expire= >>>>> again, select the next check list in the Running state and ret= urn >>>>> to step #1. If this happens for every single check list in th= e >>>>> Running state, meaning there are no remaining candidate pairs = to >>>>> perform connectivity checks for, abort these steps. >>>>> >>>>> However, that refers to exhausting all the candidate pairs to be >>>>> checked for all check lists, not to "terminat[ing] the timer for a >>>>> triggered check in relation to a check list once the agent has >>>>> exhausted all frozen pairs in the check list". So we might want to = ping Emil. >>>> >>>> I think "terminate the timer" is misleading wording. Timer Ta is not= >>>> terminated as long as there is at least one check list in "Running" = mode. >>>> >>>> It is true that, whenever timer Ta fires, check lists that are not i= n >>>> the "Running" mode will not be checked. But, even with legacy ICE, a= >>>> check list may put back in "Running" mode if e.g., a triggered check= >>>> changes that status of a failed pair, and if that pair state change >>>> affects the state of the check list. >>>> >>>> So, unless I=C2=B9ve missed something, I don=C2=B9t think that trick= le changes >>>> how check lists are checked when Ta fires. If additional candidates >>>> have been gathered, and added to a check list, step 4) in section >>>> 6.1.4.2 will not be reached. >>> >>> I suspect that Emil might have been thinking about trickling of candi= dates after nomination of a >>> candidate pair, but we'll drag him into the conversation one way or a= nother. ;-) >> >> I think you raise an important point. Once you have nominated a pair, = you can't nominate another pair (that would be "continuous nomination", w= hich is outside the scope of trickle). I think you should add text about = that, because I don't think it is currently mentioned. The draft does say= that "ICE processing" might end before end-of-candidates have been conve= yed, but that's a separate thing. I guess nomination would also implicitl= y mean end-of-candidates, and neither agent should trickle any more candi= dates after nomination is done. >=20 > Stopping to trickle is one aspect of it. But there can also be still tr= ickled candidates in flight over the signaling path which arrive after no= mination has concluded on the ICE layer. I think it makes more sense to a= ddress this on the receiving end and advise that ICE agents which still r= eceive candidates after nomination has concluded, should ignore these new= candidates. Yes, that seems reasonable. A good location for this text is Section 10: OLD When an agent receives an end-of-candidates indication for a specific media stream, it will update the state of the relevant check list as per Section 7.2. If the check list is still in the Active state after the update, the agent will persist the fact that an end-of- candidates indication has been received and take it into account in future updates to the check list. NEW When an agent receives an end-of-candidates indication for a specific media stream, it will update the state of the relevant check list as per Section 7.2. If the check list is still in the Active state after the update, the agent will persist the fact that an end-of- candidates indication has been received and take it into account in future updates to the check list. Although the agent might receive additional "inf-flight" candidates after receiving the end-of- candidates indication, it MUST ignore those candidates. > Another aspect might be continuous nomination in the future. If we dema= nd that the emitting agents stops trickling it might be harder to open it= up for continuous nomination again. Where if we only tell the receiving = agent to ignore candidates which arrive after nomination has concluded it= should be trivial for continuous nomination to lift/change that part of = the spec. Good point. Peter --XxJBF8FKYWLOtnDIMZKpQsxGjwEHzYkhQ-- --ypfKztf4qk5yzbLdNi7LCnhkOtvPakrTg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqZwFwACgkQZWGMGH9o FKnx1BAAkrMiudsB4DjSWQTFHy5vm9uXfhWLE0gnHohUDJqBvFHgex99du5Nsh2a O2+l/kqO8YDev6txyKnoK4ef2KqczXArFFDyhigOpaZeqbGeIDGAsQx6nKFUhPow BMX/lSm2M4J09lEv4BRtMFMc79g5Re24/gle0U8EWUoBn8PIfrkhp9/H7TESXJTU 9dIoleCw0AbZYX2jqeGRusPpvlVB+LmCLOrJU+xxVjIgWu3OBKcrG3z1WYg1UB3N t85yFfJ8R5WDFZHgJaIg66fxmyk6aKQ72/eIIwQw73eCNdsNlTh0cyZcP5kR38mw tpBjn8o97yWSD1ooWnC1v4n27YLOkA14AgUA8u+QzrWPZZjchT61B9zxN95RKVdD j+0y5QDeGTHTecjArqdkdFOaKNXi356fzeTrISvQT4mU+Ogon7PY/ydeCBisACWj 4XoLsc9IL7ZR+2gVOYahfXZ1lSHtm8dTW3aH3mzMprhvp7Wn+gCC8n21fBJ9aFEx Y7ngeGg+yj8ucCjhUq0vsoNIepGTuDmcNKzfH7BmYgKZ/8DYhBvfebJpA0ku4O8E iNshRD1kibtjDt6cCulDTXu3mKKfu7nNIqWZ+/DJB9j5eCWpUkLC98OliTwDekKT LTjfuDRj6az+hk/mtmRMMUqlHox/XAkXRzIaO9OlC0MZQNnFWOE= =9v19 -----END PGP SIGNATURE----- --ypfKztf4qk5yzbLdNi7LCnhkOtvPakrTg-- From nobody Fri Mar 2 13:28:12 2018 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 5C65E120227 for ; Fri, 2 Mar 2018 13:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 ecpgDykwf2IN for ; Fri, 2 Mar 2018 13:28:09 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16621200E5 for ; Fri, 2 Mar 2018 13:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520026087; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=yFSFEqhNuDMJ8OEDijP+qaGhbNueCVG3Mu6nqXO33tY=; b=Z3Erkh1iaNFBmNFX31J18nQjqAT/ytCJNUkS5onswqL51PusTVXVi0W+80V5jGIW CDiUKlhD7Zyd/IGyPpoR7V6SAmZfP0qkzPJxJJ0ffFXbXBgE+QNE9NmYgpuFAvU9 c8pFZUdcBPtZRzyxWFobmmekZAIsBMayeHPqs2Ykkl0=; X-AuditID: c1b4fb2d-4b1ff70000005540-14-5a99c1e6086c Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.0B.21824.6E1C99A5; Fri, 2 Mar 2018 22:28:06 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Fri, 2 Mar 2018 22:28:06 +0100 From: Christer Holmberg To: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] Trickle: Example in Section 17 Thread-Index: AQHTsGIj+N6AZJgq6Eqdtmvv+qQzDqO9ZhGAgAATHUA= Date: Fri, 2 Mar 2018 21:28:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1BC745@ESESSMB109.ericsson.se> References: <3d8c74e3-57cf-3044-585b-f044bd534c2a@mozilla.com> In-Reply-To: <3d8c74e3-57cf-3044-585b-f044bd534c2a@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7qO6zgzOjDB7ct7H4dqHW4tnKU4wO TB5Llvxk8ug70MUawBTFZZOSmpNZllqkb5fAlTH1QgdbwUKOimUT7jE1MB5i62Lk5JAQMJGY OOkGaxcjF4eQwGFGidcnvzNBOIsYJT5u38jSxcjBwSZgIdH9TxukQUTAS2LmnvtMILawgKHE 140/mCHiRhJNNzYzQdhWEkc63zOCtLIIqEjseOEMEuYV8JU4/f0CO4gtJFAgsfPlHrAbOAXs Jd73rgVrZRQQk/h+ag2YzSwgLnHryXwmiDsFJJbsOc8MYYtKvHz8jxXCVpJYPm0LO0S9jsSC 3Z/YIGxtiWULXzND7BWUODnzCcsERpFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWF+emGxnrpRZl JhcX5+fp5aWWbGIExsLBLb91dzCufu14iFGAg1GJh/fs9plRQqyJZcWVuYcYJTiYlUR4Wz7M iBLiTUmsrEotyo8vKs1JLT7EKM3BoiTOe9KTN0pIID2xJDU7NbUgtQgmy8TBKdXAuEK3RDXl 38GcqNSQQ8L9mV6z2Nlc9i9WOly244beYsOGM1+5uJeeawr5mTNbSHtTiqrOxEsy7wWP73Ze cm/tqeu6PLcUl76ZsPvC6S7dou9TEr0yTd7aZL6t5Mu/e6XELpJL6+LjO4t79ZhTGVY/S7x/ 7bLfN74YN67sfdPfPj9usVY2TVumU4mlOCPRUIu5qDgRAFo/kICBAgAA Archived-At: Subject: Re: [Ice] Trickle: Example in Section 17 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, 02 Mar 2018 21:28:10 -0000 Hi, >> I think the example in Section 17 should be more detailed. Currently I=20 >> wouldn't even consider the flow an example - it's just a high-level=20 >> visualisation of trickle :) > > It's not an example, it's an "example flow", i.e., a visualization. This = probably belongs in the introduction. I don't think it's even an "example flow", but we don't need to argue about= that :)=20 My point is that it only shows that you can send initial candidates, and th= en trickle more. >> Perhaps using the example in Section 15 of 5245bis as base, and then=20 >> add some trickle stuff there? > > Right, that would be a true example, instead of the flow visualization. I think that would be very useful. > We'll look into adding this. (An actual protocol example is more appropri= ate for draft-ietf-mmusic-trickle-ice-sip.) The example in 5245bis is protocol independent. I don't think the important thing to show is that you can trickle candidate= s, but more how it affects the checks etc. Regards, Christer From nobody Fri Mar 2 13:42:25 2018 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 D2E491200E5 for ; Fri, 2 Mar 2018 13:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 6w3pZtv0nY-k for ; Fri, 2 Mar 2018 13:42:21 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC2A12025C for ; Fri, 2 Mar 2018 13:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520026939; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=m7WxLhLE+WAbKUuApE34jsLkIHpaWnG2jAfQKhRXPcM=; b=LfAA9Xxa1CAnp7R34Au3Pr2jLPYor9Tau3YQm+0MyR1OSpMdwwsKzAX9NKJ+9cSy iZznD1DYuRFVz5lkWZu0oRDKUttg8ctJEvyDBeVs/q9JpbQxeOqQuWWBYbiM2gCQ zueRyGDv9tpRyHHbemzwNjImzOnzQKtDbgZosaPXkAo=; X-AuditID: c1b4fb2d-4b1ff70000005540-59-5a99c53b2b34 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2A.3C.21824.B35C99A5; Fri, 2 Mar 2018 22:42:19 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Fri, 2 Mar 2018 22:42:19 +0100 From: Christer Holmberg To: Peter Saint-Andre , Nils Ohlmeier CC: "ice@ietf.org" Thread-Topic: [Ice] Trickle: A couple of questions on section 7 Thread-Index: AdOucJgg+M5x/JnqQAe0nEYDsAIfMAA5PBQAABTM7oAAEyrzgAACkKBQAJLFpgAABlMCgAACaSig Date: Fri, 2 Mar 2018 21:42:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1BC7F7@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7tK710ZlRBgfP6ll8u1BrcX3eZEaL ZytPMToweyxZ8pPJo+9AF2sAUxSXTUpqTmZZapG+XQJXRu/hRawF/2wqLk8+wdjAuMW6i5GT Q0LARGLzmxMsXYxcHEIChxkl3k++ywjhLGKU2Ny6gr2LkYODTcBCovufNkiDiECIxKwvPWBh ZgFFiZd71UDCwgJ2Er3n17BDlNhLbOu9xgJhR0lM3naCGcRmEVCRWHp3FiOIzSvgK9H5dikr xKrpzBJ/Ll8BS3ACNc/sv8YKYjMKiEl8P7WGCcRmFhCXuPVkPhPE0QISS/acZ4awRSVePv7H CmErSSyftgXqNk2J9bv0IVoVJaZ0P2SH2CsocXLmE5YJjKKzkEydhdAxC0nHLCQdCxhZVjGK FqcWF+emGxnrpRZlJhcX5+fp5aWWbGIExsrBLb91dzCufu14iFGAg1GJh/fs9plRQqyJZcWV uYcYJTiYlUR4Wz7MiBLiTUmsrEotyo8vKs1JLT7EKM3BoiTOe9KTN0pIID2xJDU7NbUgtQgm y8TBKdXAWHMu673G4/mvduZ/ic//5NswN3eykGnkiQp5tZDUvEORVpc2bn1dMZub+2bA/zl7 Ug5+uFSXeIDp67kNMedD9iyQMNB/dyVk2rtJTFUS5yeeWcSWsXh/glPH/asVM9Vii27JsHt6 bvlo5nj5VVrAXFXZn+XeznIWIe5df6ffWqE0p0zNfmPgVSWW4oxEQy3mouJEAOQgLy6RAgAA Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 02 Mar 2018 21:42:23 -0000 SGksDQoNCj4+Pj4+Pj4gKlExOioNCj4+Pj4+Pj4NCj4+Pj4+Pj4gU2VjdGlvbiA3LjEgc2F5czoN Cj4+Pj4+Pj4NCj4+Pj4+Pj4gICAiVGhlIElDRSBzcGVjaWZpY2F0aW9uIFtyZmM1MjQ1YmlzXSwg U2VjdGlvbiA2LjEuNC4yLCBzcGVjaWZpZXMNCj4+Pj4+Pj4gICAgdGhhdCBhbiBhZ2VudCB3aWxs IHRlcm1pbmF0ZSB0aGUgdGltZXIgZm9yIGEgdHJpZ2dlcmVkIGNoZWNrIGluDQo+Pj4+Pj4+ICAg IHJlbGF0aW9uIHRvIGEgY2hlY2sgbGlzdCBvbmNlIHRoZSBhZ2VudCBoYXMgZXhoYXVzdGVkIGFs bCBmcm96ZW4gcGFpcnMgaW4NCj4+Pj4+Pj4gICAgdGhlIGNoZWNrIGxpc3QuICBUaGlzIHdpbGwg bm90IHdvcmsgd2l0aCBUcmlja2xlIElDRSwgYmVjYXVzZSBtb3JlDQo+Pj4+Pj4+ICAgIHBhaXJz IHdpbGwgYmUgYWRkZWQgdG8gdGhlIGNoZWNrIGxpc3QgaW5jcmVtZW50YWxseS4iDQo+Pj4+Pj4+ DQo+Pj4+Pj4+IEV4YWN0bHkgd2hhdCBwcm9jZWR1cmUgaW4gNTI0NWJpcyBkb3MgdGhpcyB0ZXh0 IHJlZmVyIHRvPw0KPj4+Pj4+DQo+Pj4+Pj4gSG1tLCBnb29kIHF1ZXN0aW9uLiBFbWlsIHdyb3Rl IHRoYXQgdGV4dCBzbyB3ZSBtaWdodCB3YW50IHRvIGNoZWNrIA0KPj4+Pj4+IHdpdGggaGltLCBi dXQgbG9va2luZyBhdCA1MjQ1YmlzIEknZCBzYXkgaXQgcmVmZXJzIHRvIHRoZSBsYXN0IA0KPj4+ Pj4+IHNlbnRlbmNlIGluIFN0ZXAgNCBvZiDCpzYuMS40LjI6DQo+Pj4+Pj4NCj4+Pj4+PiAgNC4g IElmIHRoaXMgc3RlcCBpcyByZWFjaGVkLCBubyBjaGVjayBjb3VsZCBiZSBwZXJmb3JtZWQgZm9y IHRoZQ0KPj4+Pj4+ICAgICAgcGlja2VkIGNoZWNrIGxpc3QuICBTbywgd2l0aG91dCB3YWl0aW5n IGZvciB0aW1lciBUYSB0byBleHBpcmUNCj4+Pj4+PiAgICAgIGFnYWluLCBzZWxlY3QgdGhlIG5l eHQgY2hlY2sgbGlzdCBpbiB0aGUgUnVubmluZyBzdGF0ZSBhbmQgcmV0dXJuDQo+Pj4+Pj4gICAg ICB0byBzdGVwICMxLiAgSWYgdGhpcyBoYXBwZW5zIGZvciBldmVyeSBzaW5nbGUgY2hlY2sgbGlz dCBpbiB0aGUNCj4+Pj4+PiAgICAgIFJ1bm5pbmcgc3RhdGUsIG1lYW5pbmcgdGhlcmUgYXJlIG5v IHJlbWFpbmluZyBjYW5kaWRhdGUgcGFpcnMgdG8NCj4+Pj4+PiAgICAgIHBlcmZvcm0gY29ubmVj dGl2aXR5IGNoZWNrcyBmb3IsIGFib3J0IHRoZXNlIHN0ZXBzLg0KPj4+Pj4+DQo+Pj4+Pj4gSG93 ZXZlciwgdGhhdCByZWZlcnMgdG8gZXhoYXVzdGluZyBhbGwgdGhlIGNhbmRpZGF0ZSBwYWlycyB0 byBiZSANCj4+Pj4+PiBjaGVja2VkIGZvciBhbGwgY2hlY2sgbGlzdHMsIG5vdCB0byAidGVybWlu YXRbaW5nXSB0aGUgdGltZXIgZm9yIGEgDQo+Pj4+Pj4gdHJpZ2dlcmVkIGNoZWNrIGluIHJlbGF0 aW9uIHRvIGEgY2hlY2sgbGlzdCBvbmNlIHRoZSBhZ2VudCBoYXMgDQo+Pj4+Pj4gZXhoYXVzdGVk IGFsbCBmcm96ZW4gcGFpcnMgaW4gdGhlIGNoZWNrIGxpc3QiLiBTbyB3ZSBtaWdodCB3YW50IHRv IHBpbmcgRW1pbC4NCj4+Pj4+DQo+Pj4+PiBJIHRoaW5rICJ0ZXJtaW5hdGUgdGhlIHRpbWVyIiBp cyBtaXNsZWFkaW5nIHdvcmRpbmcuIFRpbWVyIFRhIGlzIA0KPj4+Pj4gbm90IHRlcm1pbmF0ZWQg YXMgbG9uZyBhcyB0aGVyZSBpcyBhdCBsZWFzdCBvbmUgY2hlY2sgbGlzdCBpbiAiUnVubmluZyIg bW9kZS4NCj4+Pj4+DQo+Pj4+PiBJdCBpcyB0cnVlIHRoYXQsIHdoZW5ldmVyIHRpbWVyIFRhIGZp cmVzLCBjaGVjayBsaXN0cyB0aGF0IGFyZSBub3QgDQo+Pj4+PiBpbiB0aGUgIlJ1bm5pbmciIG1v ZGUgd2lsbCBub3QgYmUgY2hlY2tlZC4gQnV0LCBldmVuIHdpdGggbGVnYWN5IA0KPj4+Pj4gSUNF LCBhIGNoZWNrIGxpc3QgbWF5IHB1dCBiYWNrIGluICJSdW5uaW5nIiBtb2RlIGlmIGUuZy4sIGEg DQo+Pj4+PiB0cmlnZ2VyZWQgY2hlY2sgY2hhbmdlcyB0aGF0IHN0YXR1cyBvZiBhIGZhaWxlZCBw YWlyLCBhbmQgaWYgdGhhdCANCj4+Pj4+IHBhaXIgc3RhdGUgY2hhbmdlIGFmZmVjdHMgdGhlIHN0 YXRlIG9mIHRoZSBjaGVjayBsaXN0Lg0KPj4+Pj4NCj4+Pj4+IFNvLCB1bmxlc3MgScK5dmUgbWlz c2VkIHNvbWV0aGluZywgSSBkb27CuXQgdGhpbmsgdGhhdCB0cmlja2xlIA0KPj4+Pj4gY2hhbmdl cyBob3cgY2hlY2sgbGlzdHMgYXJlIGNoZWNrZWQgd2hlbiBUYSBmaXJlcy4gSWYgYWRkaXRpb25h bCANCj4+Pj4+IGNhbmRpZGF0ZXMgaGF2ZSBiZWVuIGdhdGhlcmVkLCBhbmQgYWRkZWQgdG8gYSBj aGVjayBsaXN0LCBzdGVwIDQpIA0KPj4+Pj4gaW4gc2VjdGlvbg0KPj4+Pj4gNi4xLjQuMiB3aWxs IG5vdCBiZSByZWFjaGVkLg0KPj4+Pg0KPj4+PiBJIHN1c3BlY3QgdGhhdCBFbWlsIG1pZ2h0IGhh dmUgYmVlbiB0aGlua2luZyBhYm91dCB0cmlja2xpbmcgb2YgDQo+Pj4+IGNhbmRpZGF0ZXMgYWZ0 ZXIgbm9taW5hdGlvbiBvZiBhIGNhbmRpZGF0ZSBwYWlyLCBidXQgd2UnbGwgZHJhZyBoaW0gDQo+ Pj4+IGludG8gdGhlIGNvbnZlcnNhdGlvbiBvbmUgd2F5IG9yIGFub3RoZXIuIDstKQ0KPj4+DQo+ Pj4gSSB0aGluayB5b3UgcmFpc2UgYW4gaW1wb3J0YW50IHBvaW50LiBPbmNlIHlvdSBoYXZlIG5v bWluYXRlZCBhIHBhaXIsIHlvdSBjYW4ndCBub21pbmF0ZSBhbm90aGVyIA0KPj4+IHBhaXIgKHRo YXQgd291bGQgYmUgImNvbnRpbnVvdXMgbm9taW5hdGlvbiIsIHdoaWNoIGlzIG91dHNpZGUgdGhl IHNjb3BlIG9mIHRyaWNrbGUpLiBJIHRoaW5rIHlvdSANCj4+PiBzaG91bGQgYWRkIHRleHQgYWJv dXQgdGhhdCwgYmVjYXVzZSBJIGRvbid0IHRoaW5rIGl0IGlzIGN1cnJlbnRseSBtZW50aW9uZWQu IFRoZSBkcmFmdCBkb2VzIHNheSB0aGF0IA0KPj4+ICJJQ0UgcHJvY2Vzc2luZyIgbWlnaHQgZW5k IGJlZm9yZSBlbmQtb2YtY2FuZGlkYXRlcyBoYXZlIGJlZW4gY29udmV5ZWQsIGJ1dCB0aGF0J3Mg YSBzZXBhcmF0ZSB0aGluZy4gDQo+Pj4gSSBndWVzcyBub21pbmF0aW9uIHdvdWxkIGFsc28gaW1w bGljaXRseSBtZWFuIGVuZC1vZi1jYW5kaWRhdGVzLCBhbmQgbmVpdGhlciBhZ2VudCBzaG91bGQg dHJpY2tsZSBhbnkgDQo+Pj4gbW9yZSBjYW5kaWRhdGVzIGFmdGVyIG5vbWluYXRpb24gaXMgZG9u ZS4NCj4+IA0KPj4gU3RvcHBpbmcgdG8gdHJpY2tsZSBpcyBvbmUgYXNwZWN0IG9mIGl0LiBCdXQg dGhlcmUgY2FuIGFsc28gYmUgc3RpbGwgdHJpY2tsZWQgY2FuZGlkYXRlcyBpbiBmbGlnaHQgb3Zl ciB0aGUgc2lnbmFsaW5nIHBhdGggDQo+PiB3aGljaCBhcnJpdmUgYWZ0ZXIgbm9taW5hdGlvbiBo YXMgY29uY2x1ZGVkIG9uIHRoZSBJQ0UgbGF5ZXIuIEkgdGhpbmsgaXQgbWFrZXMgbW9yZSBzZW5z ZSB0byBhZGRyZXNzIHRoaXMgb24gdGhlIA0KPj4gcmVjZWl2aW5nIGVuZCBhbmQgYWR2aXNlIHRo YXQgSUNFIGFnZW50cyB3aGljaCBzdGlsbCByZWNlaXZlIGNhbmRpZGF0ZXMgYWZ0ZXIgbm9taW5h dGlvbiBoYXMgY29uY2x1ZGVkLCBzaG91bGQgDQo+PiBpZ25vcmUgdGhlc2UgbmV3IGNhbmRpZGF0 ZXMuDQo+DQo+IFllcywgdGhhdCBzZWVtcyByZWFzb25hYmxlLiBBIGdvb2QgbG9jYXRpb24gZm9y IHRoaXMgdGV4dCBpcyBTZWN0aW9uIDEwOg0KPg0KPk9MRA0KPiAgIFdoZW4gYW4gYWdlbnQgcmVj ZWl2ZXMgYW4gZW5kLW9mLWNhbmRpZGF0ZXMgaW5kaWNhdGlvbiBmb3IgYSBzcGVjaWZpYw0KPiAg IG1lZGlhIHN0cmVhbSwgaXQgd2lsbCB1cGRhdGUgdGhlIHN0YXRlIG9mIHRoZSByZWxldmFudCBj aGVjayBsaXN0IGFzDQo+ICAgcGVyIFNlY3Rpb24gNy4yLiAgSWYgdGhlIGNoZWNrIGxpc3QgaXMg c3RpbGwgaW4gdGhlIEFjdGl2ZSBzdGF0ZQ0KPiAgIGFmdGVyIHRoZSB1cGRhdGUsIHRoZSBhZ2Vu dCB3aWxsIHBlcnNpc3QgdGhlIGZhY3QgdGhhdCBhbiBlbmQtb2YtDQo+ICAgY2FuZGlkYXRlcyBp bmRpY2F0aW9uIGhhcyBiZWVuIHJlY2VpdmVkIGFuZCB0YWtlIGl0IGludG8gYWNjb3VudCBpbg0K PiAgIGZ1dHVyZSB1cGRhdGVzIHRvIHRoZSBjaGVjayBsaXN0Lg0KPg0KPk5FVw0KPiAgIFdoZW4g YW4gYWdlbnQgcmVjZWl2ZXMgYW4gZW5kLW9mLWNhbmRpZGF0ZXMgaW5kaWNhdGlvbiBmb3IgYSBz cGVjaWZpYw0KPiAgIG1lZGlhIHN0cmVhbSwgaXQgd2lsbCB1cGRhdGUgdGhlIHN0YXRlIG9mIHRo ZSByZWxldmFudCBjaGVjayBsaXN0IGFzDQo+ICAgcGVyIFNlY3Rpb24gNy4yLiAgSWYgdGhlIGNo ZWNrIGxpc3QgaXMgc3RpbGwgaW4gdGhlIEFjdGl2ZSBzdGF0ZQ0KPiAgIGFmdGVyIHRoZSB1cGRh dGUsIHRoZSBhZ2VudCB3aWxsIHBlcnNpc3QgdGhlIGZhY3QgdGhhdCBhbiBlbmQtb2YtDQo+ICAg Y2FuZGlkYXRlcyBpbmRpY2F0aW9uIGhhcyBiZWVuIHJlY2VpdmVkIGFuZCB0YWtlIGl0IGludG8g YWNjb3VudCBpbg0KPiAgIGZ1dHVyZSB1cGRhdGVzIHRvIHRoZSBjaGVjayBsaXN0LiBBbHRob3Vn aCB0aGUgYWdlbnQgbWlnaHQgcmVjZWl2ZQ0KPiAgIGFkZGl0aW9uYWwgImluZi1mbGlnaHQiIGNh bmRpZGF0ZXMgYWZ0ZXIgcmVjZWl2aW5nIHRoZSBlbmQtb2YtDQo+ICAgY2FuZGlkYXRlcyBpbmRp Y2F0aW9uLCBpdCBNVVNUIGlnbm9yZSB0aG9zZSBjYW5kaWRhdGVzLg0KDQpGaXJzdCwgIkFjdGl2 ZSBzdGF0ZSIgKGFjdHVhbGx5LCBpdCB3YXMgbmV2ZXIgZXZlbiBhIHN0YXRlLCBqdXN0IGEgInBy b3BlcnR5IikgaGFzIGJlZW4gcmVtb3ZlZCBmcm9tIDUyNDViaXMsIHNvIHdlIHNob3VsZCBub3Qg dXNlIHRoYXQgdGVybWlub2xvZ3kuIEkgZ3Vlc3MgaXQgc2hvdWxkIGJlICJSdW5uaW5nIHN0YXRl Ii4NCg0KU2Vjb25kLCB3aGF0IGRvZXMgdGhlICJJZiB0aGUgY2hlY2sgbGlzdC4uLiIgc2VudGVu Y2UgYWN0dWFsbHkgbWVhbj8gV2hhdCB3aWxsIGJlIHRha2VuIGludG8gYWNjb3VudD8NCg0KVGhp cmQsIGlmIHRoZSBhZ2VudCByZWNlaXZlcyBhZGRpdGlvbmFsIGNhbmRpZGF0ZXMsIHNob3VsZCBp dCBhY2NlcHQgb3IgcmVqZWN0IHRoZSBtZXNzYWdlIGNhcnJ5aW5nIHRoZW0/IFRoZSBleGFjdCB3 YXkgb2YgYWNjZXB0aW5nIGFuZCByZWplY3RpbmcgaXMgb2YgY291cnNlIHByb3RvY29sIHNwZWNp ZmljLCBidXQgSSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIGdpdmUgc29tZSBndWlkYW5jZS4gSW4g bXkgb3BpbmlvbiB0aGUgbWVzc2FnZXMgc2hvdWxkIGJlIHJlamVjdGVkLCB0byBpbmZvcm0gdGhl IHBlZXIgdGhhdCB0aGUgYWdlbnQgaXMgbm90IGdvaW5nIHRvIGRvIGFueXRoaW5nIHdpdGggdGhl IGNhbmRpZGF0ZXMuDQoNCj4gQW5vdGhlciBhc3BlY3QgbWlnaHQgYmUgY29udGludW91cyBub21p bmF0aW9uIGluIHRoZSBmdXR1cmUuIElmIHdlIGRlbWFuZCB0aGF0IHRoZSBlbWl0dGluZyBhZ2Vu dHMgc3RvcHMgdHJpY2tsaW5nIGl0IG1pZ2h0IGJlIGhhcmRlciANCj4gdG8gb3BlbiBpdCB1cCBm b3IgY29udGludW91cyBub21pbmF0aW9uIGFnYWluLiBXaGVyZSBpZiB3ZSBvbmx5IHRlbGwgdGhl IHJlY2VpdmluZyBhZ2VudCB0byBpZ25vcmUgY2FuZGlkYXRlcyB3aGljaCBhcnJpdmUgYWZ0ZXIg bm9taW5hdGlvbiANCj4gaGFzIGNvbmNsdWRlZCBpdCBzaG91bGQgYmUgdHJpdmlhbCBmb3IgY29u dGludW91cyBub21pbmF0aW9uIHRvIGxpZnQvY2hhbmdlIHRoYXQgcGFydCBvZiB0aGUgc3BlYy4N Cg0KSUYgd2UgZGVjaWRlIHRvIGRvIGNvbnRpbnVvdXMgbm9taW5hdGlvbiwgd2UgY2FuIGFsd2F5 cyBjaGFuZ2UgdGhlIHJ1bGVzIGZvciB0aGF0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN Cg== From nobody Sun Mar 4 21:27:29 2018 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 86C93124235; Sun, 4 Mar 2018 21:27:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-ice-rfc5245bis@ietf.org, Peter Thatcher , ice-chairs@ietf.org, pthatcher@google.com, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152022764354.27886.13431291573089582372.idtracker@ietfa.amsl.com> Date: Sun, 04 Mar 2018 21:27:23 -0800 Archived-At: Subject: [Ice] Suresh Krishnan's No Objection on draft-ietf-ice-rfc5245bis-18: (with COMMENT) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 05:27:23 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-ice-rfc5245bis-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and for adding an additional example. From nobody Mon Mar 5 04:12:48 2018 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 6A31512D7E2 for ; Mon, 5 Mar 2018 04:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 1UGV_0FHlHri for ; Mon, 5 Mar 2018 04:12:42 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E96124207 for ; Mon, 5 Mar 2018 04:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520251956; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=t0pfyuAWb1oTu0zmQlSqfAmSm/IYBVMmJj+U8C8UA/U=; b=fDvBjn3QtO5O0YbpqdYtbaaN0C8CesaLyEEq3Di02Dv4EFrAoTguzdLb65gz/Vru v0Nt2HPobZCMBdTw0HZ1xXPqKpdTr7smQHAJdhaTaitaOMtUMyQFIdM98OYJXmdL LxzSpmbI/V+OntEsh7z3BeWxk/KehpF42V0OLMJK9LI=; X-AuditID: c1b4fb2d-87c029c000005540-a4-5a9d3433e7f0 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 15.ED.21824.3343D9A5; Mon, 5 Mar 2018 13:12:36 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Mon, 5 Mar 2018 13:12:35 +0100 From: Christer Holmberg To: Magnus Westerlund , "tsv-art@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Thread-Topic: Tsvart last call review of draft-ietf-ice-rfc5245bis-16 Thread-Index: AQHTmc09cSMwjiuCL0KSsp8F+FSKLqOMj1UAgALAtgCAModAAA== Date: Mon, 5 Mar 2018 12:12:33 +0000 Message-ID: References: <151731848710.27439.7061415423323921488@ietfa.amsl.com> <1d6ab623-0076-2e75-0e99-6a24e55ee934@ericsson.com> In-Reply-To: <1d6ab623-0076-2e75-0e99-6a24e55ee934@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3603104738_73050990" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM2K7lq6Jydwog74vXBbHf/xht/h2odbi 2cb5LBaz9ixicWDxWLLkJ1MAYxSXTUpqTmZZapG+XQJXxtxJB5kKdtpXnP65haWBcadNFyMn h4SAicShnVMZQWwhgcOMEqtWyHcxcgHZixgl7r1fxtzFyMHBJmAh0f1PG6RGRCBeomvrOzaQ GmaBmYwSr3++BGsWFnCR6Dr/mx2iyFXi+qs2ZgjbSeL6zvdMIDaLgIrE9s8NYHFeAWuJc7Oe M0MsW80ocXTTVbAiTgEHie/PJ7OA2IwCYhLfT60BizMLiEvcejKfCeJqEYmHF0+zQdiiEi8f /2MFsUUF9CQ2nLjNDnK0hICixPJ+OYjWSolJjXOYIPYKSpyc+YRlAqPoLCRTZyEpm4WkDCJu IPFn8SlWCFtb4sm7C1C2tcSMXwfZIGxFiSndD9khbFOJ10c/Mi5g5FjFKFqcWlycm25krJda lJlcXJyfp5eXWrKJERiPB7f81t3BuPq14yFGAQ5GJR7en3pzo4RYE8uKK3MPMaoAzXm0YfUF RimWvPy8VCURXilJoDRvSmJlVWpRfnxRaU5q8SFGaQ4WJXHek568UUIC6YklqdmpqQWpRTBZ Jg5OqQZG0567hpuWxC2QW7e51bRl7gyPTo2ITMnH56UKqxUFoj0TEot0+543WG3UfZj10fSW 1T0tQdveWb8/fnVzWm2yJVGC1zjslK1AwA67PesO9tzSDJqsnyIx+9yhUtlLrROzpD2Y1AL4 A3gOb3+eLLXI8MPdJwmKr6d9k7m7is/ifPvNd4ez/25SYinOSDTUYi4qTgQAIkigo88CAAA= Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16 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, 05 Mar 2018 12:12:44 -0000 --B_3603104738_73050990 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, --- >>> 11. Section 18.2: >>> >>> Local IPv6 addresses can be preferred. >>> >>> I think this sentence needs to clarify that it means local to host, >>> rather than >>> any form of relayed or translated address, rather than a local scope >>>only >>> IPv6 >>> address. >> I could say: >> >> "Local IPv6 host addresses" > >Maybe better: > >IPv6 address from the local host can be preferred. We had some off-line discussions with Magnus, as there were still some issues with the change - and also the existing text. The outcome was to simply remove the following sentence: "IPv6 address from the local host can be preferred.=B2 Regards, Christer --B_3603104738_73050990 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOQYJKoZIhvcNAQcCoIIUKjCCFCYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIMMIIGBjCCA+6gAwIBAgIQN4YipkcuAr1/ZKbsw+1eMTANBgkqhkiG9w0BAQsFADBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTAzMDgwODMyWhcNMjAxMTAzMDgwODMxWjBvMREw DwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRQ2hyaXN0ZXIgSG9sbWJlcmcxLTArBgkqhkiG 9w0BCQEWHmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTEPMA0GA1UEBRMGTE1GQ0hI MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy0z3dlyw+ybHo7PhlkBY00QOJB5T NOXcMdxiQ0nL5uM1C/0xQ7/T3uuHJRjD8nvqTqnlmfJ2VCZRKD3W8LJAUXGFd8JqwLJmGGZt cS3Jp+2WBAxBR6TjtcMwDGQNYD85YCKIuqcsarOxVhzXhwISp750JC1UmR4xxX1gbSkVb8S8 DsPsBioQ/Enkiad/rP0huQFb56Ocxu2Fy2aEW06ezyxU9My4Jh/vMDh+0DBb8EfN8ovAFmMH Qj3SxVUDwnTYbPdA1v3RipF/HH0NBsNOUS8RFct6OxHG1JDbMrkY9ErEKkrHmu3JyNM1hxmy 8rJl/yDID2n6vyxkh5QFcsvOdwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0 cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCB ggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEu Y29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNz c29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEeY2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEW LGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUESOe8HpdLQz1aZdNgbOPnJlysTIw HwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqG SIb3DQEBCwUAA4ICAQBdN30YKQsw+ow1tjR6gBDuNpQagWRw7DSkYXg4ZE5k76jyXPOTa9VE 8x3MbNIbsyuVLYiVIN/lePTPi4qyt1CNBGPn4roUOuGeGQ7/dABYWNGmT0nKjjeXmqs9bt5z CrxPfVS4xeEU7D64OJtD47f069jsG5E6qENdPmrjaKmTrllfM1S9HvWeco8PwBQC5ixpiXUq t3Dyq3K0GmCgs1P7dJqup+Dt6UNF+DwgSZZeBjo3l+BtAv7StrvWdUQCqJpjUttIwzmtqsx2 NUWa1oSoqvUJ6XnJUZdT/UF390/6Uo4rnTeOWao9dkKQCaE3KvtCHBNZRv1MW0Ot3KSKnE+4 iZeUZgg1KAVQ5dhjjtXmjYoZMYoN4lE4OB2ae8LRbOrj0PE7Wvbuhs5eOyei7e6lYDHPzpLn cfcLpQmOoHal11JqympoeJQENtQl2i1p2j5KmsfUQiqD1HQaGcpH9OKXEclLCOpQ/6zafNW3 nSYFBwADNpHMNiQXxcXKxiPCfiZa2UK5RRWohIz9kY8HXvX/1E2pvtOZoymiXJviR3g2BFvM 21+LIVu3dtoEWWxtD7MyDtOe1dEZTfxLUPMpQa66znWbEQ736mmv5n/z+Aaq7OidNuOIFfO2 HbE+LBHIWhKAy9Ttqa+RqpPONMkvz3kth+G4IOBaTYEPWWHLrqXe2zCCBsIwggSqoAMCAQIC EFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25l cmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4IC DwAwggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs 0zfSTm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9 ZVbXILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvS xlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eN o4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWq g5t2H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4 TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1 MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYv SBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaG K5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoG CCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25l cmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNV HSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRv cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8v Y3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMS MA0GCSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gV LtDUJQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyo EBHGvw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50Zk BqYnnl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEO rPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1Ur RIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKX e4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNO xdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaH KWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyE G/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDCCBTgwggMg oAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEy MDA1MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMM FlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQDCvusn8CGj82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1 gouuSLasANxldewqTV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/te uuSPl2e+S46NZAdXOFVpNDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv41 4e1Qe6kwjRnTCY5oZ12/PJcYU7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1s OTlzgBbIUrAjzeA+3N08R6C7NYrimGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1v gPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdf Y2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCDLrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2 WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt6 0H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKSL2LUP2lDfA3W/Fh1AYidWBZL3rqQ /0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8wPTAPBgNVHRMBAf8EBTADAQH/ MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA389ZoG5XcUkeudQXuZ KoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyywqODAQDc19oRc XOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr7cQZ5qtM ETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65XI0G SK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI 6wzWJoi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2H dqkXlrfPDZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/ xFZT+mNl0PMcDhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjU kL8Ws9nprFlhVMgcusrByuG5IEyPOpOJpaDMv9P2daR1lm1WMYIB8TCCAe0CAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMCEDeGIqZHLgK9f2Sm7MPtXjEwDQYJYIZIAWUDBAIBBQCgaTAvBgkq hkiG9w0BCQQxIgQgdznNDZ2har27Kcfuz6tugwFlPNzXnts0n+AVoiPQMrIwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMzA1MTIyNTM4WjANBgkqhkiG 9w0BAQEFAASCAQBgiNBQqJUBiFsyuqzPqAKmWBOLJenOHdS3jweFkq2a0j2XdORHfmw/a+SN 3eXmwciIf2wWZozQugaSwjt1ZoqDIHfsWNnSSgnjXlyRJxp+CL+ZEPl+c4u2nAQ6CRGO5FkY Ni25G+T9wl5xCsbRE2m6svfO/jTQlQA4QhxcQGZjQOBrsAm2xaYHhzUW/wVu/vpbSp6wD3nd AsaDJw8wH+GvIRF7fNTsWJBtpbtbzy1SERmBgt9Jpu0aHbNGsDLdaUlPYUfmvw3rYHmMfYzZ kYTsXGj9lV8oHal3RTYeM/oFkOWRj50y9OKBESurwwfu3jyUEibGPOgjpbO/ghPE+i87 --B_3603104738_73050990-- From nobody Mon Mar 5 05:05:02 2018 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 4B66D12D80E; Mon, 5 Mar 2018 05:05:00 -0800 (PST) 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.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152025510026.27788.2172912713426761706@ietfa.amsl.com> Date: Mon, 05 Mar 2018 05:05:00 -0800 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-rfc5245bis-19.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 13:05:00 -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-19.txt Pages : 100 Date : 2018-03-05 Abstract: This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. 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-19 https://datatracker.ietf.org/doc/html/draft-ietf-ice-rfc5245bis-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-rfc5245bis-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 5 05:09:54 2018 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 B5DC112D949 for ; Mon, 5 Mar 2018 05:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 jBFth1J4VrsJ for ; Mon, 5 Mar 2018 05:09:48 -0800 (PST) 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 55FBD12D778 for ; Mon, 5 Mar 2018 05:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520255386; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ylc/iBfVJ6TRmw7+kH6PjGye1EsPbhIMDi3ZBXR6j5c=; b=YgIKTTtBGzbCJl3K9IZtXs7TFpnQYif2cisxhPSnlDhsQqwNF5vaCTac+flDErz7 A3UXTziBcE938CB4yTEYZak9meicGmNxqyYLyMr88iH+eF/Lq78Nk25oIMXgxY82 1lp/RQ0MxNYKgcuMnJMeX/EAwtv+CfXgUcez/ujeqbM=; X-AuditID: c1b4fb30-799639c000004778-fc-5a9d419a9f73 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F2.23.18296.A914D9A5; Mon, 5 Mar 2018 14:09:46 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Mon, 5 Mar 2018 14:09:04 +0100 From: Christer Holmberg To: The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , "ice@ietf.org" , "adam@nostrum.com" Thread-Topic: Draft new version: draft-ietf-ice-rfc5245bis-19 Thread-Index: AQHTtIMhw2aa8ZI4rUmEeCqVBFRONA== Date: Mon, 5 Mar 2018 13:09:03 +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.16] Content-Type: multipart/alternative; boundary="_000_D6C310812C0BCchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2K7iu4sx7lRBl0bNS32/F3EbjH/5HVm i4uzJrNZfLtQazHjz0RmB1aPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugStjwtK5zAUzxSt+ bFzO1sDYI9LFyMkhIWAicfheM3sXIxeHkMBhRolHU7YyQziLGCU2HT7M1sXIwcEmYCHR/U8b JC4i8IBR4vPTpYwg3cJA8c3bnjKD2CICthJrbi1ng7D1JKZcfg1mswioSJx+coAVxOYVsJb4 Oe0NC4jNKCAm8f3UGiYQm1lAXOLWk/lMEBcJSCzZc54ZwhaVePn4H1ivKNDMDSdus0PEFSV2 nm1nhuhNkNj+4S3UfEGJkzOfsExgFJqFZOwsJGWzkJRBxA0k3p+bzwxha0ssW/gaytaX2Pjl LCOEbS0x9fZyNmQ1Cxg5VjGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIERtfBLb8NdjC+fO54 iFGAg1GJh5fHYG6UEGtiWXFl7iFGCQ5mJRFeKUmgEG9KYmVValF+fFFpTmrxIUZpDhYlcd6T nrxRQgLpiSWp2ampBalFMFkmDk6pBkadPebT/XMFH+44eePN8sDaR0sjZu14st+syMNLYHkW 28rWR+/8vRaGfzA/PrtG7eqh+rAfk2YoP1ZK76h5fFtc4o2a7ss5/5P2zG0yerGxepOAo1j8 vli3SkeGuasZ35qde5Rz6MXkhIwwvnWWEQeeng4+ae13ZLnINres6ZvCTmxrnNne8kBQiaU4 I9FQi7moOBEARUclWKoCAAA= Archived-At: Subject: [Ice] Draft new version: draft-ietf-ice-rfc5245bis-19 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, 05 Mar 2018 13:09:53 -0000 --_000_D6C310812C0BCchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I have merged all 5245bis pull requests, and submitted a new version (-19) = of draft-ietf-ice-rfc5245bis. At this point I don=92t intend to do further changes based on the IESG revi= ew, so let me know if I=92ve missed/misunderstood something. Thank You to everyone who reviewed the document! Regards, Christer --_000_D6C310812C0BCchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <54604FCF35B00044A770133925ECECE0@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I have merged all 5245bis pull requests, and submitted a new version (= -19) of draft-ietf-ice-rfc5245bis.

At this point I don=92t intend to do further changes based on the IESG= review, so let me know if I=92ve missed/misunderstood something.

Thank You to everyone who reviewed the document!

Regards,

Christer

 

 --_000_D6C310812C0BCchristerholmbergericssoncom_-- From nobody Mon Mar 5 19:37:16 2018 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 1C2C112E87F for ; Mon, 5 Mar 2018 19:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 6wKKIPJlJYlY for ; Mon, 5 Mar 2018 19:37:13 -0800 (PST) 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 4C84712E034 for ; Mon, 5 Mar 2018 19:37:13 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id r16so23029420qtm.4 for ; Mon, 05 Mar 2018 19:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZX2ipbh667yaOEdkdzSRMfRQ5+47L+et0I40rx+Xk5I=; b=WZH0pawtFdqMsW3aV1278qE/0NasRtgFkX8jGXC3d11/f4lr4UfsuDfXbe+ONMjgIe h3LAnO1Ogkc73VsMp3Jn2ZshIu2EzUKmjoVWLqIGWnKxXftkjcXv4P73ycdY4V78ugQl +FKUBIAnCsJzhz1c1WX1Bj9+LX7ZF1wb3+OwS5mrL2yyTn3Q2XO8aoU9NSe1v5A9xeHI JnkS9Dzhwl3UGnki48pkYeMAl1BA5+VjvvzkBUuTcaDhBy90Ed07OPXx1mrVWO+rzAcf l6H8nFxyt6K6CIX7cmDAmsuCeh3MvrUNGSD3U0E5o6rscL7L27cXhvwcNFD843bGLN5r EqJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZX2ipbh667yaOEdkdzSRMfRQ5+47L+et0I40rx+Xk5I=; b=nxso9bAALFo+pNGBlo0kkt9J7cxnnfKYG09mwmHkTSiWDMIkVd14lLjwBd66Tm2kxJ sL9Ea5MMgiT4VS4aXSY9gzGxm8BQwwV9w3bjKnKZZiPBhM/MjayoB9Uaku9M49eLOClQ w8Jnlq4H2w6j2Epn7+DZbE9re+lphNIVOn1Gzv1RwoladGZV5ocbKXNXKZ1pQdnHmJ0F lm1om5EdFDfS0QeUl0ov6NKgC9bGWtMekEpmeb5sy7yB7ESYr9GlIB6BVr59ofOPgt6z SBZnXTxn0Xk1L2UBbVNoC6b3Bs9E8BzTwBQNf0WUO9bk8O1CmfqiiI8bdhtFdINU6sdF SFVg== X-Gm-Message-State: AElRT7EL+vqrxzvjqqkNvztW4S31YRQ/joHnNafKlBaHkWTjBpYxxUtS mdEEjvGHGc/TFD2Ye9zwORe/cxQFsM5iuI3NWyDjzg== X-Google-Smtp-Source: AG47ELul7BAbsb90c+sV+cF2k2nu2teBmsu9a5C9g1A3NLYMqg0sIA2FqKEgtlg9a98IbvN5/LmMbhRCUKAoUeukN5c= X-Received: by 10.237.57.133 with SMTP id m5mr25904466qte.258.1520307432106; Mon, 05 Mar 2018 19:37:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.55.174 with HTTP; Mon, 5 Mar 2018 19:36:51 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> From: Emil Ivov Date: Mon, 5 Mar 2018 21:36:51 -0600 Message-ID: To: Christer Holmberg Cc: "ice@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 06 Mar 2018 03:37:15 -0000 Hey Christer, Inline: On Sun, Feb 25, 2018 at 1:41 PM, Christer Holmberg wrote: > Hi, > > While catching some breath between trying to address IESG comments on > 5245bis, I took a look at trickle-16, and I have a couple of questions. > > Q1: > > Section 7.1 says: > > =E2=80=9CThe ICE specification [rfc5245bis], Section 6.1.4.2, specifie= s that > an agent will terminate the timer for a triggered check in relation > to a check list once the agent has exhausted all frozen pairs in the > check list. This will not work with Trickle ICE, because more pairs > will be added to the check list incrementally.=E2=80=9D > > Exactly what procedure in 5245bis dos this text refer to? At the time of writing that was section 5.8 in 5245 and specifically this t= ext: * If there is no such pair: + Terminate the timer for that check list. I am not able to match that to text in 5245 bis and it probably went away last year when we were redoing the states. We'd need to resync it. Want to have a quick call offlist? (I suspect we can probably just drop this after the latest changes we did in Prague last year). > Q2: > > Section 7.2 says: > > =E2=80=9CWhen a check list is set to Failed as described above, regula= r ICE > requires the agent to update all other check lists, placing one pair > from each check list into the Waiting state and thereby effectively > placing all remaining check lists into the Running state.=E2=80=9D > > Exactly what procedure in 5245bis dos this text refer to? Exactly the parts that we discussed and agreed to change in Prague last year. I think this part is no longer necessary given how they are covered by 5245bis. Emil --=20 https://jitsi.org From nobody Mon Mar 5 20:39:58 2018 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 C9EB1127444 for ; Mon, 5 Mar 2018 20:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 9fKri-QCihFj for ; Mon, 5 Mar 2018 20:39:55 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 5CD46126C25 for ; Mon, 5 Mar 2018 20:39:55 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id u5so8286318pfh.6 for ; Mon, 05 Mar 2018 20:39:55 -0800 (PST) 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=tPLpFeYXgmoja/Qq37V9CSp8Cf0TxjwxUDvqM+IKxTE=; b=BivHE2CuHz0rUomS8m8JFHHlc3AF1iq8GsDCn9uiz/hu5NkSjA0JXtkxJz9FnXaiKc j2Hd2wjogMmvP1T97zLpQgYzk7s4+h0yXjn0xsWMPkJUWa4H5C6qdUq1/nYNYsc6vpxY Oueatsvp950v4RK/CjX0O0n6aDtoQQ3sFY7ME= 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=tPLpFeYXgmoja/Qq37V9CSp8Cf0TxjwxUDvqM+IKxTE=; b=UibaeEMkxvG/e7q3HlIgMNq3DriBAtTVel9qohzBFGaQwIsO4QQtt/Xvu9pLyyUbwe BG+pqukfWkSYy69dkdBDxgtM+HKg/l2zV0eHD3xoFO+kgzaZ4ZJAmf5jbmCFjNxkfqSS lz9ugYDUcDIRrkroGOB1B1L0/Zo/2dgWtnKFsvsL+B7OFVN3yGuoTmuFv+pKhxwwA4Xk h/DhluvBnZtFCDaodJ4Lf/HPb7rqcPsJmAIuA2b5emyfCtvjEG/iT27EfNnTrtiZj9sK LHzxkIfAAOKaIhiXC4h333UYA1L/zBtvkuMPFRfI1vN8T12p9k+STNJ190NePuH8e8Uo k4gA== X-Gm-Message-State: APf1xPBY/C3o+gDmj5VZR1Cx8bol2QgF58y2QvOCaybZd17rZSfJFFfB GntSNFbYdf3hfH28ju5JTZNBDQ== X-Google-Smtp-Source: AG47ELu50wyB0bPOMR1wO8ExLMW7DKoTpdSB853zJvzqp8POCzFwfA6ohc3kPpvz9/t/bf3CgyOfrA== X-Received: by 10.99.97.68 with SMTP id v65mr14236316pgb.104.1520311194729; Mon, 05 Mar 2018 20:39:54 -0800 (PST) Received: from ?IPv6:2601:647:4600:3f31:68e6:8ac1:fc02:c528? ([2601:647:4600:3f31:68e6:8ac1:fc02:c528]) by smtp.gmail.com with ESMTPSA id s9sm8347403pfh.64.2018.03.05.20.39.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Mar 2018 20:39:53 -0800 (PST) From: Nils Ohlmeier Message-Id: <6C328929-B686-49EF-A79E-EDDF3AA630AD@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_1CD81041-280A-4914-B986-ADD4D3121F49"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 5 Mar 2018 20:39:51 -0800 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1BC7F7@ESESSMB109.ericsson.se> Cc: Peter Saint-Andre , "ice@ietf.org" To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1BC7F7@ESESSMB109.ericsson.se> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 06 Mar 2018 04:39:57 -0000 --Apple-Mail=_1CD81041-280A-4914-B986-ADD4D3121F49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 2, 2018, at 13:42, Christer Holmberg = wrote: >=20 >> Another aspect might be continuous nomination in the future. If we = demand that the emitting agents stops trickling it might be harder >> to open it up for continuous nomination again. Where if we only tell = the receiving agent to ignore candidates which arrive after nomination >> has concluded it should be trivial for continuous nomination to = lift/change that part of the spec. >=20 > IF we decide to do continuous nomination, we can always change the = rules for that. Fair enough. The other worry I have with restricting on the emitting side is that = effectively ICE and the signaling layer are in a race, which most = scenarios the signaling layer is going to loose. That results in ICE = agent receiving trickle candidates very likely getting into the scenario = where ICE has concluded with use-candidate being set, but still = receiving candidates via the signaling layer. If you want to suggest = what to do with these late arrivals, e.g. rejecting, then we need some = text explaining this scenario any way. So for me it=E2=80=99s: - either only describe the receiving ICE agent ignores late arriving = candidates - or demanding that the emitting ICE candidate shall stop emitting AND = the receiving ICE agent also needs to ignore late arrival to be safe Best Nils Ohlmeier --Apple-Mail=_1CD81041-280A-4914-B986-ADD4D3121F49 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----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlqeG5cACgkQY2o/VmzJ +KGXvxAAnRIiPAsDTKDNf4KnKgZKOwIMA/EqCphTk/xzZ6JEN4bDv0HM41va2aL8 FTCAVLBD9xzJW/DTI2lM1pNU6p19laTVHmZGs/tJNBSCgJRb2OELqyBj3TKCxvui 8ukcuF2ymhmdMbQ4IYJAY3lcb9peyVUCum3DcPSRTWVfQSQB8ly48iF4WSnMCAU2 RLHknUnnsKTBEG/5SuaKZ89xXRW8w+JgxxWzlWoT5voOzt3hz59wALATH3RTNFeX MsNei+RLH0KHxrhnqBABYg57h5oTpRUTeI9p5oS0jOVV0GI4X3D4SlMsbDwjiNYa q9yZnm3Xdir9q5Q5zQeyD6lLPQMc9unq9rBH7Oxqp1kVyzs6ORCgdKZGEI4uWs3t 9zgvJ6E7AZCVI7Yj5yVjVKv5LJs/0gNEry/6hmYErkqU58jeeYU8lmb9j3kG6Xsy PKyiBsQBmt/I513eg9nP2Gu849YjGZj709vgv3LSw6TpUNWrVVrW04nYo8Alypbj +ld3nIq0leuldgdyV1OEvYm0pyHlM1dpZ62aR0HZZQsdfrnfblgvRFREkV6eeMre 5kTV6+p+fAttRm30YVSrANkFI2iolvtocGNWP1TddipPx41265lWg5Bsy2vui54p BKQtu3wJZ0I2n3uqK05nTuFjq1YtIs2vN9MluFRCMtm5udl71us= =h3TS -----END PGP SIGNATURE----- --Apple-Mail=_1CD81041-280A-4914-B986-ADD4D3121F49-- From nobody Mon Mar 5 23:47:40 2018 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 7B32D126C89 for ; Mon, 5 Mar 2018 23:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 PRxWRaolG6TN for ; Mon, 5 Mar 2018 23:47:38 -0800 (PST) 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 DCA5F120724 for ; Mon, 5 Mar 2018 23:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520322456; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pLD6MgmAlTo6v/nx9k4q9vc7XZ1ZyM31jPGo975arMw=; b=UdNygqk+fVqXEDAZXBNfMnor5O14tBmUohjR4OULEkCTQDaCpu/u09jookopU4/C SLT/nyjlhBaCoST9J0d90iVt9i5ML+VuuQpogccAlz8hr8E0rfQ018RY8ig+iAxE ZAjW1mcySzuT+1jJQ8YlJiTizw+zMYaxcO2DtNS8Exo=; X-AuditID: c1b4fb25-44ba69c000002d5f-ef-5a9e47977d8b Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C1.0B.11615.7974E9A5; Tue, 6 Mar 2018 08:47:35 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Tue, 6 Mar 2018 08:47:35 +0100 From: Christer Holmberg To: Nils Ohlmeier CC: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] Trickle: A couple of questions on section 7 Thread-Index: AdOucJgg+M5x/JnqQAe0nEYDsAIfMAA5PBQAABTM7oAAEyrzgAACkKBQAJLFpgAABlMCgAACaSigAKPFqYAACzR5gA== Date: Tue, 6 Mar 2018 07:47:35 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1BC7F7@ESESSMB109.ericsson.se> <6C328929-B686-49EF-A79E-EDDF3AA630AD@mozilla.com> In-Reply-To: <6C328929-B686-49EF-A79E-EDDF3AA630AD@mozilla.com> 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.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM2K7pe5093lRBg9eWFt8u1BrcX3eZEaL ZytPMToweyxZ8pPJo+9AF2sAUxSXTUpqTmZZapG+XQJXRufWrSwFTbwVbbcPsTYwHufqYuTk kBAwkei8/oEFxBYSOMwo8fuseRcjF5C9iFHi+ZTzTF2MHBxsAhYS3f+0QUwRAU2JExv5QMqZ Bbwk9m5ZyARiCwvYScw69QdsjIiAvcS23mtQdpbExuk32EFsFgEViUPLmsDqeQWsJX5cusMG sWoCi0TP4klgqziBmh/+rQKpYRQQk/h+ag0TxC5xiVtP5jNBnCwgsWTPeWYIW1Ti5eN/rCC2 qICexIYTt9kh4koSPzZcYoHo1ZO4MXUKG4RtLTGj+xkzhK0tsWzha2aIewQlTs58wjKBUXwW knWzkLTPQtI+C0n7LCTtCxhZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExtzBLb9VdzBe fuN4iFGAg1GJh1fLcF6UEGtiWXFl7iFGCQ5mJRHeCH2gEG9KYmVValF+fFFpTmrxIUZpDhYl cd45wu1RQgLpiSWp2ampBalFMFkmDk6pBsaiLUorZJLku4/8WP5od7zxYbfwlna5pBsLL158 k+vVsyAxVE1ebfLrHWcmVW37djut7dCdDymuH5ZmyP3UqfRM8/WM6jbtUfNOyQs081JpCYr1 XOmeFua7e//XKfF1wc8T915kVyuQT7biN1t9O7Z1v9QvTS3BW3t/7/BSjDnP//3ZFofKACWW 4oxEQy3mouJEAI1JZna1AgAA Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 06 Mar 2018 07:47:39 -0000 Hi, >>>Another aspect might be continuous nomination in the future. If we >>>demand that the emitting agents stops trickling it might be harder >>> to open it up for continuous nomination again. Where if we only tell >>>the receiving agent to ignore candidates which arrive after nomination >>> has concluded it should be trivial for continuous nomination to >>>lift/change that part of the spec. >>=20 >> IF we decide to do continuous nomination, we can always change the >>rules for that. > >Fair enough. > >The other worry I have with restricting on the emitting side is that >effectively ICE and the signaling layer are in a race, which most >scenarios the signaling layer is going to loose. That results in ICE >agent receiving trickle candidates very likely getting into the scenario >where ICE has concluded with use-candidate being set, but still receiving >candidates via the signaling layer. If you want to suggest what to do >with these late arrivals, e.g. rejecting, then we need some text >explaining this scenario any way. > >So for me it=B9s: >- either only describe the receiving ICE agent ignores late arriving >candidates >- or demanding that the emitting ICE candidate shall stop emitting AND >the receiving ICE agent also needs to ignore late arrival to be safe Not sure what you mean by =B3ignore=B2, but I think the message carrying th= e trickled candidates should be explicitly rejected, so that the emitting agent knows what is going on. Then, in future, if continuous nomination is supported, instead of rejecting the message carrying the candidates it is simply accepted :) Regards, Christer From nobody Tue Mar 6 00:00:44 2018 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 4A90D120724 for ; Tue, 6 Mar 2018 00:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 m2_c1xX7_1SA for ; Tue, 6 Mar 2018 00:00:36 -0800 (PST) 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 798C8124239 for ; Tue, 6 Mar 2018 00:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520323234; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zpeQZHL6NeVqqNTGIF/B7XK0BMDossSC4ofMps+5Of8=; b=O4+6BjDydSAeu+6AfjXOFEba+fmyU5X8D9sZjGuwsv+a9z1+LmUXvKkXf86G9rJU FJdvsaRmGTREnkxkga4r3r7EaNxLmMOJB+3oHiL5dxGJ/oD16FhQsh+bxTTtIZ9w Lg/fimlNdxs/xYiyJV5b9xsTxfVBcynhjc6R+jINieg=; X-AuditID: c1b4fb30-799639c000004778-c6-5a9e4aa23c58 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C5.42.18296.2AA4E9A5; Tue, 6 Mar 2018 09:00:34 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0352.000; Tue, 6 Mar 2018 09:00:19 +0100 From: Christer Holmberg To: Emil Ivov CC: "ice@ietf.org" Thread-Topic: [Ice] Trickle: A couple of questions on section 7 Thread-Index: AdOucJgg+M5x/JnqQAe0nEYDsAIfMAGg2MuAAA3ZuwA= Date: Tue, 6 Mar 2018 08:00:19 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C19E021@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.7.170905 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7t+4ir3lRBpsWmlis2TmBxeLbhVoH Jo8lS34yefx/ExjAFMVlk5Kak1mWWqRvl8CVcfavacFUsYoLO6awNDBOE+xi5OSQEDCRWHSp n7WLkYtDSOAwo8S757+ZIJxFjBLLllxi62Lk4GATsJDo/qcN0iAiIC/R3baICSTMLKAo8XKv GkhYWMBOYtapPywQJfYS23qvQdlWEhfn7WUFsVkEVCT+L+lnBLF5BawlrrRugVo1hVHi8N83 TCAJToFAic2zFoM1MwqISXw/tQYsziwgLnHryXwmiKMFJJbsOc8MYYtKvHz8D2yBqICexIYT t9lBbpMQUJKYtjUNolVP4sbUKWwQtrXE6UfvmCFsbYllC18zQ9wjKHFy5hOWCYzis5Bsm4Wk fRaS9llI2mchaV/AyLqKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzDODm75bbCD8eVzx0OM AhyMSjy8czznRQmxJpYVV+YeYpTgYFYS4Y3QBwrxpiRWVqUW5ccXleakFh9ilOZgURLnPenJ GyUkkJ5YkpqdmlqQWgSTZeLglGpgdD1h+0XldWwp45EDMzZJ+qeqnX297mhf7LI3l+zeLv75 hSvm+qqCRcrFVzdEGHzSLbwhEF6rcfR0TzO3r+n5T8X1lu8W/Dc9fVZI5ppb8rxtV7piv9bn yX7e92lz1Rmv8zFSR14vSl17Pt7PbO7sNR37/LavuFmw9/vLpiqTG9snnuTVPMj3doUSS3FG oqEWc1FxIgAcFJ5/rwIAAA== Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 06 Mar 2018 08:00:43 -0000 Hi Emil, We can for sure have a call, but I think this requires a bigger audience than you and me :) I assume that the authors should participate, and also individuals like Nils O, Taylor B, Peter S-A etc. As far as I understand, trickle has 3 major considerations compared to legacy ICE: 1) The order in which candidates are trickled. As we have discussed lately, it needs to be clarified. 2) How trickle impacts the check list state. In fact, I am not sure it impacts at all, because 5245bis nowadays says that a Failed checklist can become Running again if the state of a pair within the check list changes (with legacy ICE this can happen by the triggered check). 3) Once the nomination has taken place, we need to describe what happens with trickled candidates that may still arrive. That would be 3 sections in the trickle spec :) Are you going to be in London, btw? Regards, Christer On 06/03/18 05:36, "Emil Ivov" wrote: >Hey Christer, > >Inline: > >On Sun, Feb 25, 2018 at 1:41 PM, Christer Holmberg > wrote: >> Hi, >> >> While catching some breath between trying to address IESG comments on >> 5245bis, I took a look at trickle-16, and I have a couple of questions. >> >> Q1: >> >> Section 7.1 says: >> >> =B3The ICE specification [rfc5245bis], Section 6.1.4.2, specifies tha= t >> an agent will terminate the timer for a triggered check in relation >> to a check list once the agent has exhausted all frozen pairs in the >> check list. This will not work with Trickle ICE, because more pairs >> will be added to the check list incrementally.=B2 >> >> Exactly what procedure in 5245bis dos this text refer to? > >At the time of writing that was section 5.8 in 5245 and specifically this >text: > > * If there is no such pair: > + Terminate the timer for that check list. > >I am not able to match that to text in 5245 bis and it probably went >away last year when we were redoing the states. We'd need to resync >it. Want to have a quick call offlist? (I suspect we can probably just >drop this after the latest changes we did in Prague last year). > >> Q2: >> >> Section 7.2 says: >> >> =B3When a check list is set to Failed as described above, regular ICE >> requires the agent to update all other check lists, placing one pair >> from each check list into the Waiting state and thereby effectively >> placing all remaining check lists into the Running state.=B2 >> >> Exactly what procedure in 5245bis dos this text refer to? > >Exactly the parts that we discussed and agreed to change in Prague >last year. I think this part is no longer necessary given how they are >covered by 5245bis. > >Emil > > > > >--=20 >https://jitsi.org From nobody Tue Mar 6 04:24:06 2018 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 0C9871276AF for ; Tue, 6 Mar 2018 04:24:05 -0800 (PST) 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, 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=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 g07Zs7FuXDfX for ; Tue, 6 Mar 2018 04:24:02 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 0DF691270A3 for ; Tue, 6 Mar 2018 04:24:02 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id y6so24260907qtm.7 for ; Tue, 06 Mar 2018 04:24:02 -0800 (PST) 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 :cc; bh=IHYLqZuxZE982oxYmbuYW5XnWrh+4WRTrr6PrxKNEls=; b=SHMOmYTdyq2u1/DpbXze//0WokwAB3odmaw7RIAuHgZs3GCoGhvGyCzb4haN9BMBb4 oZ36fp+ucOhyAtV1XandXAIy3LRNKuEda20uhk9fX7Jh5Mketw44ig+Cudjpx03vm71b 9iCI2S3Wm/nbQDM/z8N3qXQV5ZpMkiM3SSo5LifD7d/1167IyFzwUG5ykLGY6TetD8FM GcTu/AA00BBcCC/UCT+bbAsLn0A8UqHGTEZ3t354AOz/Ag3Pntmc6lPlu6TAnZz+9fES XGuY5voTUccOIrdIp9pvu/TS+ybu3Zpvm0s3+QFiFjw6qRhpz8Y0+wS1TOTr0E1tbvWv 2tVg== 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=IHYLqZuxZE982oxYmbuYW5XnWrh+4WRTrr6PrxKNEls=; b=KAeQj7+g+z4lHAWecmGvBzQ5MunjKq7QQEzs3zT+xQ/sbZQLXkMipjrtuHWZZRsb2H fkOznH7Np+I2+mStLoGjdROORh89TC1esb+2SgJhY1Of+fJdrKWxJEH00TgFaMd995Yg t96+x7MFncqXoB15klrtVWTydfy7IUb3WU9aCQH+zITKUWB4KKBAT6iJJbVZzuxwAjLM qWsDNoswbfzJrh61JRn59LVfZQ26qlHvDubcvzOuIPklCjDB9V5oX9aFBOezlnNZZghC j/gLezN+Oci97fs781I6qdKWOIqes34Sj4Q2c9AIxd/6MruUN6nOvG6Pktw54Sx99VEQ 8pxA== X-Gm-Message-State: AElRT7GqzsM41PnSNAKt4rddQ8N5x9d1/Lz0g7LfQS8e2SEnujZfnwoi 04xEe/n0rc7cQBvVMDiw1ug0cUEJvf8hWcJThVJprw== X-Google-Smtp-Source: AG47ELvJwOs3CcIDYta2+MhgxQQymKUojBvyo32nPqMti9pMy6nBhEMjGRTEmjAVrJ0NMKUmnTyrUYVsrSuWDRJmoPM= X-Received: by 10.200.41.18 with SMTP id y18mr29236725qty.181.1520339041001; Tue, 06 Mar 2018 04:24:01 -0800 (PST) MIME-Version: 1.0 References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> In-Reply-To: From: Emil Ivov Date: Tue, 06 Mar 2018 12:23:47 +0000 Message-ID: To: Christer Holmberg Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a113f40207a640e0566bd8419" Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 06 Mar 2018 12:24:05 -0000 --001a113f40207a640e0566bd8419 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Christer, On Tue 6 Mar 2018 at 02:00, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Emil, > > We can for sure have a call, but I think this requires a bigger audience > than you and me :) > > I assume that the authors should participate, and also individuals like > Nils O, Taylor B, Peter S-A etc. As much as I=E2=80=99d be trilled to have any number of chats in such lovel= y company, I just wanted your help on finding the right sections in bis so that we would simply update the coherence of the document. Let=E2=80=99s see then if further discussion is necessary after that. > > > As far as I understand, trickle has 3 major considerations compared to > legacy ICE: > > 1) The order in which candidates are trickled. As we have discussed > lately, it needs to be clarified. > 2) How trickle impacts the check list state. In fact, I am not sure it > impacts at all, because 5245bis nowadays says that a Failed checklist can > become Running again if the state of a pair within the check list changes > (with legacy ICE this can happen by the triggered check). > 3) Once the nomination has taken place, we need to describe what happens > with trickled candidates that may still arrive. > > That would be 3 sections in the trickle spec :) > > Are you going to be in London, btw? Nope. Justhad a humans++ event at home so IETF (even in London) loses the prioritization contest there ;) I=E2=80=99d likely be able to do remot though. Emil > > > Regards, > > Christer > > > > On 06/03/18 05:36, "Emil Ivov" wrote: > > >Hey Christer, > > > >Inline: > > > >On Sun, Feb 25, 2018 at 1:41 PM, Christer Holmberg > > wrote: > >> Hi, > >> > >> While catching some breath between trying to address IESG comments on > >> 5245bis, I took a look at trickle-16, and I have a couple of questions= . > >> > >> Q1: > >> > >> Section 7.1 says: > >> > >> =C2=B3The ICE specification [rfc5245bis], Section 6.1.4.2, specifie= s that > >> an agent will terminate the timer for a triggered check in relation > >> to a check list once the agent has exhausted all frozen pairs in th= e > >> check list. This will not work with Trickle ICE, because more pair= s > >> will be added to the check list incrementally.=C2=B2 > >> > >> Exactly what procedure in 5245bis dos this text refer to? > > > >At the time of writing that was section 5.8 in 5245 and specifically thi= s > >text: > > > > * If there is no such pair: > > + Terminate the timer for that check list. > > > >I am not able to match that to text in 5245 bis and it probably went > >away last year when we were redoing the states. We'd need to resync > >it. Want to have a quick call offlist? (I suspect we can probably just > >drop this after the latest changes we did in Prague last year). > > > >> Q2: > >> > >> Section 7.2 says: > >> > >> =C2=B3When a check list is set to Failed as described above, regula= r ICE > >> requires the agent to update all other check lists, placing one pai= r > >> from each check list into the Waiting state and thereby effectively > >> placing all remaining check lists into the Running state.=C2=B2 > >> > >> Exactly what procedure in 5245bis dos this text refer to? > > > >Exactly the parts that we discussed and agreed to change in Prague > >last year. I think this part is no longer necessary given how they are > >covered by 5245bis. > > > >Emil > > > > > > > > > >-- > >https://jitsi.org > > -- =E2=80=94sent from my mobile --001a113f40207a640e0566bd8419 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Christer,


=
On Tue 6= Mar 2018 at 02:00, Christer Holmberg <christer.holmberg@ericsson.com> w= rote:
Hi Emil,

We can for sure have a call, but I think this requires a bigger audience than you and me :)

I assume that the authors should participate, and also individuals like
Nils O, Taylor B, Peter S-A etc.

As m= uch as I=E2=80=99d be trilled to have any number of chats in such lovely co= mpany, I just wanted your help on finding the right sections in bis so that= we would simply update the coherence of the document.

Let=E2=80=99s see then if further discussion= is necessary after that.


As far as I understand, trickle has 3 major considerations compared to
legacy ICE:

1) The order in which candidates are trickled. As we have discussed
lately, it needs to be clarified.
2) How trickle impacts the check list state. In fact, I am not sure it
impacts at all, because 5245bis nowadays says that a Failed checklist can become Running again if the state of a pair within the check list changes (with legacy ICE this can happen by the triggered check).
3) Once the nomination has taken place, we need to describe what happens with trickled candidates that may still arrive.

That would be 3 sections in the trickle spec :)

Are you going to be in London, btw?

N= ope. Justhad a humans++ event at home so IETF (even in London) loses the pr= ioritization contest there ;)

I=E2=80=99d likely be able to do remot though.

Emil




Regards,

Christer



On 06/03/18 05:36, "Emil Ivov" <emcho@jitsi.org> wrote:

>Hey Christer,
>
>Inline:
>
>On Sun, Feb 25, 2018 at 1:41 PM, Christer Holmberg
><christer.holmberg@ericsson.com> wrote:
>> Hi,
>>
>> While catching some breath between trying to address IESG comments= on
>> 5245bis, I took a look at trickle-16, and I have a couple of quest= ions.
>>
>> Q1:
>>
>> Section 7.1 says:
>>
>>=C2=A0 =C2=A0 =C2=B3The ICE specification [rfc5245bis], Section 6.1= .4.2, specifies that
>>=C2=A0 =C2=A0 an agent will terminate the timer for a triggered che= ck in relation
>>=C2=A0 =C2=A0 to a check list once the agent has exhausted all froz= en pairs in the
>>=C2=A0 =C2=A0 check list.=C2=A0 This will not work with Trickle ICE= , because more pairs
>>=C2=A0 =C2=A0 will be added to the check list incrementally.=C2=B2<= br> >>
>> Exactly what procedure in 5245bis dos this text refer to?
>
>At the time of writing that was section 5.8 in 5245 and specifically th= is
>text:
>
> *=C2=A0 If there is no such pair:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 Terminate the timer for that = check list.
>
>I am not able to match that to text in 5245 bis and it probably went >away last year when we were redoing the states. We'd need to resync=
>it. Want to have a quick call offlist? (I suspect we can probably just<= br> >drop this after the latest changes we did in Prague last year).
>
>> Q2:
>>
>> Section 7.2 says:
>>
>>=C2=A0 =C2=A0 =C2=B3When a check list is set to Failed as described= above, regular ICE
>>=C2=A0 =C2=A0 requires the agent to update all other check lists, p= lacing one pair
>>=C2=A0 =C2=A0 from each check list into the Waiting state and there= by effectively
>>=C2=A0 =C2=A0 placing all remaining check lists into the Running st= ate.=C2=B2
>>
>> Exactly what procedure in 5245bis dos this text refer to?
>
>Exactly the parts that we discussed and agreed to change in Prague
>last year. I think this part is no longer necessary given how they are<= br> >covered by 5245bis.
>
>Emil
>
>
>
>
>--
>http= s://jitsi.org

--
=E2=80=94sent from my mobile
--001a113f40207a640e0566bd8419-- From nobody Tue Mar 6 05:06:28 2018 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 4DEA612778D for ; Tue, 6 Mar 2018 05:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 Mypqnpow_EQv for ; Tue, 6 Mar 2018 05:06:26 -0800 (PST) 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 C3FD7127522 for ; Tue, 6 Mar 2018 05:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520341584; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=k1gKpcD+vJBChItQIfkBC90Hpedcj+NCPYIPJunqKzI=; b=FpcH360LaygXKAPe8K1cVOrR+gFAGCuUjLq+zprl8WXEg0DQYf2+F68jcHFQBK4y ttBcBrQvHWbPd2nyunU++2nNGjVK1RxVYLESDhRw8TNVY3C4JmZmzN9vUirKcA/3 5uzt9k6gqm3GBl7fB+S9fs1v7+IH57Nz73vzcrXtAek=; X-AuditID: c1b4fb25-44ba69c000002d5f-d1-5a9e924ffa2d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 50.A8.11615.F429E9A5; Tue, 6 Mar 2018 14:06:24 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Tue, 6 Mar 2018 14:06:22 +0100 From: Christer Holmberg To: Emil Ivov CC: "ice@ietf.org" Thread-Topic: [Ice] Trickle: A couple of questions on section 7 Thread-Index: AdOucJgg+M5x/JnqQAe0nEYDsAIfMAGg2MuAAA3ZuwAABI1rgAAGIuKA Date: Tue, 6 Mar 2018 13:06:22 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C19E021@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.7.170905 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="euc-kr" Content-ID: <6147E75A488C6D469581306ECF0B1B5F@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7qG7ApHlRBlufc1is2TmBxeLbhVoH Jo8lS34yefx/ExjAFMVlk5Kak1mWWqRvl8CVMbl3K2vBHvmKRdM/MTUwXpHrYuTkkBAwkZh7 6SJrFyMXh5DAYUaJCV8+M0I4ixgl9v1Zx9zFyMHBJmAh0f1PG6RBREBeorttERNImFlAUeLl XjWQsLCAncSsU39YIErsJbb1XoOy3ST+HrnDBGKzCKhITH++GczmFbCWOL7hEDvEql4miXlX LzKCJDgFAiWePLkHZjMKiEl8P7UGrIFZQFzi1pP5TBBHC0gs2XOeGcIWlXj5+B8riC0qoCex 4cRtdoi4osTOs+3MEL1aEl9+7GODsK0l9q88zwJhK0pM6X7IDnGQoMTJmU9YJjCKz0KybhaS 9llI2mchaZ+FpH0BI+sqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMBYO7jlt+oOxstvHA8x CnAwKvHwZk6cFyXEmlhWXJl7iFGCg1lJhDdCHyjEm5JYWZValB9fVJqTWnyIUZqDRUmcd45w e5SQQHpiSWp2ampBahFMlomDU6qBUV2c/7VwSKKvvfeWNOmkfFOed+6fvxyY8fT9DePgFYrq Jrt2HpA5bafG4cC1S+eTTM+Tpi29tyL6tljc/8BmFMCq8phvwjaG9HtHGnmlp/xO33Sll8U5 Y968/3Z2t+w+LrZiP39QQ2wCt3zuk2gvxVbJBZoZDPecX39R4//8+lR4QfW1tB3zlViKMxIN tZiLihMBOY2SurECAAA= Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 06 Mar 2018 13:06:27 -0000 SGksDQoNCkNvbmdyYXR1bGF0aW9ucyB0byB0aGUgYWRkZWQgaHVtYW4hOikNCg0KPj5XZSBjYW4g Zm9yIHN1cmUgaGF2ZSBhIGNhbGwsIGJ1dCBJIHRoaW5rIHRoaXMgcmVxdWlyZXMgYSBiaWdnZXIg YXVkaWVuY2UNCj4+dGhhbiB5b3UgYW5kIG1lIDopDQo+Pg0KPj5JIGFzc3VtZSB0aGF0IHRoZSBh dXRob3JzIHNob3VsZCBwYXJ0aWNpcGF0ZSwgYW5kIGFsc28gaW5kaXZpZHVhbHMgbGlrZQ0KPj5O aWxzIE8sIFRheWxvciBCLCBQZXRlciBTLUEgZXRjLg0KPg0KPkFzIG11Y2ggYXMgSaGvZCBiZSB0 cmlsbGVkIHRvIGhhdmUgYW55IG51bWJlciBvZiBjaGF0cyBpbiBzdWNoIGxvdmVseQ0KPmNvbXBh bnksIEkganVzdCB3YW50ZWQNCj55b3VyIGhlbHAgb24gZmluZGluZyB0aGUgcmlnaHQgc2VjdGlv bnMgaW4gYmlzIHNvIHRoYXQgd2Ugd291bGQgc2ltcGx5DQo+dXBkYXRlIHRoZSBjb2hlcmVuY2Ug b2YgdGhlIGRvY3VtZW50Lg0KPg0KPkxldKGvcyBzZWUgdGhlbiBpZiBmdXJ0aGVyIGRpc2N1c3Np b24gaXMgbmVjZXNzYXJ5IGFmdGVyIHRoYXQuDQoNCkJhc2VkIG9uIHlvdXIgaW5wdXQgaW4gdGhl IHByZXZpb3VzIHJlcGx5LCBJIHRoaW5rIEkgdW5kZXJzdGFuZCB3aGVyZSBRMQ0KY29tZXMgZnJv bS4gSSBzdGlsbCBoYXZlIGFuIGlzc3VlIHdpdGggUTIsIHRob3VnaC4gU2VlIGJlbG93Lg0KDQo+ PiBRMToNCj4+DQo+PiBTZWN0aW9uIDcuMSBzYXlzOg0KPj4NCj4+ICAgIKn4VGhlIElDRSBzcGVj aWZpY2F0aW9uIFtyZmM1MjQ1YmlzXSwgU2VjdGlvbiA2LjEuNC4yLCBzcGVjaWZpZXMgdGhhdA0K Pj4gICAgYW4gYWdlbnQgd2lsbCB0ZXJtaW5hdGUgdGhlIHRpbWVyIGZvciBhIHRyaWdnZXJlZCBj aGVjayBpbiByZWxhdGlvbg0KPj4gICAgdG8gYSBjaGVjayBsaXN0IG9uY2UgdGhlIGFnZW50IGhh cyBleGhhdXN0ZWQgYWxsIGZyb3plbiBwYWlycyBpbiB0aGUNCj4+ICAgIGNoZWNrIGxpc3QuICBU aGlzIHdpbGwgbm90IHdvcmsgd2l0aCBUcmlja2xlIElDRSwgYmVjYXVzZSBtb3JlIHBhaXJzDQo+ PiAgICB3aWxsIGJlIGFkZGVkIHRvIHRoZSBjaGVjayBsaXN0IGluY3JlbWVudGFsbHkuqfcNCj4+ DQo+PiBFeGFjdGx5IHdoYXQgcHJvY2VkdXJlIGluIDUyNDViaXMgZG9zIHRoaXMgdGV4dCByZWZl ciB0bz8NCj4NCj5BdCB0aGUgdGltZSBvZiB3cml0aW5nIHRoYXQgd2FzIHNlY3Rpb24gNS44IGlu IDUyNDUgYW5kIHNwZWNpZmljYWxseSB0aGlzDQo+dGV4dDoNCj4NCj4gKiAgSWYgdGhlcmUgaXMg bm8gc3VjaCBwYWlyOg0KPiAgICAgICAgICsgIFRlcm1pbmF0ZSB0aGUgdGltZXIgZm9yIHRoYXQg Y2hlY2sgbGlzdC4NCj4NCj5JIGFtIG5vdCBhYmxlIHRvIG1hdGNoIHRoYXQgdG8gdGV4dCBpbiA1 MjQ1IGJpcyBhbmQgaXQgcHJvYmFibHkgd2VudA0KPmF3YXkgbGFzdCB5ZWFyIHdoZW4gd2Ugd2Vy ZSByZWRvaW5nIHRoZSBzdGF0ZXMuIFdlJ2QgbmVlZCB0byByZXN5bmMNCj5pdC4gV2FudCB0byBo YXZlIGEgcXVpY2sgY2FsbCBvZmZsaXN0PyAoSSBzdXNwZWN0IHdlIGNhbiBwcm9iYWJseSBqdXN0 DQo+ZHJvcCB0aGlzIGFmdGVyIHRoZSBsYXRlc3QgY2hhbmdlcyB3ZSBkaWQgaW4gUHJhZ3VlIGxh c3QgeWVhcikuDQoNCk9rLCBJIHRoaW5rIEkgZ2V0IGl0IG5vdy4NCg0KSW4gUkZDIDUyNDUgKGFu ZCBlYXJsaWVyIHZlcnNpb25zIG9mIDUyNDViaXMpIHdlIGhhZCBhICpzZXBhcmF0ZSogdGltZXIg VGENCmZvciBlYWNoIGNoZWNrIGxpc3QuIFNvLCBvbmNlIHRoZXJlIHdlcmUgbm8gbW9yZSBjaGVj a3MgdG8gYmUgZG9uZSBmb3IgYQ0KY2hlY2sgbGlzdCwgdGhlIHRpbWVyIGZvciBhIGdpdmVuIGNo ZWNrIGxpc3Qgd2FzIHRlcm1pbmF0ZWQuDQoNCkluIDUyNDViaXMsIGhvd2V2ZXIsIHdlIG9ubHkg dXNlIGEgKnNpbmdsZSogdGltZXIgVGEgZm9yIHRoZSB3aG9sZSBjaGVjaw0KbGlzdCBzZXQsIGFu ZCB3aGVuZXZlciBUYSBmaXJlcyB3ZSBjaGVjayB0aGUgbmV4dCBSdW5uaW5nIGNoZWNrIGxpc3Qg aW4NCnRoZSBjaGVjayBsaXN0IHNldC4gU28sIG5vbi1SdW5uaW5nIGNoZWNrIGxpc3RzIHdpbGwg YXV0b21hdGljYWxseSBiZQ0Kc2tpcHBlZC4gVGhpcyBpcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA2 LjEuNC4yLg0KDQpTbywgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHlvdSBuZWVkIHRvIHNheSBhbnl0 aGluZyBpbiB0cmlja2xlLCBiZWNhdXNlDQp3aGV0aGVyIGEgY2hlY2sgbGlzdCBpcyBjaGVja2Vk IG9yIG5vdCBpcyB0YWtlbiBjYXJlIG9mIGJ5IHRoZSA1MjQ1YmlzDQpwcm9jZWR1cmVzLg0KDQoN Cj4+IFEyOg0KPj4NCj4+IFNlY3Rpb24gNy4yIHNheXM6DQo+Pg0KPj4gICAgqfhXaGVuIGEgY2hl Y2sgbGlzdCBpcyBzZXQgdG8gRmFpbGVkIGFzIGRlc2NyaWJlZCBhYm92ZSwgcmVndWxhciBJQ0UN Cj4+ICAgIHJlcXVpcmVzIHRoZSBhZ2VudCB0byB1cGRhdGUgYWxsIG90aGVyIGNoZWNrIGxpc3Rz LCBwbGFjaW5nIG9uZSBwYWlyDQo+PiAgICBmcm9tIGVhY2ggY2hlY2sgbGlzdCBpbnRvIHRoZSBX YWl0aW5nIHN0YXRlIGFuZCB0aGVyZWJ5IGVmZmVjdGl2ZWx5DQo+PiAgICBwbGFjaW5nIGFsbCBy ZW1haW5pbmcgY2hlY2sgbGlzdHMgaW50byB0aGUgUnVubmluZyBzdGF0ZS6p9w0KPj4NCj4+IEV4 YWN0bHkgd2hhdCBwcm9jZWR1cmUgaW4gNTI0NWJpcyBkb3MgdGhpcyB0ZXh0IHJlZmVyIHRvPw0K Pg0KPkV4YWN0bHkgdGhlIHBhcnRzIHRoYXQgd2UgZGlzY3Vzc2VkIGFuZCBhZ3JlZWQgdG8gY2hh bmdlIGluIFByYWd1ZQ0KPmxhc3QgeWVhci4gSSB0aGluayB0aGlzIHBhcnQgaXMgbm8gbG9uZ2Vy IG5lY2Vzc2FyeSBnaXZlbiBob3cgdGhleSBhcmUNCj5jb3ZlcmVkIGJ5IDUyNDViaXMuDQoNCkJ1 dCwgYXJlIHlvdSBzYXlpbmcgdGhhdCB0aGUgdGV4dCBhYm92ZSBpcyBhY2NvcmRpbmcgdG8gNTI0 NWJpcz8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQo= From nobody Tue Mar 6 09:49:40 2018 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 CA7861270AC for ; Tue, 6 Mar 2018 09:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 6dMyAtHQ0Hzj for ; Tue, 6 Mar 2018 09:49:36 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2480D120726 for ; Tue, 6 Mar 2018 09:49:36 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id r26so8547040pgv.13 for ; Tue, 06 Mar 2018 09:49:36 -0800 (PST) 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=BytS2zqKVB/wrJkAD8f03tngoeIcJsMAaTl5BVdOsC4=; b=NPtZ1ZaePkjLO3/a915TCUjiCx9s4MlwAiAlbOVOEbOp6jh7CEl12WdZERUP0KRM7y W7X5faKdNEvGuTrtTiZxD2IcHYuee7wr7+j3GSSazITyrptFmtsEYEqhtk2Puj2GsGqx ei8VBZG241NbWebWQ/uBfMSnViUbjGrvB2qK4= 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=BytS2zqKVB/wrJkAD8f03tngoeIcJsMAaTl5BVdOsC4=; b=R8skbm3Fim08Qth3tiOZTS4VfR0nwSWxa76DVu2YPbrJWRlwXoFlEsSErIEPtnw+xM +iB/wlfSOUtzP2qXFHERHlTlvYN6MqsdYeRY+EieBDqkklLwOAxVaMCJGP9s3/RjE3WO aYnOqlwsZ2VUkMOH9dmSxy2C8TgCuwdRaMBOzmVLdKOK3MC8sq/1ANHT0GmGZyXAUpr+ hWAZvsdq1D1A6y0nIhpysCxANRc+hf/VcZdBYleWFZ5x4KlF1jRyBTLOhaogNdgrsSvJ lHhtgJ3bp/ibBGmwYhfd+drRaLPvTkyuVLzeDXF0yUlwgFtPULjr8pRRZGH/x5mDeuhv gB+w== X-Gm-Message-State: APf1xPAsicGhdMWbeQMZs7oljtWVcYt41dHUfHRvucwVgDEyDnDI01df i2U9qrrQJY6xi/wg0j/HpOIvmA== X-Google-Smtp-Source: AG47ELtFpsqBLy4NqdRns3hctgUA0aEMmaufv0PCZVCXXrEcpifmx5ncfZVVLhnUQ9WWPALl20PX8A== X-Received: by 10.99.106.71 with SMTP id f68mr15832821pgc.262.1520358575457; Tue, 06 Mar 2018 09:49:35 -0800 (PST) Received: from ?IPv6:2601:647:4600:3f31:94cd:8b24:6e4a:e410? ([2601:647:4600:3f31:94cd:8b24:6e4a:e410]) by smtp.gmail.com with ESMTPSA id q65sm35897247pfd.140.2018.03.06.09.49.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Mar 2018 09:49:33 -0800 (PST) From: Nils Ohlmeier Message-Id: <96978131-7BF8-48A6-A1FA-8C8CF360A05A@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_FA696288-2D7F-4B39-81C1-7A7568858CC3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 6 Mar 2018 09:49:31 -0800 In-Reply-To: Cc: Peter Saint-Andre , "ice@ietf.org" To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1BC7F7@ESESSMB109.ericsson.se> <6C328929-B686-49EF-A79E-EDDF3AA630AD@mozilla.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 06 Mar 2018 17:49:38 -0000 --Apple-Mail=_FA696288-2D7F-4B39-81C1-7A7568858CC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 5, 2018, at 23:47, Christer Holmberg = wrote: >=20 >> Fair enough. >>=20 >> The other worry I have with restricting on the emitting side is that >> effectively ICE and the signaling layer are in a race, which most >> scenarios the signaling layer is going to loose. That results in ICE >> agent receiving trickle candidates very likely getting into the = scenario >> where ICE has concluded with use-candidate being set, but still = receiving >> candidates via the signaling layer. If you want to suggest what to do >> with these late arrivals, e.g. rejecting, then we need some text >> explaining this scenario any way. >>=20 >> So for me it=C2=B9s: >> - either only describe the receiving ICE agent ignores late arriving >> candidates >> - or demanding that the emitting ICE candidate shall stop emitting = AND >> the receiving ICE agent also needs to ignore late arrival to be safe >=20 > Not sure what you mean by =C2=B3ignore=C2=B2, but I think the message = carrying the > trickled candidates should be explicitly rejected, so that the = emitting > agent knows what is going on. With =E2=80=9Cignore=E2=80=9D I mean that the ICE agent should not add = these late arrivals to any check lists. If the agent would add the late candidate to check lists you effectively = would have implemented continuous nomination. Wether you then return on the API side of the ICE agent =E2=80=9COk=E2=80=9D= or =E2=80=9CReject=E2=80=9D I think is a separate discussion. And I would tend to argue that the IETF usually does not design APIs. > Then, in future, if continuous nomination is supported, instead of > rejecting the message carrying the candidates it is simply accepted :) That was the previous point I was trying to make :-) Cheers Nils --Apple-Mail=_FA696288-2D7F-4B39-81C1-7A7568858CC3 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----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlqe1KsACgkQY2o/VmzJ +KH9dg/8CwQ1UK+3um972PasSRmewRDClmh6Wg0Uf+OLiyvfKP/WukCAHfXH9YTQ heL/V5jC5Opt7jGRR7VKjsy/idS/t+6K3HOg5YL4XVLcifk5eBGyPX6oUsosyQHT 5cN3qYtfTpIuGKWklSjGTwtqK5KoL6WE0AsWGvwCy0kdD86yXivZcULcFLyD0u46 f4I08S+VqUGL9ZsU+vxJ3y68KluqXQxUZBozs1Mzs0zx2/OBfI0882O+oP84gQ4k rLdArhlDMI+5psYucURe5DuWvlhoyM25LpibTmtx5pCaU6S5pFEq2uUdUuR5ALqZ 8w9pZ7CSR1+ZyH0z/zqlJunx/XZAzZuJXZmFTUOWBq9SOzkuc9zVlT39jLv2Dagn bRbziA/CWK7hkuWdjUeS9hv739ZJn8iVqiCV+fEE50uXNFgzgd31Nv6mfDqhs0zx cdv4o1B+xiTJz/C6oF+fa3pfAbYcirrkDgygQFaQpTW9Kz8Ciq05BI2fPC1WChGE l3ivHX6ihFxr6pOMOYMP6A0wbdNUk767CuQcM5A1qRzaW/135QqUuczLSmO7r/Xt UDCG1ZBSGTLM+CNmtuwGIHERxU+irUaUfAylNIWaEeAHxCfAWdkRLrf3sCe1cWu0 HG4wxbx3gq9b9fIHC2Pt5PltpZ6dCOJ9KKdNE0/YFz31IxCWKjM= =Cfss -----END PGP SIGNATURE----- --Apple-Mail=_FA696288-2D7F-4B39-81C1-7A7568858CC3-- From nobody Tue Mar 6 11:33:23 2018 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 3E6A71270A0 for ; Tue, 6 Mar 2018 11:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=ericsson.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 J5rzrKWy26ff for ; Tue, 6 Mar 2018 11:33:19 -0800 (PST) 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 918AD126BF3 for ; Tue, 6 Mar 2018 11:33:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520364797; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DFFOvAWnyOkOTuIA8aSMtRNytFQoAkzSpYqXEMVyHsg=; b=UrenHr/o/PVl+k722V0uHZBRYh49ZywMMcol0cVFMz2/iCnsqTbC1/W7ukuQjxDB zXVpa7V065alAWdquk1UHqgwIdWfhWrb8u5OkzubzDCjGK5Ik+VEtN1fJpn4/QPO IjYHRw1iosfdBQWiPvIJpVC+BdcnP8CogIGR49LdkZc=; X-AuditID: c1b4fb3a-347ff700000067b4-b4-5a9eecfdf281 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 17.C4.26548.DFCEE9A5; Tue, 6 Mar 2018 20:33:17 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Tue, 6 Mar 2018 20:33:17 +0100 From: Christer Holmberg To: Nils Ohlmeier CC: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] Trickle: A couple of questions on section 7 Thread-Index: AdOucJgg+M5x/JnqQAe0nEYDsAIfMAA5PBQAABTM7oAAEyrzgAACkKBQAJLFpgAABlMCgAACaSigAKPFqYAACzR5gAAQX7OAAAWiY8A= Date: Tue, 6 Mar 2018 19:33:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1C5628@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1BC7F7@ESESSMB109.ericsson.se> <6C328929-B686-49EF-A79E-EDDF3AA630AD@mozilla.com> <96978131-7BF8-48A6-A1FA-8C8CF360A05A@mozilla.com> In-Reply-To: <96978131-7BF8-48A6-A1FA-8C8CF360A05A@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.169] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7hO7fN/OiDP481rb4dqHW4vq8yYwW z1aeYnRg9liy5CeTR9+BLtYApigum5TUnMyy1CJ9uwSujOfXzjIXLBCu2HG/jbGB8YFQFyMH h4SAicSN5fJdjFwcQgKHGSUuT3rOCuEsYpRY8n4jG0gRm4CFRPc/bRBTREBT4sRGvi5GTg5m AS+JvVsWMoHYwgJ2Er3n17CD2CIC9hLbeq+xQNhlEts/9jGD2CwCKhI3rl4Ds3kFfCU69txj gVj1nUXizbn9zCDzOYGabx8Gm8koICbx/dQaJohd4hK3nswHsyUEBCSW7DnPDGGLSrx8/I8V wlaSONm9mQVkDDPQmet36UO0KkpM6X7IDrFWUOLkzCcsExhFZyGZOguhYxaSjllIOhYwsqxi FC1OLS7OTTcy0kstykwuLs7P08tLLdnECIyTg1t+W+1gPPjc8RCjAAejEg+vxLN5UUKsiWXF lbmHGCU4mJVEeHWOAYV4UxIrq1KL8uOLSnNSiw8xSnOwKInzOqVZRAkJpCeWpGanphakFsFk mTg4pRoYNb/FHggSK+G9d/ityN5OkbiPJ05+WGh79OehJe9mpa99x+dwM/B59yy5mVG2X55+ 3au9an3lS2Ej8/MfP9bU3Q/j9Htks79j/baYR2nGahtXnOQofOfeun6zvzfTPN/WpeI5t2z8 FywuYL8X0CVUGd1qMO/b+zVKvOHuNquzf12SaG+3UatLUWIpzkg01GIuKk4EAJudjbiPAgAA Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 06 Mar 2018 19:33:21 -0000 SGksDQoNCj4+PiBGYWlyIGVub3VnaC4NCj4+PiANCj4+PiBUaGUgb3RoZXIgd29ycnkgSSBoYXZl IHdpdGggcmVzdHJpY3Rpbmcgb24gdGhlIGVtaXR0aW5nIHNpZGUgaXMgdGhhdCANCj4+PiBlZmZl Y3RpdmVseSBJQ0UgYW5kIHRoZSBzaWduYWxpbmcgbGF5ZXIgYXJlIGluIGEgcmFjZSwgd2hpY2gg bW9zdCANCj4+PiBzY2VuYXJpb3MgdGhlIHNpZ25hbGluZyBsYXllciBpcyBnb2luZyB0byBsb29z ZS4gVGhhdCByZXN1bHRzIGluIElDRSANCj4+PiBhZ2VudCByZWNlaXZpbmcgdHJpY2tsZSBjYW5k aWRhdGVzIHZlcnkgbGlrZWx5IGdldHRpbmcgaW50byB0aGUgDQo+Pj4gc2NlbmFyaW8gd2hlcmUg SUNFIGhhcyBjb25jbHVkZWQgd2l0aCB1c2UtY2FuZGlkYXRlIGJlaW5nIHNldCwgYnV0IA0KPj4+ IHN0aWxsIHJlY2VpdmluZyBjYW5kaWRhdGVzIHZpYSB0aGUgc2lnbmFsaW5nIGxheWVyLiBJZiB5 b3Ugd2FudCB0byANCj4+PiBzdWdnZXN0IHdoYXQgdG8gZG8gd2l0aCB0aGVzZSBsYXRlIGFycml2 YWxzLCBlLmcuIHJlamVjdGluZywgdGhlbiB3ZSANCj4+PiBuZWVkIHNvbWUgdGV4dCBleHBsYWlu aW5nIHRoaXMgc2NlbmFyaW8gYW55IHdheS4NCj4+PiANCj4+PiBTbyBmb3IgbWUgaXTCuXM6DQo+ Pj4gLSBlaXRoZXIgb25seSBkZXNjcmliZSB0aGUgcmVjZWl2aW5nIElDRSBhZ2VudCBpZ25vcmVz IGxhdGUgYXJyaXZpbmcgDQo+Pj4gY2FuZGlkYXRlcw0KPj4+IC0gb3IgZGVtYW5kaW5nIHRoYXQg dGhlIGVtaXR0aW5nIElDRSBjYW5kaWRhdGUgc2hhbGwgc3RvcCBlbWl0dGluZyANCj4+PiBBTkQg dGhlIHJlY2VpdmluZyBJQ0UgYWdlbnQgYWxzbyBuZWVkcyB0byBpZ25vcmUgbGF0ZSBhcnJpdmFs IHRvIGJlIA0KPj4+IHNhZmUNCj4+IA0KPj4gTm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSDCs2ln bm9yZcKyLCBidXQgSSB0aGluayB0aGUgbWVzc2FnZSBjYXJyeWluZyANCj4+IHRoZSB0cmlja2xl ZCBjYW5kaWRhdGVzIHNob3VsZCBiZSBleHBsaWNpdGx5IHJlamVjdGVkLCBzbyB0aGF0IHRoZSAN Cj4+IGVtaXR0aW5nIGFnZW50IGtub3dzIHdoYXQgaXMgZ29pbmcgb24uDQo+DQo+IFdpdGgg4oCc aWdub3Jl4oCdIEkgbWVhbiB0aGF0IHRoZSBJQ0UgYWdlbnQgc2hvdWxkIG5vdCBhZGQgdGhlc2Ug bGF0ZSBhcnJpdmFscyB0byBhbnkgY2hlY2sgbGlzdHMuDQo+IElmIHRoZSBhZ2VudCB3b3VsZCBh ZGQgdGhlIGxhdGUgY2FuZGlkYXRlIHRvIGNoZWNrIGxpc3RzIHlvdSBlZmZlY3RpdmVseSB3b3Vs ZCBoYXZlIGltcGxlbWVudGVkIGNvbnRpbnVvdXMgbm9taW5hdGlvbi4NCg0KWWVzLg0KDQo+IFdl dGhlciB5b3UgdGhlbiByZXR1cm4gb24gdGhlIEFQSSBzaWRlIG9mIHRoZSBJQ0UgYWdlbnQg4oCc T2vigJ0gb3Ig4oCcUmVqZWN04oCdIEkgdGhpbmsgaXMgYSBzZXBhcmF0ZSBkaXNjdXNzaW9uLg0K PiBBbmQgSSB3b3VsZCB0ZW5kIHRvIGFyZ3VlIHRoYXQgdGhlIElFVEYgdXN1YWxseSBkb2VzIG5v dCBkZXNpZ24gQVBJcy4NCg0KVHJ1ZS4gQnV0LCBJRVRGIGRvZXMgZGVzaWduIHByb3RvY29scywg YW5kIEkgd2FzIHRhbGtpbmcgYWJvdXQgaW5mb3JtaW5nIHRoZSBwZWVyIHRoYXQgdGhlIGNhbmRp ZGF0ZXMgaGUgdHJpY2tsZWQgdG8gbWUgd2hlcmUgcmVqZWN0ZWQgOikNCg0KRXhhY3RseSBob3cg aXQgaXMgZG9uZSBpcyBvZiBjb3Vyc2UgZGVwZW5kaW5nIG9uIHRoZSBJQ0UgdXNhZ2UgcHJvdG9j b2wsIGJ1dCB0aGUgSUNFIFdHIHNwZWMgc2hvdWxkIGRlZmluZSB0aGUgaGlnaC1sZXZlbCBwcm9j ZWR1cmUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From nobody Wed Mar 7 04:38:47 2018 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 1DD2F128954 for ; Wed, 7 Mar 2018 04:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 tclGPHsvQlau for ; Wed, 7 Mar 2018 04:38:40 -0800 (PST) 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 2158612D877 for ; Wed, 7 Mar 2018 04:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520426315; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kuIEOaR9bz8AqayhAnDHoSI4aEvj9Wc6AuPSESWAdMU=; b=hD8lylBzWnQLjiSUuAV9gcT+wq7V6NuY4tJN6BxEmKmDsoPQfbZ3+T1S6e3gB15h dUUiDkmhiRvhy38dbBsAx393E3U18dMIwfa53YYl2NiHnPJjUjZhhxO3wQr+oxd8 BcOwKSAtuuQih3XEmj1Bw8Ky4HNCLdCRg1inVzxMRc4=; X-AuditID: c1b4fb30-399ff70000004778-a5-5a9fdd4bd372 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 48.80.18296.B4DDF9A5; Wed, 7 Mar 2018 13:38:35 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Wed, 7 Mar 2018 13:38:34 +0100 From: Christer Holmberg To: Christer Holmberg , The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , "ice@ietf.org" , "adam@nostrum.com" Thread-Topic: Draft new version: draft-ietf-ice-rfc5245bis-19 Thread-Index: AQHTtIMhw2aa8ZI4rUmEeCqVBFRONKPEzdQA Date: Wed, 7 Mar 2018 12:38:34 +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.19] Content-Type: multipart/alternative; boundary="_000_D6C5ACB02C447christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7n6733flRBqcOSFrs+buI3WL+yevM FhdnTWaz+Hah1mLGn4nMDqweS5b8ZPKYtfMJSwBTFJdNSmpOZllqkb5dAldG85u3bAUrLSu+ T5nP3sDYatzFyMkhIWAi8fPTAkYQW0jgMKPE4zelXYxcQPYiRomL9z6zdDFycLAJWEh0/9MG iYsITGOS6D61nwmkQVjARuLRx33sILaIgK3EmlvL2SBsI4n1W+6xgtgsAioSM+a/BKvhFbCW mHj5JjvEMmuJHU07WEHmcwLNabwuDhJmFBCT+H5qDdh4ZgFxiVtP5jNB3CkgsWTPeWYIW1Ti 5eN/YONFBfQkNpy4zQ4RV5Rof9rACDKSWSBBYtEsNYitghInZz5hmcAoMgvJ1FkIVbOQVEGU GEi8PzefGcLWlli28DWUrS+x8ctZRohWa4l9T9yQlSxg5FjFKFqcWpyUm25kpJdalJlcXJyf p5eXWrKJERiDB7f8NtjB+PK54yFGAQ5GJR5eK2BsCrEmlhVX5h5ilOBgVhLhnVwCFOJNSays Si3Kjy8qzUktPsQozcGiJM570pM3SkggPbEkNTs1tSC1CCbLxMEp1cDIbDgpVeBQikgRc8Vu JkfdRWGvVKdyd06SKL5rPv9hqM/9L1dvtTGmxD54r/nA7XoV18H6SwFvSlOfKb6uljnGp5a+ Yb9H4Lf1/K/TMqf6Fl+U315+rTOm9EdjiJRi2bdF11X+Rvr0Xn73tj+u5WmnoH7c/qCpn3U4 /+gIqGV/XyjrtXFF83wlluKMREMt5qLiRABpDAHvvQIAAA== Archived-At: Subject: Re: [Ice] Draft new version: draft-ietf-ice-rfc5245bis-19 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, 07 Mar 2018 12:38:41 -0000 --_000_D6C5ACB02C447christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I realised there was still one section (8.1.2) which contained text based o= n usage of aggressive nomination, and multiple nominated pairs for a given = component. I have created a pull requests which fixes that: https://github.com/ice-wg/rfc5245bis/pull/64 Regards, Christer From: Christer Holmberg > Date: Monday 5 March 2018 at 15:09 To: "iesg@ietf.org" >, "draft-ietf-ice-rfc5245bis@ietf.org" >, "ice-chairs@ietf.org" >, "ice@ietf.org" >, "adam@nostrum.com" > Subject: Draft new version: draft-ietf-ice-rfc5245bis-19 Resent-From: > Resent-To: Ari Ker=E4nen >, Christer Holmberg >, "jdrosen@jdrosen.net= " > Resent-Date: Monday 5 March 2018 at 15:09 Hi, I have merged all 5245bis pull requests, and submitted a new version (-19) = of draft-ietf-ice-rfc5245bis. At this point I don=92t intend to do further changes based on the IESG revi= ew, so let me know if I=92ve missed/misunderstood something. Thank You to everyone who reviewed the document! Regards, Christer --_000_D6C5ACB02C447christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I realised there was still one section (8.1.2) which contained text ba= sed on usage of aggressive nomination, and multiple nominated pairs for a g= iven component.

I have created a pull requests which fixes that:


Regards,

Christer




Hi,

I have merged all 5245bis pull requests, and submitted a new version (= -19) of draft-ietf-ice-rfc5245bis.

At this point I don=92t intend to do further changes based on the IESG= review, so let me know if I=92ve missed/misunderstood something.

Thank You to everyone who reviewed the document!

Regards,

Christer

 

 --_000_D6C5ACB02C447christerholmbergericssoncom_-- From nobody Thu Mar 8 12:04:51 2018 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 1A617120721; Thu, 8 Mar 2018 12:04:46 -0800 (PST) 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.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152053948602.14026.6990742136181945455@ietfa.amsl.com> Date: Thu, 08 Mar 2018 12:04:46 -0800 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-rfc5245bis-20.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: Thu, 08 Mar 2018 20:04: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-20.txt Pages : 100 Date : 2018-03-08 Abstract: This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. 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-20 https://datatracker.ietf.org/doc/html/draft-ietf-ice-rfc5245bis-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-rfc5245bis-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 12 14:36:38 2018 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 08BFF1200C1; Mon, 12 Mar 2018 14:36:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-ice-rfc5245bis@ietf.org, Peter Thatcher , ice-chairs@ietf.org, pthatcher@google.com, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.75.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152089059198.10877.12230638711039434169.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2018 14:36:31 -0700 Archived-At: Subject: [Ice] Adam Roach's No Objection on draft-ietf-ice-rfc5245bis-20: (with COMMENT) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 21:36:32 -0000 Adam Roach has entered the following ballot position for draft-ietf-ice-rfc5245bis-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss and comments. From nobody Tue Mar 13 00:06:24 2018 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 68E1A12D775 for ; Tue, 13 Mar 2018 00:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 1WxdQED9oeF9 for ; Tue, 13 Mar 2018 00:06:22 -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 AF9D412D0C3 for ; Tue, 13 Mar 2018 00:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520924779; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZMWPN5eBttir6bbAKzos8vF+3OlwTlZo1FQ+/dUX+Fw=; b=a7B70cKfGsEi1q+x20xXuNJh/ORkfWLw9DPfPfIWR0HTch9CVl7JoPMqDXlzmK43 tmS8e0vOeT8KAq6tKsCZIYeqqngJNiFap0PAPRA7LX8le+CVUFFDaZuMLgRZEgLc tNG+COz+IPbbD3jzMt+8E1L5ZG57n9PPfGZGQLoWtos=; X-AuditID: c1b4fb30-799639c000004778-5a-5aa7786a7a41 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8B.05.18296.A6877AA5; Tue, 13 Mar 2018 08:06:19 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0382.000; Tue, 13 Mar 2018 08:06:17 +0100 From: Christer Holmberg To: Adam Roach , The IESG CC: "draft-ietf-ice-rfc5245bis@ietf.org" , Peter Thatcher , "ice-chairs@ietf.org" , "ice@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-ice-rfc5245bis-20: (with COMMENT) Thread-Index: AQHTukoxBwbUTNivv0+G5I5ghatR1aPNz8kA Date: Tue, 13 Mar 2018 07:06:16 +0000 Message-ID: References: <152089059198.10877.12230638711039434169.idtracker@ietfa.amsl.com> In-Reply-To: <152089059198.10877.12230638711039434169.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-ID: <0E2DF042D24BA24AA222F41016F26B7B@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2K7t252xfIogyeb2C32/F3EbjH/5HVm i4uzJrNZfLtQazHjz0Rmi2vLX7M6sHks2FTqsWTJTyaPWTufsAQwR3HZpKTmZJalFunbJXBl /P14jKWgh73i3smUBsYmti5GTg4JAROJG7/eANlcHEIChxklTravZ4FwljBK3DkxAyjDwcEm YCHR/U8bpEFEwFridPNJZpAaZoEjjBIvf3xkBEkIC0RIrN43lw2iKFKir6+TEcI2kljR9pgZ xGYRUJXoW3eaFcTmBRp0+dQ7JhBbSMBP4vTPa2D1nAL+Ei2dF8DmMAqISXw/tQashllAXOLW k/lMEFcLSCzZc54ZwhaVePn4H9hMUQE9iQ0nbrNDxBUldp5tZ4bo1ZFYsPsTG4RtLfHz1m52 CFtbYtnC18wQ9whKnJz5hGUCo/gsJOtmIWmfhaR9FpL2WUjaFzCyrmIULU4tTspNNzLSSy3K TC4uzs/Ty0st2cQIjM6DW34b7GB8+dzxEKMAB6MSD29AyvIoIdbEsuLK3EOMEhzMSiK8yv+X RQnxpiRWVqUW5ccXleakFh9ilOZgURLnPenJGyUkkJ5YkpqdmlqQWgSTZeLglGpgnGT5c8/G KzXr03INMmTv6ORIyb9+t7Tv5fqPzw6dTasK3xRafS1M3c5z8dFSlzq3D/WijM8tKre/Dzh4 K1bjW3/YOqv6ZVd05m4v2WQ67V97uuuaJq3orsUpU/nEI8+F50SVayt9EzvjsTnnzaJEcb/H cy295i1rNS5c+6p+c+omu83T7fWnKLEUZyQaajEXFScCALw1qtTKAgAA Archived-At: Subject: Re: [Ice] Adam Roach's No Objection on draft-ietf-ice-rfc5245bis-20: (with COMMENT) 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, 13 Mar 2018 07:06:23 -0000 Thank You, Adam! :) Regards, Christer On 12/03/18 23:36, "Adam Roach" wrote: >Adam Roach has entered the following ballot position for >draft-ietf-ice-rfc5245bis-20: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Thanks for addressing my discuss and comments. > > From nobody Tue Mar 13 20:46:41 2018 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 92C0E126BF3 for ; Tue, 13 Mar 2018 20:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, T_RP_MATCHES_RCVD=-0.01] 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 CCqh2XpAaq1x for ; Tue, 13 Mar 2018 20:46:38 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 F3F96124E15 for ; Tue, 13 Mar 2018 20:46:37 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id h76so1304339wme.4 for ; Tue, 13 Mar 2018 20:46:37 -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=vUq9daG35a7nf5mb2Re0FeB2UkrabV9uLFSKfaqzguA=; b=OV2i2pY/oDWpuOCQqmrivfMTEVqNHbjl31rmHjUbAgBc9UtlYRBN0sXUgzKlXuYkmq lrtqGSG3+E02mQ8DV4AyXWfzkNXLjYZ1XH1zXpsRmDWiPBLc3q8QpZtz+4myOP04Q+IR umFZzrWfDtD9Dhma19jepjnM8/e96GjgmG8/cgxLicLyaj50hzYyxgKy7MHXDfS/9z9e tHCp/CTe1MwVd1BR+GzIJhssJgcoXts8SOzO0gwfC8FNDUYFQo9oSpctCFZpGt0lcyiH MeYLomJQqG+tZ7BqVrsJmH1JymRKPhylHVivuTzMzj97RSlflbJaFMxtCmY2fVRWskE/ nN6A== 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=vUq9daG35a7nf5mb2Re0FeB2UkrabV9uLFSKfaqzguA=; b=HZ7KQNnNpqMjUqyddZtgl3FWxe/XVvgy5jyQ2wWtUBB8/cxYe2IrXtit0PahOYnaAA ym6w9oarqjB39OW1NszlcD84ICFd5LOe8IeCRfS61wR5VUeU2od/X4fKFQSRJ7/9ZF33 xml07GhxpHEc8jTZuRuOprwWnG6awgBfPy39gND/9D1Iuriw5a/vpfD2UYVjDx6XVNxh WpWftf6iHIO8GVnXcPJUr1cLiHgHzzKo1jvFcUI81VNOAathUmw/4IRW/z4TXQpVJtCs aZWxxi3CBim/2z4wGiVXBB9/i2pK8eXB68vs2movHlnFmySTVSta/nVDV7AOAgXW9PBr 35JQ== X-Gm-Message-State: AElRT7Ehd1D06v/YCvs21WDBfzaFr/TPNkAFFhOUTzWfOsine+cM9SDM rYxu53LnjfV5cKG/bzZ+Y71k/tgoj04xanPtSATWic9k X-Google-Smtp-Source: AG47ELu4JN4lLV4NdQ46kSoATGNGH1rq1UlGxRRAyI+iTOr5a7T7GwMs8qOEOX7LLxYdPx1XnLKC+J2gxD6reOAfKmw= X-Received: by 10.28.174.11 with SMTP id x11mr318543wme.124.1520999195788; Tue, 13 Mar 2018 20:46:35 -0700 (PDT) MIME-Version: 1.0 From: Peter Thatcher Date: Wed, 14 Mar 2018 03:46:24 +0000 Message-ID: To: ICE WG Content-Type: multipart/alternative; boundary="001a11444cb2c560f40567573800" Archived-At: Subject: [Ice] Confirmation about tie breaker behavior changes ICEbis 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, 14 Mar 2018 03:46:39 -0000 --001a11444cb2c560f40567573800 Content-Type: text/plain; charset="UTF-8" In the changes to ICEbis during the IESG review (thanks again Christer!), there is one item that has come up that is not just editorial: The changing of the tie breaker value during a role change due to role conflict has changed from a MAY to a MUST. This was to address the very rare situation when both sides choose the same tie breaker value. If you disagree with this change, please let it be known. If we don't hear anything, we will assume consensus and proceed with publication of ICEbis. Thanks! By the way, you can read rest of the changes to ICEbis at the links below, but in my opinion as shepherd after reading through all of them thoroughly, they are editorial except for this issue. https://tools.ietf.org/rfcdiff?url1=draft-ietf-ice-rfc5245bis-17.txt&url2=draft-ietf-ice-rfc5245bis-20.txt --001a11444cb2c560f40567573800 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the changes to ICEbis during the IESG review (thanks ag= ain Christer!), there is one item that has come up that is not just editori= al:

The changing of the tie breaker value during a role = change due to role conflict has changed from a MAY to a MUST.=C2=A0 This wa= s to address the very rare situation when both sides choose the same tie br= eaker value.=C2=A0=C2=A0

If you disagree with this= change, please let it be known.=C2=A0 If we don't hear anything, we wi= ll assume consensus and proceed with publication of ICEbis.=C2=A0

Thanks!



<= div>By the way, you can read rest of the changes to ICEbis at the links bel= ow, but in my opinion as shepherd after reading through all of them thoroug= hly, they are editorial except for this issue.

--001a11444cb2c560f40567573800-- From nobody Wed Mar 14 01:55:58 2018 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 CBDE41270A3 for ; Wed, 14 Mar 2018 01:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 d7alqwIocdT7 for ; Wed, 14 Mar 2018 01:55:56 -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 44A481200C5 for ; Wed, 14 Mar 2018 01:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521017754; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FoskdnbQ3cXcgvRN+z1Hz8cGzfvjdh4StiGI2MS7AT0=; b=BPJnyNH4NeCqIwJKpXKgovfea5dzl3qlJD1W1xABlcrRZNF50AJeFx8WXrOfekrV fk2eNfTxEKJMEvTDmKUTQAS441atyEZWv0TExvK5SqnvrChJ/57+5eEkYavJcGdW a5AhRQaBVi9NruVTHXA8sKGq1vzYH1eLLsb8TUCnTJw=; X-AuditID: c1b4fb2d-499ff70000005540-b5-5aa8e39ae33e Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 86.7E.21824.A93E8AA5; Wed, 14 Mar 2018 09:55:54 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0382.000; Wed, 14 Mar 2018 09:55:54 +0100 From: Christer Holmberg To: Christer Holmberg , Nils Ohlmeier CC: "ice@ietf.org" , Peter Saint-Andre Thread-Topic: [Ice] Trickle: A couple of questions on section 7 Thread-Index: AdOucJgg+M5x/JnqQAe0nEYDsAIfMAA5PBQAABTM7oAAEyrzgAACkKBQAJLFpgAABlMCgAACaSigAKPFqYAACzR5gAAQX7OAAAWiY8ABfkHCgA== Date: Wed, 14 Mar 2018 08:55:54 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1BC7F7@ESESSMB109.ericsson.se> <6C328929-B686-49EF-A79E-EDDF3AA630AD@mozilla.com> <96978131-7BF8-48A6-A1FA-8C8CF360A05A@mozilla.com> <7594FB04B1934943A5C02806D1A2204B6C1C5628@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1C5628@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.7.170905 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="euc-kr" Content-ID: <79285BD21135E241B9510B831C071949@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM2K7me6sxyuiDG7vUrX4dqHW4vq8yYwW z1aeYnRg9liy5CeTR9+BLtYApigum5TUnMyy1CJ9uwSujLMHZrEXnBKv2PhzDXsD4x+xLkZO DgkBE4nPt7ezdjFycQgJHGaUeL3zIDuEs4RRomF1I0sXIwcHm4CFRPc/bRBTRCBeomEaH4jJ LOAlcXu7KcgYYQE7iVmn/rCA2CIC9hLbeq9B2XUSEz4cBbNZBFQlpp1aB2bzClhL3O98ywix aTerxLcNc9hAEpwCfhJHdkwAsxkFxCS+n1rDBGIzC4hL3HoynwniZgGJJXvOM0PYohIvH/9j BbFFBfQkNpy4zQ5ym4SAksS0rWkQrVoSX37sY4OwrSU2Nc5ngbAVJaZ0P2SHuEdQ4uTMJywT GMVnIdk2C0n7LCTts5C0z0LSvoCRdRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYMwd3PJb dwfj6teOhxgFOBiVeHi7Lq6IEmJNLCuuzD3EKMHBrCTCu1UGKMSbklhZlVqUH19UmpNafIhR moNFSZz3pCdvlJBAemJJanZqakFqEUyWiYNTqoFx6aXn1+bf5xNX+nT9SWD9gcStQkHrJv99 tapwVV7o83i771duVnjmTdv/+cLVnjcPLi2+u+cXC9Nmo+LyxT/6zz+YE8M2IUFntZzhnvVT v764abFmhe6zj/Ytb60r9z0SyVx5O6HqMrfHiQX+5W9+mMSyCd48+bm4cdrn6wH/Ku8kH5F1 zhRbI6/EUpyRaKjFXFScCACBhbWNtQIAAA== Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 14 Mar 2018 08:55:58 -0000 SGksDQoNCklzIHNvbWVvbmUgcGxhbm5pbmcgdG8gZG8gc29tZXRoaW5nICh1cGRhdGUgdGhlIGRy YWZ0KSByZWxhdGVkIHRvIHRoaXM/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KT24gMDYv MDMvMTggMjE6MzMsICJJY2Ugb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnIg0KPGljZS1i b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20+IHdyb3RlOg0KDQo+SGksDQo+DQo+Pj4+IEZhaXIgZW5vdWdoLg0KPj4+PiANCj4+Pj4gVGhl IG90aGVyIHdvcnJ5IEkgaGF2ZSB3aXRoIHJlc3RyaWN0aW5nIG9uIHRoZSBlbWl0dGluZyBzaWRl IGlzIHRoYXQNCj4+Pj4gZWZmZWN0aXZlbHkgSUNFIGFuZCB0aGUgc2lnbmFsaW5nIGxheWVyIGFy ZSBpbiBhIHJhY2UsIHdoaWNoIG1vc3QNCj4+Pj4gc2NlbmFyaW9zIHRoZSBzaWduYWxpbmcgbGF5 ZXIgaXMgZ29pbmcgdG8gbG9vc2UuIFRoYXQgcmVzdWx0cyBpbiBJQ0UNCj4+Pj4gYWdlbnQgcmVj ZWl2aW5nIHRyaWNrbGUgY2FuZGlkYXRlcyB2ZXJ5IGxpa2VseSBnZXR0aW5nIGludG8gdGhlDQo+ Pj4+IHNjZW5hcmlvIHdoZXJlIElDRSBoYXMgY29uY2x1ZGVkIHdpdGggdXNlLWNhbmRpZGF0ZSBi ZWluZyBzZXQsIGJ1dA0KPj4+PiBzdGlsbCByZWNlaXZpbmcgY2FuZGlkYXRlcyB2aWEgdGhlIHNp Z25hbGluZyBsYXllci4gSWYgeW91IHdhbnQgdG8NCj4+Pj4gc3VnZ2VzdCB3aGF0IHRvIGRvIHdp dGggdGhlc2UgbGF0ZSBhcnJpdmFscywgZS5nLiByZWplY3RpbmcsIHRoZW4gd2UNCj4+Pj4gbmVl ZCBzb21lIHRleHQgZXhwbGFpbmluZyB0aGlzIHNjZW5hcmlvIGFueSB3YXkuDQo+Pj4+IA0KPj4+ PiBTbyBmb3IgbWUgaXSp9nM6DQo+Pj4+IC0gZWl0aGVyIG9ubHkgZGVzY3JpYmUgdGhlIHJlY2Vp dmluZyBJQ0UgYWdlbnQgaWdub3JlcyBsYXRlIGFycml2aW5nDQo+Pj4+IGNhbmRpZGF0ZXMNCj4+ Pj4gLSBvciBkZW1hbmRpbmcgdGhhdCB0aGUgZW1pdHRpbmcgSUNFIGNhbmRpZGF0ZSBzaGFsbCBz dG9wIGVtaXR0aW5nDQo+Pj4+IEFORCB0aGUgcmVjZWl2aW5nIElDRSBhZ2VudCBhbHNvIG5lZWRz IHRvIGlnbm9yZSBsYXRlIGFycml2YWwgdG8gYmUNCj4+Pj4gc2FmZQ0KPj4+IA0KPj4+IE5vdCBz dXJlIHdoYXQgeW91IG1lYW4gYnkgqfhpZ25vcmWp9ywgYnV0IEkgdGhpbmsgdGhlIG1lc3NhZ2Ug Y2FycnlpbmcNCj4+PiB0aGUgdHJpY2tsZWQgY2FuZGlkYXRlcyBzaG91bGQgYmUgZXhwbGljaXRs eSByZWplY3RlZCwgc28gdGhhdCB0aGUNCj4+PiBlbWl0dGluZyBhZ2VudCBrbm93cyB3aGF0IGlz IGdvaW5nIG9uLg0KPj4NCj4+IFdpdGggobBpZ25vcmWhsSBJIG1lYW4gdGhhdCB0aGUgSUNFIGFn ZW50IHNob3VsZCBub3QgYWRkIHRoZXNlIGxhdGUNCj4+YXJyaXZhbHMgdG8gYW55IGNoZWNrIGxp c3RzLg0KPj4gSWYgdGhlIGFnZW50IHdvdWxkIGFkZCB0aGUgbGF0ZSBjYW5kaWRhdGUgdG8gY2hl Y2sgbGlzdHMgeW91DQo+PmVmZmVjdGl2ZWx5IHdvdWxkIGhhdmUgaW1wbGVtZW50ZWQgY29udGlu dW91cyBub21pbmF0aW9uLg0KPg0KPlllcy4NCj4NCj4+IFdldGhlciB5b3UgdGhlbiByZXR1cm4g b24gdGhlIEFQSSBzaWRlIG9mIHRoZSBJQ0UgYWdlbnQgobBPa6GxIG9yDQo+PqGwUmVqZWN0obEg SSB0aGluayBpcyBhIHNlcGFyYXRlIGRpc2N1c3Npb24uDQo+PiBBbmQgSSB3b3VsZCB0ZW5kIHRv IGFyZ3VlIHRoYXQgdGhlIElFVEYgdXN1YWxseSBkb2VzIG5vdCBkZXNpZ24gQVBJcy4NCj4NCj5U cnVlLiBCdXQsIElFVEYgZG9lcyBkZXNpZ24gcHJvdG9jb2xzLCBhbmQgSSB3YXMgdGFsa2luZyBh Ym91dCBpbmZvcm1pbmcNCj50aGUgcGVlciB0aGF0IHRoZSBjYW5kaWRhdGVzIGhlIHRyaWNrbGVk IHRvIG1lIHdoZXJlIHJlamVjdGVkIDopDQo+DQo+RXhhY3RseSBob3cgaXQgaXMgZG9uZSBpcyBv ZiBjb3Vyc2UgZGVwZW5kaW5nIG9uIHRoZSBJQ0UgdXNhZ2UgcHJvdG9jb2wsDQo+YnV0IHRoZSBJ Q0UgV0cgc3BlYyBzaG91bGQgZGVmaW5lIHRoZSBoaWdoLWxldmVsIHByb2NlZHVyZS4NCj4NCj5S ZWdhcmRzLA0KPg0KPkNocmlzdGVyDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5JY2UgbWFpbGluZyBsaXN0DQo+SWNlQGlldGYub3JnDQo+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCg0K From nobody Wed Mar 14 01:57:44 2018 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 6F45D127909 for ; Wed, 14 Mar 2018 01:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 krxsTVnMazAB for ; Wed, 14 Mar 2018 01:57:41 -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 B521B1200C5 for ; Wed, 14 Mar 2018 01:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521017859; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+D+X9XxEUuHukplBsUCx/n1K58DKlOHTj8oYhOsc4AU=; b=ABDKrTTY/8+GGVoe9yt1P9QQxUuxvXyodSo/9gNkDLyb8Ub41ctc2x0ck+IjJ2Eb 93Fe0BX4J4YiXGLyW3Hwsg4M2Ld0/F8Tk9XUT9/IBKsmMly33xVI4WY9i0eX3ILq jfVGY83b+9a233zeAJV5GE4oN2yMF59eIMyLOQEEGKA=; X-AuditID: c1b4fb25-681ff70000006222-0f-5aa8e4020400 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 17.2A.25122.204E8AA5; Wed, 14 Mar 2018 09:57:39 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0382.000; Wed, 14 Mar 2018 09:57:38 +0100 From: Christer Holmberg To: Christer Holmberg , Nils Ohlmeier CC: "ice@ietf.org" , Peter Saint-Andre Thread-Topic: [Ice] Trickle: A couple of questions on section 7 Thread-Index: AdOucJgg+M5x/JnqQAe0nEYDsAIfMAA5PBQAABTM7oAAEyrzgAACkKBQAJLFpgAABlMCgAACaSigAKPFqYAACzR5gAAQX7OAAAWiY8ABfkHCgAAADzOA Date: Wed, 14 Mar 2018 08:57:37 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1BC7F7@ESESSMB109.ericsson.se> <6C328929-B686-49EF-A79E-EDDF3AA630AD@mozilla.com> <96978131-7BF8-48A6-A1FA-8C8CF360A05A@mozilla.com> <7594FB04B1934943A5C02806D1A2204B6C1C5628@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.7.170905 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="euc-kr" Content-ID: <13297C539B45C84D95F547355843F15B@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7sS7zkxVRBl+2Mlt8u1BrcX3eZEaL ZytPMToweyxZ8pPJo+9AF2sAUxSXTUpqTmZZapG+XQJXxudZt5gL2qQr5r1aw9bAuEaqi5GT Q0LARGLPmglMXYxcHEIChxkl5t38zgzhLGGUWLR3IUsXIwcHm4CFRPc/bRBTRCBeomEaH4jJ LOAlcXu7KcgYYQE7iVmn/rCA2CIC9hLbeq9B2U2MEoefxoPYLAKqEtffTmcFsXkFrCWWPOuG 2vSWVeLnmXvsIAlOARuJJX3b2UBsRgExie+n1jCB2MwC4hK3nsxngrhZQGLJnvPMELaoxMvH /8CGigroSWw4cZsdIq4ocXX6cqheLYkvP/axQdjWEnM3bWKHsBUlpnQ/ZIc4SFDi5MwnLBMY xWchWTcLSfssJO2zkLTPQtK+gJF1FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZg1B3c8lt1 B+PlN46HGAU4GJV4eBdeWBElxJpYVlyZe4hRgoNZSYR3qwxQiDclsbIqtSg/vqg0J7X4EKM0 B4uSOO8c4fYoIYH0xJLU7NTUgtQimCwTB6dUA+Ok+Pf1qTv0I4TM29n+1fobevY2yn7r+i8m oHdBwdHlvU3hccP1LL0qq6sdMvZVdrFNXXPt7qT2VkffrN1maqozZNY/ctXKWXfi4Jz++Dm6 7bv+Wk7LuBiZ5W0kI8AgbDmb8abyhFrdwI7jPwzfOPpejTrIrXDY+EfO3JTkNyp/7Kaq11n7 KbEUZyQaajEXFScCAI26zAy2AgAA Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 14 Mar 2018 08:57:42 -0000 Tm90ZSB0aGF0IHRoZSBkcmFmdCBpcyBvbiB0aGUgSUVTRyB0ZWxlY2hhdCBhZ2VuZGEgaW4gdGhl IGJlZ2lubmluZyBvZg0KQXByaWwuIEkgdGhpbmsgdGhlIGlzc3VlcyB3ZSBoYXZlIGFncmVlZCBl eGlzdCBzaG91bGQgYmUgZml4ZWQgYmVmb3JlIHRoYXQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCg0KT24gMTQvMDMvMTggMTA6NTUsICJDaHJpc3RlciBIb2xtYmVyZyIgPGNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbT4NCndyb3RlOg0KDQo+SGksDQo+DQo+SXMgc29tZW9uZSBwbGFu bmluZyB0byBkbyBzb21ldGhpbmcgKHVwZGF0ZSB0aGUgZHJhZnQpIHJlbGF0ZWQgdG8gdGhpcz8N Cj4NCj5SZWdhcmRzLA0KPg0KPkNocmlzdGVyDQo+DQo+DQo+T24gMDYvMDMvMTggMjE6MzMsICJJ Y2Ugb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnIg0KPjxpY2UtYm91bmNlc0BpZXRmLm9y ZyBvbiBiZWhhbGYgb2YgY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4N Cj4+SGksDQo+Pg0KPj4+Pj4gRmFpciBlbm91Z2guDQo+Pj4+PiANCj4+Pj4+IFRoZSBvdGhlciB3 b3JyeSBJIGhhdmUgd2l0aCByZXN0cmljdGluZyBvbiB0aGUgZW1pdHRpbmcgc2lkZSBpcyB0aGF0 DQo+Pj4+PiBlZmZlY3RpdmVseSBJQ0UgYW5kIHRoZSBzaWduYWxpbmcgbGF5ZXIgYXJlIGluIGEg cmFjZSwgd2hpY2ggbW9zdA0KPj4+Pj4gc2NlbmFyaW9zIHRoZSBzaWduYWxpbmcgbGF5ZXIgaXMg Z29pbmcgdG8gbG9vc2UuIFRoYXQgcmVzdWx0cyBpbiBJQ0UNCj4+Pj4+IGFnZW50IHJlY2Vpdmlu ZyB0cmlja2xlIGNhbmRpZGF0ZXMgdmVyeSBsaWtlbHkgZ2V0dGluZyBpbnRvIHRoZQ0KPj4+Pj4g c2NlbmFyaW8gd2hlcmUgSUNFIGhhcyBjb25jbHVkZWQgd2l0aCB1c2UtY2FuZGlkYXRlIGJlaW5n IHNldCwgYnV0DQo+Pj4+PiBzdGlsbCByZWNlaXZpbmcgY2FuZGlkYXRlcyB2aWEgdGhlIHNpZ25h bGluZyBsYXllci4gSWYgeW91IHdhbnQgdG8NCj4+Pj4+IHN1Z2dlc3Qgd2hhdCB0byBkbyB3aXRo IHRoZXNlIGxhdGUgYXJyaXZhbHMsIGUuZy4gcmVqZWN0aW5nLCB0aGVuIHdlDQo+Pj4+PiBuZWVk IHNvbWUgdGV4dCBleHBsYWluaW5nIHRoaXMgc2NlbmFyaW8gYW55IHdheS4NCj4+Pj4+IA0KPj4+ Pj4gU28gZm9yIG1lIGl0qfZzOg0KPj4+Pj4gLSBlaXRoZXIgb25seSBkZXNjcmliZSB0aGUgcmVj ZWl2aW5nIElDRSBhZ2VudCBpZ25vcmVzIGxhdGUgYXJyaXZpbmcNCj4+Pj4+IGNhbmRpZGF0ZXMN Cj4+Pj4+IC0gb3IgZGVtYW5kaW5nIHRoYXQgdGhlIGVtaXR0aW5nIElDRSBjYW5kaWRhdGUgc2hh bGwgc3RvcCBlbWl0dGluZw0KPj4+Pj4gQU5EIHRoZSByZWNlaXZpbmcgSUNFIGFnZW50IGFsc28g bmVlZHMgdG8gaWdub3JlIGxhdGUgYXJyaXZhbCB0byBiZQ0KPj4+Pj4gc2FmZQ0KPj4+PiANCj4+ Pj4gTm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSCp+Glnbm9yZan3LCBidXQgSSB0aGluayB0aGUg bWVzc2FnZSBjYXJyeWluZw0KPj4+PiB0aGUgdHJpY2tsZWQgY2FuZGlkYXRlcyBzaG91bGQgYmUg ZXhwbGljaXRseSByZWplY3RlZCwgc28gdGhhdCB0aGUNCj4+Pj4gZW1pdHRpbmcgYWdlbnQga25v d3Mgd2hhdCBpcyBnb2luZyBvbi4NCj4+Pg0KPj4+IFdpdGggobBpZ25vcmWhsSBJIG1lYW4gdGhh dCB0aGUgSUNFIGFnZW50IHNob3VsZCBub3QgYWRkIHRoZXNlIGxhdGUNCj4+PmFycml2YWxzIHRv IGFueSBjaGVjayBsaXN0cy4NCj4+PiBJZiB0aGUgYWdlbnQgd291bGQgYWRkIHRoZSBsYXRlIGNh bmRpZGF0ZSB0byBjaGVjayBsaXN0cyB5b3UNCj4+PmVmZmVjdGl2ZWx5IHdvdWxkIGhhdmUgaW1w bGVtZW50ZWQgY29udGludW91cyBub21pbmF0aW9uLg0KPj4NCj4+WWVzLg0KPj4NCj4+PiBXZXRo ZXIgeW91IHRoZW4gcmV0dXJuIG9uIHRoZSBBUEkgc2lkZSBvZiB0aGUgSUNFIGFnZW50IKGwT2uh sSBvcg0KPj4+obBSZWplY3ShsSBJIHRoaW5rIGlzIGEgc2VwYXJhdGUgZGlzY3Vzc2lvbi4NCj4+ PiBBbmQgSSB3b3VsZCB0ZW5kIHRvIGFyZ3VlIHRoYXQgdGhlIElFVEYgdXN1YWxseSBkb2VzIG5v dCBkZXNpZ24gQVBJcy4NCj4+DQo+PlRydWUuIEJ1dCwgSUVURiBkb2VzIGRlc2lnbiBwcm90b2Nv bHMsIGFuZCBJIHdhcyB0YWxraW5nIGFib3V0IGluZm9ybWluZw0KPj50aGUgcGVlciB0aGF0IHRo ZSBjYW5kaWRhdGVzIGhlIHRyaWNrbGVkIHRvIG1lIHdoZXJlIHJlamVjdGVkIDopDQo+Pg0KPj5F eGFjdGx5IGhvdyBpdCBpcyBkb25lIGlzIG9mIGNvdXJzZSBkZXBlbmRpbmcgb24gdGhlIElDRSB1 c2FnZSBwcm90b2NvbCwNCj4+YnV0IHRoZSBJQ0UgV0cgc3BlYyBzaG91bGQgZGVmaW5lIHRoZSBo aWdoLWxldmVsIHByb2NlZHVyZS4NCj4+DQo+PlJlZ2FyZHMsDQo+Pg0KPj5DaHJpc3Rlcg0KPj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5JY2UgbWFp bGluZyBsaXN0DQo+PkljZUBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ljZQ0KPg0KDQo= From nobody Wed Mar 14 02:05:41 2018 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 14AAB126BF7 for ; Wed, 14 Mar 2018 02:05:41 -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, MIME_QP_LONG_LINE=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 (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 M-lm0sI9P_5L for ; Wed, 14 Mar 2018 02:05:38 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 73FA71200C5 for ; Wed, 14 Mar 2018 02:05:38 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id u5-v6so3783816itc.1 for ; Wed, 14 Mar 2018 02:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sEIPFa8iXARvVmAVC4MQ6/VHz7SNkp8TCaKjqzIRPDY=; b=A/ez5qnST+cCTK4CuTfGqmvFPkCSmnVdr2pkZhOy8u5mjk5JUJFdcoAGVYVT3pjM7d MTNqvqGiPQmDCuYi9+KUywEAbQ4eyDdQs6wkWgXcXoAmL6z4SpGVIgfx54pkKBgwTOkW Mhph8Z7VkYsEdRwMHYh4Naxo/hBUPO6DUcovo= 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=sEIPFa8iXARvVmAVC4MQ6/VHz7SNkp8TCaKjqzIRPDY=; b=Pc9IuexiBO8QyLS5/Br0texK/rTGVIlmpqj4+9bNvozCukyzz7avQITbGYRoBQvqyZ TN6QAQ14b1LHD01xo4CEimV9pJlDN93kpCIjtfT8DkwvPDEn3XRTB5SJawCsI92DUSRj 5grWUaERw6z/gzZ1jFQVFjGxxEbLFnik2EkYZOF5bjEwboOt95wGrDDqg6FeBsOeakBn 2jnz6ImSvY70O8CuvGtBZvUxOGSYneVurTwmFr9DwXPmLN7cMOYD5ZrAatrpv9qPQ0fY Y2fDwJtxlOy8eTh61DL8TOowmtzwPTPvaewasEtJbZ+24gwYQQ4BaC1CSBVFT9YbNIr7 vJNQ== X-Gm-Message-State: AElRT7HUcIfA7HwpTEWPMlflJsEAPexEDbBlCEIT+5FkGtCwjxhsafDq Hp5k4IaX/3+vteAsxuBwOAfLptdf1Fw= X-Google-Smtp-Source: AG47ELtb7LLhjOscsvJC6/MpK/aDeifOBmcwL/fWS7/3MYCTQOoW1KT3tJ3+2qaMYFZFapzSv6OpHQ== X-Received: by 10.36.246.135 with SMTP id u129mr1131367ith.116.1521018337789; Wed, 14 Mar 2018 02:05:37 -0700 (PDT) Received: from [10.129.120.69] (mobile-166-170-38-213.mycingular.net. [166.170.38.213]) by smtp.gmail.com with ESMTPSA id o7sm1392205iod.52.2018.03.14.02.05.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Mar 2018 02:05:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Peter Saint-Andre X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Wed, 14 Mar 2018 02:05:35 -0700 Cc: Nils Ohlmeier , "ice@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2D0F5C88-BA63-4945-9537-1A35218C6204@mozilla.com> References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1BC7F7@ESESSMB109.ericsson.se> <6C328929-B686-49EF-A79E-EDDF3AA630AD@mozilla.com> <96978131-7BF8-48A6-A1FA-8C8CF360A05A@mozilla.com> <7594FB04B1934943A5C02806D1A2204B6C1C5628@ESESSMB109.ericsson.se> To: Christer Holmberg Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 14 Mar 2018 09:05:41 -0000 They certainly will be fixed by then. Emil and I will coordinate. Sent from mobile, might be terse=20 > On Mar 14, 2018, at 1:57 AM, Christer Holmberg wrote: >=20 > Note that the draft is on the IESG telechat agenda in the beginning of > April. I think the issues we have agreed exist should be fixed before that= . >=20 > Regards, >=20 > Christer >=20 >=20 > On 14/03/18 10:55, "Christer Holmberg" > wrote: >=20 >> Hi, >>=20 >> Is someone planning to do something (update the draft) related to this? >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >> On 06/03/18 21:33, "Ice on behalf of Christer Holmberg" >> wrote:= >>=20 >>> Hi, >>>=20 >>>>>> Fair enough. >>>>>>=20 >>>>>> The other worry I have with restricting on the emitting side is that >>>>>> effectively ICE and the signaling layer are in a race, which most >>>>>> scenarios the signaling layer is going to loose. That results in ICE >>>>>> agent receiving trickle candidates very likely getting into the >>>>>> scenario where ICE has concluded with use-candidate being set, but >>>>>> still receiving candidates via the signaling layer. If you want to >>>>>> suggest what to do with these late arrivals, e.g. rejecting, then we >>>>>> need some text explaining this scenario any way. >>>>>>=20 >>>>>> So for me it=C2=B9s: >>>>>> - either only describe the receiving ICE agent ignores late arriving >>>>>> candidates >>>>>> - or demanding that the emitting ICE candidate shall stop emitting >>>>>> AND the receiving ICE agent also needs to ignore late arrival to be >>>>>> safe >>>>>=20 >>>>> Not sure what you mean by =C2=B3ignore=C2=B2, but I think the message c= arrying >>>>> the trickled candidates should be explicitly rejected, so that the >>>>> emitting agent knows what is going on. >>>>=20 >>>> With =E2=80=9Cignore=E2=80=9D I mean that the ICE agent should not add t= hese late >>>> arrivals to any check lists. >>>> If the agent would add the late candidate to check lists you >>>> effectively would have implemented continuous nomination. >>>=20 >>> Yes. >>>=20 >>>> Wether you then return on the API side of the ICE agent =E2=80=9COk=E2=80= =9D or >>>> =E2=80=9CReject=E2=80=9D I think is a separate discussion. >>>> And I would tend to argue that the IETF usually does not design APIs. >>>=20 >>> True. But, IETF does design protocols, and I was talking about informing= >>> the peer that the candidates he trickled to me where rejected :) >>>=20 >>> Exactly how it is done is of course depending on the ICE usage protocol,= >>> but the ICE WG spec should define the high-level procedure. >>>=20 >>> Regards, >>>=20 >>> Christer >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>=20 >=20 From nobody Wed Mar 14 09:10:34 2018 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 022A01252BA for ; Wed, 14 Mar 2018 09:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 oVkwfuTZeznZ for ; Wed, 14 Mar 2018 09:10:31 -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 12A30124B0A for ; Wed, 14 Mar 2018 09:10:31 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id a20so19179854wmd.1 for ; Wed, 14 Mar 2018 09:10:30 -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=av6wgjW+k9Ru7fE2suFIG7DIxscH2MaFyqsYV25TWJU=; b=v8+reLtGX2+wcekoFk/DT7jO1SQlBVVtFr7ckPeF7maKo0XunmbpvU9cUODMgC+pqQ qZJp/HoOvP0/JX13pROf5fL38KfqgnpT/w+Kanua7GKty6+KOMpWu6jv1lLLPdNVmgoX 7nOk+0wBBFcaxQdsvX8c0a+lYwJs/81ZikSYXqF8gs/eAUceFFh7MqSk+pKzgNW1hCuZ QG3VuYttqklzJIukP0PNEki5YPVrbOf9EFm4/7F0FyOIjT/9NFymarCyZb2rJultLx19 pp9xcOqKnG/5J2/A3NkObNvqNMaiqhbT8YL+MB1Qo8XUI9YYWrF+/Cxsf+kZ5Q6VmQr2 g8iQ== 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=av6wgjW+k9Ru7fE2suFIG7DIxscH2MaFyqsYV25TWJU=; b=FsExDa3+Rx/0WKXpqC1ac4g6xrcA86wZF/XPuJ7Tyo2IyTJQ9kamVARHzZ2YRZTI2y kCcxXMotBMu/e4jLaYmN/3ODUyTNxaU91+Z98RjvzamFrRrzNinvLV/Mwa3ZXdIujCoc 0ecMElH+BI31PB462ngrdgjqQpaIyuMY0GPtX5QQF7s6PME3Q9T25kIN3cw6KdBOU9c7 RdxN/PuuefydnvrjErCFv+UZAnDiEy3rFGIq9rojaWj1ppm390PKLOMgDtGRO9rpeheu ePjKc+qESibMZgVtm4rvzY79GjrJK3yVuZcycxqSaxVai8M8pU0AsPAlceHqSUMLZ+JB 3X9A== X-Gm-Message-State: AElRT7GTQaE91H6Y/PKfRtAi/aipBeAh2nOTPbCh42cpw3k+C8kF5XyA m4chuQNcVfgrKgv8z2X++ocjJ5uyEh35rt8zY7t7vI2M X-Google-Smtp-Source: AG47ELuvoaJytC+1O/VRv65Mg7rNW51Bcuw7hY8qoEbd4Xejj8bLg4M3LGbNiaiYd2Cao17vHfNjZ4zUuObeRObaypA= X-Received: by 10.28.236.89 with SMTP id k86mr2331485wmh.82.1521043829129; Wed, 14 Mar 2018 09:10:29 -0700 (PDT) MIME-Version: 1.0 From: Peter Thatcher Date: Wed, 14 Mar 2018 16:10:18 +0000 Message-ID: To: ICE WG Content-Type: multipart/alternative; boundary="001a1146ddd8200fed0567619d60" Archived-At: Subject: [Ice] IETF 101 ICE WG meeting cancelled 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, 14 Mar 2018 16:10:33 -0000 --001a1146ddd8200fed0567619d60 Content-Type: text/plain; charset="UTF-8" Since there was nothing to talk about, we have cancelled the ICE WG meeting at IETF 101. --001a1146ddd8200fed0567619d60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since there was nothing to talk about, we have cancelled t= he ICE WG meeting at IETF 101.=C2=A0=C2=A0
--001a1146ddd8200fed0567619d60-- From nobody Wed Mar 14 14:35:42 2018 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 80BE8127775 for ; Wed, 14 Mar 2018 14:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 0L2dHQwliuOv for ; Wed, 14 Mar 2018 14:35:39 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 EE8E1127869 for ; Wed, 14 Mar 2018 14:35:24 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id z12so6258038wrg.4 for ; Wed, 14 Mar 2018 14:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:subject:from:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=LxB/BGrcq0miq8S4CrMosiCvxxVOZZ8r0d/hP4QKAWI=; b=QOkr6Co7YD7Q4Ydaiclw4JuKzkQgrlgXVuaSV2J34AWX1cYsxYjOeU3q5AJX4OnmAT 9O151A++E5+xQCVTUqEVmU49ziRRMxE6p5ancnHm5YhI8t0elwQS0wqRV+RXXLFwcFmB bixsIMhCizH0F2nracZosiKx289zKZqlf0vxWG76T85Qw4B46ku0ra180Hkn2ef3jjDL bPqHoL6Dv1PXJ4UUvp+b1+yXOUe578gexh1+p8OCjpW/nVsUjGogktG48gS4eLB+KM8t 0oXc6ulcrDRF9EEQUHSQJw6rfL9dAK/VlaPtpd9/t1MNeQjKbo0T7bxEQ1mcCHZSdGlY Grow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:subject:from:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=LxB/BGrcq0miq8S4CrMosiCvxxVOZZ8r0d/hP4QKAWI=; b=MUDyazqHHtmE4lRRb8ww7vSYHjPR1opXbBUdEVys24yfPJX88HPvLB6M9c5T19eMUe OTKYYwyon0koefvsxmZT0cauPHpuqWRurV95mUvMqHobWcsJMqOenRmmE3oWX2UAt1MQ 252HaA8OF5UaFhaBQmXYrNROP3Lojj/X1IxSf2WFj5I478T7eRgX1VBVBoCuFlTzLJuR N3+ogj8scHlgIL5aMbUhNk7hLn1ZzEPiCTg1ypo/DiP2UpyM8obRDwHlFKuhQ4xbauGO v8/eRhJ3HR+7XgSpsVW4dovkTgSCSVFg77U3dZJZKcsPLanjWPKO/ps04fxE8BY82iX+ GLSg== X-Gm-Message-State: AElRT7EYYnrwwngETwyK7wmzd9pxOw0KjfPeZRG2dLQlwR24uxqIIFBg ncdLvIqZUHhBJecfl49U4FYCKg== X-Google-Smtp-Source: AG47ELuSz32xnfvBM01c0vpkVt4OpTiVRhSFuZhwmGDcx38yqrjNrDliOZzOXpjFBl6KER9Xgn1Rfg== X-Received: by 10.223.148.194 with SMTP id 60mr5375357wrr.195.1521063323222; Wed, 14 Mar 2018 14:35:23 -0700 (PDT) Received: from ?IPv6:2003:cd:6bdb:4300:4d7d:75b9:d0c3:8ab7? (p200300CD6BDB43004D7D75B9D0C38AB7.dip0.t-ipconnect.de. [2003:cd:6bdb:4300:4d7d:75b9:d0c3:8ab7]) by smtp.gmail.com with ESMTPSA id n23sm3821851wra.14.2018.03.14.14.35.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Mar 2018 14:35:22 -0700 (PDT) To: ice@ietf.org From: Lennart Grahl Message-ID: <33e5485a-c578-0d37-1dc9-e0bcae0dcfaf@gmail.com> Date: Wed, 14 Mar 2018 22:35:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ice] RFC5245bis loopback interface 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, 14 Mar 2018 21:35:40 -0000 Hey everyone, I have a quick question. RFC5245bis section 5.1.1.1 mentions that... "Addresses from a loopback interface MUST NOT be included in the candidate addresses." My question is rather simple: Why? If I'm connecting to the same device, loopback seems perfectly fine to me. Cheers Lennart From nobody Wed Mar 14 18:48:40 2018 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 A761F126D45 for ; Wed, 14 Mar 2018 18:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 doSUdBtrLn8k for ; Wed, 14 Mar 2018 18:48:37 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::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 140541242F7 for ; Wed, 14 Mar 2018 18:48:37 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id u13-v6so2818807plq.1 for ; Wed, 14 Mar 2018 18:48:37 -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=Jj4V9EdrenS1ESO0DwVbczp4nN380iJ+S6StkVRmu8U=; b=OctglM5EoTbyW9oBdJ38jte0hbZQ3miuxhs2/BDXsOgS4GBcEwjpfnscRP8KSJLg7C H1kbF7e1P1nquYwNOp+ZGwmDX2Bn9hOuCzC8VrDXZzqyZx2OgsMLeQol+p+tHZ+wX4w/ aiAHc3K4XQxy2/OrG+yr41+k7w+FElqSsUwes= 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=Jj4V9EdrenS1ESO0DwVbczp4nN380iJ+S6StkVRmu8U=; b=RsU0hL2hybRsFCNtA9tyym/fZDdneXhI40lpL01Ejig4ypMu8/P7KewtfAS4PQ0fj8 JvNMiLeHbuGZBPaHXofDFB9Yknfahg2otLHpb0KXkg6zUI1mJYTpzpzL/a+ElgeHONCo wuBG7Qw1LgG9IHdcYgcYWOfQLJ67iTQmi6t7d5SZjUOIRY7KDmBi0g+LlvD+JFi0cNoH m+y5R7Sr8zUh10Oi3m3sNVQzfP6QvUd8Zp7kJpMFHqMY8TSbvQ0kc0ekFEp8DiUUj0/a Ga1IRA24t/9kW2Ilti9x77lA5vsA0nYRtdk+oRXt8sl+uttibu2o21dtXC4xJXPHLSV/ Sk4g== X-Gm-Message-State: AElRT7H4iF8sHgVSgWg/h5DdFUMiMUSkUh2Gi0Rs+O5cTn/6ol/H2UtU 3aybFH2hFosoAh2f0mpO7Wzn2A== X-Google-Smtp-Source: AG47ELvD/qOqOj0Xdqxop74Yuw2w3hdgh2lr2X7azmFlCOWCkI3A7DDV9vZQD1J1FUPaSEbIBHZpIA== X-Received: by 2002:a17:902:7716:: with SMTP id n22-v6mr410927pll.268.1521078516525; Wed, 14 Mar 2018 18:48:36 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:706f:1ecc:fb67:d21e? ([2601:647:4600:3f31:706f:1ecc:fb67:d21e]) by smtp.gmail.com with ESMTPSA id q15sm6141604pgv.49.2018.03.14.18.48.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Mar 2018 18:48:35 -0700 (PDT) From: Nils Ohlmeier Message-Id: <8A50F02D-EB7F-4B91-A745-F218D67EDF2F@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_CEA767AD-A842-4592-81CF-19487BC476D9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 14 Mar 2018 18:48:32 -0700 In-Reply-To: <33e5485a-c578-0d37-1dc9-e0bcae0dcfaf@gmail.com> Cc: ice@ietf.org To: Lennart Grahl References: <33e5485a-c578-0d37-1dc9-e0bcae0dcfaf@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] RFC5245bis loopback interface 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, 15 Mar 2018 01:48:39 -0000 --Apple-Mail=_CEA767AD-A842-4592-81CF-19487BC476D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 14, 2018, at 14:35, Lennart Grahl = wrote: >=20 > "Addresses from a loopback interface MUST NOT be included in the > candidate addresses." >=20 > My question is rather simple: Why? If I'm connecting to the same = device, > loopback seems perfectly fine to me. Not that I know/remember the reason. But each additional candidate comes = with costs of trying another candidate pair. Since loopback has very low chances of succeeding it makes sense to = avoid waisting cycles on this. BTW you can turn on the loopback interface in Firefox ICE via a user = prefs if that helps in your case. Best Nils Ohlmeier --Apple-Mail=_CEA767AD-A842-4592-81CF-19487BC476D9 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----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlqp0PAACgkQY2o/VmzJ +KHq8Q/+JVbZZAP3CFaWXYhQD5vj+IXB9f958pLt5ZL+ofv0QWdkA4DDtANqGs4H 3I+8lK5V1PaC/1JaqlyXCE6yTRwfRshv8UTs+qj87nhoTFeWgfVAfTO3uw+t6E6Z DeQYx3adgpOlWTm8gIq4/UCuosZhGA56rW1sThAU/dfUUIf3nPZ6jC2ee5/Ir1O6 fMtoj9C+PXVVL/emOFEhsvmdayiuWASKkzztLHEzbGpaEv5wUzCkACvwA2MC2FMe XTWgb3gSV+blupeKPy/x4LqpHlIVizA8TW5GmlL9LQ2jVWO1oPA7iRTP0iKMdHHD pVvGM2BXnCFP6rV5RbBrqHFR+jsABEppTXbe5c8ZnXvGsWrDVq2c5KahG3lsh47d iuPlh0oVXi/J/UwFkuwM+6nw3T6PtDF+1toLFVydEZmQdBhhZlYjhg51wDAGppAW yDObNk/+qUOUMxUzh6GQ7U6vFCkuEW+F3zm7tgXh2ANM3RG356UiS3tIh78CXzLv YSmhTu5Y9FfkGFStwv3foxDrIZEGgUgyTtsvhbxJrtZYNTaOp+1dgQCTl9aalydF t9MW6HHm7nJ1iu84xUACbuxpVAO95ebsfp6A5FPq4K6BWUhwPIX4rPCPpPn2LPo7 tyBDPDo1hQO3AWJQNxNcp0Dg+2SJIOHAsq/LLbHBWc5zSN0YkCk= =9UmY -----END PGP SIGNATURE----- --Apple-Mail=_CEA767AD-A842-4592-81CF-19487BC476D9-- From nobody Thu Mar 15 02:09:40 2018 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 8660712D87E for ; Thu, 15 Mar 2018 02:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 OeE4m0OSDzcm for ; Thu, 15 Mar 2018 02:09:37 -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 B4F3D12D87D for ; Thu, 15 Mar 2018 02:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521104974; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xzBK+n7fNWWHd35gNBh6pe6aB+4fN3V23p/p/Ref7GI=; b=aZwNHNnNBRJslM7zrJE/sF3a+fW0voWnQhMfKiFp5IHa+qf8O2OkTUiqksa7Ng5y kYRriEubLsv/hiA7pW9sYGUr8MQIpHSH2mVOwGHJYD+epr8sOrlSXHjG7LpQdJBh IzCtWcQ2Sgf6HCMABp1pd0orKWssTkJe5UH8njmg2Xk=; X-AuditID: c1b4fb2d-87c029c000005540-19-5aaa384e678d Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3F.E0.21824.E483AAA5; Thu, 15 Mar 2018 10:09:34 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0382.000; Thu, 15 Mar 2018 10:08:48 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Nils Ohlmeier , Lennart Grahl CC: "ice@ietf.org" Thread-Topic: [Ice] RFC5245bis loopback interface Thread-Index: AQHTu9xpLS3ku/nH2EOHQOntihlhsKPQdvUAgAB7AYA= Date: Thu, 15 Mar 2018 09:08:47 +0000 Message-ID: <01A13CC8-66D1-4B95-8D4C-8EFA08A8C5C0@ericsson.com> References: <33e5485a-c578-0d37-1dc9-e0bcae0dcfaf@gmail.com> <8A50F02D-EB7F-4B91-A745-F218D67EDF2F@mozilla.com> In-Reply-To: <8A50F02D-EB7F-4B91-A745-F218D67EDF2F@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.234.218.122] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <34D89AE65F0C64439A6356B6E8825E21@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7iq6fxaoog92TTC2+Xai1+HB8KavF 9XmTGR2YPXbOusvusWTJTyaPvgNdrAHMUVw2Kak5mWWpRfp2CVwZa9obWAr+cVRMupbTwLiE vYuRg0NCwETi5wTtLkYuDiGBw4wS0569ZoRwljBKrLi2k6WLkZODTcBeYvKaj4wgtohAiMTr r8dYQJqZBRQlXu5VAwkLCxhIrJ72jB2ixFBibcdcVgjbSmLm06dgNouAqsTGYzvZQGxeoJEv 3k8FGy8kUCixtusi2D2cQPHdx0RBwowCYhLfT61hArGZBcQlbj2ZD2ZLCAhILNlznhnCFpV4 +fgfK4StLLHuwRNGiHo9iRtTp7BB2NYSz75fhpqjLbFs4WtmiBMEJU7OfMIygVFsFpIVs5C0 z0LSPgtJ+ywk7QsYWVcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBMbYwS2/dXcwrn7teIhR gINRiYe3T3NVlBBrYllxZe4hRgkOZiUR3vuFK6OEeFMSK6tSi/Lji0pzUosPMUpzsCiJ8570 5I0SEkhPLEnNTk0tSC2CyTJxcEo1MOZPqAh8s+571NWtPx5WXxQvX7JAW2xz2Wmb03Xxc9ZP Lp62SFyi0baQ4VDtoZKINPdI4eYgL302Ja5VR1zuWjZH/J7damrLc756gbmX6Fumm3fsprpZ nF20fde/A3oTq3enfxWee82r+/UNw6eTAxjy5TO5g9xibae/1X4pn3nhlGTOorlSEUosxRmJ hlrMRcWJAC/EYEKtAgAA Archived-At: Subject: Re: [Ice] RFC5245bis loopback interface 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, 15 Mar 2018 09:09:38 -0000 > On 15 Mar 2018, at 3.48, Nils Ohlmeier wrote: >=20 >> On Mar 14, 2018, at 14:35, Lennart Grahl wrote= : >>=20 >> "Addresses from a loopback interface MUST NOT be included in the >> candidate addresses." >>=20 >> My question is rather simple: Why? If I'm connecting to the same device, >> loopback seems perfectly fine to me. >=20 > Not that I know/remember the reason. But each additional candidate comes = with costs of trying another candidate pair. > Since loopback has very low chances of succeeding it makes sense to avoid= waisting cycles on this. Yes, that's pretty much the reason. Also giving non-local endpoint loopback= address can result in interesting behavior. And you can still connect on t= he same device via the other addresses (link-local, autoconfig, etc.). Cheers, Ari=20 > BTW you can turn on the loopback interface in Firefox ICE via a user pref= s if that helps in your case. >=20 > Best > Nils Ohlmeier > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice From nobody Tue Mar 20 13:49:06 2018 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 B1B71128959 for ; Tue, 20 Mar 2018 13:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 5RWKHOmGIdv7 for ; Tue, 20 Mar 2018 13:49:01 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 906F6124D6C for ; Tue, 20 Mar 2018 13:49:01 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id r18so4040508ioa.1 for ; Tue, 20 Mar 2018 13:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=iApyAgYfA85L4DyeSiZj0Li/bp3uxv3YdZOnPGCrCPc=; b=STuSERATh9wKoAo02cEyyf8KzaMWCsaC5QItkGwgXx0E7XqhKs1Az5xqcn9AXGUHpJ 4yXcRD3xFVkQt20+ldFLp53TNwyw+aO/BDT2UQcbVNtja0GG/+Cm+jJS0ouZvF0fmNa4 l0mUQ3U2mq2+Av3asTHSWx3/6JKOvM4eN1TQw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=iApyAgYfA85L4DyeSiZj0Li/bp3uxv3YdZOnPGCrCPc=; b=OjxJ7gXzOxYU41Yyi9RgUqeOjXP+QbaYebg/0w/l2+GZ78IebUxV5Py90sEhqS8zHN 7Y1xqu6Gzv7jZvmWJQFoqZ7rv3p5k/HmLniA882jmnFgS91kRlTEyBksbVsEJ2xAiAqw UKVR3bvzCpUTlUEDDQb0iL+qaVeaBPYUuk28gUMqIQhQdx69C/JddjFUmmCMqZXrsGcF fnF3SsjmmX3Kl5V8cFCTXCbdi8Rw6Rwn7/+kF0awNa8g3DXPdc8OgN4NpdNknyQvCL0C BSCaRiFbXwvRT7JLQD0H1K/tIXOKHVMEquM3lU1uDEqE7pdU7M9uBaJvRwGLm3ZdPfSB OhbA== X-Gm-Message-State: AElRT7GK/8NzRw5K8VfaO5GNub7go5ZWsovqIeLTwiCXXTnA8IdnpYuS XDLlZIX+d7GW7arf1Vyj2cqDSw== X-Google-Smtp-Source: AG47ELtDczKZ9/jWkzTcUrUsA9HMjt/mQT847ddBX0zoB5jM1H400b3fLnnrP/VUHQWNi5c64XuSKg== X-Received: by 10.107.58.11 with SMTP id h11mr18383253ioa.283.1521578940895; Tue, 20 Mar 2018 13:49:00 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id f10-v6sm1739603itb.40.2018.03.20.13.48.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 13:49:00 -0700 (PDT) To: Christer Holmberg , Emil Ivov Cc: "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: Date: Tue, 20 Mar 2018 14:48:58 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MRtLdtwDmUBz7irgC6Hgy6ryFW6X8nZII" Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 20 Mar 2018 20:49:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MRtLdtwDmUBz7irgC6Hgy6ryFW6X8nZII Content-Type: multipart/mixed; boundary="kyVWplSUB3csRJgs7kAJApauenf0CPs63"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , Emil Ivov Cc: "ice@ietf.org" Message-ID: Subject: Re: [Ice] Trickle: A couple of questions on section 7 References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> In-Reply-To: --kyVWplSUB3csRJgs7kAJApauenf0CPs63 Content-Type: text/plain; charset=euc-kr Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/6/18 6:06 AM, Christer Holmberg wrote: > Hi, >=20 > Congratulations to the added human!:) +1! >>> We can for sure have a call, but I think this requires a bigger audie= nce >>> than you and me :) >>> >>> I assume that the authors should participate, and also individuals li= ke >>> Nils O, Taylor B, Peter S-A etc. >> >> As much as I=A1=AFd be trilled to have any number of chats in such lov= ely >> company, I just wanted >> your help on finding the right sections in bis so that we would simply= >> update the coherence of the document. >> >> Let=A1=AFs see then if further discussion is necessary after that. >=20 > Based on your input in the previous reply, I think I understand where Q= 1 > comes from. I still have an issue with Q2, though. See below. >=20 >>> Q1: >>> >>> Section 7.1 says: >>> >>> =A9=F8The ICE specification [rfc5245bis], Section 6.1.4.2, specifi= es that >>> an agent will terminate the timer for a triggered check in relatio= n >>> to a check list once the agent has exhausted all frozen pairs in t= he >>> check list. This will not work with Trickle ICE, because more pai= rs >>> will be added to the check list incrementally.=A9=F7 >>> >>> Exactly what procedure in 5245bis dos this text refer to? >> >> At the time of writing that was section 5.8 in 5245 and specifically t= his >> text: >> >> * If there is no such pair: >> + Terminate the timer for that check list. >> >> I am not able to match that to text in 5245 bis and it probably went >> away last year when we were redoing the states. We'd need to resync >> it. Want to have a quick call offlist? (I suspect we can probably just= >> drop this after the latest changes we did in Prague last year). >=20 > Ok, I think I get it now. >=20 > In RFC 5245 (and earlier versions of 5245bis) we had a *separate* timer= Ta > for each check list. So, once there were no more checks to be done for = a > check list, the timer for a given check list was terminated. >=20 > In 5245bis, however, we only use a *single* timer Ta for the whole chec= k > list set, and whenever Ta fires we check the next Running check list in= > the check list set. So, non-Running check lists will automatically be > skipped. This is described in section 6.1.4.2. >=20 > So, I am not sure whether you need to say anything in trickle, because > whether a check list is checked or not is taken care of by the 5245bis > procedures. That seems reasonable and I can adjust the text accordingly. >>> Q2: >>> >>> Section 7.2 says: >>> >>> =A9=F8When a check list is set to Failed as described above, regul= ar ICE >>> requires the agent to update all other check lists, placing one pa= ir >>> from each check list into the Waiting state and thereby effectivel= y >>> placing all remaining check lists into the Running state.=A9=F7 >>> >>> Exactly what procedure in 5245bis dos this text refer to? >> >> Exactly the parts that we discussed and agreed to change in Prague >> last year. I think this part is no longer necessary given how they are= >> covered by 5245bis. >=20 > But, are you saying that the text above is according to 5245bis? I can't speak for Emil, but IMHO it's best to remove that text so the question is moot. Peter --kyVWplSUB3csRJgs7kAJApauenf0CPs63-- --MRtLdtwDmUBz7irgC6Hgy6ryFW6X8nZII Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqxc7oACgkQZWGMGH9o FKkr8w//Y5zfQgA1MVBX4SlTSHUcviigYiN/JvqRlEq9+Hio4zHEjWH5mF+/suJY Eea2Huk89Ieh4tTXOesS4kl90w9v8RlWns20U9tglVU9iU2mu7Sh47zB7/zR5Ke5 jPeXCVv3OHKAr/vcWqQc6sdWk5gMVRn7vUvb8/ric4yqppcplCsfjOprpb6FiJnv /hf7pZyfQ9FOOuuuoCyI4rSEvF65dISGJzhudWv1pvsRHFT+meGGbOqaGa1vpaGh zQBzTnDH0UdMzI2EVoL8+0aQPFKlI3mXQGoMZGwzdxBoFKoPM3eN54/Q6px7fNXg vqxdQcJxFL0//YUBnUxlLY0C1ssVz3yfBsaq13gGaV4ljyQ7ukIaIbcLc0T4lyb8 sCpzQYIKrQnuq4mL/K3syADg52gRWIEGif92eqzCGkNxg7RSimUa4YJleAPAi6SZ KCa6hmtBeejn74IjePmU243D2w8UVTIG7kM2uK3etM52ULdWUdCzqzCxkO7ymFix 9NRHAtnAaXFJ62j7/p9bIsTxCZUNYl+JdWuHHWIPHiEwvNNsJ0BUkxp8bqSE0j5b nPNFCS8CXbIrHu43seP0umSirRLNfM7I08NMHkU/n/19SmuME/PfGFNa3Ma/TYKl FtTHtQsY9mAUbeQe88fWn6brbjWFX6fABuu9nhleYKkt4kl5Fl8= =ImOA -----END PGP SIGNATURE----- --MRtLdtwDmUBz7irgC6Hgy6ryFW6X8nZII-- From nobody Tue Mar 20 19:30:34 2018 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 7882712D7F4 for ; Tue, 20 Mar 2018 19:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 FOpIW96XrhfY for ; Tue, 20 Mar 2018 19:30:30 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 B01BA12D7F0 for ; Tue, 20 Mar 2018 19:30:30 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id w3-v6so4991760itc.4 for ; Tue, 20 Mar 2018 19:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=GW7gCCmrcqo7gFihdNFa4FmdPuI4B/Lz8Ki8ZPiKi0o=; b=ciwcKclYRdg1NdTnLqbpt22BMKhiDL1VufqVIESyqGyO6nO3foUpUkQcBRLLnEHJsj R+NJApnUZD0UB/6e+jiLiq6AEhd20p1vpzYpos4JVKBFh43jH47fdG5axpnrPH62utTC fVJwx3rLAIdGem7ni+PRmnzH4uOXtzFWU7TU0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=GW7gCCmrcqo7gFihdNFa4FmdPuI4B/Lz8Ki8ZPiKi0o=; b=YxsiB1AZNZfvKarOdG5rbMJfYoT/FSiNm8IOY8qDPr4owc4RqCrQlAx1fB1heWbf6L 6AgJ5IAAY06b4RRsV1+5jczp2TkdfuAAy1febGKZXLtb1LmUON/0L6Ct3aO+l54ba2yk s2JQabkPwISjnJ8OLIaKzYz3K4XA967VOmQD+Ef6AcjUqSl83J1VJn1Zq4rX6hh2uIGO C7jC9u51jI+YuUhoSpbdS2na4aNO0nd0yPQo4upE91XBHl2gRbMjH/bfnGDaa15J0Smx V4TDwopunmtdyoza/oOo6MhlVXgLsTAqizqvtPt9bo6KzN+YCByP3wIBpuPkNaTNNNso vVOQ== X-Gm-Message-State: AElRT7FfwyG0YY30qKfOPZildqnTTbuZmWD4JJ8rlH7fELCwzg3CCVsw BRnPo0hPoNvzRanmQY2TMJWMBR1ZT+4= X-Google-Smtp-Source: AG47ELuks7VUg0WV2BhqWVOW5GjlaQMZ9VthELCe6fBGYcBp6zbRDua12CqU0v1WUgeWqqYqoNLy5g== X-Received: by 2002:a24:6995:: with SMTP id e143-v6mr2196062itc.119.1521599430045; Tue, 20 Mar 2018 19:30:30 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id w79-v6sm2015593itb.26.2018.03.20.19.30.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 19:30:29 -0700 (PDT) To: Christer Holmberg , Taylor Brandstetter Cc: "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C1B8FEE@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1B9583@ESESSMB109.ericsson.se> <70af5888-1927-1f62-ba3f-8d6fd4614c87@mozilla.com> <7594FB04B1934943A5C02806D1A2204B6C1B9921@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: Date: Tue, 20 Mar 2018 20:30:27 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="B2wfQzqSyZmSpJoZ12tCEFg1KAX4yJVZ8" Archived-At: Subject: Re: [Ice] Trickle: What is Section 16 about? 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, 21 Mar 2018 02:30:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B2wfQzqSyZmSpJoZ12tCEFg1KAX4yJVZ8 Content-Type: multipart/mixed; boundary="c8mpO8TSh9G0lqzjVExa6NLUKxTfPh61r"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , Taylor Brandstetter Cc: "ice@ietf.org" Message-ID: Subject: Re: [Ice] Trickle: What is Section 16 about? References: <7594FB04B1934943A5C02806D1A2204B6C1B8FEE@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1B9583@ESESSMB109.ericsson.se> <70af5888-1927-1f62-ba3f-8d6fd4614c87@mozilla.com> <7594FB04B1934943A5C02806D1A2204B6C1B9921@ESESSMB109.ericsson.se> In-Reply-To: --c8mpO8TSh9G0lqzjVExa6NLUKxTfPh61r Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/2/18 12:36 AM, Christer Holmberg wrote: > Hi, >=20 >>> ICE agent does not know what candidates it will eventually get. >> >> I think this is the root of our misunderstanding. But can you clarify,= do >> you mean that the ICE agent doesn't know what candidates it will >> attempt to gather? Or that it doesn't know whether a pending STUN >> transaction will fail? >=20 > The agent probably knows what candidates it TRIES to gather. But, as yo= u > say, a pending STUN transaction may fail. The STUN/TURN server might be= > overloaded, or out-of-service for some other reason. >=20 >> If you're talking about the former case, then I think we have a >> different concept of what the "ICE agent" is. I interpreted the ICE ag= ent >> as being responsible for candidate gathering (including deciding which= >> candidates it will attempt to gather). >> >> If you're talking about the latter case, then I agree there's a questi= on >> of "how long do I wait for the pending STUN transaction before giving = up >> and trickling the candidates I have?" Which I assumed would be an >> implementation choice. >=20 > Perhaps, but then we need to document it. Based on our discussion, I > assume =B3stream order" actually means =B3foundation order throughout a= ll > streams=B2. I.e., you need to trickle all available f1 candidates befor= e you > trickle any f2 candidates, before you trickle any f3 candidates, etc et= c. While puzzling over this topic, I noticed that Section 5 of draft-ietf-ice-trickle-17 says: A Trickle ICE agent initially considers all candidate pairs in all check lists to be frozen. It then inspects the first check list and attempts to unfreeze all candidate pairs it has received so far that belong to the first component on the first media stream (i.e., the first media stream that was reported to the ICE implementation from the using application). If that first component of the first media stream does not contain candidates for one or more of the currently known pair foundations, and if candidate pairs already exist for that foundation in one of the following components or media streams, then the agent unfreezes the first of those candidate pairs. By contrast, Section 16 says: One important aspect of regular ICE is that connectivity checks for a specific foundation and component are attempted simultaneously by both agents, so that any firewalls or NATs fronting the agents would whitelist both endpoints and allow all except for the first ("suicide") packets to go through. This is also important to unfreezing candidates at the right time. While not crucial, preserving this behavior in Trickle ICE is likely to improve ICE performance. To achieve this, when trickling candidates, agents MUST respect the order in which the components and streams appear (implicitly or explicitly) as they have been negotiated by means of the relevant candidate information. Therefore candidates for a given component MUST NOT be conveyed prior to candidates for a component with a lower ID number within the same foundation. In addition, candidates MUST be paired, following the procedures in Section 8.1.1, in the same order they are conveyed. The concepts of "stream order" here don't exactly line up - in Section 5 the relevant consideration is the order of reporting streams from the using application to the ICE agent, whereas in Section 16 it's the order of negotiating streams between the local and remote ICE agents (perhaps from the inititiating agent to the receiving agent?). My inclination is still to remove the concept of stream order, unless Emil convinces us it is needed. Peter --c8mpO8TSh9G0lqzjVExa6NLUKxTfPh61r-- --B2wfQzqSyZmSpJoZ12tCEFg1KAX4yJVZ8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqxw8MACgkQZWGMGH9o FKnxVBAA1dZkLStvMeaIfrugm72TI1OFrlCe4kUpxAeGJTiHorI8egeyxCBCKuDD Rxr4yag4zufxQaJQa5deq2Gb4VAZSaD3ymW5G0Y2t9kJwcoWCThpAKEioF+/t7ja XH4EYgHo/aiRk55AlnJbRDJWZNNR4NC4od9ko/PcUnjAGcQuPGfbaSG26Rnge3Nf ublIhH8KlptBu2yIY4iUg45TdgbaoVIzw+N6chOxAbAO3FQHGPAPBGm5/jsOv7nN xVLCmSfTuXc6oEHqkvjv6SBibmyZ4m/kr0yY3jGFxsPOsTdpF81bV5a3i1UDShJ5 PQgg0P+cn5PcmGzkHJzLc+TKRiinIHzeCf8ZFXWAyfrjCDQldVpjNwbXVA9XqY1z u8C8/eHkvmpO3AdekGm416qo+wkPU6/Z/uPWQxmKz2byja6/jexvtAwWn7SBjWVn zH6fGRkGKFMKU7xeBGwkiB+kX+v0ACiW7RIrISXTrjXaUcN7tg7V8MafBunf/aG4 M5b2ip+XBNIoG26md1aWRlf+T5aDv6H1aP/3qLXn2f4FqTsGaf9fuR21vA82whoo 4YieuFAyQ66Xe963YPg+rC+g3y46I+zxCB+ZlEFogGvnEroF2gv5S3wfKXZJcCXu 0axJeEyOIKPgazVpxlCxrffEeDmy7Ql1WOJC7cTsglucl/xfJoE= =fQwR -----END PGP SIGNATURE----- --B2wfQzqSyZmSpJoZ12tCEFg1KAX4yJVZ8-- From nobody Tue Mar 20 20:00:34 2018 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 9C2B9127876 for ; Tue, 20 Mar 2018 20:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 aX_yVERojWuZ for ; Tue, 20 Mar 2018 20:00:29 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4AFF124205 for ; Tue, 20 Mar 2018 20:00:29 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id x20-v6so2929279oie.2 for ; Tue, 20 Mar 2018 20:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to; bh=YDiYpxFAgrSXrrCXcUO1S57Ye0X1/2eAVgW1phIlvPc=; b=IOji3DHlTxJ3GTxSOGklDmVRseNW22OxqEmCwBAHxXhUbFmapynpHz20W3c0KVxW6y wZugkBGPapOTc7iM0XbHOuEQyFbn5sqUAPwXtJzJOQ4HB3suQmDmXKxk2HsWJpGVuVxS L5TjL8CFoG8QBxam5e4nc9FPZaYY8JIEdw6vc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to; bh=YDiYpxFAgrSXrrCXcUO1S57Ye0X1/2eAVgW1phIlvPc=; b=oElI/4dMTTBxRYlK29pQP2bgSklSOZh9UQ2jm2kJVO3ZxIMqWst6Gob74MGrWh+8Dw vzGmLkGVIRAUByqCTzZF+xOLycou8BkHVlkuL5OArDpHliGSUW7CoTCReHRwthcGyNl/ Ii6oJZCzBGhWQgoLcPFXjhtZqfD7M1oubGJpDohtb5YsA1cLCzl1+GanO66XodqawqsJ LTjOFR5TCBo1d8WXb2JcgnmEGLY+TLmGwLOIfq9n/Iw9ThXUS7ZqpyQuKoY68J2jw1qJ t2aI0gLFoe0QBUflbQEZUfbv0Ns9YcYQHo2urvSB82qc6xgXm7sTmfrYU3yM4o/6OnuT Nuhg== X-Gm-Message-State: AElRT7FUqfELDtMmQgpFz0iwKbcsPunQAWe4dUnZxZQ45JZ4QDXx38z1 itZ/DbqqlJk0xw1TznNXxr52Rg== X-Google-Smtp-Source: AG47ELtwRPHTV/u1cEi/SBrV0dE6zpwuLBmQTcZUH8elvxW2Poycpp0KASIkQ3rhEg3r1aPe5Pb+sg== X-Received: by 10.202.1.199 with SMTP id 190mr11364684oib.80.1521601228981; Tue, 20 Mar 2018 20:00:28 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id 66-v6sm1851048otv.66.2018.03.20.20.00.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 20:00:27 -0700 (PDT) From: Peter Saint-Andre To: Christer Holmberg , Emil Ivov Cc: "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> Message-ID: <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> Date: Tue, 20 Mar 2018 21:00:26 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EdEhuujGuVlhtgTvDYfVEKi58wVi1SrQO" Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 21 Mar 2018 03:00:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EdEhuujGuVlhtgTvDYfVEKi58wVi1SrQO Content-Type: multipart/mixed; boundary="WIrsqqEptsj5p6aRSd3GAxbTgDSEzAnno"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , Emil Ivov Cc: "ice@ietf.org" Message-ID: <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> Subject: Re: [Ice] Trickle: A couple of questions on section 7 References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> In-Reply-To: --WIrsqqEptsj5p6aRSd3GAxbTgDSEzAnno Content-Type: text/plain; charset=euc-kr Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/20/18 2:48 PM, Peter Saint-Andre wrote: > On 3/6/18 6:06 AM, Christer Holmberg wrote: >> Based on your input in the previous reply, I think I understand where = Q1 >> comes from. I still have an issue with Q2, though. See below. >> >>>> Q1: >>>> >>>> Section 7.1 says: >>>> >>>> =A9=F8The ICE specification [rfc5245bis], Section 6.1.4.2, specif= ies that >>>> an agent will terminate the timer for a triggered check in relati= on >>>> to a check list once the agent has exhausted all frozen pairs in = the >>>> check list. This will not work with Trickle ICE, because more pa= irs >>>> will be added to the check list incrementally.=A9=F7 >>>> >>>> Exactly what procedure in 5245bis dos this text refer to? >>> >>> At the time of writing that was section 5.8 in 5245 and specifically = this >>> text: >>> >>> * If there is no such pair: >>> + Terminate the timer for that check list. >>> >>> I am not able to match that to text in 5245 bis and it probably went >>> away last year when we were redoing the states. We'd need to resync >>> it. Want to have a quick call offlist? (I suspect we can probably jus= t >>> drop this after the latest changes we did in Prague last year). >> >> Ok, I think I get it now. >> >> In RFC 5245 (and earlier versions of 5245bis) we had a *separate* time= r Ta >> for each check list. So, once there were no more checks to be done for= a >> check list, the timer for a given check list was terminated. >> >> In 5245bis, however, we only use a *single* timer Ta for the whole che= ck >> list set, and whenever Ta fires we check the next Running check list i= n >> the check list set. So, non-Running check lists will automatically be >> skipped. This is described in section 6.1.4.2. >> >> So, I am not sure whether you need to say anything in trickle, because= >> whether a check list is checked or not is taken care of by the 5245bis= >> procedures. >=20 > That seems reasonable and I can adjust the text accordingly. By which I mean: remove Section 7.1 entirely. >>>> Q2: >>>> >>>> Section 7.2 says: >>>> >>>> =A9=F8When a check list is set to Failed as described above, regu= lar ICE >>>> requires the agent to update all other check lists, placing one p= air >>>> from each check list into the Waiting state and thereby effective= ly >>>> placing all remaining check lists into the Running state.=A9=F7 >>>> >>>> Exactly what procedure in 5245bis dos this text refer to? >>> >>> Exactly the parts that we discussed and agreed to change in Prague >>> last year. I think this part is no longer necessary given how they ar= e >>> covered by 5245bis. >> >> But, are you saying that the text above is according to 5245bis? >=20 > I can't speak for Emil, but IMHO it's best to remove that text so the > question is moot. Looking at this further, I realize that I have a question about 5245bis: according to ICE Core, is it possible to have an empty check list? By my reading of Section 6.1.2, a check list must have candidate pairs in it. However, in Trickle ICE we can have empty check lists. That's at least in part what Section 7.2 of the trickle spec is about. Peter --WIrsqqEptsj5p6aRSd3GAxbTgDSEzAnno-- --EdEhuujGuVlhtgTvDYfVEKi58wVi1SrQO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqxysoACgkQZWGMGH9o FKkwkBAAw2Or/lj36Ut4QhgBQl1VDjRwF18o4FJwM1yRTN2RFaGm33ur/xXpkRkk +UVeNt8qGXXM6CYrquEPyMLkybN1qTMJ8UzlXRIfzIn7JmYUL0bVcpXOSGqpJSHu cgSafD9jvgUL8TvZHpYZSJkyxB3KfXA9idQDkBjCih4t0CZZ7BqjU4u7fCcLC+b3 Je9K06HX8X18B/baG7W61AvCY9QGTmdCXlSAIkTJ1U1G121V/1OTrQed4rZsVjoI ixC2deiuM6D+mY/unGPVf2on6U+woqrgmPdrGxIyNxq5NxgC6qyZ8Cmiz0AYnQVU Zy6W92VfLblFelFVARg55C0B+MirR4olQT4yrVwVQ45D1jcM8HDgJBzACYcppQLO hU6MJ2jH0k8vIqQ2R9qsD43VmdoxNwu/oPErZUad98fS06vS9ybyCIEoWsPNQEhx Lp91wX79EdmpKgkA9T7GP7JIVuasgPTF9sAUF8XSdmfvZce9u/0GT4Vg0HslbKj9 tmwMX9+qx4aLXoMDC0UKOD5WBb5/KrOHK16pLJVaXlNpCwWKfVJYaXRxZpA92Ghy dOQKzk9cp+oblO/hOxoHieDVfi++lenqFjIw0FhlzqutvZvUP6v5XlRF3/0AOTq8 R/RTmZmzg6tt/m0mBtsyWrSHVRxC/3ZZQ6ZBnOiYaOyBi4MsHp4= =O49e -----END PGP SIGNATURE----- --EdEhuujGuVlhtgTvDYfVEKi58wVi1SrQO-- From nobody Sat Mar 24 09:19:26 2018 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 4BC2D1272E1 for ; Sat, 24 Mar 2018 09:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 OArbpd1GLmk3 for ; Sat, 24 Mar 2018 09:19: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 AD8141200C5 for ; Sat, 24 Mar 2018 09:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521908361; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=a65XIkvnaGXTeLPBxry2V+jezT03btuw4SqXrAV0g+E=; b=bhagqe38lT3FHr4xDEI1mskvgNsLAtoDga2NlMEP9CDWpDUzq05dibNETo5mNdOp IH4R2mLWbsfQvqW6PQtTLBRZI3NyJsq94WOaRYDA2Lyuz7Tsf+wXP+3gtFxYvPUD zcCsaGV+WbwnG0bd8zDzsOuEVOwaKddelSAlcdi77vI=; X-AuditID: c1b4fb2d-4b1ff70000005540-15-5ab67a89bc43 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 52.49.21824.98A76BA5; Sat, 24 Mar 2018 17:19:21 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0382.000; Sat, 24 Mar 2018 17:19:20 +0100 From: Christer Holmberg To: Peter Saint-Andre , Emil Ivov CC: "ice@ietf.org" Thread-Topic: [Ice] Trickle: A couple of questions on section 7 Thread-Index: AdOucJgg+M5x/JnqQAe0nEYDsAIfMAGg2MuAAA3ZuwAABI1rgAAGIuKAAsuWQQAADPksAACw8cdg Date: Sat, 24 Mar 2018 16:19:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E16793@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> In-Reply-To: <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.170] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbFdQrezaluUwZZZKhZrdk5gsfh2odbi 2cpTjA7MHkuW/GTy+P8m0KPvQBdrAHMUl01Kak5mWWqRvl0CV0bPzxtMBSvlKj5M2MLUwHhK vIuRk0NCwESiZf8Gli5GLg4hgcOMEn+at7JCOEsYJXp2P2PvYuTgYBOwkOj+pw3SICLgIfF0 3UdmkDCzgKLEy71qIGFhATuJ3vNr2CFK7CW29V5jgbCjJL4c28cMYrMIqErc/dAOZvMK+Er8 O7IRatVKZom9J6+CNXMCNTd+vQTWzCggJvH91BomEJtZQFzi1pP5TBBHC0gs2XOeGcIWlXj5 +B8rhK0kcWbTcxaIej2JG1OnsEHY2hLLFr6GWiwocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCy rGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjJuDW37r7mBc/drxEKMAB6MSD29f8bYoIdbE suLK3EOMEhzMSiK8vxKAQrwpiZVVqUX58UWlOanFhxilOViUxHlPevJGCQmkJ5akZqemFqQW wWSZODilGhhFV3TpKN7YvDbYXTmgXt0yaGds66E1x5VffNN15lRNPOlwWOTpO1nlBXvzfhzY MPflHbd5h6Yd+C3t2N/Yt0XWUb9qZWFXc1H4k/D/HGyHp5VN/Cd7vOLT77mrtpevYfxgNEv+ 6lyFpv7Iv1m/ZELNbb2VwzKVqyNmX/lqveb6m19FNZn3bj1SYinOSDTUYi4qTgQANiYmEJcC AAA= Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 24 Mar 2018 16:19:25 -0000 Hi, >>>>> Q1: >>>>> >>>>> Section 7.1 says: >>>>> >>>>> =B3The ICE specification [rfc5245bis], Section 6.1.4.2, specifies = that >>>>> an agent will terminate the timer for a triggered check in relatio= n >>>>> to a check list once the agent has exhausted all frozen pairs in t= he >>>>> check list. This will not work with Trickle ICE, because more pai= rs >>>>> will be added to the check list incrementally.=B2 >>>>> >>>>> Exactly what procedure in 5245bis dos this text refer to? >>>> >>>> At the time of writing that was section 5.8 in 5245 and specifically=20 >>>> this >>>> text: >>>> >>>> * If there is no such pair: >>>> + Terminate the timer for that check list. >>>> >>>> I am not able to match that to text in 5245 bis and it probably went=20 >>>> away last year when we were redoing the states. We'd need to resync=20 >>>> it. Want to have a quick call offlist? (I suspect we can probably=20 >>>> just drop this after the latest changes we did in Prague last year). >>> >>> Ok, I think I get it now. >>> >>> In RFC 5245 (and earlier versions of 5245bis) we had a *separate*=20 >>> timer Ta for each check list. So, once there were no more checks to=20 >>> be done for a check list, the timer for a given check list was terminat= ed. >>> >>> In 5245bis, however, we only use a *single* timer Ta for the whole=20 >>> check list set, and whenever Ta fires we check the next Running check=20 >>> list in the check list set. So, non-Running check lists will=20 >>> automatically be skipped. This is described in section 6.1.4.2. >>> >>> So, I am not sure whether you need to say anything in trickle,=20 >>> because whether a check list is checked or not is taken care of by=20 >>> the 5245bis procedures. >>=20 >> That seems reasonable and I can adjust the text accordingly. > > By which I mean: remove Section 7.1 entirely. I am not sure it shall be removed, because I think there IS something to sa= y. But, the text needs to be adjusted, e.g., as following: "7.1. Check List State [rfc5245bis] specifies that, whenever timer Ta fires, only check lists in Running state will be picked in order to check for candidate pairs for which connectivity checks are scheduled. Therefore, an Trickle ICE agent MUST keep each check list in Running state as long as new pairs are incrementally added to the check list. After that, the check list state is set according to the procedures in [rfc5245bis]." --- >>>>> Q2: >>>>> >>>>> Section 7.2 says: >>>>> >>>>> =B3When a check list is set to Failed as described above, regular = ICE >>>>> requires the agent to update all other check lists, placing one pa= ir >>>>> from each check list into the Waiting state and thereby effectivel= y >>>>> placing all remaining check lists into the Running state.=B2 >>>>> >>>>> Exactly what procedure in 5245bis dos this text refer to? >>>> >>>> Exactly the parts that we discussed and agreed to change in Prague=20 >>>> last year. I think this part is no longer necessary given how they=20 >>>> are covered by 5245bis. >>> >>> But, are you saying that the text above is according to 5245bis? >>=20 >> I can't speak for Emil, but IMHO it's best to remove that text so the=20 >> question is moot. > > Looking at this further, I realize that I have a question about 5245bis: > according to ICE Core, is it possible to have an empty check list?=20 > By my reading of Section 6.1.2, a check list must have candidate pairs in= it. > However, in Trickle ICE we can have empty check lists. That's at least in= part what=20 > Section 7.2 of the trickle spec is about. I am not sure what an empty check list is.=20 Shouldn't the text be talking about adding new check lists to the check lis= t set instead? Regards, Christer From nobody Sat Mar 24 09:28:08 2018 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 3B08412D7E4 for ; Sat, 24 Mar 2018 09:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 JJ28wHwpJaBn for ; Sat, 24 Mar 2018 09:28:05 -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 662DE12D0C3 for ; Sat, 24 Mar 2018 09:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521908883; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cPowas3LRG3Zq89TyZwNTbgqA+VbsL6I70QVsY7Jefc=; b=Kx1ocUh+NrArNR+dGem1J4iN5ApjrmntLNtsaJ3534wO2sTfWj/mMravuSwcHP0l 0oSRHmcAvBsCP9mJzEOKhap5D0HjcU0bsMpwFtBBlQtAe3JPy6vUpXK/64bOams2 RqzCW4GfNtXSE7u6QqeMNbcWpjsCHgx4Cknfpl8LdsY=; X-AuditID: c1b4fb25-b1fff70000000e6d-3c-5ab67c9366b1 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 47.B3.03693.39C76BA5; Sat, 24 Mar 2018 17:28:03 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0382.000; Sat, 24 Mar 2018 17:28:03 +0100 From: Christer Holmberg To: Christer Holmberg , Peter Saint-Andre , Emil Ivov CC: "ice@ietf.org" Thread-Topic: [Ice] Trickle: A couple of questions on section 7 Thread-Index: AdOucJgg+M5x/JnqQAe0nEYDsAIfMAGg2MuAAA3ZuwAABI1rgAAGIuKAAsuWQQAADPksAACw8cdgAAQNEIA= Date: Sat, 24 Mar 2018 16:28:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E177D7@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E16793@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E16793@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.170] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbHdT3dyzbYog80d+hZrdk5gsfh2odbi 2cpTjA7MHkuW/GTy+P8m0KPvQBdrAHMUl01Kak5mWWqRvl0CV8bf88sYC3r5KvpWKDUwTuHu YuTkkBAwkbhw9zx7FyMXh5DAYUaJE/sfsoEkhASWMEqcv6bTxcjBwSZgIdH9TxskLCJQJ9E8 7yQ7SJhZQFHi5V41kLCwgJ1E7/k17BAl9hLbeq+xQNhJEk1vnzGB2CwCqhLTm9eCxXkFfCWO THwFtekts8SSVc4gNqeAn8TMNUfAahgFxCS+n1oD1sssIC5x68l8JoiTBSSW7DnPDGGLSrx8 /I8VwlaSOLPpOQtEvZ7EjalT2CBsbYllC18zQ+wVlDg58wnLBEbRWUjGzkLSMgtJyywkLQsY WVYxihanFiflphsZ66UWZSYXF+fn6eWllmxiBEbMwS2/VXcwXn7jeIhRgINRiYe3rnhblBBr YllxZe4hRgkOZiUR3l8JQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8D803RwkJpCeWpGanphak FsFkmTg4pRoYtavWXrg3t/dPgeVkhsLsSzprumbeL+cQfClkd3f1LY6y9Wvuvvz0P9dC/eWF 0ncWKisTrtS18jk/uPwvewVL9sqlG98rm57VO35Rmpn9cvwf7hk+HS2+IS/M27ZvDl4duPz3 7cvt7wzqTD5endUzv9EgTnTJXquMK1ecr5/4abVd8d3CgjkNK5VYijMSDbWYi4oTATVz5tqU AgAA Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 24 Mar 2018 16:28:07 -0000 Hi, ... >>>>>> Q2: >>>>>> >>>>>> Section 7.2 says: >>>>>> >>>>>> =B3When a check list is set to Failed as described above, regular= ICE >>>>>> requires the agent to update all other check lists, placing one p= air >>>>>> from each check list into the Waiting state and thereby effective= ly >>>>>> placing all remaining check lists into the Running state.=B2 >>>>>> >>>>>> Exactly what procedure in 5245bis dos this text refer to? >>>>> >>>>> Exactly the parts that we discussed and agreed to change in Prague=20 >>>>> last year. I think this part is no longer necessary given how they=20 >>>>> are covered by 5245bis. >>>> >>>> But, are you saying that the text above is according to 5245bis? >>>=20 >>> I can't speak for Emil, but IMHO it's best to remove that text so the=20 >>> question is moot. >> >> Looking at this further, I realize that I have a question about 5245bis: >> according to ICE Core, is it possible to have an empty check list?=20 >> By my reading of Section 6.1.2, a check list must have candidate pairs i= n it. >> However, in Trickle ICE we can have empty check lists. That's at least=20 >> in part what Section 7.2 of the trickle spec is about. > > I am not sure what an empty check list is.=20 I withdraw that statement. I was thinking about something else. Now, 5245bis obviously assume that there are candidate pairs in each check = list from the beginning. So, if the only think you want to say is that a check list might initially = be empty, I think the section name should be "Empty Check Lists", and then = you only need a couple of sentences to point it out. Regards, Christer _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice From nobody Sat Mar 24 10:11:20 2018 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 592981271FD for ; Sat, 24 Mar 2018 10:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 FPS5ZJ1mhQig for ; Sat, 24 Mar 2018 10:11:18 -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 AA3EF126D05 for ; Sat, 24 Mar 2018 10:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521911475; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=K0ZwndZP9Is3u9lLGu5VMyVqKg+nsmyjtBUYBfclyiQ=; b=KmUKs+55kdTAaphW4IQSwU/NfTi8tA2WEG0RU5FBwRxi0LKtZYjRUijwmi4bIHYP xEppWKvVHRsdbZwwDAuyIvI/zzZMdAII+IB5H+4PWAqPNz+IeybRkPOKZFCDYszk U2dJt8rupvrTBcUdsUqGsnv/lY+vy/qTnBCjkJEiZZY=; X-AuditID: c1b4fb30-433ff7000000197d-99-5ab686b333e7 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 90.72.06525.3B686BA5; Sat, 24 Mar 2018 18:11:15 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0382.000; Sat, 24 Mar 2018 18:11:15 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: ICE trickle: Comment on section 8.1.1 Thread-Index: AdPDkuP38FvIt3+USwysDB0OImfNMw== Date: Sat, 24 Mar 2018 17:11:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E178A7@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.172] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B72E178A7ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM2K7n+7mtm1RBt8Xq1p8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6M/p29jAWLHCvm7VjK2sB4xqKLkZNDQsBEovfYL8YuRi4OIYHD jBIn//1jhXCWMEp87brJ0sXIwcEmYCHR/U8bpEFEQFFiZsszZpCwsICexM8VThBhY4kJNy8y Qth6Ej++PmQDsVkEVCUWPr3NCmLzCvhKvDuxgRnEZhQQk/h+ag0TiM0sIC5x68l8Joh7BCSW 7DnPDGGLSrx8DHIOB5CtJNEwkwWiPF/i8ffrTBAjBSVOznzCMoFRcBaSSbOQlM1CUgYR15FY sPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgQG/cEt vw12ML587niIUYCDUYmHd1Xxtigh1sSy4srcQ4wSHMxKIry/EoBCvCmJlVWpRfnxRaU5qcWH GKU5WJTEeS38NkcJCaQnlqRmp6YWpBbBZJk4OKUaGDMvyLAe2qTj2dbvdOs10ycd08Sqwy7e x6Ynebteuby/5tCZvSLBK03iWPTjL3uk6i8+G9rOG97zcuYdG4/FF8Wyfn99VuqdZu/yYirP ii5j963pNyZXrWLb3SNt0BEVlKJnePfB8iMR8zZbSsc8vBmifesq/9lnQu5BpVrB3bsTD+1I kHvxQYmlOCPRUIu5qDgRAJDJGV12AgAA Archived-At: Subject: [Ice] ICE trickle: Comment on section 8.1.1 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, 24 Mar 2018 17:11:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B72E178A7ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was reading the rules in section 8.1.1 on how to set the pair state for t= rickled candidate pairs, and I think it can be simplified, as follows: - If there are no other pairs for the same foundation, set the sta= te to Waiting (covers Case #1) - If all other pairs for the same foundation are in either the Suc= ceeded or Failed state, set the state to Waiting (covers Case #2) - If there are more than one pair for the same foundation in the W= aiting state, set the state to Waiting (covers Case #3) - If there is exactly one pair for the same foundation in the Wait= ing state, set the state to Frozen (covers Case #4) Am I missing some case? Also, if you want to keep the tables, I think it would be good to indicate = in the table which pair(s) were inserted, using some special character. Currently the text says things like "two newly formed pairs were placed in = column 5, rows 3 and 4", which is ok, but I also think it should be shown i= n the table. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B72E178A7ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I was reading the rules in section 8.1.1 on how to s= et the pair state for trickled candidate pairs, and I think it can be simpl= ified, as follows:

 

-     &= nbsp;    If there are no other pairs for the same foundation= , set the state to Waiting   (covers Case #1)

-     &= nbsp;    If all other pairs for the same foundation are in e= ither the Succeeded or Failed state, set the state to Waiting (covers Case = #2)

-     &= nbsp;    If there are more than one pair for the same founda= tion in the Waiting state, set the state to Waiting (covers Case #3)

-     &= nbsp;    If there is exactly one pair for the same foundatio= n in the Waiting state, set the state to Frozen (covers Case #4)=

 

Am I missing some case?

 

Also, if you want to keep the tables, I think it wou= ld be good to indicate in the table which pair(s) were inserted, using some= special character.

 

Currently the text says things like “two newly= formed pairs were placed in column 5, rows 3 and 4”, which is ok, bu= t I also think it should be shown in the table.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B72E178A7ESESSMB109erics_-- From nobody Sat Mar 24 10:37:54 2018 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 B9E73126DED for ; Sat, 24 Mar 2018 10:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 n0Z5qOm8u6ff for ; Sat, 24 Mar 2018 10:37:50 -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 56C0A126D74 for ; Sat, 24 Mar 2018 10:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521913068; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=iiViX1NT93lszQ6Q1YJG9hiQmJ0MR3GRiyNoP8z0AFg=; b=azRBCFI+vceJsFptm5MmE/mQu5+3vrghIEfWxms/5R++nOj9UvE7M4QLB3RC5wMT rwJWiAyfQi2UHVpU4U57iIoccHfD+A3H64W8WrhtWyAMBS0chpnK58/w0Cj5vCrJ cLOAv5gas4nU2eBdiWqjrH5HFQWPsh/9lz0Huc8V2mk=; X-AuditID: c1b4fb30-44bff7000000197d-2c-5ab68cecac0b Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id EE.B5.06525.CEC86BA5; Sat, 24 Mar 2018 18:37:48 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0382.000; Sat, 24 Mar 2018 18:37:48 +0100 From: Christer Holmberg To: Peter Saint-Andre , Emil Ivov CC: "ice@ietf.org" Thread-Topic: [Ice] Trickle: A couple of questions on section 7 Thread-Index: AdOucJgg+M5x/JnqQAe0nEYDsAIfMAGg2MuAAA3ZuwAABI1rgAAGIuKAAsuWQQAADPksAACw8cdgAAQNEIAAAfG6EA== Date: Sat, 24 Mar 2018 17:37:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E178DD@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E16793@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E177D7@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E177D7@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.172] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbFdQvdNz7YogwP3NSzW7JzAYvHtQq3F s5WnGB2YPZYs+cnk8f9NoEffgS7WAOYoLpuU1JzMstQifbsErowTPy+zF5zXqtiw5wNTA+Ma xS5GTg4JAROJTXensXYxcnEICRxmlFj2/hcThLOEUeL7/H2MXYwcHGwCFhLd/7RBGkQEPCSe rvvIDBJmFlCUeLlXDSQsLGAn0Xt+DTtEib3Ett5rLCAlIgJZEnf+5ICEWQRUJfrOtbOB2LwC vhIrf82G2rSRRWL+9B8sIAlOAT+J86e+MoHYjAJiEt9PrQGzmQXEJW49mc8EcbOAxJI955kh bFGJl4//sYLskhBQkmiYyQJRridxY+oUNghbW2LZwtfMEHsFJU7OfMIygVF0FpKps5C0zELS MgtJywJGllWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgTFzcMtvgx2ML587HmIU4GBU4uFV 694WJcSaWFZcmXuIUYKDWUmE91cCUIg3JbGyKrUoP76oNCe1+BCjNAeLkjivhd/mKCGB9MSS 1OzU1ILUIpgsEwenVAOjd3/EMbWAGmWBPq0/W3SfhTked7J82ND6qWmi0h1nSdXLqVyC9xvE fr9u4y5YO9WmlLfWh1lQ/sRdybsXL91S/+fIrRrydUbd1o3Grep6M19fvKjmfkJm5yaOyUom hb/KbhQH7XD9nMnv9PnYJcW5bW4VwRFu37bXdDYv6g4MMNp/l3fO64NKLMUZiYZazEXFiQBl 3Md9lQIAAA== Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 24 Mar 2018 17:37:53 -0000 Hi, Below is some comments on the current text in section 7.2: (In general, please replace "The ICE specification" with "[rfc5245bis]".)=20 --- +7.2. Check List and Timer State Updates + + The ICE specification [rfc5245bis], Section 7.2.5.3.3, requires that + agents update check lists and timer states upon completing a + connectivity check transaction. During such an update, regular ICE + agents would set the state of a check list to Failed if both of the + following two conditions are satisfied: + + o all of the pairs in the check list are either in the Failed state + or Succeeded state; and + + o there is not a pair in the valid list for each component of the + media stream. + + With Trickle ICE, the above situation would often occur when + candidate gathering and trickling are still in progress, even though + it is quite possible that future checks will succeed. For this + reason, Trickle ICE agents add the following conditions to the above + list: + + o all candidate gathering has completed and the agent is not + expecting to discover any new local candidates; + + o the remote agent has conveyed an end-of-candidates indication for + that check list as described in Section 8.2. [Christer] I think more or less everything above is covered by the new text= I suggested for section 7.1. In short: keep the check list in Running stat= e until there are no more trickled pairs. + When a check list is set to Failed as described above, regular ICE + requires the agent to update all other check lists, placing one pair + from each check list into the Waiting state=20 [Christer] I don't think this is true. Is there text in 5245bis defining th= is? + and thereby effectively placing all remaining check lists into the Runn= ing state. =20 [Christer] This sounds weird. In 5245bis all check lists states are set to = Running by default. + However, + under Trickle ICE other check lists might still be empty at this + point (because candidates have not yet been received), and following + only the rules from regular ICE would prevent the agent from forming + those check lists (because the state of a check list depends on the + state of the candidate pairs in that check list, but there might not + yet by any candidate pairs in a given check list). In accordance + with the ICE specification [rfc5245bis], Section 6.1.2.1, a Trickle + ICE agent considers an empty check list to be in the Running state; [Christer] This can be simplified: simply indicate that some check lists ma= y initially be empty, but are still initially set in Running state accordin= g to the procedures in 5245bis. In addition you can say that, whenever Ta f= ires and an empty check list is picked, no actions are performed for that c= heck list. + in accordance with Section 8.1.1, when inserting a new candidate pair + into an empty check list, the agent sets the pair to a state of + Waiting. [Christer] This is not needed here. Section 8.1.1 defines the state of new = candidate pairs, no matter if they are inserted into an empty or non-empty = check list. So, based on my analysis, the only thing you need to keep is the empty chec= k list part. Regards, Christer -----Original Message----- From: Christer Holmberg=20 Sent: 24 March 2018 18:28 To: Christer Holmberg ; Peter Saint-Andre <= stpeter@mozilla.com>; Emil Ivov Cc: ice@ietf.org Subject: RE: [Ice] Trickle: A couple of questions on section 7 Hi, ... >>>>>> Q2: >>>>>> >>>>>> Section 7.2 says: >>>>>> >>>>>> =B3When a check list is set to Failed as described above, regular= ICE >>>>>> requires the agent to update all other check lists, placing one p= air >>>>>> from each check list into the Waiting state and thereby effective= ly >>>>>> placing all remaining check lists into the Running state.=B2 >>>>>> >>>>>> Exactly what procedure in 5245bis dos this text refer to? >>>>> >>>>> Exactly the parts that we discussed and agreed to change in Prague=20 >>>>> last year. I think this part is no longer necessary given how they=20 >>>>> are covered by 5245bis. >>>> >>>> But, are you saying that the text above is according to 5245bis? >>>=20 >>> I can't speak for Emil, but IMHO it's best to remove that text so=20 >>> the question is moot. >> >> Looking at this further, I realize that I have a question about 5245bis: >> according to ICE Core, is it possible to have an empty check list?=20 >> By my reading of Section 6.1.2, a check list must have candidate pairs i= n it. >> However, in Trickle ICE we can have empty check lists. That's at=20 >> least in part what Section 7.2 of the trickle spec is about. > > I am not sure what an empty check list is.=20 I withdraw that statement. I was thinking about something else. Now, 5245bis obviously assume that there are candidate pairs in each check = list from the beginning. So, if the only think you want to say is that a check list might initially = be empty, I think the section name should be "Empty Check Lists", and then = you only need a couple of sentences to point it out. Regards, Christer _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice From nobody Sat Mar 24 14:41:53 2018 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 29370126C3D for ; Sat, 24 Mar 2018 14:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 LAwbjoKHR6ZI for ; Sat, 24 Mar 2018 14:41:51 -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 B6672126BF7 for ; Sat, 24 Mar 2018 14:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521927708; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=A6Cj4AN0fmM6dvTg27VMjIxc/WGwV3ftuRTSlteqhpA=; b=MXR9lrjCn0arWz5tCfFqG+0iHwSb9UmBllM1kAJzrnPt/uAbc818pCPn36kEzhh2 ZRwAwLdZaJ1dFlLcwub4Awx0lIfI85PSEmFFe/3vQp1D+bQDq59p4b5t839hDTdr VP5gEMqEaTujriXVA2wtr24I10otMnqOX5/zJQh8X+Q=; X-AuditID: c1b4fb30-44bff7000000197d-21-5ab6c61c7e42 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AA.D8.06525.C16C6BA5; Sat, 24 Mar 2018 22:41:48 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0382.000; Sat, 24 Mar 2018 22:41:48 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: Trickle ICE: Definition of Generation Thread-Index: AdPDpr/81vwbP4rFQ72jZjC2dwTrfw== Date: Sat, 24 Mar 2018 21:41:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E18B4A@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.172] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B72E18B4AESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM2K7ja7MsW1RBkefGFl8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6MA1v+sRe0KVV83NvE1sD4WbaLkZNDQsBE4tPJCcxdjFwcQgKH GSUOzl7KCOEsYZTomrWXtYuRg4NNwEKi+582SIOIgKLEzJZnzCC2sICexKwryxkh4sYSJ5d3 s0LYehJ/1rexg9gsAqoS32Z+A6vhFfCVePvgDxuIzSggJvH91BomEJtZQFzi1pP5TBAHCUgs 2XOeGcIWlXj5+B/YCRICShINM1kgyvMlJj9ZwQIxUlDi5MwnLBMYBWchmTQLSdksJGUQcR2J Bbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZg2B/c 8ttgB+PL546HGAU4GJV4eMv2bIsSYk0sK67MPcQowcGsJMIbuAsoxJuSWFmVWpQfX1Sak1p8 iFGag0VJnNfCb3OUkEB6YklqdmpqQWoRTJaJg1OqgVF9RQNjhsicHRsuJu/uEFuxqGzTzhkL nN72rf6z7dgvlaVTOg15ff1ivZLym7Y5XjN4Za1ksDTVhf+Tz4cT576eMr30Kq3iRSWf/PL5 3JldhcXem0s23lrcU5x7/10A20M3R+UzH47ZcMzjN/rF3r3wb6/JvLhbE27Xf+Xa9/iv1X9z t4CD8+SVWIozEg21mIuKEwH4FjVjdwIAAA== Archived-At: Subject: [Ice] Trickle ICE: Definition of Generation 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, 24 Mar 2018 21:41:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B72E18B4AESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Trickle-17 contains the following: "Generation: All of the candidates conveyed within an ICE session; these are the candidates that are associated with a specific local/remote Username Fragment and Password combination (which will change on ICE restart, if any occurs)." As 5245bis now contains a definition of "ICE session", you don't need to de= scribe what it is (I think this was previously discussed). So, I suggest to only say: "Generation: All of the candidates conveyed within an ICE session [r= ef-to-5245bis]." Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B72E18B4AESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Trickle-17 contains the following:

 

      “Generation:&nb= sp; All of the candidates conveyed within an ICE session;

      these are the candida= tes that are associated with a specific

      local/remote Username= Fragment and Password combination (which

      will change on ICE re= start, if any occurs).”

 

As 5245bis now contains a definition of “ICE s= ession”, you don’t need to describe what it is (I think this wa= s previously discussed).

 

So, I suggest to only say:

 

      “Generation:&nb= sp; All of the candidates conveyed within an ICE session [ref-to-5245bis].&= #8221;

 

Regards,

 

Christer

 

 

--_000_7594FB04B1934943A5C02806D1A2204B72E18B4AESESSMB109erics_-- From nobody Sat Mar 24 14:53:33 2018 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 B5952126BF7 for ; Sat, 24 Mar 2018 14:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 lGqZTF3FjPqr for ; Sat, 24 Mar 2018 14:53:30 -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 0DAC6120721 for ; Sat, 24 Mar 2018 14:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521928408; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aeJHSTiufKPOx7BV58qd1b1r6pSzgcNjQlvCf92R9lQ=; b=c5pq8b2ZwlEaGLSDzOdTPk0ljnqM8lFsvkUwcGfGuEaX7yTbTAfqM6Fw9mPW6zJ1 P1Ge2O3rcoh8jrHait8N4f7UXgXeulZmT02lQgbkT32nhrYjiVfHGqeY/FPgWBQy DV204Clm5+GM6hYabiHquxxPgfkfWyPBFI+Y9PPJ1r4=; X-AuditID: c1b4fb30-81c549c00000197d-ec-5ab6c8d83ab1 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FC.8B.06525.8D8C6BA5; Sat, 24 Mar 2018 22:53:28 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0382.000; Sat, 24 Mar 2018 22:53:25 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: Tricke ICE: Suggested clarifications to Introduction Thread-Index: AdPDqyqQBt8cF0w/QDKTIeEKNJW1+w== Date: Sat, 24 Mar 2018 21:53:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E18C06@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.172] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B72E18C06ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM2K7ge6NE9uiDKbeFbP4dqHWgdFjyZKf TAGMUVw2Kak5mWWpRfp2CVwZs79dYS6YE1hxc/8ctgbGNrcuRk4OCQETiett55i7GLk4hAQO M0pMm3mdEcJZwihxe819ti5GDg42AQuJ7n/aIA0iAooSM1ueMYPYwgK2Emf/zGOGiDtJfLl2 lAnC1pPo2bGSHcRmEVCV+LF6JlicV8BXYvvdRjYQm1FATOL7qTVgcWYBcYlbT+YzQRwkILFk z3lmCFtU4uXjf6wgJ0gIKEk0zGSBKM+XuPhqD9RIQYmTM5+wTGAUnIVk0iwkZbOQlEHEdSQW 7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIFhf3DL b4MdjC+fOx5iFOBgVOLhLduzLUqINbGsuDL3EKMEB7OSCG8OMGqEeFMSK6tSi/Lji0pzUosP MUpzsCiJ81r4bY4SEkhPLEnNTk0tSC2CyTJxcEo1MDbYq17mkxNUcJDgYS1ec1MqpbkreY7e 0cjGydlTZotl7P1vbHVy1+dVxlp9Ezy4/V5+fl4vM+0wz/o9IS21t1YKed3rDv9aNjVn2gUN mXS5xrNxG/Idy2avclkj93UC9xol37Y7n68eMd2xNHhJjiuv7QEVHslTq6ulQnnE2a/oidTK 9MipKrEUZyQaajEXFScCAFVaOWd3AgAA Archived-At: Subject: [Ice] Tricke ICE: Suggested clarifications to Introduction 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, 24 Mar 2018 21:53:32 -0000 --_000_7594FB04B1934943A5C02806D1A2204B72E18C06ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below is a suggestion on how to modify the Introduction section of draft-tr= ickle-ice, in order to make it more clear (in my opinion). --- 1. Introduction The Interactive Connectivity Establishment (ICE) protocol [rfc5245bis] describes mechanisms how an ICE agent gathers candidates, exchanges candidates with a peer ICE agent, and creates candidate pairs. Once the pairs have been created, the ICE agent will perform connectivity checks, and eventually nominate and select pairs that will be used for sending and receiving media within a session. Although the procedures in [rfc5245bis] are relatively straightforward to implement, they might lead to relatively lengthy session establishmen= t times, as candidate gathering often involves querying STUN servers [RFC5= 389] and allocating relayed candidates using TURN servers [RFC5766]. Although many procedures can be done in parallel, the pacing requirements [rfc524= 5bis] still needs to be followed. This document defines a supplementary mode of ICE operation, "Trickle ICE", in which given candidates can be exchanged incrementally, as soon as they become available (and while other candidates are still gathered). Connectivity checks can also start as soon as candidate pairs have been created. Then, as Trickle ICE allows candidate gathering= and connectivity check in parallel, the session establishment time can be considerable shortened. In addition, this document also defines how to discovers support of Tric= kle ICE, and how procedures in [rfc5245bis] are modified when using Trickle ICE. = The document also defines how an Trickle ICE agent can interoperate with an ICE agent compliant to [rfc5245bis]. This document does not define any ICE usage for Trickle ICE. Protocol specific details for Trickle ICE are defined in separate usage documents= . Examples of such documents are [I-D.ietf-mmusic-trickle-ice-sip], which defines usage with the Session Initiation Protocol (SIP) [RFC3261] and the Session Description Protocol [RFC4566] , and [XEP-0176], which defines usage with XMPP [RFC6120]. However, some of the examples in the document uses SDP and the Offer/Answer mechanism [RFC4566] in order to explain the underlying concepts. NOTE: It is worth noting that there is quite a bit of operational experience with the technique behind Trickle ICE, going back as far as 2= 005 (when the XMPP Jingle extension defined a "dribble mode" as specified in [XEP-0176]); this document incorporates feedback from those who have implemented and deployed the technique. --- Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B72E18C06ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Below is a suggestion on how to modify the Introduct= ion section of draft-trickle-ice, in order to make it more clear (in my opi= nion).

 

---

 

1.  Introduction

 

   The Interactive Connectivity Establishm= ent (ICE) protocol

   [rfc5245bis] describes mechanisms how a= n ICE agent gathers

   candidates, exchanges candidates w= ith a peer ICE agent, and

   creates candidate pairs. Once the = pairs have been created, the

   ICE agent will perform connectivit= y checks, and eventually

   nominate and select pairs that will be = used for sending and

   receiving media within a session.<= /o:p>

 

   Although the procedures in [rfc5245bis]= are relatively straightforward

   to implement, they might lead to relati= vely lengthy session establishment

   times, as candidate gathering often inv= olves querying STUN servers [RFC5389]

  and allocating relayed candidates using TURN = servers [RFC5766]. Although

   many procedures can be done in parallel= , the pacing requirements [rfc5245bis]

   still needs to be followed.<= /p>

 

   This document defines a supplementary m= ode of ICE operation,

   “Trickle ICE”, in which giv= en candidates can be exchanged incrementally,

   as soon as they become available (and w= hile other candidates are still

   gathered). Connectivity checks can also= start as soon as candidate

   pairs have been created. Then, as Trick= le ICE allows candidate gathering and

   connectivity check in parallel, th= e session establishment time can be

   considerable shortened.=

 

   In addition, this document also defines= how to discovers support of Trickle ICE,

   and how procedures in [rfc5245bis] are = modified when using Trickle ICE. The

   document also defines how an Trickle IC= E agent can interoperate with an

   ICE agent compliant to [rfc5245bis].

 

   This document does not define any ICE u= sage for Trickle ICE. Protocol

   specific details for Trickle ICE are de= fined in separate usage documents.

   Examples of such documents are [I-D.iet= f-mmusic-trickle-ice-sip], which

   defines usage with the Session Initiati= on Protocol (SIP) [RFC3261]

   and the Session Description Protocol [R= FC4566] , and

   [XEP-0176], which defines usage with XM= PP [RFC6120]. However,

   some of the examples in the document us= es SDP and the

   Offer/Answer mechanism [RFC4566] in ord= er to explain the

   underlying concepts.

 

   NOTE: It is worth noting that there is = quite a bit of operational

   experience with the technique behind Tr= ickle ICE, going back as far as 2005

   (when the XMPP Jingle extension defined= a "dribble mode" as specified

   in [XEP-0176]); this document incorpora= tes feedback from those who

   have implemented and deployed the techn= ique.

 

---

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B72E18C06ESESSMB109erics_-- From nobody Tue Mar 27 08:40:21 2018 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 0CA131289B0 for ; Tue, 27 Mar 2018 08:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 C1QVWnOTsP7M for ; Tue, 27 Mar 2018 08:40:17 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 D2A5B12785F for ; Tue, 27 Mar 2018 08:40:17 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id v194-v6so15847443itb.0 for ; Tue, 27 Mar 2018 08:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=NL/h9zTEN8oRSY1g42S6cYRT5wL71FnWD2Wb2HwfTrk=; b=RpBQKWWpDFdw+qSejcyDfpr9Ov0vAarPFnrkE5RsePnc2/o1JELhuq4MR2Bf+iAWF3 lXU+Nsv13xUEfrCxW0zqWxCCUy77dN4KXaV+f+pfyTmN99GO0WgT7wKebb1hMRcImoSf gCnMj/ACxwR0Lp9yjePZhWCic9jTFrAah1fpI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=NL/h9zTEN8oRSY1g42S6cYRT5wL71FnWD2Wb2HwfTrk=; b=iKNayuXVuv1FdwUvywDabxckEjY58QDtI+DjeGz3vyMiYmK7x1zuMaXePLTW7tEmts hus9rB+wxeiuGLlxtrXgvD/PICScMhNpv2s8ErdJzSkNwdPjHRtL9p7V2/qCYa2sojYB 99A/ljMoAzD/Y7X0XjfNgWbxvTdOCHmXCclpHGh0gcSSavgzkbNYtMYvPh5eYZ2Ni9qo 9uy/E7T2nbeQt/7NAErI9eJiWqYSlePcYlHYA01nkQ5Ta1r7jITp/Cxx+YVldt5rD3uF trQZntt8KVqWm9b1d5GDCxt5/rWqdb7ucsAfiFyVIxtSzLEg5JoKweCtK7X8OZACfutx u1zQ== X-Gm-Message-State: AElRT7HSd8JRrpkdKzT73KTHu8oCUHOKf2XzmmzEiThZ+Prtcr2XV2Mo eB+HfnOlotVnOzi3+uaGSZCvj5Hn1gA= X-Google-Smtp-Source: AG47ELufbnTDpLO266XplQMywvWcZK48TAuDgKEcL9qCKAeuviT+PNcI5nmNNpOzjzTlAMp5M0Sfig== X-Received: by 2002:a24:e4c2:: with SMTP id o185-v6mr26998331ith.37.1522165217163; Tue, 27 Mar 2018 08:40:17 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id l124-v6sm1315985ite.20.2018.03.27.08.40.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 08:40:16 -0700 (PDT) To: ice@ietf.org References: <7594FB04B1934943A5C02806D1A2204B72E18B4A@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: <90460b6a-7bcc-616f-bb75-c8b910873769@mozilla.com> Date: Tue, 27 Mar 2018 09:40:15 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E18B4A@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FvhVljbvHmhM6bCemoTLvEazmuUU1367Z" Archived-At: Subject: Re: [Ice] Trickle ICE: Definition of Generation 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, 27 Mar 2018 15:40:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FvhVljbvHmhM6bCemoTLvEazmuUU1367Z Content-Type: multipart/mixed; boundary="L3NW44GMOchgLmOjnmPPLd6I4siemMCpZ"; protected-headers="v1" From: Peter Saint-Andre To: ice@ietf.org Message-ID: <90460b6a-7bcc-616f-bb75-c8b910873769@mozilla.com> Subject: Re: [Ice] Trickle ICE: Definition of Generation References: <7594FB04B1934943A5C02806D1A2204B72E18B4A@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E18B4A@ESESSMB109.ericsson.se> --L3NW44GMOchgLmOjnmPPLd6I4siemMCpZ Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/24/18 3:41 PM, Christer Holmberg wrote: > Hi, >=20 > =A0 >=20 > Trickle-17 contains the following: >=20 > =A0 >=20 > =A0=A0=A0=A0=A0 =93Generation:=A0 All of the candidates conveyed within= an ICE session; >=20 > =A0=A0=A0=A0=A0 these are the candidates that are associated with a spe= cific >=20 > =A0=A0=A0=A0=A0 local/remote Username Fragment and Password combination= (which >=20 > =A0=A0=A0=A0=A0 will change on ICE restart, if any occurs).=94 >=20 > =A0 >=20 > As 5245bis now contains a definition of =93ICE session=94, you don=92t = need to > describe what it is (I think this was previously discussed). >=20 > =A0 >=20 > So, I suggest to only say: >=20 > =A0 >=20 > =A0=A0=A0=A0=A0 =93Generation:=A0 All of the candidates conveyed within= an ICE session > [ref-to-5245bis].=94 WFM! Peter --L3NW44GMOchgLmOjnmPPLd6I4siemMCpZ-- --FvhVljbvHmhM6bCemoTLvEazmuUU1367Z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq6Zd8ACgkQZWGMGH9o FKmnDBAAnJ5B6RLI9H7mEsBELGTip+QYHOk/ZIrJ09clMkWCXzmOJzS9/luXs4k4 dCPHKRRNR4HOxsc1c9dEDx+KkW5z/fhC1Z5iD4/sXvL4tmXs3+YtEGM2md2dUQFd OacyyqwB44iVj7i6mU6Y9GpsJZW1w+DTRvQXEH2WMkQGFt5wqrPi4iUXnq1Rd9X4 8aAzXLVFwh5kZE3+JR0zHIExWzTruzx2B+y9EROL4zdHT9+3DKypjpAp+Q7tho7M 40XwgYcwzyrsaD8/QDzrBLU7zXKxhj9fwJIS3xrv5rp2hszi3v9lS9vWtt5vAm8G 781PUCxJOZW9QbJwlUlhV8yhiue7JEN6UyWF1HZLFOqvPJ4rne8WjpFQVfeCgdzY QcwUc7Q3zu+l/DI/r3qSWkxE1v1q8eZ9DJ6CMBObqNRDcnrGl5d3CKm+y6zO3lL8 +jnvsEJx4XmMZLbQREVT5Y3s86JrQZspzTHU/ntioRbEB4TGbbaIIVS1Zb8hxV7u H0w8kG9mvFc3n5gNT/mgCTFYr3t7P305S6LriDOk6qXTnFF/0MH1OOJWK65/bevA rlesltu8jp0IVBfgyW3KeMeW2CfgTno3yzyPi6D9XUVjeAoRXdvs7MfZPaw1TsWD V1Fqym/PP4hhV1toJGspJtKLZKu07Qhm1Y9Pyb0Q5IqLVf1VlP8= =UzCx -----END PGP SIGNATURE----- --FvhVljbvHmhM6bCemoTLvEazmuUU1367Z-- From nobody Tue Mar 27 08:52:09 2018 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 5D6DE12DA6B for ; Tue, 27 Mar 2018 08:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Wnpb-WBZ7wE7 for ; Tue, 27 Mar 2018 08:52:05 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 AFE3612DA69 for ; Tue, 27 Mar 2018 08:52:05 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id e98-v6so15882262itd.4 for ; Tue, 27 Mar 2018 08:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=LfP2YBMgf2whLweUcbh33Yf+rsvnzcynWNqnQUSk7CM=; b=E3DXJYb6sYV6epTAKEzUep/WKCalD6cLuH97bxEgE8UrEgYOpkjl+5Hw0NVzbL4wmX wAZ07tSn9Z6+oaCptaRDVvr+lgHDG7AbZi2zCNniPquSUGoMm7A8Y7ehI5OdmTyiVl/S e9SeQL3IKBjKnaTglZJkkhCAHAovgfPmvphN8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=LfP2YBMgf2whLweUcbh33Yf+rsvnzcynWNqnQUSk7CM=; b=ZOkzJhgAcSMwZyr/Uv6xF+qD6fcrp7hvynwBEHNPIhZ+2qIaLbz6gc9K1L1Hxg2RCU kqUOYKkBkD4eJRkvHB5yje4gSRzYiMOd2wyHPoCAgvuJ5LXFojRbgfdOqWNIy3lPAh/S 4dzgXWRvstHjbEfSDf/b3WPplu0o0z2JyOPjAuZvFovQ1rsjSLQQMulDrXPyO6iPiR/p 8M/d3IU6tBYWdhyQZtzNjD6BmocjD2CEV3ZHnLiijug/wNJk1D9HREGfh4kCCQ0Gv4rX ewxzI53WKlaVajzzlZtY+yfhwdcXKbW7s5uMn7Pssdn0EjusSHdYIZ2tyel57UjHgnVk GAoA== X-Gm-Message-State: AElRT7Ez2J6FXED/Eo4ynWqit5K9fOd6t+DrjFIfvveU0Th7LFsDa7W7 sq2xpUnt93ksA3A3To7nbLmOaQ== X-Google-Smtp-Source: AG47ELsRrulAIsHsQi0IIPr14nviLtL6J/XliEa80N2NojOrzCjzYYFGR0W71Ei/b10tjUcOv2gOHw== X-Received: by 2002:a24:75d1:: with SMTP id y200-v6mr28807193itc.152.1522165924956; Tue, 27 Mar 2018 08:52:04 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id a128sm49910ioa.1.2018.03.27.08.52.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 08:52:03 -0700 (PDT) To: Christer Holmberg , Emil Ivov Cc: "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E16793@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E177D7@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: <7f3ebc1f-8b8a-cce2-6758-5ef3b5c9b717@mozilla.com> Date: Tue, 27 Mar 2018 09:52:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E177D7@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6gecyrbzTJCRYB16i475xCGnul2tENz6x" Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 27 Mar 2018 15:52:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6gecyrbzTJCRYB16i475xCGnul2tENz6x Content-Type: multipart/mixed; boundary="j9BnBTW5vyFNvEuAQmcozDA6wV5fGYjYd"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , Emil Ivov Cc: "ice@ietf.org" Message-ID: <7f3ebc1f-8b8a-cce2-6758-5ef3b5c9b717@mozilla.com> Subject: Re: [Ice] Trickle: A couple of questions on section 7 References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E16793@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E177D7@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E177D7@ESESSMB109.ericsson.se> --j9BnBTW5vyFNvEuAQmcozDA6wV5fGYjYd Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/24/18 10:28 AM, Christer Holmberg wrote: > Hi, >=20 > ... >=20 >>>>>>> Q2: >>>>>>> >>>>>>> Section 7.2 says: >>>>>>> >>>>>>> =C2=B3When a check list is set to Failed as described above, r= egular ICE >>>>>>> requires the agent to update all other check lists, placing on= e pair >>>>>>> from each check list into the Waiting state and thereby effect= ively >>>>>>> placing all remaining check lists into the Running state.=C2=B2= >>>>>>> >>>>>>> Exactly what procedure in 5245bis dos this text refer to? >>>>>> >>>>>> Exactly the parts that we discussed and agreed to change in Prague= =20 >>>>>> last year. I think this part is no longer necessary given how they= =20 >>>>>> are covered by 5245bis. >>>>> >>>>> But, are you saying that the text above is according to 5245bis? >>>> >>>> I can't speak for Emil, but IMHO it's best to remove that text so th= e=20 >>>> question is moot. >>> >>> Looking at this further, I realize that I have a question about 5245b= is: >>> according to ICE Core, is it possible to have an empty check list?=20 >>> By my reading of Section 6.1.2, a check list must have candidate pair= s in it. >>> However, in Trickle ICE we can have empty check lists. That's at leas= t=20 >>> in part what Section 7.2 of the trickle spec is about. >> >> I am not sure what an empty check list is.=20 >=20 > I withdraw that statement. I was thinking about something else. >=20 > Now, 5245bis obviously assume that there are candidate pairs in each ch= eck list from the beginning. Yes. > So, if the only think you want to say is that a check list might initia= lly be empty, I think the section name should be "Empty Check Lists", and= then you only need a couple of sentences to point it out. I suggest: A Trickle ICE agent will create a check list even if it does not yet have any candidates to put in that check list (this scenario does not arise with non-trickle agents, because all candidates are known when the agent creates the check list set); in accordance with the ICE specification [rfc5245bis], Section 6.1.2.1, a Trickle ICE agent considers an empty check list to be in the Running state. Peter --j9BnBTW5vyFNvEuAQmcozDA6wV5fGYjYd-- --6gecyrbzTJCRYB16i475xCGnul2tENz6x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq6aKIACgkQZWGMGH9o FKktqBAA6Zx9nRBuft3zFyAk61U+kAPOEGkb0dGf+zmY5icLLEzQ3XjxC9PZG0aw 6s7Zc7fscGSr6NGt1VpTM09aY4nmztl9tSFbGSJhfDudGG6nFy/OzdMAwcTR5qxr MDxKLr3/GkHjNZNJ0WVieyo+pPMFlW8h3Vm3DKY3CRMxXJxSSJDvwxaDN9F6UMrA 6Pvw6fx+h3BMqn3uNe+KEInX0aB13TwtjJ6+2OANn359JBoICAXbeBB/Web7p9Bb fr22Kws+1gCTXS5c7bDoLH/MsIV+HqBl7wlokM4svKkaI1u/WiEGJUwHImZiqoWs vJNWrC6wC/hoMQ6llvEO8mGPV+8iafpPECZTaiMHFMbWxEqSWCaUjM9JWiD0mpJk 6JQz4ZcrlqJQXDAa2JgCT/XFz7znFkAnS+r555yxtPMfzXyVASNBJ0bZkTo2i4K4 ry93U4K2u59s218HALPkRijKGUTmaVMdlt+UO6w3t2BeTc7wv/w0MrSFkqpo+K8F nHLqYGbEZ6/QLSpwR+wxhx1MJmTaieqBMxoTfi1o6iRQTsM/pytyWh9JuKnA9GWb 1ZuCHhO/1U/pAZpZF7aHf2Hm907S4c+yvn/+jAoU9g/mW9FbvkUqV42ZCEqzextY 0MIIYWP8Wnep7OpOQDE/GdDakHhMr223ljf9r0la5HUVLEYf15E= =npwl -----END PGP SIGNATURE----- --6gecyrbzTJCRYB16i475xCGnul2tENz6x-- From nobody Tue Mar 27 08:54:24 2018 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 8C89112DA72 for ; Tue, 27 Mar 2018 08:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 D8KeD-wfcerY for ; Tue, 27 Mar 2018 08:54:20 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 D67A612762F for ; Tue, 27 Mar 2018 08:54:19 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id p67-v6so15899089itc.2 for ; Tue, 27 Mar 2018 08:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=kfl1hTdoZN4lRc9MhY+C33UtJ97mTNPXbGjOu0wZCC4=; b=P0vKnkVSa9ObKkEkAj5CkGi4fsOobZZY4c4BILgjjolKIcrdGMTt89qtALP75uOo7X V80ybpPLGnbSGcbR1Olf8KVZYX/E7MY5n9sW3LNaGeZddGA1266d/hstirM15V5uw9xB kWA29ReZwCGHDomUv/d1aFYp8F4AcMgcliVbo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=kfl1hTdoZN4lRc9MhY+C33UtJ97mTNPXbGjOu0wZCC4=; b=b6PozizRiU0FtSjmJJPM1a5O/r3yuBg9ACGckHYnt/03dgaTqA3OVoNAEleEp4aI9L o16vbfMwVXfp/r7MR7g/28ELhK1rRY2w4AN0rAtDai738ho4zXZJ630TXsNQTtxID2uu reyYNhzbv4d2N74/GhenwpMC8rQwgJfv1Uqt3JxaZnR+8RvG04ds2Un4TEJ4ijSS7rA+ PEdUc6T8Cf8FGVITv/9vgwZE6U7c/iyu92H8RogJiPYSedKmWjpygQS0SGQLDGObZ8ta uUNb3qMidWBpP+F2sCIQePUSWeP7dAz7khq5AknDNJyU88xIVcCtuSS2xfWDT1A36m96 S6Qg== X-Gm-Message-State: AElRT7HaKKsnoNgC3vYZ2Yl8dBJxvgcT6IFlo+7x5GtrMKwsnpiMO64b XupAHnvo4uXmRw8qmGcxuEy0hw== X-Google-Smtp-Source: AIpwx4/o9ln3L4VQoXikMRq3iA5y4kchGAjtapjOsmwMfAau07ysocHuNzDM/aOf1TxFXeimCNVSFw== X-Received: by 2002:a24:e14e:: with SMTP id n75-v6mr26999731ith.58.1522166059055; Tue, 27 Mar 2018 08:54:19 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id k24sm1184814iod.3.2018.03.27.08.54.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 08:54:18 -0700 (PDT) To: Christer Holmberg , Emil Ivov Cc: "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E16793@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: Date: Tue, 27 Mar 2018 09:54:17 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E16793@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="237jAviM57lyC1H0r307XOC7TGdHPNkwk" Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 27 Mar 2018 15:54:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --237jAviM57lyC1H0r307XOC7TGdHPNkwk Content-Type: multipart/mixed; boundary="E7e3tdjmDNx2swXEiV5ZJ4tkX1WZsmOXa"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , Emil Ivov Cc: "ice@ietf.org" Message-ID: Subject: Re: [Ice] Trickle: A couple of questions on section 7 References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E16793@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E16793@ESESSMB109.ericsson.se> --E7e3tdjmDNx2swXEiV5ZJ4tkX1WZsmOXa Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/24/18 10:19 AM, Christer Holmberg wrote: > Hi, >=20 >>>>>> Q1: >>>>>> >>>>>> Section 7.1 says: >>>>>> >>>>>> =C2=B3The ICE specification [rfc5245bis], Section 6.1.4.2, spec= ifies that >>>>>> an agent will terminate the timer for a triggered check in rela= tion >>>>>> to a check list once the agent has exhausted all frozen pairs i= n the >>>>>> check list. This will not work with Trickle ICE, because more = pairs >>>>>> will be added to the check list incrementally.=C2=B2 >>>>>> >>>>>> Exactly what procedure in 5245bis dos this text refer to? >>>>> >>>>> At the time of writing that was section 5.8 in 5245 and specificall= y=20 >>>>> this >>>>> text: >>>>> >>>>> * If there is no such pair: >>>>> + Terminate the timer for that check list. >>>>> >>>>> I am not able to match that to text in 5245 bis and it probably wen= t=20 >>>>> away last year when we were redoing the states. We'd need to resync= =20 >>>>> it. Want to have a quick call offlist? (I suspect we can probably=20 >>>>> just drop this after the latest changes we did in Prague last year)= =2E >>>> >>>> Ok, I think I get it now. >>>> >>>> In RFC 5245 (and earlier versions of 5245bis) we had a *separate*=20 >>>> timer Ta for each check list. So, once there were no more checks to = >>>> be done for a check list, the timer for a given check list was termi= nated. >>>> >>>> In 5245bis, however, we only use a *single* timer Ta for the whole=20 >>>> check list set, and whenever Ta fires we check the next Running chec= k=20 >>>> list in the check list set. So, non-Running check lists will=20 >>>> automatically be skipped. This is described in section 6.1.4.2. >>>> >>>> So, I am not sure whether you need to say anything in trickle,=20 >>>> because whether a check list is checked or not is taken care of by=20 >>>> the 5245bis procedures. >>> >>> That seems reasonable and I can adjust the text accordingly. >> >> By which I mean: remove Section 7.1 entirely. >=20 > I am not sure it shall be removed, because I think there IS something t= o say. But, the text needs to be adjusted, e.g., as following: >=20 > "7.1. Check List State >=20 > [rfc5245bis] specifies that, whenever timer Ta fires, only check lis= ts > in Running state will be picked in order to check for candidate pair= s > for which connectivity checks are scheduled. >=20 > Therefore, an Trickle ICE agent MUST keep each check list in Running= > state as long as new pairs are incrementally added to the check list= =2E > After that, the check list state is set according to the procedures = in > [rfc5245bis]." Yes, that is a more accurate description of trickle ICE agent behavior. Thanks for the text! Peter --E7e3tdjmDNx2swXEiV5ZJ4tkX1WZsmOXa-- --237jAviM57lyC1H0r307XOC7TGdHPNkwk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq6aSkACgkQZWGMGH9o FKkB1hAA3Ti21BwR8NU+yQA+QU1DrRDUSL95A8iHd4SKZDH6hxXCP4wdgtMCP7KC n7VYOYMnADwmZvPV7+bvoR27vC51g53fsO6sgRLttJB9FtiN28UV5dwksEKvruzh JfkoEHA/iuyLDBShN9tmBR70w8KUlxaxH/DKAzYHNPrW0g8ZCjBcrLfWagixUGSh E96mnxAkz/plpf2OuW3rLXHMITN6eyzgeNYNGv+V+RKx8FwP7DvgS6AO9nRpic+2 KrarOTxWqKrxvGffUEDBo+fc2EAtoz+oJj7704MDhTio5uKgk4FcPbsaD0fC4XUO l18r48MZ8wTcpYBZxxdQBxJf7OAWTP8wCipTACjGX3YAJXtrzksFeyS+TgHf2FUd DT1BouwOrgG/1jS4AnNzWYqRvVxj3e/o1z+jgJKCTs9ZyzYiuO2EjGc5UzAC5CX8 sXWjmpfnykJc7oH7nWSWGsC7EjO0EV03SgAqCW2ZQlcp/TmCPW+3UjmWi1SMW1/s 8FnIj9TB3SfjbtaE9a+FnNxaVOmU1pip6QqFB1Fjz8WE5VfCM1iKWOo5uIt6Iusk NOi96JL7GLchiVTm9Uw72MkPbDqyyW4phwamw7ck1LnHNj1Of+iEFDJ9okNxARSH f4BdQyusnE9AIFIHYkDqjQjxR6KD4SRFceg84k7pgYMczlRzdp0= =0i0X -----END PGP SIGNATURE----- --237jAviM57lyC1H0r307XOC7TGdHPNkwk-- From nobody Tue Mar 27 09:34:37 2018 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 E218312946D for ; Tue, 27 Mar 2018 09:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 wNtBYaz8zrQh for ; Tue, 27 Mar 2018 09:34:33 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 ED6B1127863 for ; Tue, 27 Mar 2018 09:34:32 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id k135-v6so12703ite.2 for ; Tue, 27 Mar 2018 09:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=/ISRJWOcJAu73VlYw2Fy7y3RF3v86JdS/YQ8LjdSCPE=; b=X0n1K7DPhLDuegDPoD0QKCig3Us5CaMJb/DdhaiP/t571V+aeS/RN+KiaTcnYY9xGH /nCWFmT4wu3KKfhTYac+gGcj51FKTOTevCs6oaz8guLGhyKhOuPqMx6F+sG48Gzwwc48 JRgUPDXhHFboaU4IUFpAtLYlJplCgTRHwpUxs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=/ISRJWOcJAu73VlYw2Fy7y3RF3v86JdS/YQ8LjdSCPE=; b=GNO/VD8W+7mDl57Elle6vMfHmcXETr39YKBpOwkwBf9ufi92OK/I1cGh3D0Hl8Tr0m 1EbfPYeSXHODkC5XDefkTRPj0RGgBpPk3f1srl63SAhCHMuB2aNmddHpvoRym98eWatA 1eEBqSrJJvyoYHMZiWmeZey168TMeldAkvonHbhdLUPNFaTczMSI2EQOrWqAVAaCEjRc LQFa6gpflgK6E9pFQeg92TP3PfHQ5C3sq5bpB/JXZKIdLHVEzmG5aJAMoKLFpp3bp8MN FVno36v32Uyaf7CmykGam//6sEfKnsc0P6iISk7XYhnX4fGDzf1lXHTmjNOPugQCRkb1 XJOg== X-Gm-Message-State: ALQs6tBHnkOltGYf35sQxVIVIw0aNXxCZv3WqhwsoqDTBG7per60EcSu h39sREI9xDSDHVtYb/i2LxPTksHgfzQ= X-Google-Smtp-Source: AIpwx48w8h0nKgzyQKWxhLZVJhvECFNihhdOdSGE6Mft6xabwUSbJ6NqrL4S1BmmwoDAvEo225FKWg== X-Received: by 2002:a24:bd0c:: with SMTP id x12-v6mr25864ite.97.1522168472142; Tue, 27 Mar 2018 09:34:32 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id 12-v6sm13061423itm.0.2018.03.27.09.34.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 09:34:31 -0700 (PDT) To: Christer Holmberg , Emil Ivov Cc: "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E16793@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E177D7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E178DD@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: <5ea04626-5c4a-a7a0-f1fe-cd29424f5fc9@mozilla.com> Date: Tue, 27 Mar 2018 10:34:29 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E178DD@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KrEOMw4Gapk8KpHVtbxSRWP6rJn5ziwUW" Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 27 Mar 2018 16:34:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KrEOMw4Gapk8KpHVtbxSRWP6rJn5ziwUW Content-Type: multipart/mixed; boundary="auT9l0tvxLIH5KccHtGBuMaZ19rQEwhKO"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , Emil Ivov Cc: "ice@ietf.org" Message-ID: <5ea04626-5c4a-a7a0-f1fe-cd29424f5fc9@mozilla.com> Subject: Re: [Ice] Trickle: A couple of questions on section 7 References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E16793@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E177D7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E178DD@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E178DD@ESESSMB109.ericsson.se> --auT9l0tvxLIH5KccHtGBuMaZ19rQEwhKO Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/24/18 11:37 AM, Christer Holmberg wrote: > Hi, >=20 > Below is some comments on the current text in section 7.2: >=20 > (In general, please replace "The ICE specification" with "[rfc5245bis]"= =2E)=20 Although opinions vary on this stylistic question, over the years I've come to see the wisdom of using xref only for the actual citation and not in running prose. Thus I'd prefer not to make this change. > --- >=20 > +7.2. Check List and Timer State Updates > + > + The ICE specification [rfc5245bis], Section 7.2.5.3.3, requires tha= t > + agents update check lists and timer states upon completing a > + connectivity check transaction. During such an update, regular ICE= > + agents would set the state of a check list to Failed if both of the= > + following two conditions are satisfied: > + > + o all of the pairs in the check list are either in the Failed stat= e > + or Succeeded state; and > + > + o there is not a pair in the valid list for each component of the > + media stream. > + > + With Trickle ICE, the above situation would often occur when > + candidate gathering and trickling are still in progress, even thoug= h > + it is quite possible that future checks will succeed. For this > + reason, Trickle ICE agents add the following conditions to the abov= e > + list: > + > + o all candidate gathering has completed and the agent is not > + expecting to discover any new local candidates; > + > + o the remote agent has conveyed an end-of-candidates indication fo= r > + that check list as described in Section 8.2. >=20 > [Christer] I think more or less everything above is covered by the new = text I suggested for section 7.1. In short: keep the check list in Runnin= g state until there are no more trickled pairs. Agreed. > + When a check list is set to Failed as described above, regular ICE > + requires the agent to update all other check lists, placing one pai= r > + from each check list into the Waiting state=20 >=20 > [Christer] I don't think this is true. Is there text in 5245bis definin= g this? >=20 > + and thereby effectively placing all remaining check lists into the = Running state. =20 >=20 > [Christer] This sounds weird. In 5245bis all check lists states are set= to Running by default. Here again, I don't think we need to summarize what 5425bis says. > + However, > + under Trickle ICE other check lists might still be empty at this > + point (because candidates have not yet been received), and followin= g > + only the rules from regular ICE would prevent the agent from formin= g > + those check lists (because the state of a check list depends on the= > + state of the candidate pairs in that check list, but there might no= t > + yet by any candidate pairs in a given check list). In accordance > + with the ICE specification [rfc5245bis], Section 6.1.2.1, a Trickle= > + ICE agent considers an empty check list to be in the Running state;= >=20 > [Christer] This can be simplified: simply indicate that some check list= s may initially be empty, but are still initially set in Running state ac= cording to the procedures in 5245bis. In addition you can say that, whene= ver Ta fires and an empty check list is picked, no actions are performed = for that check list. >=20 > + in accordance with Section 8.1.1, when inserting a new candidate pa= ir > + into an empty check list, the agent sets the pair to a state of > + Waiting. >=20 > [Christer] This is not needed here. Section 8.1.1 defines the state of = new candidate pairs, no matter if they are inserted into an empty or non-= empty check list. >=20 > So, based on my analysis, the only thing you need to keep is the empty = check list part. Agreed. Peter --auT9l0tvxLIH5KccHtGBuMaZ19rQEwhKO-- --KrEOMw4Gapk8KpHVtbxSRWP6rJn5ziwUW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq6cpYACgkQZWGMGH9o FKnk2xAAoXuKaari006677Tey+ZJ5yHkVVAgK/x7yd58yz0P1kHInz8QjM4SmXdw Czs2dvlmANFrRgZu59sFYGVW5K7FDwvf5ApUp3HmeT3ry3tLkQdB8YNeeRpxz/7q vmBldcrGtvHdFplhT5DDhd/6Fms2u8LKjFAcbB9IGsOJvJpvy6yU9780iThLJYhB VwTwwL1RLc2CkigsqS//Jc8uJrgbqyogP/xgxR3gaxfo69F9OnvBnfUzfzYCw7U9 CYWSDqD7IRYGn5BaeFHPOQ9QI8uhgUOnHfZs95HGR/q6VxzR/sUsqMcBPU6JSyfv 6VJPtT101P0d/pq+fnFegjlDDHntz8oz/CBltHmtblgk+p671ipfV+Zw5y4yStbQ hA/Sz+WvylO9zJxST5VtQ1YWuPNS6WB28IkZQQJMKnPzmuAZxv0sP8y6YNfK7G+Z tilpGFQbFZILpuxWopLBPTq0ZROXIR6PfpR0/uKluFRKNEP4y79ZiUFwW5Ie4ckH Pm6fuhzNRYvGaQgdc/EzfyYDtJ+xlf8F+xS6OXzsqEbEsG9Akim/m8QJ4cofkywX YDPWlEYiAGzIO/qYTaJ4Y13URBJ2xANbZBiYNY4IBiAsXPgGLXHczHAVAUhr6gY9 EEc9IEwWh473hdoNfcYC+I9ZEzSM1oxVlAwBqXvXW3nTRAliseM= =MMo6 -----END PGP SIGNATURE----- --KrEOMw4Gapk8KpHVtbxSRWP6rJn5ziwUW-- From nobody Tue Mar 27 10:40:06 2018 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 ED99512D953 for ; Tue, 27 Mar 2018 10:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 pZJDGAoI4E_G for ; Tue, 27 Mar 2018 10:40:03 -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 35453124E15 for ; Tue, 27 Mar 2018 10:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522172401; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ves5fL9pvUmNbMlYexMy/2MV4/k8ZOFIK6lAommVeEA=; b=QI3fXJ6S7YRQZme2c2Hw9ZxvC0yMhA/Y9DIWeIkoMFHoHx2UBeWLY2uFTu3YaDXL vHALo9sq451QWrvlfto0qvUKv1ANXKwjs6fM3YX3uDiAE59EQySwqk+iuwTBO0PF bo27HGKqJ0vEgNNVHJzDHXqXCjaCdWPEiW/zaRZG7zQ=; X-AuditID: c1b4fb25-b1fff70000000e6d-9f-5aba81f1cba2 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 64.9B.03693.1F18ABA5; Tue, 27 Mar 2018 19:40:01 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0382.000; Tue, 27 Mar 2018 19:40:00 +0200 From: Christer Holmberg To: Peter Saint-Andre , Emil Ivov CC: "ice@ietf.org" Thread-Topic: [Ice] Trickle: A couple of questions on section 7 Thread-Index: AdOucJgg+M5x/JnqQAe0nEYDsAIfMAGg2MuAAA3ZuwAABI1rgAAGIuKAAsuWQQAADPksAACw8cdgAAQNEIAAkZr7AAAHeBHw Date: Tue, 27 Mar 2018 17:40:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E33305@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E16793@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E177D7@ESESSMB109.ericsson.se> <7f3ebc1f-8b8a-cce2-6758-5ef3b5c9b717@mozilla.com> In-Reply-To: <7f3ebc1f-8b8a-cce2-6758-5ef3b5c9b717@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.169] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbHdWPdj464ogy9nFC3W7JzAYvHtQq3F s5WnGB2YPZYs+cnk8f9NoEffgS7WAOYoLpuU1JzMstQifbsErozGe+tYCjYoVHS9vsbSwHhE vouRk0NCwERi8a+3rF2MXBxCAkcYJdZNnMMM4SxhlFi2ZRaQw8HBJmAh0f1PG6RBRMBD4um6 j2BhZgFFiZd71UDCwgJ2Er3n17BDlNhLbOu9xgJh50nM+d7CClLOIqAq8aWVGyTMK+Ar8fTF JjaITc9YJOb3TQLr5QTq/TOjgw3EZhQQk/h+ag0TiM0sIC5x68l8JoibBSSW7DnPDGGLSrx8 /I8VwlaSONm9mQXiNE2J9bv0IVoVJaZ0P2SH2CsocXLmE5YJjKKzkEydhdAxC0nHLCQdCxhZ VjGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIERszBLb9VdzBefuN4iFGAg1GJh3d79K4oIdbE suLK3EOMEhzMSiK8mYJAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwPzTdHCQmkJ5akZqemFqQW wWSZODilGhhb+Zk4D9jM7pPqeKrldzHcoO/bwivtOVYK4v80WM8+4dKc4v7b/s6eUBHOlQli +txe05R+uHWYck3QyDja1/K4oPHH4wOvn/zWEfp+rOSQ5VrHTo7b03fOkxHKerE+ccUJwUSz kKIdntExKyVfFC7q/1CmZvl8gUBR3b6THPc8tapactUf2CixFGckGmoxFxUnAgDOrwSYlAIA AA== Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 27 Mar 2018 17:40:05 -0000 SGksDQoNCj4+Pj4+Pj4+IFEyOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFNlY3Rpb24gNy4yIHNheXM6 DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgwrNXaGVuIGEgY2hlY2sgbGlzdCBpcyBzZXQgdG8gRmFp bGVkIGFzIGRlc2NyaWJlZCBhYm92ZSwgcmVndWxhciBJQ0UNCj4+Pj4+Pj4+ICAgIHJlcXVpcmVz IHRoZSBhZ2VudCB0byB1cGRhdGUgYWxsIG90aGVyIGNoZWNrIGxpc3RzLCBwbGFjaW5nIG9uZSBw YWlyDQo+Pj4+Pj4+PiAgICBmcm9tIGVhY2ggY2hlY2sgbGlzdCBpbnRvIHRoZSBXYWl0aW5nIHN0 YXRlIGFuZCB0aGVyZWJ5IGVmZmVjdGl2ZWx5DQo+Pj4+Pj4+PiAgICBwbGFjaW5nIGFsbCByZW1h aW5pbmcgY2hlY2sgbGlzdHMgaW50byB0aGUgUnVubmluZyBzdGF0ZS7Csg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+IEV4YWN0bHkgd2hhdCBwcm9jZWR1cmUgaW4gNTI0NWJpcyBkb3MgdGhpcyB0ZXh0IHJl ZmVyIHRvPw0KPj4+Pj4+Pg0KPj4+Pj4+PiBFeGFjdGx5IHRoZSBwYXJ0cyB0aGF0IHdlIGRpc2N1 c3NlZCBhbmQgYWdyZWVkIHRvIGNoYW5nZSBpbiANCj4+Pj4+Pj4gUHJhZ3VlIGxhc3QgeWVhci4g SSB0aGluayB0aGlzIHBhcnQgaXMgbm8gbG9uZ2VyIG5lY2Vzc2FyeSBnaXZlbiANCj4+Pj4+Pj4g aG93IHRoZXkgYXJlIGNvdmVyZWQgYnkgNTI0NWJpcy4NCj4+Pj4+Pg0KPj4+Pj4+IEJ1dCwgYXJl IHlvdSBzYXlpbmcgdGhhdCB0aGUgdGV4dCBhYm92ZSBpcyBhY2NvcmRpbmcgdG8gNTI0NWJpcz8N Cj4+Pj4+DQo+Pj4+PiBJIGNhbid0IHNwZWFrIGZvciBFbWlsLCBidXQgSU1ITyBpdCdzIGJlc3Qg dG8gcmVtb3ZlIHRoYXQgdGV4dCBzbyANCj4+Pj4+IHRoZSBxdWVzdGlvbiBpcyBtb290Lg0KPj4+ Pg0KPj4+PiBMb29raW5nIGF0IHRoaXMgZnVydGhlciwgSSByZWFsaXplIHRoYXQgSSBoYXZlIGEg cXVlc3Rpb24gYWJvdXQgNTI0NWJpczoNCj4+Pj4gYWNjb3JkaW5nIHRvIElDRSBDb3JlLCBpcyBp dCBwb3NzaWJsZSB0byBoYXZlIGFuIGVtcHR5IGNoZWNrIGxpc3Q/IA0KPj4+PiBCeSBteSByZWFk aW5nIG9mIFNlY3Rpb24gNi4xLjIsIGEgY2hlY2sgbGlzdCBtdXN0IGhhdmUgY2FuZGlkYXRlIHBh aXJzIGluIGl0Lg0KPj4+PiBIb3dldmVyLCBpbiBUcmlja2xlIElDRSB3ZSBjYW4gaGF2ZSBlbXB0 eSBjaGVjayBsaXN0cy4gVGhhdCdzIGF0IA0KPj4+PiBsZWFzdCBpbiBwYXJ0IHdoYXQgU2VjdGlv biA3LjIgb2YgdGhlIHRyaWNrbGUgc3BlYyBpcyBhYm91dC4NCj4+Pg0KPj4+IEkgYW0gbm90IHN1 cmUgd2hhdCBhbiBlbXB0eSBjaGVjayBsaXN0IGlzLiANCj4+IA0KPj4gSSB3aXRoZHJhdyB0aGF0 IHN0YXRlbWVudC4gSSB3YXMgdGhpbmtpbmcgYWJvdXQgc29tZXRoaW5nIGVsc2UuDQo+PiANCj4+ IE5vdywgNTI0NWJpcyBvYnZpb3VzbHkgYXNzdW1lIHRoYXQgdGhlcmUgYXJlIGNhbmRpZGF0ZSBw YWlycyBpbiBlYWNoIA0KPj4gY2hlY2sgbGlzdCBmcm9tIHRoZSBiZWdpbm5pbmcuDQo+DQo+IFll cy4NCj4NCj4+IFNvLCBpZiB0aGUgb25seSB0aGluayB5b3Ugd2FudCB0byBzYXkgaXMgdGhhdCBh IGNoZWNrIGxpc3QgbWlnaHQgaW5pdGlhbGx5IA0KPj4gYmUgZW1wdHksIEkgdGhpbmsgdGhlIHNl Y3Rpb24gbmFtZSBzaG91bGQgYmUgIkVtcHR5IENoZWNrIExpc3RzIiwgYW5kIA0KPj4gdGhlbiB5 b3Ugb25seSBuZWVkIGEgY291cGxlIG9mIHNlbnRlbmNlcyB0byBwb2ludCBpdCBvdXQuDQo+DQo+ IEkgc3VnZ2VzdDoNCj4NCj4gICBBIFRyaWNrbGUgSUNFIGFnZW50IHdpbGwgY3JlYXRlIGEgY2hl Y2sgbGlzdCBldmVuIGlmIGl0IGRvZXMNCj4gICBub3QgeWV0IGhhdmUgYW55IGNhbmRpZGF0ZXMg dG8gcHV0IGluIHRoYXQgY2hlY2sgbGlzdCAodGhpcyBzY2VuYXJpbw0KPiAgIGRvZXMgbm90IGFy aXNlIHdpdGggbm9uLXRyaWNrbGUgYWdlbnRzLCBiZWNhdXNlIGFsbCBjYW5kaWRhdGVzIGFyZQ0K PiAgIGtub3duIHdoZW4gdGhlIGFnZW50IGNyZWF0ZXMgdGhlIGNoZWNrIGxpc3Qgc2V0KTsgaW4g YWNjb3JkYW5jZSB3aXRoDQo+ICAgdGhlIElDRSBzcGVjaWZpY2F0aW9uIFtyZmM1MjQ1YmlzXSwg U2VjdGlvbiA2LjEuMi4xLCBhIFRyaWNrbGUgSUNFDQo+ICAgYWdlbnQgY29uc2lkZXJzIGFuIGVt cHR5IGNoZWNrIGxpc3QgdG8gYmUgaW4gdGhlIFJ1bm5pbmcgc3RhdGUuDQoNCkEgY2hlY2sgbGlz dCBkb2VzIG5vdCBjb250YWluIGNhbmRpZGF0ZXMsIGJ1dCBjYW5kaWRhdGUgcGFpcnMuIEl0IGlz IGFsc28gZ29vZCB0byBtZW50aW9uIGhvdyBhbiBlbXB0eSBsaXN0IGlzIHByb2Nlc3NlZCB3aGVu IFRhIGZpcmVzLiANCg0KU28sIGEgbW9kaWZpZWQgc3VnZ2VzdGlvbjoNCg0KICAgICBBIFRyaWNr bGUgSUNFIGFnZW50IG1pZ2h0IGNyZWF0ZSBhIGNoZWNrIGxpc3QgdGhhdCBpbml0aWFsbHkgZG9l cyBub3QgY29udGFpbg0KICAgICBhbnkgY2FuZGlkYXRlIHBhaXJzICh0aGV5IHdpbGwgYmUgaW5j cmVtZW50YWxseSBhZGRlZCkuIFRoaXMgaXMgcmVmZXJyZWQgdG8NCiAgICAgYXMgYW4gZW1wdHkg Y2hlY2sgbGlzdC4gU2ltaWxhciB0byBvdGhlciBjaGVjayBsaXN0cywgdGhlIHN0YXRlIG9mIGFu IGVtcHR5DQogICAgIGNoZWNrIGxpc3QgaXMgaW5pdGlhbGx5IHNldCB0byBSdW5uaW5nLCBpbiBh Y2NvcmRhbmNlIHdpdGggdGhlIElDRSBzcGVjaWZpY2F0aW9uDQogICAgIFtyZmM1MjQ1YmlzXSwg U2VjdGlvbiA2LjEuMi4xLg0KDQogICAgIFdoZW5ldmVyIHRpbWVyIFRhIGZpcmVzLCBhbmQgYW4g ZW1wdHkgY2hlY2sgbGlzdCBpcyBwaWNrZWQsIG5vIGFjdGlvbnMgaXMgcGVyZm9ybWVkDQogICAg IGZvciB0aGUgbGlzdC4gV2l0aG91dCB3YWl0aW5nIGZvciB0aW1lciBUYSB0byBleHBpcmUgYWdh aW4sIHRoZSBhZ2VudCBzZWxlY3RzIHRoZSBuZXh0DQogICAgIGNoZWNrIGxpc3QgaW4gdGhlIFJ1 bm5pbmcgc3RhdGUsIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgSUNFIHNwZWNpZmljYXRpb24NCiAg ICAgW3JmYzUyNDViaXNdLCBTZWN0aW9uIDYuMS40LjIuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCg== From nobody Tue Mar 27 11:29:14 2018 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 B804712D7E2 for ; Tue, 27 Mar 2018 11:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 pxPhkCPLnIgC for ; Tue, 27 Mar 2018 11:29:09 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 06E1E12AF84 for ; Tue, 27 Mar 2018 11:29:08 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id y128so421096iod.4 for ; Tue, 27 Mar 2018 11:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=UwhqZUCvzWia9u1CiUUHz5Lu7DlceKL+S8QNZ+6jc3Y=; b=ZHBG+LVD7/BH6tifSSm3ho7eR+TNSy9uqNl36v/8RFhg87swoCtwPTxhj9X4HYmG74 6bREIDTH5aD7doMjd8GqbastM7K4m44IMlql1BFaLW/EeM1d4Z2CEWQu+rD6CSvYYPv5 i2VMyEdZuWcfkPDYGuTddj5RBcak/P43snHPI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=UwhqZUCvzWia9u1CiUUHz5Lu7DlceKL+S8QNZ+6jc3Y=; b=SUcPk+ErnfzDkxjxJiOyGmiNV2sA77T9wbjF4O2hqWWfjcnpJ5rciwhMqXCxbM7weg DLmhpKLoYUp9glNEk+GIc44XCiv1yA4fSq9dqLSNxCHfeWVIkig7lKUWvtYLnJabYbNJ fupHMa74ByS3qJnM3zsKtbret7VsDdyLB0Ghb/VpB+r14Mw8XTwX+DGTDIIchjErtMYh Tz80BMfOt/HeELFfDuy0ukV3Vf08Z6pQo0AXCI7nv9DE5O1spvRWAjNnAZk1vhTc59+j vSQNM5Vi/qrTMYOjqLKqkknpGY+ATd7iHAC1CC4NnSCPyhRv1CYqpykx98blsHeZxeAn 9uzA== X-Gm-Message-State: AElRT7GyEcJOJs9CG9IV5MIn2895p24Ky6i3jJ1IO+v+9mzRiiCm2Ecz PHvaX55eXXykNgwtS3EgG4o8cpLhbyA= X-Google-Smtp-Source: AIpwx4831/7NHC9s9aDWIQG7ctj5tcVdcJsPm/5db7D/YHz4Ux5YJuBCK987/HGWTEYpXf9xG36bdg== X-Received: by 10.107.57.133 with SMTP id g127mr19276517ioa.52.1522175348152; Tue, 27 Mar 2018 11:29:08 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id u96sm1299393iou.58.2018.03.27.11.29.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 11:29:07 -0700 (PDT) To: Christer Holmberg , "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: Date: Tue, 27 Mar 2018 12:29:05 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zoUxGPRZwrsI9XQ8SK9eJsghUXz4wQGtu" Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 27 Mar 2018 18:29:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --zoUxGPRZwrsI9XQ8SK9eJsghUXz4wQGtu Content-Type: multipart/mixed; boundary="vIfPXYpMpqQ14VBK6Z5hbMZpDf20WcoJH"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , "ice@ietf.org" Message-ID: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> --vIfPXYpMpqQ14VBK6Z5hbMZpDf20WcoJH Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Christer, thanks for the continued feedback... On 3/24/18 11:11 AM, Christer Holmberg wrote: > Hi, >=20 > =A0 >=20 > I was reading the rules in section 8.1.1 on how to set the pair state > for trickled candidate pairs, and I think it can be simplified,=20 I'm hesitant to mess around with these rules, but let's discuss... > as follows: >=20 > =A0 >=20 > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 If there are no other pairs for the same f= oundation, set the > state to Waiting=A0=A0 (covers Case #1) That covers Case #1 but it is more restrictive because it doesn't cover the case where the new pair is not the only pair, just the topmost pair. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 If all other pairs for the same foundation= are in either the > Succeeded or Failed state, set the state to Waiting (covers Case #2) That covers Case #2 but it is more permissive because it also covers the case where the new pair is not immediately below the Succeeded pair and the case where the new pair is above the Succeeded pair but not topmost. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 If there are more than one pair for the sa= me foundation in > the Waiting state, set the state to Waiting (covers Case #3) That covers Case #3 but it is more permissive because it it also covers the case where, say, two pairs succeeded and one pair is waiting. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 If there is exactly one pair for the same = foundation in the > Waiting state, set the state to Frozen (covers Case #4) >=20 > =A0 >=20 > Am I missing some case? Maybe? ;-) I agree that the rules as written are complicated, but perhaps that's unavoidable. > Also, if you want to keep the tables, I think it would be good to > indicate in the table which pair(s) were inserted, using some special > character. >=20 > Currently the text says things like =93two newly formed pairs were plac= ed > in column 5, rows 3 and 4=94, which is ok, but I also think it should b= e > shown in the table. Good suggestion. BTW, are you still reviewing the spec, or can we publish -18 once we're done with the issues you've already sent to the list? Peter --vIfPXYpMpqQ14VBK6Z5hbMZpDf20WcoJH-- --zoUxGPRZwrsI9XQ8SK9eJsghUXz4wQGtu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq6jXEACgkQZWGMGH9o FKlVlA//ZkbPmj02IV/FcjyAB1Vl80RYTtRd+4W4t5rtn7Pmr0EiyZkb09VX89pw tUteLYuRiufGNBe4/8Ymkv0QHIqFADuolvNMTPM/PICZ/7pzNfWlHlL0UGrz3TVs 8A5CjzZ1q2TbBxF3DdJHYuqQ77I59fnaZhSrHD8JWd0y0H29HFMcjfRd0tFFUs34 wECHss0DNop6cwmngPq2GKToQvnjRJ5A9c5r4TY6gvjmfIoxUoEFBfp6K6l1YejF TT4yVIJ7nZx5rNOTmBUvxFggUn4cIJY1dZ1xe+n9tlL43oT2PnSik+E9PTRhvL9J In0T13cA6RrOnjfBOYA4BDFZ1dbkQl+arWcFkvZcgBn7IS3kdfLmgo34kG1JgpPz UMAghqIT1VvYcdwQ1nfHhzZMxskQZWb+rYWGk1G17SfisjVCILlgasfGQzp/NYtf VnnFRpTY+KffbqOE9ejg+cVy/Vju5HTk45l+hyKqBJUh1D4EBdmcXrgMPxPL1oz0 jJSpZItWKvDwCKeAJSturr1+GiJlfP6rEmM9Vrc6G4raYD/CTHHUAVpTfxf0TlBG we3dwWmgYo5J6eTFCoSfJIX1mhd8x4aUISaxScrpL3pRrHsHeqpDJCjMCFMr72Bt 77sn4oveUe6molERADLBOvRi5QV7VAClWN0cUy9w9ecp7PpU44k= =XjpP -----END PGP SIGNATURE----- --zoUxGPRZwrsI9XQ8SK9eJsghUXz4wQGtu-- From nobody Tue Mar 27 11:41:39 2018 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 2025D126B6E for ; Tue, 27 Mar 2018 11:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 lj6INAL3k8Di for ; Tue, 27 Mar 2018 11:41:35 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 1695B120227 for ; Tue, 27 Mar 2018 11:41:35 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id c1-v6so474163itj.1 for ; Tue, 27 Mar 2018 11:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=N++eVJj3N0jLsoDPyRLjCKBr9SW3c8AxOHqfwLfo/Vs=; b=NAnQE9CiO/z9x6KuIa8tcWtfNTWSUugD9IMFeVnCF9E1gScDbhbuJkaxG1pPqVS9YI +cKQMhMc4H4yJeiiSTIdUGjp7aMJCvE1URztzLD5i4b0HnonKdWUBPUHAddCGgc/qNn5 URnACo7K9ZC6Japq5eBczlIgTjXl4Y59EXoqA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=N++eVJj3N0jLsoDPyRLjCKBr9SW3c8AxOHqfwLfo/Vs=; b=QTub7vHp4kf1eB6JN7DAvXu+lkRwzvx3mG96qtisGIX3KTLp94Ri0KK8E5djHDUZDR XyHbFRHZI2J5dQp8NsU5b0ac8J4tQPzwrJNf4TBi96vXsIV1HgWXpi3NmLCMsKZeADou bZ4qIvbt+hw+WryAgDYHHzpvVBmNi7eQl4g1z63xBI8lSpHB9O3nWja1OY+12x+WEuAw iJccbQwNXRr9JwpKT45uXGtzL8e/fq7ZfTk7kbO3Nv9/1HGaqABciE5r1GswZd046cn9 noXR7PZEm5udbKaxZvMn4C/bifBqaSS28PyAM6On+dn6qVXCX+/JGK3mSuaabfGztL6G 2pvA== X-Gm-Message-State: ALQs6tCWhTWk4CDut2p9lTNAr6sxtA4uu6KDt91nTZl0WaSLc97fnvRo s5du8KgqNFPSVdD4AaCgyIm0Ew== X-Google-Smtp-Source: AIpwx48WN3fuQFyJRgQw3i29rttVg5ek6j+3sdudyStjyiOJ6LNcPU6I6EdGU9yuFqBLCvvS1K+HEA== X-Received: by 2002:a24:39c8:: with SMTP id l191-v6mr397836ita.81.1522176094355; Tue, 27 Mar 2018 11:41:34 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id v70sm1273695ioi.32.2018.03.27.11.41.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 11:41:33 -0700 (PDT) To: Christer Holmberg , Emil Ivov Cc: "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E16793@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E177D7@ESESSMB109.ericsson.se> <7f3ebc1f-8b8a-cce2-6758-5ef3b5c9b717@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E33305@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: Date: Tue, 27 Mar 2018 12:41:32 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E33305@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nDo8oboP7mUgeaGQSjepg33PtWeFrI1Tr" Archived-At: Subject: Re: [Ice] Trickle: A couple of questions on section 7 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, 27 Mar 2018 18:41:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nDo8oboP7mUgeaGQSjepg33PtWeFrI1Tr Content-Type: multipart/mixed; boundary="5lUbRFlIlKVDVvrAk12Qmhx5XD1tq0bAP"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , Emil Ivov Cc: "ice@ietf.org" Message-ID: Subject: Re: [Ice] Trickle: A couple of questions on section 7 References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> <38e89900-5280-42d7-102a-c9ad1caca349@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E16793@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E177D7@ESESSMB109.ericsson.se> <7f3ebc1f-8b8a-cce2-6758-5ef3b5c9b717@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E33305@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E33305@ESESSMB109.ericsson.se> --5lUbRFlIlKVDVvrAk12Qmhx5XD1tq0bAP Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/27/18 11:40 AM, Christer Holmberg wrote: > Hi, >=20 >>>>>>>>> Q2: >>>>>>>>> >>>>>>>>> Section 7.2 says: >>>>>>>>> >>>>>>>>> =C2=B3When a check list is set to Failed as described above,= regular ICE >>>>>>>>> requires the agent to update all other check lists, placing = one pair >>>>>>>>> from each check list into the Waiting state and thereby effe= ctively >>>>>>>>> placing all remaining check lists into the Running state.=C2= =B2 >>>>>>>>> >>>>>>>>> Exactly what procedure in 5245bis dos this text refer to? >>>>>>>> >>>>>>>> Exactly the parts that we discussed and agreed to change in=20 >>>>>>>> Prague last year. I think this part is no longer necessary given= =20 >>>>>>>> how they are covered by 5245bis. >>>>>>> >>>>>>> But, are you saying that the text above is according to 5245bis? >>>>>> >>>>>> I can't speak for Emil, but IMHO it's best to remove that text so = >>>>>> the question is moot. >>>>> >>>>> Looking at this further, I realize that I have a question about 524= 5bis: >>>>> according to ICE Core, is it possible to have an empty check list? = >>>>> By my reading of Section 6.1.2, a check list must have candidate pa= irs in it. >>>>> However, in Trickle ICE we can have empty check lists. That's at=20 >>>>> least in part what Section 7.2 of the trickle spec is about. >>>> >>>> I am not sure what an empty check list is.=20 >>> >>> I withdraw that statement. I was thinking about something else. >>> >>> Now, 5245bis obviously assume that there are candidate pairs in each = >>> check list from the beginning. >> >> Yes. >> >>> So, if the only think you want to say is that a check list might init= ially=20 >>> be empty, I think the section name should be "Empty Check Lists", and= =20 >>> then you only need a couple of sentences to point it out. >> >> I suggest: >> >> A Trickle ICE agent will create a check list even if it does >> not yet have any candidates to put in that check list (this scenario= >> does not arise with non-trickle agents, because all candidates are >> known when the agent creates the check list set); in accordance with= >> the ICE specification [rfc5245bis], Section 6.1.2.1, a Trickle ICE >> agent considers an empty check list to be in the Running state. >=20 > A check list does not contain candidates, but candidate pairs.=20 Indeed. Sorry about the error. > It is also good to mention how an empty list is processed when Ta fires= =2E=20 >=20 > So, a modified suggestion: >=20 > A Trickle ICE agent might create a check list that initially does = not contain > any candidate pairs (they will be incrementally added). This is re= ferred to > as an empty check list. Similar to other check lists, the state of= an empty > check list is initially set to Running, in accordance with the ICE= specification > [rfc5245bis], Section 6.1.2.1. >=20 > Whenever timer Ta fires, and an empty check list is picked, no act= ions is performed > for the list. Without waiting for timer Ta to expire again, the ag= ent selects the next > check list in the Running state, in accordance with the ICE specif= ication > [rfc5245bis], Section 6.1.4.2. WFM. Peter --5lUbRFlIlKVDVvrAk12Qmhx5XD1tq0bAP-- --nDo8oboP7mUgeaGQSjepg33PtWeFrI1Tr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq6kFwACgkQZWGMGH9o FKmLBQ/+KR4LbkJNOE/b7XifmCsHyjZ543lhUobfM/ZVGyQ9eiviDxZGHxDXCAYq JMjK+JlyVG7Eh1zOdcdMCS5bV7K3lS2gh8dCqNw/dQQEUlQUSnzM7ngd0pk4KFd/ ygx36zLW0STdPkJbxVmmRUP9qZYgvRcuZWim/BxfCtfszgrkAmYs09gtzeJVNV2T w8kf/jUlyVSRzvnNAYFm2MWjHJI+rp8B0V8vrAk59+SPgXkyvBFA/8r1ZyA3coti IYXzRbzjW2grEi0lNq/RhVSpt1UYbTHd2AiX2kXx9TS7w7z+4jqNsh+vj3D6iZHe 36Twl893N0TnjLIXM2zNTqQnjMvcM7nRAsHljQGNtKMU2nI6o5LAlDqrM0GwiIhs u9rdRl5hRuNz2fi4wfUmS+Bx3Ifo4Rp1pXZBbwi3kS5xyTPpWF7UP9bx7Xh9it84 upwv4D/XaK5SC7xjTg24Pt/8Tf97xO6xeijVpVWuM6F7oU2ECviddj9oKgWlJcsq UYuEXDZx/lEg+CnPir+lv+7kUJquUWo75rZS3Q9d9EwGvGhvNKdf0G5y+3Mw4MLL aYMRE74FYCE/UVnqs2sd8ooRXX6iPjWRNsSehddRNNurp30idb3sRP8IjrZn+fBa f8EyQ0zDvxoXQUK3bWxMHoRhpdPUf9GbkPhLOtIhnAAxGb7k25o= =pKXe -----END PGP SIGNATURE----- --nDo8oboP7mUgeaGQSjepg33PtWeFrI1Tr-- From nobody Tue Mar 27 11:50:53 2018 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 060F212DB6C for ; Tue, 27 Mar 2018 11:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 C08WBCqRBYFX for ; Tue, 27 Mar 2018 11:50:35 -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 AFD2012DA51 for ; Tue, 27 Mar 2018 11:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522176617; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=M7YGyPiJh7TshLiELLA1IFiEDqz4q7i8vfjKHGEAb9o=; b=Fgvg3/A1+/svbQLlbdOQy+lJjAqBc/rBIt0x1AtNm691eGMOKc1DvAqI30sRYDe2 izENBtjiG6gXHF6YWnfIY+3kulktXhZI6N6pjD8vndzEmWaxxPPoP6JZv6jle1x7 eDgdR85zxpHyWlyg6Rod1otVya7mmAnECz2x/YSrbHA=; X-AuditID: c1b4fb3a-0efff70000007691-49-5aba9269f50a Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 33.4B.30353.9629ABA5; Tue, 27 Mar 2018 20:50:17 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0382.000; Tue, 27 Mar 2018 20:50:17 +0200 From: Christer Holmberg To: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] ICE trickle: Comment on section 8.1.1 Thread-Index: AdPDkuP38FvIt3+USwysDB0OImfNMwCVdT+AAATm0WA= Date: Tue, 27 Mar 2018 18:50:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E334BD@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.169] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7mW7mpF1RBrNPGlp8u1Br8WzlKUYH Jo8lS34yefQd6GINYIrisklJzcksSy3St0vgynjx8Sx7wQ6Rin+X1zE3ME4U6GLk5JAQMJGY d3oKexcjF4eQwBFGifZnPYwQzhJGiTPvz7F0MXJwsAlYSHT/0wZpEBHwkpi55z4TiC0MFP52 7iI7RNxSYuneFSwQtpXEwRntjCA2i4CqxKnG6cwgNq+Ar0TToTvMEPObGCV2v9kJluAUsJf4 Pe0zWDOjgJjE91NrwBYwC4hL3HoynwniUgGJJXvOM0PYohIvH/9jhbCVJE52b2aBqNeTuDF1 ChuErS2xbOFrqMWCEidnPmGZwCgyC8nYWUhaZiFpmYWkZQEjyypG0eLU4uLcdCMjvdSizOTi 4vw8vbzUkk2MwHg4uOW31Q7Gg88dDzEKcDAq8fC2dO2KEmJNLCuuzD3EKMHBrCTCmykIFOJN SaysSi3Kjy8qzUktPsQozcGiJM7rlGYRJSSQnliSmp2aWpBaBJNl4uCUamB0EeGunKRovO+R w/3Zb9Z7qtS/avi8yPTzmWyBJyJGR6J+PjoXdMeC+YfMhdapApo+vtsyLk9b0XtA91bF7pro olNfWSry/njJMvp5K6wXf1+0SIPl2Dyewk3LVzWn3awU2cTYNvlfUsrsVatX8zz3E+CXYE8z FWZ6uL9W7ejT+XtvdC1gvlCkxFKckWioxVxUnAgAw52a3oMCAAA= Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 27 Mar 2018 18:50:45 -0000 Hi, I will take a second look at the rules in section 8.1.1. I just want to mak= e sure they are aligned with the latest version of 5245bis. Regards, Christer -----Original Message----- From: Peter Saint-Andre [mailto:stpeter@mozilla.com]=20 Sent: 27 March 2018 20:29 To: Christer Holmberg ; ice@ietf.org Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 Hi Christer, thanks for the continued feedback... On 3/24/18 11:11 AM, Christer Holmberg wrote: > Hi, >=20 > =A0 >=20 > I was reading the rules in section 8.1.1 on how to set the pair state=20 > for trickled candidate pairs, and I think it can be simplified, I'm hesitant to mess around with these rules, but let's discuss... > as follows: >=20 > =A0 >=20 > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 If there are no other pairs for the same fou= ndation, set=20 > the state to Waiting=A0=A0 (covers Case #1) That covers Case #1 but it is more restrictive because it doesn't cover the= case where the new pair is not the only pair, just the topmost pair. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 If all other pairs for the same foundation a= re in either=20 > the Succeeded or Failed state, set the state to Waiting (covers Case=20 > #2) That covers Case #2 but it is more permissive because it also covers the ca= se where the new pair is not immediately below the Succeeded pair and the c= ase where the new pair is above the Succeeded pair but not topmost. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 If there are more than one pair for the same= foundation in=20 > the Waiting state, set the state to Waiting (covers Case #3) That covers Case #3 but it is more permissive because it it also covers the= case where, say, two pairs succeeded and one pair is waiting. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 If there is exactly one pair for the same fo= undation in the=20 > Waiting state, set the state to Frozen (covers Case #4) >=20 > =A0 >=20 > Am I missing some case? Maybe? ;-) I agree that the rules as written are complicated, but perhaps that's unavo= idable. > Also, if you want to keep the tables, I think it would be good to=20 > indicate in the table which pair(s) were inserted, using some special=20 > character. >=20 > Currently the text says things like "two newly formed pairs were=20 > placed in column 5, rows 3 and 4", which is ok, but I also think it=20 > should be shown in the table. Good suggestion. BTW, are you still reviewing the spec, or can we publish -18 once we're don= e with the issues you've already sent to the list? Peter From nobody Tue Mar 27 12:07:09 2018 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 9C22812D969 for ; Tue, 27 Mar 2018 12:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 NQn-GJmRvVP7 for ; Tue, 27 Mar 2018 12:07:05 -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 7BBB0120227 for ; Tue, 27 Mar 2018 12:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522177620; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=v6T5d1jcBC1AzrvX0RndPoYcajBG5ZncDskVjeIqoe0=; b=e+kbWybvc7qwH2mL18hIwa8qX8BSkAUvCrRsry4ZGIGDOzJSpTiTS3E8a2iVwlWP mtVkjtVWoBXzlc8AlNxdPkHbOc2jvmH9ZxVSTrrwt++96mswNwEqqWQUtyq10C6R k6Reb6kjSDbMhJ71ZSovWJ6JRfGh1xau/s/DWZ4JtJs=; X-AuditID: c1b4fb25-b1fff70000000e6d-0b-5aba96545896 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 02.A4.03693.4569ABA5; Tue, 27 Mar 2018 21:07:00 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0382.000; Tue, 27 Mar 2018 21:06:59 +0200 From: Christer Holmberg To: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] ICE trickle: Comment on section 8.1.1 Thread-Index: AdPDkuP38FvIt3+USwysDB0OImfNMwCVdT+AAAUSnMA= Date: Tue, 27 Mar 2018 19:06:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.169] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7pW7ItF1RBqd71Cy+Xai1eLbyFKMD k8eSJT+ZPPoOdLEGMEVx2aSk5mSWpRbp2yVwZUxbMpG5YK5oxYTXrxkbGC8KdDFyckgImEhM /LKdFcQWEjjCKDHreWUXIxeQvYRR4vLFk2xdjBwcbAIWEt3/tEFqRAS8JGbuuc8EYgsDhb+d u8gOEbeUWLp3BQuEbSVxdNptMJtFQFXieN8PNhCbV8BX4lvHQzaI+U2MErvf7GQGSXAK2Ev8 nvYZrIFRQEzi+6k1YAuYBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+xQthKEie7N7NA1OtJ3Jg6 hQ3C1pZYtvA1M8RiQYmTM5+wTGAUmYVk7CwkLbOQtMxC0rKAkWUVo2hxanFSbrqRsV5qUWZy cXF+nl5easkmRmA0HNzyW3UH4+U3jocYBTgYlXh4F3btihJiTSwrrsw9xCjBwawkwpspCBTi TUmsrEotyo8vKs1JLT7EKM3BoiTO+9B8c5SQQHpiSWp2ampBahFMlomDU6qBUWSa8/qVz1Q1 PLW2zVZZeFdor+/p+F+tdVvv7zmxsCnD53bUwS+zzNTfPW7+XSOuJPcj06VkmuZnkTYeqZRT 4rMVryhm5BmwPN+z/nFnhBBnNU9CfQqndfJlrZmut3jaime/mbjUffrF3iPZ3v8mrgpfvdno pJVYNfta+U/Xn3/0u3JPWW2vkBJLcUaioRZzUXEiALMwOTmCAgAA Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 27 Mar 2018 19:07:07 -0000 Hi, >> I was reading the rules in section 8.1.1 on how to set the pair state=20 >> for trickled candidate pairs, and I think it can be simplified, > >I'm hesitant to mess around with these rules, but let's discuss... My issue is that I have a feeling you are still using old 5245bis concepts. >> as follows: >>=20 >> =A0 >>=20 >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 If there are no other pairs for the same fo= undation, set the state to Waiting=A0=A0 (covers Case #1) > > That covers Case #1 but it is more restrictive because it doesn't cover t= he case where the new pair is not the only pair, just the topmost pair. Not sure I understand "is not the only pair". If there are no other pairs f= or the same foundation, the new pair IS the only pair for that foundation := ) =20 >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 If all other pairs for the same foundation = are in either=20 >> the Succeeded or Failed state, set the state to Waiting (covers Case=20 >> #2) > > That covers Case #2 but it is more permissive because it also covers the = case where the new pair is not=20 > immediately below the Succeeded pair and the case where the new pair is a= bove the Succeeded pair but not topmost. I don't understand the "immediately below" text etc. According to the procedures in Section 7.2.5.3.3. of 5245bis, once a pair s= ucceeds all Frozen pairs for the same foundation are set to Waiting. And, in case #2 at least one pair has succeeded, which means the new pair s= hould be set to Waiting. >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 If there are more than one pair for the sam= e foundation in=20 >> the Waiting state, set the state to Waiting (covers Case #3) > > That covers Case #3 but it is more permissive because it it also covers t= he case where, say, two pairs succeeded and one pair is waiting. Yes. I don't think that is a problem :) >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 If there is exactly one pair for the same f= oundation in the=20 >> Waiting state, set the state to Frozen (covers Case #4) >>=20 >> =A0 >>=20 >> Am I missing some case? > > Maybe? ;-) > > I agree that the rules as written are complicated, but perhaps that's una= voidable. > > Also, if you want to keep the tables, I think it would be good to=20 > indicate in the table which pair(s) were inserted, using some special=20 > character. >=20 > Currently the text says things like "two newly formed pairs were=20 > placed in column 5, rows 3 and 4", which is ok, but I also think it=20 > should be shown in the table. Good suggestion. BTW, are you still reviewing the spec, or can we publish -18 once we're don= e with the issues you've already sent to the list? Peter From nobody Tue Mar 27 13:01:09 2018 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 650FA127698 for ; Tue, 27 Mar 2018 13:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 cmJRXX3x3hu7 for ; Tue, 27 Mar 2018 13:01:06 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 627241273E2 for ; Tue, 27 Mar 2018 13:01:06 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id m134-v6so774095itb.3 for ; Tue, 27 Mar 2018 13:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=jA/q1vTOhT8p3PpFiYGVZ81zGlew2P1zAlbrlngeLyE=; b=KgyE4YC6tteMFD9eE0ZReRQu8jLIgSc0uuNwQ5JEmOBXmHUNs+w8tBsGYOW1EMDPzR vtWcH4XeqOX1lyJkt0IR7P0W8dwG+fQwerCx2Pc1S+6bzZu83XyPukFXMBA4xZ15T1MA 04FMsk3awTgWuUSPj51qNMGXuDSzZOrFukfyc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=jA/q1vTOhT8p3PpFiYGVZ81zGlew2P1zAlbrlngeLyE=; b=qyIPZQ9KL+y1BpaRDV+o5TM63ZryrE+fNpvAP5BJndcyHBxjP9aNNWRsXLLMB357ex 6jJu/1wbJIuBEryRkmRANCgGow+f6pQoLeas+Z+yb1KvElsHQl61i7RZ5KuYBIDqAzw0 qX8hOgftIcSmbyvU6xqpmPHdtCmBNc5fJYsIxWqp+tiTxZX05J+MOXrX2rdaIfbcc/eT MdqcMQFrnyXVsN0SS8hC01uX7d6hGERxj4LVyZtGq8x23zWKUv8hmCrQplfCX7Y4tuKP C2cFw03wewKZc8O98yUv4EhUCtniWII8GD07Bd6pxc71UuP/bgmsRqkUAS6f0pDtmKEY AMpA== X-Gm-Message-State: AElRT7FovQYtDCaZ9iwhUn+7e5N8Pb9b6NglbpMj9vN+0lFSwKLHKEfN +LvjqHcoGdgkXkSkVmHxENRM+w== X-Google-Smtp-Source: AIpwx4+wNbKmZK+jtzVdR0PkvJxOftovFAJxG5GljNRDRO6weTqaI4kJl0/9ScsatTNncMXMlGMhJA== X-Received: by 2002:a24:79ca:: with SMTP id z193-v6mr688668itc.7.1522180864984; Tue, 27 Mar 2018 13:01:04 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id k199-v6sm1587879itb.35.2018.03.27.13.01.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 13:01:04 -0700 (PDT) To: Christer Holmberg , "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> Date: Tue, 27 Mar 2018 14:01:03 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vRPbJXCu18uCYOgWISvjjWWHhOd6lHK5I" Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 27 Mar 2018 20:01:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vRPbJXCu18uCYOgWISvjjWWHhOd6lHK5I Content-Type: multipart/mixed; boundary="g16dLaNrO9dEmRu0LcQAtSJHGRsftD4tw"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , "ice@ietf.org" Message-ID: <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> --g16dLaNrO9dEmRu0LcQAtSJHGRsftD4tw Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/27/18 1:06 PM, Christer Holmberg wrote: > Hi, >=20 >>> I was reading the rules in section 8.1.1 on how to set the pair state= =20 >>> for trickled candidate pairs, and I think it can be simplified, >> >> I'm hesitant to mess around with these rules, but let's discuss... >=20 > My issue is that I have a feeling you are still using old 5245bis conce= pts. Alignment is hard. I'll look at it again. One thing that's bothering me about these rules is that they're written about the diagrams (e.g., "top-most pair") and not about protocol features (e.g., "the pair with the lowest component ID"). >>> as follows: >>> >>> =C2=A0 >>> >>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If there are = no other pairs for the same foundation, set the state to Waiting=C2=A0=C2= =A0 (covers Case #1) >> >> That covers Case #1 but it is more restrictive because it doesn't cove= r the case where the new pair is not the only pair, just the topmost pair= =2E >=20 > Not sure I understand "is not the only pair".=20 Let's say there are already two pairs for the 5th foundation: +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | m1 (Audio.RTP) | W | W | W | | | +-----------------+------+------+------+------+------+ | m2 (Audio.RTCP) | F | F | F | W | | +-----------------+------+------+------+------+------+ | m3 (Video.RTP) | F | | | | W | +-----------------+------+------+------+------+------+ | m4 (Video.RTCP) | F | | | | F | +-----------------+------+------+------+------+------+ Now we add a new pair "X", which has a lower component ID than the other pairs: +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | m1 (Audio.RTP) | W | W | W | | | +-----------------+------+------+------+------+------+ | m2 (Audio.RTCP) | F | F | F | W | ^X^ | +-----------------+------+------+------+------+------+ | m3 (Video.RTP) | F | | | | W | +-----------------+------+------+------+------+------+ | m4 (Video.RTCP) | F | | | | F | +-----------------+------+------+------+------+------+ That doesn't seem to be covered by your text. (I realize this is a contrived or wrong example - we'd likely get candidate pairs for both m1 and m2, or just m1. Imagine an example with even more media streams and you get the picture.) > If there are no other pairs for the same foundation, the new pair IS th= e only pair for that foundation :) > =20 >>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If all other = pairs for the same foundation are in either=20 >>> the Succeeded or Failed state, set the state to Waiting (covers Case = >>> #2) >> >> That covers Case #2 but it is more permissive because it also covers t= he case where the new pair is not=20 >> immediately below the Succeeded pair and the case where the new pair i= s above the Succeeded pair but not topmost. >=20 > I don't understand the "immediately below" text etc. >=20 > According to the procedures in Section 7.2.5.3.3. of 5245bis, once a pa= ir succeeds all Frozen pairs for the same foundation are set to Waiting. >=20 > And, in case #2 at least one pair has succeeded, which means the new pa= ir should be set to Waiting. I see your point. >>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If there are = more than one pair for the same foundation in=20 >>> the Waiting state, set the state to Waiting (covers Case #3) >> >> That covers Case #3 but it is more permissive because it it also cover= s the case where, say, two pairs succeeded and one pair is waiting. >=20 > Yes. I don't think that is a problem :) Ah, I see. The procedures you cite from Section 7.2.5.3.3. of 5245bis actually cover both Case #2 and Case #3, don't they? >>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If there is e= xactly one pair for the same foundation in the=20 >>> Waiting state, set the state to Frozen (covers Case #4) This is a fall-through case, isn't it? I'm not yet sure why we'd say anything other than "in all other cases, set to Frozen"... Peter --g16dLaNrO9dEmRu0LcQAtSJHGRsftD4tw-- --vRPbJXCu18uCYOgWISvjjWWHhOd6lHK5I Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq6ov8ACgkQZWGMGH9o FKkDhg//Q4x96DYBYZXE7F/xuTY8zCWyNVyd9eNgQc3hh6VYlwUvj/54ZMW9zkbV P3PFlP3OeqsqjI3TbjSDS4ggwI8Hejd9C1PKdwQeU+5PnexebAcvZIBbIOURrZTX ZgC2J3rMXumAh4N3srfMjtmyoTTrdk/57uxtP1Zl1DvN+gjTDPsiwK+enFBpqapP wgTTLnuCanVjvoEnzX5V05/fhwNrthEdqi2/raXVLOAj6MIuWkuWCVHkbfAzG9ox 5m5YkSzMMhlObOGwWh/uXbi5sjPBHJbDO92wOptIgTx84BVgyWjqSAdvpy5sLAEq ziQT4pB3qYie54zROWllZBA+kDgd+/iU1Z5fPI0qbsf1oVYT3zf/UzmMi9K83hJI mlMuxLu8QVLwhbtcauO80pu9FaL4JAzx7QY54D3XZuGfurz+UOsubdKA2UGXVqsN a/Tyv0/Q6/xU7382KVCy62Ymq1RjSZdYDn7pB9+OyUcKZhBIaDDuSFR0E2HMLVGw ZViX2tLgLKe/pPfbVxkZz+JqwN1jq8qhvPZFAds9Ug9goc/WSRvJg0o4q+4PXfMy qOACQbY/ScTI6iR7EpvToy7BL4RGFTiuT4Fdsos4FBTkF87jElBbjcvhzp0B/JYj vFR4/2BrLMBBDLLuPJQZmPP/4l9sP2TQk5rHBJYOcq03REU8BgA= =4BJW -----END PGP SIGNATURE----- --vRPbJXCu18uCYOgWISvjjWWHhOd6lHK5I-- From nobody Wed Mar 28 01:02:47 2018 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 2EB6E126D73 for ; Wed, 28 Mar 2018 01:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 iHPccL798M6R for ; Wed, 28 Mar 2018 01:02:44 -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 7C8F11200C1 for ; Wed, 28 Mar 2018 01:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522224162; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Slst6pr9po78azDKtyHG2SP2pECRl4OFFzR9SkRjKYE=; b=NjbPrFTHRkrDetFVJYyeYh+5qJxQjEyV52ch7lxjmEzYVOS6ExxBilrVwq2VuEkI RF3G+UGUZygz7Vz4i0cuZ0SbrY29Q6Hs4jWNnzDcNvT3SiCa/tdB3RXSnzZgCNqB ljPac4X1RMnVCv073DXQNmO1ZLdxYA6DC4YJdKV350I=; X-AuditID: c1b4fb30-81c549c00000197d-66-5abb4c22fb52 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 30.48.06525.22C4BBA5; Wed, 28 Mar 2018 10:02:42 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 10:02:38 +0200 From: Christer Holmberg To: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] ICE trickle: Comment on section 8.1.1 Thread-Index: AdPDkuP38FvIt3+USwysDB0OImfNMwCVdT+AAAUSnMD///EdgIAA/DAA Date: Wed, 28 Mar 2018 08:02:38 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> In-Reply-To: <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> 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: [131.160.50.130] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7hK6Sz+4og3mv1Sy+Xai1eLbyFKMD k8eSJT+ZPPoOdLEGMEVx2aSk5mSWpRbp2yVwZWz5HVXwQr3i+esOpgbGN7JdjJwcEgImEhcO PmfuYuTiEBI4wihxbu05RghnCaPEp8N32bsYOTjYBCwkuv9pgzSICHhJzNxznwnEFgYK/+jr YYeIW0os3buCBcJ2k7jROZkVxGYRUJV4s3kJE8gYXgFriQ3foHb9ZpRY27gIrJ5TwF5i4ZcO sDmMAmIS30+tAZvPLCAucevJfCaIQwUkluw5zwxhi0q8fPwPbL6ogJ7EhhO3wc6UEFCSuL3B CaJVT+LG1ClsELa1xKebh6FGakssW/gabAyvgKDEyZlPWCYwis1Csm0WkvZZSNpnIWmfhaR9 ASPrKkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzAiDq45bfBDsaXzx0PMQpwMCrx8Cp6744S Yk0sK67MPcQowcGsJML7XgMoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNfCb3OUkEB6Yklqdmpq QWoRTJaJg1OqgbEhjSV2vdmxFEPNyOt2gvGHVNve/OPeyLEvPpTl7ttf7h+na+U7bTzgtkea 2bpl+4QNyXpf9qZ2XahdWMt+98zTEsfzatPWfJqs5Husf5bougMKNncZF6X6qa80Ez1mtzrW Ivy48RPWXycDplnKsdZ9jr/NeO67zRKJJTklppzvtVLvugkaNSmxFGckGmoxFxUnAgCHpmSX pAIAAA== Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 28 Mar 2018 08:02:46 -0000 Hi, >>>>I was reading the rules in section 8.1.1 on how to set the pair state >>>> for trickled candidate pairs, and I think it can be simplified, >>> >>> I'm hesitant to mess around with these rules, but let's discuss... >>=20 >> My issue is that I have a feeling you are still using old 5245bis >>concepts. > >Alignment is hard. I'll look at it again. > >One thing that's bothering me about these rules is that they're written >about the diagrams (e.g., "top-most pair") and not about protocol >features (e.g., "the pair with the lowest component ID"). > >>>> as follows: >>>> >>>> =20 >>>> >>>> - If there are no other pairs for the same foundation, set >>>>the state to Waiting (covers Case #1) >>> >>> That covers Case #1 but it is more restrictive because it doesn't >>>cover the case where the new pair is not the only pair, just the >>>topmost pair. >>=20 >> Not sure I understand "is not the only pair". > >Let's say there are already two pairs for the 5th foundation: > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | W | W | W | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | F | F | F | W | | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | F | | | | W | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | F | | | | F | > +-----------------+------+------+------+------+------+ > >Now we add a new pair "X", which has a lower component ID than the other >pairs: > > > +-----------------+------+------+------+------+------+ > | | f1 | f2 | f3 | f4 | f5 | > +-----------------+------+------+------+------+------+ > | m1 (Audio.RTP) | W | W | W | | | > +-----------------+------+------+------+------+------+ > | m2 (Audio.RTCP) | F | F | F | W | ^X^ | > +-----------------+------+------+------+------+------+ > | m3 (Video.RTP) | F | | | | W | > +-----------------+------+------+------+------+------+ > | m4 (Video.RTCP) | F | | | | F | > +-----------------+------+------+------+------+------+ > >That doesn't seem to be covered by your text. It is not covered by case #1, because in case #1 there are no other pairs in the foundation :) The case above is covered by the following bullet I suggested: "- If there is exactly one pair for the same foundation in the Waiting state, set the state to Frozen (covers Case #4)=B2 So, in this case the state would be set to Frozen. An alternative would be to change the m3 pair to Frozen, and set the new pair to Waiting, but I think modifying the state of existing pairs would be messy. >(I realize this is a contrived or wrong example - we'd likely get >candidate pairs for both m1 and m2, or just m1. Imagine an example with >even more media streams and you get the picture.) > >> If there are no other pairs for the same foundation, the new pair IS >>the only pair for that foundation :) >> =20 >>>> - If all other pairs for the same foundation are in either >>>> the Succeeded or Failed state, set the state to Waiting (covers Case >>>> #2) >>> >>> That covers Case #2 but it is more permissive because it also covers >>>the case where the new pair is not >>> immediately below the Succeeded pair and the case where the new pair >>>is above the Succeeded pair but not topmost. >>=20 >> I don't understand the "immediately below" text etc. >>=20 >> According to the procedures in Section 7.2.5.3.3. of 5245bis, once a >>pair succeeds all Frozen pairs for the same foundation are set to >>Waiting. >>=20 >> And, in case #2 at least one pair has succeeded, which means the new >>pair should be set to Waiting. > >I see your point. > >>>> - If there are more than one pair for the same foundation in >>>> the Waiting state, set the state to Waiting (covers Case #3) >>> >>> That covers Case #3 but it is more permissive because it it also >>>covers the case where, say, two pairs succeeded and one pair is waiting. >>=20 >> Yes. I don't think that is a problem :) > >Ah, I see. The procedures you cite from Section 7.2.5.3.3. of 5245bis >actually cover both Case #2 and Case #3, don't they? Correct. When at least one pair is Succeeded, all non-Failed pairs (Frozen pairs and new trickled pairs) are set to Waiting. I think that would be a simple approach. >>>> - If there is exactly one pair for the same foundation in >>>>the=20 >>>> Waiting state, set the state to Frozen (covers Case #4) > >This is a fall-through case, isn't it? I'm not yet sure why we'd say >anything other than "in all other cases, set to Frozen"... Sure, we could do that. The simpler the better :) Regards, Christer From nobody Wed Mar 28 05:33:10 2018 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 1ADEC1242F7 for ; Wed, 28 Mar 2018 05:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 KMgG1w4v_Ezk for ; Wed, 28 Mar 2018 05:33:04 -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 29CB312702E for ; Wed, 28 Mar 2018 05:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522240374; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=axHJ3WvXGl0s8V6lcGUuM1DM7vtIAcDKF7akHFkQTbY=; b=eEJaHnxCA03bppk1kjSfZRP0TceQnP2l32o8f/3yoobE2jH6EM9A7yll4WXU97fH ImSeSUCNTxJD9a4upQLb+JjZ/qaWYN+C0ONE5aFvUmT1mwiA818el6YHLz9RHDll yKrDooBt9y337oItgifA3+yfLcTbfyDGekfjY/uSr0c=; X-AuditID: c1b4fb30-433ff7000000197d-dd-5abb8b76b64b Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 49.75.06525.67B8BBA5; Wed, 28 Mar 2018 14:32:54 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 14:32:43 +0200 From: Christer Holmberg To: Christer Holmberg , Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] ICE trickle: Comment on section 8.1.1 Thread-Index: AdPDkuP38FvIt3+USwysDB0OImfNMwCVdT+AAAUSnMD///EdgIAA/DAAgABLdoA= Date: Wed, 28 Mar 2018 12:32:42 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [131.160.50.130] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7sW5Z9+4og6urpC2+Xai1eLbyFKMD k8eSJT+ZPPoOdLEGMEVx2aSk5mSWpRbp2yVwZTSdn8BesMmuYuqco+wNjE9suhg5OSQETCSa ZnSydjFycQgJHGGUWNe3EMpZwijxcN9jpi5GDg42AQuJ7n/aIHERgQZGiZvTl7KBdAsDxX/0 9bCD2CIClhJL965ggbD9JKav3MMMYrMIqEpsmryRDWQOr4C1xP9XKhDz1zJJvNz1hxGkhlPA RmLGlp1gNqOAmMT3U2uYQGxmAXGJW0/mM0FcKiCxZM95ZghbVOLl43+sILaogJ7EhhO32UHm SwgoSdze4ATRqiXx5cc+NgjbWmLdpPmsELaixJTuh2An8woISpyc+YRlAqPYLCTbZiFpn4Wk fRaS9llI2hcwsq5iFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIyqg1t+G+xgfPnc8RCjAAej Eg8vX9XuKCHWxLLiytxDjBIczEoivO81gEK8KYmVValF+fFFpTmpxYcYpTlYlMR5Lfw2RwkJ pCeWpGanphakFsFkmTg4pRoYm16JC6+xmrzr+rzfXGZH2SY3cB3YNnvaep7lFvtNl284NSvy VtudaJVrcS92r7A3sBNc+lNfnXtj/wTV5dF6l19u8eDfkN056cajU5wTc2+LLzOb3VXKtHnf uSUr172SOijf0J2hsn774ygPbtlqrq7rTnt/d1vptxS5v/+0PSdLkS27QYH5mhJLcUaioRZz UXEiAO+JFlWmAgAA Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 28 Mar 2018 12:33:07 -0000 SGksDQoNCkkgdGhpbmsgdGhlIHJ1bGVzIGNvdWxkIGJlIHNpbXBsaWZpZWQgaW4gdGhlIGZvbGxv d2luZyB3YXk6DQoNCi0gSWYgdGhlcmUgYXJlIGF0IGxlYXN0IG9uZSBwYWlyIGluIFN1Y2NlZWRl ZCBzdGF0ZSwgc2V0IHRoZSBzdGF0ZSBvZiB0aGUNCm5ldyBwYWlyIHRvIFdhaXRpbmcNCi0gSWYg dGhlcmUgYXJlIHR3byBvciBtb3JlIHBhaXJzIGluIFdhaXRpbmcvSW4tUHJvZ3Jlc3Mgc3RhdGUs IHNldCB0aGUNCnN0YXRlIG9mIHRoZSBuZXcgcGFpciB0byBXYWl0aW5nDQotIE90aGVyd2lzZSBz ZXQgdGhlIHN0YXRlIG9mIHRoZSBuZXcgcGFpciB0byBGcm96ZW4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KDQoNCk9uIDI4LzAzLzE4IDExOjAyLCAiSWNlIG9uIGJlaGFsZiBvZiBDaHJpc3Rl ciBIb2xtYmVyZyINCjxpY2UtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCg0KPkhpLA0KPg0KPj4+Pj5JIHdhcyByZWFk aW5nIHRoZSBydWxlcyBpbiBzZWN0aW9uIDguMS4xIG9uIGhvdyB0byBzZXQgdGhlIHBhaXIgc3Rh dGUNCj4+Pj4+IGZvciB0cmlja2xlZCBjYW5kaWRhdGUgcGFpcnMsIGFuZCBJIHRoaW5rIGl0IGNh biBiZSBzaW1wbGlmaWVkLA0KPj4+Pg0KPj4+PiBJJ20gaGVzaXRhbnQgdG8gbWVzcyBhcm91bmQg d2l0aCB0aGVzZSBydWxlcywgYnV0IGxldCdzIGRpc2N1c3MuLi4NCj4+PiANCj4+PiBNeSBpc3N1 ZSBpcyB0aGF0IEkgaGF2ZSBhIGZlZWxpbmcgeW91IGFyZSBzdGlsbCB1c2luZyBvbGQgNTI0NWJp cw0KPj4+Y29uY2VwdHMuDQo+Pg0KPj5BbGlnbm1lbnQgaXMgaGFyZC4gSSdsbCBsb29rIGF0IGl0 IGFnYWluLg0KPj4NCj4+T25lIHRoaW5nIHRoYXQncyBib3RoZXJpbmcgbWUgYWJvdXQgdGhlc2Ug cnVsZXMgaXMgdGhhdCB0aGV5J3JlIHdyaXR0ZW4NCj4+YWJvdXQgdGhlIGRpYWdyYW1zIChlLmcu LCAidG9wLW1vc3QgcGFpciIpIGFuZCBub3QgYWJvdXQgcHJvdG9jb2wNCj4+ZmVhdHVyZXMgKGUu Zy4sICJ0aGUgcGFpciB3aXRoIHRoZSBsb3dlc3QgY29tcG9uZW50IElEIikuDQo+Pg0KPj4+Pj4g YXMgZm9sbG93czoNCj4+Pj4+DQo+Pj4+PiAgDQo+Pj4+Pg0KPj4+Pj4gLSAgICAgICAgICBJZiB0 aGVyZSBhcmUgbm8gb3RoZXIgcGFpcnMgZm9yIHRoZSBzYW1lIGZvdW5kYXRpb24sIHNldA0KPj4+ Pj50aGUgc3RhdGUgdG8gV2FpdGluZyAgIChjb3ZlcnMgQ2FzZSAjMSkNCj4+Pj4NCj4+Pj4gVGhh dCBjb3ZlcnMgQ2FzZSAjMSBidXQgaXQgaXMgbW9yZSByZXN0cmljdGl2ZSBiZWNhdXNlIGl0IGRv ZXNuJ3QNCj4+Pj5jb3ZlciB0aGUgY2FzZSB3aGVyZSB0aGUgbmV3IHBhaXIgaXMgbm90IHRoZSBv bmx5IHBhaXIsIGp1c3QgdGhlDQo+Pj4+dG9wbW9zdCBwYWlyLg0KPj4+IA0KPj4+IE5vdCBzdXJl IEkgdW5kZXJzdGFuZCAiaXMgbm90IHRoZSBvbmx5IHBhaXIiLg0KPj4NCj4+TGV0J3Mgc2F5IHRo ZXJlIGFyZSBhbHJlYWR5IHR3byBwYWlycyBmb3IgdGhlIDV0aCBmb3VuZGF0aW9uOg0KPj4NCj4+ ICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0r DQo+PiAgIHwgICAgICAgICAgICAgICAgIHwgIGYxICB8ICBmMiAgfCAgZjMgIHwgIGY0ICB8ICBm NSAgfA0KPj4gICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0t Ky0tLS0tLSsNCj4+ICAgfCBtMSAoQXVkaW8uUlRQKSAgfCAgVyAgIHwgIFcgICB8ICBXICAgfCAg ICAgIHwgICAgICB8DQo+PiAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0t LSstLS0tLS0rLS0tLS0tKw0KPj4gICB8IG0yIChBdWRpby5SVENQKSB8ICBGICAgfCAgRiAgIHwg IEYgICB8ICBXICAgfCAgICAgIHwNCj4+ICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS0t LS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+PiAgIHwgbTMgKFZpZGVvLlJUUCkgIHwgIEYgICB8 ICAgICAgfCAgICAgIHwgICAgICB8ICBXICAgfA0KPj4gICArLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSsNCj4+ICAgfCBtNCAoVmlkZW8uUlRDUCkg fCAgRiAgIHwgICAgICB8ICAgICAgfCAgICAgIHwgIEYgICB8DQo+PiAgICstLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKw0KPj4NCj4+Tm93IHdlIGFk ZCBhIG5ldyBwYWlyICJYIiwgd2hpY2ggaGFzIGEgbG93ZXIgY29tcG9uZW50IElEIHRoYW4gdGhl IG90aGVyDQo+PnBhaXJzOg0KPj4NCj4+DQo+PiAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0r LS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKw0KPj4gICB8ICAgICAgICAgICAgICAgICB8ICBm MSAgfCAgZjIgIHwgIGYzICB8ICBmNCAgfCAgZjUgIHwNCj4+ICAgKy0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+PiAgIHwgbTEgKEF1ZGlvLlJU UCkgIHwgIFcgICB8ICBXICAgfCAgVyAgIHwgICAgICB8ICAgICAgfA0KPj4gICArLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSsNCj4+ICAgfCBtMiAo QXVkaW8uUlRDUCkgfCAgRiAgIHwgIEYgICB8ICBGICAgfCAgVyAgIHwgXlheICB8DQo+PiAgICst LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKw0KPj4g ICB8IG0zIChWaWRlby5SVFApICB8ICBGICAgfCAgICAgIHwgICAgICB8ICAgICAgfCAgVyAgIHwN Cj4+ICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0t LS0rDQo+PiAgIHwgbTQgKFZpZGVvLlJUQ1ApIHwgIEYgICB8ICAgICAgfCAgICAgIHwgICAgICB8 ICBGICAgfA0KPj4gICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0t LS0tKy0tLS0tLSsNCj4+DQo+PlRoYXQgZG9lc24ndCBzZWVtIHRvIGJlIGNvdmVyZWQgYnkgeW91 ciB0ZXh0Lg0KPg0KPg0KPkl0IGlzIG5vdCBjb3ZlcmVkIGJ5IGNhc2UgIzEsIGJlY2F1c2UgaW4g Y2FzZSAjMSB0aGVyZSBhcmUgbm8gb3RoZXIgcGFpcnMNCj5pbiB0aGUgZm91bmRhdGlvbiA6KQ0K Pg0KPlRoZSBjYXNlIGFib3ZlIGlzIGNvdmVyZWQgYnkgdGhlIGZvbGxvd2luZyBidWxsZXQgSSBz dWdnZXN0ZWQ6DQo+DQo+Ii0gSWYgdGhlcmUgaXMgZXhhY3RseSBvbmUgcGFpciBmb3IgdGhlIHNh bWUgZm91bmRhdGlvbiBpbiB0aGUgV2FpdGluZw0KPnN0YXRlLCBzZXQgdGhlIHN0YXRlIHRvIEZy b3plbiAoY292ZXJzIENhc2UgIzQpqfcNCj4NCj5TbywgaW4gdGhpcyBjYXNlIHRoZSBzdGF0ZSB3 b3VsZCBiZSBzZXQgdG8gRnJvemVuLg0KPg0KPkFuIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvIGNo YW5nZSB0aGUgbTMgcGFpciB0byBGcm96ZW4sIGFuZCBzZXQgdGhlIG5ldw0KPnBhaXIgdG8gV2Fp dGluZywgYnV0IEkgdGhpbmsgbW9kaWZ5aW5nIHRoZSBzdGF0ZSBvZiBleGlzdGluZyBwYWlycyB3 b3VsZA0KPmJlIG1lc3N5Lg0KPg0KPg0KPg0KPj4oSSByZWFsaXplIHRoaXMgaXMgYSBjb250cml2 ZWQgb3Igd3JvbmcgZXhhbXBsZSAtIHdlJ2QgbGlrZWx5IGdldA0KPj5jYW5kaWRhdGUgcGFpcnMg Zm9yIGJvdGggbTEgYW5kIG0yLCBvciBqdXN0IG0xLiBJbWFnaW5lIGFuIGV4YW1wbGUgd2l0aA0K Pj5ldmVuIG1vcmUgbWVkaWEgc3RyZWFtcyBhbmQgeW91IGdldCB0aGUgcGljdHVyZS4pDQo+Pg0K Pj4+IElmIHRoZXJlIGFyZSBubyBvdGhlciBwYWlycyBmb3IgdGhlIHNhbWUgZm91bmRhdGlvbiwg dGhlIG5ldyBwYWlyIElTDQo+Pj50aGUgb25seSBwYWlyIGZvciB0aGF0IGZvdW5kYXRpb24gOikN Cj4+PiAgDQo+Pj4+PiAtICAgICAgICAgIElmIGFsbCBvdGhlciBwYWlycyBmb3IgdGhlIHNhbWUg Zm91bmRhdGlvbiBhcmUgaW4gZWl0aGVyDQo+Pj4+PiB0aGUgU3VjY2VlZGVkIG9yIEZhaWxlZCBz dGF0ZSwgc2V0IHRoZSBzdGF0ZSB0byBXYWl0aW5nIChjb3ZlcnMgQ2FzZQ0KPj4+Pj4gIzIpDQo+ Pj4+DQo+Pj4+IFRoYXQgY292ZXJzIENhc2UgIzIgYnV0IGl0IGlzIG1vcmUgcGVybWlzc2l2ZSBi ZWNhdXNlIGl0IGFsc28gY292ZXJzDQo+Pj4+dGhlIGNhc2Ugd2hlcmUgdGhlIG5ldyBwYWlyIGlz IG5vdA0KPj4+PiBpbW1lZGlhdGVseSBiZWxvdyB0aGUgU3VjY2VlZGVkIHBhaXIgYW5kIHRoZSBj YXNlIHdoZXJlIHRoZSBuZXcgcGFpcg0KPj4+PmlzIGFib3ZlIHRoZSBTdWNjZWVkZWQgcGFpciBi dXQgbm90IHRvcG1vc3QuDQo+Pj4gDQo+Pj4gSSBkb24ndCB1bmRlcnN0YW5kIHRoZSAiaW1tZWRp YXRlbHkgYmVsb3ciIHRleHQgZXRjLg0KPj4+IA0KPj4+IEFjY29yZGluZyB0byB0aGUgcHJvY2Vk dXJlcyBpbiBTZWN0aW9uIDcuMi41LjMuMy4gb2YgNTI0NWJpcywgb25jZSBhDQo+Pj5wYWlyIHN1 Y2NlZWRzIGFsbCBGcm96ZW4gcGFpcnMgZm9yIHRoZSBzYW1lIGZvdW5kYXRpb24gYXJlIHNldCB0 bw0KPj4+V2FpdGluZy4NCj4+PiANCj4+PiBBbmQsIGluIGNhc2UgIzIgYXQgbGVhc3Qgb25lIHBh aXIgaGFzIHN1Y2NlZWRlZCwgd2hpY2ggbWVhbnMgdGhlIG5ldw0KPj4+cGFpciBzaG91bGQgYmUg c2V0IHRvIFdhaXRpbmcuDQo+Pg0KPj5JIHNlZSB5b3VyIHBvaW50Lg0KPj4NCj4+Pj4+IC0gICAg ICAgICAgSWYgdGhlcmUgYXJlIG1vcmUgdGhhbiBvbmUgcGFpciBmb3IgdGhlIHNhbWUgZm91bmRh dGlvbiBpbg0KPj4+Pj4gdGhlIFdhaXRpbmcgc3RhdGUsIHNldCB0aGUgc3RhdGUgdG8gV2FpdGlu ZyAoY292ZXJzIENhc2UgIzMpDQo+Pj4+DQo+Pj4+IFRoYXQgY292ZXJzIENhc2UgIzMgYnV0IGl0 IGlzIG1vcmUgcGVybWlzc2l2ZSBiZWNhdXNlIGl0IGl0IGFsc28NCj4+Pj5jb3ZlcnMgdGhlIGNh c2Ugd2hlcmUsIHNheSwgdHdvIHBhaXJzIHN1Y2NlZWRlZCBhbmQgb25lIHBhaXIgaXMNCj4+Pj53 YWl0aW5nLg0KPj4+IA0KPj4+IFllcy4gSSBkb24ndCB0aGluayB0aGF0IGlzIGEgcHJvYmxlbSA6 KQ0KPj4NCj4+QWgsIEkgc2VlLiBUaGUgcHJvY2VkdXJlcyB5b3UgY2l0ZSBmcm9tIFNlY3Rpb24g Ny4yLjUuMy4zLiBvZiA1MjQ1YmlzDQo+PmFjdHVhbGx5IGNvdmVyIGJvdGggQ2FzZSAjMiBhbmQg Q2FzZSAjMywgZG9uJ3QgdGhleT8NCj4NCj5Db3JyZWN0LiBXaGVuIGF0IGxlYXN0IG9uZSBwYWly IGlzIFN1Y2NlZWRlZCwgYWxsIG5vbi1GYWlsZWQgcGFpcnMgKEZyb3plbg0KPnBhaXJzIGFuZCBu ZXcgdHJpY2tsZWQgcGFpcnMpIGFyZSBzZXQgdG8gV2FpdGluZy4gSSB0aGluayB0aGF0IHdvdWxk IGJlIGENCj5zaW1wbGUgYXBwcm9hY2guDQo+DQo+DQo+Pj4+PiAtICAgICAgICAgIElmIHRoZXJl IGlzIGV4YWN0bHkgb25lIHBhaXIgZm9yIHRoZSBzYW1lIGZvdW5kYXRpb24gaW4NCj4+Pj4+dGhl IA0KPj4+Pj4gV2FpdGluZyBzdGF0ZSwgc2V0IHRoZSBzdGF0ZSB0byBGcm96ZW4gKGNvdmVycyBD YXNlICM0KQ0KPj4NCj4+VGhpcyBpcyBhIGZhbGwtdGhyb3VnaCBjYXNlLCBpc24ndCBpdD8gSSdt IG5vdCB5ZXQgc3VyZSB3aHkgd2UnZCBzYXkNCj4+YW55dGhpbmcgb3RoZXIgdGhhbiAiaW4gYWxs IG90aGVyIGNhc2VzLCBzZXQgdG8gRnJvemVuIi4uLg0KPg0KPlN1cmUsIHdlIGNvdWxkIGRvIHRo YXQuIFRoZSBzaW1wbGVyIHRoZSBiZXR0ZXIgOikNCj4NCj5SZWdhcmRzLA0KPg0KPkNocmlzdGVy DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5J Y2UgbWFpbGluZyBsaXN0DQo+SWNlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pY2UNCg0K From nobody Wed Mar 28 08:36:52 2018 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 B11F0127369 for ; Wed, 28 Mar 2018 08:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 OvbKvSBUD7uP for ; Wed, 28 Mar 2018 08:36:49 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 3555F120047 for ; Wed, 28 Mar 2018 08:36:49 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id e79so4039205ioi.7 for ; Wed, 28 Mar 2018 08:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=j6iwMJc03pEIf8jNvhMlW+EyI2HbWBgG5u+bHLSVqtI=; b=b1zBVppn4QJykDrOXkyuStPzTymQ2Ds/uuZNKQFoaNG+fT7533Fqn77bppk8Lfewu4 yyge2egbu3+zlRhSc5W/Gg1p5ZkwMbei3Ziz8WmKsy+0oQqquqPMVAhUMzsPUiMMaoLr EzYlNg2XKLXlaFIUWeMkbnhNYV1bAwqB1mVms= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=j6iwMJc03pEIf8jNvhMlW+EyI2HbWBgG5u+bHLSVqtI=; b=LM/EB814F1Nsz7874MNRlg2fj0Q9AqhjQ3vp/iEF8wdct8OxjaY9llMB9aJAC7wSXv +0yndJOeOFQ1SGSnR8NewvKTZbDvbjFJMHxWVa/P4ASEI2LV/6KIPs9/76TWPevA8jby WTDl9J6nH7dY3gHEHfosPOjndexoDIpL6QowqOmie5/zYXuU0bNBouJ+ylquZ5Gd0lMH vjmoTvWIrklaMiIgBEO6vatz/sgKHhPXVRJjuoBUMo5ZzkN8W4G6HWljxmuEynKK1xBG is9o17NrkQs02RdSr5O8Mx6CfI44nJhmMrGPB7Y/t1GuEHkNmu+RSpuRfBjaL6cZrvln fTqA== X-Gm-Message-State: AElRT7E8Puq9oXOdgEP5zN7lI4yE5ikqE35Eie7t1lwETf0lRBG/xlGD AG3aNC1H2MJtUZJ1Hx8of3+LZw== X-Google-Smtp-Source: AIpwx4+y1AmKK34dz4tFsenLMLBuXiVoT6y0p2mUEbto9+9IlyQOaMubi662X1Z5HhC4kXTQ0HbdVA== X-Received: by 10.107.146.136 with SMTP id u130mr12484342iod.96.1522251408471; Wed, 28 Mar 2018 08:36:48 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id h82sm2747724ioe.66.2018.03.28.08.36.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 08:36:47 -0700 (PDT) To: Christer Holmberg , "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> From: Peter Saint-Andre Message-ID: Date: Wed, 28 Mar 2018 09:36:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZyWqE4vtpjScjvChezuEe32TkdtNRHshG" Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 28 Mar 2018 15:36:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ZyWqE4vtpjScjvChezuEe32TkdtNRHshG Content-Type: multipart/mixed; boundary="DxUSIiDrxxOHqnDHLs6TqJrIygx6ZVZrG"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , "ice@ietf.org" Message-ID: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> In-Reply-To: --DxUSIiDrxxOHqnDHLs6TqJrIygx6ZVZrG Content-Type: text/plain; charset=euc-kr Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/28/18 6:32 AM, Christer Holmberg wrote: > Hi, >=20 > I think the rules could be simplified in the following way: >=20 > - If there are at least one pair in Succeeded state, set the state of t= he > new pair to Waiting Yes, that's consistent with =A1=D77.2.5.3.3 of 5245bis. > - If there are two or more pairs in Waiting/In-Progress state, set the > state of the new pair to Waiting Why "two or more"? > - Otherwise set the state of the new pair to Frozen I think that might do it. I will run through a bunch of scenarios (offlist) to verify. Please see one more comment below. > On 28/03/18 11:02, "Ice on behalf of Christer Holmberg" > wrot= e: >=20 >> Hi, >> >>>>>> I was reading the rules in section 8.1.1 on how to set the pair st= ate >>>>>> for trickled candidate pairs, and I think it can be simplified, >>>>> >>>>> I'm hesitant to mess around with these rules, but let's discuss... >>>> >>>> My issue is that I have a feeling you are still using old 5245bis >>>> concepts. >>> >>> Alignment is hard. I'll look at it again. >>> >>> One thing that's bothering me about these rules is that they're writt= en >>> about the diagrams (e.g., "top-most pair") and not about protocol >>> features (e.g., "the pair with the lowest component ID"). >>> >>>>>> as follows: >>>>>> >>>>>> =20 >>>>>> >>>>>> - If there are no other pairs for the same foundation, se= t >>>>>> the state to Waiting (covers Case #1) >>>>> >>>>> That covers Case #1 but it is more restrictive because it doesn't >>>>> cover the case where the new pair is not the only pair, just the >>>>> topmost pair. >>>> >>>> Not sure I understand "is not the only pair". >>> >>> Let's say there are already two pairs for the 5th foundation: >>> >>> +-----------------+------+------+------+------+------+ >>> | | f1 | f2 | f3 | f4 | f5 | >>> +-----------------+------+------+------+------+------+ >>> | m1 (Audio.RTP) | W | W | W | | | >>> +-----------------+------+------+------+------+------+ >>> | m2 (Audio.RTCP) | F | F | F | W | | >>> +-----------------+------+------+------+------+------+ >>> | m3 (Video.RTP) | F | | | | W | >>> +-----------------+------+------+------+------+------+ >>> | m4 (Video.RTCP) | F | | | | F | >>> +-----------------+------+------+------+------+------+ >>> >>> Now we add a new pair "X", which has a lower component ID than the ot= her >>> pairs: >>> >>> >>> +-----------------+------+------+------+------+------+ >>> | | f1 | f2 | f3 | f4 | f5 | >>> +-----------------+------+------+------+------+------+ >>> | m1 (Audio.RTP) | W | W | W | | | >>> +-----------------+------+------+------+------+------+ >>> | m2 (Audio.RTCP) | F | F | F | W | ^X^ | >>> +-----------------+------+------+------+------+------+ >>> | m3 (Video.RTP) | F | | | | W | >>> +-----------------+------+------+------+------+------+ >>> | m4 (Video.RTCP) | F | | | | F | >>> +-----------------+------+------+------+------+------+ >>> >>> That doesn't seem to be covered by your text. >> >> >> It is not covered by case #1, because in case #1 there are no other pa= irs >> in the foundation :) >> >> The case above is covered by the following bullet I suggested: >> >> "- If there is exactly one pair for the same foundation in the Waiting= >> state, set the state to Frozen (covers Case #4)=A9=F7 >> >> So, in this case the state would be set to Frozen. >> >> An alternative would be to change the m3 pair to Frozen, and set the n= ew >> pair to Waiting, but I think modifying the state of existing pairs wou= ld >> be messy. =A1=D76.1.2.6 of 5245bis states: 5. For each foundation, the agent sets the state of exactly one candidate pair to the Waiting state (unfreezing it). The candidate pair to unfreeze is chosen by finding the first candidate pair (ordered by lowest component ID and then highest priority if component IDs are equal) in the first check list (according to the usage-defined check list set order) that has that foundation. My inclination is to set the state of this "X" candidate pair to Waiting, because it is now the candidate with the lowest component ID (and highest prioritiy if the component IDs are equal) within this foundation. However, if we proceeded in this way then we would have two candidate pairs in the Waiting state within this foundation. That doesn't seem like a problem, but I wanted to point it out. Peter --DxUSIiDrxxOHqnDHLs6TqJrIygx6ZVZrG-- --ZyWqE4vtpjScjvChezuEe32TkdtNRHshG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq7to0ACgkQZWGMGH9o FKlJ+A/+IBJzPcgiVRFqqXUC8YGS9K9JBK2iW9lJc1KoDwBUBncDaJ7fbjFqZmze 5GIprojlI5jKQHQkvFOVXD0xRhTQ9u6sB8EfOO1c9CERhCG+8G5nxcq7KOynvzn8 E0jpRHIGVdOm1mLvXY8q7f97UrAcWL0nogcltCuP2d4E9tdvnrhcTNr2OPUnQV8b M0f2ixQ7e4FentRFzd+pHWrxTfjK8ol010nIT+FobdecgML7zT9842GpImCMtiCO WeuZ4paLnft6I16FM/AONoimfj8ezqdGm9elSKC3kKI+9Fqe/B834JR9uzv4syCj fCYF3fF3xkGRFBGnb7vFLhw9J/GeqywOrCzA+WHc+rDA5gJHySRyCswa0W8pkdXi yS+evFAZ4l8X4fSlPn2xFcVKRexj7ANahYOebb2G4jZ8kqeAnLEUM7vZOF/NrnWg U24c1ZYGvP+0UInIL4TE8OLeBuj5zHrgFtls2HrF+pF57y9fxVz15N9yXhF1rzBj MbbvtdPEo2+wacktXQnsJGkJDQngsriErKgCLs1Ke0CMDY5t3s1r8LdiNhftN0G7 vZSrW5Nx6pB//FPgBjH0Cj/QB3nNrEhNwjFCC+wEPBib3iFEgkoWxRE8U4c/3CDY ObS1p2SJP08NKH3SKDivVaPaoKti8VYwOaM813Ledan2H/86EMU= =dyE8 -----END PGP SIGNATURE----- --ZyWqE4vtpjScjvChezuEe32TkdtNRHshG-- From nobody Wed Mar 28 08:42:43 2018 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 238CD127369 for ; Wed, 28 Mar 2018 08:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 TvVSQ9cxJqNG for ; Wed, 28 Mar 2018 08:42:39 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 182A9120047 for ; Wed, 28 Mar 2018 08:42:39 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id l3so4085240iog.0 for ; Wed, 28 Mar 2018 08:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=dfkzfV+mPZ8qq/6Pu7yAMpPimyuINjuMj8tlQJx/tNI=; b=ciBYUP+rYBQD82Q0WjK7MfIBwuN7uOWTQ6utNChcIhq+iEkdQ/Y+Q4Esxk65pWhJ1h iUcx/V7y/LlRlOJXHsojljQDeU70AOF8dSEHKPi14LtLT7CuiM3RoTFYlJFFua7LZKKJ volqC+mAfCE0+2rnXr+93tVYgoJaVWqo0gTM0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=dfkzfV+mPZ8qq/6Pu7yAMpPimyuINjuMj8tlQJx/tNI=; b=oDG5fd7d0xhwRmzscX01jGpMEoqKofcavYjuR5/+uee2h8gw6CBuvj6tIJ5qKLBXqX jG91q+9AspDY7fnP0cK3l4b9qAKeINC955xF22JXG7HVkOQIHBxMlVgxLuIZSOlKyZYe VafcNs46rb0BhO3rXCQms71D6yjuX5/EL7PVBd7OozWRgUgvjHO7Qrf2Gv/P3+fkuYVC XcdKtbfGpyK67IZ2oqIIW5c6zANSR/F3lm7tmotIJ7acvVbnt2/XRjxmVUai+SViZ1ce SCRmxS50xeaSYI4Muw1e8tqr9xPKcicRXUqFVSXECm+SOstUos14bEUvF9eA6QN4Xsic /Mxg== X-Gm-Message-State: AElRT7G6lxmBh/WzjOsNPysUUF2JkRgZaH+LJTomorPpv0yP3uTYARO8 6twtLWeGcz8n4Fj3V9dDx12nXw== X-Google-Smtp-Source: AIpwx4+L4lzvz1cwSfKu/1OsYTT/PpXyBuXblCSMZV9rwfHp5tji7kO03/HeKDcfO7nfZzvoZn/C+g== X-Received: by 10.107.202.67 with SMTP id a64mr34199788iog.15.1522251758392; Wed, 28 Mar 2018 08:42:38 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id m14-v6sm3043431iti.13.2018.03.28.08.42.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 08:42:37 -0700 (PDT) To: Christer Holmberg , "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: <00037ad3-1e3d-34aa-bf2c-34fb141766ae@mozilla.com> Date: Wed, 28 Mar 2018 09:42:36 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8iEn2bLms32tR9eqYfygmS8EUt5HK4anU" Archived-At: Subject: Re: [Ice] Tricke ICE: Suggested clarifications to Introduction 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, 28 Mar 2018 15:42:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8iEn2bLms32tR9eqYfygmS8EUt5HK4anU Content-Type: multipart/mixed; boundary="vfdAxmZL8gzF6G6McSvtWUR9oeKF3R6Hn"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , "ice@ietf.org" Message-ID: <00037ad3-1e3d-34aa-bf2c-34fb141766ae@mozilla.com> Subject: Re: [Ice] Tricke ICE: Suggested clarifications to Introduction References: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> --vfdAxmZL8gzF6G6McSvtWUR9oeKF3R6Hn Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/24/18 3:53 PM, Christer Holmberg wrote: > Hi, >=20 > =A0 >=20 > Below is a suggestion on how to modify the Introduction section of > draft-trickle-ice, in order to make it more clear (in my opinion). >=20 > =A0 >=20 > --- >=20 > =A0 >=20 > 1.=A0 Introduction >=20 > =A0 >=20 > =A0=A0 The Interactive Connectivity Establishment (ICE) protocol >=20 > =A0=A0 [rfc5245bis] describes mechanisms how an ICE agent gathers >=20 > =A0=A0=A0candidates, exchanges candidates with a peer ICE agent, and >=20 > =A0=A0=A0creates candidate pairs. Once the pairs have been created, the= >=20 > =A0=A0=A0ICE agent will perform connectivity checks, and eventually >=20 > =A0=A0 nominate and select pairs that will be used for sending and >=20 > =A0=A0 receiving media within a session. Because 5245bis now talks about "data streams" (not "media streams"), we should make the trickle spec consistent with that usage. > =A0=A0 Although the procedures in [rfc5245bis] are relatively straightf= orward >=20 > =A0=A0 to implement, they might lead to relatively lengthy session esta= blishment >=20 > =A0=A0 times, as candidate gathering often involves querying STUN serve= rs > [RFC5389] >=20 > =A0 and allocating relayed candidates using TURN servers [RFC5766]. Alt= hough >=20 > =A0=A0 many procedures can be done in parallel, the pacing requirements= > [rfc5245bis] >=20 > =A0=A0 still needs to be followed. >=20 > =A0 >=20 > =A0=A0 This document defines a supplementary mode of ICE operation, >=20 > =A0=A0 =93Trickle ICE=94, in which given candidates can be exchanged in= crementally, >=20 > =A0=A0 as soon as they become available (and while other candidates are= still >=20 > =A0=A0 gathered). Connectivity checks can also start as soon as candida= te >=20 > =A0=A0 pairs have been created. Then, as Trickle ICE allows candidate > gathering and >=20 > =A0=A0=A0connectivity check in parallel, the session establishment time= can be >=20 > =A0=A0=A0considerable shortened. >=20 > =A0 >=20 > =A0=A0 In addition, this document also defines how to discovers support= of > Trickle ICE, >=20 > =A0=A0 and how procedures in [rfc5245bis] are modified when using Trick= le > ICE. The >=20 > =A0=A0 document also defines how an Trickle ICE agent can interoperate = with an >=20 > =A0=A0 ICE agent compliant to [rfc5245bis]. >=20 > =A0 >=20 > =A0=A0 This document does not define any ICE usage for Trickle ICE. Pro= tocol >=20 > =A0=A0 specific details for Trickle ICE are defined in separate usage d= ocuments. >=20 > =A0=A0 Examples of such documents are [I-D.ietf-mmusic-trickle-ice-sip]= , which >=20 > =A0=A0 defines usage with the Session Initiation Protocol (SIP) [RFC326= 1] >=20 > =A0=A0 and the Session Description Protocol [RFC4566] , and >=20 > =A0=A0 [XEP-0176], which defines usage with XMPP [RFC6120]. However, >=20 > =A0=A0 some of the examples in the document uses SDP and the >=20 > =A0=A0 Offer/Answer mechanism [RFC4566] in order to explain the >=20 > =A0=A0 underlying concepts. >=20 > =A0 >=20 > =A0=A0 NOTE: It is worth noting that there is quite a bit of operationa= l >=20 > =A0=A0 experience with the technique behind Trickle ICE, going back as = far > as 2005 >=20 > =A0=A0 (when the XMPP Jingle extension defined a "dribble mode" as spec= ified >=20 > =A0=A0 in [XEP-0176]); this document incorporates feedback from those w= ho >=20 > =A0=A0 have implemented and deployed the technique. Modulo some small grammar adjustments, that looks good and is shorter. Thanks, Christer! Peter --vfdAxmZL8gzF6G6McSvtWUR9oeKF3R6Hn-- --8iEn2bLms32tR9eqYfygmS8EUt5HK4anU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq7t+wACgkQZWGMGH9o FKkADRAAuaEhVCk20rGbR9QZf65VKoNpjDFQ67//fyb81A6DYF3X3VjeooCZue8f KajUcojF70SKdoICSaa796c/MzQMuR5fX0gZfT6mV/XUddsWD/B1erHjZW7OhWtG QvwLRbLLYqprPA5SFocbBE344kJtgw/zRqIoGOEIcIx2eCO2/ByA9fc59e17WWGi Yta2bGV2u9LuPfRIl6JhLeee1+A0i+AbfryZEkI85ohlnz7mO/XNu4VA7cdTALKr H45f1En3wb/oU60zn6VWKF1O+6yYGeUCu/zxu0Nc7/AxfqTrR0pLMtjmE8wyVxxb jpbEZcH2iT+0C5fyytE+mqJzuBKll0g6RsvuEBHf/U/yDU48eOYkTiXNfC7qdzYQ iflzB1Mq7PgqSaKvcjZiKcZBshYNm/qjSZQoWN3T0x1vBAV+qFKJlPHULnYBm9X6 XmRrkynKTNuDza4EFQcni4vF6Mq+eiw8EdYmGWSZnYsessmRHQ3q+r5sg5cWDe7q p/jLPGni0/qwjbrHaTTidwgi+WvfYB6xzfovvFCcTq7/mVV1QzIcD38A3oRrzExL 3qmorpmd5ZT6h1A/A+IVflLTPGnFT5X49Q8dAzGYV+MxPlBCk2/WWIyCLUGBVVMU yHJiqpfOUOCEpBfiuhaVgAebLxLoBGzq/3Xw0AvUo6vedfYPIuw= =xQ6z -----END PGP SIGNATURE----- --8iEn2bLms32tR9eqYfygmS8EUt5HK4anU-- From nobody Wed Mar 28 09:41:43 2018 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 A73141275AB for ; Wed, 28 Mar 2018 09:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 hlUO_WRsAKYK for ; Wed, 28 Mar 2018 09:41:35 -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 31220127419 for ; Wed, 28 Mar 2018 09:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522255293; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kyPp0A1r6MlJliJ57ZaGwva4njiCtspbrJcFo9LPZRM=; b=GNA4KUI0y0sa0iVoTylG+hpw4A/IuyuwCYXlISQpuCSzyg0NPMpg/QIkdFrXzF87 78p3CeYaxCWTJ14wyW8qeF0nggMrYoMVK49HepoxpisjaQS6tqg9w1sj3+NBWJJb 2MWBTSbApywPxUXplFuzPSKpAEtpafYARpBusp1e5C0=; X-AuditID: c1b4fb3a-1ff859c000005d56-36-5abbc5bd7e0f Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9F.54.23894.DB5CBBA5; Wed, 28 Mar 2018 18:41:33 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 18:41:04 +0200 From: Christer Holmberg To: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] Tricke ICE: Suggested clarifications to Introduction Thread-Index: AdPDqyqQBt8cF0w/QDKTIeEKNJW1+wC73bkAAAYyOJA= Date: Wed, 28 Mar 2018 16:41:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E37DD3@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> <00037ad3-1e3d-34aa-bf2c-34fb141766ae@mozilla.com> In-Reply-To: <00037ad3-1e3d-34aa-bf2c-34fb141766ae@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.164] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7ve7eo7ujDNZOVbD4dqHW4tnKU4wO TB5Llvxk8ug70MUawBTFZZOSmpNZllqkb5fAlfHvj3bBNfmKhQ3b2BoYj0t2MXJySAiYSMw4 dp2pi5GLQ0jgCKPEvem3GSGcJYwSs/a0sXQxcnCwCVhIdP/TBmkQEfCSmLnnPhNIWFjAXWJe ky1E2EOi+UwrK4RtJXHpWj8LiM0ioCox49cnRhCbV8BXYteyy8wQ45sYJSa9vsQMkuAUsJfY 8XsiWDOjgJjE91NrmEBsZgFxiVtP5jNBHCogsWTPeWYIW1Ti5eN/rBC2ksTZL1PYIOr1JG5M hbG1JZYtfM0MsVhQ4uTMJywTGEVmIRk7C0nLLCQts5C0LGBkWcUoWpxaXJybbmSkl1qUmVxc nJ+nl5dasokRGAsHt/y22sF48LnjIUYBDkYlHt7g1bujhFgTy4orcw8xSnAwK4nwvtcACvGm JFZWpRblxxeV5qQWH2KU5mBREud1SrOIEhJITyxJzU5NLUgtgskycXBKNTC2aGyUUdQ7vk1x 8Wr29os/znNwKl/1WCvazWPBlrtxC1vK52UTuVqtV4vHZW5zuxWxKmWt0k4b4YglKj/tSz4l njr9wGhramlzTMT7hRYPZMyYGDpkrNx2C28XXx12RD43jHHvq51PVC25TJ43SQfsD9nqrf03 Q/PAu1+vrBL1Omr3fDRqbVJiKc5INNRiLipOBADLjOiFgQIAAA== Archived-At: Subject: Re: [Ice] Tricke ICE: Suggested clarifications to Introduction 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, 28 Mar 2018 16:41:38 -0000 Hi, I was going to make the media-stream-to-data-stream modification, but forgo= t :) Regards, Christer -----Original Message----- From: Peter Saint-Andre [mailto:stpeter@mozilla.com]=20 Sent: 28 March 2018 17:43 To: Christer Holmberg ; ice@ietf.org Subject: Re: [Ice] Tricke ICE: Suggested clarifications to Introduction On 3/24/18 3:53 PM, Christer Holmberg wrote: > Hi, >=20 > =A0 >=20 > Below is a suggestion on how to modify the Introduction section of=20 > draft-trickle-ice, in order to make it more clear (in my opinion). >=20 > =A0 >=20 > --- >=20 > =A0 >=20 > 1.=A0 Introduction >=20 > =A0 >=20 > =A0=A0 The Interactive Connectivity Establishment (ICE) protocol >=20 > =A0=A0 [rfc5245bis] describes mechanisms how an ICE agent gathers >=20 > =A0=A0=A0candidates, exchanges candidates with a peer ICE agent, and >=20 > =A0=A0=A0creates candidate pairs. Once the pairs have been created, the >=20 > =A0=A0=A0ICE agent will perform connectivity checks, and eventually >=20 > =A0=A0 nominate and select pairs that will be used for sending and >=20 > =A0=A0 receiving media within a session. Because 5245bis now talks about "data streams" (not "media streams"), we sh= ould make the trickle spec consistent with that usage. > =A0=A0 Although the procedures in [rfc5245bis] are relatively=20 > straightforward >=20 > =A0=A0 to implement, they might lead to relatively lengthy session=20 > establishment >=20 > =A0=A0 times, as candidate gathering often involves querying STUN servers= =20 > [RFC5389] >=20 > =A0 and allocating relayed candidates using TURN servers [RFC5766].=20 > Although >=20 > =A0=A0 many procedures can be done in parallel, the pacing requirements=20 > [rfc5245bis] >=20 > =A0=A0 still needs to be followed. >=20 > =A0 >=20 > =A0=A0 This document defines a supplementary mode of ICE operation, >=20 > =A0=A0 "Trickle ICE", in which given candidates can be exchanged=20 > incrementally, >=20 > =A0=A0 as soon as they become available (and while other candidates are=20 > still >=20 > =A0=A0 gathered). Connectivity checks can also start as soon as candidate >=20 > =A0=A0 pairs have been created. Then, as Trickle ICE allows candidate=20 > gathering and >=20 > =A0=A0=A0connectivity check in parallel, the session establishment time c= an=20 > be >=20 > =A0=A0=A0considerable shortened. >=20 > =A0 >=20 > =A0=A0 In addition, this document also defines how to discovers support o= f=20 > Trickle ICE, >=20 > =A0=A0 and how procedures in [rfc5245bis] are modified when using Trickle= =20 > ICE. The >=20 > =A0=A0 document also defines how an Trickle ICE agent can interoperate=20 > with an >=20 > =A0=A0 ICE agent compliant to [rfc5245bis]. >=20 > =A0 >=20 > =A0=A0 This document does not define any ICE usage for Trickle ICE.=20 > Protocol >=20 > =A0=A0 specific details for Trickle ICE are defined in separate usage doc= uments. >=20 > =A0=A0 Examples of such documents are [I-D.ietf-mmusic-trickle-ice-sip],= =20 > which >=20 > =A0=A0 defines usage with the Session Initiation Protocol (SIP) [RFC3261] >=20 > =A0=A0 and the Session Description Protocol [RFC4566] , and >=20 > =A0=A0 [XEP-0176], which defines usage with XMPP [RFC6120]. However, >=20 > =A0=A0 some of the examples in the document uses SDP and the >=20 > =A0=A0 Offer/Answer mechanism [RFC4566] in order to explain the >=20 > =A0=A0 underlying concepts. >=20 > =A0 >=20 > =A0=A0 NOTE: It is worth noting that there is quite a bit of operational >=20 > =A0=A0 experience with the technique behind Trickle ICE, going back as fa= r=20 > as 2005 >=20 > =A0=A0 (when the XMPP Jingle extension defined a "dribble mode" as=20 > specified >=20 > =A0=A0 in [XEP-0176]); this document incorporates feedback from those who >=20 > =A0=A0 have implemented and deployed the technique. Modulo some small grammar adjustments, that looks good and is shorter. Thanks, Christer! Peter From nobody Wed Mar 28 09:51:31 2018 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 B1180126C19 for ; Wed, 28 Mar 2018 09:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Vv07fdofPjlT for ; Wed, 28 Mar 2018 09:51:27 -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 389901243F6 for ; Wed, 28 Mar 2018 09:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522255885; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GLUr592W2QFwHiZ/DBs8AZ+dY6JB6QkouaUaSreTOM8=; b=LW4EQJdUebkiRNLUSh3R9HkGN7jBnxiAuh8ac7hG6/H50ZKREq2rs1Yy1hD71S90 L//feXMl2WYfAEs7cpOLKTIYYBA0dn4xzlEFPSjjFZxD4QqD6FT9FZ42CLWp2/8j 1Ba++65+x/nWIjH2IH16Leic2RN3mgUP4G3ldvEefAY=; X-AuditID: c1b4fb3a-e21ff70000005d56-13-5abbc80dc2b4 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FD.95.23894.D08CBBA5; Wed, 28 Mar 2018 18:51:25 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 18:51:24 +0200 From: Christer Holmberg To: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] ICE trickle: Comment on section 8.1.1 Thread-Index: AdPDkuP38FvIt3+USwysDB0OImfNMwCVdT+AAAUSnMD///EdgIAA/DAAgABLdoCAAADWgP//zJvw Date: Wed, 28 Mar 2018 16:51:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.164] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7qC7vid1RBm+6+C2+Xai1eLbyFKMD k8eSJT+ZPPoOdLEGMEVx2aSk5mSWpRbp2yVwZUzdklNwX6ni9KNljA2MLyS7GDk5JARMJI68 O8PWxcjFISRwhFFi94zdLBDOEkaJ11OOs3cxcnCwCVhIdP/TBmkQEfCSmLnnPhOILQwU/nbu IjtE3FJi6d4VLBB2lMTRp38YQWwWAVWJRQtWgNXzCvhKLJrYDWYLCUxhlvg3zQvE5hSwl5g1 +yZYPaOAmMT3U2vAapgFxCVuPZnPBHGogMSSPeeZIWxRiZeP/7FC2EoSZ79MYYOo15O4MRXG 1pZYtvA1M8ReQYmTM5+wTGAUmYVk7CwkLbOQtMxC0rKAkWUVo2hxanFxbrqRkV5qUWZycXF+ nl5easkmRmAsHNzy22oH48HnjocYBTgYlXh4g1fvjhJiTSwrrsw9xCjBwawkwvteAyjEm5JY WZValB9fVJqTWnyIUZqDRUmc1ynNIkpIID2xJDU7NbUgtQgmy8TBKdXA6Lil/fxjMUveVNNF V9sn7jMw/XPixZ4+fZPPascOt0iEuH9V6JFS8Hgc+X1r7uz6Nr1JG9IVXV++rDJLvd75MW/p tKOTeLjYOBxilryeKtgds1lzwaR9ax5Nc5YvXFZ0JnKjc375XMtt14XfizIHP2joDdV69ODq ps2NJW1X3oVycIfe5HOYrcRSnJFoqMVcVJwIAJEfjFOBAgAA Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 28 Mar 2018 16:51:30 -0000 Hi, >> I think the rules could be simplified in the following way: >>=20 >> - If there are at least one pair in Succeeded state, set the state of=20 >> the new pair to Waiting > > Yes, that's consistent with =A77.2.5.3.3 of 5245bis. Correct. >> - If there are two or more pairs in Waiting/In-Progress state, set the=20 >> state of the new pair to Waiting > > Why "two or more"? If there is only one (or no) pair in Waiting state, the check list set has = just been initialized, which means there should be no more than one pair in= the waiting state. =20 >> - Otherwise set the state of the new pair to Frozen > > I think that might do it. I will run through a bunch of scenarios > (offlist) to verify. Please do :) > Please see one more comment below. ... >>>>>>> - If there are no other pairs for the same foundation, set >>>>>>> the state to Waiting (covers Case #1) >>>>>> >>>>>> That covers Case #1 but it is more restrictive because it doesn't=20 >>>>>> cover the case where the new pair is not the only pair, just the=20 >>>>>> topmost pair. >>>>> >>>>> Not sure I understand "is not the only pair". >>>> >>>> Let's say there are already two pairs for the 5th foundation: >>>> >>>> +-----------------+------+------+------+------+------+ >>>> | | f1 | f2 | f3 | f4 | f5 | >>>> +-----------------+------+------+------+------+------+ >>>> | m1 (Audio.RTP) | W | W | W | | | >>>> +-----------------+------+------+------+------+------+ >>>> | m2 (Audio.RTCP) | F | F | F | W | | >>>> +-----------------+------+------+------+------+------+ >>>> | m3 (Video.RTP) | F | | | | W | >>>> +-----------------+------+------+------+------+------+ >>>> | m4 (Video.RTCP) | F | | | | F | >>>> +-----------------+------+------+------+------+------+ >>>> >>>> Now we add a new pair "X", which has a lower component ID than the=20 >>>> other pairs: >>>> >>>> >>>> +-----------------+------+------+------+------+------+ >>>> | | f1 | f2 | f3 | f4 | f5 | >>>> +-----------------+------+------+------+------+------+ >>>> | m1 (Audio.RTP) | W | W | W | | | >>>> +-----------------+------+------+------+------+------+ >>>> | m2 (Audio.RTCP) | F | F | F | W | ^X^ | >>>> +-----------------+------+------+------+------+------+ >>>> | m3 (Video.RTP) | F | | | | W | >>>> +-----------------+------+------+------+------+------+ >>>> | m4 (Video.RTCP) | F | | | | F | >>>> +-----------------+------+------+------+------+------+ >>>> >>>> That doesn't seem to be covered by your text. >>> >>> It is not covered by case #1, because in case #1 there are no other=20 >>> pairs in the foundation :) >>> >>> The case above is covered by the following bullet I suggested: >>> >>> "- If there is exactly one pair for the same foundation in the=20 >>> Waiting state, set the state to Frozen (covers Case #4)=B2 >>> >>> So, in this case the state would be set to Frozen. >>> >>> An alternative would be to change the m3 pair to Frozen, and set the=20 >>> new pair to Waiting, but I think modifying the state of existing=20 >>> pairs would be messy. >> > =A76.1.2.6 of 5245bis states: > > 5. For each foundation, the agent sets the state of exactly one > candidate pair to the Waiting state (unfreezing it). The > candidate pair to unfreeze is chosen by finding the first > candidate pair (ordered by lowest component ID and then highest > priority if component IDs are equal) in the first check list > (according to the usage-defined check list set order) that has > that foundation. > > My inclination is to set the state of this "X" candidate pair to Waiting,= because it is now the candidate with the=20 > lowest component ID (and highest prioritiy if the component IDs are equal= ) within this foundation. However, if we=20 > proceeded in this way then we would have two candidate pairs in the Waiti= ng state within this foundation. That=20 > doesn't seem like a problem, but I wanted to point it out. Yes. Another alternative would be to set the current pair in Waiting state to Fr= ozen, since X has higher priority. Regards, Christer From nobody Wed Mar 28 10:54:37 2018 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 B999F126C89 for ; Wed, 28 Mar 2018 10:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 dgtI_CfjyvNg for ; Wed, 28 Mar 2018 10:54:33 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E90124B17 for ; Wed, 28 Mar 2018 10:54:33 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id c1-v6so4701340itj.1 for ; Wed, 28 Mar 2018 10:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=qbkxcTjFWbVnC9buNv015PynuMHyYG3w4loUpBtDCVs=; b=O9pkUEgINzNT6gPEuQSiOKTmAWf7BlvSZxrJmY1CQlU0Ui7SHwcjok8pcjPrWAKyAk /pwaydjVfskm5BodfmaxobcF/DZelGahq3QZhAdHwm3WXCoiu8Xh/z6NGor/Fy5TZGcF Itjz7SFjMIgZ/LypfM0H986f7LEns5qUbRjfc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=qbkxcTjFWbVnC9buNv015PynuMHyYG3w4loUpBtDCVs=; b=YhPG2M2wPIT3gaXMRiqNaArpN5p268EkAnpLHx6asP6ZKK2vNnBoTgTVcIuug9Y6Dd ubFATOikJFUrv7ga4c1fulMp2efBSjHV2Pa66VV1/4bzJMOdxmrrAl6LqSOb+D47PmJh PnAdkIGjh+p7v+teE6Uv7kx06jZplEvQPm3dHb8zEMhXT/dm3NQNnDuIfOa1CpjycU+2 PwWGEXKfDO85QIqohse+djaILetU4TWWnZ5L73hAQ11QhglsuNo50NdbKnMw14+8qXz5 kEnUZUwE9V1JP8qWE945BQOEjAccNLfBwsbbl1b5r2SDbPC9pk9WElojf/lYZjC9gcwc hhCw== X-Gm-Message-State: AElRT7EsVgn69jsA6XhBRX3yjZz9tWCASPAL9zj2Fg1nOKlUpakOe5Os UJXHcE6+M9Id483JNaEvh2Zz1w== X-Google-Smtp-Source: AIpwx4+p8TwWxo8T5Q9jX2IUV7jNZyTP3GrsRYg5xTYoAi521HqTE0w6kogSPfeSb+vjczmw0+iZ9Q== X-Received: by 2002:a24:80c7:: with SMTP id g190-v6mr4351269itd.129.1522259672466; Wed, 28 Mar 2018 10:54:32 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id l201sm2960296iol.6.2018.03.28.10.54.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 10:54:31 -0700 (PDT) To: Christer Holmberg , "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> Date: Wed, 28 Mar 2018 11:54:30 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UH54NEITUsDxcIEELXKozkLtCCSkdejC0" Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 28 Mar 2018 17:54:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UH54NEITUsDxcIEELXKozkLtCCSkdejC0 Content-Type: multipart/mixed; boundary="iHbVLDR3P7KRznkO1d2tkJvDLcPta2n4D"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , "ice@ietf.org" Message-ID: <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> --iHbVLDR3P7KRznkO1d2tkJvDLcPta2n4D Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/28/18 10:51 AM, Christer Holmberg wrote: > Hi, >=20 >>> I think the rules could be simplified in the following way: >>> >>> - If there are at least one pair in Succeeded state, set the state of= =20 >>> the new pair to Waiting >> >> Yes, that's consistent with =C2=A77.2.5.3.3 of 5245bis. >=20 > Correct. >=20 >>> - If there are two or more pairs in Waiting/In-Progress state, set th= e=20 >>> state of the new pair to Waiting >> >> Why "two or more"? >=20 > If there is only one (or no) pair in Waiting state, the check list set = has just been initialized, which means there should be no more than one p= air in the waiting state. Is that true in the context of trickle? Couldn't a candidate pair trickle in after initialization of the check list set? >>> - Otherwise set the state of the new pair to Frozen >> >> I think that might do it. I will run through a bunch of scenarios >> (offlist) to verify. >=20 > Please do :) >=20 >> Please see one more comment below. >=20 > ... >=20 >>>>>>>> - If there are no other pairs for the same foundation, = set >>>>>>>> the state to Waiting (covers Case #1) >>>>>>> >>>>>>> That covers Case #1 but it is more restrictive because it doesn't= =20 >>>>>>> cover the case where the new pair is not the only pair, just the = >>>>>>> topmost pair. >>>>>> >>>>>> Not sure I understand "is not the only pair". >>>>> >>>>> Let's say there are already two pairs for the 5th foundation: >>>>> >>>>> +-----------------+------+------+------+------+------+ >>>>> | | f1 | f2 | f3 | f4 | f5 | >>>>> +-----------------+------+------+------+------+------+ >>>>> | m1 (Audio.RTP) | W | W | W | | | >>>>> +-----------------+------+------+------+------+------+ >>>>> | m2 (Audio.RTCP) | F | F | F | W | | >>>>> +-----------------+------+------+------+------+------+ >>>>> | m3 (Video.RTP) | F | | | | W | >>>>> +-----------------+------+------+------+------+------+ >>>>> | m4 (Video.RTCP) | F | | | | F | >>>>> +-----------------+------+------+------+------+------+ >>>>> >>>>> Now we add a new pair "X", which has a lower component ID than the = >>>>> other pairs: >>>>> >>>>> >>>>> +-----------------+------+------+------+------+------+ >>>>> | | f1 | f2 | f3 | f4 | f5 | >>>>> +-----------------+------+------+------+------+------+ >>>>> | m1 (Audio.RTP) | W | W | W | | | >>>>> +-----------------+------+------+------+------+------+ >>>>> | m2 (Audio.RTCP) | F | F | F | W | ^X^ | >>>>> +-----------------+------+------+------+------+------+ >>>>> | m3 (Video.RTP) | F | | | | W | >>>>> +-----------------+------+------+------+------+------+ >>>>> | m4 (Video.RTCP) | F | | | | F | >>>>> +-----------------+------+------+------+------+------+ >>>>> >>>>> That doesn't seem to be covered by your text. >>>> >>>> It is not covered by case #1, because in case #1 there are no other = >>>> pairs in the foundation :) >>>> >>>> The case above is covered by the following bullet I suggested: >>>> >>>> "- If there is exactly one pair for the same foundation in the=20 >>>> Waiting state, set the state to Frozen (covers Case #4)=C2=B2 >>>> >>>> So, in this case the state would be set to Frozen. >>>> >>>> An alternative would be to change the m3 pair to Frozen, and set the= =20 >>>> new pair to Waiting, but I think modifying the state of existing=20 >>>> pairs would be messy. >>> >> =C2=A76.1.2.6 of 5245bis states: >> >> 5. For each foundation, the agent sets the state of exactly one >> candidate pair to the Waiting state (unfreezing it). The >> candidate pair to unfreeze is chosen by finding the first >> candidate pair (ordered by lowest component ID and then highest >> priority if component IDs are equal) in the first check list >> (according to the usage-defined check list set order) that has >> that foundation. >> >> My inclination is to set the state of this "X" candidate pair to Waiti= ng, because it is now the candidate with the=20 >> lowest component ID (and highest prioritiy if the component IDs are eq= ual) within this foundation. However, if we=20 >> proceeded in this way then we would have two candidate pairs in the Wa= iting state within this foundation. That=20 >> doesn't seem like a problem, but I wanted to point it out. >=20 > Yes. >=20 > Another alternative would be to set the current pair in Waiting state t= o Frozen, since X has higher priority. That seems preferable to me. Peter --iHbVLDR3P7KRznkO1d2tkJvDLcPta2n4D-- --UH54NEITUsDxcIEELXKozkLtCCSkdejC0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq71tYACgkQZWGMGH9o FKmiAw//XlBJAUsh74CZyDFph/t0sjEVE9KegT1RulF+IRPJqhDnEv+MAL9/pbKg MUGGovESsLvx5hKWXMYR1o3zVdEAa15YRDjsMf7sos+QcJxuv7vI/bX9IeQk09hM fr5VJ+BVSlz8/3CyzXq98QwQs/3TWyM2bQH0SIQkPw+OvbQZyYBbxHPg0haR/8lU wVe7Csb8MpErqgRGXGPQFlilAdZi8IcirFB+zJxFzw3Qw8NiBwKElvW3bPSHM/oZ aegjMoV0/2kEegYt2uDs1hlt4QjGQL3B/P8vGUiI6/wgYelmvN3mLmMZ7FCqUX4I XGCQWFrFV/gq3K4mgjfjk4VZSsrwG7cZ+o5JaJ4izgy9DTlGVaVYC2VHs6shMPVF azhhqDuVrbnacotIMAwbEDwcey4i7DsGirj1kcflAtsncNNMDDK71fIKd5a1mnxS WRykwX/llg4KGOBxq1y3x7k2Z7oXrBs2DycLgPk/K+OJeVFFMnEc7Eo6Gcb9B7+Q 2Mk/Z22lelH/qDskMSbT6x55XTHw14Gpg8bwVCAbRlA+MBv/Xa8xfJuJHT2GGG6o i2Hp+cSU6qAEplNhbj2BMS5U2HTb3G2Jw139j3T5p8GzqvPR4hFDiE4TO5cpiqtx Rmm7Y709+Nab8NxfZCpM5/CqE6eGxzpIwqMfN3L/YdtKm4zx6nc= =gMDO -----END PGP SIGNATURE----- --UH54NEITUsDxcIEELXKozkLtCCSkdejC0-- From nobody Wed Mar 28 11:05:43 2018 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 A6386126DED for ; Wed, 28 Mar 2018 11:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01] 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 tGJPhwz3DQJ9 for ; Wed, 28 Mar 2018 11:05:36 -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 8092E120725 for ; Wed, 28 Mar 2018 11:05:36 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id q38so2095661uad.5 for ; Wed, 28 Mar 2018 11:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0lO6EO1pxl/oleogYsuxeLompg204kfIea58F4fApgo=; b=MkB83zFoPiDSjAQyWYNSokEASIFVwllaS3W91wTFgiD2BEt2ZvysJ7gyrapawV9JEI YlGrxUKmm0TfvxYgHatT/j2qRCFYiZbzqA5ZSCd2+tdoK/qlx+4EuZyajNq9Klc6kfYB KU0dkijT9x2maq80ut1zWM8FwgVWHE65/BGYEc2Lax2R2uuTy6Mw8Konn7SgbR+gmIBk BnjT8Bb+O7BNrMkw+A1SJIYui6KcuIGNuVzRqavTxXNXrVNnqH60CwQ2ai7UPhW979gZ F+e+CBvpPQz+/AhGd3HuXs0KQd6bEgfFfisE5cC2s6T+iWP0ypvZU0kbZYKndcTm77oE C6gw== 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=0lO6EO1pxl/oleogYsuxeLompg204kfIea58F4fApgo=; b=KQ9VxsXvZmATN8GAm/nnGA4RA/0HvOVzWAQ4VF+fwMS/6KPrpFlfa24TILrbNTM2XM GwP38UiD7Ai12WEmZ0vsvboCj6wYoqAZHeoT/1UigdM3fOMsrxK6zqzGwSR/vIdin1XR afrkLYiw3FfVU9o8JpoDyFJdkRfJNNypOMrpBux/WoOxL/CTKszJnGlZnTeYeOIFDhFH azomAUEwBpvU8jyqyL0rlDDhoVz0o74cA34pBxo0I0Wsc7vOZAkEE3LJ7BU2UAJPH8nT /mgkm903NYaxttLf884Kw0FhjIaO3HrT6IoU+hwTy9yRW3i9wqTFGuzjwrI8iOleiknd flvA== X-Gm-Message-State: AElRT7FRcK5GWlZlT/cEI7pqxSNGDZJtX0iLhVBWtWjJZAbmioj+IJYJ yVpc7vLAaUo0HS28q6LzPj9j7NFCroT+XwrVXIW6CjuGZpI= X-Google-Smtp-Source: AIpwx4+nRXJuExAXy3U7saXUQV5+6IhJ3gI90+iar483gv1npbV5i5050BefZFXx6Leks7gkZkGPQ+z0UY0yInF/nx0= X-Received: by 10.176.36.143 with SMTP id i15mr3212998uan.105.1522260335175; Wed, 28 Mar 2018 11:05:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.189.19 with HTTP; Wed, 28 Mar 2018 11:05:34 -0700 (PDT) In-Reply-To: <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> From: Taylor Brandstetter Date: Wed, 28 Mar 2018 11:05:34 -0700 Message-ID: To: Peter Saint-Andre Cc: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="f40304373aec89210f05687cda52" Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 28 Mar 2018 18:05:42 -0000 --f40304373aec89210f05687cda52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christer, Something that's lost by the simplified set of rules is the guarantee that the "topmost" pair is always unfrozen. This ensures that the two ICE agents always have at least one common pair unfrozen per foundation, even when pairs are formed in a different order. Suppose one agent forms pairs in order "A, B", and the other in the order "B, A". With the simplified set of rules, one agent will unfreeze "A" and the other "B", and connectivity checks may fail for each due to lack of hole-punching. But with the "topmost" stipulation, one agent will unfreeze "A" and the other both "A" and "B", so checks will succeed for "A" before proceeding to "B". This "topmost" rule wouldn't be necessary if candidate pairs were formed in a deterministic order, which Section 16 guarantees. But I thought you were planning to remove the ordering requirements of Section 16? https://mailarchive.ietf.org/arch/msg/ice/XCquM6Gf-8bbG2ADXD4DNqePNK0 On Wed, Mar 28, 2018 at 10:54 AM, Peter Saint-Andre wrote: > On 3/28/18 10:51 AM, Christer Holmberg wrote: > > Hi, > > > >>> I think the rules could be simplified in the following way: > >>> > >>> - If there are at least one pair in Succeeded state, set the state of > >>> the new pair to Waiting > >> > >> Yes, that's consistent with =C2=A77.2.5.3.3 of 5245bis. > > > > Correct. > > > >>> - If there are two or more pairs in Waiting/In-Progress state, set th= e > >>> state of the new pair to Waiting > >> > >> Why "two or more"? > > > > If there is only one (or no) pair in Waiting state, the check list set > has just been initialized, which means there should be no more than one > pair in the waiting state. > > Is that true in the context of trickle? Couldn't a candidate pair > trickle in after initialization of the check list set? > > >>> - Otherwise set the state of the new pair to Frozen > >> > >> I think that might do it. I will run through a bunch of scenarios > >> (offlist) to verify. > > > > Please do :) > > > >> Please see one more comment below. > > > > ... > > > >>>>>>>> - If there are no other pairs for the same foundation, > set > >>>>>>>> the state to Waiting (covers Case #1) > >>>>>>> > >>>>>>> That covers Case #1 but it is more restrictive because it doesn't > >>>>>>> cover the case where the new pair is not the only pair, just the > >>>>>>> topmost pair. > >>>>>> > >>>>>> Not sure I understand "is not the only pair". > >>>>> > >>>>> Let's say there are already two pairs for the 5th foundation: > >>>>> > >>>>> +-----------------+------+------+------+------+------+ > >>>>> | | f1 | f2 | f3 | f4 | f5 | > >>>>> +-----------------+------+------+------+------+------+ > >>>>> | m1 (Audio.RTP) | W | W | W | | | > >>>>> +-----------------+------+------+------+------+------+ > >>>>> | m2 (Audio.RTCP) | F | F | F | W | | > >>>>> +-----------------+------+------+------+------+------+ > >>>>> | m3 (Video.RTP) | F | | | | W | > >>>>> +-----------------+------+------+------+------+------+ > >>>>> | m4 (Video.RTCP) | F | | | | F | > >>>>> +-----------------+------+------+------+------+------+ > >>>>> > >>>>> Now we add a new pair "X", which has a lower component ID than the > >>>>> other pairs: > >>>>> > >>>>> > >>>>> +-----------------+------+------+------+------+------+ > >>>>> | | f1 | f2 | f3 | f4 | f5 | > >>>>> +-----------------+------+------+------+------+------+ > >>>>> | m1 (Audio.RTP) | W | W | W | | | > >>>>> +-----------------+------+------+------+------+------+ > >>>>> | m2 (Audio.RTCP) | F | F | F | W | ^X^ | > >>>>> +-----------------+------+------+------+------+------+ > >>>>> | m3 (Video.RTP) | F | | | | W | > >>>>> +-----------------+------+------+------+------+------+ > >>>>> | m4 (Video.RTCP) | F | | | | F | > >>>>> +-----------------+------+------+------+------+------+ > >>>>> > >>>>> That doesn't seem to be covered by your text. > >>>> > >>>> It is not covered by case #1, because in case #1 there are no other > >>>> pairs in the foundation :) > >>>> > >>>> The case above is covered by the following bullet I suggested: > >>>> > >>>> "- If there is exactly one pair for the same foundation in the > >>>> Waiting state, set the state to Frozen (covers Case #4)=C2=B2 > >>>> > >>>> So, in this case the state would be set to Frozen. > >>>> > >>>> An alternative would be to change the m3 pair to Frozen, and set the > >>>> new pair to Waiting, but I think modifying the state of existing > >>>> pairs would be messy. > >>> > >> =C2=A76.1.2.6 of 5245bis states: > >> > >> 5. For each foundation, the agent sets the state of exactly one > >> candidate pair to the Waiting state (unfreezing it). The > >> candidate pair to unfreeze is chosen by finding the first > >> candidate pair (ordered by lowest component ID and then highest > >> priority if component IDs are equal) in the first check list > >> (according to the usage-defined check list set order) that has > >> that foundation. > >> > >> My inclination is to set the state of this "X" candidate pair to > Waiting, because it is now the candidate with the > >> lowest component ID (and highest prioritiy if the component IDs are > equal) within this foundation. However, if we > >> proceeded in this way then we would have two candidate pairs in the > Waiting state within this foundation. That > >> doesn't seem like a problem, but I wanted to point it out. > > > > Yes. > > > > Another alternative would be to set the current pair in Waiting state t= o > Frozen, since X has higher priority. > > That seems preferable to me. > > Peter > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --f40304373aec89210f05687cda52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christer,

Something that's lost by the simplified set of rules is the guarantee= that the "topmost" pair is always unfrozen. This ensures that th= e two ICE agents always have at least one common pair unfrozen per foundati= on, even when pairs are formed in a different order.

Su= ppose one agent forms pairs in order "A, B", and the other in the= order "B, A". With the simplified set of rules, one agent will u= nfreeze "A" and the other "B", and connectivity checks = may fail for each due to lack of hole-punching. But with the "topmost&= quot; stipulation, one agent will unfreeze "A" and the other both= "A" and "B", so checks will succeed for "A" = before proceeding to "B".

This "topmost&= quot; rule wouldn't be necessary if candidate pairs were formed in a de= terministic order, which Section 16 guarantees. But I thought you were plan= ning to remove the ordering requirements of Section 16?=C2=A0https:/= /mailarchive.ietf.org/arch/msg/ice/XCquM6Gf-8bbG2ADXD4DNqePNK0

On Wed, Ma= r 28, 2018 at 10:54 AM, Peter Saint-Andre <stpeter@mozilla.com> wrote:
On 3/28/18 = 10:51 AM, Christer Holmberg wrote:
> Hi,
>
>>> I think the rules could be simplified in the following way: >>>
>>> - If there are at least one pair in Succeeded state, set the s= tate of
>>> the new pair to Waiting
>>
>> Yes, that's consistent with =C2=A77.2.5.3.3 of 5245bis.
>
> Correct.
>
>>> - If there are two or more pairs in Waiting/In-Progress state,= set the
>>> state of the new pair to Waiting
>>
>> Why "two or more"?
>
> If there is only one (or no) pair in Waiting state, the check list set= has just been initialized, which means there should be no more than one pa= ir in the waiting state.

Is that true in the context of trickle? Couldn't a candidate pai= r
trickle in after initialization of the check list set?

>>> - Otherwise set the state of the new pair to Frozen
>>
>> I think that might do it. I will run through a bunch of scenarios<= br> >> (offlist) to verify.
>
> Please do :)
>
>> Please see one more comment below.
>
> ...
>
>>>>>>>> -=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 If there are no other pairs for the same foundatio= n, set
>>>>>>>> the state to Waiting=C2=A0 =C2=A0(covers C= ase #1)
>>>>>>>
>>>>>>> That covers Case #1 but it is more restrictive= because it doesn't
>>>>>>> cover the case where the new pair is not the o= nly pair, just the
>>>>>>> topmost pair.
>>>>>>
>>>>>> Not sure I understand "is not the only pair&q= uot;.
>>>>>
>>>>> Let's say there are already two pairs for the 5th = foundation:
>>>>>
>>>>>=C2=A0 =C2=A0+-----------------+------+------+----= --+------+------+
>>>>>=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 f1=C2=A0 |=C2=A0 f2=C2= =A0 |=C2=A0 f3=C2=A0 |=C2=A0 f4=C2=A0 |=C2=A0 f5=C2=A0 |
>>>>>=C2=A0 =C2=A0+-----------------+------+------+----= --+------+------+
>>>>>=C2=A0 =C2=A0| m1 (Audio.RTP)=C2=A0 |=C2=A0 W=C2=A0 =C2= =A0|=C2=A0 W=C2=A0 =C2=A0|=C2=A0 W=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 |
>>>>>=C2=A0 =C2=A0+-----------------+------+------+----= --+------+------+
>>>>>=C2=A0 =C2=A0| m2 (Audio.RTCP) |=C2=A0 F=C2=A0 =C2=A0|= =C2=A0 F=C2=A0 =C2=A0|=C2=A0 F=C2=A0 =C2=A0|=C2=A0 W=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 |
>>>>>=C2=A0 =C2=A0+-----------------+------+------+----= --+------+------+
>>>>>=C2=A0 =C2=A0| m3 (Video.RTP)=C2=A0 |=C2=A0 F=C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2= =A0 W=C2=A0 =C2=A0|
>>>>>=C2=A0 =C2=A0+-----------------+------+------+----= --+------+------+
>>>>>=C2=A0 =C2=A0| m4 (Video.RTCP) |=C2=A0 F=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 F= =C2=A0 =C2=A0|
>>>>>=C2=A0 =C2=A0+-----------------+------+------+----= --+------+------+
>>>>>
>>>>> Now we add a new pair "X", which has a lower= component ID than the
>>>>> other pairs:
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0+-----------------+------+------+----= --+------+------+
>>>>>=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 f1=C2=A0 |=C2=A0 f2=C2=A0 |=C2=A0 f3=C2=A0 |= =C2=A0 f4=C2=A0 |=C2=A0 f5=C2=A0 |
>>>>>=C2=A0 =C2=A0+-----------------+------+------+----= --+------+------+
>>>>>=C2=A0 =C2=A0| m1 (Audio.RTP)=C2=A0 |=C2=A0 W=C2=A0 =C2= =A0|=C2=A0 W=C2=A0 =C2=A0|=C2=A0 W=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 |
>>>>>=C2=A0 =C2=A0+-----------------+------+------+----= --+------+------+
>>>>>=C2=A0 =C2=A0| m2 (Audio.RTCP) |=C2=A0 F=C2=A0 =C2=A0|= =C2=A0 F=C2=A0 =C2=A0|=C2=A0 F=C2=A0 =C2=A0|=C2=A0 W=C2=A0 =C2=A0| ^X^=C2= =A0 |
>>>>>=C2=A0 =C2=A0+-----------------+------+------+----= --+------+------+
>>>>>=C2=A0 =C2=A0| m3 (Video.RTP)=C2=A0 |=C2=A0 F=C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2= =A0 W=C2=A0 =C2=A0|
>>>>>=C2=A0 =C2=A0+-----------------+------+------+----= --+------+------+
>>>>>=C2=A0 =C2=A0| m4 (Video.RTCP) |=C2=A0 F=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 F= =C2=A0 =C2=A0|
>>>>>=C2=A0 =C2=A0+-----------------+------+------+----= --+------+------+
>>>>>
>>>>> That doesn't seem to be covered by your text.
>>>>
>>>> It is not covered by case #1, because in case #1 there are= no other
>>>> pairs in the foundation :)
>>>>
>>>> The case above is covered by the following bullet I sugges= ted:
>>>>
>>>> "- If there is exactly one pair for the same foundati= on in the
>>>> Waiting state, set the state to Frozen (covers Case #4)=C2= =B2
>>>>
>>>> So, in this case the state would be set to Frozen.
>>>>
>>>> An alternative would be to change the m3 pair to Frozen, a= nd set the
>>>> new pair to Waiting, but I think modifying the state of ex= isting
>>>> pairs would be messy.
>>>
>> =C2=A76.1.2.6 of 5245bis states:
>>
>>=C2=A0 =C2=A05.=C2=A0 For each foundation, the agent sets the state= of exactly one
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0candidate pair to the Waiting state (unf= reezing it).=C2=A0 The
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0candidate pair to unfreeze is chosen by = finding the first
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0candidate pair (ordered by lowest compon= ent ID and then highest
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0priority if component IDs are equal) in = the first check list
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(according to the usage-defined check li= st set order) that has
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0that foundation.
>>
>> My inclination is to set the state of this "X" candidate= pair to Waiting, because it is now the candidate with the
>> lowest component ID (and highest prioritiy if the component IDs ar= e equal) within this foundation. However, if we
>> proceeded in this way then we would have two candidate pairs in th= e Waiting state within this foundation. That
>> doesn't seem like a problem, but I wanted to point it out.
>
> Yes.
>
> Another alternative would be to set the current pair in Waiting state = to Frozen, since X has higher priority.

That seems preferable to me.

Peter



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


--f40304373aec89210f05687cda52-- From nobody Wed Mar 28 11:17:16 2018 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 90B0C126DED for ; Wed, 28 Mar 2018 11:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 sWTzOgv6zG0y for ; Wed, 28 Mar 2018 11:17:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11930126D0C for ; Wed, 28 Mar 2018 11:17:12 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w2SIH7nc082946 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 28 Mar 2018 13:17:08 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Christer Holmberg , "ice@ietf.org" , Ben Campbell References: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> From: Adam Roach Message-ID: <321c0d02-8e3b-1c6a-769a-ada15a5d5d6e@nostrum.com> Date: Wed, 28 Mar 2018 13:17:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> Content-Type: multipart/alternative; boundary="------------22CE87CD0BDB97B81448A0FF" Content-Language: en-US Archived-At: Subject: Re: [Ice] Tricke ICE: Suggested clarifications to Introduction 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, 28 Mar 2018 18:17:15 -0000 This is a multi-part message in MIME format. --------------22CE87CD0BDB97B81448A0FF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit As a reminder -- this document is on the IESG formal telechat for a week from tomorrow. Speaking only for myself, I find it unnecessarily disruptive when documents change out from under me during the week leading up to the telechat. If you're going to make *editorial* changes[1], please make them today or not at all. /a ____ [1] Technical fixes are always appropriate, although they may slow down processing in some cases; we never want to publish the wrong thing due to process. On 3/24/18 4:53 PM, Christer Holmberg wrote: > > Hi, > > Below is a suggestion on how to modify the Introduction section of > draft-trickle-ice, in order to make it more clear (in my opinion). > > --- > > 1.  Introduction > >    The Interactive Connectivity Establishment (ICE) protocol > >    [rfc5245bis] describes mechanisms how an ICE agent gathers > >    candidates, exchanges candidates with a peer ICE agent, and > >    creates candidate pairs. Once the pairs have been created, the > >    ICE agent will perform connectivity checks, and eventually > >    nominate and select pairs that will be used for sending and > >    receiving media within a session. > >    Although the procedures in [rfc5245bis] are relatively straightforward > >    to implement, they might lead to relatively lengthy session > establishment > >    times, as candidate gathering often involves querying STUN servers > [RFC5389] > >   and allocating relayed candidates using TURN servers [RFC5766]. Although > >    many procedures can be done in parallel, the pacing requirements > [rfc5245bis] > >    still needs to be followed. > >    This document defines a supplementary mode of ICE operation, > >    “Trickle ICEâ€, in which given candidates can be exchanged > incrementally, > >    as soon as they become available (and while other candidates are still > >    gathered). Connectivity checks can also start as soon as candidate > >    pairs have been created. Then, as Trickle ICE allows candidate > gathering and > >    connectivity check in parallel, the session establishment time can be > >    considerable shortened. > >    In addition, this document also defines how to discovers support of > Trickle ICE, > >    and how procedures in [rfc5245bis] are modified when using Trickle > ICE. The > >    document also defines how an Trickle ICE agent can interoperate with an > >    ICE agent compliant to [rfc5245bis]. > >    This document does not define any ICE usage for Trickle ICE. Protocol > >    specific details for Trickle ICE are defined in separate usage > documents. > >    Examples of such documents are [I-D.ietf-mmusic-trickle-ice-sip], which > >    defines usage with the Session Initiation Protocol (SIP) [RFC3261] > >    and the Session Description Protocol [RFC4566] , and > >    [XEP-0176], which defines usage with XMPP [RFC6120]. However, > >    some of the examples in the document uses SDP and the > >    Offer/Answer mechanism [RFC4566] in order to explain the > >    underlying concepts. > >    NOTE: It is worth noting that there is quite a bit of operational > >    experience with the technique behind Trickle ICE, going back as far > as 2005 > >    (when the XMPP Jingle extension defined a "dribble mode" as specified > >    in [XEP-0176]); this document incorporates feedback from those who > >    have implemented and deployed the technique. > > --- > > Regards, > > Christer > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice --------------22CE87CD0BDB97B81448A0FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
As a reminder -- this document is on the IESG formal telechat for a week from tomorrow. Speaking only for myself, I find it unnecessarily disruptive when documents change out from under me during the week leading up to the telechat. If you're going to make *editorial* changes[1], please make them today or not at all.

/a


____
[1] Technical fixes are always appropriate, although they may slow down processing in some cases; we never want to publish the wrong thing due to process.

On 3/24/18 4:53 PM, Christer Holmberg wrote:

Hi,

 

Below is a suggestion on how to modify the Introduction section of draft-trickle-ice, in order to make it more clear (in my opinion).

 

---

 

1.  Introduction

 

   The Interactive Connectivity Establishment (ICE) protocol

   [rfc5245bis] describes mechanisms how an ICE agent gathers

   candidates, exchanges candidates with a peer ICE agent, and

   creates candidate pairs. Once the pairs have been created, the

   ICE agent will perform connectivity checks, and eventually

   nominate and select pairs that will be used for sending and

   receiving media within a session.

 

   Although the procedures in [rfc5245bis] are relatively straightforward

   to implement, they might lead to relatively lengthy session establishment

   times, as candidate gathering often involves querying STUN servers [RFC5389]

  and allocating relayed candidates using TURN servers [RFC5766]. Although

   many procedures can be done in parallel, the pacing requirements [rfc5245bis]

   still needs to be followed.

 

   This document defines a supplementary mode of ICE operation,

   “Trickle ICEâ€, in which given candidates can be exchanged incrementally,

   as soon as they become available (and while other candidates are still

   gathered). Connectivity checks can also start as soon as candidate

   pairs have been created. Then, as Trickle ICE allows candidate gathering and

   connectivity check in parallel, the session establishment time can be

   considerable shortened.

 

   In addition, this document also defines how to discovers support of Trickle ICE,

   and how procedures in [rfc5245bis] are modified when using Trickle ICE. The

   document also defines how an Trickle ICE agent can interoperate with an

   ICE agent compliant to [rfc5245bis].

 

   This document does not define any ICE usage for Trickle ICE. Protocol

   specific details for Trickle ICE are defined in separate usage documents.

   Examples of such documents are [I-D.ietf-mmusic-trickle-ice-sip], which

   defines usage with the Session Initiation Protocol (SIP) [RFC3261]

   and the Session Description Protocol [RFC4566] , and

   [XEP-0176], which defines usage with XMPP [RFC6120]. However,

   some of the examples in the document uses SDP and the

   Offer/Answer mechanism [RFC4566] in order to explain the

   underlying concepts.

 

   NOTE: It is worth noting that there is quite a bit of operational

   experience with the technique behind Trickle ICE, going back as far as 2005

   (when the XMPP Jingle extension defined a "dribble mode" as specified

   in [XEP-0176]); this document incorporates feedback from those who

   have implemented and deployed the technique.

 

---

 

Regards,

 

Christer



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


--------------22CE87CD0BDB97B81448A0FF-- From nobody Wed Mar 28 11:18:30 2018 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 09A30127369 for ; Wed, 28 Mar 2018 11:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Ka3wWks0PA4H for ; Wed, 28 Mar 2018 11:18:26 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 593E0126D0C for ; Wed, 28 Mar 2018 11:18:26 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id v194-v6so4799382itb.0 for ; Wed, 28 Mar 2018 11:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=AOAhJIgOzzmTlAeA16256hmnbbv9D6jnH9Nsz3yLMnM=; b=PYLkd+w8vJ7jqXzR6FjC8jjtOdNQGxUShyYrOVsHwaS70gGuPx/wy7yUhEtJAEUg7W P/nVPLYET+L2wLYM6axadA57NxFMM/ifltJ6DAgVDg0zozkBGPJoTSfUmc+W7yDl4Lj1 7lO07a2bVJ9Wz5RWw/0K6L0z78QpjfUPlJOSY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=AOAhJIgOzzmTlAeA16256hmnbbv9D6jnH9Nsz3yLMnM=; b=FrPP8xSvayukwi/JfxJLxyI5uPoN84FGUDTi5xQsL9k2dWkjbp8bYY7xTpqHt6nt2Q ehSnVTulxvd4Or42djV0C229BfABqdY3wXdJHv8i/vTjd8r9mBm72kqEY9RIR5xHMVdf hIvi65PtH2BFqDWHV6omeSoi9R0P48rT2BJ+60Ea++gi4qfrJP86IIqeKy73PVZHPdop //HjgPVTzSi+Eh+lxdPbnuSstL7R9ACtoGQOCeiJKguoaKgeQPaHGGDHC3xOePWK0eMf 5QVaS650qRJ18VKsiNb5H8Q3Y7Rpgi3nlqTlKyGcY+1uvF9F6DcZkVpOMzYIn/h9dmNz WT9w== X-Gm-Message-State: AElRT7F26Zps28SwsgqSQ41ERyvuZBZjSsqZyx9K+Pvd2fVUfLx6Xi0C GpS1nY0iYsOFnauQon1i7vXlR87sodg= X-Google-Smtp-Source: AIpwx48YfisRH4NUlRxo3FteZjlojZy8LconeMiTeWUG4lkWFJOWUbaitcaSnGOHuF3HKtyvKiYAxQ== X-Received: by 2002:a24:9f82:: with SMTP id c124-v6mr4769676ite.60.1522261105666; Wed, 28 Mar 2018 11:18:25 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id x139-v6sm44921itb.3.2018.03.28.11.18.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 11:18:24 -0700 (PDT) To: Adam Roach , Christer Holmberg , "ice@ietf.org" , Ben Campbell References: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> <321c0d02-8e3b-1c6a-769a-ada15a5d5d6e@nostrum.com> From: Peter Saint-Andre Message-ID: <299c43bb-6747-8ce8-6a76-15a007704fda@mozilla.com> Date: Wed, 28 Mar 2018 12:18:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <321c0d02-8e3b-1c6a-769a-ada15a5d5d6e@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="57zHvWzVjCjP2Xrly4iTPgQi4znJGli5V" Archived-At: Subject: Re: [Ice] Tricke ICE: Suggested clarifications to Introduction 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, 28 Mar 2018 18:18:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --57zHvWzVjCjP2Xrly4iTPgQi4znJGli5V Content-Type: multipart/mixed; boundary="cG6CdV24wdGUqY59I79rXIPNnN9LJBfVV"; protected-headers="v1" From: Peter Saint-Andre To: Adam Roach , Christer Holmberg , "ice@ietf.org" , Ben Campbell Message-ID: <299c43bb-6747-8ce8-6a76-15a007704fda@mozilla.com> Subject: Re: [Ice] Tricke ICE: Suggested clarifications to Introduction References: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> <321c0d02-8e3b-1c6a-769a-ada15a5d5d6e@nostrum.com> In-Reply-To: <321c0d02-8e3b-1c6a-769a-ada15a5d5d6e@nostrum.com> --cG6CdV24wdGUqY59I79rXIPNnN9LJBfVV Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Duly noted. Planning to submit -18 as soon as possible. On 3/28/18 12:17 PM, Adam Roach wrote: > As a reminder -- this document is on the IESG formal telechat for a wee= k > from tomorrow. Speaking only for myself, I find it unnecessarily > disruptive when documents change out from under me during the week > leading up to the telechat. If you're going to make *editorial* > changes[1], please make them today or not at all. >=20 > /a >=20 >=20 > ____ > [1] Technical fixes are always appropriate, although they may slow down= > processing in some cases; we never want to publish the wrong thing due > to process. >=20 > On 3/24/18 4:53 PM, Christer Holmberg wrote: >> >> Hi, >> >> =C2=A0 >> >> Below is a suggestion on how to modify the Introduction section of >> draft-trickle-ice, in order to make it more clear (in my opinion). >> >> =C2=A0 >> >> --- >> >> =C2=A0 >> >> 1.=C2=A0 Introduction >> >> =C2=A0 >> >> =C2=A0=C2=A0 The Interactive Connectivity Establishment (ICE) protocol= >> >> =C2=A0=C2=A0 [rfc5245bis] describes mechanisms how an ICE agent gather= s >> >> =C2=A0=C2=A0=C2=A0candidates, exchanges candidates with a peer ICE age= nt, and >> >> =C2=A0=C2=A0=C2=A0creates candidate pairs. Once the pairs have been cr= eated, the >> >> =C2=A0=C2=A0=C2=A0ICE agent will perform connectivity checks, and even= tually >> >> =C2=A0=C2=A0 nominate and select pairs that will be used for sending a= nd >> >> =C2=A0=C2=A0 receiving media within a session. >> >> =C2=A0 >> >> =C2=A0=C2=A0 Although the procedures in [rfc5245bis] are relatively st= raightforward >> >> =C2=A0=C2=A0 to implement, they might lead to relatively lengthy sessi= on >> establishment >> >> =C2=A0=C2=A0 times, as candidate gathering often involves querying STU= N servers >> [RFC5389] >> >> =C2=A0 and allocating relayed candidates using TURN servers [RFC5766].= Although >> >> =C2=A0=C2=A0 many procedures can be done in parallel, the pacing requi= rements >> [rfc5245bis] >> >> =C2=A0=C2=A0 still needs to be followed. >> >> =C2=A0 >> >> =C2=A0=C2=A0 This document defines a supplementary mode of ICE operati= on, >> >> =C2=A0=C2=A0 =E2=80=9CTrickle ICE=E2=80=9D, in which given candidates = can be exchanged >> incrementally, >> >> =C2=A0=C2=A0 as soon as they become available (and while other candida= tes are still >> >> =C2=A0=C2=A0 gathered). Connectivity checks can also start as soon as = candidate >> >> =C2=A0=C2=A0 pairs have been created. Then, as Trickle ICE allows cand= idate >> gathering and >> >> =C2=A0=C2=A0=C2=A0connectivity check in parallel, the session establis= hment time can be >> >> =C2=A0=C2=A0=C2=A0considerable shortened. >> >> =C2=A0 >> >> =C2=A0=C2=A0 In addition, this document also defines how to discovers = support of >> Trickle ICE, >> >> =C2=A0=C2=A0 and how procedures in [rfc5245bis] are modified when usin= g Trickle >> ICE. The >> >> =C2=A0=C2=A0 document also defines how an Trickle ICE agent can intero= perate with an >> >> =C2=A0=C2=A0 ICE agent compliant to [rfc5245bis]. >> >> =C2=A0 >> >> =C2=A0=C2=A0 This document does not define any ICE usage for Trickle I= CE. Protocol >> >> =C2=A0=C2=A0 specific details for Trickle ICE are defined in separate = usage >> documents. >> >> =C2=A0=C2=A0 Examples of such documents are [I-D.ietf-mmusic-trickle-i= ce-sip], which >> >> =C2=A0=C2=A0 defines usage with the Session Initiation Protocol (SIP) = [RFC3261] >> >> =C2=A0=C2=A0 and the Session Description Protocol [RFC4566] , and >> >> =C2=A0=C2=A0 [XEP-0176], which defines usage with XMPP [RFC6120]. Howe= ver, >> >> =C2=A0=C2=A0 some of the examples in the document uses SDP and the >> >> =C2=A0=C2=A0 Offer/Answer mechanism [RFC4566] in order to explain the >> >> =C2=A0=C2=A0 underlying concepts. >> >> =C2=A0 >> >> =C2=A0=C2=A0 NOTE: It is worth noting that there is quite a bit of ope= rational >> >> =C2=A0=C2=A0 experience with the technique behind Trickle ICE, going b= ack as far >> as 2005 >> >> =C2=A0=C2=A0 (when the XMPP Jingle extension defined a "dribble mode" = as specified >> >> =C2=A0=C2=A0 in [XEP-0176]); this document incorporates feedback from = those who >> >> =C2=A0=C2=A0 have implemented and deployed the technique. >> >> =C2=A0 >> >> --- >> >> =C2=A0 >> >> Regards, >> >> =C2=A0 >> >> Christer >> >> >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >=20 >=20 >=20 >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice >=20 --cG6CdV24wdGUqY59I79rXIPNnN9LJBfVV-- --57zHvWzVjCjP2Xrly4iTPgQi4znJGli5V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq73G8ACgkQZWGMGH9o FKlRERAAxZ4mOwlpzs6lamLdjhaiVeESlA+zRslPHqzg59Y2ih4EibiaoA8TxV6N vY2p5euu/6WAecXy7POlZVeRD4t4BVDjEOk0s3zWEOfXxfHVIFr/Lih2DFClsdMu bc85xVA1NKn3bZh/to5+9T6UskQQ2ZAQB3QrsQavJ83bEDMUhYoFvzzvNObXVbEq 13uclgCKkxNdbH2mlAIEzQ8vW/cr8y/vpm/NBPt+YuAuqPBhyBxRpU99FqnIALbj xGVGFIAUd2MamHtNsjZuXUFWtkZbMvTxnHL/2cIq2LCbrqtkLBXCrY+YSezfnCq3 xogCMfwuq9TvWCHN9x9f6si7R5LkRJvLBepYb9khk+uTuND3rKafnihEnTha9xbK 879thXMzKVvm7QZ2wNXKa+tfUNzfzSuk9yRuOdrpdgOL32HUtLLX4xJ7J8UtoHs0 3/ZwzmMR2cYHHbVKXE9iLXBCLNg8cJ/xGt/rLHO/6GIlC3m/ydW/BPEWS/f0LoRF KJqzjhVexJWWDH1dcWAvTHeLc9CTc1RTL0CRACugcTGedmsXDiTeo9QptV5mWvUV 1xYEcjBcj9irjDXWdVS1CNbTKwR4VglStzCGJmoRpnFZ5to68LMKJR5sU/TsSkdV 049jsuNUHCHQytnCg+SqV/IugvQpx4Ky4R/r8M3gyNBOBLYBtik= =eHME -----END PGP SIGNATURE----- --57zHvWzVjCjP2Xrly4iTPgQi4znJGli5V-- From nobody Wed Mar 28 11:27:55 2018 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 13099127369 for ; Wed, 28 Mar 2018 11:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 hI8zptaHuEdx for ; Wed, 28 Mar 2018 11:27:50 -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 CCE40124E15 for ; Wed, 28 Mar 2018 11:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522261668; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7TNbMfIP6J+qFawk1ONnbC5j6bcGBzIG1++jyv/Sidw=; b=MCnHpwsHJ2xeXJtqTgjPfRR6pUk0xDZ4yam6oF9eJGrNIPVBT4wGg2PL+4GxDYN+ 2Kzx8h2aAVz0ox+nthX1tDdic15tIG1YSK36QnmaoIXoZkNTHfFqmOF16QwqKi3d Rz1FGvv3c9QYRkAHs4wij2eYPUBAf8hkGK7ZMnMuib8=; X-AuditID: c1b4fb3a-e39ff70000005d56-42-5abbdea394fe Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A4.F1.23894.3AEDBBA5; Wed, 28 Mar 2018 20:27:48 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 20:27:46 +0200 From: Christer Holmberg To: Taylor Brandstetter , Peter Saint-Andre CC: "ice@ietf.org" Thread-Topic: [Ice] ICE trickle: Comment on section 8.1.1 Thread-Index: AdPDkuP38FvIt3+USwysDB0OImfNMwCVdT+AAAUSnMD///EdgIAA/DAAgABLdoCAAADWgP//zJvwgABZ4gCAAAMXAP//2T4Q Date: Wed, 28 Mar 2018 18:27:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E380BF@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbHdVXfJvd1RBmsWsFhcXvGQ1eLbhVqL ZytPMToweyzYVOqxZMlPJo++A12sAcxRXDYpqTmZZalF+nYJXBnPNh1kL1jhWtE3t7iB8Yhz FyMnh4SAicS3753MXYxcHEICRxglJq9ezAbhLGGUmDd7MpDDwcEmYCHR/U8bpEFEIELix6Or TCBhZgFFiZd71UDCwkAV385dZIcosZRYuncFC4SdJ7Hs9E5mEJtFQFXi8o2zYDW8Ar4S1x6s ZYVYdYVF4tOHpWwgCU6BQIlJ17eC2YwCYhLfT61hArGZBcQlbj2ZzwRxtIDEkj3nmSFsUYmX j/+xQthKEme/TGGDuE1TYv0ufYhWRYkp3Q+h9gpKnJz5hGUCo+gsJFNnIXTMQtIxC0nHAkaW VYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBEXNwy2+rHYwHnzseYhTgYFTi4XW4tTtKiDWx rLgy9xCjBAezkgjvew2gEG9KYmVValF+fFFpTmrxIUZpDhYlcV6nNIsoIYH0xJLU7NTUgtQi mCwTB6dUA6P8o2sl4dPm+51cGpbmve/TCeFJibc3dz3qijJ4+2iuDuvFA26/HqnmzrD+XPus Ke9ecsn/DfrewX6//r5+53bjrLnGpy3+nxPMtso+VwvP8mI5v2/LM3nRaRfmpGfeel4ceTtp zx7bjcvmfjLl+7iYoeBMafvNukSdVkXbKWnZZTvUmTpXx/1QYinOSDTUYi4qTgQAGFI4RJQC AAA= Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 28 Mar 2018 18:27:53 -0000 SGkgVGF5bG9yLA0KDQo+IFNvbWV0aGluZyB0aGF0J3MgbG9zdCBieSB0aGUgc2ltcGxpZmllZCBz ZXQgb2YgcnVsZXMgaXMgdGhlIGd1YXJhbnRlZSB0aGF0IHRoZSAidG9wbW9zdCIgcGFpciBpcyBh bHdheXMgdW5mcm96ZW4uIA0KPiBUaGlzIGVuc3VyZXMgdGhhdCB0aGUgdHdvIElDRSBhZ2VudHMg YWx3YXlzIGhhdmUgYXQgbGVhc3Qgb25lIGNvbW1vbiBwYWlyIHVuZnJvemVuIHBlciBmb3VuZGF0 aW9uLCBldmVuIHdoZW4gcGFpcnMgYXJlIGZvcm1lZCBpbiBhIGRpZmZlcmVudCBvcmRlci4NCg0K SWYgeW91IGdvIHRvIHRoZSBib3R0b20gb2YgdGhlIGNvbnZlcnNhdGlvbiwgSSB0aGluayBpdCBp cyBjb3ZlcmVkIHRoZXJlIDopDQoNCldoZW4gYSBuZXcgcGFpciBpcyBhZGRlZCwgYW5kIGlmIHRo ZXJlIGlzIGFuIGV4aXN0aW5nIHBhaXIgaW4gV2FpdGluZyBzdGF0ZSwgaWYgdGhlIG5ldyBwYWly IGhhcyBoaWdoZXIgcHJpb3JpdHkgKGkuZS4sIGl0IGlzICJtb3JlIHRvcG1vc3QiIHRoYW4gdGhl IGN1cnJlbnQgcGFpciBpbiBXYWl0aW5nIHN0YXRlKSwgdGhlIG5ldyBwYWlyIGlzIHNldCB0byBX YWl0aW5nLCBhbmQgdGhlIGN1cnJlbnQgdG9wbW9zdCBpcyBjaGFuZ2VkIGZyb20gV2FpdGluZyB0 byBGcm93bi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoNClN1cHBvc2Ugb25l IGFnZW50IGZvcm1zIHBhaXJzIGluIG9yZGVyICJBLCBCIiwgYW5kIHRoZSBvdGhlciBpbiB0aGUg b3JkZXIgIkIsIEEiLiBXaXRoIHRoZSBzaW1wbGlmaWVkIHNldCBvZiBydWxlcywgb25lIGFnZW50 IHdpbGwgdW5mcmVlemUgIkEiIGFuZCB0aGUgb3RoZXIgIkIiLCBhbmQgY29ubmVjdGl2aXR5IGNo ZWNrcyBtYXkgZmFpbCBmb3IgZWFjaCBkdWUgdG8gbGFjayBvZiBob2xlLXB1bmNoaW5nLiBCdXQg d2l0aCB0aGUgInRvcG1vc3QiIHN0aXB1bGF0aW9uLCBvbmUgYWdlbnQgd2lsbCB1bmZyZWV6ZSAi QSIgYW5kIHRoZSBvdGhlciBib3RoICJBIiBhbmQgIkIiLCBzbyBjaGVja3Mgd2lsbCBzdWNjZWVk IGZvciAiQSIgYmVmb3JlIHByb2NlZWRpbmcgdG8gIkIiLg0KDQpUaGlzICJ0b3Btb3N0IiBydWxl IHdvdWxkbid0IGJlIG5lY2Vzc2FyeSBpZiBjYW5kaWRhdGUgcGFpcnMgd2VyZSBmb3JtZWQgaW4g YSBkZXRlcm1pbmlzdGljIG9yZGVyLCB3aGljaCBTZWN0aW9uIDE2IGd1YXJhbnRlZXMuIEJ1dCBJ IHRob3VnaHQgeW91IHdlcmUgcGxhbm5pbmcgdG8gcmVtb3ZlIHRoZSBvcmRlcmluZyByZXF1aXJl bWVudHMgb2YgU2VjdGlvbiAxNj/CoGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9t c2cvaWNlL1hDcXVNNkdmLThiYkcyQURYRDRETnFlUE5LMA0KDQoNCk9uIFdlZCwgTWFyIDI4LCAy MDE4IGF0IDEwOjU0IEFNLCBQZXRlciBTYWludC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT4g d3JvdGU6DQpPbiAzLzI4LzE4IDEwOjUxIEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4g SGksDQo+DQo+Pj4gSSB0aGluayB0aGUgcnVsZXMgY291bGQgYmUgc2ltcGxpZmllZCBpbiB0aGUg Zm9sbG93aW5nIHdheToNCj4+Pg0KPj4+IC0gSWYgdGhlcmUgYXJlIGF0IGxlYXN0IG9uZSBwYWly IGluIFN1Y2NlZWRlZCBzdGF0ZSwgc2V0IHRoZSBzdGF0ZSBvZg0KPj4+IHRoZSBuZXcgcGFpciB0 byBXYWl0aW5nDQo+Pg0KPj4gWWVzLCB0aGF0J3MgY29uc2lzdGVudCB3aXRoIMKnNy4yLjUuMy4z IG9mIDUyNDViaXMuDQo+DQo+IENvcnJlY3QuDQo+DQo+Pj4gLSBJZiB0aGVyZSBhcmUgdHdvIG9y IG1vcmUgcGFpcnMgaW4gV2FpdGluZy9Jbi1Qcm9ncmVzcyBzdGF0ZSwgc2V0IHRoZQ0KPj4+IHN0 YXRlIG9mIHRoZSBuZXcgcGFpciB0byBXYWl0aW5nDQo+Pg0KPj4gV2h5ICJ0d28gb3IgbW9yZSI/ DQo+DQo+IElmIHRoZXJlIGlzIG9ubHkgb25lIChvciBubykgcGFpciBpbiBXYWl0aW5nIHN0YXRl LCB0aGUgY2hlY2sgbGlzdCBzZXQgaGFzIGp1c3QgYmVlbiBpbml0aWFsaXplZCwgd2hpY2ggbWVh bnMgdGhlcmUgc2hvdWxkIGJlIG5vIG1vcmUgdGhhbiBvbmUgcGFpciBpbiB0aGUgd2FpdGluZyBz dGF0ZS4NCg0KSXMgdGhhdCB0cnVlIGluIHRoZSBjb250ZXh0IG9mIHRyaWNrbGU/IENvdWxkbid0 IGEgY2FuZGlkYXRlIHBhaXINCnRyaWNrbGUgaW4gYWZ0ZXIgaW5pdGlhbGl6YXRpb24gb2YgdGhl IGNoZWNrIGxpc3Qgc2V0Pw0KDQo+Pj4gLSBPdGhlcndpc2Ugc2V0IHRoZSBzdGF0ZSBvZiB0aGUg bmV3IHBhaXIgdG8gRnJvemVuDQo+Pg0KPj4gSSB0aGluayB0aGF0IG1pZ2h0IGRvIGl0LiBJIHdp bGwgcnVuIHRocm91Z2ggYSBidW5jaCBvZiBzY2VuYXJpb3MNCj4+IChvZmZsaXN0KSB0byB2ZXJp ZnkuDQo+DQo+IFBsZWFzZSBkbyA6KQ0KPg0KPj4gUGxlYXNlIHNlZSBvbmUgbW9yZSBjb21tZW50 IGJlbG93Lg0KPg0KPiAuLi4NCj4NCj4+Pj4+Pj4+IC3CoCDCoCDCoCDCoCDCoCBJZiB0aGVyZSBh cmUgbm8gb3RoZXIgcGFpcnMgZm9yIHRoZSBzYW1lIGZvdW5kYXRpb24sIHNldA0KPj4+Pj4+Pj4g dGhlIHN0YXRlIHRvIFdhaXRpbmfCoCDCoChjb3ZlcnMgQ2FzZSAjMSkNCj4+Pj4+Pj4NCj4+Pj4+ Pj4gVGhhdCBjb3ZlcnMgQ2FzZSAjMSBidXQgaXQgaXMgbW9yZSByZXN0cmljdGl2ZSBiZWNhdXNl IGl0IGRvZXNuJ3QNCj4+Pj4+Pj4gY292ZXIgdGhlIGNhc2Ugd2hlcmUgdGhlIG5ldyBwYWlyIGlz IG5vdCB0aGUgb25seSBwYWlyLCBqdXN0IHRoZQ0KPj4+Pj4+PiB0b3Btb3N0IHBhaXIuDQo+Pj4+ Pj4NCj4+Pj4+PiBOb3Qgc3VyZSBJIHVuZGVyc3RhbmQgImlzIG5vdCB0aGUgb25seSBwYWlyIi4N Cj4+Pj4+DQo+Pj4+PiBMZXQncyBzYXkgdGhlcmUgYXJlIGFscmVhZHkgdHdvIHBhaXJzIGZvciB0 aGUgNXRoIGZvdW5kYXRpb246DQo+Pj4+Pg0KPj4+Pj7CoCDCoCstLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKw0KPj4+Pj7CoCDCoHzCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgZjHCoCB8wqAgZjLCoCB8wqAgZjPCoCB8wqAg ZjTCoCB8wqAgZjXCoCB8DQo+Pj4+PsKgIMKgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS0t LS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+Pj4+PsKgIMKgfCBtMSAoQXVkaW8uUlRQKcKgIHzC oCBXwqAgwqB8wqAgV8KgIMKgfMKgIFfCoCDCoHzCoCDCoCDCoCB8wqAgwqAgwqAgfA0KPj4+Pj7C oCDCoCstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0t Kw0KPj4+Pj7CoCDCoHwgbTIgKEF1ZGlvLlJUQ1ApIHzCoCBGwqAgwqB8wqAgRsKgIMKgfMKgIEbC oCDCoHzCoCBXwqAgwqB8wqAgwqAgwqAgfA0KPj4+Pj7CoCDCoCstLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKw0KPj4+Pj7CoCDCoHwgbTMgKFZpZGVv LlJUUCnCoCB8wqAgRsKgIMKgfMKgIMKgIMKgIHzCoCDCoCDCoCB8wqAgwqAgwqAgfMKgIFfCoCDC oHwNCj4+Pj4+wqAgwqArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0t LS0tKy0tLS0tLSsNCj4+Pj4+wqAgwqB8IG00IChWaWRlby5SVENQKSB8wqAgRsKgIMKgfMKgIMKg IMKgIHzCoCDCoCDCoCB8wqAgwqAgwqAgfMKgIEbCoCDCoHwNCj4+Pj4+wqAgwqArLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSsNCj4+Pj4+DQo+Pj4+ PiBOb3cgd2UgYWRkIGEgbmV3IHBhaXIgIlgiLCB3aGljaCBoYXMgYSBsb3dlciBjb21wb25lbnQg SUQgdGhhbiB0aGUNCj4+Pj4+IG90aGVyIHBhaXJzOg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PsKgIMKg Ky0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+ Pj4+PsKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIGYxwqAgfMKgIGYywqAgfMKg IGYzwqAgfMKgIGY0wqAgfMKgIGY1wqAgfA0KPj4+Pj7CoCDCoCstLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKw0KPj4+Pj7CoCDCoHwgbTEgKEF1ZGlv LlJUUCnCoCB8wqAgV8KgIMKgfMKgIFfCoCDCoHzCoCBXwqAgwqB8wqAgwqAgwqAgfMKgIMKgIMKg IHwNCj4+Pj4+wqAgwqArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0t LS0tKy0tLS0tLSsNCj4+Pj4+wqAgwqB8IG0yIChBdWRpby5SVENQKSB8wqAgRsKgIMKgfMKgIEbC oCDCoHzCoCBGwqAgwqB8wqAgV8KgIMKgfCBeWF7CoCB8DQo+Pj4+PsKgIMKgKy0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rDQo+Pj4+PsKgIMKgfCBt MyAoVmlkZW8uUlRQKcKgIHzCoCBGwqAgwqB8wqAgwqAgwqAgfMKgIMKgIMKgIHzCoCDCoCDCoCB8 wqAgV8KgIMKgfA0KPj4+Pj7CoCDCoCstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0t LS0tLSstLS0tLS0rLS0tLS0tKw0KPj4+Pj7CoCDCoHwgbTQgKFZpZGVvLlJUQ1ApIHzCoCBGwqAg wqB8wqAgwqAgwqAgfMKgIMKgIMKgIHzCoCDCoCDCoCB8wqAgRsKgIMKgfA0KPj4+Pj7CoCDCoCst LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKw0KPj4+ Pj4NCj4+Pj4+IFRoYXQgZG9lc24ndCBzZWVtIHRvIGJlIGNvdmVyZWQgYnkgeW91ciB0ZXh0Lg0K Pj4+Pg0KPj4+PiBJdCBpcyBub3QgY292ZXJlZCBieSBjYXNlICMxLCBiZWNhdXNlIGluIGNhc2Ug IzEgdGhlcmUgYXJlIG5vIG90aGVyDQo+Pj4+IHBhaXJzIGluIHRoZSBmb3VuZGF0aW9uIDopDQo+ Pj4+DQo+Pj4+IFRoZSBjYXNlIGFib3ZlIGlzIGNvdmVyZWQgYnkgdGhlIGZvbGxvd2luZyBidWxs ZXQgSSBzdWdnZXN0ZWQ6DQo+Pj4+DQo+Pj4+ICItIElmIHRoZXJlIGlzIGV4YWN0bHkgb25lIHBh aXIgZm9yIHRoZSBzYW1lIGZvdW5kYXRpb24gaW4gdGhlDQo+Pj4+IFdhaXRpbmcgc3RhdGUsIHNl dCB0aGUgc3RhdGUgdG8gRnJvemVuIChjb3ZlcnMgQ2FzZSAjNCnCsg0KPj4+Pg0KPj4+PiBTbywg aW4gdGhpcyBjYXNlIHRoZSBzdGF0ZSB3b3VsZCBiZSBzZXQgdG8gRnJvemVuLg0KPj4+Pg0KPj4+ PiBBbiBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byBjaGFuZ2UgdGhlIG0zIHBhaXIgdG8gRnJvemVu LCBhbmQgc2V0IHRoZQ0KPj4+PiBuZXcgcGFpciB0byBXYWl0aW5nLCBidXQgSSB0aGluayBtb2Rp ZnlpbmcgdGhlIHN0YXRlIG9mIGV4aXN0aW5nDQo+Pj4+IHBhaXJzIHdvdWxkIGJlIG1lc3N5Lg0K Pj4+DQo+PiDCpzYuMS4yLjYgb2YgNTI0NWJpcyBzdGF0ZXM6DQo+Pg0KPj7CoCDCoDUuwqAgRm9y IGVhY2ggZm91bmRhdGlvbiwgdGhlIGFnZW50IHNldHMgdGhlIHN0YXRlIG9mIGV4YWN0bHkgb25l DQo+PsKgIMKgIMKgIMKgY2FuZGlkYXRlIHBhaXIgdG8gdGhlIFdhaXRpbmcgc3RhdGUgKHVuZnJl ZXppbmcgaXQpLsKgIFRoZQ0KPj7CoCDCoCDCoCDCoGNhbmRpZGF0ZSBwYWlyIHRvIHVuZnJlZXpl IGlzIGNob3NlbiBieSBmaW5kaW5nIHRoZSBmaXJzdA0KPj7CoCDCoCDCoCDCoGNhbmRpZGF0ZSBw YWlyIChvcmRlcmVkIGJ5IGxvd2VzdCBjb21wb25lbnQgSUQgYW5kIHRoZW4gaGlnaGVzdA0KPj7C oCDCoCDCoCDCoHByaW9yaXR5IGlmIGNvbXBvbmVudCBJRHMgYXJlIGVxdWFsKSBpbiB0aGUgZmly c3QgY2hlY2sgbGlzdA0KPj7CoCDCoCDCoCDCoChhY2NvcmRpbmcgdG8gdGhlIHVzYWdlLWRlZmlu ZWQgY2hlY2sgbGlzdCBzZXQgb3JkZXIpIHRoYXQgaGFzDQo+PsKgIMKgIMKgIMKgdGhhdCBmb3Vu ZGF0aW9uLg0KPj4NCj4+IE15IGluY2xpbmF0aW9uIGlzIHRvIHNldCB0aGUgc3RhdGUgb2YgdGhp cyAiWCIgY2FuZGlkYXRlIHBhaXIgdG8gV2FpdGluZywgYmVjYXVzZSBpdCBpcyBub3cgdGhlIGNh bmRpZGF0ZSB3aXRoIHRoZQ0KPj4gbG93ZXN0IGNvbXBvbmVudCBJRCAoYW5kIGhpZ2hlc3QgcHJp b3JpdGl5IGlmIHRoZSBjb21wb25lbnQgSURzIGFyZSBlcXVhbCkgd2l0aGluIHRoaXMgZm91bmRh dGlvbi4gSG93ZXZlciwgaWYgd2UNCj4+IHByb2NlZWRlZCBpbiB0aGlzIHdheSB0aGVuIHdlIHdv dWxkIGhhdmUgdHdvIGNhbmRpZGF0ZSBwYWlycyBpbiB0aGUgV2FpdGluZyBzdGF0ZSB3aXRoaW4g dGhpcyBmb3VuZGF0aW9uLiBUaGF0DQo+PiBkb2Vzbid0IHNlZW0gbGlrZSBhIHByb2JsZW0sIGJ1 dCBJIHdhbnRlZCB0byBwb2ludCBpdCBvdXQuDQo+DQo+IFllcy4NCj4NCj4gQW5vdGhlciBhbHRl cm5hdGl2ZSB3b3VsZCBiZSB0byBzZXQgdGhlIGN1cnJlbnQgcGFpciBpbiBXYWl0aW5nIHN0YXRl IHRvIEZyb3plbiwgc2luY2UgWCBoYXMgaGlnaGVyIHByaW9yaXR5Lg0KVGhhdCBzZWVtcyBwcmVm ZXJhYmxlIHRvIG1lLg0KDQpQZXRlcg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkljZSBtYWlsaW5nIGxpc3QNCkljZUBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCg0K From nobody Wed Mar 28 11:30:21 2018 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 2C5B01271DF for ; Wed, 28 Mar 2018 11:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 4nY1edLoF_6x for ; Wed, 28 Mar 2018 11:30:17 -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 D77EC124E15 for ; Wed, 28 Mar 2018 11:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522261815; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Y/+xsjxssGKyE4lol+Rak7iPwWRmB54MTj46+D4fAsg=; b=IRsIFkKwtMiIXc82nTIMNO4g9hOabDiEwjQwp+7tSjA5N03iEJT8KdxF/mBVZnwq 0i+8OiOBoJh7TYfy2aPw5XldPOaj1iNsFw99Yql54N6O7XTlJTlp928ib1Q4Ci46 oEd2hJijTLjAdwo9FAnE0ZBEwjS1gg47nGfgoFCMzXI=; X-AuditID: c1b4fb25-d69a99c000004653-3a-5abbdf36927a Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4D.91.18003.63FDBBA5; Wed, 28 Mar 2018 20:30:15 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 20:29:23 +0200 From: Christer Holmberg To: Adam Roach , "ice@ietf.org" , Ben Campbell Thread-Topic: [Ice] Tricke ICE: Suggested clarifications to Introduction Thread-Index: AdPDqyqQBt8cF0w/QDKTIeEKNJW1+wDBQncAAASRy/A= Date: Wed, 28 Mar 2018 18:29:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E380FC@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> <321c0d02-8e3b-1c6a-769a-ada15a5d5d6e@nostrum.com> In-Reply-To: <321c0d02-8e3b-1c6a-769a-ada15a5d5d6e@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.164] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B72E380FCESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbHdXtf8/u4ogwMvuC32/F3EbjG/8zS7 xbcLtQ7MHkuW/GTymLXzCUsAUxSXTUpqTmZZapG+XQJXxqPDUgV/JjBWzPp1krWBsaeXsYuR k0NCwERi870Wti5GLg4hgSOMEis3NDJDOEsYJZ7vWADkcHCwCVhIdP/TBmkQEUiSeN3ZyQgS FhZwl5jXZAsR9pBoPtPKCmFbSZw49gHMZhFQldj14AQ7iM0r4CvRu+4hC8T4JkaJObMvsYLM 4RSwl5i7XB6khlFATOL7qTVMIDazgLjErSfzmSDuFJBYsuc8M4QtKvHy8T9WCFtJ4uyXKWwQ 9fkSn79eYIPYJShxcuYTlgmMwrOQjJqFpGwWkrJZQFcwC2hKrN+lD1GiKDGl+yE7hK0h0Tpn Ljuy+AJG9lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgVF0cMtv1R2Ml984HmIU4GBU4uEN urU7Sog1say4MvcQowQHs5II73sNoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeh+abo4QE0hNL UrNTUwtSi2CyTBycUg2M5d/qFa/vUrmmUBL3re3GvzAnjS3+LHqst9gvHF4s6mYRezB55ZGJ q+s/hXm23WE7d2VlxOIDPg9efNM5dXTP8wcWlp6+Vd9yPAWcF0xZ13v4BK/eO1HOayyxp7eu +yuWzMK6T5Sh5pDfguZd0VfrHqwP4d7tEM24pbRJ5Mz5VXt5ujY9yNr6TImlOCPRUIu5qDgR AJc58dyeAgAA Archived-At: Subject: Re: [Ice] Tricke ICE: Suggested clarifications to Introduction 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, 28 Mar 2018 18:30:20 -0000 --_000_7594FB04B1934943A5C02806D1A2204B72E380FCESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWRhbSwNCg0KPkFzIGEgcmVtaW5kZXIgLS0gdGhpcyBkb2N1bWVudCBpcyBvbiB0aGUgSUVT RyBmb3JtYWwgdGVsZWNoYXQgZm9yIGEgd2VlayBmcm9tIHRvbW9ycm93LiA+U3BlYWtpbmcgb25s eSBmb3IgbXlzZWxmLCBJIGZpbmQgaXQgdW5uZWNlc3NhcmlseSBkaXNydXB0aXZlIHdoZW4gZG9j dW1lbnRzIGNoYW5nZSBvdXQgPmZyb20gdW5kZXIgbWUgZHVyaW5nIHRoZSB3ZWVrIGxlYWRpbmcg dXAgdG8gdGhlIHRlbGVjaGF0LiBJZiB5b3UncmUgZ29pbmcgdG8gbWFrZSA+KmVkaXRvcmlhbCog Y2hhbmdlc1sxXSwgcGxlYXNlIG1ha2UgdGhlbSB0b2RheSBvciBub3QgYXQgYWxsLg0KDQpVbmZv cnR1bmF0ZWx5IGl0IHdhcyBub3RlZCB0aGF0IHRoZSBkcmFmdCBjb250YWlucyB0ZXh0IHRoYXQg aXMgYmFzZWQgb24gb2xkIDUyNDViaXMgcHJvY2VkdXJlcy4gU28sIHdoaWxlIGNoYW5nZXMgYXJl IGVkaXRvcmlhbCwgdGhlcmUgYXJlIGFsc28gdGVjaG5pY2FsIGNoYW5nZXMuDQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQoNCg0KDQpPbiAzLzI0LzE4IDQ6NTMgUE0sIENocmlzdGVyIEhvbG1iZXJn IHdyb3RlOg0KSGksDQoNCkJlbG93IGlzIGEgc3VnZ2VzdGlvbiBvbiBob3cgdG8gbW9kaWZ5IHRo ZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBvZiBkcmFmdC10cmlja2xlLWljZSwgaW4gb3JkZXIgdG8g bWFrZSBpdCBtb3JlIGNsZWFyIChpbiBteSBvcGluaW9uKS4NCg0KLS0tDQoNCjEuICBJbnRyb2R1 Y3Rpb24NCg0KICAgVGhlIEludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2htZW50IChJ Q0UpIHByb3RvY29sDQogICBbcmZjNTI0NWJpc10gZGVzY3JpYmVzIG1lY2hhbmlzbXMgaG93IGFu IElDRSBhZ2VudCBnYXRoZXJzDQogICBjYW5kaWRhdGVzLCBleGNoYW5nZXMgY2FuZGlkYXRlcyB3 aXRoIGEgcGVlciBJQ0UgYWdlbnQsIGFuZA0KICAgY3JlYXRlcyBjYW5kaWRhdGUgcGFpcnMuIE9u Y2UgdGhlIHBhaXJzIGhhdmUgYmVlbiBjcmVhdGVkLCB0aGUNCiAgIElDRSBhZ2VudCB3aWxsIHBl cmZvcm0gY29ubmVjdGl2aXR5IGNoZWNrcywgYW5kIGV2ZW50dWFsbHkNCiAgIG5vbWluYXRlIGFu ZCBzZWxlY3QgcGFpcnMgdGhhdCB3aWxsIGJlIHVzZWQgZm9yIHNlbmRpbmcgYW5kDQogICByZWNl aXZpbmcgbWVkaWEgd2l0aGluIGEgc2Vzc2lvbi4NCg0KICAgQWx0aG91Z2ggdGhlIHByb2NlZHVy ZXMgaW4gW3JmYzUyNDViaXNdIGFyZSByZWxhdGl2ZWx5IHN0cmFpZ2h0Zm9yd2FyZA0KICAgdG8g aW1wbGVtZW50LCB0aGV5IG1pZ2h0IGxlYWQgdG8gcmVsYXRpdmVseSBsZW5ndGh5IHNlc3Npb24g ZXN0YWJsaXNobWVudA0KICAgdGltZXMsIGFzIGNhbmRpZGF0ZSBnYXRoZXJpbmcgb2Z0ZW4gaW52 b2x2ZXMgcXVlcnlpbmcgU1RVTiBzZXJ2ZXJzIFtSRkM1Mzg5XQ0KICBhbmQgYWxsb2NhdGluZyBy ZWxheWVkIGNhbmRpZGF0ZXMgdXNpbmcgVFVSTiBzZXJ2ZXJzIFtSRkM1NzY2XS4gQWx0aG91Z2gN CiAgIG1hbnkgcHJvY2VkdXJlcyBjYW4gYmUgZG9uZSBpbiBwYXJhbGxlbCwgdGhlIHBhY2luZyBy ZXF1aXJlbWVudHMgW3JmYzUyNDViaXNdDQogICBzdGlsbCBuZWVkcyB0byBiZSBmb2xsb3dlZC4N Cg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc3VwcGxlbWVudGFyeSBtb2RlIG9mIElDRSBv cGVyYXRpb24sDQogICDigJxUcmlja2xlIElDReKAnSwgaW4gd2hpY2ggZ2l2ZW4gY2FuZGlkYXRl cyBjYW4gYmUgZXhjaGFuZ2VkIGluY3JlbWVudGFsbHksDQogICBhcyBzb29uIGFzIHRoZXkgYmVj b21lIGF2YWlsYWJsZSAoYW5kIHdoaWxlIG90aGVyIGNhbmRpZGF0ZXMgYXJlIHN0aWxsDQogICBn YXRoZXJlZCkuIENvbm5lY3Rpdml0eSBjaGVja3MgY2FuIGFsc28gc3RhcnQgYXMgc29vbiBhcyBj YW5kaWRhdGUNCiAgIHBhaXJzIGhhdmUgYmVlbiBjcmVhdGVkLiBUaGVuLCBhcyBUcmlja2xlIElD RSBhbGxvd3MgY2FuZGlkYXRlIGdhdGhlcmluZyBhbmQNCiAgIGNvbm5lY3Rpdml0eSBjaGVjayBp biBwYXJhbGxlbCwgdGhlIHNlc3Npb24gZXN0YWJsaXNobWVudCB0aW1lIGNhbiBiZQ0KICAgY29u c2lkZXJhYmxlIHNob3J0ZW5lZC4NCg0KICAgSW4gYWRkaXRpb24sIHRoaXMgZG9jdW1lbnQgYWxz byBkZWZpbmVzIGhvdyB0byBkaXNjb3ZlcnMgc3VwcG9ydCBvZiBUcmlja2xlIElDRSwNCiAgIGFu ZCBob3cgcHJvY2VkdXJlcyBpbiBbcmZjNTI0NWJpc10gYXJlIG1vZGlmaWVkIHdoZW4gdXNpbmcg VHJpY2tsZSBJQ0UuIFRoZQ0KICAgZG9jdW1lbnQgYWxzbyBkZWZpbmVzIGhvdyBhbiBUcmlja2xl IElDRSBhZ2VudCBjYW4gaW50ZXJvcGVyYXRlIHdpdGggYW4NCiAgIElDRSBhZ2VudCBjb21wbGlh bnQgdG8gW3JmYzUyNDViaXNdLg0KDQogICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGRlZmluZSBh bnkgSUNFIHVzYWdlIGZvciBUcmlja2xlIElDRS4gUHJvdG9jb2wNCiAgIHNwZWNpZmljIGRldGFp bHMgZm9yIFRyaWNrbGUgSUNFIGFyZSBkZWZpbmVkIGluIHNlcGFyYXRlIHVzYWdlIGRvY3VtZW50 cy4NCiAgIEV4YW1wbGVzIG9mIHN1Y2ggZG9jdW1lbnRzIGFyZSBbSS1ELmlldGYtbW11c2ljLXRy aWNrbGUtaWNlLXNpcF0sIHdoaWNoDQogICBkZWZpbmVzIHVzYWdlIHdpdGggdGhlIFNlc3Npb24g SW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBbUkZDMzI2MV0NCiAgIGFuZCB0aGUgU2Vzc2lvbiBE ZXNjcmlwdGlvbiBQcm90b2NvbCBbUkZDNDU2Nl0gLCBhbmQNCiAgIFtYRVAtMDE3Nl0sIHdoaWNo IGRlZmluZXMgdXNhZ2Ugd2l0aCBYTVBQIFtSRkM2MTIwXS4gSG93ZXZlciwNCiAgIHNvbWUgb2Yg dGhlIGV4YW1wbGVzIGluIHRoZSBkb2N1bWVudCB1c2VzIFNEUCBhbmQgdGhlDQogICBPZmZlci9B bnN3ZXIgbWVjaGFuaXNtIFtSRkM0NTY2XSBpbiBvcmRlciB0byBleHBsYWluIHRoZQ0KICAgdW5k ZXJseWluZyBjb25jZXB0cy4NCg0KICAgTk9URTogSXQgaXMgd29ydGggbm90aW5nIHRoYXQgdGhl cmUgaXMgcXVpdGUgYSBiaXQgb2Ygb3BlcmF0aW9uYWwNCiAgIGV4cGVyaWVuY2Ugd2l0aCB0aGUg dGVjaG5pcXVlIGJlaGluZCBUcmlja2xlIElDRSwgZ29pbmcgYmFjayBhcyBmYXIgYXMgMjAwNQ0K ICAgKHdoZW4gdGhlIFhNUFAgSmluZ2xlIGV4dGVuc2lvbiBkZWZpbmVkIGEgImRyaWJibGUgbW9k ZSIgYXMgc3BlY2lmaWVkDQogICBpbiBbWEVQLTAxNzZdKTsgdGhpcyBkb2N1bWVudCBpbmNvcnBv cmF0ZXMgZmVlZGJhY2sgZnJvbSB0aG9zZSB3aG8NCiAgIGhhdmUgaW1wbGVtZW50ZWQgYW5kIGRl cGxveWVkIHRoZSB0ZWNobmlxdWUuDQoNCi0tLQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpJ Y2UgbWFpbGluZyBsaXN0DQoNCkljZUBpZXRmLm9yZzxtYWlsdG86SWNlQGlldGYub3JnPg0KDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0KDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B72E380FCESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNv bG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNv bG9yOmJsYWNrOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uRW1haWxTdHls ZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1HQiIgbGluaz0iIzA1 NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBBZGFtLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mZ3Q7PC9zcGFuPkFzIGEgcmVtaW5kZXIgLS0gdGhpcyBkb2N1bWVudCBpcyBvbiB0aGUg SUVTRyBmb3JtYWwgdGVsZWNoYXQgZm9yIGEgd2VlayBmcm9tIHRvbW9ycm93Lg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+U3BlYWtpbmcgb25seSBmb3IgbXlzZWxmLCBJ IGZpbmQgaXQgdW5uZWNlc3NhcmlseSBkaXNydXB0aXZlIHdoZW4gZG9jdW1lbnRzIGNoYW5nZSBv dXQNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPmZyb20gdW5kZXIgbWUg ZHVyaW5nIHRoZSB3ZWVrIGxlYWRpbmcgdXAgdG8gdGhlIHRlbGVjaGF0LiBJZiB5b3UncmUgZ29p bmcgdG8gbWFrZQ0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+KmVkaXRv cmlhbCogY2hhbmdlc1sxXSwgcGxlYXNlIG1ha2UgdGhlbSB0b2RheSBvciBub3QgYXQgYWxsLjxi cj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VW5m b3J0dW5hdGVseSBpdCB3YXMgbm90ZWQgdGhhdCB0aGUgZHJhZnQgY29udGFpbnMgdGV4dCB0aGF0 IGlzIGJhc2VkIG9uIG9sZCA1MjQ1YmlzIHByb2NlZHVyZXMuIFNvLCB3aGlsZSBjaGFuZ2VzIGFy ZSBlZGl0b3JpYWwsIHRoZXJlIGFyZSBhbHNvIHRlY2huaWNhbCBjaGFuZ2VzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQpPbiAzLzI0LzE4IDQ6NTMgUE0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJlbG93IGlzIGEgc3VnZ2VzdGlvbiBvbiBob3cgdG8gbW9kaWZ5 IHRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBvZiBkcmFmdC10cmlja2xlLWljZSwgaW4gb3JkZXIg dG8gbWFrZSBpdCBtb3JlIGNsZWFyIChpbiBteSBvcGluaW9uKS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuJm5ic3A7IEludHJvZHVjdGlvbjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgVGhlIEludGVyYWN0aXZlIENvbm5l Y3Rpdml0eSBFc3RhYmxpc2htZW50IChJQ0UpIHByb3RvY29sPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgW3JmYzUyNDViaXNdIGRlc2NyaWJlcyBtZWNo YW5pc21zIGhvdyBhbiBJQ0UgYWdlbnQgZ2F0aGVycw0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDtjYW5kaWRhdGVzLCBleGNoYW5nZXMgY2Fu ZGlkYXRlcyB3aXRoIGEgcGVlciBJQ0UgYWdlbnQsIGFuZA0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDtjcmVhdGVzIGNhbmRpZGF0ZSBwYWly cy4gT25jZSB0aGUgcGFpcnMgaGF2ZSBiZWVuIGNyZWF0ZWQsIHRoZQ0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDtJQ0UgYWdlbnQgd2lsbCBw ZXJmb3JtIGNvbm5lY3Rpdml0eSBjaGVja3MsIGFuZCBldmVudHVhbGx5PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgbm9taW5hdGUgYW5kIHNlbGVjdCBw YWlycyB0aGF0IHdpbGwgYmUgdXNlZCBmb3Igc2VuZGluZyBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyByZWNlaXZpbmcgbWVkaWEgd2l0aGluIGEg c2Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IEFsdGhvdWdoIHRo ZSBwcm9jZWR1cmVzIGluIFtyZmM1MjQ1YmlzXSBhcmUgcmVsYXRpdmVseSBzdHJhaWdodGZvcndh cmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyB0byBp bXBsZW1lbnQsIHRoZXkgbWlnaHQgbGVhZCB0byByZWxhdGl2ZWx5IGxlbmd0aHkgc2Vzc2lvbiBl c3RhYmxpc2htZW50PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsgdGltZXMsIGFzIGNhbmRpZGF0ZSBnYXRoZXJpbmcgb2Z0ZW4gaW52b2x2ZXMgcXVlcnlp bmcgU1RVTiBzZXJ2ZXJzIFtSRkM1Mzg5XTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7IGFuZCBhbGxvY2F0aW5nIHJlbGF5ZWQgY2FuZGlkYXRlcyB1c2luZyBUVVJO IHNlcnZlcnMgW1JGQzU3NjZdLiBBbHRob3VnaDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Jm5ic3A7IG1hbnkgcHJvY2VkdXJlcyBjYW4gYmUgZG9uZSBpbiBwYXJh bGxlbCwgdGhlIHBhY2luZyByZXF1aXJlbWVudHMgW3JmYzUyNDViaXNdPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgc3RpbGwgbmVlZHMgdG8gYmUgZm9s bG93ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50 IGRlZmluZXMgYSBzdXBwbGVtZW50YXJ5IG1vZGUgb2YgSUNFIG9wZXJhdGlvbiw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyDigJxUcmlja2xlIElDReKA nSwgaW4gd2hpY2ggZ2l2ZW4gY2FuZGlkYXRlcyBjYW4gYmUgZXhjaGFuZ2VkIGluY3JlbWVudGFs bHksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgYXMg c29vbiBhcyB0aGV5IGJlY29tZSBhdmFpbGFibGUgKGFuZCB3aGlsZSBvdGhlciBjYW5kaWRhdGVz IGFyZSBzdGlsbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7IGdhdGhlcmVkKS4gQ29ubmVjdGl2aXR5IGNoZWNrcyBjYW4gYWxzbyBzdGFydCBhcyBzb29u IGFzIGNhbmRpZGF0ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7IHBhaXJzIGhhdmUgYmVlbiBjcmVhdGVkLiBUaGVuLCBhcyBUcmlja2xlIElDRSBhbGxv d3MgY2FuZGlkYXRlIGdhdGhlcmluZyBhbmQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Y29ubmVjdGl2aXR5IGNoZWNrIGluIHBhcmFsbGVs LCB0aGUgc2Vzc2lvbiBlc3RhYmxpc2htZW50IHRpbWUgY2FuIGJlDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwO2NvbnNpZGVyYWJsZSBzaG9y dGVuZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBJbiBhZGRpdGlvbiwg dGhpcyBkb2N1bWVudCBhbHNvIGRlZmluZXMgaG93IHRvIGRpc2NvdmVycyBzdXBwb3J0IG9mIFRy aWNrbGUgSUNFLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7IGFuZCBob3cgcHJvY2VkdXJlcyBpbiBbcmZjNTI0NWJpc10gYXJlIG1vZGlmaWVkIHdoZW4g dXNpbmcgVHJpY2tsZSBJQ0UuIFRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7Jm5ic3A7IGRvY3VtZW50IGFsc28gZGVmaW5lcyBob3cgYW4gVHJpY2tsZSBJQ0Ug YWdlbnQgY2FuIGludGVyb3BlcmF0ZSB3aXRoIGFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgSUNFIGFnZW50IGNvbXBsaWFudCB0byBbcmZjNTI0NWJp c10uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRv ZXMgbm90IGRlZmluZSBhbnkgSUNFIHVzYWdlIGZvciBUcmlja2xlIElDRS4gUHJvdG9jb2w8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBzcGVjaWZpYyBk ZXRhaWxzIGZvciBUcmlja2xlIElDRSBhcmUgZGVmaW5lZCBpbiBzZXBhcmF0ZSB1c2FnZSBkb2N1 bWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsg RXhhbXBsZXMgb2Ygc3VjaCBkb2N1bWVudHMgYXJlIFtJLUQuaWV0Zi1tbXVzaWMtdHJpY2tsZS1p Y2Utc2lwXSwgd2hpY2g8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyBkZWZpbmVzIHVzYWdlIHdpdGggdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2Nv bCAoU0lQKSBbUkZDMzI2MV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyBhbmQgdGhlIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgW1JGQzQ1NjZd ICwgYW5kPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsg W1hFUC0wMTc2XSwgd2hpY2ggZGVmaW5lcyB1c2FnZSB3aXRoIFhNUFAgW1JGQzYxMjBdLiBIb3dl dmVyLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IHNv bWUgb2YgdGhlIGV4YW1wbGVzIGluIHRoZSBkb2N1bWVudCB1c2VzIFNEUCBhbmQgdGhlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgT2ZmZXIvQW5zd2Vy IG1lY2hhbmlzbSBbUkZDNDU2Nl0gaW4gb3JkZXIgdG8gZXhwbGFpbiB0aGU8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyB1bmRlcmx5aW5nIGNvbmNlcHRz LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgTk9URTogSXQgaXMgd29ydGgg bm90aW5nIHRoYXQgdGhlcmUgaXMgcXVpdGUgYSBiaXQgb2Ygb3BlcmF0aW9uYWw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBleHBlcmllbmNlIHdpdGgg dGhlIHRlY2huaXF1ZSBiZWhpbmQgVHJpY2tsZSBJQ0UsIGdvaW5nIGJhY2sgYXMgZmFyIGFzIDIw MDU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAod2hl biB0aGUgWE1QUCBKaW5nbGUgZXh0ZW5zaW9uIGRlZmluZWQgYSAmcXVvdDtkcmliYmxlIG1vZGUm cXVvdDsgYXMgc3BlY2lmaWVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsmbmJzcDsgaW4gW1hFUC0wMTc2XSk7IHRoaXMgZG9jdW1lbnQgaW5jb3Jwb3JhdGVzIGZl ZWRiYWNrIGZyb20gdGhvc2Ugd2hvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsgaGF2ZSBpbXBsZW1lbnRlZCBhbmQgZGVwbG95ZWQgdGhlIHRlY2huaXF1 ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJl Z2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNocmlzdGVyPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tR0IiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5JY2UgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEg aHJlZj0ibWFpbHRvOkljZUBpZXRmLm9yZyI+SWNlQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWNlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZTwvYT48bzpwPjwv bzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B72E380FCESESSMB109erics_-- From nobody Wed Mar 28 11:38:09 2018 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 21E40127369 for ; Wed, 28 Mar 2018 11:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 zbqAl1xCJa1w for ; Wed, 28 Mar 2018 11:38:05 -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 092091275AB for ; Wed, 28 Mar 2018 11:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522262283; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fJblUEyHS1oMDPVX/cGSM4jGHVY/VXNNh0Af4BMvNwk=; b=Q4K5VAIfCEb/U+RPJ6z7ZaCefKcwaIvZh9NeFHOycy6w8k5f6MTchnHM6AWoA8DN fcUKp2BtT5k00JVAf2rV8xlOpBnJev48QIi+wZXVeMPW+IcT/dOmckDksJrPBASq U3PV/yAgJLKI21cZFiuJo5MoXCPKuPCsozyl/FAwCxc=; X-AuditID: c1b4fb25-d69a99c000004653-b7-5abbe10be649 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FE.62.18003.B01EBBA5; Wed, 28 Mar 2018 20:38:03 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 20:37:06 +0200 From: Christer Holmberg To: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] ICE trickle: Comment on section 8.1.1 Thread-Index: AdPDkuP38FvIt3+USwysDB0OImfNMwCVdT+AAAUSnMD///EdgIAA/DAAgABLdoCAAADWgP//zJvwgABZ4gD//9OOMA== Date: Wed, 28 Mar 2018 18:37:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E3814D@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> In-Reply-To: <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM2K7vS73w91RBl/WiVh8u1Br8WzlKUYH Jo8lS34yefQd6GINYIrisklJzcksSy3St0vgyjgxeSd7QYtExcZjU9gaGLeIdzFycEgImEgs 7JPqYuTiEBI4wiix+dxjZghnCaNE9+PpjCBFbAIWEt3/tLsYOTlEBLwkZu65zwRiCwOFv527 yA4Rt5RYuncFC4SdJfFy0R9WEJtFQFVi1rGZbCA2r4CvxJqrf9gg5veySEz4cZYRJMEpYC+x fMFGsGZGATGJ76fWgC1gFhCXuPVkPpgtISAgsWTPeWYIW1Ti5eN/rBC2ksTZL1PYQO5kFtCU WL9LH6JVUWJK90N2iL2CEidnPmGZwCgyC8nUWQgds5B0zELSsYCRZRWjaHFqcVJuupGxXmpR ZnJxcX6eXl5qySZGYCQc3PJbdQfj5TeOhxgFOBiVeHiDbu2OEmJNLCuuzD3EKMHBrCTC+14D KMSbklhZlVqUH19UmpNafIhRmoNFSZz3ofnmKCGB9MSS1OzU1ILUIpgsEwenVANjb/73Za3N DftnrrnDyH3hbVCJYKJ08xzjLysZTWZzmbxJmBjzxqAl+krsjsVBUWcDXhdXb/uSWdt6eR7f 0Vy/pHNzDs+x5rF8Ue6mW1Far/1a9uyCYHu7XYWb3c/Vlsw2mM0uby10puJfXs/iPYd6ElIi njCLZrYJq9/ruV2578nZ+yWsLTJKLMUZiYZazEXFiQCRupKXgAIAAA== Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 28 Mar 2018 18:38:07 -0000 SGksDQoNCj4+Pj4gSSB0aGluayB0aGUgcnVsZXMgY291bGQgYmUgc2ltcGxpZmllZCBpbiB0aGUg Zm9sbG93aW5nIHdheToNCj4+Pj4NCj4+Pj4gLSBJZiB0aGVyZSBhcmUgYXQgbGVhc3Qgb25lIHBh aXIgaW4gU3VjY2VlZGVkIHN0YXRlLCBzZXQgdGhlIHN0YXRlIA0KPj4+PiBvZiB0aGUgbmV3IHBh aXIgdG8gV2FpdGluZw0KPj4+DQo+Pj4gWWVzLCB0aGF0J3MgY29uc2lzdGVudCB3aXRoIMKnNy4y LjUuMy4zIG9mIDUyNDViaXMuDQo+PiANCj4+IENvcnJlY3QuDQo+PiANCj4+Pj4gLSBJZiB0aGVy ZSBhcmUgdHdvIG9yIG1vcmUgcGFpcnMgaW4gV2FpdGluZy9Jbi1Qcm9ncmVzcyBzdGF0ZSwgc2V0 IA0KPj4+PiB0aGUgc3RhdGUgb2YgdGhlIG5ldyBwYWlyIHRvIFdhaXRpbmcNCj4+Pg0KPj4+IFdo eSAidHdvIG9yIG1vcmUiPw0KPj4gDQo+ID4gSWYgdGhlcmUgaXMgb25seSBvbmUgKG9yIG5vKSBw YWlyIGluIFdhaXRpbmcgc3RhdGUsIHRoZSBjaGVjayBsaXN0IHNldCBoYXMganVzdCBiZWVuIGlu aXRpYWxpemVkLCB3aGljaCANCj4+IG1lYW5zIHRoZXJlIHNob3VsZCBiZSBubyBtb3JlIHRoYW4g b25lIHBhaXIgaW4gdGhlIHdhaXRpbmcgc3RhdGUuDQo+DQo+IElzIHRoYXQgdHJ1ZSBpbiB0aGUg Y29udGV4dCBvZiB0cmlja2xlPyBDb3VsZG4ndCBhIGNhbmRpZGF0ZSBwYWlyIHRyaWNrbGUgaW4g YWZ0ZXIgaW5pdGlhbGl6YXRpb24gb2YgdGhlIGNoZWNrIGxpc3Qgc2V0Pw0KDQpZZXMuIEJ1dCwg dGhlcmUgYXJlIHR3byBjYXNlczoNCg0KMS4gSWYgdGhlcmUgd2VyZSBwYWlycyBmb3IgdGhlIGZv dW5kYXRpb24gYXQgaW5pdGlhbGl6YXRpb24sIG9uZSBwYWlyICh0aGUgdG9wbW9zdCkgd2FzIHNl dCB0byB3YWl0aW5nLg0KMi4gVGhlIGxpc3Qgd2FzIGVtcHR5IGF0IGluaXRpYWxpemF0aW9uLiBJ biB0aGF0IGNhc2UgdGhlIGZpcnN0IHRyaWNrbGVkIHBhaXIgYXV0b21hdGljYWxseSBiZWNvbWVz IHRvcG1vc3QuDQoNCi4uLg0KDQo+Pj4gwqc2LjEuMi42IG9mIDUyNDViaXMgc3RhdGVzOg0KPj4+ DQo+Pj4gICA1LiAgRm9yIGVhY2ggZm91bmRhdGlvbiwgdGhlIGFnZW50IHNldHMgdGhlIHN0YXRl IG9mIGV4YWN0bHkgb25lDQo+Pj4gICAgICAgY2FuZGlkYXRlIHBhaXIgdG8gdGhlIFdhaXRpbmcg c3RhdGUgKHVuZnJlZXppbmcgaXQpLiAgVGhlDQo+Pj4gICAgICAgY2FuZGlkYXRlIHBhaXIgdG8g dW5mcmVlemUgaXMgY2hvc2VuIGJ5IGZpbmRpbmcgdGhlIGZpcnN0DQo+Pj4gICAgICAgY2FuZGlk YXRlIHBhaXIgKG9yZGVyZWQgYnkgbG93ZXN0IGNvbXBvbmVudCBJRCBhbmQgdGhlbiBoaWdoZXN0 DQo+Pj4gICAgICAgcHJpb3JpdHkgaWYgY29tcG9uZW50IElEcyBhcmUgZXF1YWwpIGluIHRoZSBm aXJzdCBjaGVjayBsaXN0DQo+Pj4gICAgICAgKGFjY29yZGluZyB0byB0aGUgdXNhZ2UtZGVmaW5l ZCBjaGVjayBsaXN0IHNldCBvcmRlcikgdGhhdCBoYXMNCj4+PiAgICAgICB0aGF0IGZvdW5kYXRp b24uDQo+Pj4NCj4+PiBNeSBpbmNsaW5hdGlvbiBpcyB0byBzZXQgdGhlIHN0YXRlIG9mIHRoaXMg IlgiIGNhbmRpZGF0ZSBwYWlyIHRvIA0KPj4+IFdhaXRpbmcsIGJlY2F1c2UgaXQgaXMgbm93IHRo ZSBjYW5kaWRhdGUgd2l0aCB0aGUgbG93ZXN0IGNvbXBvbmVudCBJRCANCj4+PiAoYW5kIGhpZ2hl c3QgcHJpb3JpdGl5IGlmIHRoZSBjb21wb25lbnQgSURzIGFyZSBlcXVhbCkgd2l0aGluIHRoaXMg DQo+Pj4gZm91bmRhdGlvbi4gSG93ZXZlciwgaWYgd2UgcHJvY2VlZGVkIGluIHRoaXMgd2F5IHRo ZW4gd2Ugd291bGQgaGF2ZSB0d28gDQo+Pj4gY2FuZGlkYXRlIHBhaXJzIGluIHRoZSBXYWl0aW5n IHN0YXRlIHdpdGhpbiB0aGlzIGZvdW5kYXRpb24uIFRoYXQgZG9lc24ndCBzZWVtIA0KPj4+IGxp a2UgYSBwcm9ibGVtLCBidXQgSSB3YW50ZWQgdG8gcG9pbnQgaXQgb3V0Lg0KPj4gDQo+PiBZZXMu DQo+PiANCj4+IEFub3RoZXIgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gc2V0IHRoZSBjdXJyZW50 IHBhaXIgaW4gV2FpdGluZyBzdGF0ZSB0byBGcm96ZW4sIHNpbmNlIFggaGFzIGhpZ2hlciBwcmlv cml0eS4NCj4NCj4gVGhhdCBzZWVtcyBwcmVmZXJhYmxlIHRvIG1lLg0KDQpXb3JrcyBmb3IgbWUg dG9vLiBUaGF0IHdheSwgd2hlbiB0aGVyZSBpcyBvbmx5IG9uZSBwYWlyIGluIHdhaXRpbmcgc3Rh dGUsIHdlIGtub3cgaXQgaXMgdGhlIHRvcG1vc3QgYXQgdGhhdCBnaXZlbiBtb21lbnQuDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K From nobody Wed Mar 28 12:56:05 2018 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 7D2B8126D05 for ; Wed, 28 Mar 2018 12:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ogn0KOuulXal for ; Wed, 28 Mar 2018 12:55:47 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F1B120227 for ; Wed, 28 Mar 2018 12:55:47 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id d5so4932562iob.9 for ; Wed, 28 Mar 2018 12:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=g3RSu92AZzWRB7h2DPEowR0ji/0EvoxogsB+AjhKFt8=; b=RNqoWmsYxZnvu5nqU/wZDN3H8iuTXw5kbkQKhKb2GLzlISlTGFp8JgtWnp4VXe2oGw zSMnv0SW0PtU/9vEmCcNjT69qZ34bNSTgRA03/qwCez4JBNNLoS9LuFeNCJ1qqgrNmq3 t3Jfx3rw2ckB0q+Y9QPeml369Ovlocda+Esr8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=g3RSu92AZzWRB7h2DPEowR0ji/0EvoxogsB+AjhKFt8=; b=Lg230f4HkKCtTu04A0ozWFuSCXMlabgMIv7neyKIW2+R78eA8fc1CW1/sTv1lOux01 bPxy1cFt8ubujIQBmOgDmcAt8Cma0sHNvtHy9hJrsnxCIuvVe63ABRb7jRBpjsu6hvk5 cPwaSuUplpakR7cJI4lfLPmkXeVwhkpgtDPRRk9eI7I9Ub8xibY5/4hZ8OXR6CmX7Yqx zz8XeW+rlO07Mq9o6Yz0a8RLfgwMRd3qr/ocjyobO/V3dibrU6qOEZoGkEsWlMJsdrBK RpN18KZ+YriSq3ursUbl/1sA2SR5o+ylH8gmYOfxW96XjcVKt3VU30N7wqzAu0V6SeLM /1sg== X-Gm-Message-State: AElRT7HmjSFmoM5yTGkBTB9vT2z9X34rYTR7w5fMkCygjqXpbpRlbi+1 AZxMIN6py7tAKyCNzZMuHmhjqg== X-Google-Smtp-Source: AG47ELtNfQJECAhjfoCsw6M9vufUPmZfpIhs2NxxqY8eXZexEc9AMO7tvVa5nAizxiAuW4UssaxgVw== X-Received: by 10.107.51.207 with SMTP id z198mr51838201ioz.112.1522266946681; Wed, 28 Mar 2018 12:55:46 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id f201-v6sm130425itc.12.2018.03.28.12.55.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 12:55:45 -0700 (PDT) To: Christer Holmberg , Taylor Brandstetter Cc: "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E380BF@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: <26eb8324-9fea-5f95-e84d-c922e691107e@mozilla.com> Date: Wed, 28 Mar 2018 13:55:44 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E380BF@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uTPxdODeqt0KPrKvZTzFHfRJcn9xmYIOT" Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 28 Mar 2018 19:55:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uTPxdODeqt0KPrKvZTzFHfRJcn9xmYIOT Content-Type: multipart/mixed; boundary="e9lrXZGj1hR1XwU9uxGMcRPBtFgHZrX4T"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , Taylor Brandstetter Cc: "ice@ietf.org" Message-ID: <26eb8324-9fea-5f95-e84d-c922e691107e@mozilla.com> Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E380BF@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E380BF@ESESSMB109.ericsson.se> --e9lrXZGj1hR1XwU9uxGMcRPBtFgHZrX4T Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/28/18 12:27 PM, Christer Holmberg wrote: > Hi Taylor, >=20 >> Something that's lost by the simplified set of rules is the guarantee = that the "topmost" pair is always unfrozen.=20 >> This ensures that the two ICE agents always have at least one common p= air unfrozen per foundation, even when pairs are formed in a different or= der. >=20 > If you go to the bottom of the conversation, I think it is covered ther= e :) >=20 > When a new pair is added, and if there is an existing pair in Waiting s= tate, if the new pair has higher priority (i.e., it is "more topmost" tha= n the current pair in Waiting state), the new pair is set to Waiting, and= the current topmost is changed from Waiting to Frown. Yeah, I'm in a Frown state too, right now. ;-) This gets messy to specify because handling of the topmost pair is a proviso to another rule. I might suggest the following: 1. If the newly formed pair has the lowest component ID of any candidate pair for this foundation, set its state to Waiting. 2. If there is at least one pair in the Succeeded state for this foundation, set the state of the newly formed pair to Waiting. 3. If there are two or more pairs in the Waiting or In-Progress state for this foundation, set the state of the newly formed pair to Waiting. [Question: when would #3 arise? Given 5245bis rules, it seems like we would not have 2+ pairs in the Waiting or In-Progress state...] 4. Otherwise, set the state of the newly formed pair to Frozen. Peter --e9lrXZGj1hR1XwU9uxGMcRPBtFgHZrX4T-- --uTPxdODeqt0KPrKvZTzFHfRJcn9xmYIOT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq780AACgkQZWGMGH9o FKlnCQ/9EF0YHigluCLSqbmgCPRFIxpeHSTe8z8JFpT/BwnmvQqgBV6Q30HiHz3D eapaT0O85Cd/1X3rL+w8gxLSTYDmMiBa7XOpma53m0MOYwv4xCAZSHyy18ZuWYki 4ViS7dhxYEwejkFv+ayIy64TudvHU6riVU+7GRj93Mfv3GXHMRwCcGYXLfcLPuPA xKDGmKyaz0OEHAHyOaKvEk54psrZJvHKzwULIw7dKG7eOg2lVh82tAThRQmwcD8j TFyvi+cSzvOH/RDTvtwQOiqeoS61Aw1Z4uAkXAH1vLqNJkynyxqapLSoEVsHb5+T ssI8N5X9OzKwiRSYXe9Tq6Zr1gz8fzJ1DTXyE7CqqKCABwYr0pwmkZQR9XvQqLV7 ddDXQm9qsIMx9am3X7M8w0GW735bRiDTO1ld4XAfam34DRWV3afvDEfcsT8HsQHm LXD7phXvV3Z4nOz2ugHXRAQ28cc3uyzgcYkaZH6oLNZzNC9GYmTQh/QB3ZYpKOa+ Sj8ThRrsKvaiqK0PNQRv6O1tOi5C1PXg9dqzm6hqJS6vcCQ439AjyMzg/SWzjD7A /S6CQ0ZekW8EliTZwUVlsyGjtynS+htPEmHA6fGxnVlvGz0mU+MKBe4Ef5F4VPbD 8Rp5m5EaP1LVNOoyq0L9tW7e+NCcZp7IG95fHe7RllA6UTjlPhg= =lE3+ -----END PGP SIGNATURE----- --uTPxdODeqt0KPrKvZTzFHfRJcn9xmYIOT-- From nobody Wed Mar 28 13:01:43 2018 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 443FD126DC2 for ; Wed, 28 Mar 2018 13:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 x5lKBvA7m6qj for ; Wed, 28 Mar 2018 13:01:39 -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 8FA40120227 for ; Wed, 28 Mar 2018 13:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522267297; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6y4ujFwp0r1IFT7zDV2N7ETj/1flaNJDfLKaLQqaI5o=; b=JvBdhFPDmbQG3rlHQZRIavlbsco2N7zetp/hvCGKka7C9/W5qntIyPvnBhhRCYT6 yTiLFxl1ukmTLP01zP6cUu+R9gafEyrKkj6faoykfqbIO4Aw/04ibyrXNBBSxwMB EwizAdDqJ0GLF5ujcWFRSyVAm41331GY9xTKWQsKzxg=; X-AuditID: c1b4fb2d-313ff7000000236d-49-5abbf4a1cf20 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 50.2E.09069.1A4FBBA5; Wed, 28 Mar 2018 22:01:37 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 22:01:37 +0200 From: Christer Holmberg To: Peter Saint-Andre , Taylor Brandstetter CC: "ice@ietf.org" Thread-Topic: [Ice] ICE trickle: Comment on section 8.1.1 Thread-Index: AdPDkuP38FvIt3+USwysDB0OImfNMwCVdT+AAAUSnMD///EdgIAA/DAAgABLdoCAAADWgP//zJvwgABZ4gCAAAMXAP//2T4QgABFigD//929wA== Date: Wed, 28 Mar 2018 20:01:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E3823D@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E380BF@ESESSMB109.ericsson.se> <26eb8324-9fea-5f95-e84d-c922e691107e@mozilla.com> In-Reply-To: <26eb8324-9fea-5f95-e84d-c922e691107e@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbFdQnfhl91RBgfuWlpcXvGQ1eLbhVqL ZytPMToweyzYVOqxZMlPJo++A12sAcxRXDYpqTmZZalF+nYJXBnXfzewFlzhrNi95C5LA+MW zi5GTg4JAROJOSdmsHQxcnEICRxhlDiyspkVwlnCKHG4owPI4eBgE7CQ6P6nDdIgIhAhcfHF WWaQMLOAosTLvWogYWGgim/nLrJDlFhKLN27ggXCrpO41LgYLM4ioCox4ctUVhCbV8BX4uqf C4wgtpDAWVaJv4eyQGxOAXuJnp3r2UBsRgExie+n1jCB2MwC4hK3nsxngrhZQGLJnvPMELao xMvH/1ghbCWJs1+msEGcpimxfpc+RKuixJTuh+wQawUlTs58wjKBUXQWkqmzEDpmIemYhaRj ASPLKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAiDm45bfuDsbVrx0PMQpwMCrx8Erd2h0l xJpYVlyZe4hRgoNZSYT3vQZQiDclsbIqtSg/vqg0J7X4EKM0B4uSOO9JT94oIYH0xJLU7NTU gtQimCwTB6dUA+NUz7oyey9Bu3PtV4tvioX/+aNo/mynQ9qsO2qfG4SUmR8qNYVUCnGa7v84 88xi28VMt11dHlZYKxnFvud4oH6h7kg6a92Onjcih7+FPOxZxtXNKbm8Jf/jwqIjPQ82fzO1 ucUY4Vve+nD+0xYGZ+VfdUbNJ5/dC/L+7uKQUqX9Z82OmjNS55VYijMSDbWYi4oTAbdyzh+U AgAA Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 28 Mar 2018 20:01:41 -0000 SGksDQoNCj4gSSBtaWdodCBzdWdnZXN0IHRoZSBmb2xsb3dpbmc6DQo+DQo+IDEuIElmIHRoZSBu ZXdseSBmb3JtZWQgcGFpciBoYXMgdGhlIGxvd2VzdCBjb21wb25lbnQgSUQgb2YgYW55IGNhbmRp ZGF0ZSBwYWlyIGZvciB0aGlzIGZvdW5kYXRpb24sIHNldCBpdHMgc3RhdGUgdG8gV2FpdGluZy4N Cg0KTG93ZXN0IGNvbXBvbmVudCBBTkQgdG9wLW1vc3QsIGFzIG1hbnkgcGFpcnMgd2lsbCBoYXZl IHRoZSBzYW1lIGNvbXBvbmVudCBJRC4NCiANCj4gMi4gSWYgdGhlcmUgaXMgYXQgbGVhc3Qgb25l IHBhaXIgaW4gdGhlIFN1Y2NlZWRlZCBzdGF0ZSBmb3IgdGhpcyBmb3VuZGF0aW9uLCBzZXQgdGhl IHN0YXRlIG9mIHRoZSBuZXdseSBmb3JtZWQgcGFpciB0byBXYWl0aW5nLg0KDQpZZXMuDQoNCj4g My4gSWYgdGhlcmUgYXJlIHR3byBvciBtb3JlIHBhaXJzIGluIHRoZSBXYWl0aW5nIG9yIEluLVBy b2dyZXNzIHN0YXRlIGZvciB0aGlzIGZvdW5kYXRpb24sIHNldCB0aGUgc3RhdGUgb2YgdGhlIG5l d2x5IGZvcm1lZCBwYWlyIHRvIFdhaXRpbmcuDQoNClllcy4NCg0KPiBbUXVlc3Rpb246IHdoZW4g d291bGQgIzMgYXJpc2U/IEdpdmVuIDUyNDViaXMgcnVsZXMsIGl0IHNlZW1zIGxpa2Ugd2Ugd291 bGQgbm90IGhhdmUgMisgcGFpcnMgaW4gdGhlIFdhaXRpbmcgb3IgSW4tUHJvZ3Jlc3Mgc3RhdGUu Li5dDQoNCkl0IGhhcHBlbnMgd2hlbiBhIHBhaXIgaGFzIHN1Y2NlZWRlZC4gQWZ0ZXIgdGhhdCBh bGwgdGhlIHBhaXJzIGZvciB0aGUgc2FtZSBmb3VuZGF0aW9uIGFyZSBzZXQgdG8gV2FpdGluZy4N Cg0KPiA0LiBPdGhlcndpc2UsIHNldCB0aGUgc3RhdGUgb2YgdGhlIG5ld2x5IGZvcm1lZCBwYWly IHRvIEZyb3plbi4NCg0KWWVzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Wed Mar 28 13:07:28 2018 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 589E9126DC2 for ; Wed, 28 Mar 2018 13:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 a3GBoq-0QaMS for ; Wed, 28 Mar 2018 13:07:25 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 7A0B4120227 for ; Wed, 28 Mar 2018 13:07:25 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id k135-v6so5351256ite.2 for ; Wed, 28 Mar 2018 13:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=15TeqO0SGuczQTlYyWa4pFfyQj1qYkjxRsP+ENkwegY=; b=Vip8pw83N7M2llIkXLVveMiXW2V0/XGtosQVXIzlySw5TZthOzyoobiPoJnqjd73oZ C8TRf0ESUNDf8k88q2IwAUabD7q6tB7XRywtDtJ7CIrZEdfJkcql39cXdxuIzQHNQ5+B ir7ZkXOEGRm5ovhPqyOTnFK3wHMyCy1/RZiWI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=15TeqO0SGuczQTlYyWa4pFfyQj1qYkjxRsP+ENkwegY=; b=Z871RWDd6+OVvKZf76eCkUpyWp/kmGBHMVLgRDw+JAsyUPJGGyjxmeE/lAOOJaDYpX nSAKLdKL35HywWgEA3KwEhXOZtSIlVKgiEJyWiMJIeagg6zyIPloC5/4THqdjIf6HOzQ 6m9gdNIAgrc2vUWTq/gbEhkcaNF8qsSq23KKhskzLn/t/vmcW3RczHEh1s3oaRL07/c8 AmTaRoeYpPk10MOrkXEwVSHY4D6SMIUh/N2Hd1e0lqMGW+ZaI8MCVSu93lH95vJLaSof qw/i0gakdlUfobfqvPaBILyYvOqmF5jBvIze47FrcNgTjU0a7gQqZCSZ1caGzuORRtkX 0+wQ== X-Gm-Message-State: AElRT7Fj0Rb26j0Ec0M7emGGmRWN8P1clOB7skTHCpaT0+h9sxvYYbL2 MnYSG3dgfCdR89+xPJdY+vijoA== X-Google-Smtp-Source: AIpwx48ona6e00p9YcQrIDHPeCAyTVm7GF3JivkHhBzJLYvJQwxKet9XtS8CxBBMTmqwRaKIOYg2JQ== X-Received: by 2002:a24:5143:: with SMTP id s64-v6mr5158497ita.116.1522267644820; Wed, 28 Mar 2018 13:07:24 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id y185-v6sm135809itd.11.2018.03.28.13.07.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 13:07:23 -0700 (PDT) To: Christer Holmberg , Taylor Brandstetter Cc: "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E380BF@ESESSMB109.ericsson.se> <26eb8324-9fea-5f95-e84d-c922e691107e@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E3823D@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: <852b5897-c716-b294-8ed2-bc710ce49db1@mozilla.com> Date: Wed, 28 Mar 2018 14:07:22 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E3823D@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FTAAETdEpHfuAONasloY0A4sH7MqiWsuk" Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 28 Mar 2018 20:07:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FTAAETdEpHfuAONasloY0A4sH7MqiWsuk Content-Type: multipart/mixed; boundary="79JONgZ9g0lw3C0DpXA0xOwqBMqQOcjjw"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , Taylor Brandstetter Cc: "ice@ietf.org" Message-ID: <852b5897-c716-b294-8ed2-bc710ce49db1@mozilla.com> Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E380BF@ESESSMB109.ericsson.se> <26eb8324-9fea-5f95-e84d-c922e691107e@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E3823D@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E3823D@ESESSMB109.ericsson.se> --79JONgZ9g0lw3C0DpXA0xOwqBMqQOcjjw Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/28/18 2:01 PM, Christer Holmberg wrote: > Hi, >=20 >> I might suggest the following: >> >> 1. If the newly formed pair has the lowest component ID of any candida= te pair for this foundation, set its state to Waiting. >=20 > Lowest component AND top-most, as many pairs will have the same compone= nt ID. Yes, I keep trying to get away from "topmost" because that's just a way of describing things in terms of these mythical grids. But "pair with the lowest component ID and, if there are candidates with the same component ID value, also the highest priority" is long-winded. >> 2. If there is at least one pair in the Succeeded state for this found= ation, set the state of the newly formed pair to Waiting. >=20 > Yes. >=20 >> 3. If there are two or more pairs in the Waiting or In-Progress state = for this foundation, set the state of the newly formed pair to Waiting. >=20 > Yes. >=20 >> [Question: when would #3 arise? Given 5245bis rules, it seems like we = would not have 2+ pairs in the Waiting or In-Progress state...] >=20 > It happens when a pair has succeeded. After that all the pairs for the = same foundation are set to Waiting. But then isn't that covered by Rule #2? Peter --79JONgZ9g0lw3C0DpXA0xOwqBMqQOcjjw-- --FTAAETdEpHfuAONasloY0A4sH7MqiWsuk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq79foACgkQZWGMGH9o FKmedg/9GOq4TX01KphMAjOYwCMyRCshk+31nFP93IVWITZXf19hTeJF6nwfIA1a SXZPWhp/Pf2jCl2SQ4oqF2GZ7cErmUxTSj2QWn2btqQ7WN+KIp/+f5fVCdYDQCRU v580dhLWPf3NY0T7p8KjbAmDZcPzp8W+h3D90QjlMzTtg23kv2aDTxrhUX6xP+m3 8aXoBdWsPGV4gEWqnhm7uGU4g0WvHfrsEIoAZYqw4I+Z22Hy3zFt+bf1YyHvJAVr nLjiLYnADWuiS8i48vupIlxK95EQExgAlxkGWZawd0uS1YF/uUdgRU1xUSmTVR7y Ma+6QUmWbdWTSPG/il9WYtL5upujqMAMLceK/3uprkx8+VBHcwuQYeumnRX/ZtcC tASnhJkBuq6cJ1+uWQ+tYXPR0WTHETeRw/TUnyrF338YSJRGT68M+reyNJEzRpy8 zf1o254RCBOFhhqllDWQylXotMxs7Jh488cRmwsSwodS127QMEdJyIJhKSK6GT2x XIOiFMgHNeS2Ufjryszs8jrmqtcF8Lt6W/o2oMC9BoypjFZRlDyLXvq+OUHUgSbA KchF4g356xII83aXzV6zewBDLXxdHFnbRwizdf5oKXjm9mIeSETvySAr7ASE9KDx OoNtWHAI341Mor/tZeXuTNn5eROOZ81WwZnueeeliUV7Y+LA9OA= =dDLc -----END PGP SIGNATURE----- --FTAAETdEpHfuAONasloY0A4sH7MqiWsuk-- From nobody Wed Mar 28 13:17:13 2018 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 75BEC120227 for ; Wed, 28 Mar 2018 13:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ebNwW3O2_Oet for ; Wed, 28 Mar 2018 13:17:09 -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 5D7DD1200F1 for ; Wed, 28 Mar 2018 13:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522268227; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0SxuAZXl1x7qpWKjIOPX9r9EnK7TCLcIXyZlSl4SSpQ=; b=TUfO5OluHJdcqaeaB6erH+XC74fuzf+D8S/eECnNL9mcOW5PDt+od4e29R9D1lus v6/wi2qTuNfG1gKsxWmUDGLHb4EpYRT5HTiiOuLI7nOlgnOsJ7uuPGWqUiSgfmuM jxYyGw2ZYyCER4MsGNhBc1texGshhtHVM02C5EvtDU8=; X-AuditID: c1b4fb3a-e39ff70000005d56-97-5abbf84384c1 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 25.8D.23894.348FBBA5; Wed, 28 Mar 2018 22:17:07 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 22:17:07 +0200 From: Christer Holmberg To: Peter Saint-Andre , Taylor Brandstetter CC: "ice@ietf.org" Thread-Topic: [Ice] ICE trickle: Comment on section 8.1.1 Thread-Index: AdPDkuP38FvIt3+USwysDB0OImfNMwCVdT+AAAUSnMD///EdgIAA/DAAgABLdoCAAADWgP//zJvwgABZ4gCAAAMXAP//2T4QgABFigD//929wAAEsHcA///dhfA= Date: Wed, 28 Mar 2018 20:17:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E382BF@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E380BF@ESESSMB109.ericsson.se> <26eb8324-9fea-5f95-e84d-c922e691107e@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E3823D@ESESSMB109.ericsson.se> <852b5897-c716-b294-8ed2-bc710ce49db1@mozilla.com> In-Reply-To: <852b5897-c716-b294-8ed2-bc710ce49db1@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbFdRdf5x+4ogw0HNC0ur3jIavHtQq3F s5WnGB2YPRZsKvVYsuQnk0ffgS7WAOYoLpuU1JzMstQifbsEroxHc58xF8wQqWhpYW1gvCLc xcjBISFgInGgWb2LkYtDSOAIo8STm21sEM4SRonmGaeZQYrYBCwkuv9pdzFycogIREhcfHEW LMwsoCjxcq8aSFgYqOLbuYvsECWWEkv3rmABGSMi0MUosWP7InaQehYBVYlZy+xAangFfCUm TjjNCrHqGJvE71d9TCAJTgF7iUtff4MNYhQQk/h+ag1YnFlAXOLWk/lgtoSAgMSSPeeZIWxR iZeP/7FC2EoSZ79MYYO4TVNi/S59iFZFiSndD9kh9gpKnJz5hGUCo+gsJFNnIXTMQtIxC0nH AkaWVYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiB8XJwy2+rHYwHnzseYhTgYFTi4c35tjtK iDWxrLgy9xCjBAezkgjvew2gEG9KYmVValF+fFFpTmrxIUZpDhYlcV6nNIsoIYH0xJLU7NTU gtQimCwTB6dUA+Myk90bFq4qV57yhG+uxr2pf7+9KWHQnb7v4E+X1MbSjOMJRhs6L1VmTTrP 1lVasl8RGOr6M/+qfr1+o8+18azqEt5wpnNh03dyfbi52d/g99qNmo8stK+e7kw+vdl8nVNk 6Ra2Gyd3ZC3tl/gxNezZKrWWs3JbDdumBKz24JGLkeOdzcq9664SS3FGoqEWc1FxIgB51hHK kwIAAA== Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 28 Mar 2018 20:17:11 -0000 SGksDQoNCj4+PiBJIG1pZ2h0IHN1Z2dlc3QgdGhlIGZvbGxvd2luZzoNCj4+Pg0KPj4+IDEuIElm IHRoZSBuZXdseSBmb3JtZWQgcGFpciBoYXMgdGhlIGxvd2VzdCBjb21wb25lbnQgSUQgb2YgYW55 IGNhbmRpZGF0ZSBwYWlyIGZvciB0aGlzIGZvdW5kYXRpb24sIHNldCBpdHMgc3RhdGUgdG8gV2Fp dGluZy4NCj4+IA0KPj4gTG93ZXN0IGNvbXBvbmVudCBBTkQgdG9wLW1vc3QsIGFzIG1hbnkgcGFp cnMgd2lsbCBoYXZlIHRoZSBzYW1lIGNvbXBvbmVudCBJRC4NCj4NCj4gWWVzLCBJIGtlZXAgdHJ5 aW5nIHRvIGdldCBhd2F5IGZyb20gInRvcG1vc3QiIGJlY2F1c2UgdGhhdCdzIGp1c3QgYSB3YXkg b2YgZGVzY3JpYmluZyB0aGluZ3MgaW4gdGVybXMgb2YgDQo+IHRoZXNlIG15dGhpY2FsIGdyaWRz LiBCdXQgInBhaXIgd2l0aCB0aGUgbG93ZXN0IGNvbXBvbmVudCBJRCBhbmQsIGlmIHRoZXJlIGFy ZSBjYW5kaWRhdGVzIHdpdGggdGhlIHNhbWUgY29tcG9uZW50IElEIA0KPiB2YWx1ZSwgYWxzbyB0 aGUgaGlnaGVzdCBwcmlvcml0eSIgaXMgbG9uZy13aW5kZWQuDQoNCjUyNDViaXMgdXNlcyB0aGUg Zm9sbG93aW5nIGxhbmd1YWdlIGZvciBkZXNjcmliaW5nIHdoaWNoIHBhaXIgaXMgc2V0IHRvIFdh aXRpbmcgZHVyaW5nIGluaXRpYWxpemF0aW9uOg0KDQogICAgICAgIlRoZSBjYW5kaWRhdGUgcGFp ciB0byB1bmZyZWV6ZSBpcyBjaG9zZW4gYnkgZmluZGluZyB0aGUgZmlyc3QNCiAgICAgICBjYW5k aWRhdGUgcGFpciAob3JkZXJlZCBieSBsb3dlc3QgY29tcG9uZW50IElEIGFuZCB0aGVuIGhpZ2hl c3QNCiAgICAgICBwcmlvcml0eSBpZiBjb21wb25lbnQgSURzIGFyZSBlcXVhbCkgaW4gdGhlIGZp cnN0IGNoZWNrIGxpc3QNCiAgICAgICAoYWNjb3JkaW5nIHRvIHRoZSB1c2FnZS1kZWZpbmVkIGNo ZWNrIGxpc3Qgc2V0IG9yZGVyKSB0aGF0IGhhcw0KICAgICAgIHRoYXQgZm91bmRhdGlvbi4iDQoN CkkgdGhpbmsgd2Ugc2hhbGwgdXNlIHRoZSBzYW1lIHRlcm1pbm9sb2d5Lg0KDQpQYWlycyBpbiBk aWZmZXJlbnQgY2hlY2sgbGlzdHMsIGZvciB0aGUgc2FtZSBmb3VuZGF0aW9uLCBtYXkgaGF2ZSB0 aGUgc2FtZSBjb21wb25lbnQgSUQgYW5kIHByaW9yaXR5LCBhbmQgdGhlcmVmb3JlIHlvdSBuZWVk IHRvIGFsc28gbG9vayBhdCB0aGUgb3JkZXIgb2YgdGhlIGNoZWNrIGxpc3QgaW4gd2hpY2ggdGhl eSBvY2N1ci4NCg0KDQo+Pj4gMi4gSWYgdGhlcmUgaXMgYXQgbGVhc3Qgb25lIHBhaXIgaW4gdGhl IFN1Y2NlZWRlZCBzdGF0ZSBmb3IgdGhpcyBmb3VuZGF0aW9uLCBzZXQgdGhlIHN0YXRlIG9mIHRo ZSBuZXdseSBmb3JtZWQgcGFpciB0byBXYWl0aW5nLg0KPj4gDQo+PiBZZXMuDQo+PiANCj4+PiAz LiBJZiB0aGVyZSBhcmUgdHdvIG9yIG1vcmUgcGFpcnMgaW4gdGhlIFdhaXRpbmcgb3IgSW4tUHJv Z3Jlc3Mgc3RhdGUgZm9yIHRoaXMgZm91bmRhdGlvbiwgc2V0IHRoZSBzdGF0ZSBvZiB0aGUgbmV3 bHkgZm9ybWVkIHBhaXIgdG8gV2FpdGluZy4NCj4+IA0KPj4gWWVzLg0KPj4gDQo+Pj4gW1F1ZXN0 aW9uOiB3aGVuIHdvdWxkICMzIGFyaXNlPyBHaXZlbiA1MjQ1YmlzIHJ1bGVzLCBpdCBzZWVtcyBs aWtlIHdlIA0KPj4+IHdvdWxkIG5vdCBoYXZlIDIrIHBhaXJzIGluIHRoZSBXYWl0aW5nIG9yIElu LVByb2dyZXNzIHN0YXRlLi4uXQ0KPj4gDQo+PiBJdCBoYXBwZW5zIHdoZW4gYSBwYWlyIGhhcyBz dWNjZWVkZWQuIEFmdGVyIHRoYXQgYWxsIHRoZSBwYWlycyBmb3IgdGhlIHNhbWUgZm91bmRhdGlv biBhcmUgc2V0IHRvIFdhaXRpbmcuDQo+DQo+IEJ1dCB0aGVuIGlzbid0IHRoYXQgY292ZXJlZCBi eSBSdWxlICMyPw0KDQpDb3JyZWN0LiBZb3UgYXJlIHJpZ2h0Lg0KDQpSZWdhcmRzLA0KDQpDaHJp c3Rlcg0K From nobody Wed Mar 28 13:36:00 2018 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 DE84A126DC2 for ; Wed, 28 Mar 2018 13:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 5QxDGCLWl43k for ; Wed, 28 Mar 2018 13:35:56 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 83FC31200F1 for ; Wed, 28 Mar 2018 13:35:50 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id j137-v6so5461909ita.1 for ; Wed, 28 Mar 2018 13:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=MY4XmDGw7U8I/KfDGvj7zCVeCMe02Rlvzrl3dcWeQVA=; b=UblB6tXK2fTkVYhH1FenLc/kuDsFyVgiI0wUqPpDrD0kYwhThCeCCteh1HVM63Zvz/ qUlnzMAA+BqThcUAcMYniwvDQdoNqdUvI4qpbRGafCi/NPWoPObb8kQLAMe0Wy1ULJxq JbEuw3wJisEl8aKa9giHZdcQL0ZhJK+7lu2Y0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=MY4XmDGw7U8I/KfDGvj7zCVeCMe02Rlvzrl3dcWeQVA=; b=P8pq4xgGGLjn7dSazmLfgNUIydOtDdtOfeqpTksltZ377HA2DH7DcWBo915bUEYfuK cOwXGxfVR8ihOZs75y0HVoIZOO3DHsVjqFz0YI+hyD2nBP2ILw+iQMqb1NTCwDcM1j0R MAz68PgjplbOb3b/iZchWapbwfv7aBFkl8YRRCYvsZtdrwfadxCkBGFqPdZ+JWCOdYkZ q7GDqzT2o7n5tJpuD4pi+6VbjoHBd2Il5zyRJ/W4UGJpFnerHPCO+09tQ2Qj2MI3GG5W ZfMZGRJ5A/J0XvFaoaw3+YDII0DMkWHM0mVq7m6kmlmc24SUa7vStiJH7ukmGApx+U3T qc+g== X-Gm-Message-State: AElRT7F1R7quuAxJVvK/VhGnYPvIw6ZFkMLPPxO7bkP75bk8/jTkUhQN 8QWaI8qLcLLshrfYpjl+bmv5lA== X-Google-Smtp-Source: AIpwx4/QtJAd6UnsxOEsxh2vDz/84T7WtxxBl6HD25CvumdsEaxTNdiEz1PtZdHg3Jhh5w3WaZLMJw== X-Received: by 2002:a24:40d4:: with SMTP id n203-v6mr4368181ita.142.1522269349852; Wed, 28 Mar 2018 13:35:49 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id o7sm2865273iob.63.2018.03.28.13.35.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 13:35:49 -0700 (PDT) To: Christer Holmberg , Taylor Brandstetter Cc: "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E380BF@ESESSMB109.ericsson.se> <26eb8324-9fea-5f95-e84d-c922e691107e@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E3823D@ESESSMB109.ericsson.se> <852b5897-c716-b294-8ed2-bc710ce49db1@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E382BF@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: <326106b5-254d-15bf-17c0-5dd1b08e41a3@mozilla.com> Date: Wed, 28 Mar 2018 14:35:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E382BF@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tNCnyHI5dngDS7VbfobMkZF3xr1bGewNU" Archived-At: Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 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, 28 Mar 2018 20:35:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tNCnyHI5dngDS7VbfobMkZF3xr1bGewNU Content-Type: multipart/mixed; boundary="q3e3hvvstkqJeIEcCaTqUafxO23di8mBh"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , Taylor Brandstetter Cc: "ice@ietf.org" Message-ID: <326106b5-254d-15bf-17c0-5dd1b08e41a3@mozilla.com> Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1 References: <7594FB04B1934943A5C02806D1A2204B72E178A7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E3352E@ESESSMB109.ericsson.se> <4be30d69-bc9b-cfd3-89d1-1fc10e6b1061@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E37E0E@ESESSMB109.ericsson.se> <67d8ea21-7e1c-9d7c-facc-53927f2ad48a@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E380BF@ESESSMB109.ericsson.se> <26eb8324-9fea-5f95-e84d-c922e691107e@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E3823D@ESESSMB109.ericsson.se> <852b5897-c716-b294-8ed2-bc710ce49db1@mozilla.com> <7594FB04B1934943A5C02806D1A2204B72E382BF@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E382BF@ESESSMB109.ericsson.se> --q3e3hvvstkqJeIEcCaTqUafxO23di8mBh Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/28/18 2:17 PM, Christer Holmberg wrote: > Hi, >=20 >>>> I might suggest the following: >>>> >>>> 1. If the newly formed pair has the lowest component ID of any candi= date pair for this foundation, set its state to Waiting. >>> >>> Lowest component AND top-most, as many pairs will have the same compo= nent ID. >> >> Yes, I keep trying to get away from "topmost" because that's just a wa= y of describing things in terms of=20 >> these mythical grids. But "pair with the lowest component ID and, if t= here are candidates with the same component ID=20 >> value, also the highest priority" is long-winded. >=20 > 5245bis uses the following language for describing which pair is set to= Waiting during initialization: >=20 > "The candidate pair to unfreeze is chosen by finding the first > candidate pair (ordered by lowest component ID and then highest > priority if component IDs are equal) in the first check list > (according to the usage-defined check list set order) that has > that foundation." >=20 > I think we shall use the same terminology.> > Pairs in different check lists, for the same foundation, may have the s= ame component ID and priority, and therefore you need to also look at the= order of the check list in which they occur. Exactly. I'll reuse the 5245bis text with appropriate modifications for trickle scenarios. >>>> 2. If there is at least one pair in the Succeeded state for this fou= ndation, set the state of the newly formed pair to Waiting. >>> >>> Yes. >>> >>>> 3. If there are two or more pairs in the Waiting or In-Progress stat= e for this foundation, set the state of the newly formed pair to Waiting.= >>> >>> Yes. >>> >>>> [Question: when would #3 arise? Given 5245bis rules, it seems like w= e=20 >>>> would not have 2+ pairs in the Waiting or In-Progress state...] >>> >>> It happens when a pair has succeeded. After that all the pairs for th= e same foundation are set to Waiting. >> >> But then isn't that covered by Rule #2? >=20 > Correct. You are right. Simpler is better. :-) I now have what I need to publish -18, which I will do later today. Peter --q3e3hvvstkqJeIEcCaTqUafxO23di8mBh-- --tNCnyHI5dngDS7VbfobMkZF3xr1bGewNU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq7/KMACgkQZWGMGH9o FKnaYg/8D8EtX1Un8xlklvie7bGioxuqolcDRlYeTPj9Qqb7X9PZRpG9ZFJSyYW1 vvw6rmNaetDUnP4F2SbPuxzD/avtAQKVUI3bcONOA5rXiKqgIr3/F3lnLeWRfAjx yv0CKTB6Nhv2GsNMGLi0/0OjUbUdiwKs+2FB7t0OS+Zp9Pqn4C+w1otlA7R7G8lB UKHEF4LgxMP/8rrg+QZUohbEp2C2J1T+0r3faaja36n/m9n2Ky+ryxaa76dX4sW9 0k9tBCpy+0lJ55eq8B/F9DvGoggrUeTm0QMEWuBLQZHFTBA6ROYGfHN1CEoQW9/c VP1udUorJQlCW1iitPf1WXLnJKX1WI+b0HfyCuUjie1igcF/O78y8U/Qszz8ss8b wiJiwG5K6lWzMU/yFUk94ZViD+CiUISh01mrDQLdU8KbhMlTJMbASkERhcy1ljgZ nj/Oirdkm5wLLaYWrIQjNi3XClba9oa5uJ4uahJNPiPKloZWLKRcIYa2wuxD1MPU UgLUbhtdg2vi6kzSxSRpl9vqF2Lv0KzHsme9LkX/gd8cAhmQEHR1L4Xa0OfgK+dX QIxcTPC0StSwP7ixV3/6eobxY79DUMRg7flbEtfPmk7IM73hp7k655WRJjPpbxHK Tb3puHezt4rIbdkXxIVZrlNGmB4xk831IvXPZVF5p8VoDPl4Q5g= =d7LP -----END PGP SIGNATURE----- --tNCnyHI5dngDS7VbfobMkZF3xr1bGewNU-- From nobody Wed Mar 28 15:31:20 2018 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 C50A4126CC7 for ; Wed, 28 Mar 2018 15:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 uLFJfMAi0URk for ; Wed, 28 Mar 2018 15:31:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA64124234 for ; Wed, 28 Mar 2018 15:31:16 -0700 (PDT) Received: from [10.50.10.6] (ip-17-232-239-173.texas.us.northamericancoax.com [173.239.232.17]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w2SMVBH5024353 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 28 Mar 2018 17:31:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host ip-17-232-239-173.texas.us.northamericancoax.com [173.239.232.17] claimed to be [10.50.10.6] From: Ben Campbell Message-Id: <83C077AF-139B-41D2-94AB-0CF89C515382@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_43E2414F-BA55-4F18-88DE-5572A21F8554"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 28 Mar 2018 17:31:10 -0500 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E380FC@ESESSMB109.ericsson.se> Cc: Adam Roach , "ice@ietf.org" To: Christer Holmberg , Peter Saint-Andre References: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> <321c0d02-8e3b-1c6a-769a-ada15a5d5d6e@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E380FC@ESESSMB109.ericsson.se> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] Tricke ICE: Suggested clarifications to Introduction 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, 28 Mar 2018 22:31:19 -0000 --Apple-Mail=_43E2414F-BA55-4F18-88DE-5572A21F8554 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Christer and Peter: I prefer to have post-IETF LC drafts materially =E2=80=9Cdone=E2=80=9D = at least 7 days prior to the telechat. That=E2=80=99s nominally 0900 = Thursday us/central, although I=E2=80=99ve generally treated that as = =E2=80=9Csometime before my close of business on Thursday without too = much pushback.) But I take this discussion to mean that these probably = by then? If that=E2=80=99s the case, I will defer both of the trickle = drafts to the next telechat that has space. Thanks, Ben. > On Mar 28, 2018, at 1:29 PM, Christer Holmberg = wrote: >=20 > Hi Adam, >=20 > >As a reminder -- this document is on the IESG formal telechat for a = week from tomorrow. >Speaking only for myself, I find it unnecessarily = disruptive when documents change out >from under me during the week = leading up to the telechat. If you're going to make >*editorial* = changes[1], please make them today or not at all. >=20 > Unfortunately it was noted that the draft contains text that is based = on old 5245bis procedures. So, while changes are editorial, there are = also technical changes. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > On 3/24/18 4:53 PM, Christer Holmberg wrote: > Hi, >=20 > Below is a suggestion on how to modify the Introduction section of = draft-trickle-ice, in order to make it more clear (in my opinion). >=20 > --- >=20 > 1. Introduction >=20 > The Interactive Connectivity Establishment (ICE) protocol > [rfc5245bis] describes mechanisms how an ICE agent gathers > candidates, exchanges candidates with a peer ICE agent, and > creates candidate pairs. Once the pairs have been created, the > ICE agent will perform connectivity checks, and eventually > nominate and select pairs that will be used for sending and > receiving media within a session. >=20 > Although the procedures in [rfc5245bis] are relatively = straightforward > to implement, they might lead to relatively lengthy session = establishment > times, as candidate gathering often involves querying STUN servers = [RFC5389] > and allocating relayed candidates using TURN servers [RFC5766]. = Although > many procedures can be done in parallel, the pacing requirements = [rfc5245bis] > still needs to be followed. >=20 > This document defines a supplementary mode of ICE operation, > =E2=80=9CTrickle ICE=E2=80=9D, in which given candidates can be = exchanged incrementally, > as soon as they become available (and while other candidates are = still > gathered). Connectivity checks can also start as soon as candidate > pairs have been created. Then, as Trickle ICE allows candidate = gathering and > connectivity check in parallel, the session establishment time can = be > considerable shortened. >=20 > In addition, this document also defines how to discovers support of = Trickle ICE, > and how procedures in [rfc5245bis] are modified when using Trickle = ICE. The > document also defines how an Trickle ICE agent can interoperate = with an > ICE agent compliant to [rfc5245bis]. >=20 > This document does not define any ICE usage for Trickle ICE. = Protocol > specific details for Trickle ICE are defined in separate usage = documents. > Examples of such documents are [I-D.ietf-mmusic-trickle-ice-sip], = which > defines usage with the Session Initiation Protocol (SIP) [RFC3261] > and the Session Description Protocol [RFC4566] , and > [XEP-0176], which defines usage with XMPP [RFC6120]. However, > some of the examples in the document uses SDP and the > Offer/Answer mechanism [RFC4566] in order to explain the > underlying concepts. >=20 > NOTE: It is worth noting that there is quite a bit of operational > experience with the technique behind Trickle ICE, going back as far = as 2005 > (when the XMPP Jingle extension defined a "dribble mode" as = specified > in [XEP-0176]); this document incorporates feedback from those who > have implemented and deployed the technique. >=20 > --- >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice >=20 >=20 --Apple-Mail=_43E2414F-BA55-4F18-88DE-5572A21F8554 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----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlq8F64ACgkQgFZKbJXz 1A1L+g//UEhoR3SeCu1psu0vxcY9IpWGiOX3727AqRuajzoEBs7mfvoi0Nqj1/jC Y+JjkcXYLcNcpekv6LHMp7TroaIOgoq10RZpZcfGwSet4HaQYaJy3IGtyPxmCl0M KrE3qdEL8txEye0SH28jtsqDk7gOFR1jAVH9ym7RH3Uh2OWvn6UFQ/b+vgiB78lH b2TbmwwDthSWSoqCGctdcp1xojxSznhF95dwNhRI650zUhiNSredS1a034uK2WS7 sNOQf9LJYX/Rj52v8U/rdRmzAXDVxhWcKBanfiiqRhOMaKkacg4mej0oPkoT1JlF 18eHkk6X/b/fv+MzlBKpifhb9yUeqvV1qD5Kijj+vOZClEjXF6gTm+d4dnmVJoAO H+qMirsyrwdCh9tgTAzzwexlWYKkIGPvlRRvTqyDQ6zI2qhIZemFntImTNdaifW/ KcQNN74QNi+SiR1yOq1UJfDMq6zSrvF3/QeZVhCoJeeguj9qoV46lMuBC1JrxoR7 w/a201yWEZBPnMYy8gHBvXhwmz1RM578QKM484Dw1yaLpD9I62WR0mEn9MxoCU/y sI02nX1ybpJ4VZ3EjiCMxU9DBK13ePuarGm6/LfcCezOtf5IauLHtrY3FlB9MgPU dPtLHqhrsRx9Nze3tfBi+ARL8qFlypu3WmjC7k3ZaMKNF2/yatQ= =cIPp -----END PGP SIGNATURE----- --Apple-Mail=_43E2414F-BA55-4F18-88DE-5572A21F8554-- From nobody Wed Mar 28 15:43:38 2018 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 A770D127867 for ; Wed, 28 Mar 2018 15:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 2fWIMKM-EiBF for ; Wed, 28 Mar 2018 15:43:34 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 1E3761271FD for ; Wed, 28 Mar 2018 15:43:34 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id q80so5398323ioi.13 for ; Wed, 28 Mar 2018 15:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=s+nPM3lSilzCME8xb2eiyGF1FFizBgM62ljMOs4jmWk=; b=L/korPWsJzF+sfuoRRu6NG+qRXMw9rUhmkPJuBhHZFqqXlvXZqUjlwV1+ORpAclKSc 8WK4rpOUnFtbAj4jluQjczGfFg06MNSgfAeD6/uIc1vt7kdW3qF+fIQrMakksGZ3/BrN pezljCOtp4JzQoYGJROWrQUvRPv+8KyVABGRw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=s+nPM3lSilzCME8xb2eiyGF1FFizBgM62ljMOs4jmWk=; b=IU3IKeynjSgZ5ml0ZxdWjMPMkBpQPPlVRdkEbNh1zxxh2I8tDsBjQRfB9aMyGTS75A Do//mYX6mTWkjzFyGxUHCUQIUotKmLV1Vr6rPNaqD0oUQh9/F6cfOvb1fEY7+Eq4i5Qy /gvm/VlUrOvMOBUT76Y97DKra1hW1LOlr73FQHJ1cqgBSki9xPeA8yVH54cVaqn5CWb5 9E2KN46n7VwqVl2wuxvV1zikW1nIMqsXLvqv9MNH22yFpC5kAXM9XCmdg1d24sVUVcyP fM7m6KEZQNZXug6aDvJgMrgcTyMRV3lnMy7YHb7ZRoEgK5iNIDJBO2PDMurJMy6rNPLV y8iA== X-Gm-Message-State: AElRT7FNfFxuhpH7C+MmT95sVBY4x8RckvFrppX7LxkBkvuGiHXXye98 /lH+ej/weBZbF26+eJVCOXexlaHSAMI= X-Google-Smtp-Source: AG47ELs57pae70E7+oFzEMyoWE6P5QNFFT7nrPrIuNHtFaVVuqyNVBgjrSWhn+ivfg0irNHicMkolw== X-Received: by 10.107.151.146 with SMTP id z140mr44255258iod.237.1522277013379; Wed, 28 Mar 2018 15:43:33 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id z66-v6sm271461itg.37.2018.03.28.15.43.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 15:43:32 -0700 (PDT) To: Ben Campbell , Christer Holmberg Cc: Adam Roach , "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> <321c0d02-8e3b-1c6a-769a-ada15a5d5d6e@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E380FC@ESESSMB109.ericsson.se> <83C077AF-139B-41D2-94AB-0CF89C515382@nostrum.com> From: Peter Saint-Andre Message-ID: Date: Wed, 28 Mar 2018 16:43:31 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <83C077AF-139B-41D2-94AB-0CF89C515382@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cvwPkIPItECXMFLWKZeQteAQ0ok1NJ1Gq" Archived-At: Subject: Re: [Ice] Tricke ICE: Suggested clarifications to Introduction 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, 28 Mar 2018 22:43:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cvwPkIPItECXMFLWKZeQteAQ0ok1NJ1Gq Content-Type: multipart/mixed; boundary="02INDs7p3V0UpbGnPsD0WwFcMpW87B2vk"; protected-headers="v1" From: Peter Saint-Andre To: Ben Campbell , Christer Holmberg Cc: Adam Roach , "ice@ietf.org" Message-ID: Subject: Re: [Ice] Tricke ICE: Suggested clarifications to Introduction References: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> <321c0d02-8e3b-1c6a-769a-ada15a5d5d6e@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E380FC@ESESSMB109.ericsson.se> <83C077AF-139B-41D2-94AB-0CF89C515382@nostrum.com> In-Reply-To: <83C077AF-139B-41D2-94AB-0CF89C515382@nostrum.com> --02INDs7p3V0UpbGnPsD0WwFcMpW87B2vk Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I'm doing a final check and will publish this evening. On 3/28/18 4:31 PM, Ben Campbell wrote: > Hi Christer and Peter: >=20 > I prefer to have post-IETF LC drafts materially =E2=80=9Cdone=E2=80=9D = at least 7 days prior to the telechat. That=E2=80=99s nominally 0900 Thur= sday us/central, although I=E2=80=99ve generally treated that as =E2=80=9C= sometime before my close of business on Thursday without too much pushbac= k.) But I take this discussion to mean that these probably by then? If th= at=E2=80=99s the case, I will defer both of the trickle drafts to the nex= t telechat that has space. >=20 > Thanks, >=20 > Ben. >=20 >> On Mar 28, 2018, at 1:29 PM, Christer Holmberg wrote: >> >> Hi Adam, >> >>> As a reminder -- this document is on the IESG formal telechat for a w= eek from tomorrow. >Speaking only for myself, I find it unnecessarily dis= ruptive when documents change out >from under me during the week leading = up to the telechat. If you're going to make >*editorial* changes[1], plea= se make them today or not at all. >> >> Unfortunately it was noted that the draft contains text that is based = on old 5245bis procedures. So, while changes are editorial, there are als= o technical changes. >> >> Regards, >> >> Christer >> >> >> >> On 3/24/18 4:53 PM, Christer Holmberg wrote: >> Hi, >> >> Below is a suggestion on how to modify the Introduction section of dra= ft-trickle-ice, in order to make it more clear (in my opinion). >> >> --- >> >> 1. Introduction >> >> The Interactive Connectivity Establishment (ICE) protocol >> [rfc5245bis] describes mechanisms how an ICE agent gathers >> candidates, exchanges candidates with a peer ICE agent, and >> creates candidate pairs. Once the pairs have been created, the >> ICE agent will perform connectivity checks, and eventually >> nominate and select pairs that will be used for sending and >> receiving media within a session. >> >> Although the procedures in [rfc5245bis] are relatively straightforw= ard >> to implement, they might lead to relatively lengthy session establi= shment >> times, as candidate gathering often involves querying STUN servers = [RFC5389] >> and allocating relayed candidates using TURN servers [RFC5766]. Alth= ough >> many procedures can be done in parallel, the pacing requirements [r= fc5245bis] >> still needs to be followed. >> >> This document defines a supplementary mode of ICE operation, >> =E2=80=9CTrickle ICE=E2=80=9D, in which given candidates can be exc= hanged incrementally, >> as soon as they become available (and while other candidates are st= ill >> gathered). Connectivity checks can also start as soon as candidate >> pairs have been created. Then, as Trickle ICE allows candidate gath= ering and >> connectivity check in parallel, the session establishment time can = be >> considerable shortened. >> >> In addition, this document also defines how to discovers support of= Trickle ICE, >> and how procedures in [rfc5245bis] are modified when using Trickle = ICE. The >> document also defines how an Trickle ICE agent can interoperate wit= h an >> ICE agent compliant to [rfc5245bis]. >> >> This document does not define any ICE usage for Trickle ICE. Protoc= ol >> specific details for Trickle ICE are defined in separate usage docu= ments. >> Examples of such documents are [I-D.ietf-mmusic-trickle-ice-sip], w= hich >> defines usage with the Session Initiation Protocol (SIP) [RFC3261] >> and the Session Description Protocol [RFC4566] , and >> [XEP-0176], which defines usage with XMPP [RFC6120]. However, >> some of the examples in the document uses SDP and the >> Offer/Answer mechanism [RFC4566] in order to explain the >> underlying concepts. >> >> NOTE: It is worth noting that there is quite a bit of operational >> experience with the technique behind Trickle ICE, going back as far= as 2005 >> (when the XMPP Jingle extension defined a "dribble mode" as specifi= ed >> in [XEP-0176]); this document incorporates feedback from those who >> have implemented and deployed the technique. >> >> --- >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >> >=20 --02INDs7p3V0UpbGnPsD0WwFcMpW87B2vk-- --cvwPkIPItECXMFLWKZeQteAQ0ok1NJ1Gq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq8GpMACgkQZWGMGH9o FKkkhg//XIvIFr+OPfPAND8od0crKba9u5OCKKSxYvVM9scdbZYttFbxw0N6bQtd ZiVYrBb9MszulgiSNL/2WnCFsA3MC57Mun5hYdYkld4E6tKwfYYq/+Fx2O1LPcQa D3qA4/1sCkrkDQewhQ5H3roLRdt3gZPCR1NJ29bceSKaIaU7Dlm0hMf7pAlens/l fPT3nqQHV8m8UiLc0dWm7l/3fdm4mUEohIUKHLtNUY86e1K5YF8C/PKLfkNKuaya Or7CMSSf3fvW1QV3n+q60ySVlqzAfAo6kfYg7Y4NoNk4Q6vg+8F6klVO65cc4tSX pQOzRVsJvFzSzp/SyTnZajecMPLS4ixfyHjTq1pOI+ZBl2pM9DsRcAnTx/yY6mfL yy2VDy/TNsnESINQbTt3eG22cpX8DVMQlR5HOXxoKmJ6wBTKM1On9HVeht9OeSqh qQdujp/wOOsW9jjZKPUAPExIigqbxfRa7d3jRDEVCzwSLZJtGv4SFNcRv3dn0Vs4 Z2IH54iAGY1i+8rS8/4cxEFu46+da0ExSQ2gVF/uTDUge+xfHJx4P5zolhbB8EAU K89YPRC1b61IOwdh01lX/VKglZ/QDPRvl4lrKZwHjlTZ0qgot/JbbK8nR9x3lwEN YGZcwBS4z6JoYlFd9joj3DFUo2yfVSJ5cmV6Ovz2lM6/TIhNans= =ApmR -----END PGP SIGNATURE----- --cvwPkIPItECXMFLWKZeQteAQ0ok1NJ1Gq-- From nobody Wed Mar 28 15:46:49 2018 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 7DCE0127867 for ; Wed, 28 Mar 2018 15:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 308d9KfpOHxV for ; Wed, 28 Mar 2018 15:46:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A50124234 for ; Wed, 28 Mar 2018 15:46:45 -0700 (PDT) Received: from [10.50.10.6] (ip-17-232-239-173.texas.us.northamericancoax.com [173.239.232.17]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w2SMke71026916 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 28 Mar 2018 17:46:41 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host ip-17-232-239-173.texas.us.northamericancoax.com [173.239.232.17] claimed to be [10.50.10.6] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_048A70DA-F80B-4D94-8D56-7AE867DE0EAC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 28 Mar 2018 17:46:39 -0500 In-Reply-To: Cc: Christer Holmberg , Adam Roach , "ice@ietf.org" To: Peter Saint-Andre References: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> <321c0d02-8e3b-1c6a-769a-ada15a5d5d6e@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E380FC@ESESSMB109.ericsson.se> <83C077AF-139B-41D2-94AB-0CF89C515382@nostrum.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] Tricke ICE: Suggested clarifications to Introduction 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, 28 Mar 2018 22:46:47 -0000 --Apple-Mail=_048A70DA-F80B-4D94-8D56-7AE867DE0EAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Peter! I take it you expect that version will be ready for IESG = review? Ben. On Mar 28, 2018, at 5:43 PM, Peter Saint-Andre = wrote: >=20 >=20 > I'm doing a final check and will publish this evening. >=20 > On 3/28/18 4:31 PM, Ben Campbell wrote: >> Hi Christer and Peter: >>=20 >> I prefer to have post-IETF LC drafts materially =E2=80=9Cdone=E2=80=9D = at least 7 days prior to the telechat. That=E2=80=99s nominally 0900 = Thursday us/central, although I=E2=80=99ve generally treated that as = =E2=80=9Csometime before my close of business on Thursday without too = much pushback.) But I take this discussion to mean that these probably = by then? If that=E2=80=99s the case, I will defer both of the trickle = drafts to the next telechat that has space. >>=20 >> Thanks, >>=20 >> Ben. >>=20 >>> On Mar 28, 2018, at 1:29 PM, Christer Holmberg = wrote: >>>=20 >>> Hi Adam, >>>=20 >>>> As a reminder -- this document is on the IESG formal telechat for a = week from tomorrow. >Speaking only for myself, I find it unnecessarily = disruptive when documents change out >from under me during the week = leading up to the telechat. If you're going to make >*editorial* = changes[1], please make them today or not at all. >>>=20 >>> Unfortunately it was noted that the draft contains text that is = based on old 5245bis procedures. So, while changes are editorial, there = are also technical changes. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>> On 3/24/18 4:53 PM, Christer Holmberg wrote: >>> Hi, >>>=20 >>> Below is a suggestion on how to modify the Introduction section of = draft-trickle-ice, in order to make it more clear (in my opinion). >>>=20 >>> --- >>>=20 >>> 1. Introduction >>>=20 >>> The Interactive Connectivity Establishment (ICE) protocol >>> [rfc5245bis] describes mechanisms how an ICE agent gathers >>> candidates, exchanges candidates with a peer ICE agent, and >>> creates candidate pairs. Once the pairs have been created, the >>> ICE agent will perform connectivity checks, and eventually >>> nominate and select pairs that will be used for sending and >>> receiving media within a session. >>>=20 >>> Although the procedures in [rfc5245bis] are relatively = straightforward >>> to implement, they might lead to relatively lengthy session = establishment >>> times, as candidate gathering often involves querying STUN servers = [RFC5389] >>> and allocating relayed candidates using TURN servers [RFC5766]. = Although >>> many procedures can be done in parallel, the pacing requirements = [rfc5245bis] >>> still needs to be followed. >>>=20 >>> This document defines a supplementary mode of ICE operation, >>> =E2=80=9CTrickle ICE=E2=80=9D, in which given candidates can be = exchanged incrementally, >>> as soon as they become available (and while other candidates are = still >>> gathered). Connectivity checks can also start as soon as candidate >>> pairs have been created. Then, as Trickle ICE allows candidate = gathering and >>> connectivity check in parallel, the session establishment time can = be >>> considerable shortened. >>>=20 >>> In addition, this document also defines how to discovers support = of Trickle ICE, >>> and how procedures in [rfc5245bis] are modified when using Trickle = ICE. The >>> document also defines how an Trickle ICE agent can interoperate = with an >>> ICE agent compliant to [rfc5245bis]. >>>=20 >>> This document does not define any ICE usage for Trickle ICE. = Protocol >>> specific details for Trickle ICE are defined in separate usage = documents. >>> Examples of such documents are [I-D.ietf-mmusic-trickle-ice-sip], = which >>> defines usage with the Session Initiation Protocol (SIP) [RFC3261] >>> and the Session Description Protocol [RFC4566] , and >>> [XEP-0176], which defines usage with XMPP [RFC6120]. However, >>> some of the examples in the document uses SDP and the >>> Offer/Answer mechanism [RFC4566] in order to explain the >>> underlying concepts. >>>=20 >>> NOTE: It is worth noting that there is quite a bit of operational >>> experience with the technique behind Trickle ICE, going back as = far as 2005 >>> (when the XMPP Jingle extension defined a "dribble mode" as = specified >>> in [XEP-0176]); this document incorporates feedback from those who >>> have implemented and deployed the technique. >>>=20 >>> --- >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_048A70DA-F80B-4D94-8D56-7AE867DE0EAC 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----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlq8G08ACgkQgFZKbJXz 1A0L/hAAlvACaSbu+/qGtBK/fhKvbaixUIq9aYv52oyIu/cJCTyORgc86MQmqzP8 0Aq+HYXjoQPReKHiA+sFvjAuiBEuvyc3gHeCfKq7iGznaUWRYFFJNOQjjCC9ctRv ATvVClnzVPIuuiKRw2dmJySzqk+e6T5pwY87hZik9i69QOi4xp7jo4OICpxyICFs 0KQp0pjaOM3/rwAu7ejXOzL1Qsx2MRCAIaifFRJglZubSi+m8XtsDBYsIfRUy3gv zJRfdCbz40BVD0jXQGwVtVjcNRKc6ILnjRpE+bDCpe2244bITxxXw1bjMBrYjep+ lbVqdfnxNN+WLs7s1bVgyLvBExWpw9g1R+YUz04HLvHqYjgJd1aar2HTCehe/qcc FHo3lagE6o6ycP/rqawe5RSduV1787zVryKaPmXn+O3EBNrM6lLQWuHCJG2EWoO0 ytc5Pw0jxkhnKkAoveKYq36kn6SRJKi/E15tcUfcoGM3xzwkqLNmdpZOaBysjr5O YynT4qpaSdn7IUOUGKuZ0Xew/cJu5F2v5gLWMW6r7j68mZ90//7ttpgZOyCjMURo cmuc/r+rqAcUas1oaUDai8tzIgig2san6ZdvhzV26XNwzGlZO02YtdP9jfQlFC+E nTMYs3MnUfKkGuF+0WiUphuic0trjLla41hh0KkRSMyxTR3Wx3Q= =7mHK -----END PGP SIGNATURE----- --Apple-Mail=_048A70DA-F80B-4D94-8D56-7AE867DE0EAC-- From nobody Wed Mar 28 15:51:30 2018 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 A43B9127867 for ; Wed, 28 Mar 2018 15:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 3pGndwBtUj1Q for ; Wed, 28 Mar 2018 15:51:26 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133EE124234 for ; Wed, 28 Mar 2018 15:51:26 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id d6so3472409iog.1 for ; Wed, 28 Mar 2018 15:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=qqf+VNeRwtkf18kXzB2NqpqHuGPtPOXGI+SNorNjQp4=; b=aRYFpg0Jk5C4oD1vEit+lbLHInCrW0Wtn46UMcipqbFZYS9s81heIq3MGa0mtIVH/+ G6/pJ3MXyj2hxg9wHGC6RnJVp0rGY5Lfx25zcoeoO7oERFBbIu2yB0+OL/dJEvRPTAO2 /j9WEK9vlpaWZatqp715HizmGXD2B9tM4orEg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=qqf+VNeRwtkf18kXzB2NqpqHuGPtPOXGI+SNorNjQp4=; b=J+SCu2i8QsoVNFY0oIl8gtwZ1JZfr5DSQISeyT8mAFUTrPdmvfPtz3pPI6CCFoB/gU 8R80BidA6FY7J+JhVr8QTwq5vo9PtRhSpgr3Zwf1B7D3DwjOFb8UDskUKXHSFHfvio0s 7NX7q6HZHeQw1iAP45DvcW+AUkzwCx7Hp1QRt2JrGXJ1wwfgLlFRjsqHq0GdSjqnhsbp NDVADLkHVg0I8elXKmYHVFue4iKELaUiWz1rut/iiVzOWD/tXE1PCA0LZ5sc8YwuM5DP UY9q1MYt9CilGooWUYDOcJbMxlLrGTJ565K0CrJ53Ks+QfEL7IdwS1YaszXIwgSHh+pI KGFw== X-Gm-Message-State: AElRT7H3h2E95sOidh8C2SRmnBox5yuS9le/wYpI6YSJPZfsUvSZNpEg EW+hi2zzh7sIhfOvPy/zSYeMoQ== X-Google-Smtp-Source: AG47ELs2xMnCvQucuXaOZQZEW7DxmaDGtCA8bq5UFZD3JxKbylO0HuWDL0WwGxP6qyjLlzGcU1pFdg== X-Received: by 10.107.11.198 with SMTP id 67mr48841532iol.43.1522277485343; Wed, 28 Mar 2018 15:51:25 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id i137sm3175678ioi.44.2018.03.28.15.51.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 15:51:24 -0700 (PDT) To: Ben Campbell Cc: Christer Holmberg , Adam Roach , "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> <321c0d02-8e3b-1c6a-769a-ada15a5d5d6e@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E380FC@ESESSMB109.ericsson.se> <83C077AF-139B-41D2-94AB-0CF89C515382@nostrum.com> From: Peter Saint-Andre Message-ID: <59350440-87b3-f878-ca50-8c00887ec1c7@mozilla.com> Date: Wed, 28 Mar 2018 16:51:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PmPBF9ugvK1eLOV2jHmbOUpzDiM0NqR61" Archived-At: Subject: Re: [Ice] Tricke ICE: Suggested clarifications to Introduction 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, 28 Mar 2018 22:51:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PmPBF9ugvK1eLOV2jHmbOUpzDiM0NqR61 Content-Type: multipart/mixed; boundary="JpWexFuNLn79Yw8apgDyXFWVnaiPnqiBu"; protected-headers="v1" From: Peter Saint-Andre To: Ben Campbell Cc: Christer Holmberg , Adam Roach , "ice@ietf.org" Message-ID: <59350440-87b3-f878-ca50-8c00887ec1c7@mozilla.com> Subject: Re: [Ice] Tricke ICE: Suggested clarifications to Introduction References: <7594FB04B1934943A5C02806D1A2204B72E18C06@ESESSMB109.ericsson.se> <321c0d02-8e3b-1c6a-769a-ada15a5d5d6e@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E380FC@ESESSMB109.ericsson.se> <83C077AF-139B-41D2-94AB-0CF89C515382@nostrum.com> In-Reply-To: --JpWexFuNLn79Yw8apgDyXFWVnaiPnqiBu Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable That is indeed the intent! On 3/28/18 4:46 PM, Ben Campbell wrote: > Thanks Peter! I take it you expect that version will be ready for IESG = review? >=20 > Ben. >=20 > On Mar 28, 2018, at 5:43 PM, Peter Saint-Andre wr= ote: >> >> >> I'm doing a final check and will publish this evening. >> >> On 3/28/18 4:31 PM, Ben Campbell wrote: >>> Hi Christer and Peter: >>> >>> I prefer to have post-IETF LC drafts materially =E2=80=9Cdone=E2=80=9D= at least 7 days prior to the telechat. That=E2=80=99s nominally 0900 Thu= rsday us/central, although I=E2=80=99ve generally treated that as =E2=80=9C= sometime before my close of business on Thursday without too much pushbac= k.) But I take this discussion to mean that these probably by then? If th= at=E2=80=99s the case, I will defer both of the trickle drafts to the nex= t telechat that has space. >>> >>> Thanks, >>> >>> Ben. >>> >>>> On Mar 28, 2018, at 1:29 PM, Christer Holmberg wrote: >>>> >>>> Hi Adam, >>>> >>>>> As a reminder -- this document is on the IESG formal telechat for a= week from tomorrow. >Speaking only for myself, I find it unnecessarily d= isruptive when documents change out >from under me during the week leadin= g up to the telechat. If you're going to make >*editorial* changes[1], pl= ease make them today or not at all. >>>> >>>> Unfortunately it was noted that the draft contains text that is base= d on old 5245bis procedures. So, while changes are editorial, there are a= lso technical changes. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> On 3/24/18 4:53 PM, Christer Holmberg wrote: >>>> Hi, >>>> >>>> Below is a suggestion on how to modify the Introduction section of d= raft-trickle-ice, in order to make it more clear (in my opinion). >>>> >>>> --- >>>> >>>> 1. Introduction >>>> >>>> The Interactive Connectivity Establishment (ICE) protocol >>>> [rfc5245bis] describes mechanisms how an ICE agent gathers >>>> candidates, exchanges candidates with a peer ICE agent, and >>>> creates candidate pairs. Once the pairs have been created, the >>>> ICE agent will perform connectivity checks, and eventually >>>> nominate and select pairs that will be used for sending and >>>> receiving media within a session. >>>> >>>> Although the procedures in [rfc5245bis] are relatively straightfor= ward >>>> to implement, they might lead to relatively lengthy session establ= ishment >>>> times, as candidate gathering often involves querying STUN servers= [RFC5389] >>>> and allocating relayed candidates using TURN servers [RFC5766]. Alt= hough >>>> many procedures can be done in parallel, the pacing requirements [= rfc5245bis] >>>> still needs to be followed. >>>> >>>> This document defines a supplementary mode of ICE operation, >>>> =E2=80=9CTrickle ICE=E2=80=9D, in which given candidates can be ex= changed incrementally, >>>> as soon as they become available (and while other candidates are s= till >>>> gathered). Connectivity checks can also start as soon as candidate= >>>> pairs have been created. Then, as Trickle ICE allows candidate gat= hering and >>>> connectivity check in parallel, the session establishment time can= be >>>> considerable shortened. >>>> >>>> In addition, this document also defines how to discovers support o= f Trickle ICE, >>>> and how procedures in [rfc5245bis] are modified when using Trickle= ICE. The >>>> document also defines how an Trickle ICE agent can interoperate wi= th an >>>> ICE agent compliant to [rfc5245bis]. >>>> >>>> This document does not define any ICE usage for Trickle ICE. Proto= col >>>> specific details for Trickle ICE are defined in separate usage doc= uments. >>>> Examples of such documents are [I-D.ietf-mmusic-trickle-ice-sip], = which >>>> defines usage with the Session Initiation Protocol (SIP) [RFC3261]= >>>> and the Session Description Protocol [RFC4566] , and >>>> [XEP-0176], which defines usage with XMPP [RFC6120]. However, >>>> some of the examples in the document uses SDP and the >>>> Offer/Answer mechanism [RFC4566] in order to explain the >>>> underlying concepts. >>>> >>>> NOTE: It is worth noting that there is quite a bit of operational >>>> experience with the technique behind Trickle ICE, going back as fa= r as 2005 >>>> (when the XMPP Jingle extension defined a "dribble mode" as specif= ied >>>> in [XEP-0176]); this document incorporates feedback from those who= >>>> have implemented and deployed the technique. >>>> >>>> --- >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ice mailing list >>>> Ice@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ice >>>> >>>> >>> >> >=20 --JpWexFuNLn79Yw8apgDyXFWVnaiPnqiBu-- --PmPBF9ugvK1eLOV2jHmbOUpzDiM0NqR61 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq8HGsACgkQZWGMGH9o FKmg9A/+PesOkUr9brJYs+HP7bl7z+S8QY540RXsZfYGVBV997+HJnB98hfBHpKt dN2WLNeACxcl9+hvVIMaWxhpXN7VhMb1d5O0yldFvHL6NvItCpDWoesa1Vy0D2X8 9rCAgwpHVRAf5kW+AuF5FVlnbKihYLLMZegHEOo4vyWDzPDVoZpsCRu+jU13CZmO DyCRCL8gTl4S5slxzp6U4hJz7ApYzV/Z3+t1/4+59YRt873NmQUZqYiAyccuSdEm w9ti4KlYDfOdPyFpvX1zHrOXpDeEyyHsGrdtdLiMpZYcRIZ83EZth3vzTMRRWVuz 1T6irysaglydVwx1H4aZD7Wl11XAsLMlq3hkOAzaOWFDwQyhfKT6V2eSdlIlcv6o xDgOC2YC1+uF0uut0jmx1ZuFPQWiTvEhn3H8s7C2G6s3NmpcOE4FQFlN5NKIvMmJ qJuBiQzPx9sDTAgKHRfAEO69aaZku5c5Oqzpl4qoPKRQUx8KYnW9SWNfOWHTRzer CKnFoP1LFk8EhxWmJxwailmWofIr+I2R07cE2ewDtB9pATwda4i/7S437uK1Vpey 8WRjHm2z21dqN3zF133Qi3d/NcoJoENcSuU1ndd/BYFgGnMuFjf0JlBTu+D7TwF9 OKiAw8fTZRK3T51FZXH1YMoDdH6abmLXh2Hzq44aeGFAmZOF8i8= =V3LV -----END PGP SIGNATURE----- --PmPBF9ugvK1eLOV2jHmbOUpzDiM0NqR61-- From nobody Wed Mar 28 16:38:29 2018 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 556D51242F5; Wed, 28 Mar 2018 16:38:27 -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.76.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152228030728.24074.8190705353047990691@ietfa.amsl.com> Date: Wed, 28 Mar 2018 16:38:27 -0700 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-trickle-18.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: Wed, 28 Mar 2018 23:38:27 -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-18.txt Pages : 32 Date : 2018-03-28 Abstract: This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to begin connectivity checks while they are still gathering candidates, by incrementally "trickling" candidates over time. This method can considerably accelerate the process of establishing a communication session. 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-18 https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 29 08:06:11 2018 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 E823212DA25 for ; Thu, 29 Mar 2018 08:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 8VIzxwKYopMR for ; Thu, 29 Mar 2018 08:05:57 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1585912E870 for ; Thu, 29 Mar 2018 08:05:57 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id l201so11364807wmg.0 for ; Thu, 29 Mar 2018 08:05:56 -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=iuF12k5YbpbL10MS+0dGb2LPxsECd44p4M0hO/558Fc=; b=eDQFfsAWXH6+gINHrsRsaQGaC/sQ5+COXVKv59X0Rvu5+rD7Qj72sDeDJpenJdzEBL sTrzdHl5PWygrjhZYc37aGR8fTNE/gvEIQnOELLTKEZAl4qNTJAFOcWnqXJdm+yEPok5 w4wQ9N+PH/w1ID++uN2G//GbmMP8+1Y8bLtu+SOidW4lx7dG3UEjFIwNyOxPHk4HWhY7 WC8KZcKE3uP407OciBdYk2TXHoTHsWpLsP/u70Ol9+pu/v5bGtL1iezlHZWqJRbXLieS o/6itgYeFgfbgzjwm3fqxh1S2SmBTXUI9gxCMXqXZkqd0OtLaoQbB5+uKR1zujHCusaD uuEQ== 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=iuF12k5YbpbL10MS+0dGb2LPxsECd44p4M0hO/558Fc=; b=hDzp4jp3b6OXzRP2A1FeGWtv0PoInMEsArKqQbHqgQa2L/fg9mTB+vzEltwdSh1ySE Pj80Ve+YOtHr9AjNO7PE/cXs67m5F+jtrKkZPnESgU2TvS2VJPrSYnw0geRM1TZ7aB8H 9o9a80jLLGAxT25Hutns8hoqm20/nOIgDS8+wSI9847oIWZU7tRf/SIwnnWThqNYWaTm adkBPlixjuxlFDIewC6Yk2aCW2JfvWGbWxPqn6sOuJ204Ddqgi4C72C8IPwN7D8tZNLD E0L8TpK4jhXtUNBeQD0USUYn4nke1K46ZERavrve9fWW+L+3gXIr/hkG28yKfe6Az5zP 6+0w== X-Gm-Message-State: AElRT7GNWVbglWeXod8fIFpPjun+sXnCuQPO9lXWR+37iwp5q2qRRByy 5MEYCk0t+ZZ8ByRD8nbbb6NSQFha4oRgfnnW0s1x/LyL X-Google-Smtp-Source: AIpwx4+zSsmQG2Vyr/NkUudUBHWXLPBo5Hx9+OWFLdvnyRgPPLC+PZFghyv++lvIhdn54jSm/UPLC8u6PWfVU89gEBE= X-Received: by 10.28.63.212 with SMTP id m203mr6354379wma.124.1522335955165; Thu, 29 Mar 2018 08:05:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 29 Mar 2018 15:05:44 +0000 Message-ID: To: ICE WG Content-Type: multipart/alternative; boundary="001a114b4174d6b5b805688e75a4" Archived-At: Subject: Re: [Ice] Confirmation about tie breaker behavior changes ICEbis 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, 29 Mar 2018 15:06:10 -0000 --001a114b4174d6b5b805688e75a4 Content-Type: text/plain; charset="UTF-8" Since we haven't heard anything, we're going to declare consensus and proceed with publication. On Tue, Mar 13, 2018 at 8:46 PM Peter Thatcher wrote: > In the changes to ICEbis during the IESG review (thanks again Christer!), > there is one item that has come up that is not just editorial: > > The changing of the tie breaker value during a role change due to role > conflict has changed from a MAY to a MUST. This was to address the very > rare situation when both sides choose the same tie breaker value. > > If you disagree with this change, please let it be known. If we don't > hear anything, we will assume consensus and proceed with publication of > ICEbis. > > Thanks! > > > > By the way, you can read rest of the changes to ICEbis at the links below, > but in my opinion as shepherd after reading through all of them thoroughly, > they are editorial except for this issue. > > > https://tools.ietf.org/rfcdiff?url1=draft-ietf-ice-rfc5245bis-17.txt&url2=draft-ietf-ice-rfc5245bis-20.txt > --001a114b4174d6b5b805688e75a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since we haven't heard anything, we're going to de= clare consensus and proceed with publication.

On Tue, Mar 13, 2018 at 8:46 PM Peter Thatcher <pthatcher@google.com> wrote:
In the changes to I= CEbis during the IESG review (thanks again Christer!), there is one item th= at has come up that is not just editorial:

The changing = of the tie breaker value during a role change due to role conflict has chan= ged from a MAY to a MUST.=C2=A0 This was to address the very rare situation= when both sides choose the same tie breaker value.=C2=A0=C2=A0
<= br>
If you disagree with this change, please let it be known.=C2= =A0 If we don't hear anything, we will assume consensus and proceed wit= h publication of ICEbis.=C2=A0

Thanks!
<= br>


By the way, you can read rest o= f the changes to ICEbis at the links below, but in my opinion as shepherd a= fter reading through all of them thoroughly, they are editorial except for = this issue.

--001a114b4174d6b5b805688e75a4-- From nobody Thu Mar 29 13:59:44 2018 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 615AB1250B8; Thu, 29 Mar 2018 13:59:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-ice-trickle@ietf.org, Nils Ohlmeier , ice-chairs@ietf.org, nohlmeier@mozilla.com, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.76.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152235718235.4397.6159667533096871849.idtracker@ietfa.amsl.com> Date: Thu, 29 Mar 2018 13:59:42 -0700 Archived-At: Subject: [Ice] Benjamin Kaduk's Yes on draft-ietf-ice-trickle-18: (with COMMENT) 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, 29 Mar 2018 20:59:42 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-ice-trickle-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please consider using the RFC 8174 boilerplate to supplement RFC 2119. Section 5 implies that plain ICE includes a provision for an ICE description with no candidates, but I'm failing to find that reference. The rfc5245bis draft seems to always assume that there will be at least a host candidate. Is perhaps a different reference intended? In section 8.2: o As a standalone notification (e.g., after STUN Binding requests or TURN Allocate requests to a server time out and the agent has is not actively gathering candidates) s/has is/is/ Section 13 says that trickled candidate information may cause an ICE restart using the 5245bis semantics, but I don't see anywhere in 5245bis that would have additional candidate information induce a restart. Is this the right reference? Thanks for updating per the secdir review about the in-order requirement! However, we currently have language about transmitting candidates/end-of-candidates "not more than once", but we kind of do want exactly-once semantics for end-of-candidates, unless ICE terminates normally prior to that. Is there a good way to phrase that more clearly? Maybe the last bullet of section 15 (must be able to send end-of-candidates) should come earlier in the list, in particular before the requirement for nonduplication and in-order. From nobody Thu Mar 29 14:36:22 2018 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 C6DC912D82F for ; Thu, 29 Mar 2018 14:36:19 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 c_-aW-8qvBu2 for ; Thu, 29 Mar 2018 14:36:16 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 772611272E1 for ; Thu, 29 Mar 2018 14:36:16 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id o4so9278109iod.3 for ; Thu, 29 Mar 2018 14:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=YikHbfZB9GvkOqcx4Y4FEGmZciAgs+fv92CqE7mKcCU=; b=b32N1HAfytTacFZAOVBbynGeoj1ngjYgtsi/i5bbgTHpYZ2WVb+wR68M/UPb+wfCJI lfFRIZqu9iQT49OA8MfNDDtn4A52OpAnjhF0j+2m3BdW5q2/3TMNJ2wspYpnm5pV2kR3 lN0uhh2JDMXkFoI8kwtxXWBF2ID/H9KCinJII= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=YikHbfZB9GvkOqcx4Y4FEGmZciAgs+fv92CqE7mKcCU=; b=LPZBKkPOBDW2UJcv6vqQl/jkP2cE2XLol5+JGQEegJheNrBYqMhvcq17JVi0d2EQhn X8xzDUAEh3i97GJIFzeENrDixIj0DciTc2lFGmgVsI8rrqSWN/rcJScwrvod/CMX/t9H oAaRRVr3DTkjXp/udbxq1vb1RJMjFeluC+9H3tlhg3H0KFZObcHDLp35sbBix+lAKFod +PbCH/u6OuOHEkVSI5EVxAAPaFGsCe0CWNs6uU9r2YkvECObZcspzfU5EfKuS0hfebEj d2kmDxXacnWYot8J3oyVLB90yYHDUcu/0maC/jL90QLVuGQo23KMbz9jbX6WT38nE+i1 v2bA== X-Gm-Message-State: AElRT7FhxzELB/wgRXeUVOMwRuouXCAQ9N7b4pnRprmMBher/IJqKXza maXXV4qqrp9QFCYsTBSPrB+AjQ== X-Google-Smtp-Source: AIpwx48Fgw6zqSOSmZHQzEVbzBcEUkahvFaDubHTYXs56m9qRy4jIc777mJOl7Q5Y83Ji/4+LZVz0Q== X-Received: by 10.107.198.136 with SMTP id w130mr11095257iof.131.1522359375718; Thu, 29 Mar 2018 14:36:15 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id p68-v6sm1606802itc.13.2018.03.29.14.36.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 14:36:14 -0700 (PDT) To: Benjamin Kaduk , The IESG Cc: draft-ietf-ice-trickle@ietf.org, Nils Ohlmeier , ice-chairs@ietf.org, ice@ietf.org References: <152235718235.4397.6159667533096871849.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Thu, 29 Mar 2018 15:36:13 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <152235718235.4397.6159667533096871849.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Wx9H012c2c9jYuijOvrzWVDpzkcqNt2il" Archived-At: Subject: Re: [Ice] Benjamin Kaduk's Yes on draft-ietf-ice-trickle-18: (with COMMENT) 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, 29 Mar 2018 21:36:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Wx9H012c2c9jYuijOvrzWVDpzkcqNt2il Content-Type: multipart/mixed; boundary="YU95N5MLSTLAjk6oTs3iWSIGrcTIFuLgZ"; protected-headers="v1" From: Peter Saint-Andre To: Benjamin Kaduk , The IESG Cc: draft-ietf-ice-trickle@ietf.org, Nils Ohlmeier , ice-chairs@ietf.org, ice@ietf.org Message-ID: Subject: Re: Benjamin Kaduk's Yes on draft-ietf-ice-trickle-18: (with COMMENT) References: <152235718235.4397.6159667533096871849.idtracker@ietfa.amsl.com> In-Reply-To: <152235718235.4397.6159667533096871849.idtracker@ietfa.amsl.com> --YU95N5MLSTLAjk6oTs3iWSIGrcTIFuLgZ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Ben, welcome to the IESG! :-) On 3/29/18 2:59 PM, Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-ice-trickle-18: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Please consider using the RFC 8174 boilerplate to supplement RFC 2119. My preferred solution is to scrub lowercase instances from the document, which I will do in the next revision. > Section 5 implies that plain ICE includes a provision for an ICE descri= ption > with no candidates, but I'm failing to find that reference. The rfc524= 5bis draft seems > to always assume that there will be at least a host candidate. > Is perhaps a different reference intended? I see a few things in 5245bis, but perhaps I'm missing something... =C2=A72.1 At least one viable candidate has a transport address obtained directly from a local interface. Such a candidate is called a host candidate. =C2=A75.3 ICE agents (initiating and responding) need the following information about candidates to be exchanged. Each ICE usage MUST define how the information is exchanged with the using protocol. This section describes the information that needs to be exchanged. Candidates: One or more candidates. For each candidate: Also, =C2=A73 says: This document specifies generic use of ICE with protocols that provide means to exchange candidate information between the ICE agents. The specific details of (i.e how to encode candidate information and the actual candidate exchange process) for different protocols using ICE (referred to as using protocol) are described in separate usage documents. I'm not seeing anything in 5245bis specifying that an ICE description (or ICE candidate exchange) MUST contain at least one candidate. Can you point to the text? IMHO Trickle ICE defines one way of completing the candidate exchange (e.g., offer/answer is another), and its methods are not forbidden by 5245bis. > In section 8.2: >=20 > o As a standalone notification (e.g., after STUN Binding requests o= r > TURN Allocate requests to a server time out and the agent has is > not actively gathering candidates) >=20 > s/has is/is/ That text is not in -18. I fear you might have reviewed -17? I published -18 late yesterday. (Note that some section numbers changed, too.) > Section 13 says that trickled candidate information may cause an ICE > restart using the 5245bis semantics, but I don't see anywhere in > 5245bis that would have additional candidate information induce a > restart. Is this the right reference? 5245bis states: To restart ICE, an agent MUST change both the password and the username fragment for the data stream(s) being restarted. Such a change could be included when sending candidate information. > Thanks for updating per the secdir review about the in-order requiremen= t! > However, we currently have language about transmitting candidates/end-o= f-candidates > "not more than once", but we kind of do want exactly-once semantics for= > end-of-candidates, unless ICE terminates normally prior to that. > Is there a good way to phrase that more clearly? Not-more-than-once and exactly-once are indeed different things, with the latter being more difficult to accomplish. Do we kind of want to impose stricter requirements on implementations and using protocols, or do we really want to? ;-) > Maybe the last bullet of section 15 (must be able to send > end-of-candidates) should come earlier in the list, in particular befor= e the > requirement for nonduplication and in-order. That's an unordered list ('symbols' not 'numbers' in the XML). The bullets are ordered by the appearance of those points in the text. I have no particular allegiance to that order - but if you believe in the serial-position effect then first or last is best. :-) Thanks for the review! Peter --YU95N5MLSTLAjk6oTs3iWSIGrcTIFuLgZ-- --Wx9H012c2c9jYuijOvrzWVDpzkcqNt2il Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq9XE0ACgkQZWGMGH9o FKmkqw//VKEf7Ovjq092EfzL5RZ2RPUeX60g+fxwFWmeY24Pqp1fW3WVY9ws4eR3 EN/FKhPEGBG/eND8a//lfmrtQGtKsmVLpcK7mEcNsP7FwEPybjWzJxTkaR/bPTzP gHki4ceu/tTXXhQtHRnFXGidRi5eP0bX3GnG8A0fMzuHFl1SXIuxI0Z/sp2zg7mK 6fVnCcOTjdRqp2ooydVhL4ukI0Ps2Zyp80/eh8N8byU9j7xFwstEtNXFzje/6RKK 5nU8BGvXt3y3Axu6qRtogZTdRKZPDLycWo8mH8gwgsEYoquYagHInfbkoXLrszJF NSMDrZ7KkAfoPJ5sTt7YP4J7dkF6zkdQ7QxtmCmYS+ODNQtL1iwN/UI9d87nOGse AYKMA7SeQHJ8eK4eyIpYmhsWzuUGANxXtLofOGLgTna1sDb5svFaS8ltodpGqERZ rNW7zaVIUH0HEIzRtKhheLOerC2S5LQoXTMZe+kIGL2WR0mQSZMvfBB0kBN4lvSF oPkVbRnIOYmp9NCcQYTvV8IhylXoDZAzNeZY9CKX0iUOq25McR4YKYywwuj1CGpY +WjXuUwx72pc495HJCTOS2RpJjVh8zYXYSpIo21MCAfi4D5Qe19iPY9h98U/C5BQ Ws7+1N0d5zwH1pCQq3A5rZFJUJpzO2/wiIuhS1CdKs+N5TG7Yuk= =P5cF -----END PGP SIGNATURE----- --Wx9H012c2c9jYuijOvrzWVDpzkcqNt2il-- From nobody Thu Mar 29 14:51:55 2018 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 64F0C124BFA for ; Thu, 29 Mar 2018 14:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 wduLqYxsVsDk for ; Thu, 29 Mar 2018 14:51:44 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 B230E126DC2 for ; Thu, 29 Mar 2018 14:51:41 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id c1-v6so9583688itj.1 for ; Thu, 29 Mar 2018 14:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:from:to:cc:references:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=LKaamtCAuKnrMVDIZjCuw3gtzERtkBxbnDs1Lo0Xgtk=; b=OMEhJiD51W80+C8E0Y4or6OZ/ljzfQ+FWuTaBLnz3Aix1PTPOWjGFoT45ryq/ShNwD +eTx9D725xvFkKLjlAJjYtz2ggpdxddJkGCqNHWEQFEP0NKyhqNwTSKOXguu5ktXYFBU juOzyPDKYqJuwppY4vDlPuMhA36R1LIojpxBA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=LKaamtCAuKnrMVDIZjCuw3gtzERtkBxbnDs1Lo0Xgtk=; b=Rm7QAguO7jeHu1eLhty9A73xziKKbJO4ooVr4c1TKohdR63IWD422iSoNAJfRr75Bv H6yrSpJ/vQ9b807/4V404wGqpcweXDodbYfPt57yZIIUqnvG3CfHcYI78TMHb9EwD4Al kblWMUzlZR8cmgzjKw0SUZf58BxHJAJyuUnbwgC4LeGeINunwSUc4yd3BTYE5JLnIO2p LCTLonMOfYNtYi+T1WD9/Mwl5CpxXjv//n77wKvmtpfQ/fc8yuEtxAC4jxR5Fxjg+mdo BPDxsT4GZ3SsKi9kugyytste5VdlV8xKZ+6ddQvwLRZXDC0ytcCm761z03F9Pb4uyXs4 wnKQ== X-Gm-Message-State: AElRT7G0vBIWP4ArwvloRzaB7y7C7E+CIKTE3Vv7s/ImDxEGIs8I8eoC CpJhs80tCbZ783aqSDK/yANwew== X-Google-Smtp-Source: AIpwx4/Pe8E9CSM9sp1Ze6Vw4aDcKFDsuCFeKeI/aK9O/NfSg/U2q+VNFjQAPyMbCmyJgMLnbm8BhQ== X-Received: by 2002:a24:82c1:: with SMTP id t184-v6mr700908itd.61.1522360300984; Thu, 29 Mar 2018 14:51:40 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id e142-v6sm1682082ite.23.2018.03.29.14.51.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 14:51:40 -0700 (PDT) From: Peter Saint-Andre To: Benjamin Kaduk , The IESG Cc: draft-ietf-ice-trickle@ietf.org, Nils Ohlmeier , ice-chairs@ietf.org, ice@ietf.org References: <152235718235.4397.6159667533096871849.idtracker@ietfa.amsl.com> Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <59cfabf3-2e47-a183-5506-aa037f45de1e@mozilla.com> Date: Thu, 29 Mar 2018 15:51:39 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rgoFvyGh57m2fW0C8yRR65XKJ6MkpaDYE" Archived-At: Subject: Re: [Ice] Benjamin Kaduk's Yes on draft-ietf-ice-trickle-18: (with COMMENT) 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, 29 Mar 2018 21:51:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rgoFvyGh57m2fW0C8yRR65XKJ6MkpaDYE Content-Type: multipart/mixed; boundary="JC4a4f6zArl9rWTHVkMUfTjigeP45w0Bt"; protected-headers="v1" From: Peter Saint-Andre To: Benjamin Kaduk , The IESG Cc: draft-ietf-ice-trickle@ietf.org, Nils Ohlmeier , ice-chairs@ietf.org, ice@ietf.org Message-ID: <59cfabf3-2e47-a183-5506-aa037f45de1e@mozilla.com> Subject: Re: Benjamin Kaduk's Yes on draft-ietf-ice-trickle-18: (with COMMENT) References: <152235718235.4397.6159667533096871849.idtracker@ietfa.amsl.com> In-Reply-To: --JC4a4f6zArl9rWTHVkMUfTjigeP45w0Bt Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Correction inline! >> Thanks for updating per the secdir review about the in-order requireme= nt! >> However, we currently have language about transmitting candidates/end-= of-candidates >> "not more than once", but we kind of do want exactly-once semantics fo= r >> end-of-candidates, unless ICE terminates normally prior to that. >> Is there a good way to phrase that more clearly? >=20 > Not-more-than-once and exactly-once are indeed different things, with > the latter being more difficult to accomplish. Do we kind of want to > impose stricter requirements on implementations and using protocols, or= > do we really want to? ;-) Sorry, I mis-read your comment. By "not-more-than-once" I'm pretty sure we meant "exactly-once" (I suppose the former includes not delivering the data at all, but delivery is implied by the text "MUST deliver ... not more than once" in =C2=A78). So this is an editorial matter, not a technical matter as I see it. (It's the difference between exactly once and at least once that I was thinking about.) Peter --JC4a4f6zArl9rWTHVkMUfTjigeP45w0Bt-- --rgoFvyGh57m2fW0C8yRR65XKJ6MkpaDYE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq9X+sACgkQZWGMGH9o FKm3MBAAqPpsWw3FfD93r8PEhKo5TA9sxYdLFLmxbRW9tQj1aLkD+8T1ayJfJQSv zJyOIqapoVJodlZkQOZtVDKYro1JULR9dAKSKCH3JB1LIxcXEzMn8maFqOa5Th2i vpRjiJBGoB6gDyuEwfuxt4m0zGCqntVY/KZyNlO00iXNyk2mskTF+PiUJpWfG2bI qOsGWpF8ikQLy1IKnCIGsv59lWcWDgCHOyhZRIEVyDR4vpm9k911xb1mbl5z5N4p a5RNSTw06Ozk1Z+hE8LyIdwBasH8kxLobqC8gt7jGJaWwRxsknUnXs270qFuOJer KCja0meA+rFBOL+SZpav36sqEhUHMdqeY9JVJa6IKH+22eOkJsXh+P8pwpX95DFk FBC0T2s58NmAJOMv7z8qxnedrlsdm0Lh2vOEd/rPVKqCAdsNRkI/ISTxyz1LyOWh 4kj5y0874v2N14LxXeVvk3mYa55bIOxJG3I9O6PF4bs7TzoNKxB0aOK3v8VG96GK MG9eR2yWCPTkrzj/opFhZB9xg+jh5GGj+z/5Wy8WDl9mlpk0w07AByQ1rAiXy2Nd M4X3wD1/wsTlU4cQ7wDlTr4DDgL3sZcLRc1n+Mc7Rvrfj7a1I8ssrIKqR32hvJAb eSeA+XgYwWAinwzpQszZj9KytP74Fatv9UsC2lMGcwnJYFTDcYs= =8+7y -----END PGP SIGNATURE----- --rgoFvyGh57m2fW0C8yRR65XKJ6MkpaDYE-- From nobody Thu Mar 29 15:02:26 2018 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 7F2BA126DFB; Thu, 29 Mar 2018 15:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 5LIIUfk2ANMM; Thu, 29 Mar 2018 15:02:16 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 26956126DC2; Thu, 29 Mar 2018 15:02:15 -0700 (PDT) X-AuditID: 12074422-187ff70000003feb-42-5abd62642f52 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 1A.35.16363.5626DBA5; Thu, 29 Mar 2018 18:02:14 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w2TM28hc012179; Thu, 29 Mar 2018 18:02:09 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w2TM23ZK025070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Mar 2018 18:02:06 -0400 Date: Thu, 29 Mar 2018 17:02:03 -0500 From: Benjamin Kaduk To: Peter Saint-Andre Cc: The IESG , draft-ietf-ice-trickle@ietf.org, Nils Ohlmeier , ice-chairs@ietf.org, ice@ietf.org Message-ID: <20180329220203.GA80088@kduck.kaduk.org> References: <152235718235.4397.6159667533096871849.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsUixG6nopuWtDfK4FarhMWrV62MFhdnTWaz +Hah1mLGn4nMFtfnTWa0eLbyFKMDm8eSJT+ZPPoOdLEGMEVx2aSk5mSWpRbp2yVwZdzZtpmp 4I5xxaKPL5kaGO9rdDFyckgImEj8OfmGrYuRi0NIYDGTxKeXX5ggnI2MEvO3fWUCqRISuMok 8eWnIojNIqAq8WNtK1icTUBFoqH7MjOILSKgLXHz0F4WkGZmgZmMEjs+/GcFSQgL+Ek0n28A K+IFWvf+5nVmiA2NjBKHDt+ESghKnJz5hAXEZhbQkdi59Q7QTRxAtrTE8n8cEGF5ieats8HK OQXsJf7/aGQEsUUFlCX29h1in8AoOAvJpFlIJs1CmDQLyaQFjCyrGGVTcqt0cxMzc4pTk3WL kxPz8lKLdE31cjNL9FJTSjcxgsPfRWkH48R/XocYBTgYlXh4K9j2RgmxJpYVV+YeYpTkYFIS 5b0aDRTiS8pPqcxILM6ILyrNSS0+xCjBwawkwvteY3eUEG9KYmVValE+TEqag0VJnNfDRDtK SCA9sSQ1OzW1ILUIJivDwaEkwduSCDRUsCg1PbUiLTOnBCHNxMEJMpwHaHg7SA1vcUFibnFm OkT+FKOilDivJUhCACSRUZoH1wtKTxLZ+2teMYoDvSLMOxGkigeY2uC6XwENZgIaLFKzB2Rw SSJCSqqBMfdFU9HqrDurZlpt4voQrrSW50CJ3+vMe3zbzZufWbxpK78wdUVI4f8tZ5ou/bg6 fVNIhedB00nmKx6nl6yxyrQ6+WPZmbXNB4IDtS5wdW/lPPrKr2GLQrj4+fVdvtuvdz//7r/i xdZ3c25IuBtsu89zdXtIsNGc2+p+k4Rf8v+Mkd+cu3yhy0ElluKMREMt5qLiRAACN5pqKgMA AA== Archived-At: Subject: Re: [Ice] Benjamin Kaduk's Yes on draft-ietf-ice-trickle-18: (with COMMENT) 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, 29 Mar 2018 22:02:20 -0000 On Thu, Mar 29, 2018 at 03:36:13PM -0600, Peter Saint-Andre wrote: > Hi Ben, welcome to the IESG! :-) Thanks :) > On 3/29/18 2:59 PM, Benjamin Kaduk wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-ice-trickle-18: Yes > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Please consider using the RFC 8174 boilerplate to supplement RFC 2119. > > My preferred solution is to scrub lowercase instances from the document, > which I will do in the next revision. > > > Section 5 implies that plain ICE includes a provision for an ICE description > > with no candidates, but I'm failing to find that reference. The rfc5245bis draft seems > > to always assume that there will be at least a host candidate. > > Is perhaps a different reference intended? > > I see a few things in 5245bis, but perhaps I'm missing something... > > §2.1 > > At least one viable candidate has a transport address obtained > directly from a local interface. Such a candidate is called a host > candidate. > > §5.3 > > ICE agents (initiating and responding) need the following information > about candidates to be exchanged. Each ICE usage MUST define how the > information is exchanged with the using protocol. This section > describes the information that needs to be exchanged. > > Candidates: One or more candidates. For each candidate: Maybe this is what I'm thinking of. (I appreciate the help searching from someone more familiar with the space.) > Also, §3 says: > > This document specifies generic use of ICE with protocols that > provide means to exchange candidate information between the ICE > agents. The specific details of (i.e how to encode candidate > information and the actual candidate exchange process) for different > protocols using ICE (referred to as using protocol) are described in > separate usage documents. > > I'm not seeing anything in 5245bis specifying that an ICE description > (or ICE candidate exchange) MUST contain at least one candidate. Can you > point to the text? (No, just the above note.) > IMHO Trickle ICE defines one way of completing the candidate exchange > (e.g., offer/answer is another), and its methods are not forbidden by > 5245bis. I don't think I want to dispute your statement. I'm looking at this text: [...] Specifically, the rules from [rfc5245bis] would imply that ICE itself is not supported if the initial ICE description includes no candidates; however, such a conclusion is not warranted if the responder can confirm that the initiator supports Trickle ICE, and need help figuring out what part of 5245bis is intended as the reference. > > In section 8.2: > > > > o As a standalone notification (e.g., after STUN Binding requests or > > TURN Allocate requests to a server time out and the agent has is > > not actively gathering candidates) > > > > s/has is/is/ > > That text is not in -18. I fear you might have reviewed -17? I published > -18 late yesterday. (Note that some section numbers changed, too.) I did review the -17, yes. (I had this and the sip profile open simultaneously since yesterday to cross-reference, but didn't submit reviews of either until today.) I will look at the diff from -17 to -18 after I send this. > > Section 13 says that trickled candidate information may cause an ICE > > restart using the 5245bis semantics, but I don't see anywhere in > > 5245bis that would have additional candidate information induce a > > restart. Is this the right reference? > > 5245bis states: > > To restart ICE, an agent MUST change both the password and the > username fragment for the data stream(s) being restarted. > > Such a change could be included when sending candidate information. Thanks for the clarification. There is perhaps some subtle state-keeping requirement on implementations, then, as section 8 (of -18) notes: Also, candidate trickling needs to be correlated to a specific ICE session, so that if there is an ICE restart, any delayed updates for a previous session can be recognized as such and ignored by the receiving party. In that one needs to keep state in order to tell between ignoring delayed updates from a previous session and detecting a desire to start a new session. > > Thanks for updating per the secdir review about the in-order requirement! > > However, we currently have language about transmitting candidates/end-of-candidates > > "not more than once", but we kind of do want exactly-once semantics for > > end-of-candidates, unless ICE terminates normally prior to that. > > Is there a good way to phrase that more clearly? > > Not-more-than-once and exactly-once are indeed different things, with > the latter being more difficult to accomplish. Do we kind of want to > impose stricter requirements on implementations and using protocols, or > do we really want to? ;-) [other clarification followed, but for this situation it might actually just be "kind-of want to"] > > Maybe the last bullet of section 15 (must be able to send > > end-of-candidates) should come earlier in the list, in particular before the > > requirement for nonduplication and in-order. > > That's an unordered list ('symbols' not 'numbers' in the XML). The > bullets are ordered by the appearance of those points in the text. I > have no particular allegiance to that order - but if you believe in the > serial-position effect then first or last is best. :-) I was just going off the principle that concepts should be (re)introduced before they are (re)used, not any particular sense of ordering or priority. And it's not like this is the first time in the document that we're hearing about any of these, so do as you want :) > Thanks for the review! You're welcome! -Benjamin From nobody Thu Mar 29 16:15:55 2018 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 71576126CC7 for ; Thu, 29 Mar 2018 16:15:53 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 UYeVdHSwDb-Z for ; Thu, 29 Mar 2018 16:15:51 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 95CDF127775 for ; Thu, 29 Mar 2018 16:15:48 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id d5so9446501iob.9 for ; Thu, 29 Mar 2018 16:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=EUy9ShDOkxYS0rfC3w34ScSQrtQ23VDLZ3UlGkAHxXM=; b=Zy0QY/XMZne/YvdL1MID0arfGKbh4vecG7BUnb7pYlDBTS0cfoUC0sRsfYrZFtwBxy V+o+QocfewASpgX4+Q7ckvZ2YQg30rbgjLvSZPK8WwMTjY2t/9dmbtzhnY0LRiRrc0TY 1giPB+td+EpgF3ZhJs1xVF0CiKXSrLpqiS89Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=EUy9ShDOkxYS0rfC3w34ScSQrtQ23VDLZ3UlGkAHxXM=; b=ez8ljCeW8IIzgYxcqix9UX+Xn3WeOacV6+Y5Q91m7E2ElPBpZY7fwMqNqeN9mfSqv8 i5e5GrekPp1AnDqQ2DRyGM/d7crg+GYsyVkqy7H6u8IZP1xb7n85b24lawxggjwm3p7a Ipa4zLSJR4tDpKeZD/OyJ2O4R8qrZMZD4a3w1KlGBFWhqz7cKLYcv7AsjwufbmX9CH0q gZKCN1MwsCmXNf1qyYq6uyGto4pCbuqDzMEXMKRHwZ0+F8hiAUVMyMUpg+d0kpX2cggF g/l32+9cuf5tth54/SblGDN00fxvId1/R2FAqGMcHjfyPBdZ3P5jZeuUsneuC7czEOTf 9/ag== X-Gm-Message-State: AElRT7FOTfgMhyMImu340xr1zeF1Bj11RqKfFMJIfZXLt/PpL+mehLrc kB6/WJxwSAs44HS3jJwSNtQ8EQ== X-Google-Smtp-Source: AIpwx4/KNXetlFg8LBijIgcquEpFnB/gOTi/D3iZPbhYD10clNq7xoIXCK0ylvSoRWFHhs2I4jr2rQ== X-Received: by 10.107.171.65 with SMTP id u62mr33454365ioe.73.1522365347829; Thu, 29 Mar 2018 16:15:47 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id q71sm4467803iod.64.2018.03.29.16.15.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 16:15:47 -0700 (PDT) To: Benjamin Kaduk Cc: The IESG , draft-ietf-ice-trickle@ietf.org, Nils Ohlmeier , ice-chairs@ietf.org, ice@ietf.org References: <152235718235.4397.6159667533096871849.idtracker@ietfa.amsl.com> <20180329220203.GA80088@kduck.kaduk.org> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Thu, 29 Mar 2018 17:15:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180329220203.GA80088@kduck.kaduk.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3WdFFsH8LBT1cHwFo2MDSQc4PI6ppWLHl" Archived-At: Subject: Re: [Ice] Benjamin Kaduk's Yes on draft-ietf-ice-trickle-18: (with COMMENT) 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, 29 Mar 2018 23:15:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3WdFFsH8LBT1cHwFo2MDSQc4PI6ppWLHl Content-Type: multipart/mixed; boundary="FspSWCQx8hoiPGloU7Zz4wohbOz8wWb08"; protected-headers="v1" From: Peter Saint-Andre To: Benjamin Kaduk Cc: The IESG , draft-ietf-ice-trickle@ietf.org, Nils Ohlmeier , ice-chairs@ietf.org, ice@ietf.org Message-ID: Subject: Re: Benjamin Kaduk's Yes on draft-ietf-ice-trickle-18: (with COMMENT) References: <152235718235.4397.6159667533096871849.idtracker@ietfa.amsl.com> <20180329220203.GA80088@kduck.kaduk.org> In-Reply-To: <20180329220203.GA80088@kduck.kaduk.org> --FspSWCQx8hoiPGloU7Zz4wohbOz8wWb08 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/29/18 4:02 PM, Benjamin Kaduk wrote: > On Thu, Mar 29, 2018 at 03:36:13PM -0600, Peter Saint-Andre wrote: >> Hi Ben, welcome to the IESG! :-) >=20 > Thanks :) >=20 >> On 3/29/18 2:59 PM, Benjamin Kaduk wrote: >>> Benjamin Kaduk has entered the following ballot position for >>> draft-ietf-ice-trickle-18: Yes >>> >>> When responding, please keep the subject line intact and reply to all= >>> email addresses included in the To and CC lines. (Feel free to cut th= is >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.= html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ >>> >>> >>> >>> ---------------------------------------------------------------------= - >>> COMMENT: >>> ---------------------------------------------------------------------= - >>> >>> Please consider using the RFC 8174 boilerplate to supplement RFC 2119= =2E >> >> My preferred solution is to scrub lowercase instances from the documen= t, >> which I will do in the next revision. >> >>> Section 5 implies that plain ICE includes a provision for an ICE desc= ription >>> with no candidates, but I'm failing to find that reference. The rfc5= 245bis draft seems >>> to always assume that there will be at least a host candidate. >>> Is perhaps a different reference intended? >> >> I see a few things in 5245bis, but perhaps I'm missing something... >> >> =C2=A72.1 >> >> At least one viable candidate has a transport address obtained >> directly from a local interface. Such a candidate is called a host= >> candidate. >> >> =C2=A75.3 >> >> ICE agents (initiating and responding) need the following informati= on >> about candidates to be exchanged. Each ICE usage MUST define how t= he >> information is exchanged with the using protocol. This section >> describes the information that needs to be exchanged. >> >> Candidates: One or more candidates. For each candidate: >=20 > Maybe this is what I'm thinking of. (I appreciate the help > searching from someone more familiar with the space.) >=20 >> Also, =C2=A73 says: >> >> This document specifies generic use of ICE with protocols that >> provide means to exchange candidate information between the ICE >> agents. The specific details of (i.e how to encode candidate >> information and the actual candidate exchange process) for differen= t >> protocols using ICE (referred to as using protocol) are described i= n >> separate usage documents. >> >> I'm not seeing anything in 5245bis specifying that an ICE description >> (or ICE candidate exchange) MUST contain at least one candidate. Can y= ou >> point to the text? >=20 > (No, just the above note.) >=20 >> IMHO Trickle ICE defines one way of completing the candidate exchange >> (e.g., offer/answer is another), and its methods are not forbidden by >> 5245bis. >=20 > I don't think I want to dispute your statement. I'm looking at this > text: >=20 > [...] Specifically, > the rules from [rfc5245bis] would imply that ICE itself is not > supported if the initial ICE description includes no candidates; > however, such a conclusion is not warranted if the responder can > confirm that the initiator supports Trickle ICE, >=20 > and need help figuring out what part of 5245bis is intended as the > reference. It's possible this sentence referred to text in 5245bis that's now gone. In particular, RFC 5245 was tied to the offer/answer model (RFC 3264) but that is no longer the case and this seems like an offer/answer stricture. In any case, we've tried to remove text from the trickle spec that summarizes or duplicates or describes what 5245bis specifies, and this seems like more text to remove. >>> In section 8.2: >>> >>> o As a standalone notification (e.g., after STUN Binding requests= or >>> TURN Allocate requests to a server time out and the agent has i= s >>> not actively gathering candidates) >>> >>> s/has is/is/ >> >> That text is not in -18. I fear you might have reviewed -17? I publish= ed >> -18 late yesterday. (Note that some section numbers changed, too.) >=20 > I did review the -17, yes. (I had this and the sip profile open > simultaneously since yesterday to cross-reference, but didn't submit > reviews of either until today.) I will look at the diff from -17 to > -18 after I send this. Sorry about that. We received some late-ish feedback that needed to be addressed. >>> Section 13 says that trickled candidate information may cause an ICE >>> restart using the 5245bis semantics, but I don't see anywhere in >>> 5245bis that would have additional candidate information induce a >>> restart. Is this the right reference? >> >> 5245bis states: >> >> To restart ICE, an agent MUST change both the password and the >> username fragment for the data stream(s) being restarted. >> >> Such a change could be included when sending candidate information. >=20 > Thanks for the clarification. There is perhaps some subtle > state-keeping requirement on implementations, then, as section 8 (of > -18) notes: >=20 > Also, candidate trickling needs to be correlated to a specific ICE > session, so that if there is an ICE restart, any delayed updates for= > a previous session can be recognized as such and ignored by the > receiving party. >=20 > In that one needs to keep state in order to tell between ignoring > delayed updates from a previous session and detecting a desire to > start a new session. Yes, this is handled by ICE agents by tracking which ICE session is in force (through the combination of Username Fragment and Password). I'm not sure it's all so subtle, though. >>> Thanks for updating per the secdir review about the in-order requirem= ent! >>> However, we currently have language about transmitting candidates/end= -of-candidates >>> "not more than once", but we kind of do want exactly-once semantics f= or >>> end-of-candidates, unless ICE terminates normally prior to that. >>> Is there a good way to phrase that more clearly? >> >> Not-more-than-once and exactly-once are indeed different things, with >> the latter being more difficult to accomplish. Do we kind of want to >> impose stricter requirements on implementations and using protocols, o= r >> do we really want to? ;-) >=20 > [other clarification followed, but for this situation it might > actually just be "kind-of want to"] Do you agree this a matter of phrasing, or do you have a technical concer= n? >>> Maybe the last bullet of section 15 (must be able to send >>> end-of-candidates) should come earlier in the list, in particular bef= ore the >>> requirement for nonduplication and in-order. >> >> That's an unordered list ('symbols' not 'numbers' in the XML). The >> bullets are ordered by the appearance of those points in the text. I >> have no particular allegiance to that order - but if you believe in th= e >> serial-position effect then first or last is best. :-) >=20 > I was just going off the principle that concepts should be > (re)introduced before they are (re)used, not any particular sense of > ordering or priority. And it's not like this is the first time in > the document that we're hearing about any of these, so do as you > want :) OK. I'll look at that order again (perhaps it makes sense to order them by importance or difficulty). Peter --FspSWCQx8hoiPGloU7Zz4wohbOz8wWb08-- --3WdFFsH8LBT1cHwFo2MDSQc4PI6ppWLHl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlq9c6EACgkQZWGMGH9o FKm2BRAAilBX5F6JEtKyZuKHfxb/ZR7jxsxAY1XhxCVrX/28fqqqq4jO2kKjmjfx ZHnkbgvs6wU6Ievq0FUR6vcNKb77rUuAVCZWcwEg+AUrCYlKpRLdC6l6LzxKjlX0 elyljqVO1eBI/s3m00rPo7oJvvfDrmbmViQvYeturrGY1zhMZA2XotZOwy7nfUSH HGL4XnAYMniGu2e67R2Nm8CYfeI07opfejsoEdbB1TQmJtBli62daoJyGf2GwQh7 YlcwfOX+d5n5WyO4Y5JKtEwMs0S+UmmO+D/bbup6/+rwPXkh2LUc2MhDbLlXhINc bz4sd5xgB5bYz7h9VBkEhtgsk3oqjbRTUjo0SpmomR2spB+cNOWuFucH/c/dGKDJ pgwke11xDaULCB0WcAnmhYFTv1n7xwlMJP5kZMqGxunQPewSIVw+de//EAaMsop3 Cf4socXTMtluJsEPulY63z/5QU69ysHTtNVpr8hV0XtBfGqg4iQPApkQt+9HKeB1 U1KuGeBNb1+W25wWFXaGqs45e+GnzZqW4P/05Isig5S6A1q6kzNTdS9syGVcGSW0 SmUzKovRo8QN4dhebK7Uc8Cg4whizxQbuLO1oLTC7sTMPuFwQ6ikClFfbzdM/QU4 EfifA3tkpkJ8prxnC5hjdbccab6A/Ae4+R2n6/JYb/HMUAlxcdc= =yMVI -----END PGP SIGNATURE----- --3WdFFsH8LBT1cHwFo2MDSQc4PI6ppWLHl-- From nobody Thu Mar 29 21:05:37 2018 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 2766312E059; Thu, 29 Mar 2018 21:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 6FjHnofPnouu; Thu, 29 Mar 2018 21:05:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F0D12DA09; Thu, 29 Mar 2018 21:05:34 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w2U45Xtq015397 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 29 Mar 2018 23:05:34 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_CF1EED4F-25CF-4A99-B4C4-583987B1F183"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <8BD83ABC-2F3E-4DC5-82F6-12C88B4E60F4@nostrum.com> Date: Thu, 29 Mar 2018 23:05:32 -0500 To: draft-ietf-ice-rfc5245bis.all@ietf.org, ice@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Ice] draft-ietf-ice-rfc5245bis-20 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, 30 Mar 2018 04:05:36 -0000 --Apple-Mail=_CF1EED4F-25CF-4A99-B4C4-583987B1F183 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, draft-ietf-ice-rfc5245bis-20 is approved for publication. Many thanks to = the authors and all who have been involved for the hard work! Ben. --Apple-Mail=_CF1EED4F-25CF-4A99-B4C4-583987B1F183 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----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlq9t4wACgkQgFZKbJXz 1A1SpA/9HGVYpc/feDqc0vCrplc94aFuhM5eCrMGn+/nsHZE/cS/SegLXa1/c4pb rNawuyKJ9Mj1O5fQP6Wa8I6/0coontZY+xuyerBtYHa7nYqST/k4LuMEwliiN08y 8rbSnonMp2SfwmggH2jiClSPGQfw1eTzKxC5PZGB2xkNDpp3q9URu2bqHlcThxeW VddnDHk5KCurNHi5vp7O5Y7UTsYT6SprFex2G8oQmnsmDT3QqYN7KwbEVowMbhj4 Y1N69ucu9grV3n+cVNGx0BE6lKBDuq5Y7oUNCOA0UZUeaHLRXpc9/TK2Hzp/ZBt+ WAfV7tmf6DzEdqy8YtJn/0pY9FU485eZXcpcHeQj161NqB7imCpqkdm1A0ifH/XG Bamovr3ZqlVxJlz56JGaR/6fFAgIyitU7K2y9hMRVynTnzpldIdFiPZS6DnE29Qp 9RpxvWKd+gl+ytmCVherek6q8ECrFt1Pj+TAnD6xzPI54e8nyKZgcXYecLkGZnH0 86rzRQRSreZ3Fcoo9cs8Jt6B/mZnqOMZbyQC6Ja1KI2o4HbgG9BYDok/D0AMPp4o QVCNjQa3NAXdfOzRFf5TdBinl20dbhFPx2pr/ERVMWipPmKDZdlcCAL45TaVCZwf L/BmIf1gywJFIQHw9/RaxR54ZcGdhHNQ9Upq+LezBak1zaVB3ZI= =Ugy2 -----END PGP SIGNATURE----- --Apple-Mail=_CF1EED4F-25CF-4A99-B4C4-583987B1F183-- From nobody Fri Mar 30 04:24:54 2018 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 B663212D7EF for ; Fri, 30 Mar 2018 04:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 lhTzyehWrHlD for ; Fri, 30 Mar 2018 04:24:51 -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 23A7412D7EC for ; Fri, 30 Mar 2018 04:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522409089; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mvOl7AscqaqzbIBAgRJg9UAomxpKnKhCawtNE1AUy/8=; b=Kykx5d2Mx2VuB2+cV2gi+OFkGwUNI3Xte4ogTlg8blXY8MmeklJuISwzt4wiQqd2 0A7zPDXg0BTeRcxciyXeaooHrHRGtNgzitG4y7xkzuq2PLhSTH3YGVbVQ1KnNIpF iuKgvA4Z0WgjBusTKwhuW3dEQK597QO/+aVVmkJWe08=; X-AuditID: c1b4fb2d-e31ff700000073d9-08-5abe1e819ebc Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 28.8A.29657.18E1EBA5; Fri, 30 Mar 2018 13:24:49 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0382.000; Fri, 30 Mar 2018 13:24:48 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Ben Campbell , ICE WG , "draft-ietf-ice-rfc5245bis.all@ietf.org" Thread-Topic: draft-ietf-ice-rfc5245bis-20 Thread-Index: AQHTx9xcx1p4+t9epkSXZsAka9Je86PogiuA Date: Fri, 30 Mar 2018 11:24:48 +0000 Message-ID: <1A163F01-7148-4512-9A73-830DC3A53BA7@ericsson.com> References: <8BD83ABC-2F3E-4DC5-82F6-12C88B4E60F4@nostrum.com> In-Reply-To: <8BD83ABC-2F3E-4DC5-82F6-12C88B4E60F4@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.95.226.8] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1EE779F15C83B74FA80D8F36B1CCE808@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbFdXbdRbl+Uwc79UhbzO0+zWxz/8Yfd 4tuFWgdmjyVLfjJ5zNr5hCWAKYrLJiU1J7MstUjfLoEr4/XsXcwFq5kq5q7tZGlgfMnYxcjJ ISFgIvHu6UO2LkYuDiGBI4wSe5bdZAZJCAksYZRoadUHsdkE7CUmr/nICFIkIjCBUeL0/l4g h4NDWEBT4uO/NJAaEQEtiS8vnrFC2EYSrSdmgM1hEVCVePDtPFicF2jOioMT2SDm20ksvfQZ zOYEiq+9eALsIEYBMYnvp9YwgdjMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWx5iRlnb0HV 60ncmDqFDcK2lri8ei8zhK0tsWzha2aIGwQlTs58wjKBUXQWkhWzkLTPQtI+C0n7LCTtCxhZ VzGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIExtHBLb91dzCufu14iFGAg1GJhzdUYl+UEGti WXFl7iFGCQ5mJRFeq5N7o4R4UxIrq1KL8uOLSnNSiw8xSnOwKInz6q3aEyUkkJ5YkpqdmlqQ WgSTZeLglGpg5L+oa7n64UGhRAGHLdt3/Tc9wuCtdD08+ZK1wJ0rzydt+7b8w40pZRrVneuc +LlK9Z1EF1yP1lzMkxrd/Jzb4EQAW+Ga+l8PM/W0P3OeFZ5bFGEsZNTJdrPgj9wprmUND87I 75RIjNh9wvTzKz6fb/p+/qdnOXnL676OfbPutDKrYe+Nx4e1lFiKMxINtZiLihMBVZo7ap8C AAA= Archived-At: Subject: Re: [Ice] draft-ietf-ice-rfc5245bis-20 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, 30 Mar 2018 11:24:53 -0000 Excellent news! Thank you everyone! Cheers, Ari > On 30 Mar 2018, at 7.05, Ben Campbell wrote: >=20 > Hi, >=20 > draft-ietf-ice-rfc5245bis-20 is approved for publication. Many thanks to = the authors and all who have been involved for the hard work! >=20 > Ben. From nobody Fri Mar 30 11:14:51 2018 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 44F1B12420B; Fri, 30 Mar 2018 11:14:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.76.2 Auto-Submitted: auto-generated Precedence: bulk Cc: ben@nostrum.com, The IESG , ice-chairs@ietf.org, ice@ietf.org, draft-ietf-ice-rfc5245bis@ietf.org, pthatcher@google.com, rfc-editor@rfc-editor.org, Peter Thatcher MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152243368925.20556.6530232970285691487.idtracker@ietfa.amsl.com> Date: Fri, 30 Mar 2018 11:14:49 -0700 Archived-At: Subject: [Ice] Protocol Action: 'Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal' to Proposed Standard (draft-ietf-ice-rfc5245bis-20.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, 30 Mar 2018 18:14:49 -0000 The IESG has approved the following document: - 'Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal' (draft-ietf-ice-rfc5245bis-20.txt) as Proposed Standard This document is the product of the Interactive Connectivity Establishment Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ Technical Summary This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. 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. Working Group Summary The document was discussed and reviewed very actively for many years by many parties. There is much interest in the community because there are many documents which depend on this document, especially in the RTCWEB work, and because there are many deployed implementations of the existing Proposed Standard (RFC 5245). Notable discussions include the decisions of the "Ta" value (how frequently packets are sent), backwards compatibility with RFC 5245 endpoints, removal of "aggressive nomination", generalization of ICE to more than just RTP/RTCP, and generalization of ICE signaling to more than just SDP offer/answer. There was a long-term, lively discussion with a large number of folks followed by thorough review by a smaller number of very interested folks. Consensus was usually not quick, but was broad when finally reached. One particular point of controversy waws around the Ta value and packet pacing, which required significant experimentation by working members in the real world and participation from many other working groups, especially from the transport area. This point was resolved by finding a technical solution that all groups were happy with and which seemed to work well in real world experimentation. Document Quality Reviews on specific areas (such as the Ta value) were done by folks in the transport area. Other reviews were done by members of other working groups (such as RTCWEB and MMUSIC). The reviews were extensive and no further review is necessary. The document shepherd has no specific concerns or issues with the document. There are many RFC 5245 implementations and at least some of those (especially RTCWEB implementations) are already being updated. Personnel The document shepherd is Peter Thatcher. The responsible area director is Ben Campbell. From nobody Sat Mar 31 10:52:38 2018 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 D6E14127077; Sat, 31 Mar 2018 10:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 MpDB96vsG_An; Sat, 31 Mar 2018 10:52:35 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 8EB8312D941; Sat, 31 Mar 2018 10:52:34 -0700 (PDT) X-AuditID: 12074424-e4bff70000007a51-76-5abfcadf41e4 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id D7.05.31313.0EACFBA5; Sat, 31 Mar 2018 13:52:32 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w2VHqTOV032468; Sat, 31 Mar 2018 13:52:30 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w2VHqPEK026885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 31 Mar 2018 13:52:28 -0400 Date: Sat, 31 Mar 2018 12:52:25 -0500 From: Benjamin Kaduk To: Peter Saint-Andre Cc: The IESG , draft-ietf-ice-trickle@ietf.org, Nils Ohlmeier , ice-chairs@ietf.org, ice@ietf.org Message-ID: <20180331175225.GE80088@kduck.kaduk.org> References: <152235718235.4397.6159667533096871849.idtracker@ietfa.amsl.com> <20180329220203.GA80088@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IR4hRV1n1wan+UQcc+GYtXr1oZLS7Omsxm 8e1CrcWMPxOZLa7Pm8xo8WzlKUYHNo8lS34yefQd6GINYIrisklJzcksSy3St0vgynj5+jVj wSOVikPnpzE2MD6T6WLk5JAQMJGYunsyexcjF4eQwGImiZU/j7BBOBsZJfae/8gM4VxlkpjY c4gdpIVFQFXi3ebrYDabgIpEQ/dlZhBbREBb4uahvSwgDcwCMxkldnz4zwqSEBbwk2g+3wBW xAu0b8PKnywQUx8ySjx6eZcNIiEocXLmExYQm1lAS+LGv5dMXYwcQLa0xPJ/HCBhTgF7iY0r N4OViwooS+ztO8Q+gVFgFpLuWUi6ZyF0L2BkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRrrpeb WaKXmlK6iREU0OwuKjsYu3u8DzEKcDAq8fBGJO6LEmJNLCuuzD3EKMnBpCTKm9cGFOJLyk+p zEgszogvKs1JLT7EKMHBrCTCK5a0P0qINyWxsiq1KB8mJc3BoiTOu3j/3ighgfTEktTs1NSC 1CKYrAwHh5IEr8ZJoEbBotT01Iq0zJwShDQTByfIcB6g4RtAaniLCxJzizPTIfKnGBWlxHnX gCQEQBIZpXlwvaCEI5G9v+YVozjQK8K8l0GqeIDJCq77FdBgJqDBIjV7QAaXJCKkpBoYmXkF vdU2O2pa6Sz6evTpOyEptr03Vr0ymXN3yf0j/pdtnicf275u1bqjpvJnSh88r8m8pJ2Qut/N veP9vUt1FtOtGNV85/y9tjFWtetU6Byr9DbFtwdecc4xT3WyWt0suCrO2NiYtTo/UaL9y4+9 rgufHT4b8zlRXeyAxJGG5pDMQ28dbpaxKLEUZyQaajEXFScCAOjvfBsTAwAA Archived-At: Subject: Re: [Ice] Benjamin Kaduk's Yes on draft-ietf-ice-trickle-18: (with COMMENT) 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, 31 Mar 2018 17:52:37 -0000 On Thu, Mar 29, 2018 at 05:15:45PM -0600, Peter Saint-Andre wrote: > On 3/29/18 4:02 PM, Benjamin Kaduk wrote: > > On Thu, Mar 29, 2018 at 03:36:13PM -0600, Peter Saint-Andre wrote: > >> Hi Ben, welcome to the IESG! :-) > > > >> On 3/29/18 2:59 PM, Benjamin Kaduk wrote: > > > > I don't think I want to dispute your statement. I'm looking at this > > text: > > > > [...] Specifically, > > the rules from [rfc5245bis] would imply that ICE itself is not > > supported if the initial ICE description includes no candidates; > > however, such a conclusion is not warranted if the responder can > > confirm that the initiator supports Trickle ICE, > > > > and need help figuring out what part of 5245bis is intended as the > > reference. > > It's possible this sentence referred to text in 5245bis that's now gone. > In particular, RFC 5245 was tied to the offer/answer model (RFC 3264) > but that is no longer the case and this seems like an offer/answer > stricture. In any case, we've tried to remove text from the trickle spec > that summarizes or duplicates or describes what 5245bis specifies, and > this seems like more text to remove. Okay. > > >>> Section 13 says that trickled candidate information may cause an ICE > >>> restart using the 5245bis semantics, but I don't see anywhere in > >>> 5245bis that would have additional candidate information induce a > >>> restart. Is this the right reference? > >> > >> 5245bis states: > >> > >> To restart ICE, an agent MUST change both the password and the > >> username fragment for the data stream(s) being restarted. > >> > >> Such a change could be included when sending candidate information. > > > > Thanks for the clarification. There is perhaps some subtle > > state-keeping requirement on implementations, then, as section 8 (of > > -18) notes: > > > > Also, candidate trickling needs to be correlated to a specific ICE > > session, so that if there is an ICE restart, any delayed updates for > > a previous session can be recognized as such and ignored by the > > receiving party. > > > > In that one needs to keep state in order to tell between ignoring > > delayed updates from a previous session and detecting a desire to > > start a new session. > > Yes, this is handled by ICE agents by tracking which ICE session is in > force (through the combination of Username Fragment and Password). I'm > not sure it's all so subtle, though. I think it's a question of do you only keep one ufrag+password as state ("the current sesion"), or some level of history. In the former case, you can't tell between a delayed packet coming in from an old session and a request to start a new one, IIUC. So the subtlety would be if there is actually a requirement to track more history than just the current session. > >>> Thanks for updating per the secdir review about the in-order requirement! > >>> However, we currently have language about transmitting candidates/end-of-candidates > >>> "not more than once", but we kind of do want exactly-once semantics for > >>> end-of-candidates, unless ICE terminates normally prior to that. > >>> Is there a good way to phrase that more clearly? > >> > >> Not-more-than-once and exactly-once are indeed different things, with > >> the latter being more difficult to accomplish. Do we kind of want to > >> impose stricter requirements on implementations and using protocols, or > >> do we really want to? ;-) > > > > [other clarification followed, but for this situation it might > > actually just be "kind-of want to"] > > Do you agree this a matter of phrasing, or do you have a technical concern? I do not have a technical concern with the text. > >>> Maybe the last bullet of section 15 (must be able to send > >>> end-of-candidates) should come earlier in the list, in particular before the > >>> requirement for nonduplication and in-order. > >> > >> That's an unordered list ('symbols' not 'numbers' in the XML). The > >> bullets are ordered by the appearance of those points in the text. I > >> have no particular allegiance to that order - but if you believe in the > >> serial-position effect then first or last is best. :-) > > > > I was just going off the principle that concepts should be > > (re)introduced before they are (re)used, not any particular sense of > > ordering or priority. And it's not like this is the first time in > > the document that we're hearing about any of these, so do as you > > want :) > > OK. I'll look at that order again (perhaps it makes sense to order them > by importance or difficulty). Thanks! -Benjamin