From nobody Tue Nov 1 02:20:39 2016 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 B09551298D3 for ; Tue, 1 Nov 2016 02:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8kfUk__p1Nn for ; Tue, 1 Nov 2016 02:20:36 -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 F0DDD129583 for ; Tue, 1 Nov 2016 02:20:35 -0700 (PDT) X-AuditID: c1b4fb3a-18c55980000078c6-89-58185e61d173 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 5E.8C.30918.16E58185; Tue, 1 Nov 2016 10:20:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Tue, 1 Nov 2016 10:20:32 +0100 From: Christer Holmberg To: Bernard Aboba , "ice@ietf.org" Thread-Topic: [Ice] Trickle ICE Section 5 Thread-Index: AQHSM7tsxsK+3jE+y0+aFTl1RSyvq6DD3QcA Date: Tue, 1 Nov 2016 09:20:32 +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.6.9.160926 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D43E2CBC123EAchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7tG5SnESEQfdGZosN+/4zW3y7UOvA 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZTx8voet4JxJxb3/l1gbGDfrdjFyckgImEj8 P/SatYuRi0NIYB2jxMelO6GcxYwSp/9eZuti5OBgE7CQ6P6nDdIgIuAlse3ETyaQsLCAhsST +YUQYU2JOe93MEHYRhIbF09nAbFZBFQkTs1rZAaxeQWsJfY03AKrERIIkDg8bToriM0pECjx dv8pRhCbUUBM4vupNWA1zALiEreezGeCuFNAYsme88wQtqjEy8f/WEFOEBXQk1hzPwwirCjx 8dU+RojWBIkrT9ezQawVlDg58wnLBEaRWUimzkJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMH HgP1cgDZ1hLTzsciK1nAyLGKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzDODm75bbWD8eBz x0OMAhyMSjy8BTHiEUKsiWXFlbmHGCU4mJVEeCWiJCKEeFMSK6tSi/Lji0pzUosPMUpzsCiJ 85qtvB8uJJCeWJKanZpakFoEk2Xi4JRqYCzd9TJX18A0e85P9/T1OdwvkyNWZQhtq7R6eJ6L e8f/B86RwR+9ZB+IHSsM2SvqaZXM4fM2Maby0GM/y88rvf5wrNt4WuvlyUuTRCYqyq95Uf6u IHcPa5Hes+/VcToHf/oceqV0bFZI969/LxcIRKvNsLGwTJpSfcrDw6aQReSUbPiMZ+eDYpVY ijMSDbWYi4oTAQJZyHavAgAA Archived-At: Subject: Re: [Ice] Trickle ICE Section 5 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 09:20:38 -0000 --_000_D43E2CBC123EAchristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Regards, Christer From: Ice > on behalf of = Bernard Aboba > Date: Tuesday 1 November 2016 at 00:11 To: "ice@ietf.org" > Subject: [Ice] Trickle ICE Section 5 Receiving the Initial Offer When an agent receives an initial offer, it will first check if the offer or offerer indicates support for Trickle ICE as explained in Section 3. If this is not the case, the agent MUST process the offer according to Vanilla ICE procedures [rfc5245bis] or offer/answer processing rules [RFC3264] if no IC= E support is detected at all. If support for Trickle ICE is confirmed, an agent will automatically assume support for Vanilla ICE as well even if the support verification procedure in [rfc5245bis] indicates otherwise. Specifically, the rules from [rfc5245bis] would imply that ICE itself is not supported if the initial offer includes no candidates in the offer; however, such a conclusion is not warranted if the answerer can confirm that the offerer supports Trickle ICE and thus fallback to [RFC3264] is not necessary. If the offer does indicate support for Trickle ICE, the agent will determine its role, start gathering and prioritizing candidates; while doing so, it will also respond by sending its own answer, so that both agents can start forming check lists and begin connectivity checks. [BA] Most of this text seems more appropriate to the SIP draft than this on= e, since it references RFC 3264. --_000_D43E2CBC123EAchristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <94160B205CBE314E89B605633C13FCCF@ericsson.com> Content-Transfer-Encoding: quoted-printable
+1

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf of Bernard Aboba = <bernard.aboba@gmail.com&= gt;
Date: Tuesday 1 November 2016 at 00= :11
To: "ice@ietf.org" <ice@ietf.= org>
Subject: [Ice] Trickle ICE Section = 5

Receiving the Initial Offer


   When an agent receives an initial offer, it will first check if the
   offer or offerer indicates support for Trickle ICE as explained in
   Section 3.  If this is not the case, the agent MUST process the off=
er
   according to Vanilla ICE procedures [rfc5245bis] or offer/answ=
er
   processing rules [RFC3264] if no ICE support is detected at all.
   If support for Trickle ICE is confirme=
d, an agent will automatically
   assume support for Vanilla ICE as well even if the support

   verification procedure in [rfc52=
45bis] indicates otherwise.
   Specifically, the rules from [rfc5245bis] would imply that ICE=
 itself
   is not supported if the initial offer includes no candidates in the
   offer; however, such a conclusion is not warranted if the answerer
   can confirm that the offerer supports Trickle ICE and thus fallback
   to [RFC3264=
] is not necessary.

   If the offer does indicate support for Trickle ICE, the agent will
   determine its role, start gathering and prioritizing candidates;
   while doing so, it will also respond by sending its own answer, so
   that both agents can start forming check lists and begin connectivity
   checks.

[BA] Most of this text seems more appropr=
iate to the SIP draft than this one, 
since it references RFC 3264.
--_000_D43E2CBC123EAchristerholmbergericssoncom_-- From nobody Tue Nov 1 05:50:10 2016 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 6767B12950B for ; Tue, 1 Nov 2016 05:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHwR61mvKIpR for ; Tue, 1 Nov 2016 05:50:06 -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 5FA8512945E for ; Tue, 1 Nov 2016 05:50:06 -0700 (PDT) X-AuditID: c1b4fb2d-5b107980000009f7-e5-58188f7c14d0 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 92.42.02551.C7F88185; Tue, 1 Nov 2016 13:50:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Tue, 1 Nov 2016 13:50:03 +0100 From: Christer Holmberg To: Bernard Aboba , Taylor Brandstetter Thread-Topic: [Ice] Contradiction regarding when an ICE agent is allowed to send media Thread-Index: AQHSGqTpVlbkPKJoTUy4xT3JYY1SFKCQ+UEAgDNQfYA= Date: Tue, 1 Nov 2016 12:50:02 +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.6.9.160926 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D43E5DBF12451christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7q25Nv0SEwf4eY4sN+/4zW1xe8ZDV 4tuFWgdmj52z7rJ7LNhU6rFkyU+mAOYoLpuU1JzMstQifbsErozZCz0KrtRVtHy/y9jAeC2r i5GDQ0LARGLDx/wuRi4OIYF1jBI3bj9ng3AWM0rcXnaAEaSITcBCovufdhcjJ4eIQITElLl/ mUHCzAKKEi/3qoGEhQXCJbr6LjLClHzvu8YEYVtJrFnxkQ3EZhFQkTixdyeYzStgLbHi+lxm iFX3GCVmbFnHApLgFAiUaNr/CqyIUUBM4vupNWCDmAXEJW49mQ9mSwgISCzZc54ZwhaVePn4 HyvIPaICehJr7odBvKUosbxfDqIzQeLTsjdMEGsFJU7OfMIygVF0FpKhs5CUzUJSBhHXkViw +xMbhK0tsWzha2YY+8yBx1C91hIPW68xIatZwMixilG0OLW4ODfdyFgvtSgzubg4P08vL7Vk EyMwHg9u+a27g3H1a8dDjAIcjEo8vAUx4hFCrIllxZW5hxglOJiVRHjX90lECPGmJFZWpRbl xxeV5qQWH2KU5mBREuc1W3k/XEggPbEkNTs1tSC1CCbLxMEp1cDoPZdp4/Go9xODL6ZNDZzq qScv9m/WycDqNiuhMob9ByN5w/us1la/3+3yvafi4XK2Jy9+KijNjdlZo/fOV4rTV2larhPP nxcOwvO3XOCcuba1xMbw5NmsPwqBH88H20VurHl6XK5r2qXNqS8inOud7bI19jyovLpe+uHp tf2Ll504ah1a8IlHiaU4I9FQi7moOBEASMvUKsMCAAA= Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Contradiction regarding when an ICE agent is allowed to send media X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 12:50:08 -0000 --_000_D43E5DBF12451christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bernard/Taylor, Would you be able to create a pull request with the suggested changes? Regards, Christer From: Ice > on behalf of = Bernard Aboba > Date: Friday 30 September 2016 at 02:20 To: Taylor Brandstetter > Cc: "ice@ietf.org" > Subject: Re: [Ice] Contradiction regarding when an ICE agent is allowed to = send media Looking over RFC 5245bis, there are a number of places in the text that sho= uld have been updated to allow passive-aggressive nomination that were inst= ead left as is. There are issues in Section 2.6 (which says "ICE will now = send media using this pair"), Section 3 (which defines "selected pair" as "= The candidate pair selected by ICE for sending and receiving media"), Secti= on 6.2.3.1 (which still mentions aggressive nomination!) and Section 9.1.1. A potential rewrite of Section 9.1.1 might look like this: "9.1.1. Procedures for Full Implementations A full implementation MUST NOT send media until it has a Valid list that contains a candidate pair for each component of that media stream. Once that happens, the agent MAY begin sending media packets. An agent will send media to the remote candidate (setting the destination address and port of the packet equal to that remote candidat= e), and will send it from the local candidate. When the local candidate is server or peer reflexive, media is originated from the base. Media sent from a relayed candidate is sent from the base through that TURN server, using procedures defined in [RFC5766]. If the local candidate is a relayed candidate, it is RECOMMENDED that an agent create a channel on the TURN server towards the remote candidate. This is done using the procedures for channel creation as defined in Section 11 of [RFC5766]." If those changes are made, it looks to me like the rest of the text from Se= ction 9.1.1 could be deleted: "The selected pair for a component of a media stream is: o empty if the state of the check list for that media stream is Running, and there is no previous selected pair for that component due to an ICE restart o equal to the previous selected pair for a component of a media stream if the state of the check list for that media stream is Running, and there was a previous selected pair for that component due to an ICE restart o equal to the highest-priority nominated pair for that component in the valid list if the state of the check list is Completed" On Thu, Sep 29, 2016 at 3:57 PM, Bernard Aboba > wrote: There is a contradiction in draft-ietf-rfc5245bis because aggressive nomina= tion was removed without making all the required changes to regular nominat= ion to allow sending of media before a pair is nominated. So the text in dr= aft-ietf-rfc5245bis Section 9.1.1 was carried over verbatim from RFC 5245 S= ection 11.1.1 instead of being adapted. IMHO, the requirement for sending = media in draft-ietf-rfc5245bis Section 9.1.2 (which currently only applies = to a lite implementation) should be applied to all implementations (lite or= full): A lite implementation MUST NOT send media until it has a Valid list that contains a candidate pair for each component of that media stream. Once that happens, the agent MAY begin sending media packets. Making this change should not impact an RFC 5245-compliant implementation s= ince RFC 5245 Section 11.2 says: ICE implementations MUST be prepared to receive media on each component on any candidates provided for that component in the most recent offer/answer exchange (in the case of RTP, this would include both RTP and RTCP if candidates were provided for both). On Thu, Sep 29, 2016 at 12:35 PM, Taylor Brandstetter > wrote: Section 6.2.1.1 of draft-ietf-ice-rfc5245bis-04 states: Before the agent has received Binding responses associated with the [nominated] candidiate pair, the agent can send media o= n any candidiate for which it has received Binding responses. To me, this would imply that until a pair is nominated, the ICE agent can s= end media on any pair with a local candidate that has received a binding re= sponse. However, section 9.1.1 states: If the selected pair for at least one component of a media stream is empty, an agent MUST NOT send media for any component of that media stream. And the selected pair is empty until a pair is nominated, which means you c= an't send media until a pair is nominated. The examples at the end of Secti= on 12 seems to reiterate this. So, which is it? I was under the impression that aggressive nomination was = being removed because you could accomplish essentially the same thing with = regular nomination, by sending media before a pair is nominated (the so cal= led "passive aggressive" nomination). But that doesn't seem to be allowed b= y section 9.1.1. _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_D43E5DBF12451christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Bernard/Taylor,

Would you be able to create a pull request with the suggested changes?=

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf of Bernard Aboba = <bernard.aboba@gmail.com&= gt;
Date: Friday 30 September 2016 at 0= 2:20
To: Taylor Brandstetter <deadbeef@google.com>
Cc: "ice@ietf.org" <ice@ietf.= org>
Subject: Re: [Ice] Contradiction re= garding when an ICE agent is allowed to send media

Looking over RFC 5245bis, there are a number of places in the text tha= t should have been updated to allow passive-aggressive nomination that were= instead left as is.  There are issues in Section 2.6 (which says &quo= t;ICE will now send media using this pair"), Section 3 (which defines "selected pair" as "The candidate = pair selected by ICE for sending and receiving media"), Section 6.2.3.= 1 (which still mentions aggressive nomination!) and Section 9.1.1. 

A potential rewrite of Section 9.1.1 might look like this: 

"9.1.1.  Procedures for Full Implementations

   A full implementation MUST NOT send media until it has a = Valid list
   that contains a candidate pair for each component of that= media
   stream.  Once that happens, the agent MAY begin send= ing media
   packets.

   An agent will send media to the remote candidate (setting= the 
   destination address and port of the packet equal to that = remote candidate), 
   and will send it from the local candidate.  When the= local candidate is
   server or peer reflexive, media is originated from the ba= se.  Media
   sent from a relayed candidate is sent from the base throu= gh that TURN
   server, using procedures defined in [RFC5766].

   If the local candidate is a relayed candidate, it is RECO= MMENDED that
   an agent create a channel on the TURN server towards the = remote
   candidate.  This is done using the procedures for ch= annel creation as
   defined in Section 11 of [RFC5766]."

If those changes are made, it looks to me like the rest of the text fr= om Section 9.1.1 could be deleted:

   "The selected pair for a component of a media stream= is:

   o  empty if the state of the check list for that med= ia stream is
      Running, and there is no previous selected pair f= or that component
      due to an ICE restart

   o  equal to the previous selected pair for a compone= nt of a media
      stream if the state of the check list for that me= dia stream is
      Running, and there was a previous selected pair f= or that component
      due to an ICE restart

   o  equal to the highest-priority nominated pair for = that component in
      the valid list if the state of the check list is = Completed"

On Thu, Sep 29, 2016 at 3:57 PM, Bernard Aboba <= span dir=3D"ltr"> <bernard.ab= oba@gmail.com> wrote:
There is a contradiction in draft-ietf-rfc5245bis because = aggressive nomination was removed without making all the required changes t= o regular nomination to allow sending of media before a pair is nominated. = So the text in draft-ietf-rfc5245bis Section 9.1.1 was carried over verbatim from RFC 5245 Section 11.1.1 instead of be= ing adapted.  IMHO, the requirement for sending media in draft-ie= tf-rfc5245bis Section 9.1.2 (which currently only applies to a li= te implementation) should be applied to all implementations (lite or full):  

   A lite implementation MUST NOT send media until it has a Valid=
 list
   that contains a candidate pair for each component of that media
   stream.  Once that happens, the agent MAY begin sending media
   packets.

Making this change should not impact an RFC 5245-compliant implementat= ion since RFC 5245 Section 11.2 says: 

   ICE implementations MUST be prepared to receive media on each
   component on any candidates provided for that component in the most
   recent offer/answer exchange (in the case of RTP, this would include
   both RTP and RTCP if candidates were provided for both).





On Thu, Sep 29, 2016 at 12:35 P= M, Taylor Brandstetter <deadbeef@google.com> wrote:
Section 6.2.1.1 = of draft-ietf-ice-rfc5245bis-04 states: 

Before the agent has re=
ceived Binding responses
associated with the [nominated] candidiate pair, the agent can send media o=
n any
candidiate for which it has received Binding responses.

To me, this would imply that= until a pair is nominated, the ICE agent can send media on any pair with a= local candidate that has received a binding response.

However, section 9.1.1 state= s:

If the selected pair for at least one component of a media stream is
empty, an agent MUST NOT send media for any component of that media
stream.

And the selected pair is empty until a pair is nominated, which means = you can't send media until a pair is nominated. The examples at the end of = Section 12 seems to reiterate this.

So, which is it? I was under the impression that aggressive nomination= was being removed because you could accomplish essentially the same thing = with regular nomination, by sending media before a pair is nominated (the s= o called "passive aggressive" nomination). But that doesn't seem to be allowed by section 9.1.1. 

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



--_000_D43E5DBF12451christerholmbergericssoncom_-- From nobody Tue Nov 1 09:27:53 2016 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 9ADA41294D1 for ; Tue, 1 Nov 2016 09:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pakF7vBJE827 for ; Tue, 1 Nov 2016 09:27:47 -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 9AA651294BF for ; Tue, 1 Nov 2016 09:27:46 -0700 (PDT) X-AuditID: c1b4fb30-b87ff70000000cb2-c2-5818c27f5a1d Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id B2.8A.03250.F72C8185; Tue, 1 Nov 2016 17:27:44 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.241]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0319.002; Tue, 1 Nov 2016 17:27:43 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: ICE WG Thread-Topic: ICE WG draft agenda for IETF #97 Thread-Index: AQHSNFzeEuqypX34jEC/3YVYpPPuaA== Date: Tue, 1 Nov 2016 16:27:42 +0000 Message-ID: <9233D31B-EFB1-4C8B-9803-8EE47F1CD25B@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5BDE697DEE6F844A815280A56504C192@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7h27DIYkIgwNPbSy+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DKmNw7j6lgDkfF9bWtjA2Mp9i6GDk5JARMJP7+ fcHaxcjFISSwjlGiu/UWlLOYUaJnxlcmkCo2AXuJyWs+MoLYIgKSEi1/NrKC2MwCmhL3Ty5k B7GFgew5966yQtToSTTNbGbuYuQAs5c2+ICEWQRUJH4fvAo2hhdo5JFHt8HKGQXEJL6fWsME MVJc4taT+UwQxwlILNlznhnCFpV4+fgfK4StJLFi+yVGiHo9iRtTp7BB2NYSb2+vg5qjLbFs 4WtmiF2CEidnPmGZwCgyC8mKWUjaZyFpn4WkfRaS9gWMrKsYRYtTi5Ny042M9FKLMpOLi/Pz 9PJSSzYxAmPk4JbfBjsYXz53PMQowMGoxMP7Ya1EhBBrYllxZe4hRgkOZiURXteDQCHelMTK qtSi/Pii0pzU4kOM0hwsSuK8ZivvhwsJpCeWpGanphakFsFkmTg4pRoYRaOqvbWdAr/V60+3 tZFbXnpkwaxftxhFp2hxTDp75lzfWfmdG1XnHI09yij0dwLPUbdNH7WCjnlWpmqZhzY0zJWa Nu8ge3/SBk81qz3P75WbrSr16zJy7TthuNxz7q3KJfcK2ut41q6M+PJBhfdd8bdCgyUJsvN/ zk6wCk9NLb99nG3lgV83lViKMxINtZiLihMBRP/uho0CAAA= Archived-At: Cc: Peter Thatcher Subject: [Ice] ICE WG draft agenda for IETF #97 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 16:27:48 -0000 Hi all, Draft agenda for the ICE WG meeting at the IETF #97 is available here: https://www.ietf.org/proceedings/97/agenda/agenda-97-ice-00 Please have a look at the agenda and let us know if you have any questions = or comments. In particular note that we have only a short slot for conclusion on Ta-disc= ussion for the ICE-bis draft. The authors believe there are no substantial = open issues requiring face-to-face discussion left for the draft (i.e., the= remaining issues are minor and/or editorial). If you believe there are ope= n issues, or you discover new ones that require discussion when reading the= draft, please raise the issues on list as soon as possible. Also, we have reserved time at the end of the session to discuss the way fo= rward with ICE WG after our WG items are done (which is hopefully very soon= ). Think about that while preparing for the meeting, and if you want to sup= port your points with slides on the topic, let us know as soon as possible. Thanks, Ari & Peter (ICE WG co-chairs)= From nobody Wed Nov 2 03:08:55 2016 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 1DE36129A6C; Wed, 2 Nov 2016 03:08:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147808133311.24126.15765271660818591137.idtracker@ietfa.amsl.com> Date: Wed, 02 Nov 2016 03:08:53 -0700 Archived-At: Cc: ice-chairs@ietf.org, ari.keranen@ericsson.com, draft-ietf-ice-dualstack-fairness@ietf.org, ice@ietf.org Subject: [Ice] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-ice-dualstack-fairness-06=3A_=28with_COMMENT=29?= X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 10:08:53 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-ice-dualstack-fairness-06: 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-dualstack-fairness/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my comments and also not talking about fairness anymore. There are some more concrete recommendations now but some are still vague. I would still like to proposed the following addition to the intro: OLD: "To avoid such user noticeable delays when either IPv6 or IPv4 path is broken or excessively slow, this specification encourages intermingling the different address families when connectivity checks are performed. This will lead to more sustained dual-stack IPv4/IPv6 deployment as users will no longer have an incentive to disable IPv6. The cost is a small penalty to the address type that otherwise would have been prioritized." NEW: "To avoid user noticeable delays when either IPv6 or IPv4 path is broken or excessively slow, this specification encourages intermingling the different address families when connectivity checks are performed. This will lead to more sustained dual-stack IPv4/IPv6 deployment as users will no longer have an incentive to disable IPv6. The cost is a small penalty to the address type that otherwise would have been prioritized. Further this document recommends to keep track of previous known connectivity problem and assign a lower priority to those addresses." Maybe even add: "Tracking connectivity is a question on its own and out of scope for this document." From nobody Wed Nov 2 04:58:32 2016 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 4A4AD1295B2 for ; Wed, 2 Nov 2016 04:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8cVRL3dHMAS for ; Wed, 2 Nov 2016 04:58:29 -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 28BAC129505 for ; Wed, 2 Nov 2016 04:58:29 -0700 (PDT) X-AuditID: c1b4fb2d-5b107980000009f7-b8-5819d4e333d3 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 20.51.02551.3E4D9185; Wed, 2 Nov 2016 12:58:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0319.002; Wed, 2 Nov 2016 12:58:20 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: Definition of "base" Thread-Index: AQHSNQBmCLSA9AWB8E65eAM760MCDg== Date: Wed, 2 Nov 2016 11:58:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D43FA34112654christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7hO7jK5IRBr+OK1p8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6MD7ujCg7aVby/tZm1gfGtSRcjJ4eEgInEqgNzGbsYuTiEBNYx Svy/NJMFwlnMKDG7oYu9i5GDg03AQqL7nzZIg4iAosTMlmfMILawgJrE45mP2CDi2hIrJ7ew QNh6Eo3be8FqWARUJB5suscIYvMKWEusWH6YFcRmFBCT+H5qDROIzSwgLnHryXwmiIMEJJbs Oc8MYYtKvHz8jxXkBFGgmWvuh0GEFSV2nm1nhmhNkHj3+wU7xHhBiZMzn7BMYBSahWTqLCRl s5CUQcQNJN6fm88MYWtLLFv4GsrWl9j45SwjhG0tsW1jFxOymgWMHKsYRYtTi4tz042M9VKL MpOLi/Pz9PJSSzYxAqPk4JbfujsYV792PMQowMGoxMP7Ya1EhBBrYllxZe4hRgkOZiUR3uMX JSOEeFMSK6tSi/Lji0pzUosPMUpzsCiJ85qtvB8uJJCeWJKanZpakFoEk2Xi4JRqYJxRcPBy 4eM3y9rnO67KYGQ8EaPr1T/7TjNL/71mN23zo1nCBp7s1eV3u+42yM7KPnni1939i/zn/J0U UVm50eT7QV9PlpkJ11akKsfP+rsyru2+VUVuV/m9VxarRSu2tO2Y2CqwjW9hUcKn+LeF4RON RY83tGm03zPzPLxwX9eCb14rVp+NEFNiKc5INNRiLipOBAB/lWtqjgIAAA== Archived-At: Subject: [Ice] 5245bis: Definition of "base" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 11:58:31 -0000 --_000_D43FA34112654christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Section 2.1 of draft-5245-bis says: "We call the host candidate associated with a given server reflexive can= didate the BASE.=94 "Note: "Base" refers to the address an agent sends from for a particular candidate. Thus, as a degenerate case host candidates also have a base, but it's the same as the host candidate.=94 Q1: The note seems to contradict with the text above, which says a base is = only associated with a server reflexive candidate. Q2: The note is unclear on whether =93address=94 also includes the port. I = assume it does, in which case I think it should be =93transport address=94. "If the agent is not behind a NAT, then the base candidate will be the s= ame as the server reflexive candidate and the server reflexive candidate is redundant and = will be eliminated." =93Base candidate=94 is not defined anywhere (and, afaik, not used elsewher= e in the document). I assume we should say either =93base=94 or =93host can= didate=94. Section 3 says: "Base: The base of a server reflexive candidate is the host candidat= e from which it was derived. A host candidate is also said to have a base, equal to that candidate itself. Similarly, the base of a relayed candidate is that candidate itself." Q3: This text talks about =93derived=94, which is different terminology tha= n elsewhere. Section 4.1.1 says: "The base of a candidate is the candidate that an agent must send from w= hen using that candidate. Q4: There are now 3 different places defining =93base=94, all with differen= t terminology. In SUGGESTION: We should only define =93base=94 once, in section 3. Regards, Christer --_000_D43FA34112654christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Section 2.1 of draft-5245-bis says:

   "We call the host candidat=
e associated with a given server reflexive candidate
   the BASE.=94
      "Note=
: "Base" refers to the address an agent sends from for a
      particular candidate.  Thus, as a degenerate case host candidates
      also have a base, but it's the same as the host candidate.=94
Q1: The note seems to contradict wi=
th the text above, which says a base is only associated with a server refle=
xive candidate.

Q2: The note is unclear on whether =93address=94 also includes the port=
. I assume it does, in which case I think it should be =93transport address=
=94.

   "If the agent is not behin=
d a NAT, then the base candidate will be the same as the server
   reflexive candidate and the server reflexive candidate is redundant and =
will be eliminated."
=93Base ca=
ndidate=94 is not defined anywhere (and, afaik, not used elsewhere in the d=
ocument). I assume we should say either =93base=94 or =93host candidate=94.=



<=
div style=3D"font-family: Calibri, sans-serif; orphans: auto; white-space: =
normal; widows: auto;">Section 3 says:

      &=
quot;Base:  The base of a server reflexive candidate is the host candidate
      from which it was derived.  A host candidate is also said to have
      a base, equal to that candidate itself.  Similarly, the base of a
      relayed candidate is that candidate itself."
Q3: This text talks about =93derived=94, which is different terminolo=
gy than elsewhere.

=
Section  4.1.1 says:

   "The base of a candidate is the candidate that an age=
nt must send from when using that candidate.
Q4: There are now 3 different places defining =
=93base=94, all with different terminology. In 

SUGGESTION: We should only define =
=93base=94 once, in section 3.

Regards,

Christer
--_000_D43FA34112654christerholmbergericssoncom_-- From nobody Wed Nov 2 07:50:49 2016 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 3B354129681; Wed, 2 Nov 2016 07:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 Xe4Ci33HBWXt; Wed, 2 Nov 2016 07:50:43 -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 E6C46129656; Wed, 2 Nov 2016 07:50:39 -0700 (PDT) Received: from [10.0.1.21] (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 uA2EoYEn054486 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 Nov 2016 09:50:36 -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.21] From: "Ben Campbell" To: "Mirja Kuehlewind" Date: Wed, 02 Nov 2016 09:50:36 -0500 Message-ID: In-Reply-To: <147808133311.24126.15765271660818591137.idtracker@ietfa.amsl.com> References: <147808133311.24126.15765271660818591137.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: ari.keranen@ericsson.com, ice@ietf.org, ice-chairs@ietf.org, The IESG , draft-ietf-ice-dualstack-fairness@ietf.org Subject: Re: [Ice] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-ice-dualstack-fairness-06=3A_=28with_COMMENT=29?= X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 14:50:47 -0000 On 2 Nov 2016, at 5:08, Mirja Kuehlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-ice-dualstack-fairness-06: 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-dualstack-fairness/ > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for addressing my comments and also not talking about fairness > anymore. There are some more concrete recommendations now but some are > still vague. > > I would still like to proposed the following addition to the intro: > > OLD: > "To avoid such user noticeable delays when either IPv6 or IPv4 path is > broken or excessively slow, this specification encourages > intermingling the different address families when connectivity > checks > are performed. This will lead to more sustained dual-stack > IPv4/IPv6 > deployment as users will no longer have an incentive to disable > IPv6. > The cost is a small penalty to the address type that otherwise > would > have been prioritized." > > NEW: > "To avoid user noticeable delays when either IPv6 or IPv4 path is > broken or excessively slow, this specification encourages > intermingling the different address families when connectivity > checks > are performed. This will lead to more sustained dual-stack > IPv4/IPv6 > deployment as users will no longer have an incentive to disable > IPv6. > The cost is a small penalty to the address type that otherwise > would > have been prioritized. Further this document recommends to keep > track of previous known connectivity problem and assign a lower > priority to those addresses." > > Maybe even add: > "Tracking connectivity is a question on its own and out of scope for > this document." This seems reasonable. I might suggest the last sentence be something to the effect of: "Specific mechanisms and rules for tracking connectivity issues are out of scope for this document" Thanks! Ben. From nobody Wed Nov 2 12:57:12 2016 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 E840212989C for ; Wed, 2 Nov 2016 12:57:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147811662894.24078.15068658030132276033.idtracker@ietfa.amsl.com> Date: Wed, 02 Nov 2016 12:57:08 -0700 From: IETF Secretariat Archived-At: Subject: [Ice] Milestones changed for ice WG X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 19:57:09 -0000 Changed milestone "Submit Dual-stack Fairness with ICE as Proposed Standard ", resolved as "Done". Changed milestone "Submit a revision of ICE (RFC 5245) as Proposed Standard (draft-ietf-mmusic-ice-sip-sdp remains in MMUSIC) ", set due date to December 2016 from April 2016. Changed milestone "Submit Trickle ICE as Proposed Standard (draft-ietf-mmusic-trickle-ice-sip remains in MMUSIC)", set due date to January 2017 from January 2016. URL: https://datatracker.ietf.org/wg/ice/charter/ From nobody Thu Nov 3 04:41:57 2016 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 809471294DD for ; Thu, 3 Nov 2016 04:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ry2CY9WVEId7 for ; Thu, 3 Nov 2016 04:41:55 -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 B125C1299CE for ; Thu, 3 Nov 2016 04:41:54 -0700 (PDT) X-AuditID: c1b4fb30-b87ff70000000cb2-77-581b22802eed Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 08.B6.03250.0822B185; Thu, 3 Nov 2016 12:41:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Thu, 3 Nov 2016 12:41:52 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: [Ice] 5245bis: Definition of "base" Thread-Index: AQHSNcdEW+DxktTIN0eLjsqrPhLvOg== Date: Thu, 3 Nov 2016 11:41:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D440F06B12811christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7k26jknSEwfQFnBbfLtQ6MHosWfKT KYAxissmJTUnsyy1SN8ugStj84o9LAXrgioWPOpia2Bsduti5OSQEDCRuDTnMFsXIxeHkMA6 RonZO88yQjiLGSW+bm5i7WLk4GATsJDo/qcN0iAioCgxs+UZM4gtLGAg8XzjPTaIuKHE6dUT oWw9ieXLNrCD2CwCKhKn7y0Bs3kFrCVunLzEAmIzCohJfD+1hgnEZhYQl7j1ZD4TxEECEkv2 nGeGsEUlXj7+B3aCKNDMNffDIMKKEu1PGxghWhMkTk45zAoxXlDi5MwnLBMYhWYhmToLSdks JGUQcQOJ9+fmM0PY2hLLFr6GsvUlNn45ywhhW0tM+bKZBVnNAkaOVYyixanFSbnpRkZ6qUWZ ycXF+Xl6eaklmxiBcXJwy2+DHYwvnzseYhTgYFTi4S34LxkhxJpYVlyZe4hRgoNZSYRXXlE6 Qog3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQZG910H/p+S 014Y81Q3gSO2tzlqtrRl6ub2T6u0eF5MvGJim3X7wNninPqORAYb+dz1OS0KPjleQbueFRjz 1rydtlpq/8EcK8cYFndzhx+WHiminNtr14Xt8PHesTux+U9ht9TVrotXTZ49LOmqENv6zF5v RTvHw+zo/0f2Tyx/9LYs5LzZsjtKLMUZiYZazEXFiQC35XV5jwIAAA== Archived-At: Subject: Re: [Ice] 5245bis: Definition of "base" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 11:41:56 -0000 --_000_D440F06B12811christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Suggestion for modified base definition: "Base: The transport address that an agent sends from for a particular cand= idate. For host-, server reflexive- and peer reflexive candidates the base = is the same as the host candidate. For relayed candidates the base is the s= ame as the relayed candidate.=94 With that, we=92d remove all other sentences describing what a base is. Regards, Christer From: Ice > on behalf of = Christer Holmberg > Date: Wednesday 2 November 2016 at 14:58 To: "ice@ietf.org" > Subject: [Ice] 5245bis: Definition of "base" Hi, Section 2.1 of draft-5245-bis says: "We call the host candidate associated with a given server reflexive can= didate the BASE.=94 "Note: "Base" refers to the address an agent sends from for a particular candidate. Thus, as a degenerate case host candidates also have a base, but it's the same as the host candidate.=94 Q1: The note seems to contradict with the text above, which says a base is = only associated with a server reflexive candidate. Q2: The note is unclear on whether =93address=94 also includes the port. I = assume it does, in which case I think it should be =93transport address=94. "If the agent is not behind a NAT, then the base candidate will be the s= ame as the server reflexive candidate and the server reflexive candidate is redundant and = will be eliminated." =93Base candidate=94 is not defined anywhere (and, afaik, not used elsewher= e in the document). I assume we should say either =93base=94 or =93host can= didate=94. Section 3 says: "Base: The base of a server reflexive candidate is the host candidat= e from which it was derived. A host candidate is also said to have a base, equal to that candidate itself. Similarly, the base of a relayed candidate is that candidate itself." Q3: This text talks about =93derived=94, which is different terminology tha= n elsewhere. Section 4.1.1 says: "The base of a candidate is the candidate that an agent must send from w= hen using that candidate. Q4: There are now 3 different places defining =93base=94, all with differen= t terminology. In SUGGESTION: We should only define =93base=94 once, in section 3. Regards, Christer --_000_D440F06B12811christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <379BCD70CFAAF84EB291062880FE80FD@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Suggestion for modified base definition:

"Base: The transport address that an agent sends from for a parti= cular candidate. For host-, server reflexive- and peer reflexive candidates= the base is the same as the host candidate. For relayed candidates the bas= e is the same as the relayed candidate.=94

With that, we=92d remove all other sentences describing what a base is= .

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf of Christer Holmb= erg <christer.holmberg= @ericsson.com>
Date: Wednesday 2 November 2016 at = 14:58
To: "ice@ietf.org" <ice@ietf.= org>
Subject: [Ice] 5245bis: Definition = of "base"

Hi,

Section 2.1 of draft-5245-bis says:

   "We call the host candidat=
e associated with a given server reflexive candidate
   the BASE.=94
      "Note=
: "Base" refers to the address an agent sends from for a
      particular candidate.  Thus, as a degenerate case host candidates
      also have a base, but it's the same as the host candidate.=94
Q1: The note seems to contradict wi=
th the text above, which says a base is only associated with a server refle=
xive candidate.

Q2: The note is unclear on whether =93address=94 also includes the port=
. I assume it does, in which case I think it should be =93transport address=
=94.

   "If the agent is not behin=
d a NAT, then the base candidate will be the same as the server
   reflexive candidate and the server reflexive candidate is redundant and =
will be eliminated."
=93Base ca=
ndidate=94 is not defined anywhere (and, afaik, not used elsewhere in the d=
ocument). I assume we should say either =93base=94 or =93host candidate=94.=



<=
div style=3D"font-family: Calibri, sans-serif; orphans: auto; white-space: =
normal; widows: auto;">Section 3 says:

      &=
quot;Base:  The base of a server reflexive candidate is the host candidate
      from which it was derived.  A host candidate is also said to have
      a base, equal to that candidate itself.  Similarly, the base of a
      relayed candidate is that candidate itself."
Q3: This text talks about =93derived=94, which is different terminolo=
gy than elsewhere.

=
Section  4.1.1 says:

   "The base of a candidate is the candidate that an age=
nt must send from when using that candidate.
Q4: There are now 3 different places defining =
=93base=94, all with different terminology. In 

SUGGESTION: We should only define =
=93base=94 once, in section 3.

Regards,

Christer
 --_000_D440F06B12811christerholmbergericssoncom_-- From nobody Thu Nov 3 06:28:00 2016 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 0F67D1295B6 for ; Thu, 3 Nov 2016 06:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSTj3eYuX8SM for ; Thu, 3 Nov 2016 06:27: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 603601295AD for ; Thu, 3 Nov 2016 06:27:52 -0700 (PDT) X-AuditID: c1b4fb2d-1c7ff700000009f7-d9-581b3b54c2e3 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by (Symantec Mail Security) with SMTP id 6D.A6.02551.45B3B185; Thu, 3 Nov 2016 14:27:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0319.002; Thu, 3 Nov 2016 14:27:48 +0100 From: Christer Holmberg To: Christer Holmberg , "ice@ietf.org" Thread-Topic: [Ice] 5245bis: Definition of "base" Thread-Index: AQHSNcdEW+DxktTIN0eLjsqrPhLvOqDHQEOQ Date: Thu, 3 Nov 2016 13:27:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE1AEAD@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE1AEADESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7nG6YtXSEwYPDahbfLtQ6MHosWfKT KYAxissmJTUnsyy1SN8ugSvjyJL0gvaaits/5BoYN+Z2MXJwSAiYSFxfot7FyMUhJLCOUWJi 1xNGCGcxo8THiU+YQYrYBCwkuv9pdzFycogIhEvceXmTDSQsLGAgcX9NMUTYUOL06olsELaR xI+N88BsFgEViR+HjzOC2LwCvhLn9p1iAbGFBKwl/nVOB6vhFLCR2PK1GcxmFBCT+H5qDROI zSwgLnHryXwwW0JAQGLJnvPMELaoxMvH/1ghbCWJxiVPWCHq8yXeTm9kgdglKHFy5hOWCYzC s5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tbg4N93IWC+1KDO5 uDg/Ty8vtWQTIzBCDm75rbuDcfVrx0OMAhyMSjy8Bf8lI4RYE8uKK3MPMUpwMCuJ8D60lI4Q 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgVF6it25guxX Xh8CbKef+raeIXP/90PGaXwsAfqtc6OlrCz71zcx7/72PvDBUgv+C+vmdV877mAT8oHLZv4b 69jd3cwpC2c7bfCs3/jSnNnhMX/AmUdB7ZyCrvuqec5/ndTq/rSFL7nca1skV7XGU/dPQhN/ 3THNKf5zQ+fplXNeNgIvgwS+FiuxFGckGmoxFxUnAgDebqGQjAIAAA== Archived-At: Subject: Re: [Ice] 5245bis: Definition of "base" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:27:59 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE1AEADESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, I'd prefer to call it "Candidate base". From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 03 November 2016 13:42 To: ice@ietf.org Subject: Re: [Ice] 5245bis: Definition of "base" Hi, Suggestion for modified base definition: "Base: The transport address that an agent sends from for a particular cand= idate. For host-, server reflexive- and peer reflexive candidates the base = is the same as the host candidate. For relayed candidates the base is the s= ame as the relayed candidate." With that, we'd remove all other sentences describing what a base is. Regards, Christer From: Ice > on behalf of = Christer Holmberg > Date: Wednesday 2 November 2016 at 14:58 To: "ice@ietf.org" > Subject: [Ice] 5245bis: Definition of "base" Hi, Section 2.1 of draft-5245-bis says: "We call the host candidate associated with a given server reflexive can= didate the BASE." "Note: "Base" refers to the address an agent sends from for a particular candidate. Thus, as a degenerate case host candidates also have a base, but it's the same as the host candidate." Q1: The note seems to contradict with the text above, which says a base is = only associated with a server reflexive candidate. Q2: The note is unclear on whether "address" also includes the port. I assu= me it does, in which case I think it should be "transport address". "If the agent is not behind a NAT, then the base candidate will be the s= ame as the server reflexive candidate and the server reflexive candidate is redundant and = will be eliminated." "Base candidate" is not defined anywhere (and, afaik, not used elsewhere in= the document). I assume we should say either "base" or "host candidate". Section 3 says: "Base: The base of a server reflexive candidate is the host candidat= e from which it was derived. A host candidate is also said to have a base, equal to that candidate itself. Similarly, the base of a relayed candidate is that candidate itself." Q3: This text talks about "derived", which is different terminology than el= sewhere. Section 4.1.1 says: "The base of a candidate is the candidate that an agent must send from w= hen using that candidate. Q4: There are now 3 different places defining "base", all with different te= rminology. In SUGGESTION: We should only define "base" once, in section 3. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4BE1AEADESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually, = I’d prefer to call it “Candidate base”.=

 

From: = Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 03 November 2016 13:42
To: ice@ietf.org
Subject: Re: [Ice] 5245bis: Definition of "base"

 

Hi,

 

Suggestion for modified base definition= :

 

"Base: The transport address that = an agent sends from for a particular candidate. For host-, server reflexive= - and peer reflexive candidates the base is the same as the host candidate. For relayed candidates the base is the same as the = relayed candidate.”

 

With that, we’d remove all other = sentences describing what a base is.

 

Regards,

 

Christer

 

From: Ice <ice= -bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com><= br> Date: Wednesday 2 November 2016 at 14:58
To: "ice@ietf.org" <= ;ice@ietf.org>
Subject: [Ice] 5245bis: Definition of "base"

 

Hi,

 

Section 2.1 of draft-5245-bis says:

 

  =
 "We call the host candidate associated with a given server reflexive =
candidate
   the BASE.”
  =
    "Note: "Base" refers to the address an ag=
ent sends from for a
      particular =
candidate.  Thus, as a degenerate case host candidates
      also have a=
 base, but it's the same as the host candidate.”



Q1: The note seems to contradict with the text above, which says a base is=
 only associated with a server reflexive candidate.






 






Q2: The note is unclear on whether “address” also includes the=
 port. I assume it does, in which case I think it should be “transpor=
t address”.






 




  =
 "If the agent is not behind a NAT, then the base candidate will be th=
e same as the server
   reflexive candidate and the s=
erver reflexive candidate is redundant and will be eliminated."
“Base candidate” is not defined anywhere (and, afaik, not used=
 elsewhere in the document). I assume we should say either “base̶=
1; or “host candidate”.
 
 
Section 3 says:
 
      "Base:=
  The base of a server reflexive candidate is the host candidate<=
/o:p>
      from which =
it was derived.  A host candidate is also said to have
      a base, equ=
al to that candidate itself.  Similarly, the base of a
      relayed can=
didate is that candidate itself."
Q3: This text talks about “derived”, which is different termin=
ology than elsewhere.
 
 
Section  4.1.1 says:
 
   "The base of a candidate=
 is the candidate that an agent must send from when using that candidate.
Q4: There are now 3 different places defining “base”, all with=
 different terminology. In 
 
SUGGESTION: We should only define “base” once, in section 3.
 
Regards,
 
Christer
--_000_7594FB04B1934943A5C02806D1A2204B4BE1AEADESESSMB209erics_-- From nobody Thu Nov 3 08:46:34 2016 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 E1D0A129A88 for ; Thu, 3 Nov 2016 08:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz_seUvKz5cX for ; Thu, 3 Nov 2016 08:46:31 -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 1B3E7129A9C for ; Thu, 3 Nov 2016 08:46:20 -0700 (PDT) X-AuditID: c1b4fb2d-5b107980000009f7-b8-581b5bcbc805 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 08.B3.02551.BCB5B185; Thu, 3 Nov 2016 16:46:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0319.002; Thu, 3 Nov 2016 16:46:15 +0100 From: Christer Holmberg To: Nils Ohlmeier Thread-Topic: [Ice] Triggered checks are missing peer reflexive Thread-Index: AQHSBVlPEOYY7CCEV0C+dqegwGP6+aCBttwAgBacroCABbZ6AIApvL1A Date: Thu, 3 Nov 2016 15:46:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE1C36A@ESESSMB209.ericsson.se> References: <37F6A130-E058-4683-B566-AD250032AB3F@mozilla.com> <78810E33-18A5-4C8D-89F0-A4B943C4520F@mozilla.com> <85414E3B-744A-48A2-BA6C-DC96E677484D@mozilla.com> In-Reply-To: <85414E3B-744A-48A2-BA6C-DC96E677484D@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2K7h+7paOkIgzVd8hbfLtRaXJ83mdGB yWPJkp9MHn0HulgDmKK4bFJSczLLUov07RK4Mta+2sVccMqqov3mD/YGxg7LLkZODgkBE4mJ HX1sILaQwDpGiVmvA7sYuYDsxYwS7/9eYuli5OBgE7CQ6P6nDWKKCGhKnNjIB2IyCyhKvNyr BtIpLGAnMXPdVrApIgL2Emd2dbBD2G4S32fPAouzCKhIXDjTwgRi8wr4SqxdOYENYtMtRon1 b44ygyQ4gZq/7uwBa2AUEJP4fmoNWAOzgLjErSfzmSBOFpBYsuc8M4QtKvHy8T9WCFtJYu3h 7SwQt2lKrN+lD9GqKDGl+yE7xF5BiZMzn7BMYBSdhWTqLISOWUg6ZiHpWMDIsopRtDi1uDg3 3chYL7UoM7m4OD9PLy+1ZBMjMDoObvmtu4Nx9WvHQ4wCHIxKPLwfAqQjhFgTy4orcw8xSnAw K4nwtkUAhXhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamCc eObhgc+nLM9dF11nHHbpZrWb6JHSrrSnYesfT3naPj381RfVSKZwTbtrT+TeCc/o1S4SXLpg oZOPWZ/4j96pYv1H6kNq/s28qNZ2nOHK7dZ7HY153aZcC546rK1QmXCrYfWqmsNCU//ZlGQc C18cayVX0Mc2yefiEuW8szIyFz4suOBXIfxdiaU4I9FQi7moOBEAW5z/7ooCAAA= Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Triggered checks are missing peer reflexive X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 15:46:34 -0000 SGksDQoNCj5UaGFua3MgZm9yIHlvdXIgcmVwbHkuIEkgZG9u4oCZdCB0aGluayB0aGF0IHRoZXJl IGlzIGFueSBwcnVuaW5nIGhhcHBlbmluZyB3aGVuIHlvdSBkaXNjb3ZlciBwZWVyIHJlZmxleGl2 ZSANCj5jYW5kaWRhdGVzICh5b3UgYXJlIHN1cHBvc2UgdG8gY2hlY2sgZm9yIGFuIGV4aXN0aW5n IGVxdWFsIHBhaXIsIG5vdCBzdXJlIGlmIHlvdSBjb25zaWRlciB0aGF0IGFzIHBydW5pbmcgYXQg dGhhdCBzdGVwKS4NCj4NCj5CdXQgdGhlIHJlcGVhdGVkIHJlYWRpbmcgb2YgdGhlIHNlY3Rpb25z IGFib3V0IGRpc2NvdmVyaW5nIHBlZXIgcmVmbGV4aXZlIGNhbmRpZGF0ZXMgbWFkZSBtZSBhY3R1 YWxseSByZWFsaXplIHRoYXQgDQo+d2UgaGF2ZSBhIG5vdCBzdGFuZGFyZCBjb21wbGlhbnQgaW1w bGVtZW50YXRpb24gYW5kIHRoZXJlZm9yZSBteSB3aG9sZSBzY2VuYXJpbyBpcyB2b2lkIGlmIHlv dXIgaW1wbGVtZW50YXRpb24gDQo+YWRoZXJlcyB0byBlaXRoZXIgdmVyc2lvbiBvZiB0aGUgc3Rh bmRhcmQuIFNvIHBsZWFzZSBkaXMtcmVnYXJkIG15IGNvbmNlcm5zLg0KPg0KPlRoZSBvbmx5IGJp dCBsZWZ0IGlzIHRoYXQgaWYgaXQgdG9vayBtZSB0aGF0IG1hbnkgcmVhZGluZ3MgdG8gdW5kZXJz dGFuZCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBjaGVjayBsaXN0IGFuZCANCj50aGUgdmFs aWQgbGlzdCB3ZSBtaWdodCBiZSBpbnRlcmVzdGVkIGluIG1ha2luZyB0aGUgd29yZGluZyBpbiB0 aGF0IHNlY3Rpb25zIGEgbGl0dGxlIGJpdCBzdHJvbmdlciBvciBtb3JlIGNsZWFyIHRvIA0KPnBy ZXZlbnQgb3RoZXIgcmVhZGVycyBmcm9tIHdhc3RpbmcgbW9yZSB0aW1lIG9uIHRoaXMgbGlrZSBJ IGRpZC4NCg0KNTI0NWJpcyBpcyBhIGNvbXBsZXggZG9jdW1lbnQgdG8gcmVhZCwgc28gd2hhdGV2 ZXIgc3VnZ2VzdGlvbnMgeW91IGhhdmUgZm9yIG1ha2luZyB0aGluZ3MgbW9yZSBjbGVhciBJIGFt IGhhcHB5IHRvIGhlYXIgOikgDQoNCkZvciBleGFtcGxlLCByZWdhcmRpbmcgdGhlIGRpZmZlcmVu Y2UgYmV0d2VlbiBjaGVjayBsaXN0IGFuZCB2YWxpZCBsaXN0LCBwZXJoYXBzIHdlIGNvdWxkIGFk ZCBzb21lIG1vcmUgdGV4dCB0byB0aGUgZGVmaW5pdGlvbnMgaW4gc2VjdGlvbiAzPw0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQo+IE9uIE9jdCA0LCAyMDE2LCBhdCAwMjo1OCwgQ2hy aXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+ IA0KPiBIaSBOaWxzLA0KPiANCj4gU29ycnkgZm9yIHRoZSBsYXRlIHJlcGx5Lg0KPiANCj4gSWYg SSB1bmRlcnN0YW5kIHRoZSBpc3N1ZSBjb3JyZWN0bHksIHRoaXMgY291bGQgb25seSBoYXBwZW4g d2l0aCB0cmlja2xlLg0KPiBCZWNhdXNlLCBpbiBub3JtYWwgY2FzZXMgcHJ1bmluZyB3b3VsZCB0 YWtlIGNhcmUgb2YgaXQuDQo+IA0KPiBPcj8NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rl cg0KPiANCj4gT24gMjAvMDkvMTYgMDY6NDYsICJJY2Ugb24gYmVoYWxmIG9mIE5pbHMgT2hsbWVp ZXIiIA0KPiA8aWNlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG5vaGxtZWllckBtb3pp bGxhLmNvbT4gd3JvdGU6DQo+IA0KPj4gQWZ0ZXIgcmVhZGluZyB1cCBvbiBob3cgdGhlIGN1cnJl bnQgVHJpY2tsZSBJQ0UgZHJhZnQgcHJvcG9zZXMgdG8gDQo+PiBoYW5kbGUgcGVlciByZWZsZXhp dmUgY2FuZGlkYXRlcyBpdCBhcHBlYXJzIHRvIG1lIHRoYXQgbXkgc2NlbmFyaW8gDQo+PiBiZWxv dyBpcyByZWxldmFudCBmb3IgSUNFIDUyNDViaXMgaWYgdGhlcmUgaXMgbm8gU1RVTiBzZXJ2ZXIu DQo+PiBBbmQgaWYgdGhlcmUgaXMgYSBTVFVOIHNlcnZlciB0aGVuIGl0IHNob3VsZCBvbmx5IGhh cHBlbiBpZiBCIGhhcyANCj4+IHRyaWNrbGVkIGhpcyBwdWJsaWMgaG9zdCBjYW5kaWRhdGUgdG8g QSBhbHJlYWR5LiBBbmQgQSByZWNlaXZlcyBpdHMgDQo+PiBiaW5kaW5nIHJlc3BvbnNlIGZyb20g QiBiZWZvcmUgaXQgZGlzY292ZXJzIGhpcyBvd24gc2VydmVyIHJlZmxleGl2ZSANCj4+IGJ5IHJl Y2VpdmluZyBhIGJpbmRpbmcgcmVzcG9uc2UgZnJvbSB0aGUgU1RVTiBzZXJ2ZXIuDQo+PiANCj4+ IEV2ZW4gaWYgd2UgZG9uwrl0IGJvdGhlciBkbyB0cnkgdG8gb3B0aW1pemUgdGhlIHVzZWxlc3Mv cmVkdW5kYW50IA0KPj4gdHJpZ2dlciBjaGVjayBhd2F5IEkgdGhpbmsgd2Ugc2hvdWxkOg0KPj4g LSBpbmNsdWRlIHBlZXIgcmVmbGV4aXZlIGNhbmRpZGF0ZXMgaW50byB0aGUgcGFyYWdyYXBoIG9m IDUyNDUgd2hpY2ggDQo+PiB0YWxrcyBhYm91dCB0cmlnZ2VyIGNoZWNrcw0KPj4gLSBleHRlbmQg dGhlIHBhcmFncmFwaCBpbiB0aGUgdHJpY2tsZSBkcmFmdCB0byBub3Qgb25seSBtZW50aW9uIA0K Pj4gZGlzY292ZXJpbmcgcGVlciByZWZsZXhpdmUgY2FuZGlkYXRlcyB2aWEgU1RVTiBiaW5kaW5n IHJlcXVlc3QsIGJ1dCANCj4+IGFsc28gZnJvbSBiaW5kaW5nIHJlc3BvbnNlcy4NCj4+IA0KPj4g SSB3b3VsZCBhcHByZWNpYXRlIHNvbWUgZmVlZGJhY2sgb24gdGhpcyBiZWZvcmUgdHJ5aW5nIHRv IHByb3Bvc2UgDQo+PiBpbXByb3ZlZCB3b3JkaW5nIGZvciBib3RoIHNwZWNzLg0KPj4gDQo+PiBC ZXN0DQo+PiBOaWxzIE9obG1laWVyDQo+PiANCj4+PiBPbiBTZXAgMiwgMjAxNiwgYXQgMTM6MzQs IE5pbHMgT2hsbWVpZXIgPG5vaGxtZWllckBtb3ppbGxhLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4g SGVsbG8sDQo+Pj4gDQo+Pj4gSSBoYXZlIGlkZW50aWZpZWQgc29tZXRoaW5nIHdoaWNoIEkgd291 bGQgYmUgaW50ZXJlc3RlZCB0byBoZWFyIHRoZSANCj4+PiBvcGluaW9ucyBvZiB0aGUgSUNFIGV4 cGVydHMgYWJvdXQuDQo+Pj4gDQo+Pj4gSW4gUkZDIDUyNDUgKHNlY3Rpb24gNy4yLjEuNCkgYW5k IGFsc28gaW4gYmlzLTA0IChzZWN0aW9uIDYuMS4zLjEuNCkgDQo+Pj4gY2xhaW0gdGhlIGZvbGxv d2luZyByZWdhcmRpbmcgcmVjZWl2aW5nIHRyaWdnZXJlZCBjaGVja3M6DQo+Pj4gIFRoZSBsb2Nh bCBjYW5kaWRhdGUgd2lsbCBlaXRoZXIgYmUgYSBob3N0IGNhbmRpZGF0ZSAoLi4uKSBvciBhIA0K Pj4+IHJlbGF5ZWQgY2FuZGlkYXRlICjFoCkuIFRoZSBsb2NhbCBjYW5kaWRhdGUgY2FuIG5ldmVy IGJlIGEgc2VydmVyIA0KPj4+IHJlZmxleGl2ZSBjYW5kaWRhdGUuDQo+Pj4gDQo+Pj4gV2hpY2gg SSB0aGluayBpcyBtaXNzaW5nIHRoZSBjYXNlIHdoZXJlIHRoZSBsb2NhbCBjYW5kaWRhdGUgY2Fu IGFsc28gDQo+Pj4gYSBiZSBhIHBlZXIgcmVmbGV4aXZlLiBBbmQgdGhpcyBpcyBhY3R1YWxseSBj YXVzaW5nIHVubmVjZXNzYXJ5IA0KPj4+IGV4dHJhIGNoZWNrcyB0byBiZSBtYWRlLg0KPj4+IA0K Pj4+IENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW86DQo+Pj4gDQo+Pj4gLSBBIHNpdHMg YmVoaW5kIHN5bW1ldHJpYyBOQVQNCj4+PiAtIEIgaXMgb24gYSBwdWJsaWNseSByb3V0YWJsZSBh ZGRyZXNzIHdpdGggbm8gTkFUIG9yIGZpcmV3YWxsDQo+Pj4gLSBObyBTVFVOIHNlcnZlcnMgKGp1 c3QgbWFrZXMgdGhlIHNjZW5hcmlvIGxlc3MgY29tcGxleCkNCj4+PiAtIEhvc3QgY2FuZGlkYXRl cyBnZXQgZXhjaGFuZ2VkICBhbmQgY2FuZGlkYXRlIHBhaXJzIEE6QiBhbmQgQjpBIGdldCANCj4+ PiBjcmVhdGVkIG9uIGJvdGggc2lkZXMNCj4+PiAtIEEgc2VuZHMgYmluZGluZyByZXF1ZXN0IHRv IEINCj4+PiAtIEIgcmVjZWl2ZXMgYmluZGluZyByZXF1ZXN0IHdpdGggdHJhbnNwb3J0IGFkZHJl c3MgQcK5DQo+Pj4gLSBCIGNyZWF0ZXMgYSBwZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGUgZm9yIEHC uSBhbmQgdGhlIGEgbmV3IHBhaXIgDQo+Pj4gQjpBwrkgYW5kIHB1dHMgdGhhdCBuZXcgcGFpciBp bnRvIGl0cyB0cmlnZ2VyIGNoZWNrIHF1ZXVlDQo+Pj4gLSBCIHNlbmRzIGJpbmRpbmcgcmVzcG9u c2UgdG8gQcK5DQo+Pj4gLSBBIHJlY2VpdmVzIGJpbmRpbmcgcmVzcG9uc2UsIGxlYXJucyBhYm91 dCBBwrkgYW5kIGNyZWF0ZXMgQcK5OkIgYW5kIA0KPj4+IG1hcmtzIGl0IGFzIHN1Y2Nlc3NmdWwN Cj4+PiAtIE5vdyBCIHNlbmRzIGEgYmluZGluZyByZXF1ZXN0IGZvciBpdCB0cmlnZ2VyIGNoZWNr IHF1ZXVlIGVudHJ5IHRvIA0KPj4+IEHCuQ0KPj4+IC0gV2hlbiBBIHJlY2VpdmVzIHRoaXMgYmlu ZGluZyByZXF1ZXN0IGlzIGhhcyBubyB3YXkgdG8gbWF0Y2ggdGhpcyANCj4+PiB0byB0aGUgc3Vj Y2Vzc2Z1bCBwYWlyIEHCuTpCDQo+Pj4gLSBCZWNhdXNlIG9mIHRoZSB3b3JkaW5nIGluIHRoZSBh Ym92ZSBtZW50aW9uZWQgc2VjdGlvbnMgaXQgd2lsbCANCj4+PiBtYXRjaCB0aGUgcmVxdWVzdCB0 byB0aGUgcGFpciBBOkINCj4+PiAtIFdoaWNoIHRoZW4gaW4gdHVybiBjYXVzZXMgYW5vdGhlciB0 cmlnZ2VyZWQgY2hlY2sgdG8gYmUgY3JlYXRlZCANCj4+PiBiZWNhdXNlIEE6QiBpcyBub3QgaW4g dGhlIHN1Y2Nlc3Mgc3RhdGUNCj4+PiANCj4+PiBUaGlzIGFkZGl0aW9uYWwgdHJpZ2dlcmVkIGNo ZWNrIGZyb20gQSBpcyBqdXN0IHdhc3RlIG9mIHRpbWUgYW5kIA0KPj4+IHJlc291cmNlcy4gSXQg ZG9lcyBub3QgaHVydC4gQnV0IEnCuW0gd29uZGVyaW5nIGhvdyB0aGlzIGNvdWxkIGJlIGF2b2lk ZWQuDQo+Pj4gDQo+Pj4gSWYgcGVvcGxlIGFncmVlIEkgdGhpbmsgc2VjdGlvbiA2LjEuMy4xLjQg c2hvdWxkIGF0IGxlYXN0IG1lbnRpb24gDQo+Pj4gdGhlIHNjZW5hcmlvIHRoYXQgaW5jb21pbmcg YmluZGluZyByZXF1ZXN0cyBjYW4gYWxzbyBtYXRjaCBhIHBlZXIgDQo+Pj4gcmVmbGV4aXZlIGNh bmRpZGF0ZS4NCj4+PiANCj4+PiBBcyB0aGUgaW5jb21pbmcgYmluZGluZyByZXF1ZXN0IGRvZXMg bm90IGNvbnRhaW4gdGhlIGRlc3RpbmF0aW9uIA0KPj4+IGFkZHJlc3MgaXQgZ290IHNlbmQgdG8g dGhlcmUgaXMgb2J2aW91c2x5IG5vIHdheSBmb3IgQSB0byBjbGVhcmx5IA0KPj4+IGRpc3Rpbmd1 aXNoIGlmIHRoZSByZXF1ZXN0IGdvdCBzZW5kIHRvIEEgb3IgQcK5Lg0KPj4+IA0KPj4+IEZvciBh dm9pZGluZyB0aGUgYWRkaXRpb25hbCB0cmlnZ2VyZWQgY2hlY2sgb24gQcK5cyBzaWRlIHRoZSBv bmx5IA0KPj4+IHNvbHV0aW9uIEkgc2VlIHJpZ2h0IG5vdyBpcyB0byBnbyB0aHJvdWdoIHRoZSBw YWlycyB3aGljaCBoYXZlIEEgYXMgDQo+Pj4gdGhlaXIgZm91bmRhdGlvbiBhbmQgaWYgdGhhdCBs aXN0IGNvbnRhaW5zIGEgcGFpciB3aGljaCBpcyBtYXJrZWQgYXMgDQo+Pj4gc3VjY2Vzc2Z1bCBh bHJlYWR5IGFzc3VtZSBubyB0cmlnZ2VyZWQgY2hlY2sgaXMgbmVlZGVkLiBTbyBmYXIgSSANCj4+ PiBoYXZlIG5vdCBiZWVuIGFibGUgdG8gaWRlbnRpZnkgYSBzY2VuYXJpbyB3aGVyZSBpdCBodXJ0 cyB0byBza2lwIA0KPj4+IHRoaXMgZXh0cmEgcm91bmQgb2YgdHJpZ2dlcmVkIGNoZWNrcyBvbiBB wrlzIHNpZGUuDQo+Pj4gDQo+Pj4gQmVzdA0KPj4+IE5pbHMgT2hsbWVpZXINCj4+PiANCj4+IA0K PiANCg0K From nobody Thu Nov 3 11:17:46 2016 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 C797A1298D3 for ; Thu, 3 Nov 2016 11:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jALY6HsCXbmC for ; Thu, 3 Nov 2016 11:17:43 -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 7B7EB12970A for ; Thu, 3 Nov 2016 11:17:42 -0700 (PDT) X-AuditID: c1b4fb25-d35ee98000001e3e-94-581b7f44ad07 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 68.57.07742.44F7B185; Thu, 3 Nov 2016 19:17:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Thu, 3 Nov 2016 19:17:38 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: Discarding low-priority candidates Thread-Index: AdI1/o1j5Yhjnp3LTsWO5iY/pf4RCQ== Date: Thu, 3 Nov 2016 18:17:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE1C70E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE1C70EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM2K7t65LvXSEweszlhbfLtQ6MHosWfKT KYAxissmJTUnsyy1SN8ugStjy8c+loL9VhW/5txlbWBcYNzFyMkhIWAi8XbDBJYuRi4OIYF1 jBKzr71hhHAWM0oc2zCRuYuRg4NNwEKi+582SIOIgKLEzJZnzCC2MFBzx8uZrBBxS4lrm7ZA 2XoS35qfgtWwCKhIvG2cwg5i8wr4Skw61AUWZxQQk/h+ag0TiM0sIC5x68l8JoiDBCSW7DnP DGGLSrx8/I8VwlaSWHt4OwvIOcwC+RInjqVBjBSUODnzCcsERsFZSCbNQqiahaQKokRHYsHu T2wQtrbEsoWvmWHsMwceMyGLL2BkX8UoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGPQHt/xW 3cF4+Y3jIUYBDkYlHt4PAdIRQqyJZcWVuYcYJTiYlUR4/9YChXhTEiurUovy44tKc1KLDzFK c7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamBsmvfnUWCdQeZiVY55DPsd9wUWB+5QqWVX vKrosktAcM3znidykt1PcyM3LWrnSViUErymxNRB7eeqqRU6z1POZT/5GtR+L4XhZvw8hUj2 yXuXtH1xX7B6enL97Nvtxj0mEb/ebyrZGRLlu8C7Pm/5+u272Nm6/BISjteyRM2ZbqFzWJ7h 6EklluKMREMt5qLiRADNJIjSdgIAAA== Archived-At: Subject: [Ice] 5245bis: Discarding low-priority candidates X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 18:17:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE1C70EESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 5.1.3.3 (Pruning the Pairs) of 5245bis contains the following parag= raph: "In addition, in order to limit the attacks described in Section 13.4.1, an agent MUST limit the total number of connectivity checks the agent performs across all check lists to a specific value, and this value MUST be configurable. A default of 100 is RECOMMENDED. This limit is enforced by discarding the lower-priority candidate pairs until there are less than 100. It is RECOMMENDED that a lower value be utilized when possible, set to the maximum number of plausible checks that might be seen in an actual deployment configuration. The requirement for configuration is meant to provide a tool for fixing this value in the field if, once deployed, it is found to be problematic." I guess we can have some text about removing low-priority candidate pairs, = but do we really need a number? And, if we need a number, do we need to tak= e into consideration multiple ICE instances (e.g., multiple browser tabs)? Also, is removing low-priority candidates really part of pruning? Elsewhere= in the document where pruning is mentioned there is no word about removing= low-priority candidates. So, if we want to keep the text (or a modified ve= rsion of it), perhaps it should be a separate section? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4BE1C70EESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 5.1.3.3 (Pruning the Pairs) of 5245bis conta= ins the following paragraph:

 

   “In addition= , in order to limit the attacks described in

  Section 13.4.1, an = agent MUST limit the total number of connectivity

   checks the agent p= erforms across all check lists to a specific value,

   and this value MUS= T be configurable.  A default of 100 is

   RECOMMENDED. = This limit is enforced by discarding the lower-priority<= /p>

   candidate pairs un= til there are less than 100.  It is RECOMMENDED

   that a lower value= be utilized when possible, set to the maximum

   number of plausibl= e checks that might be seen in an actual deployment

   configuration.&nbs= p; The requirement for configuration is meant to provide<= /p>

   a tool for fixing = this value in the field if, once deployed, it is

   found to be proble= matic.”

 

I guess we can have some text about removing low-pri= ority candidate pairs, but do we really need a number? And, if we need a nu= mber, do we need to take into consideration multiple ICE instances (e.g., m= ultiple browser tabs)?

 

Also, is removing low-priority candidates really par= t of pruning? Elsewhere in the document where pruning is mentioned there is= no word about removing low-priority candidates. So, if we want to keep the= text (or a modified version of it), perhaps it should be a separate section?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4BE1C70EESESSMB209erics_-- From nobody Sun Nov 6 05:50:32 2016 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 A639C129890 for ; Sun, 6 Nov 2016 05:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90zvQI7TamR8 for ; Sun, 6 Nov 2016 05:50:24 -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 63A32129861 for ; Sun, 6 Nov 2016 05:50:24 -0800 (PST) X-AuditID: c1b4fb3a-447ff700000070a2-61-581f351eeb48 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 29.A1.28834.E153F185; Sun, 6 Nov 2016 14:50:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Sun, 6 Nov 2016 14:50:21 +0100 From: Christer Holmberg To: Nils Ohlmeier Thread-Topic: [Ice] Triggered checks are missing peer reflexive Thread-Index: AQHSBVlPEOYY7CCEV0C+dqegwGP6+aCBttwAgBacroCABbZ6AIAuVBSw Date: Sun, 6 Nov 2016 13:50:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE224F2@ESESSMB209.ericsson.se> References: <37F6A130-E058-4683-B566-AD250032AB3F@mozilla.com> <78810E33-18A5-4C8D-89F0-A4B943C4520F@mozilla.com> <85414E3B-744A-48A2-BA6C-DC96E677484D@mozilla.com> In-Reply-To: <85414E3B-744A-48A2-BA6C-DC96E677484D@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7tK6cqXyEwdnVEhbfLtRaXJ83mdGB yWPJkp9MHn0HulgDmKK4bFJSczLLUov07RK4Mub+ncFcMMGkor+7mamB8YlRFyMnh4SAicSn 532sXYxcHEIC6xgl/jdvZoZwFjNKTH/fxdbFyMHBJmAh0f1PG8QUEdCUOLGRD8RkFlCUeLlX DWSMsICdxMx1W9lAbBEBe4kzuzrYIWw3icldT1lAbBYBFYkNP/8wgdi8Ar4S6xaeg9p0i1Fi /ZujzCAJTqDmrzt7wAYxCohJfD+1BqyBWUBc4taT+UwQNwtILNlznhnCFpV4+fgfK4StJNG4 5AkrxG2aEut36UO0KkpM6X7IDrFXUOLkzCcsExhFZyGZOguhYxaSjllIOhYwsqxiFC1OLS7O TTcy0kstykwuLs7P08tLLdnECIyPg1t+W+1gPPjc8RCjAAejEg+vgY5chBBrYllxZe4hRgkO ZiUR3rPG8hFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEec1W3g8XEkhPLEnNTk0tSC2CyTJxcEo1 MC70uvBRIij88lRGHsaT5T+yWue0G2dOULt5TqG286IXU2NO7a7qQobZO8tWt0fc6Vx6cNqT vm6+gBu223pLQ4K/hFtd8NpYdntHp+Eq+7yb/R9dzum7t0qsEWs8zWzIInUmmFm07GiMloHO sym+Lz0MrbzinT+Hzb6w2SXgqAabz76PbVI6SizFGYmGWsxFxYkAe4ZyzosCAAA= Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Triggered checks are missing peer reflexive X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2016 13:50:28 -0000 SGksDQoNCj5UaGFua3MgZm9yIHlvdXIgcmVwbHkuIEkgZG9u4oCZdCB0aGluayB0aGF0IHRoZXJl IGlzIGFueSBwcnVuaW5nIGhhcHBlbmluZyB3aGVuIHlvdSA+ZGlzY292ZXIgcGVlciByZWZsZXhp dmUgY2FuZGlkYXRlcyAoeW91IGFyZSBzdXBwb3NlIHRvIGNoZWNrIGZvciBhbiBleGlzdGluZyBl cXVhbCBwYWlyLCA+bm90IHN1cmUgaWYgeW91IGNvbnNpZGVyIHRoYXQgYXMgcHJ1bmluZyBhdCB0 aGF0IHN0ZXApLg0KDQpUaGUgc3BlYyBkb2VzIGFsbG93IHVwZGF0aW5nIG9mIHRoZSBjaGVjayBs aXN0IHdoZW4gcGVlciByZWZsZXhpdmUgY2FuZGlkYXRlcyBoYXZlIGJlZW4gZGlzY292ZXJlZC4g QnV0LCBjdXJyZW50bHkgdGhleSB3b24ndCBiZSBwcnVuZWQuDQoNCkNvdWxkIHdlIHNheSB0aGF0 IHBydW5pbmcgb2NjdXIgd2hlbiB0aGUgbG9jYWwgY2FuZGlkYXRlIGRvZXNuJ3QgbWF0Y2ggdGhl IGJhc2U/IFRoYXQgd291bGQgY292ZXIgYm90aCBzZXJ2ZXIgcmVmbGV4aXZlIGFuZCBwZWVyIHJl ZmxleGl2ZSBjYW5kaWRhdGVzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCj4gT24gT2N0 IDQsIDIwMTYsIGF0IDAyOjU4LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+IEhpIE5pbHMsDQo+IA0KPiBTb3JyeSBmb3IgdGhl IGxhdGUgcmVwbHkuDQo+IA0KPiBJZiBJIHVuZGVyc3RhbmQgdGhlIGlzc3VlIGNvcnJlY3RseSwg dGhpcyBjb3VsZCBvbmx5IGhhcHBlbiB3aXRoIHRyaWNrbGUuDQo+IEJlY2F1c2UsIGluIG5vcm1h bCBjYXNlcyBwcnVuaW5nIHdvdWxkIHRha2UgY2FyZSBvZiBpdC4NCj4gDQo+IE9yPw0KPiANCj4g UmVnYXJkcywNCj4gDQo+IENocmlzdGVyDQo+IA0KPiBPbiAyMC8wOS8xNiAwNjo0NiwgIkljZSBv biBiZWhhbGYgb2YgTmlscyBPaGxtZWllciIgDQo+IDxpY2UtYm91bmNlc0BpZXRmLm9yZyBvbiBi ZWhhbGYgb2Ygbm9obG1laWVyQG1vemlsbGEuY29tPiB3cm90ZToNCj4gDQo+PiBBZnRlciByZWFk aW5nIHVwIG9uIGhvdyB0aGUgY3VycmVudCBUcmlja2xlIElDRSBkcmFmdCBwcm9wb3NlcyB0byAN Cj4+IGhhbmRsZSBwZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGVzIGl0IGFwcGVhcnMgdG8gbWUgdGhh dCBteSBzY2VuYXJpbyANCj4+IGJlbG93IGlzIHJlbGV2YW50IGZvciBJQ0UgNTI0NWJpcyBpZiB0 aGVyZSBpcyBubyBTVFVOIHNlcnZlci4NCj4+IEFuZCBpZiB0aGVyZSBpcyBhIFNUVU4gc2VydmVy IHRoZW4gaXQgc2hvdWxkIG9ubHkgaGFwcGVuIGlmIEIgaGFzIA0KPj4gdHJpY2tsZWQgaGlzIHB1 YmxpYyBob3N0IGNhbmRpZGF0ZSB0byBBIGFscmVhZHkuIEFuZCBBIHJlY2VpdmVzIGl0cyANCj4+ IGJpbmRpbmcgcmVzcG9uc2UgZnJvbSBCIGJlZm9yZSBpdCBkaXNjb3ZlcnMgaGlzIG93biBzZXJ2 ZXIgcmVmbGV4aXZlIA0KPj4gYnkgcmVjZWl2aW5nIGEgYmluZGluZyByZXNwb25zZSBmcm9tIHRo ZSBTVFVOIHNlcnZlci4NCj4+IA0KPj4gRXZlbiBpZiB3ZSBkb27CuXQgYm90aGVyIGRvIHRyeSB0 byBvcHRpbWl6ZSB0aGUgdXNlbGVzcy9yZWR1bmRhbnQgDQo+PiB0cmlnZ2VyIGNoZWNrIGF3YXkg SSB0aGluayB3ZSBzaG91bGQ6DQo+PiAtIGluY2x1ZGUgcGVlciByZWZsZXhpdmUgY2FuZGlkYXRl cyBpbnRvIHRoZSBwYXJhZ3JhcGggb2YgNTI0NSB3aGljaCANCj4+IHRhbGtzIGFib3V0IHRyaWdn ZXIgY2hlY2tzDQo+PiAtIGV4dGVuZCB0aGUgcGFyYWdyYXBoIGluIHRoZSB0cmlja2xlIGRyYWZ0 IHRvIG5vdCBvbmx5IG1lbnRpb24gDQo+PiBkaXNjb3ZlcmluZyBwZWVyIHJlZmxleGl2ZSBjYW5k aWRhdGVzIHZpYSBTVFVOIGJpbmRpbmcgcmVxdWVzdCwgYnV0IA0KPj4gYWxzbyBmcm9tIGJpbmRp bmcgcmVzcG9uc2VzLg0KPj4gDQo+PiBJIHdvdWxkIGFwcHJlY2lhdGUgc29tZSBmZWVkYmFjayBv biB0aGlzIGJlZm9yZSB0cnlpbmcgdG8gcHJvcG9zZSANCj4+IGltcHJvdmVkIHdvcmRpbmcgZm9y IGJvdGggc3BlY3MuDQo+PiANCj4+IEJlc3QNCj4+IE5pbHMgT2hsbWVpZXINCj4+IA0KPj4+IE9u IFNlcCAyLCAyMDE2LCBhdCAxMzozNCwgTmlscyBPaGxtZWllciA8bm9obG1laWVyQG1vemlsbGEu Y29tPiB3cm90ZToNCj4+PiANCj4+PiBIZWxsbywNCj4+PiANCj4+PiBJIGhhdmUgaWRlbnRpZmll ZCBzb21ldGhpbmcgd2hpY2ggSSB3b3VsZCBiZSBpbnRlcmVzdGVkIHRvIGhlYXIgdGhlIA0KPj4+ IG9waW5pb25zIG9mIHRoZSBJQ0UgZXhwZXJ0cyBhYm91dC4NCj4+PiANCj4+PiBJbiBSRkMgNTI0 NSAoc2VjdGlvbiA3LjIuMS40KSBhbmQgYWxzbyBpbiBiaXMtMDQgKHNlY3Rpb24gNi4xLjMuMS40 KSANCj4+PiBjbGFpbSB0aGUgZm9sbG93aW5nIHJlZ2FyZGluZyByZWNlaXZpbmcgdHJpZ2dlcmVk IGNoZWNrczoNCj4+PiAgVGhlIGxvY2FsIGNhbmRpZGF0ZSB3aWxsIGVpdGhlciBiZSBhIGhvc3Qg Y2FuZGlkYXRlICguLi4pIG9yIGEgDQo+Pj4gcmVsYXllZCBjYW5kaWRhdGUgKMWgKS4gVGhlIGxv Y2FsIGNhbmRpZGF0ZSBjYW4gbmV2ZXIgYmUgYSBzZXJ2ZXIgDQo+Pj4gcmVmbGV4aXZlIGNhbmRp ZGF0ZS4NCj4+PiANCj4+PiBXaGljaCBJIHRoaW5rIGlzIG1pc3NpbmcgdGhlIGNhc2Ugd2hlcmUg dGhlIGxvY2FsIGNhbmRpZGF0ZSBjYW4gYWxzbyANCj4+PiBhIGJlIGEgcGVlciByZWZsZXhpdmUu IEFuZCB0aGlzIGlzIGFjdHVhbGx5IGNhdXNpbmcgdW5uZWNlc3NhcnkgDQo+Pj4gZXh0cmEgY2hl Y2tzIHRvIGJlIG1hZGUuDQo+Pj4gDQo+Pj4gQ29uc2lkZXIgdGhlIGZvbGxvd2luZyBzY2VuYXJp bzoNCj4+PiANCj4+PiAtIEEgc2l0cyBiZWhpbmQgc3ltbWV0cmljIE5BVA0KPj4+IC0gQiBpcyBv biBhIHB1YmxpY2x5IHJvdXRhYmxlIGFkZHJlc3Mgd2l0aCBubyBOQVQgb3IgZmlyZXdhbGwNCj4+ PiAtIE5vIFNUVU4gc2VydmVycyAoanVzdCBtYWtlcyB0aGUgc2NlbmFyaW8gbGVzcyBjb21wbGV4 KQ0KPj4+IC0gSG9zdCBjYW5kaWRhdGVzIGdldCBleGNoYW5nZWQgIGFuZCBjYW5kaWRhdGUgcGFp cnMgQTpCIGFuZCBCOkEgZ2V0IA0KPj4+IGNyZWF0ZWQgb24gYm90aCBzaWRlcw0KPj4+IC0gQSBz ZW5kcyBiaW5kaW5nIHJlcXVlc3QgdG8gQg0KPj4+IC0gQiByZWNlaXZlcyBiaW5kaW5nIHJlcXVl c3Qgd2l0aCB0cmFuc3BvcnQgYWRkcmVzcyBBwrkNCj4+PiAtIEIgY3JlYXRlcyBhIHBlZXIgcmVm bGV4aXZlIGNhbmRpZGF0ZSBmb3IgQcK5IGFuZCB0aGUgYSBuZXcgcGFpciANCj4+PiBCOkHCuSBh bmQgcHV0cyB0aGF0IG5ldyBwYWlyIGludG8gaXRzIHRyaWdnZXIgY2hlY2sgcXVldWUNCj4+PiAt IEIgc2VuZHMgYmluZGluZyByZXNwb25zZSB0byBBwrkNCj4+PiAtIEEgcmVjZWl2ZXMgYmluZGlu ZyByZXNwb25zZSwgbGVhcm5zIGFib3V0IEHCuSBhbmQgY3JlYXRlcyBBwrk6QiBhbmQgDQo+Pj4g bWFya3MgaXQgYXMgc3VjY2Vzc2Z1bA0KPj4+IC0gTm93IEIgc2VuZHMgYSBiaW5kaW5nIHJlcXVl c3QgZm9yIGl0IHRyaWdnZXIgY2hlY2sgcXVldWUgZW50cnkgdG8gDQo+Pj4gQcK5DQo+Pj4gLSBX aGVuIEEgcmVjZWl2ZXMgdGhpcyBiaW5kaW5nIHJlcXVlc3QgaXMgaGFzIG5vIHdheSB0byBtYXRj aCB0aGlzIA0KPj4+IHRvIHRoZSBzdWNjZXNzZnVsIHBhaXIgQcK5OkINCj4+PiAtIEJlY2F1c2Ug b2YgdGhlIHdvcmRpbmcgaW4gdGhlIGFib3ZlIG1lbnRpb25lZCBzZWN0aW9ucyBpdCB3aWxsIA0K Pj4+IG1hdGNoIHRoZSByZXF1ZXN0IHRvIHRoZSBwYWlyIEE6Qg0KPj4+IC0gV2hpY2ggdGhlbiBp biB0dXJuIGNhdXNlcyBhbm90aGVyIHRyaWdnZXJlZCBjaGVjayB0byBiZSBjcmVhdGVkIA0KPj4+ IGJlY2F1c2UgQTpCIGlzIG5vdCBpbiB0aGUgc3VjY2VzcyBzdGF0ZQ0KPj4+IA0KPj4+IFRoaXMg YWRkaXRpb25hbCB0cmlnZ2VyZWQgY2hlY2sgZnJvbSBBIGlzIGp1c3Qgd2FzdGUgb2YgdGltZSBh bmQgDQo+Pj4gcmVzb3VyY2VzLiBJdCBkb2VzIG5vdCBodXJ0LiBCdXQgScK5bSB3b25kZXJpbmcg aG93IHRoaXMgY291bGQgYmUgYXZvaWRlZC4NCj4+PiANCj4+PiBJZiBwZW9wbGUgYWdyZWUgSSB0 aGluayBzZWN0aW9uIDYuMS4zLjEuNCBzaG91bGQgYXQgbGVhc3QgbWVudGlvbiANCj4+PiB0aGUg c2NlbmFyaW8gdGhhdCBpbmNvbWluZyBiaW5kaW5nIHJlcXVlc3RzIGNhbiBhbHNvIG1hdGNoIGEg cGVlciANCj4+PiByZWZsZXhpdmUgY2FuZGlkYXRlLg0KPj4+IA0KPj4+IEFzIHRoZSBpbmNvbWlu ZyBiaW5kaW5nIHJlcXVlc3QgZG9lcyBub3QgY29udGFpbiB0aGUgZGVzdGluYXRpb24gDQo+Pj4g YWRkcmVzcyBpdCBnb3Qgc2VuZCB0byB0aGVyZSBpcyBvYnZpb3VzbHkgbm8gd2F5IGZvciBBIHRv IGNsZWFybHkgDQo+Pj4gZGlzdGluZ3Vpc2ggaWYgdGhlIHJlcXVlc3QgZ290IHNlbmQgdG8gQSBv ciBBwrkuDQo+Pj4gDQo+Pj4gRm9yIGF2b2lkaW5nIHRoZSBhZGRpdGlvbmFsIHRyaWdnZXJlZCBj aGVjayBvbiBBwrlzIHNpZGUgdGhlIG9ubHkgDQo+Pj4gc29sdXRpb24gSSBzZWUgcmlnaHQgbm93 IGlzIHRvIGdvIHRocm91Z2ggdGhlIHBhaXJzIHdoaWNoIGhhdmUgQSBhcyANCj4+PiB0aGVpciBm b3VuZGF0aW9uIGFuZCBpZiB0aGF0IGxpc3QgY29udGFpbnMgYSBwYWlyIHdoaWNoIGlzIG1hcmtl ZCBhcyANCj4+PiBzdWNjZXNzZnVsIGFscmVhZHkgYXNzdW1lIG5vIHRyaWdnZXJlZCBjaGVjayBp cyBuZWVkZWQuIFNvIGZhciBJIA0KPj4+IGhhdmUgbm90IGJlZW4gYWJsZSB0byBpZGVudGlmeSBh IHNjZW5hcmlvIHdoZXJlIGl0IGh1cnRzIHRvIHNraXAgDQo+Pj4gdGhpcyBleHRyYSByb3VuZCBv ZiB0cmlnZ2VyZWQgY2hlY2tzIG9uIEHCuXMgc2lkZS4NCj4+PiANCj4+PiBCZXN0DQo+Pj4gTmls cyBPaGxtZWllcg0KPj4+IA0KPj4gDQo+IA0KDQo= From nobody Sun Nov 6 23:34:01 2016 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 920DB129CC6 for ; Sun, 6 Nov 2016 23:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJvO7IbMpOo0 for ; Sun, 6 Nov 2016 23:33:58 -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 3DFB1129418 for ; Sun, 6 Nov 2016 23:33:58 -0800 (PST) X-AuditID: c1b4fb25-953ff70000001e3e-d3-58202e63b24f Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id B4.D1.07742.36E20285; Mon, 7 Nov 2016 08:33:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 08:33:55 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: active and frozen check lists Thread-Index: AQHSOMlKI+Ewb+mCTUeB9HElk7Zj+Q== Date: Mon, 7 Nov 2016 07:33:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D445FCD812A92christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7q26KnkKEwd0X8hbfLtQ6MHosWfKT KYAxissmJTUnsyy1SN8ugSvjX49CwSm5ils7zjI1MN6W6GLk5JAQMJG42fGetYuRi0NIYB2j xKFF/WwQzmJGiRN/fgI5HBxsAhYS3f+0QRpEBBQlZrY8YwaxhQX0Ja7cuMYMETeROH59FjNI uYiAnsSLSb4gYRYBFYkdv6cygti8AtYSS2YuZwWxGQXEJL6fWsMEYjMLiEvcejKfCeIeAYkl e84zQ9iiEi8f/2MFGSkKNHLN/TCIsKLEx1f7GCFaEyQ6nqyEGi8ocXLmE5YJjEKzkEydhaRs FpIyiLiBxPtz85khbG2JZQtfQ9n6Ehu/nGWEsK0l3sy+xY6sZgEjxypG0eLU4qTcdCNjvdSi zOTi4vw8vbzUkk2MwBg5uOW36g7Gy28cDzEKcDAq8fAWuMpHCLEmlhVX5h5ilOBgVhLhVdRV iBDiTUmsrEotyo8vKs1JLT7EKM3BoiTOa7byfriQQHpiSWp2ampBahFMlomDU6qBsUmqPeqT 3MfES1vVniff95VOl+wUZWKU3342bFnamvfaTYmsP5XMLXdKOMx5t/9OROa9ibmmXzUFjFbO Uuv6cnPd7x89/bl3Vuxj3bb0vFXhcwum6kv79z94fvPnutVzvzr6eK0suRmwsPbs34P3y1ec ZRRc0Pv2kklwcciWFqmrf6onu585wKDEUpyRaKjFXFScCAC5pSHgjQIAAA== Archived-At: Subject: [Ice] 5245bis: active and frozen check lists X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 07:33:59 -0000 --_000_D445FCD812A92christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Section 5.1.3.4 of 5245bis defines the following check list states: running= , completed, failed. The check list itself is associated with a state, which captures the state of ICE checks for that media stream. There are three states: Running: In this state, ICE checks are still in progress for this media stream. Completed: In this state, ICE checks have produced nominated pairs for each component of the media stream. Failed: In this state, the ICE checks have not completed successfully for this media stream. However, the section also defines two =93types=94 of check lists: active ch= eck list and frozen check list. One of the check lists will have some number of pairs in the Waiting state, and the other check lists will have all of their pairs in the Frozen state. A check list with at least one pair that is Waiting is called an active check list, and a check list with all pairs Frozen is called a frozen check list. Q1: Why can=92t Frozen simply be a check list state? Q2: What=92s the state of a Frozen check list? Q3: What=92s the difference between an active check list and an active chec= k list in Running state? Regards, Christer --_000_D445FCD812A92christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Section 5.1.3.4 of 5245bis defines the following check list states: ru= nning, completed, failed.

 The check list itself is associat=
ed with a state, which captures the
   state of ICE checks for that media stream.  There are three states:

   Running:  In this state, ICE checks are still in progress for thi=
s
      media stream.

   Completed:  In this state, ICE checks have produced nominated pai=
rs
      for each component of the media stream.

   Failed:  In this state, the ICE checks have not completed
      successfully for this media stream.

However, the section also defines two =93types=94 of check lists: acti= ve check list and frozen check list.

   One of the check lists will hav=
e some number of pairs in the Waiting
   state, and the other check lists will have all of their pairs in the
   Frozen state.  A check list with at least one pair that is Waiting is
   called an active check list, and a check list with all pairs Froz=
en
   is called a frozen check list.

Q1: Why can=92t Frozen simply be a check list state?

Q2: What=92s the state of a Frozen check list?

Q3: What=92s the difference between an active check list and an= active check list in Running state?

Regards,

Christer

--_000_D445FCD812A92christerholmbergericssoncom_-- From nobody Sun Nov 6 23:35:22 2016 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 F1C07129CCA for ; Sun, 6 Nov 2016 23:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sKrYCRe_5-k for ; Sun, 6 Nov 2016 23:35:19 -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 4CFF6129CC8 for ; Sun, 6 Nov 2016 23:35:19 -0800 (PST) X-AuditID: c1b4fb30-b87ff70000000cb2-3b-58202eb4f0c9 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 23.D6.03250.4BE20285; Mon, 7 Nov 2016 08:35:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 08:35:16 +0100 From: Christer Holmberg To: Christer Holmberg , "ice@ietf.org" Thread-Topic: [Ice] 5245bis: active and frozen check lists Thread-Index: AQHSOMl7va+midl13kuOWuFnzB9ZdQ== Date: Mon, 7 Nov 2016 07:35:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D445FD0C12A95christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7k+5WPYUIg/ufdSy+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAldGx45mxoLtOhXbj69lbWD8qdLFyMkhIWAice7uBGYQW0hgHaPE ghtANheQvZhR4k1bP5DDwcEmYCHR/U8bpEZEIFzizsubbCBhYQFLiWNvVEBMEQEriXUHUyEq 9CSWztjLCmKzCKhI7Hu0ih3E5hWwlphy+zAbiM0oICbx/dQaJhCbWUBc4taT+UwQ1whILNlz nhnCFpV4+fgfK8h4UaCZa+6HQYQVJT6+2scI0ZogsWPxVUaI8YISJ2c+YZnAKDQLydRZSMpm ISmDiBtIvD83nxnC1pZYtvA1lK0vsfHLWaB6DiDbWqLtrDaykgWMHKsYRYtTi5Ny042M9FKL MpOLi/Pz9PJSSzYxAuPj4JbfBjsYXz53PMQowMGoxMNb4CofIcSaWFZcmXuIUYKDWUmEV1FX IUKINyWxsiq1KD++qDQntfgQozQHi5I4r9nK++FCAumJJanZqakFqUUwWSYOTqkGRhF9Q3nt pvcCxU9MT9rq/c5++leY0+XlAV7LoGKV7YwdkbZL3cz3TOrZfvP0YX7ulOJlBznXX+75K7vw aOnX12ce3VhjpppgJre93S7gTEH6VeU3i9eJS7iFb35zMqj2sOm1rPKwkx0Ppl45+eT6Fcfb +16tYZM8fmZj896Lr3g3is7lbWQ/9FuJpTgj0VCLuag4EQB9CyiFiwIAAA== Archived-At: Subject: Re: [Ice] 5245bis: active and frozen check lists X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 07:35:21 -0000 --_000_D445FD0C12A95christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Q3 correction: What=92s the difference between an active check list and a c= heck list in Running state? From: Ice > on behalf of = Christer Holmberg > Date: Monday 7 November 2016 at 10:33 To: "ice@ietf.org" > Subject: [Ice] 5245bis: active and frozen check lists Hi, Section 5.1.3.4 of 5245bis defines the following check list states: running= , completed, failed. The check list itself is associated with a state, which captures the state of ICE checks for that media stream. There are three states: Running: In this state, ICE checks are still in progress for this media stream. Completed: In this state, ICE checks have produced nominated pairs for each component of the media stream. Failed: In this state, the ICE checks have not completed successfully for this media stream. However, the section also defines two =93types=94 of check lists: active ch= eck list and frozen check list. One of the check lists will have some number of pairs in the Waiting state, and the other check lists will have all of their pairs in the Frozen state. A check list with at least one pair that is Waiting is called an active check list, and a check list with all pairs Frozen is called a frozen check list. Q1: Why can=92t Frozen simply be a check list state? Q2: What=92s the state of a Frozen check list? Q3: What=92s the difference between an active check list and an active chec= k list in Running state? Regards, Christer --_000_D445FD0C12A95christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Q3 correction: What=92s the difference between an active check list an= d a check list in Running state?

From: Ice <ice-bounces@ietf.org> on behalf of Christer Holmb= erg <christer.holmberg= @ericsson.com>
Date: Monday 7 November 2016 at 10:= 33
To: "ice@ietf.org" <ice@ietf.= org>
Subject: [Ice] 5245bis: active and = frozen check lists

Hi,

Section 5.1.3.4 of 5245bis defines the following check list states: ru= nning, completed, failed.

 The check list itself is associat=
ed with a state, which captures the
   state of ICE checks for that media stream.  There are three states:

   Running:  In this state, ICE checks are still in progress for thi=
s
      media stream.

   Completed:  In this state, ICE checks have produced nominated pai=
rs
      for each component of the media stream.

   Failed:  In this state, the ICE checks have not completed
      successfully for this media stream.

However, the section also defines two =93types=94 of check lists: acti= ve check list and frozen check list.

   One of the check lists will hav=
e some number of pairs in the Waiting
   state, and the other check lists will have all of their pairs in the
   Frozen state.  A check list with at least one pair that is Waiting is
   called an active check list, and a check list with all pairs Froz=
en
   is called a frozen check list.

Q1: Why can=92t Frozen simply be a check list state?

Q2: What=92s the state of a Frozen check list?

Q3: What=92s the difference between an active check list and an= active check list in Running state?

Regards,

Christer

 --_000_D445FD0C12A95christerholmbergericssoncom_-- From nobody Mon Nov 7 03:50:37 2016 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 52150129E0B for ; Mon, 7 Nov 2016 03:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDfTeB8gd6DG for ; Mon, 7 Nov 2016 03:50:34 -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 D71101298A6 for ; Mon, 7 Nov 2016 03:50:33 -0800 (PST) X-AuditID: c1b4fb2d-1c7ff700000009f7-92-58206a86b150 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id F2.EA.02551.68A60285; Mon, 7 Nov 2016 12:50:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 12:50:30 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: From where to send triggered checks? Thread-Index: AQHSOO0jZY7Qy8aFW0utoaf7Wn5sKw== Date: Mon, 7 Nov 2016 11:50:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D44638FB12B0Achristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7sW5HlkKEwedCi28Xah0YPZYs+ckU wBjFZZOSmpNZllqkb5fAldE7+QNbwRGxis+XtzM2MB4V6mLk5JAQMJGY1tTA2sXIxSEksI5R YvLy31DOYkaJRVu2MHUxcnCwCVhIdP/TBmkQEVCUmNnyjBnEFhYwk/g34w87RNxa4vGT6cwQ tp7Eh+PbmEFaWQRUJBp/8YGEeYFKbq04ywJiMwqISXw/tYYJxGYWEJe49WQ+E8Q9AhJL9pxn hrBFJV4+/scKMkYUaOSa+2EQYUWJ9qcNjBCtCRLNZ/axQYwXlDg58wnLBEahWUimzkJSNgtJ GUTcQOL9ufnMELa2xLKFr6FsfYmNX84yQtjWEhM7njIhq1nAyLGKUbQ4tbg4N93IWC+1KDO5 uDg/Ty8vtWQTIzBGDm75rbuDcfVrx0OMAhyMSjy8Ba7yEUKsiWXFlbmHGCU4mJVEePdlKkQI 8aYkVlalFuXHF5XmpBYfYpTmYFES5zVbeT9cSCA9sSQ1OzW1ILUIJsvEwSnVwJjjwJZSlOZk KL70gN6/RS6J2euMiu2NVRJaeGZovP20LGL/NMXCNA/R36cd9opZ1fK7LJqaISg9q3Bb7kFb CQb+m5qXxXkbospr9z+3EGxQ6+hYO62a75GovFyDkduD31lvY042rexLejNF/+oBbvnovuTV Kx8YR2Rd0754Nf/SM++LH++/U2Ipzkg01GIuKk4EACRWrWKNAgAA Archived-At: Subject: [Ice] 5245bis: From where to send triggered checks? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 11:50:36 -0000 --_000_D44638FB12B0Achristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Section 5.1.4 of 5245bis says: "When the timer fires and there is no triggered check to be sent, the agent MUST choose an ordinary check as follows: o Find the highest-priority pair in that check list that is in the Waiting state. o If there is such a pair: * Send a STUN check from the local candidate of that pair to the remote candidate of that pair. The procedures for forming the STUN request for this purpose are described in Section 6.1.2.=94 Doesn=92t the =93Send a STUN check=85=94 text also apply to triggered check= s? Regards, Christer --_000_D44638FB12B0Achristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable 
Hi,
Section 5.1.4 of 5245bis says:

   "When the timer fires and there is no triggered check to be sent, t=
he
   agent MUST choose an ordinary check as follows:

   o  Find the highest-priority pair in that check list that is in the
      Waiting state.

   o  If there is such a pair:

      *  Send a STUN check from the local candidate of that pair to the
         remote candidate of that pair.  The procedures for forming the
         STUN request for this purpose are described in Section 6.1.2.=94




Doesn=92t the =93Send a STUN check=
=85=94 text also apply to triggered checks?


Regards,


Christer
--_000_D44638FB12B0Achristerholmbergericssoncom_-- From nobody Mon Nov 7 05:33:59 2016 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 39F7D1294E6; Mon, 7 Nov 2016 05:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZMMtk5dt7bd; Mon, 7 Nov 2016 05:33:51 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5488B12946E; Mon, 7 Nov 2016 05:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3544; q=dns/txt; s=iport; t=1478525631; x=1479735231; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=b4Qesl3ChY+Sohh4sD+Q3RPaAvoXUk/p1rq6Cb5rl0A=; b=Rz4bz8qoIYTjhYxILsrkj9fqiKlVTXUM19U7P3diElLz/hJBRaUy7z9y ac0DGnjxJZK8uDkHAg4sLzj3RUMCllU6EpeaKZexREZ0hPHyzRzYLHwEz Ac6tCDh7boH/XgnAKkaNBAG2Yd7A2074t6p1Iy6q3QWqbe6pXjbCs0Tse 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAgBegiBY/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4BAQEBAR9YfAeNMZcBkAWETYIIHguFewIagWs/FAECAQEBAQE?= =?us-ascii?q?BAWIohGEBAQEDAQEBASAROgsFCwIBCBgCAiYCAgIlCxUFCwIEDgWIUAgOsTeCQ?= =?us-ascii?q?Is9AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBCYU1gX2CWIdLLYIvBZRHhWABkEO?= =?us-ascii?q?QEI0qhAUBHjd6G4NKgUVyhn2BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,606,1473120000"; d="scan'208";a="345287428" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2016 13:33:50 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uA7DXoUw008594 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2016 13:33:50 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 08:33:48 -0500 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1210.000; Mon, 7 Nov 2016 08:33:49 -0500 From: "Pal Martinsen (palmarti)" To: Ben Campbell Thread-Topic: =?utf-8?B?W0ljZV0gTWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFm?= =?utf-8?B?dC1pZXRmLWljZS1kdWFsc3RhY2stZmFpcm5lc3MtMDY6ICh3aXRoIENPTU1F?= =?utf-8?Q?NT)?= Thread-Index: AQHSNPEfyfyM8nB5i0uv6J7hCh8WtaDGChwAgAfW9gA= Date: Mon, 7 Nov 2016 13:33:49 +0000 Message-ID: References: <147808133311.24126.15765271660818591137.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.225.6] Content-Type: text/plain; charset="utf-8" Content-ID: <03EF6EACAF79A34881B7430BF85D903F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , "draft-ietf-ice-dualstack-fairness@ietf.org" , "ice-chairs@ietf.org" , "ice@ietf.org" , Mirja Kuehlewind , The IESG Subject: Re: [Ice] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-ice-dualstack-fairness-06=3A_=28with_COMMENT=29?= X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 13:33:53 -0000 DQoNCg0KPiBPbiAyIE5vdiAyMDE2LCBhdCAxNTo1MCwgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1 bS5jb20+IHdyb3RlOg0KPiANCj4gT24gMiBOb3YgMjAxNiwgYXQgNTowOCwgTWlyamEgS3VlaGxl d2luZCB3cm90ZToNCj4gDQo+PiBNaXJqYSBLw7xobGV3aW5kIGhhcyBlbnRlcmVkIHRoZSBmb2xs b3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPj4gZHJhZnQtaWV0Zi1pY2UtZHVhbHN0YWNrLWZh aXJuZXNzLTA2OiBObyBPYmplY3Rpb24NCj4+IA0KPj4gDQo+PiBUaGFua3MgZm9yIGFkZHJlc3Np bmcgbXkgY29tbWVudHMgYW5kIGFsc28gbm90IHRhbGtpbmcgYWJvdXQgZmFpcm5lc3MNCj4+IGFu eW1vcmUuDQoNCk5vIHdvcnJpZXMuIERvY3VtZW50IHR1cm5lZCBvdXQgbXVjaCBiZXR0ZXIgc28g dGhhbmtzIGZvciB0aGF0LiANCg0KPj4gVGhlcmUgYXJlIHNvbWUgbW9yZSBjb25jcmV0ZSByZWNv bW1lbmRhdGlvbnMgbm93IGJ1dCBzb21lIGFyZQ0KPj4gc3RpbGwgdmFndWUuDQo+PiANCkkgdGVu ZCB0byBhZ3JlZS4gTXkgdXN1YWwgZXhjdXNlIGlzIFdHIOKAnGNvbnN0cmFpbnRz4oCdLiANCihB Y3R1YWwg4oCcdGhyZWF0cyIgaW4gdGhlIGhhbGx3YXlzIHRvIGJlIG5pdHBpY2tlZCB1bnRpbCBJ RVRGIGlzIG5vIGxvbmdlciBvcGVyYXRpbmcuLiApDQoNCg0KPj4gSSB3b3VsZCBzdGlsbCBsaWtl IHRvIHByb3Bvc2VkIHRoZSBmb2xsb3dpbmcgYWRkaXRpb24gdG8gdGhlIGludHJvOg0KPj4gDQo+ PiBPTEQ6DQo+PiAiVG8gYXZvaWQgc3VjaCB1c2VyIG5vdGljZWFibGUgZGVsYXlzIHdoZW4gZWl0 aGVyIElQdjYgb3IgSVB2NCBwYXRoIGlzDQo+PiAgIGJyb2tlbiBvciBleGNlc3NpdmVseSBzbG93 LCB0aGlzIHNwZWNpZmljYXRpb24gZW5jb3VyYWdlcw0KPj4gICBpbnRlcm1pbmdsaW5nIHRoZSBk aWZmZXJlbnQgYWRkcmVzcyBmYW1pbGllcyB3aGVuIGNvbm5lY3Rpdml0eSBjaGVja3MNCj4+ICAg YXJlIHBlcmZvcm1lZC4gIFRoaXMgd2lsbCBsZWFkIHRvIG1vcmUgc3VzdGFpbmVkIGR1YWwtc3Rh Y2sgSVB2NC9JUHY2DQo+PiAgIGRlcGxveW1lbnQgYXMgdXNlcnMgd2lsbCBubyBsb25nZXIgaGF2 ZSBhbiBpbmNlbnRpdmUgdG8gZGlzYWJsZSBJUHY2Lg0KPj4gICBUaGUgY29zdCBpcyBhIHNtYWxs IHBlbmFsdHkgdG8gdGhlIGFkZHJlc3MgdHlwZSB0aGF0IG90aGVyd2lzZSB3b3VsZA0KPj4gICBo YXZlIGJlZW4gcHJpb3JpdGl6ZWQuIg0KPj4gDQo+PiBORVc6DQo+PiAiVG8gYXZvaWQgdXNlciBu b3RpY2VhYmxlIGRlbGF5cyB3aGVuIGVpdGhlciBJUHY2IG9yIElQdjQgcGF0aCBpcw0KPj4gICBi cm9rZW4gb3IgZXhjZXNzaXZlbHkgc2xvdywgdGhpcyBzcGVjaWZpY2F0aW9uIGVuY291cmFnZXMN Cj4+ICAgaW50ZXJtaW5nbGluZyB0aGUgZGlmZmVyZW50IGFkZHJlc3MgZmFtaWxpZXMgd2hlbiBj b25uZWN0aXZpdHkgY2hlY2tzDQo+PiAgIGFyZSBwZXJmb3JtZWQuICBUaGlzIHdpbGwgbGVhZCB0 byBtb3JlIHN1c3RhaW5lZCBkdWFsLXN0YWNrIElQdjQvSVB2Ng0KPj4gICBkZXBsb3ltZW50IGFz IHVzZXJzIHdpbGwgbm8gbG9uZ2VyIGhhdmUgYW4gaW5jZW50aXZlIHRvIGRpc2FibGUgSVB2Ni4N Cj4+ICAgVGhlIGNvc3QgaXMgYSBzbWFsbCBwZW5hbHR5IHRvIHRoZSBhZGRyZXNzIHR5cGUgdGhh dCBvdGhlcndpc2Ugd291bGQNCj4+ICAgaGF2ZSBiZWVuIHByaW9yaXRpemVkLiBGdXJ0aGVyIHRo aXMgZG9jdW1lbnQgcmVjb21tZW5kcyB0byBrZWVwDQo+PiAgIHRyYWNrIG9mIHByZXZpb3VzIGtu b3duIGNvbm5lY3Rpdml0eSBwcm9ibGVtIGFuZCBhc3NpZ24gYSBsb3dlcg0KPj4gICBwcmlvcml0 eSB0byB0aG9zZSBhZGRyZXNzZXMu4oCdDQo+PiANCg0KRG9uZQ0KDQo+PiBNYXliZSBldmVuIGFk ZDoNCj4+ICJUcmFja2luZyBjb25uZWN0aXZpdHkgaXMgYSBxdWVzdGlvbiBvbiBpdHMgb3duIGFu ZCBvdXQgb2Ygc2NvcGUgZm9yDQo+PiAgIHRoaXMgZG9jdW1lbnQuIg0KPiANCj4gVGhpcyBzZWVt cyByZWFzb25hYmxlLiBJIG1pZ2h0IHN1Z2dlc3QgdGhlIGxhc3Qgc2VudGVuY2UgYmUgc29tZXRo aW5nIHRvIHRoZSBlZmZlY3Qgb2Y6DQo+IA0KPiDigJxTcGVjaWZpYyBtZWNoYW5pc21zIGFuZCBy dWxlcyBmb3IgdHJhY2tpbmcgY29ubmVjdGl2aXR5IGlzc3VlcyBhcmUgb3V0IG9mIHNjb3BlIGZv ciB0aGlzIGRvY3VtZW50Ig0KPiANCg0KRG9uZS4NCg0KDQpOZXcgdmVyc2lvbiAoLTA3KSBpcyBy ZWFkeS4gQnV0IG5vdCB1cGxvYWRlZC4uDQpVbmxlc3MgdGhlIGNoYWlycyBvciBBRHMgYXJlIGlu IGEgaHVycnkgdGhpcyBjYW4gcHJvYmFibHkgd2FpdCBhcyB0aGlzIHdpbGwgYmUgcHVibGlzaGVk IHRvZ2V0aGVyIHdpdGggSUNFYmlzLg0KDQpDYW4gZWFzaWx5IHNlbmQgeG1sIGFuZCB0eHQgZmls ZSBpZiBuZWVkZWQuDQoNCi4tLg0KUMOlbC1FcmlrDQoNCj4gVGhhbmtzIQ0KPiANCj4gQmVuLg0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g SWNlIG1haWxpbmcgbGlzdA0KPiBJY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pY2UNCg0K From nobody Mon Nov 7 05:51:26 2016 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 C9F6E12967D for ; Mon, 7 Nov 2016 05:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAQEU9LwaPNh for ; Mon, 7 Nov 2016 05:51:23 -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 0A829129640 for ; Mon, 7 Nov 2016 05:51:22 -0800 (PST) X-AuditID: c1b4fb30-f60a598000000cb2-18-582086d92694 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 15.3F.03250.9D680285; Mon, 7 Nov 2016 14:51:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 14:51:17 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: check list for first media stream Thread-Index: AQHSOP4DxF6FAUcNHUSS7cC2vWDCpg== Date: Mon, 7 Nov 2016 13:51:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D446554B12B37christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7q+7NNoUIg2vP5Sy+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGgZNT2Av2i1W8ePuSpYFxqXAXIyeHhICJxMpXbaxdjFwcQgLr GCUW3XjPBuEsZpTYenY/kMPBwSZgIdH9TxukQURAUWJmyzNmEFtYwFjiSeskNoi4hcTpvu2M ELaexJTNjYwgrSwCKhIL2jNBwrwC1hLbvpxkBbEZBcQkvp9awwRiMwuIS9x6Mp8J4h4BiSV7 zjND2KISLx//YwUZIwo0cs39MIiwosTV6cuhWhMkuhe0M0KMF5Q4OfMJywRGoVlIps5CUjYL SRlE3EDi/bn5zBC2tsSyha+hbH2JjV/OMkLY1hIdv/6wIqtZwMixilG0OLU4KTfdyEgvtSgz ubg4P08vL7VkEyMwSg5u+W2wg/Hlc8dDjAIcjEo8vAWu8hFCrIllxZW5hxglOJiVRHj5axUi hHhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamBkuyb1n2NL a0BUVv7mZZmy/FPT3u5v9li53HZl0/Gbz41bt8xduEqPjzHeUUQqpTXxe9Bk0StylS4yJ4Kk ZnB1JaV6bvnksqhn47mv91Y+31xwc87mA3fYXHgnNSp9jBdUWtv8S/TBDqtXbu4t00N+cD76 vKe3paJjm/yBBy9WVGoJK1R8PWigxFKckWioxVxUnAgAGNRo344CAAA= Archived-At: Subject: [Ice] 5245bis: check list for first media stream X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 13:51:25 -0000 --_000_D446554B12B37christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, If I understand section 5.1.3.4 of 5245bis correctly, initially there will = only be one active check list (the check list associated with the =93first = media stream=94 - whatever that means). All other check lists will be froze= n. Then, based on my understanding of section 6.1.2.4.3, other checks lists wo= n=92t become active until all pairs in the previous check list have become = either Succeeded or Failed. Q1: What is the reason for =93activating=94 only one check list, and keep t= he others frozen, instead of activating all check lists at the same time? Regards, Christer --_000_D446554B12B37christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6D559F8CE2A0B5449601880649228967@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

If I understand section 5.1.3.4 of 5245bis correctly, initially there will = only be one active check list (the check list associated with the =93first = media stream=94 - whatever that means). All other check lists will be froze= n.

The= n, based on my understanding of section 6.1.2.4.3, other checks lists won=92t become active until all pairs in the previous check list have beco= me either Succeeded or Failed.

Q1: What is the reason for =93activat= ing=94 only one check list, and keep the others frozen, instead of activati= ng all check lists at the same time?

Regards,

Christer
--_000_D446554B12B37christerholmbergericssoncom_-- From nobody Mon Nov 7 06:01:34 2016 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 105D5129643 for ; Mon, 7 Nov 2016 06:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AVcUu8xjLVo for ; Mon, 7 Nov 2016 06:01:31 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD08D129526 for ; Mon, 7 Nov 2016 06:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8866; q=dns/txt; s=iport; t=1478527290; x=1479736890; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l6iVEB4aN7NHbVrmaLnVi4tpmv/dwt2pupyoPCNpcJ4=; b=aq3PYahyoo88D2s0DzcI0tCabAhQ2oAPHBhJEIUNL3m7LiIFSnmy8qQK t8Q2TpP9+Vf7mdeJPUOdqvoDcekBqiwDaSgVe4QkwKcQN6ibyOSkaljdm xwc64yA4u7g4E47VFgnpVna74con2pqoiyV/9Nvx1AxTkt0MWzWH0pojm g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AwADiCBY/4wNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnM7AQEBAQEfWHwHs2mFGoIIHgEKhXsCGoFsQBMBAgEBAQEBAQFiKIR?= =?us-ascii?q?iAQEEAQEBIEsLEAIBCD8DAgICJQsUEQIEDgWIWA6xRIJAiz4BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEXBYY+gX2CWIQqAQFRgk4tgi8FiEWHTIoWAZBDCpAGjSqEBQE?= =?us-ascii?q?fATUoUhuFD3IBhVuBIYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,606,1473120000"; d="scan'208,217";a="171356111" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2016 14:01:29 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uA7E1TnP002592 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2016 14:01:29 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 09:01:29 -0500 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1210.000; Mon, 7 Nov 2016 09:01:29 -0500 From: "Pal Martinsen (palmarti)" To: Christer Holmberg Thread-Topic: [Ice] 5245bis: active and frozen check lists Thread-Index: AQHSOMlKI+Ewb+mCTUeB9HElk7Zj+aDN4RyA Date: Mon, 7 Nov 2016 14:01:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.225.6] Content-Type: multipart/alternative; boundary="_000_E6D3720ACDB5412AB05DE6333EC1D068ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: active and frozen check lists X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 14:01:33 -0000 --_000_E6D3720ACDB5412AB05DE6333EC1D068ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiA3IE5vdiAyMDE2LCBhdCAwODozMywgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t Pj4gd3JvdGU6DQoNCkhpLA0KDQpTZWN0aW9uIDUuMS4zLjQgb2YgNTI0NWJpcyBkZWZpbmVzIHRo ZSBmb2xsb3dpbmcgY2hlY2sgbGlzdCBzdGF0ZXM6IHJ1bm5pbmcsIGNvbXBsZXRlZCwgZmFpbGVk Lg0KDQoNCiBUaGUgY2hlY2sgbGlzdCBpdHNlbGYgaXMgYXNzb2NpYXRlZCB3aXRoIGEgc3RhdGUs IHdoaWNoIGNhcHR1cmVzIHRoZQ0KICAgc3RhdGUgb2YgSUNFIGNoZWNrcyBmb3IgdGhhdCBtZWRp YSBzdHJlYW0uICBUaGVyZSBhcmUgdGhyZWUgc3RhdGVzOg0KDQogICBSdW5uaW5nOiAgSW4gdGhp cyBzdGF0ZSwgSUNFIGNoZWNrcyBhcmUgc3RpbGwgaW4gcHJvZ3Jlc3MgZm9yIHRoaXMNCiAgICAg IG1lZGlhIHN0cmVhbS4NCg0KICAgQ29tcGxldGVkOiAgSW4gdGhpcyBzdGF0ZSwgSUNFIGNoZWNr cyBoYXZlIHByb2R1Y2VkIG5vbWluYXRlZCBwYWlycw0KICAgICAgZm9yIGVhY2ggY29tcG9uZW50 IG9mIHRoZSBtZWRpYSBzdHJlYW0uDQoNCiAgIEZhaWxlZDogIEluIHRoaXMgc3RhdGUsIHRoZSBJ Q0UgY2hlY2tzIGhhdmUgbm90IGNvbXBsZXRlZA0KICAgICAgc3VjY2Vzc2Z1bGx5IGZvciB0aGlz IG1lZGlhIHN0cmVhbS4NCg0KDQpIb3dldmVyLCB0aGUgc2VjdGlvbiBhbHNvIGRlZmluZXMgdHdv IOKAnHR5cGVz4oCdIG9mIGNoZWNrIGxpc3RzOiBhY3RpdmUgY2hlY2sgbGlzdCBhbmQgZnJvemVu IGNoZWNrIGxpc3QuDQoNCg0KICAgT25lIG9mIHRoZSBjaGVjayBsaXN0cyB3aWxsIGhhdmUgc29t ZSBudW1iZXIgb2YgcGFpcnMgaW4gdGhlIFdhaXRpbmcNCiAgIHN0YXRlLCBhbmQgdGhlIG90aGVy IGNoZWNrIGxpc3RzIHdpbGwgaGF2ZSBhbGwgb2YgdGhlaXIgcGFpcnMgaW4gdGhlDQogICBGcm96 ZW4gc3RhdGUuICBBIGNoZWNrIGxpc3Qgd2l0aCBhdCBsZWFzdCBvbmUgcGFpciB0aGF0IGlzIFdh aXRpbmcgaXMNCiAgIGNhbGxlZCBhbiBhY3RpdmUgY2hlY2sgbGlzdCwgYW5kIGEgY2hlY2sgbGlz dCB3aXRoIGFsbCBwYWlycyBGcm96ZW4NCiAgIGlzIGNhbGxlZCBhIGZyb3plbiBjaGVjayBsaXN0 Lg0KDQpRMTogV2h5IGNhbuKAmXQgRnJvemVuIHNpbXBseSBiZSBhIGNoZWNrIGxpc3Qgc3RhdGU/ DQoNCisxIFRoaXMgaGF2ZSBiZWVuIGRpc2N1c3NlZCBiZWZvcmUuLg0KDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2ljZS9jdXJyZW50L21zZzAwMDY0Lmh0bWwNCg0KDQoN ClEyOiBXaGF04oCZcyB0aGUgc3RhdGUgb2YgYSBGcm96ZW4gY2hlY2sgbGlzdD8NCg0KDQpSdW5u aW5nPyAoQnV0IGZyb3plbik/DQoNCg0KUTM6IFdoYXTigJlzIHRoZSBkaWZmZXJlbmNlIGJldHdl ZW4gYW4gYWN0aXZlIGNoZWNrIGxpc3QgYW5kIGFuIGNoZWNrIGxpc3QgaW4gUnVubmluZyBzdGF0 ZT8NCg0KDQpObyBpZGVhLi4NCg0KLi0uDQpQw6VsLUVyaWsNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJY2Ug bWFpbGluZyBsaXN0DQpJY2VAaWV0Zi5vcmc8bWFpbHRvOkljZUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlDQoNCg== --_000_E6D3720ACDB5412AB05DE6333EC1D068ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7E80D0DE64B96042B921CCACF4C83078@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiA3IE5v diAyMDE2LCBhdCAwODozMywgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIGNsYXNzPSIiPmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSw8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNlY3Rpb24gNS4x LjMuNCBvZiA1MjQ1YmlzIGRlZmluZXMgdGhlIGZvbGxvd2luZyBjaGVjayBsaXN0IHN0YXRlczog cnVubmluZywgY29tcGxldGVkLCBmYWlsZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1s aWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyB3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiIGNsYXNzPSIiPiBUaGUgY2hlY2sgbGlzdCBp dHNlbGYgaXMgYXNzb2NpYXRlZCB3aXRoIGEgc3RhdGUsIHdoaWNoIGNhcHR1cmVzIHRoZQ0KICAg c3RhdGUgb2YgSUNFIGNoZWNrcyBmb3IgdGhhdCBtZWRpYSBzdHJlYW0uICBUaGVyZSBhcmUgdGhy ZWUgc3RhdGVzOg0KDQogICA8YiBjbGFzcz0iIj5SdW5uaW5nPC9iPjogIEluIHRoaXMgc3RhdGUs IElDRSBjaGVja3MgYXJlIHN0aWxsIGluIHByb2dyZXNzIGZvciB0aGlzDQogICAgICBtZWRpYSBz dHJlYW0uDQoNCiAgIDxiIGNsYXNzPSIiPkNvbXBsZXRlZDwvYj46ICBJbiB0aGlzIHN0YXRlLCBJ Q0UgY2hlY2tzIGhhdmUgcHJvZHVjZWQgbm9taW5hdGVkIHBhaXJzDQogICAgICBmb3IgZWFjaCBj b21wb25lbnQgb2YgdGhlIG1lZGlhIHN0cmVhbS4NCg0KICAgPGIgY2xhc3M9IiI+RmFpbGVkPC9i PjogIEluIHRoaXMgc3RhdGUsIHRoZSBJQ0UgY2hlY2tzIGhhdmUgbm90IGNvbXBsZXRlZA0KICAg ICAgc3VjY2Vzc2Z1bGx5IGZvciB0aGlzIG1lZGlhIHN0cmVhbS4NCjwvcHJlPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Ib3dldmVy LCB0aGUgc2VjdGlvbiBhbHNvIGRlZmluZXMgdHdvIOKAnHR5cGVz4oCdIG9mIGNoZWNrIGxpc3Rz OiBhY3RpdmUgY2hlY2sgbGlzdCBhbmQgZnJvemVuIGNoZWNrIGxpc3QuPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwcmUgc3R5bGU9 ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyB3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiIGNsYXNzPSIiPiAg IE9uZSBvZiB0aGUgY2hlY2sgbGlzdHMgd2lsbCBoYXZlIHNvbWUgbnVtYmVyIG9mIHBhaXJzIGlu IHRoZSBXYWl0aW5nDQogICBzdGF0ZSwgYW5kIHRoZSBvdGhlciBjaGVjayBsaXN0cyB3aWxsIGhh dmUgYWxsIG9mIHRoZWlyIHBhaXJzIGluIHRoZQ0KICAgRnJvemVuIHN0YXRlLiAgQSBjaGVjayBs aXN0IHdpdGggYXQgbGVhc3Qgb25lIHBhaXIgdGhhdCBpcyBXYWl0aW5nIGlzDQogICBjYWxsZWQg YW4gPGIgY2xhc3M9IiI+YWN0aXZlIGNoZWNrIGxpc3Q8L2I+LCBhbmQgYSBjaGVjayBsaXN0IHdp dGggYWxsIHBhaXJzIEZyb3plbg0KICAgaXMgY2FsbGVkIGEgPGIgY2xhc3M9IiI+ZnJvemVuIGNo ZWNrIGxpc3Q8L2I+LjwvcHJlPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YiBjbGFzcz0iIj5RMTwvYj46PHNwYW4gY2xhc3M9IkFw cGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj4NCjwvc3Bhbj5XaHkgY2Fu4oCZ dCBGcm96ZW4gc2ltcGx5IGJlIGEgY2hlY2sgbGlzdCBzdGF0ZT88L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KJiM0MzsxIFRo aXMgaGF2ZSBiZWVuIGRpc2N1c3NlZCBiZWZvcmUuLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9pY2UvY3VycmVudC9tc2cwMDA2NC5odG1sIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL2ljZS9jdXJyZW50L21zZzAwMDY0Lmh0bWw8L2E+PC9kaXY+ DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1s aW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+UTI8L2I+OiBXaGF04oCZ cyB0aGUgc3RhdGUgb2YgYSBGcm96ZW4gY2hlY2sgbGlzdD88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClJ1bm5pbmc/IChCdXQgZnJvemVuKT88L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQt d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YiBjbGFzcz0iIj5RMzwvYj46IFdoYXTigJlzIHRoZSBkaWZmZXJlbmNlIGJl dHdlZW4gYW4gYWN0aXZlIGNoZWNrIGxpc3QgYW5kIGFuIGNoZWNrIGxpc3QgaW4gUnVubmluZyBz dGF0ZT88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCk5vIGlk ZWEuLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Li0uPC9kaXY+DQo8 ZGl2PlDDpWwtRXJpazxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5SZWdhcmRz LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+Q2hyaXN0ZXI8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy IGNsYXNzPSIiPg0KSWNlIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0 bzpJY2VAaWV0Zi5vcmciIGNsYXNzPSIiPkljZUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZTxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_E6D3720ACDB5412AB05DE6333EC1D068ciscocom_-- From nobody Mon Nov 7 06:24:02 2016 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 D3AE51296D6 for ; Mon, 7 Nov 2016 06:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 GfYb_pY141VO for ; Mon, 7 Nov 2016 06:23:58 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63134129689 for ; Mon, 7 Nov 2016 06:23:57 -0800 (PST) Received: (qmail 13668 invoked from network); 7 Nov 2016 15:16:31 +0100 Received: from public-docking-pat-etx-mapped-0004.ethz.ch (HELO ?10.2.113.239?) (195.176.110.229) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 7 Nov 2016 15:16:30 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Mon, 7 Nov 2016 15:16:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147808133311.24126.15765271660818591137.idtracker@ietfa.amsl.com> To: "Pal Martinsen (palmarti)" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Ben Campbell , =?utf-8?Q?Ari_Ker=C3=A4nen?= , "draft-ietf-ice-dualstack-fairness@ietf.org" , "ice-chairs@ietf.org" , "ice@ietf.org" , The IESG Subject: Re: [Ice] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-ice-dualstack-fairness-06=3A_=28with_COMMENT=29?= X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 14:24:00 -0000 Sounds good! Thx! Mirja > Am 07.11.2016 um 14:33 schrieb Pal Martinsen (palmarti) = : >=20 >=20 >=20 >=20 >> On 2 Nov 2016, at 15:50, Ben Campbell wrote: >>=20 >> On 2 Nov 2016, at 5:08, Mirja Kuehlewind wrote: >>=20 >>> Mirja K=C3=BChlewind has entered the following ballot position for >>> draft-ietf-ice-dualstack-fairness-06: No Objection >>>=20 >>>=20 >>> Thanks for addressing my comments and also not talking about = fairness >>> anymore. >=20 > No worries. Document turned out much better so thanks for that.=20 >=20 >>> There are some more concrete recommendations now but some are >>> still vague. >>>=20 > I tend to agree. My usual excuse is WG =E2=80=9Cconstraints=E2=80=9D.=20= > (Actual =E2=80=9Cthreats" in the hallways to be nitpicked until IETF = is no longer operating.. ) >=20 >=20 >>> I would still like to proposed the following addition to the intro: >>>=20 >>> OLD: >>> "To avoid such user noticeable delays when either IPv6 or IPv4 path = is >>> broken or excessively slow, this specification encourages >>> intermingling the different address families when connectivity = checks >>> are performed. This will lead to more sustained dual-stack = IPv4/IPv6 >>> deployment as users will no longer have an incentive to disable = IPv6. >>> The cost is a small penalty to the address type that otherwise = would >>> have been prioritized." >>>=20 >>> NEW: >>> "To avoid user noticeable delays when either IPv6 or IPv4 path is >>> broken or excessively slow, this specification encourages >>> intermingling the different address families when connectivity = checks >>> are performed. This will lead to more sustained dual-stack = IPv4/IPv6 >>> deployment as users will no longer have an incentive to disable = IPv6. >>> The cost is a small penalty to the address type that otherwise = would >>> have been prioritized. Further this document recommends to keep >>> track of previous known connectivity problem and assign a lower >>> priority to those addresses.=E2=80=9D >>>=20 >=20 > Done >=20 >>> Maybe even add: >>> "Tracking connectivity is a question on its own and out of scope for >>> this document." >>=20 >> This seems reasonable. I might suggest the last sentence be something = to the effect of: >>=20 >> =E2=80=9CSpecific mechanisms and rules for tracking connectivity = issues are out of scope for this document" >>=20 >=20 > Done. >=20 >=20 > New version (-07) is ready. But not uploaded.. > Unless the chairs or ADs are in a hurry this can probably wait as this = will be published together with ICEbis. >=20 > Can easily send xml and txt file if needed. >=20 > .-. > P=C3=A5l-Erik >=20 >> Thanks! >>=20 >> Ben. >>=20 >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >=20 From nobody Mon Nov 7 07:47:57 2016 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 40B4D12941E for ; Mon, 7 Nov 2016 07:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCsbTix8PANC for ; Mon, 7 Nov 2016 07:47:49 -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 6B1ED1200DF for ; Mon, 7 Nov 2016 07:47:46 -0800 (PST) X-AuditID: c1b4fb25-d35ee98000001e3e-b7-5820a22049f4 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id D3.B3.07742.022A0285; Mon, 7 Nov 2016 16:47:44 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.241]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 16:47:44 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: "Pal Martinsen (palmarti)" , Christer Holmberg Thread-Topic: [Ice] 5245bis: active and frozen check lists Thread-Index: AQHSOMlKI+Ewb+mCTUeB9HElk7Zj+aDN4RyA//+5G4A= Date: Mon, 7 Nov 2016 15:47:43 +0000 Message-ID: <63E6B9DE-EFBB-47A8-9529-2DB13358EA53@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbHdUldhkUKEwdt5WhbfLtRavL++ksWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyjh1qYu94IRIxaUDNxgbGFtEuhg5OSQETCSm zZrE3sXIxSEksI5R4kHHe2YIZzGjREfHBxaQKjYBW4knrftYQWwRgUyJAwtuA3VwcDALKEq8 3KsGYgoLWEoce6MCYooIWEmsO5gKUWwl0fHuHBOIzSKgInG9cw/YQF4Be4nXTzexgdhCAnkS p3/uB7M5gRa1PT8EVsMoICbx/dQasF5mAXGJW0/mM0GcLCCxZM95ZghbVOLl43+sELaSxIrt lxghDtOUWL9LH6LVWmLjwsXMELaixJTuh+wQJwhKnJz5hGUCo9gsJBtmIXTPQtI9C0n3LCTd CxhZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIERtPBLb9VdzBefuN4iFGAg1GJh/fDNIUI IdbEsuLK3EOMEhzMSiK8bQuBQrwpiZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJzU5N LUgtgskycXBKNTAy5P1qrZ55Z1+CeObvCOkvG3Yvu5e+INJ06m+7R0eq+FNDo1P2ucYn/c+X /Hvx1KpPuxne5Lia2Jhs2r7jXHYIH8+1G2fEGFsMrwRla282EeYOS4zvcfvsoxdjVPelplXV RHz3UbeJ4vnciu6Pl9WUyj6Q016+TdaELXOtwOqZfxfXfHWPeKLEUpyRaKjFXFScCACvV6hM ogIAAA== Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: active and frozen check lists X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 15:47:56 -0000 DQo+IE9uIDA3IE5vdiAyMDE2LCBhdCAxNjowMSwgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpIDxw YWxtYXJ0aUBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4gDQo+PiBPbiA3IE5vdiAyMDE2LCBhdCAw ODozMywgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4g d3JvdGU6DQo+PiANCj4+IEhpLA0KPj4gDQo+PiBTZWN0aW9uIDUuMS4zLjQgb2YgNTI0NWJpcyBk ZWZpbmVzIHRoZSBmb2xsb3dpbmcgY2hlY2sgbGlzdCBzdGF0ZXM6IHJ1bm5pbmcsIGNvbXBsZXRl ZCwgZmFpbGVkLg0KPj4gDQo+PiAgVGhlIGNoZWNrIGxpc3QgaXRzZWxmIGlzIGFzc29jaWF0ZWQg d2l0aCBhIHN0YXRlLCB3aGljaCBjYXB0dXJlcyB0aGUNCj4+ICAgIHN0YXRlIG9mIElDRSBjaGVj a3MgZm9yIHRoYXQgbWVkaWEgc3RyZWFtLiAgVGhlcmUgYXJlIHRocmVlIHN0YXRlczoNCj4+IA0K Pj4gICAgDQo+PiBSdW5uaW5nDQo+PiA6ICBJbiB0aGlzIHN0YXRlLCBJQ0UgY2hlY2tzIGFyZSBz dGlsbCBpbiBwcm9ncmVzcyBmb3IgdGhpcw0KPj4gICAgICAgbWVkaWEgc3RyZWFtLg0KPj4gDQo+ PiAgICANCj4+IENvbXBsZXRlZA0KPj4gOiAgSW4gdGhpcyBzdGF0ZSwgSUNFIGNoZWNrcyBoYXZl IHByb2R1Y2VkIG5vbWluYXRlZCBwYWlycw0KPj4gICAgICAgZm9yIGVhY2ggY29tcG9uZW50IG9m IHRoZSBtZWRpYSBzdHJlYW0uDQo+PiANCj4+ICAgIA0KPj4gRmFpbGVkDQo+PiA6ICBJbiB0aGlz IHN0YXRlLCB0aGUgSUNFIGNoZWNrcyBoYXZlIG5vdCBjb21wbGV0ZWQNCj4+ICAgICAgIHN1Y2Nl c3NmdWxseSBmb3IgdGhpcyBtZWRpYSBzdHJlYW0uDQo+PiANCj4+IA0KPj4gSG93ZXZlciwgdGhl IHNlY3Rpb24gYWxzbyBkZWZpbmVzIHR3byDigJx0eXBlc+KAnSBvZiBjaGVjayBsaXN0czogYWN0 aXZlIGNoZWNrIGxpc3QgYW5kIGZyb3plbiBjaGVjayBsaXN0Lg0KPj4gDQo+PiAgICBPbmUgb2Yg dGhlIGNoZWNrIGxpc3RzIHdpbGwgaGF2ZSBzb21lIG51bWJlciBvZiBwYWlycyBpbiB0aGUgV2Fp dGluZw0KPj4gICAgc3RhdGUsIGFuZCB0aGUgb3RoZXIgY2hlY2sgbGlzdHMgd2lsbCBoYXZlIGFs bCBvZiB0aGVpciBwYWlycyBpbiB0aGUNCj4+ICAgIEZyb3plbiBzdGF0ZS4gIEEgY2hlY2sgbGlz dCB3aXRoIGF0IGxlYXN0IG9uZSBwYWlyIHRoYXQgaXMgV2FpdGluZyBpcw0KPj4gICAgY2FsbGVk IGFuIA0KPj4gYWN0aXZlIGNoZWNrIGxpc3QNCj4+ICwgYW5kIGEgY2hlY2sgbGlzdCB3aXRoIGFs bCBwYWlycyBGcm96ZW4NCj4+ICAgIGlzIGNhbGxlZCBhIA0KPj4gZnJvemVuIGNoZWNrIGxpc3Qu DQo+PiANCj4+IFExOg0KPj4gV2h5IGNhbuKAmXQgRnJvemVuIHNpbXBseSBiZSBhIGNoZWNrIGxp c3Qgc3RhdGU/DQo+IA0KPiArMSBUaGlzIGhhdmUgYmVlbiBkaXNjdXNzZWQgYmVmb3JlLi4NCj4g DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWNlL2N1cnJlbnQvbXNn MDAwNjQuaHRtbA0KDQorMS4gVW5sZXNzIHNvbWVvbmUgb2JqZWN0cywgbGV0J3MgbWFrZSB0aGF0 IGNoYW5nZS4NCg0KPiANCj4+IA0KPj4gUTI6IFdoYXTigJlzIHRoZSBzdGF0ZSBvZiBhIEZyb3pl biBjaGVjayBsaXN0Pw0KPj4gDQo+IA0KPiBSdW5uaW5nPyAoQnV0IGZyb3plbik/DQoNCklmIHdl IGRvIHRoZSBjaGFuZ2UgYWJvdmUsIHRoYXQnZCBiZSBGcm96ZW4gKHJpZ2h0PykuDQoNCj4gDQo+ PiBRMzogV2hhdOKAmXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhbiBhY3RpdmUgY2hlY2sgbGlz dCBhbmQgYW4gY2hlY2sgbGlzdCBpbiBSdW5uaW5nIHN0YXRlPw0KPj4gDQo+IA0KPiBObyBpZGVh Li4NCg0KU2VlbXMgdGhlcmUncyBubyBkaWZmZXJlbmNlLiBNaWdodCBiZSB3b3J0aHdoaWxlIHRv IHVuaWZ5IHRlcm1pbm9sb2d5IGhlcmUuDQoNCg0KQ2hlZXJzLA0KQXJp From nobody Mon Nov 7 10:40:27 2016 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 D82231293E9 for ; Mon, 7 Nov 2016 10:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtmOZLDHYaeL for ; Mon, 7 Nov 2016 10:40:25 -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 1C6BF1293DB for ; Mon, 7 Nov 2016 10:40:24 -0800 (PST) X-AuditID: c1b4fb3a-83dd4980000070a2-22-5820ca977a98 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 1C.BC.28834.79AC0285; Mon, 7 Nov 2016 19:40:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 19:40:21 +0100 From: Christer Holmberg To: =?utf-8?B?QXJpIEtlcsOkbmVu?= , "Pal Martinsen (palmarti)" Thread-Topic: [Ice] 5245bis: active and frozen check lists Thread-Index: AQHSOMlKI+Ewb+mCTUeB9HElk7Zj+aDN4RyA//+5G4CAAEAVwA== Date: Mon, 7 Nov 2016 18:40:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE27384@ESESSMB209.ericsson.se> References: <63E6B9DE-EFBB-47A8-9529-2DB13358EA53@ericsson.com> In-Reply-To: <63E6B9DE-EFBB-47A8-9529-2DB13358EA53@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2J7iO70UwoRBo83K1l8u1Br8f76ShYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK+PwlOksBctEK85ducTewPhApIuRk0NCwETi 4ZwG9i5GLg4hgXWMEl+n/oFyFjNKvP3ZD+RwcLAJWEh0/9MGaRARyJN4uHcCG0iYWUBR4uVe NZCwsIClxPpXR5hAwiICVhLrDqZCVDtJTNv1jRnEZhFQkfjx5QUbiM0r4CvR2drKDLFpCdDa h9vAEpwCDhL9J+cxgtiMAmIS30+tYQKxmQXEJW49mc8EcbOAxJI955khbFGJl4//sULYShJr D29ngThNU2L9Ln2IVkWJKd0P2SH2CkqcnPmEZQKj6CwkU2chdMxC0jELSccCRpZVjKLFqcXF uelGRnqpRZnJxcX5eXp5qSWbGIHxcXDLb6sdjAefOx5iFOBgVOLh/TBNIUKINbGsuDL3EKME B7OSCG/NSaAQb0piZVVqUX58UWlOavEhRmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwcnFIN jC2H+F+rXNLzdExmz8ueKGBvsDqfv3PC4fVntPo1pTjusUpax/190xalzjjplMLDmqjWT2EM KQcU3nwvURdvl1JatmaffuLn0zd5ODuvfgjfsl+4O/Js0fWGbJuYzkBHE5bYwuJA/oNyHy9Z OSppRsxnevDm6LFfyiwFG2cfMg+W4ElytNurxFKckWioxVxUnAgAFd6ytIsCAAA= Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: active and frozen check lists X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 18:40:27 -0000 SGksDQoNCj4+PiBTZWN0aW9uIDUuMS4zLjQgb2YgNTI0NWJpcyBkZWZpbmVzIHRoZSBmb2xsb3dp bmcgY2hlY2sgbGlzdCBzdGF0ZXM6IHJ1bm5pbmcsIGNvbXBsZXRlZCwgZmFpbGVkLg0KPj4+IA0K Pj4+ICBUaGUgY2hlY2sgbGlzdCBpdHNlbGYgaXMgYXNzb2NpYXRlZCB3aXRoIGEgc3RhdGUsIHdo aWNoIGNhcHR1cmVzIHRoZQ0KPj4+ICAgIHN0YXRlIG9mIElDRSBjaGVja3MgZm9yIHRoYXQgbWVk aWEgc3RyZWFtLiAgVGhlcmUgYXJlIHRocmVlIHN0YXRlczoNCj4+PiANCj4+PiAgICANCj4+PiBS dW5uaW5nDQo+Pj4gOiAgSW4gdGhpcyBzdGF0ZSwgSUNFIGNoZWNrcyBhcmUgc3RpbGwgaW4gcHJv Z3Jlc3MgZm9yIHRoaXMNCj4+PiAgICAgICBtZWRpYSBzdHJlYW0uDQo+Pj4gDQo+Pj4gICAgDQo+ Pj4gQ29tcGxldGVkDQo+Pj4gOiAgSW4gdGhpcyBzdGF0ZSwgSUNFIGNoZWNrcyBoYXZlIHByb2R1 Y2VkIG5vbWluYXRlZCBwYWlycw0KPj4+ICAgICAgIGZvciBlYWNoIGNvbXBvbmVudCBvZiB0aGUg bWVkaWEgc3RyZWFtLg0KPj4+IA0KPj4+ICAgIA0KPj4+IEZhaWxlZA0KPj4+IDogIEluIHRoaXMg c3RhdGUsIHRoZSBJQ0UgY2hlY2tzIGhhdmUgbm90IGNvbXBsZXRlZA0KPj4+ICAgICAgIHN1Y2Nl c3NmdWxseSBmb3IgdGhpcyBtZWRpYSBzdHJlYW0uDQo+Pj4gDQo+Pj4gDQo+Pj4gSG93ZXZlciwg dGhlIHNlY3Rpb24gYWxzbyBkZWZpbmVzIHR3byDigJx0eXBlc+KAnSBvZiBjaGVjayBsaXN0czog YWN0aXZlIGNoZWNrIGxpc3QgYW5kIGZyb3plbiBjaGVjayBsaXN0Lg0KPj4+IA0KPj4+ICAgIE9u ZSBvZiB0aGUgY2hlY2sgbGlzdHMgd2lsbCBoYXZlIHNvbWUgbnVtYmVyIG9mIHBhaXJzIGluIHRo ZSBXYWl0aW5nDQo+Pj4gICAgc3RhdGUsIGFuZCB0aGUgb3RoZXIgY2hlY2sgbGlzdHMgd2lsbCBo YXZlIGFsbCBvZiB0aGVpciBwYWlycyBpbiB0aGUNCj4+PiAgICBGcm96ZW4gc3RhdGUuICBBIGNo ZWNrIGxpc3Qgd2l0aCBhdCBsZWFzdCBvbmUgcGFpciB0aGF0IGlzIFdhaXRpbmcgaXMNCj4+PiAg ICBjYWxsZWQgYW4gIGFjdGl2ZSBjaGVjayBsaXN0LCBhbmQgYSBjaGVjayBsaXN0IHdpdGggYWxs IHBhaXJzIEZyb3plbg0KPj4+ICAgIGlzIGNhbGxlZCBhICBmcm96ZW4gY2hlY2sgbGlzdC4NCj4+ PiANCj4+PiBRMToNCj4+PiBXaHkgY2Fu4oCZdCBGcm96ZW4gc2ltcGx5IGJlIGEgY2hlY2sgbGlz dCBzdGF0ZT8NCj4+IA0KPj4gKzEgVGhpcyBoYXZlIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZS4uDQo+ PiANCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWNlL2N1cnJlbnQv bXNnMDAwNjQuaHRtbA0KPg0KPiArMS4gVW5sZXNzIHNvbWVvbmUgb2JqZWN0cywgbGV0J3MgbWFr ZSB0aGF0IGNoYW5nZS4NCg0KKzENCg0KPj4+IFEyOiBXaGF04oCZcyB0aGUgc3RhdGUgb2YgYSBG cm96ZW4gY2hlY2sgbGlzdD8NCj4+PiANCj4+IA0KPj4gUnVubmluZz8gKEJ1dCBmcm96ZW4pPw0K Pg0KPiBJZiB3ZSBkbyB0aGUgY2hhbmdlIGFib3ZlLCB0aGF0J2QgYmUgRnJvemVuIChyaWdodD8p Lg0KDQpZZXMuDQogDQo+Pj4gUTM6IFdoYXTigJlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYW4g YWN0aXZlIGNoZWNrIGxpc3QgYW5kIGFuIGNoZWNrIGxpc3QgaW4gUnVubmluZyBzdGF0ZT8NCj4+ PiANCj4+IA0KPj4gTm8gaWRlYS4uDQo+DQo+IFNlZW1zIHRoZXJlJ3Mgbm8gZGlmZmVyZW5jZS4g TWlnaHQgYmUgd29ydGh3aGlsZSB0byB1bmlmeSB0ZXJtaW5vbG9neSBoZXJlLg0KDQpJIGFzc3Vt ZSB0aGUgc3RhdGUgaXMgIlJ1bm5pbmciLg0KDQpJZiB3ZSB3YW50IHRvIHVzZSAiYWN0aXZlIGNo ZWNrIGxpc3QiIHRlcm1pbm9sb2d5LCB3ZSBzaG91bGQgYmluZCBpdCB0byB0aGUgc3RhdGUsIGUu Zy4sIGJ5IHNheWluZyAiYSBjaGVjayBsaXN0IHdoaWNoIHN0YXRlIGlzIFJ1bm5pbmcgaXMgY2Fs bGVkIGFuIGFjdGl2ZSBjaGVjayBsaXN0Ii4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Mon Nov 7 10:52:38 2016 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 2BFDC1298A1 for ; Mon, 7 Nov 2016 10:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTgCaY6g_JZE for ; Mon, 7 Nov 2016 10:52:35 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C35D12965B for ; Mon, 7 Nov 2016 10:52:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6480; q=dns/txt; s=iport; t=1478544755; x=1479754355; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EMxdTxTkFKSPxJ43S1GE0omXd6X8oNloB74v2jxW0vs=; b=QDt8qujOruH4RBsa0nlrEinE2UZneLad2aPxJWPeLwNv8IzjFBKqimgw S6npReDXAP5m7fnj3oS2kG7zI8dtPqJtaF1TPbnn9at93OY3FJXc3sVfk FHdt8QSM35kI7Axq0N6yYPa7Gm04o4JWn484OzTSf16u/1GrrwFb1I1eI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAQDEzCBY/5ldJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnM7AQEBAQEfWHwHjTGmOoUagggeAQqFewIagXE/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGIBAQQBAQEgSwsQAgEIPwMCAgIlCxQRAgQOBR+IOQ6xZ4JAiz4BAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEXBYY+gX0IglCHSy2CLwWIRYdMihYBkEOQEI0qhAUBHjc?= =?us-ascii?q?oUhuFD3KGPoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,606,1473120000"; d="scan'208,217";a="344639883" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2016 18:52:34 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uA7IqY6m008539 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2016 18:52:34 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 13:52:33 -0500 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1210.000; Mon, 7 Nov 2016 13:52:33 -0500 From: "Pal Martinsen (palmarti)" To: Christer Holmberg Thread-Topic: [Ice] 5245bis: check list for first media stream Thread-Index: AQHSOP4DxF6FAUcNHUSS7cC2vWDCpqDOMgYA Date: Mon, 7 Nov 2016 18:52:33 +0000 Message-ID: <6DB17DA5-326B-4711-8D3C-5A82D8BF6249@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.225.6] Content-Type: multipart/alternative; boundary="_000_6DB17DA5326B47118D3C5A82D8BF6249ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: check list for first media stream X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 18:52:37 -0000 --_000_6DB17DA5326B47118D3C5A82D8BF6249ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiA3IE5vdiAyMDE2LCBhdCAxNDo1MSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t Pj4gd3JvdGU6DQoNCkhpLA0KDQpJZiBJIHVuZGVyc3RhbmQgc2VjdGlvbiA1LjEuMy40IG9mIDUy NDViaXMgY29ycmVjdGx5LCBpbml0aWFsbHkgdGhlcmUgd2lsbCBvbmx5IGJlIG9uZSBhY3RpdmUg Y2hlY2sgbGlzdCAodGhlIGNoZWNrIGxpc3QgYXNzb2NpYXRlZCB3aXRoIHRoZSDigJxmaXJzdCBt ZWRpYSBzdHJlYW3igJ0gLSB3aGF0ZXZlciB0aGF0IG1lYW5zKS4gQWxsIG90aGVyIGNoZWNrIGxp c3RzIHdpbGwgYmUgZnJvemVuLg0KDQpUaGVuLCBiYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5nIG9m IHNlY3Rpb24gNi4xLjIuNC4zLCBvdGhlciBjaGVja3MgbGlzdHMgd29u4oCZdCBiZWNvbWUgYWN0 aXZlIHVudGlsIGFsbCBwYWlycyBpbiB0aGUgcHJldmlvdXMgY2hlY2sgbGlzdCBoYXZlIGJlY29t ZSBlaXRoZXIgU3VjY2VlZGVkIG9yIEZhaWxlZC4NCg0KUTE6IFdoYXQgaXMgdGhlIHJlYXNvbiBm b3Ig4oCcYWN0aXZhdGluZ+KAnSBvbmx5IG9uZSBjaGVjayBsaXN0LCBhbmQga2VlcCB0aGUgb3Ro ZXJzIGZyb3plbiwgaW5zdGVhZCBvZiBhY3RpdmF0aW5nIGFsbCBjaGVjayBsaXN0cyBhdCB0aGUg c2FtZSB0aW1lPw0KDQpJIHRoaW5rIHRoZSByYXRpb25hbGUgYmVoaW5kIHRoaXMgaXMgYSBmb3Jt IG9mIOKAnGdsb2JhbCBwYWNpbmfigJ0gdG8gYXZvaWQgb3ZlcmxvYWRpbmcgb2YgdGhlIE5BVC4N Cg0KTm90IHN1cmUgaWYgdGhhdCByYXRpb25hbGUgaXMgc3RpbGwgdmFsaWQuIEkgYm91Z2h0IGEg Y291cGxlIG9mIHRoZSBjaGVhcGVzdCBXaUZpIHJvdXRlcnMgYW5kIGNvdWxkIG5vdCBicmVhayB0 aGVtLiBCdXQgdGhlbiBhZ2FpbiBJQ0UgbWlnaHQgb3BlcmF0ZSBpbiB3ZWlyZCBuZXR3b3JrcyB0 aGF0IGFyZSBzZXZlcmVseSBjb25zdHJhaW5lZC4NCg0KLi0uDQpQw6VsLUVyaWsNCg0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkljZSBtYWlsaW5nIGxpc3QNCkljZUBpZXRmLm9yZzxtYWlsdG86SWNlQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCg0K --_000_6DB17DA5326B47118D3C5A82D8BF6249ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <57B14E19B9B24A4BB6DB3294CBB19281@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiA3IE5v diAyMDE2LCBhdCAxNDo1MSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIGNsYXNzPSIiPmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiIGNsYXNzPSIiPkhpLDwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiIGNsYXNzPSIi PklmIEkgdW5kZXJzdGFuZCBzZWN0aW9uIDUuMS4zLjQgb2YgNTI0NWJpcyBjb3JyZWN0bHksIGlu aXRpYWxseSB0aGVyZSB3aWxsIG9ubHkgYmUgb25lIGFjdGl2ZSBjaGVjayBsaXN0ICh0aGUgY2hl Y2sgbGlzdCBhc3NvY2lhdGVkIHdpdGggdGhlIOKAnGZpcnN0IG1lZGlhIHN0cmVhbeKAnSAtIHdo YXRldmVyIHRoYXQgbWVhbnMpLg0KIEFsbCBvdGhlciBjaGVjayBsaXN0cyB3aWxsIGJlIGZyb3pl bi48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im9ycGhhbnM6IDI7IHdpZG93czogMjsiIGNsYXNzPSIiPjxmb250IGZhY2U9IkNhbGlicmks c2Fucy1zZXJpZiIgY2xhc3M9IiI+VGhlbiwgYmFzZWQgb24gbXkgdW5kZXJzdGFuZGluZyBvZiBz ZWN0aW9uJm5ic3A7PC9mb250PjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IiBj bGFzcz0iIj42LjEuMi40LjM8L3NwYW4+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIiBj bGFzcz0iIj48c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6IHByZS13cmFwOyIgY2xhc3M9IiI+LA0K IG90aGVyIGNoZWNrcyBsaXN0cyB3b27igJl0IGJlY29tZSBhY3RpdmUgdW50aWwgYWxsIHBhaXJz IGluIHRoZSBwcmV2aW91cyBjaGVjayBsaXN0IGhhdmUgYmVjb21lIGVpdGhlciBTdWNjZWVkZWQg b3IgRmFpbGVkLjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJvcnBoYW5zOiAyOyB3 aWRvd3M6IDI7IiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0ib3JwaGFuczogMjsgd2lk b3dzOiAyOyIgY2xhc3M9IiI+UTE6IFdoYXQgaXMgdGhlIHJlYXNvbiBmb3Ig4oCcYWN0aXZhdGlu Z+KAnSBvbmx5IG9uZSBjaGVjayBsaXN0LCBhbmQga2VlcCB0aGUgb3RoZXJzIGZyb3plbiwgaW5z dGVhZCBvZiBhY3RpdmF0aW5nIGFsbCBjaGVjayBsaXN0cyBhdCB0aGUgc2FtZSB0aW1lPzwvZGl2 Pg0KPGRpdiBzdHlsZT0ib3JwaGFuczogMjsgd2lkb3dzOiAyOyIgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj5JIHRoaW5r IHRoZSByYXRpb25hbGUgYmVoaW5kIHRoaXMgaXMgYSBmb3JtIG9mIOKAnGdsb2JhbCBwYWNpbmfi gJ0gdG8gYXZvaWQgb3ZlcmxvYWRpbmcgb2YgdGhlIE5BVC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pk5vdCBzdXJlIGlmIHRoYXQgcmF0aW9uYWxlIGlzIHN0 aWxsIHZhbGlkLiBJIGJvdWdodCBhIGNvdXBsZSBvZiB0aGUgY2hlYXBlc3QgV2lGaSByb3V0ZXJz IGFuZCBjb3VsZCBub3QgYnJlYWsgdGhlbS4gQnV0IHRoZW4gYWdhaW4gSUNFIG1pZ2h0IG9wZXJh dGUgaW4gd2VpcmQgbmV0d29ya3MgdGhhdCBhcmUgc2V2ZXJlbHkgY29uc3RyYWluZWQuICZuYnNw OzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Li0uPC9kaXY+DQo8ZGl2 PlDDpWwtRXJpazwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJvcnBoYW5zOiAyOyB3aWRvd3M6IDI7IiBjbGFzcz0iIj48L2Rpdj4NCjxkaXYgc3R5 bGU9Im9ycGhhbnM6IDI7IHdpZG93czogMjsiIGNsYXNzPSIiPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2 IHN0eWxlPSJvcnBoYW5zOiAyOyB3aWRvd3M6IDI7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6IDI7IHdpZG93czogMjsiIGNsYXNzPSIiPkNocmlz dGVyPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyIGNsYXNzPSIiPg0KSWNlIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxh IGhyZWY9Im1haWx0bzpJY2VAaWV0Zi5vcmciIGNsYXNzPSIiPkljZUBpZXRmLm9yZzwvYT48YnIg Y2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZTxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_6DB17DA5326B47118D3C5A82D8BF6249ciscocom_-- From nobody Mon Nov 7 11:13:19 2016 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 6F75112965B for ; Mon, 7 Nov 2016 11:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gP6R8EnV9XP8 for ; Mon, 7 Nov 2016 11:13:15 -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 4F670129558 for ; Mon, 7 Nov 2016 11:13:15 -0800 (PST) X-AuditID: c1b4fb25-d35ee98000001e3e-d6-5820d249330f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id D6.91.07742.942D0285; Mon, 7 Nov 2016 20:13:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 20:12:47 +0100 From: Christer Holmberg To: "Pal Martinsen (palmarti)" Thread-Topic: [Ice] 5245bis: check list for first media stream Thread-Index: AQHSOP4DxF6FAUcNHUSS7cC2vWDCpqDOMgYA//+wqFA= Date: Mon, 7 Nov 2016 19:12:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE27440@ESESSMB209.ericsson.se> References: <6DB17DA5-326B-4711-8D3C-5A82D8BF6249@cisco.com> In-Reply-To: <6DB17DA5-326B-4711-8D3C-5A82D8BF6249@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE27440ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbHdW9fzkkKEwfcOHYtvF2ot3l9fyeLA 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZXR/3cFWcM674tzeJrYGxgOeXYycHBICJhI7 /7YzdTFycQgJrGOUWPp6DyOEs5hRouf7OvYuRg4ONgELie5/2iANIgLGEs1HjoKFmQUUJV7u VQMJCwvYSqxdP4MNJCwiYCcx5WUFRLWVxO0TdxlBbBYBFYme5ivsIDavgK/E1mcHwGwhgTyJ 1vtbGEFaOYHGzP7rARJmFBCT+H5qDROIzSwgLnHryXwmiIsFJJbsOc8MYYtKvHz8jxXCVpJY e3g7C0R9vsSut4ehVglKnJz5hGUCo8gsJKNmISmbhaRsFthfmhLrd+lDlChKTOl+yA5ha0i0 zpnLjiy+gJF9FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgNB3c8lt1B+PlN46HGAU4GJV4 eD9MU4gQYk0sK67MPcQowcGsJMJ7+QJQiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/ZyvvhQgLp iSWp2ampBalFMFkmDk6pBsYa+Rjz6VN0vNRVpfvbvTX/+zE8XvzRVLiq85Ru/YfAHddvX9WY qlbra5CWaJif53X1161jf35kfI5fcO6WsKHdpwm1xxb/0ff1+3cq93B+x/GY+KmWLkvDdt6x XXaG5fuznPy9F9Mddd/0VMuwnDC43cscK6/tuihujeWnns/vv+aZX5T1uKPEUpyRaKjFXFSc CACY6FdFogIAAA== Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: check list for first media stream X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 19:13:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE27440ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCklmIEkgdW5kZXJzdGFuZCBzZWN0aW9uIDUuMS4zLjQgb2YgNTI0NWJpcyBjb3JyZWN0 bHksIGluaXRpYWxseSB0aGVyZSB3aWxsIG9ubHkgYmUgb25lIGFjdGl2ZSBjaGVjayBsaXN0ICh0 aGUgY2hlY2sgbGlzdCBhc3NvY2lhdGVkIHdpdGggdGhlIOKAnGZpcnN0IG1lZGlhIHN0cmVhbeKA nSAtIHdoYXRldmVyIHRoYXQgbWVhbnMpLiBBbGwgb3RoZXIgY2hlY2sgbGlzdHMgd2lsbCBiZSBm cm96ZW4uDQoNClRoZW4sIGJhc2VkIG9uIG15IHVuZGVyc3RhbmRpbmcgb2Ygc2VjdGlvbiA2LjEu Mi40LjMsIG90aGVyIGNoZWNrcyBsaXN0cyB3b27igJl0IGJlY29tZSBhY3RpdmUgdW50aWwgYWxs IHBhaXJzIGluIHRoZSBwcmV2aW91cyBjaGVjayBsaXN0IGhhdmUgYmVjb21lIGVpdGhlciBTdWNj ZWVkZWQgb3IgRmFpbGVkLg0KDQoNClExOiBXaGF0IGlzIHRoZSByZWFzb24gZm9yIOKAnGFjdGl2 YXRpbmfigJ0gb25seSBvbmUgY2hlY2sgbGlzdCwgYW5kIGtlZXAgdGhlIG90aGVycyBmcm96ZW4s IGluc3RlYWQgb2YgYWN0aXZhdGluZyBhbGwgY2hlY2sgbGlzdHMgYXQgdGhlIHNhbWUgdGltZT8N Cg0KSSB0aGluayB0aGUgcmF0aW9uYWxlIGJlaGluZCB0aGlzIGlzIGEgZm9ybSBvZiDigJxnbG9i YWwgcGFjaW5n4oCdIHRvIGF2b2lkIG92ZXJsb2FkaW5nIG9mIHRoZSBOQVQuDQoNCk5vdCBzdXJl IGlmIHRoYXQgcmF0aW9uYWxlIGlzIHN0aWxsIHZhbGlkLiBJIGJvdWdodCBhIGNvdXBsZSBvZiB0 aGUgY2hlYXBlc3QgV2lGaSByb3V0ZXJzIGFuZCBjb3VsZCBub3QgYnJlYWsgdGhlbS4gQnV0IHRo ZW4gYWdhaW4gSUNFIG1pZ2h0IG9wZXJhdGUgaW4gd2VpcmQgbmV0d29ya3MgdGhhdCBhcmUgc2V2 ZXJlbHkgY29uc3RyYWluZWQuDQoNCltDaHJpc3Rlcl0gSSB0aGluayBvdmVybG9hZGluZyBpcyBh bHJlYWR5IGNvbnNpZGVyZWQsIGFzIHRoZSBjaGVjayB0aW1lciBpcyBjYWxjdWxhdGVkIHVzaW5n IFRhKk4sIHdoZXJlIE4gaXMgdGhlIG51bWJlciBvZiBhY3RpdmUgY2hlY2sgbGlzdC4NCg0KQnV0 LCBpdCBpcyBhbHNvIHVuY2xlYXIgdG8gbWUgd2hlbiB3ZSB3aWxsIGhhdmUgbXVsdGlwbGUgYWN0 aXZlIGNoZWNrIGxpc3RzIHRvIGJlZ2luIHdpdGguIEFyZSBBTEwgZnJvemVuIGNoZWNrIGxpc3Rz IGFjdGl2YXRlZCBvbmNlIHRoZSBmaXJzdCBjaGVjayBsaXN0IGlzIGRvbmU/DQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQoNCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B4BE27440ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SWYgSSB1bmRl cnN0YW5kIHNlY3Rpb24gNS4xLjMuNCBvZiA1MjQ1YmlzIGNvcnJlY3RseSwgaW5pdGlhbGx5IHRo ZXJlIHdpbGwgb25seSBiZSBvbmUgYWN0aXZlIGNoZWNrIGxpc3QgKHRoZSBjaGVjayBsaXN0IGFz c29jaWF0ZWQgd2l0aCB0aGUg4oCcZmlyc3QgbWVkaWEgc3RyZWFt4oCdIC0gd2hhdGV2ZXINCiB0 aGF0IG1lYW5zKS4gQWxsIG90aGVyIGNoZWNrIGxpc3RzIHdpbGwgYmUgZnJvemVuLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlbiwgYmFzZWQgb24gbXkgdW5kZXJzdGFuZGluZyBvZiBz ZWN0aW9uJm5ic3A7PC9zcGFuPjYuMS4yLjQuMzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiwgb3RoZXIgY2hlY2tzIGxpc3RzIHdvbuKAmXQg YmVjb21lIGFjdGl2ZSB1bnRpbCBhbGwgcGFpcnMgaW4gdGhlIHByZXZpb3VzIGNoZWNrIGxpc3QN CiBoYXZlIGJlY29tZSBlaXRoZXIgU3VjY2VlZGVkIG9yIEZhaWxlZC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5RMTogV2hhdCBpcyB0aGUgcmVhc29uIGZvciDigJxhY3RpdmF0aW5n4oCdIG9ubHkgb25lIGNo ZWNrIGxpc3QsIGFuZCBrZWVwIHRoZSBvdGhlcnMgZnJvemVuLCBpbnN0ZWFkIG9mIGFjdGl2YXRp bmcgYWxsIGNoZWNrIGxpc3RzIGF0IHRoZSBzYW1lIHRpbWU/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHRoaW5rIHRoZSByYXRpb25hbGUgYmVoaW5kIHRoaXMgaXMgYSBmb3JtIG9mIOKA nGdsb2JhbCBwYWNpbmfigJ0gdG8gYXZvaWQgb3ZlcmxvYWRpbmcgb2YgdGhlIE5BVC4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IHN1cmUg aWYgdGhhdCByYXRpb25hbGUgaXMgc3RpbGwgdmFsaWQuIEkgYm91Z2h0IGEgY291cGxlIG9mIHRo ZSBjaGVhcGVzdCBXaUZpIHJvdXRlcnMgYW5kIGNvdWxkIG5vdCBicmVhayB0aGVtLiBCdXQgdGhl biBhZ2FpbiBJQ0UgbWlnaHQgb3BlcmF0ZSBpbiB3ZWlyZCBuZXR3b3JrcyB0aGF0IGFyZSBzZXZl cmVseSBjb25zdHJhaW5lZC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPltDaHJpc3Rlcl0gSSB0 aGluayBvdmVybG9hZGluZyBpcyBhbHJlYWR5IGNvbnNpZGVyZWQsIGFzIHRoZSBjaGVjayB0aW1l ciBpcyBjYWxjdWxhdGVkIHVzaW5nIFRhKk4sIHdoZXJlIE4gaXMgdGhlIG51bWJlciBvZiBhY3Rp dmUgY2hlY2sgbGlzdC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPkJ1dCwg aXQgaXMgYWxzbyB1bmNsZWFyIHRvIG1lIHdoZW4gd2Ugd2lsbCBoYXZlIG11bHRpcGxlIGFjdGl2 ZSBjaGVjayBsaXN0cyB0byBiZWdpbiB3aXRoLiBBcmUgQUxMIGZyb3plbiBjaGVjayBsaXN0cyBh Y3RpdmF0ZWQgb25jZSB0aGUgZmlyc3QgY2hlY2sgbGlzdCBpcyBkb25lPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpyZWQiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnJlZCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOnJlZCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVkIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_7594FB04B1934943A5C02806D1A2204B4BE27440ESESSMB209erics_-- From nobody Mon Nov 7 11:31:02 2016 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 35CED1297C4 for ; Mon, 7 Nov 2016 11:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 iONYlKupo40j for ; Mon, 7 Nov 2016 11:30:57 -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 A2DBB1298C0 for ; Mon, 7 Nov 2016 11:30:57 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id x186so130144422vkd.1 for ; Mon, 07 Nov 2016 11:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1SfHa+PXamuVYLnDdjPUL3XVNXyYpUBD1JDeqpKKndo=; b=EFw8l7lKYaPO7wTvZu8qynARr8jqL+QlX1w4extUw7X4UXMHj1FD5c14iLU8+nZI9T Wws97RlACzlUP1KNAIaULERzRKxPs/pfUL39PPTwxDY+601PUWCzwtstEQR1uBzomRPl plb/QvySVoe50KGDVnvXd2GvCHOmXXJgsU/nYA3deT3lC2+APVjRaPaaPZCBiKoQrrNC pAnY5fONxRpMtssBJJhy+iD9te2aRH8kz4DZo0qMz9e5cHyzxQhHlIqUkQ5aYcXrwN7L QbfiE05UeeXOQVKKPAFwTJEZ/ADnXA042HiCp0kJSy/3IUc0qtNBjnjDJeNv2VZvh/SH NrcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1SfHa+PXamuVYLnDdjPUL3XVNXyYpUBD1JDeqpKKndo=; b=BUv5Nr1jaxqFStiyjubzRlLfifpSC6tTcAUiShjbSYO258wr3/NMs+SKILBnqcvzmZ OzUHlHU4Ur6VkNlmkWM24F83pkSuCvJQOY0KROCR361jjDjLaY9hYWLGPNPfuumMqVzK 3jMrlEE4ywULu6amkY9/hQYONeeNSn96seOdeQW27SFL2ffIv4xAotixGqLkZqfB4RFK LVM3f9459BVcNmsBZbR9Wzr0I2UHD4w9Wyvw1uOemPv0EpYv3+pubgfAdD3xR/6teLtR gjhW18LEpmVTg5osazzpp3zJrpfA+izszBTaJvWePvGjbR2unpmeYcr082PfUUc/3PAB 5wGw== X-Gm-Message-State: ABUngvcoyLsOJQrd6pMBL2hGI7w5h7YffrPFBWq4gOrff/mhSdP01PeCDXXl0PdEOYCIfLbmUUUFcv0HIrJmVQ== X-Received: by 10.31.134.3 with SMTP id i3mr5903235vkd.57.1478547056407; Mon, 07 Nov 2016 11:30:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Mon, 7 Nov 2016 11:30:36 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Mon, 7 Nov 2016 11:30:36 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11441afc14b9e90540bb1024 Archived-At: Cc: "ice@ietf.org" , Taylor Brandstetter Subject: Re: [Ice] Contradiction regarding when an ICE agent is allowed to send media X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 19:31:00 -0000 --001a11441afc14b9e90540bb1024 Content-Type: text/plain; charset=UTF-8 Done: https://github.com/ice-wg/rfc5245bis/pull/20 On Tue, Nov 1, 2016 at 5:50 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Bernard/Taylor, > > Would you be able to create a pull request with the suggested changes? > > Regards, > > Christer > > From: Ice on behalf of Bernard Aboba < > bernard.aboba@gmail.com> > Date: Friday 30 September 2016 at 02:20 > To: Taylor Brandstetter > Cc: "ice@ietf.org" > Subject: Re: [Ice] Contradiction regarding when an ICE agent is allowed > to send media > > Looking over RFC 5245bis, there are a number of places in the text that > should have been updated to allow passive-aggressive nomination that were > instead left as is. There are issues in Section 2.6 (which says "ICE will > now send media using this pair"), Section 3 (which defines "selected pair" > as "The candidate pair selected by ICE for sending and receiving media"), > Section 6.2.3.1 (which still mentions aggressive nomination!) and Section > 9.1.1. > > A potential rewrite of Section 9.1.1 might look like this: > > "9.1.1. Procedures for Full Implementations > > A full implementation MUST NOT send media until it has a Valid list > that contains a candidate pair for each component of that media > stream. Once that happens, the agent MAY begin sending media > packets. > > An agent will send media to the remote candidate (setting the > destination address and port of the packet equal to that remote > candidate), > and will send it from the local candidate. When the local candidate is > server or peer reflexive, media is originated from the base. Media > sent from a relayed candidate is sent from the base through that TURN > server, using procedures defined in [RFC5766]. > > If the local candidate is a relayed candidate, it is RECOMMENDED that > an agent create a channel on the TURN server towards the remote > candidate. This is done using the procedures for channel creation as > defined in Section 11 of [RFC5766]." > > If those changes are made, it looks to me like the rest of the text from > Section 9.1.1 could be deleted: > > "The selected pair for a component of a media stream is: > > o empty if the state of the check list for that media stream is > Running, and there is no previous selected pair for that component > due to an ICE restart > > o equal to the previous selected pair for a component of a media > stream if the state of the check list for that media stream is > Running, and there was a previous selected pair for that component > due to an ICE restart > > o equal to the highest-priority nominated pair for that component in > the valid list if the state of the check list is Completed" > > On Thu, Sep 29, 2016 at 3:57 PM, Bernard Aboba > wrote: > >> There is a contradiction in draft-ietf-rfc5245bis because aggressive >> nomination was removed without making all the required changes to regular >> nomination to allow sending of media before a pair is nominated. So the >> text in draft-ietf-rfc5245bis Section 9.1.1 was carried over verbatim >> from RFC 5245 Section 11.1.1 instead of being adapted. IMHO, the >> requirement for sending media in draft-ietf-rfc5245bis Section 9.1.2 >> (which currently only applies to a lite implementation) should be applied >> to all implementations (lite or full): >> >> A lite implementation MUST NOT send media until it has a Valid list >> that contains a candidate pair for each component of that media >> stream. Once that happens, the agent MAY begin sending media >> packets. >> >> >> Making this change should not impact an RFC 5245-compliant implementation >> since RFC 5245 Section 11.2 says: >> >> ICE implementations MUST be prepared to receive media on each >> component on any candidates provided for that component in the most >> recent offer/answer exchange (in the case of RTP, this would include >> both RTP and RTCP if candidates were provided for both). >> >> >> >> >> >> >> On Thu, Sep 29, 2016 at 12:35 PM, Taylor Brandstetter < >> deadbeef@google.com> wrote: >> >>> Section 6.2.1.1 of draft-ietf-ice-rfc5245bis-04 states: >>> >>> Before the agent has received Binding responses >>>> associated with the [nominated] candidiate pair, the agent can send media on any >>>> candidiate for which it has received Binding responses. >>>> >>>> >>> To me, this would imply that until a pair is nominated, the ICE agent >>> can send media on any pair with a local candidate that has received a >>> binding response. >>> >>> However, section 9.1.1 states: >>> >>> If the selected pair for at least one component of a media stream is >>>> >>> empty, an agent MUST NOT send media for any component of that media >>> >>> stream. >>> >>> >>> And the selected pair is empty until a pair is nominated, which means >>> you can't send media until a pair is nominated. The examples at the end of >>> Section 12 seems to reiterate this. >>> >>> So, which is it? I was under the impression that aggressive nomination >>> was being removed because you could accomplish essentially the same thing >>> with regular nomination, by sending media before a pair is nominated (the >>> so called "passive aggressive" nomination). But that doesn't seem to be >>> allowed by section 9.1.1. >>> >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >>> >> > --001a11441afc14b9e90540bb1024 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 1, 2016 at 5:50 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi Bernard/Taylor,

Would you be able to create a pull request with the suggested changes?=

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf= of Bernard Aboba <bernard.aboba@gmail.com>
Date: Friday 30 September 2016 at 0= 2:20
To: Taylor Brandstetter <deadbeef@google.com&g= t;
Cc: "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Contradiction re= garding when an ICE agent is allowed to send media

Looking over RFC 5245bis, there are a number of places in the text tha= t should have been updated to allow passive-aggressive nomination that were= instead left as is.=C2=A0 There are issues in Section 2.6 (which says &quo= t;ICE will now send media using this pair"), Section 3 (which defines "selected pair" as "The candidate = pair selected by ICE for sending and receiving media"), Section 6.2.3.= 1 (which still mentions aggressive nomination!) and Section 9.1.1.=C2=A0

A potential rewrite of Section 9.1.1 might look like this:=C2=A0

"9.1.1.=C2=A0 Procedures for Full Implementations

=C2=A0 =C2=A0A full implementation MUST NOT send media until it has a = Valid list
=C2=A0 =C2=A0that contains a candidate pair for each component of that= media
=C2=A0 =C2=A0stream.=C2=A0 Once that happens, the agent MAY begin send= ing media
=C2=A0 =C2=A0packets.

=C2=A0 =C2=A0An agent will send media to the remote candidate (setting= the=C2=A0
=C2=A0 =C2=A0destination address and port of the packet equal to that = remote candidate),=C2=A0
=C2=A0 =C2=A0and will send it from the local candidate.=C2=A0 When the= local candidate is
=C2=A0 =C2=A0server or peer reflexive, media is originated from the ba= se.=C2=A0 Media
=C2=A0 =C2=A0sent from a relayed candidate is sent from the base throu= gh that TURN
=C2=A0 =C2=A0server, using procedures defined in [RFC5766].

=C2=A0 =C2=A0If the local candidate is a relayed candidate, it is RECO= MMENDED that
=C2=A0 =C2=A0an agent create a channel on the TURN server towards the = remote
=C2=A0 =C2=A0candidate.=C2=A0 This is done using the procedures for ch= annel creation as
=C2=A0 =C2=A0defined in Section 11 of [RFC5766]."

If those changes are made, it looks to me like the rest of the text fr= om Section 9.1.1 could be deleted:

=C2=A0 =C2=A0"The selected pair for a component of a media stream= is:

=C2=A0 =C2=A0o =C2=A0empty if the state of the check list for that med= ia stream is
=C2=A0 =C2=A0 =C2=A0 Running, and there is no previous selected pair f= or that component
=C2=A0 =C2=A0 =C2=A0 due to an ICE restart

=C2=A0 =C2=A0o =C2=A0equal to the previous selected pair for a compone= nt of a media
=C2=A0 =C2=A0 =C2=A0 stream if the state of the check list for that me= dia stream is
=C2=A0 =C2=A0 =C2=A0 Running, and there was a previous selected pair f= or that component
=C2=A0 =C2=A0 =C2=A0 due to an ICE restart

=C2=A0 =C2=A0o =C2=A0equal to the highest-priority nominated pair for = that component in
=C2=A0 =C2=A0 =C2=A0 the valid list if the state of the check list is = Completed"

On Thu, Sep 29, 2016 at 3:57 PM, Bernard Aboba <= span dir=3D"ltr"> <bernard.ab= oba@gmail.com> wrote:
There is a contradiction in draft-ietf-rfc5245bis because = aggressive nomination was removed without making all the required changes t= o regular nomination to allow sending of media before a pair is nominated. = So the text in=C2=A0draft-ietf-rfc5245bis=C2=A0Section 9.1.1 was carried over verbatim from RFC 5245 Section 11.1.1 instead of be= ing adapted.=C2=A0 IMHO, the requirement for sending media in=C2=A0draft-ie= tf-rfc5245bis=C2=A0Section 9.1.2 (which currently only applies to a li= te implementation) should be applied to all implementations (lite or full):=C2=A0 

   A lite implementation MUST NOT send media until it has a Valid=
 list
   that contains a candidate pair for each component of that media
   stream.  Once that happens, the agent MAY begin sending media
   packets.

Making this change should not impact an RFC 5245-compliant implementat= ion since RFC 5245 Section 11.2 says:=C2=A0

   ICE implementations MUST be prepared to receive media on each
   component on any candidates provided for that component in the most
   recent offer/answer exchange (in the case of RTP, this would include
   both RTP and RTCP if candidates were provided for both).





On Thu, Sep 29, 2016 at 12:35 PM, Taylor B= randstetter <deadbeef@google.com> wrote:
Section 6.2.1.1 = of=C2=A0draft-ietf-ice-rfc5245bis-04 states: 

Before the agent has re=
ceived Binding responses
associated with the [nominated] candidiate pair, the agent can send media o=
n any
candidiate for which it has received Binding responses.

To me, this would imply that= until a pair is nominated, the ICE agent can send media on any pair with a= local candidate that has received a binding response.

However, section 9.1.1 state= s:

If the selected pair for at least one component of a media stream is
empty, an agent MUST NOT send media for any component of that media
stream.

And the selected pair is empty until a pair is nominated, which means = you can't send media until a pair is nominated. The examples at the end= of Section 12 seems to reiterate this.

So, which is it? I was under the impression that aggressive nomination= was being removed because you could accomplish essentially the same thing = with regular nomination, by sending media before a pair is nominated (the s= o called "passive aggressive" nomination). But that doesn't seem to be allowed by section 9.1.1.=C2=A0

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




--001a11441afc14b9e90540bb1024-- From nobody Mon Nov 7 11:36:15 2016 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 A5A251298CF for ; Mon, 7 Nov 2016 11:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSgx8kEkVSqk for ; Mon, 7 Nov 2016 11:36:11 -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 0F345129695 for ; Mon, 7 Nov 2016 11:36:10 -0800 (PST) X-AuditID: c1b4fb3a-83dd4980000070a2-86-5820d7a86516 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 95.82.28834.8A7D0285; Mon, 7 Nov 2016 20:36:09 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 20:36:07 +0100 From: Christer Holmberg To: Bernard Aboba Thread-Topic: [Ice] Contradiction regarding when an ICE agent is allowed to send media Thread-Index: AQHSGqTpVlbkPKJoTUy4xT3JYY1SFKCQ+UEAgDNQfYCACcsIAIAAEkew Date: Mon, 7 Nov 2016 19:36:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE274C5@ESESSMB209.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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE274C5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7ge7K6woRBtdW8lls2Pef2eLyioes Ft8u1Dowe+ycdZfdY8GmUo8lS34yBTBHcdmkpOZklqUW6dslcGXMuHiBveDaPqaKg/d+sjcw rtnG1MXIySEhYCIxb+5Nxi5GLg4hgXWMEuemX4ByFjNKfDjwkrmLkYODTcBCovufNkiDiIC2 RN+3fWDNzAI+ElfebWUHsYUFwiWeX5vBBlETIfG97xoThO0mcePWfxYQm0VAReL7ulMsICN5 BXwleuYVQ6y6ziTxoHkv2BxOgUCJh/1nwXoZBcQkvp9aA7VLXOLWk/lQRwtILNlznhnCFpV4 +fgfK4StJLH28HYWiPp8iZ9/roLV8woISpyc+YRlAqPILCSjZiEpm4WkbBbQecwCmhLrd+lD lChKTOl+yA5ha0i0zpnLjiy+gJF9FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgpB3c8ttq B+PB546HGAU4GJV4eD9MU4gQYk0sK67MPcQowcGsJMK79BpQiDclsbIqtSg/vqg0J7X4EKM0 B4uSOK/ZyvvhQgLpiSWp2ampBalFMFkmDk6pBsaAE7UxJ1nW3vjGJNY0+zN3nV3L5J/XZMK3 /VxySvZIiJHdgg/ykey3pG3t/A7f6NRt+8Cw2og7gsfJyHaycz/rm9yFeTNk9C6yLu1d3Zig NH2Ki5bwguJSRr+w1+82vAuezvPhuUvl+qjJHDcFf3zabPy0UsLt0Smrv0d3f+vrZq9XLX58 65ESS3FGoqEWc1FxIgBfQZqtsAIAAA== Archived-At: Cc: "ice@ietf.org" , Taylor Brandstetter Subject: Re: [Ice] Contradiction regarding when an ICE agent is allowed to send media X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 19:36:13 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE274C5ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzISA6KQ0KDQpGcm9tOiBCZXJuYXJkIEFib2JhIFttYWlsdG86YmVybmFyZC5hYm9iYUBn bWFpbC5jb21dDQpTZW50OiAwNyBOb3ZlbWJlciAyMDE2IDIxOjMxDQpUbzogQ2hyaXN0ZXIgSG9s bWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNjOiBUYXlsb3IgQnJhbmRz dGV0dGVyIDxkZWFkYmVlZkBnb29nbGUuY29tPjsgaWNlQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W0ljZV0gQ29udHJhZGljdGlvbiByZWdhcmRpbmcgd2hlbiBhbiBJQ0UgYWdlbnQgaXMgYWxsb3dl ZCB0byBzZW5kIG1lZGlhDQoNCkRvbmU6DQpodHRwczovL2dpdGh1Yi5jb20vaWNlLXdnL3JmYzUy NDViaXMvcHVsbC8yMA0KDQoNCg0KT24gVHVlLCBOb3YgMSwgMjAxNiBhdCA1OjUwIEFNLCBDaHJp c3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpIEJlcm5hcmQvVGF5bG9yLA0K DQpXb3VsZCB5b3UgYmUgYWJsZSB0byBjcmVhdGUgYSBwdWxsIHJlcXVlc3Qgd2l0aCB0aGUgc3Vn Z2VzdGVkIGNoYW5nZXM/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEljZSA8aWNl LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmljZS1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxm IG9mIEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJuYXJk LmFib2JhQGdtYWlsLmNvbT4+DQpEYXRlOiBGcmlkYXkgMzAgU2VwdGVtYmVyIDIwMTYgYXQgMDI6 MjANClRvOiBUYXlsb3IgQnJhbmRzdGV0dGVyIDxkZWFkYmVlZkBnb29nbGUuY29tPG1haWx0bzpk ZWFkYmVlZkBnb29nbGUuY29tPj4NCkNjOiAiaWNlQGlldGYub3JnPG1haWx0bzppY2VAaWV0Zi5v cmc+IiA8aWNlQGlldGYub3JnPG1haWx0bzppY2VAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJ Y2VdIENvbnRyYWRpY3Rpb24gcmVnYXJkaW5nIHdoZW4gYW4gSUNFIGFnZW50IGlzIGFsbG93ZWQg dG8gc2VuZCBtZWRpYQ0KDQpMb29raW5nIG92ZXIgUkZDIDUyNDViaXMsIHRoZXJlIGFyZSBhIG51 bWJlciBvZiBwbGFjZXMgaW4gdGhlIHRleHQgdGhhdCBzaG91bGQgaGF2ZSBiZWVuIHVwZGF0ZWQg dG8gYWxsb3cgcGFzc2l2ZS1hZ2dyZXNzaXZlIG5vbWluYXRpb24gdGhhdCB3ZXJlIGluc3RlYWQg bGVmdCBhcyBpcy4gIFRoZXJlIGFyZSBpc3N1ZXMgaW4gU2VjdGlvbiAyLjYgKHdoaWNoIHNheXMg IklDRSB3aWxsIG5vdyBzZW5kIG1lZGlhIHVzaW5nIHRoaXMgcGFpciIpLCBTZWN0aW9uIDMgKHdo aWNoIGRlZmluZXMgInNlbGVjdGVkIHBhaXIiIGFzICJUaGUgY2FuZGlkYXRlIHBhaXIgc2VsZWN0 ZWQgYnkgSUNFIGZvciBzZW5kaW5nIGFuZCByZWNlaXZpbmcgbWVkaWEiKSwgU2VjdGlvbiA2LjIu My4xICh3aGljaCBzdGlsbCBtZW50aW9ucyBhZ2dyZXNzaXZlIG5vbWluYXRpb24hKSBhbmQgU2Vj dGlvbiA5LjEuMS4NCg0KQSBwb3RlbnRpYWwgcmV3cml0ZSBvZiBTZWN0aW9uIDkuMS4xIG1pZ2h0 IGxvb2sgbGlrZSB0aGlzOg0KDQoiOS4xLjEuICBQcm9jZWR1cmVzIGZvciBGdWxsIEltcGxlbWVu dGF0aW9ucw0KDQogICBBIGZ1bGwgaW1wbGVtZW50YXRpb24gTVVTVCBOT1Qgc2VuZCBtZWRpYSB1 bnRpbCBpdCBoYXMgYSBWYWxpZCBsaXN0DQogICB0aGF0IGNvbnRhaW5zIGEgY2FuZGlkYXRlIHBh aXIgZm9yIGVhY2ggY29tcG9uZW50IG9mIHRoYXQgbWVkaWENCiAgIHN0cmVhbS4gIE9uY2UgdGhh dCBoYXBwZW5zLCB0aGUgYWdlbnQgTUFZIGJlZ2luIHNlbmRpbmcgbWVkaWENCiAgIHBhY2tldHMu DQoNCiAgIEFuIGFnZW50IHdpbGwgc2VuZCBtZWRpYSB0byB0aGUgcmVtb3RlIGNhbmRpZGF0ZSAo c2V0dGluZyB0aGUNCiAgIGRlc3RpbmF0aW9uIGFkZHJlc3MgYW5kIHBvcnQgb2YgdGhlIHBhY2tl dCBlcXVhbCB0byB0aGF0IHJlbW90ZSBjYW5kaWRhdGUpLA0KICAgYW5kIHdpbGwgc2VuZCBpdCBm cm9tIHRoZSBsb2NhbCBjYW5kaWRhdGUuICBXaGVuIHRoZSBsb2NhbCBjYW5kaWRhdGUgaXMNCiAg IHNlcnZlciBvciBwZWVyIHJlZmxleGl2ZSwgbWVkaWEgaXMgb3JpZ2luYXRlZCBmcm9tIHRoZSBi YXNlLiAgTWVkaWENCiAgIHNlbnQgZnJvbSBhIHJlbGF5ZWQgY2FuZGlkYXRlIGlzIHNlbnQgZnJv bSB0aGUgYmFzZSB0aHJvdWdoIHRoYXQgVFVSTg0KICAgc2VydmVyLCB1c2luZyBwcm9jZWR1cmVz IGRlZmluZWQgaW4gW1JGQzU3NjZdLg0KDQogICBJZiB0aGUgbG9jYWwgY2FuZGlkYXRlIGlzIGEg cmVsYXllZCBjYW5kaWRhdGUsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQNCiAgIGFuIGFnZW50IGNy ZWF0ZSBhIGNoYW5uZWwgb24gdGhlIFRVUk4gc2VydmVyIHRvd2FyZHMgdGhlIHJlbW90ZQ0KICAg Y2FuZGlkYXRlLiAgVGhpcyBpcyBkb25lIHVzaW5nIHRoZSBwcm9jZWR1cmVzIGZvciBjaGFubmVs IGNyZWF0aW9uIGFzDQogICBkZWZpbmVkIGluIFNlY3Rpb24gMTEgb2YgW1JGQzU3NjZdLiINCg0K SWYgdGhvc2UgY2hhbmdlcyBhcmUgbWFkZSwgaXQgbG9va3MgdG8gbWUgbGlrZSB0aGUgcmVzdCBv ZiB0aGUgdGV4dCBmcm9tIFNlY3Rpb24gOS4xLjEgY291bGQgYmUgZGVsZXRlZDoNCg0KICAgIlRo ZSBzZWxlY3RlZCBwYWlyIGZvciBhIGNvbXBvbmVudCBvZiBhIG1lZGlhIHN0cmVhbSBpczoNCg0K ICAgbyAgZW1wdHkgaWYgdGhlIHN0YXRlIG9mIHRoZSBjaGVjayBsaXN0IGZvciB0aGF0IG1lZGlh IHN0cmVhbSBpcw0KICAgICAgUnVubmluZywgYW5kIHRoZXJlIGlzIG5vIHByZXZpb3VzIHNlbGVj dGVkIHBhaXIgZm9yIHRoYXQgY29tcG9uZW50DQogICAgICBkdWUgdG8gYW4gSUNFIHJlc3RhcnQN Cg0KICAgbyAgZXF1YWwgdG8gdGhlIHByZXZpb3VzIHNlbGVjdGVkIHBhaXIgZm9yIGEgY29tcG9u ZW50IG9mIGEgbWVkaWENCiAgICAgIHN0cmVhbSBpZiB0aGUgc3RhdGUgb2YgdGhlIGNoZWNrIGxp c3QgZm9yIHRoYXQgbWVkaWEgc3RyZWFtIGlzDQogICAgICBSdW5uaW5nLCBhbmQgdGhlcmUgd2Fz IGEgcHJldmlvdXMgc2VsZWN0ZWQgcGFpciBmb3IgdGhhdCBjb21wb25lbnQNCiAgICAgIGR1ZSB0 byBhbiBJQ0UgcmVzdGFydA0KDQogICBvICBlcXVhbCB0byB0aGUgaGlnaGVzdC1wcmlvcml0eSBu b21pbmF0ZWQgcGFpciBmb3IgdGhhdCBjb21wb25lbnQgaW4NCiAgICAgIHRoZSB2YWxpZCBsaXN0 IGlmIHRoZSBzdGF0ZSBvZiB0aGUgY2hlY2sgbGlzdCBpcyBDb21wbGV0ZWQiDQoNCk9uIFRodSwg U2VwIDI5LCAyMDE2IGF0IDM6NTcgUE0sIEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21h aWwuY29tPG1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhlcmUgaXMg YSBjb250cmFkaWN0aW9uIGluIGRyYWZ0LWlldGYtcmZjNTI0NWJpcyBiZWNhdXNlIGFnZ3Jlc3Np dmUgbm9taW5hdGlvbiB3YXMgcmVtb3ZlZCB3aXRob3V0IG1ha2luZyBhbGwgdGhlIHJlcXVpcmVk IGNoYW5nZXMgdG8gcmVndWxhciBub21pbmF0aW9uIHRvIGFsbG93IHNlbmRpbmcgb2YgbWVkaWEg YmVmb3JlIGEgcGFpciBpcyBub21pbmF0ZWQuIFNvIHRoZSB0ZXh0IGluIGRyYWZ0LWlldGYtcmZj NTI0NWJpcyBTZWN0aW9uIDkuMS4xIHdhcyBjYXJyaWVkIG92ZXIgdmVyYmF0aW0gZnJvbSBSRkMg NTI0NSBTZWN0aW9uIDExLjEuMSBpbnN0ZWFkIG9mIGJlaW5nIGFkYXB0ZWQuICBJTUhPLCB0aGUg cmVxdWlyZW1lbnQgZm9yIHNlbmRpbmcgbWVkaWEgaW4gZHJhZnQtaWV0Zi1yZmM1MjQ1YmlzIFNl Y3Rpb24gOS4xLjIgKHdoaWNoIGN1cnJlbnRseSBvbmx5IGFwcGxpZXMgdG8gYSBsaXRlIGltcGxl bWVudGF0aW9uKSBzaG91bGQgYmUgYXBwbGllZCB0byBhbGwgaW1wbGVtZW50YXRpb25zIChsaXRl IG9yIGZ1bGwpOg0KDQoNCiAgIEEgbGl0ZSBpbXBsZW1lbnRhdGlvbiBNVVNUIE5PVCBzZW5kIG1l ZGlhIHVudGlsIGl0IGhhcyBhIFZhbGlkIGxpc3QNCg0KICAgdGhhdCBjb250YWlucyBhIGNhbmRp ZGF0ZSBwYWlyIGZvciBlYWNoIGNvbXBvbmVudCBvZiB0aGF0IG1lZGlhDQoNCiAgIHN0cmVhbS4g IE9uY2UgdGhhdCBoYXBwZW5zLCB0aGUgYWdlbnQgTUFZIGJlZ2luIHNlbmRpbmcgbWVkaWENCg0K ICAgcGFja2V0cy4NCg0KTWFraW5nIHRoaXMgY2hhbmdlIHNob3VsZCBub3QgaW1wYWN0IGFuIFJG QyA1MjQ1LWNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbiBzaW5jZSBSRkMgNTI0NSBTZWN0aW9uIDEx LjIgc2F5czoNCg0KDQogICBJQ0UgaW1wbGVtZW50YXRpb25zIE1VU1QgYmUgcHJlcGFyZWQgdG8g cmVjZWl2ZSBtZWRpYSBvbiBlYWNoDQoNCiAgIGNvbXBvbmVudCBvbiBhbnkgY2FuZGlkYXRlcyBw cm92aWRlZCBmb3IgdGhhdCBjb21wb25lbnQgaW4gdGhlIG1vc3QNCg0KICAgcmVjZW50IG9mZmVy L2Fuc3dlciBleGNoYW5nZSAoaW4gdGhlIGNhc2Ugb2YgUlRQLCB0aGlzIHdvdWxkIGluY2x1ZGUN Cg0KICAgYm90aCBSVFAgYW5kIFJUQ1AgaWYgY2FuZGlkYXRlcyB3ZXJlIHByb3ZpZGVkIGZvciBi b3RoKS4NCg0KDQoNCg0KDQoNCg0KDQpPbiBUaHUsIFNlcCAyOSwgMjAxNiBhdCAxMjozNSBQTSwg VGF5bG9yIEJyYW5kc3RldHRlciA8ZGVhZGJlZWZAZ29vZ2xlLmNvbTxtYWlsdG86ZGVhZGJlZWZA Z29vZ2xlLmNvbT4+IHdyb3RlOg0KU2VjdGlvbiA2LjIuMS4xIG9mIGRyYWZ0LWlldGYtaWNlLXJm YzUyNDViaXMtMDQgc3RhdGVzOg0KDQoNCkJlZm9yZSB0aGUgYWdlbnQgaGFzIHJlY2VpdmVkIEJp bmRpbmcgcmVzcG9uc2VzDQoNCmFzc29jaWF0ZWQgd2l0aCB0aGUgW25vbWluYXRlZF0gY2FuZGlk aWF0ZSBwYWlyLCB0aGUgYWdlbnQgY2FuIHNlbmQgbWVkaWEgb24gYW55DQoNCmNhbmRpZGlhdGUg Zm9yIHdoaWNoIGl0IGhhcyByZWNlaXZlZCBCaW5kaW5nIHJlc3BvbnNlcy4NCg0KVG8gbWUsIHRo aXMgd291bGQgaW1wbHkgdGhhdCB1bnRpbCBhIHBhaXIgaXMgbm9taW5hdGVkLCB0aGUgSUNFIGFn ZW50IGNhbiBzZW5kIG1lZGlhIG9uIGFueSBwYWlyIHdpdGggYSBsb2NhbCBjYW5kaWRhdGUgdGhh dCBoYXMgcmVjZWl2ZWQgYSBiaW5kaW5nIHJlc3BvbnNlLg0KDQpIb3dldmVyLCBzZWN0aW9uIDku MS4xIHN0YXRlczoNCg0KSWYgdGhlIHNlbGVjdGVkIHBhaXIgZm9yIGF0IGxlYXN0IG9uZSBjb21w b25lbnQgb2YgYSBtZWRpYSBzdHJlYW0gaXMNCmVtcHR5LCBhbiBhZ2VudCBNVVNUIE5PVCBzZW5k IG1lZGlhIGZvciBhbnkgY29tcG9uZW50IG9mIHRoYXQgbWVkaWENCnN0cmVhbS4NCg0KQW5kIHRo ZSBzZWxlY3RlZCBwYWlyIGlzIGVtcHR5IHVudGlsIGEgcGFpciBpcyBub21pbmF0ZWQsIHdoaWNo IG1lYW5zIHlvdSBjYW4ndCBzZW5kIG1lZGlhIHVudGlsIGEgcGFpciBpcyBub21pbmF0ZWQuIFRo ZSBleGFtcGxlcyBhdCB0aGUgZW5kIG9mIFNlY3Rpb24gMTIgc2VlbXMgdG8gcmVpdGVyYXRlIHRo aXMuDQoNClNvLCB3aGljaCBpcyBpdD8gSSB3YXMgdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCBh Z2dyZXNzaXZlIG5vbWluYXRpb24gd2FzIGJlaW5nIHJlbW92ZWQgYmVjYXVzZSB5b3UgY291bGQg YWNjb21wbGlzaCBlc3NlbnRpYWxseSB0aGUgc2FtZSB0aGluZyB3aXRoIHJlZ3VsYXIgbm9taW5h dGlvbiwgYnkgc2VuZGluZyBtZWRpYSBiZWZvcmUgYSBwYWlyIGlzIG5vbWluYXRlZCAodGhlIHNv IGNhbGxlZCAicGFzc2l2ZSBhZ2dyZXNzaXZlIiBub21pbmF0aW9uKS4gQnV0IHRoYXQgZG9lc24n dCBzZWVtIHRvIGJlIGFsbG93ZWQgYnkgc2VjdGlvbiA5LjEuMS4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkljZSBtYWlsaW5nIGxpc3QNCkljZUBp ZXRmLm9yZzxtYWlsdG86SWNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pY2UNCg0KDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B4BE274C5ESESSMB209erics_ 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 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H Qjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5UaGFua3MhIDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9h PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQmVybmFy ZCBBYm9iYSBbbWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IDA3IE5vdmVtYmVyIDIwMTYgMjE6MzE8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1i ZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBUYXlsb3IgQnJhbmRzdGV0dGVyICZsdDtkZWFkYmVlZkBnb29nbGUuY29tJmd0OzsgaWNlQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWNlXSBDb250cmFkaWN0aW9uIHJlZ2Fy ZGluZyB3aGVuIGFuIElDRSBhZ2VudCBpcyBhbGxvd2VkIHRvIHNlbmQgbWVkaWE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb25lOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9p Y2Utd2cvcmZjNTI0NWJpcy9wdWxsLzIwIj5odHRwczovL2dpdGh1Yi5jb20vaWNlLXdnL3JmYzUy NDViaXMvcHVsbC8yMDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTm92IDEsIDIwMTYgYXQgNTo1MCBBTSwgQ2hyaXN0 ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SGkgQmVybmFy ZC9UYXlsb3IsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPldvdWxkIHlvdSBiZSBhYmxlIHRvIGNyZWF0ZSBhIHB1bGwg cmVxdWVzdCB3aXRoIHRoZSBzdWdnZXN0ZWQgY2hhbmdlcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5G cm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkljZSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmljZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNlLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQmVybmFyZCBBYm9iYSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmVy bmFyZC5hYm9iYUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXkgMzAg U2VwdGVtYmVyIDIwMTYgYXQgMDI6MjA8YnI+DQo8Yj5UbzogPC9iPlRheWxvciBCcmFuZHN0ZXR0 ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkZWFkYmVlZkBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+ZGVhZGJlZWZAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBo cmVmPSJtYWlsdG86aWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNlQGlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmljZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmljZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWNlXSBDb250 cmFkaWN0aW9uIHJlZ2FyZGluZyB3aGVuIGFuIElDRSBhZ2VudCBpcyBhbGxvd2VkIHRvIHNlbmQg bWVkaWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Mb29r aW5nIG92ZXIgUkZDIDUyNDViaXMsIHRoZXJlIGFyZSBhIG51bWJlciBvZiBwbGFjZXMgaW4gdGhl IHRleHQgdGhhdCBzaG91bGQgaGF2ZSBiZWVuIHVwZGF0ZWQgdG8gYWxsb3cgcGFzc2l2ZS1hZ2dy ZXNzaXZlIG5vbWluYXRpb24gdGhhdCB3ZXJlIGluc3RlYWQgbGVmdCBhcw0KIGlzLiZuYnNwOyBU aGVyZSBhcmUgaXNzdWVzIGluIFNlY3Rpb24gMi42ICh3aGljaCBzYXlzICZxdW90O0lDRSB3aWxs IG5vdyBzZW5kIG1lZGlhIHVzaW5nIHRoaXMgcGFpciZxdW90OyksIFNlY3Rpb24gMyAod2hpY2gg ZGVmaW5lcyAmcXVvdDtzZWxlY3RlZCBwYWlyJnF1b3Q7IGFzICZxdW90O1RoZSBjYW5kaWRhdGUg cGFpciBzZWxlY3RlZCBieSBJQ0UgZm9yIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBtZWRpYSZxdW90 OyksIFNlY3Rpb24gNi4yLjMuMSAod2hpY2ggc3RpbGwgbWVudGlvbnMgYWdncmVzc2l2ZQ0KIG5v bWluYXRpb24hKSBhbmQgU2VjdGlvbiA5LjEuMS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QSBwb3RlbnRp YWwgcmV3cml0ZSBvZiBTZWN0aW9uIDkuMS4xIG1pZ2h0IGxvb2sgbGlrZSB0aGlzOiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mcXVvdDs5LjEuMS4mbmJzcDsgUHJvY2VkdXJlcyBmb3IgRnVsbCBJbXBsZW1l bnRhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO0EgZnVsbCBpbXBsZW1lbnRhdGlvbiBN VVNUIE5PVCBzZW5kIG1lZGlhIHVudGlsIGl0IGhhcyBhIFZhbGlkIGxpc3Q8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDt0aGF0IGNvbnRhaW5zIGEgY2FuZGlkYXRl IHBhaXIgZm9yIGVhY2ggY29tcG9uZW50IG9mIHRoYXQgbWVkaWE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtzdHJlYW0uJm5ic3A7IE9uY2UgdGhhdCBoYXBwZW5z LCB0aGUgYWdlbnQgTUFZIGJlZ2luIHNlbmRpbmcgbWVkaWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOyAmbmJzcDtwYWNrZXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7 QW4gYWdlbnQgd2lsbCBzZW5kIG1lZGlhIHRvIHRoZSByZW1vdGUgY2FuZGlkYXRlIChzZXR0aW5n IHRoZSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO2Rl c3RpbmF0aW9uIGFkZHJlc3MgYW5kIHBvcnQgb2YgdGhlIHBhY2tldCBlcXVhbCB0byB0aGF0IHJl bW90ZSBjYW5kaWRhdGUpLCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5i c3A7ICZuYnNwO2FuZCB3aWxsIHNlbmQgaXQgZnJvbSB0aGUgbG9jYWwgY2FuZGlkYXRlLiZuYnNw OyBXaGVuIHRoZSBsb2NhbCBjYW5kaWRhdGUgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOyAmbmJzcDtzZXJ2ZXIgb3IgcGVlciByZWZsZXhpdmUsIG1lZGlhIGlzIG9yaWdp bmF0ZWQgZnJvbSB0aGUgYmFzZS4mbmJzcDsgTWVkaWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOyAmbmJzcDtzZW50IGZyb20gYSByZWxheWVkIGNhbmRpZGF0ZSBpcyBzZW50 IGZyb20gdGhlIGJhc2UgdGhyb3VnaCB0aGF0IFRVUk48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOyAmbmJzcDtzZXJ2ZXIsIHVzaW5nIHByb2NlZHVyZXMgZGVmaW5lZCBpbiBb UkZDNTc2Nl0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtJZiB0aGUgbG9jYWwgY2FuZGlkYXRl IGlzIGEgcmVsYXllZCBjYW5kaWRhdGUsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDthbiBhZ2VudCBjcmVhdGUgYSBjaGFu bmVsIG9uIHRoZSBUVVJOIHNlcnZlciB0b3dhcmRzIHRoZSByZW1vdGU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtjYW5kaWRhdGUuJm5ic3A7IFRoaXMgaXMgZG9u ZSB1c2luZyB0aGUgcHJvY2VkdXJlcyBmb3IgY2hhbm5lbCBjcmVhdGlvbiBhczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO2RlZmluZWQgaW4gU2VjdGlvbiAxMSBv ZiBbUkZDNTc2Nl0uJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPklmIHRob3NlIGNoYW5nZXMgYXJlIG1hZGUs IGl0IGxvb2tzIHRvIG1lIGxpa2UgdGhlIHJlc3Qgb2YgdGhlIHRleHQgZnJvbSBTZWN0aW9uIDku MS4xIGNvdWxkIGJlIGRlbGV0ZWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsmcXVvdDtUaGUg c2VsZWN0ZWQgcGFpciBmb3IgYSBjb21wb25lbnQgb2YgYSBtZWRpYSBzdHJlYW0gaXM6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOyAmbmJzcDtvICZuYnNwO2VtcHR5IGlmIHRoZSBzdGF0ZSBvZiB0aGUgY2hl Y2sgbGlzdCBmb3IgdGhhdCBtZWRpYSBzdHJlYW0gaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFJ1bm5pbmcsIGFuZCB0aGVyZSBpcyBubyBwcmV2 aW91cyBzZWxlY3RlZCBwYWlyIGZvciB0aGF0IGNvbXBvbmVudDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZHVlIHRvIGFuIElDRSByZXN0YXJ0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOyAmbmJzcDtvICZuYnNwO2VxdWFsIHRvIHRoZSBwcmV2aW91cyBzZWxl Y3RlZCBwYWlyIGZvciBhIGNvbXBvbmVudCBvZiBhIG1lZGlhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBzdHJlYW0gaWYgdGhlIHN0YXRlIG9mIHRo ZSBjaGVjayBsaXN0IGZvciB0aGF0IG1lZGlhIHN0cmVhbSBpczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgUnVubmluZywgYW5kIHRoZXJlIHdhcyBh IHByZXZpb3VzIHNlbGVjdGVkIHBhaXIgZm9yIHRoYXQgY29tcG9uZW50PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBkdWUgdG8gYW4gSUNFIHJlc3Rh cnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO28gJm5ic3A7ZXF1YWwgdG8gdGhlIGhpZ2hlc3Qt cHJpb3JpdHkgbm9taW5hdGVkIHBhaXIgZm9yIHRoYXQgY29tcG9uZW50IGluPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgdmFsaWQgbGlzdCBp ZiB0aGUgc3RhdGUgb2YgdGhlIGNoZWNrIGxpc3QgaXMgQ29tcGxldGVkJnF1b3Q7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPk9uIFRodSwgU2VwIDI5LCAyMDE2IGF0IDM6NTcgUE0sIEJlcm5hcmQgQWJvYmEgJmx0Ozxh IGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJl cm5hcmQuYWJvYmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPlRoZXJlIGlzIGEgY29udHJhZGljdGlvbiBpbiBkcmFmdC1pZXRmLXJm YzUyNDViaXMgYmVjYXVzZSBhZ2dyZXNzaXZlIG5vbWluYXRpb24gd2FzIHJlbW92ZWQgd2l0aG91 dCBtYWtpbmcgYWxsIHRoZSByZXF1aXJlZCBjaGFuZ2VzIHRvIHJlZ3VsYXIgbm9taW5hdGlvbiB0 byBhbGxvdw0KIHNlbmRpbmcgb2YgbWVkaWEgYmVmb3JlIGEgcGFpciBpcyBub21pbmF0ZWQuIFNv IHRoZSB0ZXh0IGluJm5ic3A7ZHJhZnQtaWV0Zi1yZmM1MjQ1YmlzJm5ic3A7U2VjdGlvbiA5LjEu MSB3YXMgY2FycmllZCBvdmVyIHZlcmJhdGltIGZyb20gUkZDIDUyNDUgU2VjdGlvbiAxMS4xLjEg aW5zdGVhZCBvZiBiZWluZyBhZGFwdGVkLiZuYnNwOyBJTUhPLCB0aGUgcmVxdWlyZW1lbnQgZm9y IHNlbmRpbmcgbWVkaWEgaW4mbmJzcDtkcmFmdC1pZXRmLXJmYzUyNDViaXMmbmJzcDtTZWN0aW9u IDkuMS4yDQogKHdoaWNoIGN1cnJlbnRseSBvbmx5IGFwcGxpZXMgdG8gYSBsaXRlIGltcGxlbWVu dGF0aW9uKSBzaG91bGQgYmUgYXBwbGllZCB0byBhbGwgaW1wbGVtZW50YXRpb25zIChsaXRlIG9y IGZ1bGwpOiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBBIGxpdGUgaW1wbGVtZW50YXRpb24gTVVTVCBOT1Qgc2VuZCBtZWRpYSB1 bnRpbCBpdCBoYXMgYSBWYWxpZCBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRoYXQgY29udGFpbnMgYSBjYW5k aWRhdGUgcGFpciBmb3IgZWFjaCBjb21wb25lbnQgb2YgdGhhdCBtZWRpYTxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBz dHJlYW0uJm5ic3A7IE9uY2UgdGhhdCBoYXBwZW5zLCB0aGUgYWdlbnQgTUFZIGJlZ2luIHNlbmRp bmcgbWVkaWE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgcGFja2V0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk1ha2luZyB0aGlzIGNo YW5nZSBzaG91bGQgbm90IGltcGFjdCBhbiBSRkMgNTI0NS1jb21wbGlhbnQgaW1wbGVtZW50YXRp b24gc2luY2UgUkZDIDUyNDUgU2VjdGlvbiAxMS4yIHNheXM6Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IElDRSBpbXBs ZW1lbnRhdGlvbnMgTVVTVCBiZSBwcmVwYXJlZCB0byByZWNlaXZlIG1lZGlhIG9uIGVhY2g8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgY29tcG9uZW50IG9uIGFueSBjYW5kaWRhdGVzIHByb3ZpZGVkIGZvciB0aGF0IGNv bXBvbmVudCBpbiB0aGUgbW9zdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyByZWNlbnQgb2ZmZXIvYW5zd2VyIGV4Y2hh bmdlIChpbiB0aGUgY2FzZSBvZiBSVFAsIHRoaXMgd291bGQgaW5jbHVkZTxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBi b3RoIFJUUCBhbmQgUlRDUCBpZiBjYW5kaWRhdGVzIHdlcmUgcHJvdmlkZWQgZm9yIGJvdGgpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk9uIFRodSwgU2VwIDI5 LCAyMDE2IGF0IDEyOjM1IFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVyICZsdDs8YSBocmVmPSJtYWls dG86ZGVhZGJlZWZAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRlYWRiZWVmQGdvb2dsZS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+U2VjdGlvbiA2LjIuMS4xIG9mJm5ic3A7ZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJp cy0wNCBzdGF0ZXM6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5CZWZvcmUgdGhlIGFnZW50IGhhcyByZWNlaXZlZCBC aW5kaW5nIHJlc3BvbnNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ YXNzb2NpYXRlZCB3aXRoIHRoZSBbbm9taW5hdGVkXSBjYW5kaWRpYXRlIHBhaXIsIHRoZSBhZ2Vu dCBjYW4gc2VuZCBtZWRpYSBvbiBhbnk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPmNhbmRpZGlhdGUgZm9yIHdoaWNoIGl0IGhhcyByZWNlaXZlZCBCaW5kaW5nIHJlc3Bv bnNlcy4gPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5UbyBtZSwgdGhpcyB3b3VsZCBpbXBseSB0aGF0IHVudGlsIGEgcGFpciBpcyBub21pbmF0ZWQs IHRoZSBJQ0UgYWdlbnQgY2FuIHNlbmQgbWVkaWEgb24gYW55IHBhaXIgd2l0aCBhIGxvY2FsIGNh bmRpZGF0ZSB0aGF0IGhhcyByZWNlaXZlZCBhIGJpbmRpbmcgcmVzcG9uc2UuPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Ib3dldmVyLCBzZWN0aW9uIDkuMS4x IHN0YXRlczo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+SWYgdGhlIHNlbGVjdGVkIHBhaXIgZm9yIGF0IGxlYXN0IG9uZSBjb21wb25lbnQgb2Yg YSBtZWRpYSBzdHJlYW0gaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5lbXB0eSwgYW4gYWdlbnQgTVVTVCBOT1Qgc2VuZCBtZWRpYSBmb3IgYW55IGNvbXBvbmVu dCBvZiB0aGF0IG1lZGlhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+c3RyZWFtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QW5kIHRoZSBzZWxlY3RlZCBwYWlyIGlzIGVt cHR5IHVudGlsIGEgcGFpciBpcyBub21pbmF0ZWQsIHdoaWNoIG1lYW5zIHlvdSBjYW4ndCBzZW5k IG1lZGlhIHVudGlsIGEgcGFpciBpcyBub21pbmF0ZWQuIFRoZSBleGFtcGxlcyBhdCB0aGUgZW5k IG9mIFNlY3Rpb24gMTIgc2VlbXMNCiB0byByZWl0ZXJhdGUgdGhpcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U28s IHdoaWNoIGlzIGl0PyBJIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IGFnZ3Jlc3NpdmUg bm9taW5hdGlvbiB3YXMgYmVpbmcgcmVtb3ZlZCBiZWNhdXNlIHlvdSBjb3VsZCBhY2NvbXBsaXNo IGVzc2VudGlhbGx5IHRoZSBzYW1lIHRoaW5nIHdpdGggcmVndWxhciBub21pbmF0aW9uLA0KIGJ5 IHNlbmRpbmcgbWVkaWEgYmVmb3JlIGEgcGFpciBpcyBub21pbmF0ZWQgKHRoZSBzbyBjYWxsZWQg JnF1b3Q7cGFzc2l2ZSBhZ2dyZXNzaXZlJnF1b3Q7IG5vbWluYXRpb24pLiBCdXQgdGhhdCBkb2Vz bid0IHNlZW0gdG8gYmUgYWxsb3dlZCBieSBzZWN0aW9uIDkuMS4xLiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOkljZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkljZUBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNl PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4BE274C5ESESSMB209erics_-- From nobody Mon Nov 7 18:42:00 2016 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 022EE129637; Mon, 7 Nov 2016 18:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=unavailable 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 xKPCAPLC-VaX; Mon, 7 Nov 2016 18:41:58 -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 5D996129589; Mon, 7 Nov 2016 18:41:58 -0800 (PST) Received: from [10.0.1.21] (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 uA82fpgi069971 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 7 Nov 2016 20:41:52 -0600 (CST) (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.21] From: "Ben Campbell" To: "Pal Martinsen" Date: Mon, 07 Nov 2016 20:41:51 -0600 Message-ID: In-Reply-To: References: <147808133311.24126.15765271660818591137.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: Ari =?utf-8?q?Ker=C3=A4nen?= , "draft-ietf-ice-dualstack-fairness@ietf.org" , "ice-chairs@ietf.org" , "ice@ietf.org" , Mirja Kuehlewind , The IESG Subject: Re: [Ice] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-ice-dualstack-fairness-06=3A_=28with_COMMENT=29?= X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 02:41:59 -0000 On 7 Nov 2016, at 7:33, Pal Martinsen (palmarti) wrote: > New version (-07) is ready. But not uploaded.. > Unless the chairs or ADs are in a hurry this can probably wait as this > will be published together with ICEbis. > > Can easily send xml and txt file if needed. The pre-meeting black out ends Monday morning. Please submit 07 at your convenience after that, and poke me. I should be able to approve it at that point. Thanks! Ben. From nobody Sun Nov 13 13:56:30 2016 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 A510E1295F6; Sun, 13 Nov 2016 13:56:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147907418563.5505.6467977891584495511.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 13:56:25 -0800 Archived-At: Cc: ice@ietf.org Subject: [Ice] I-D Action: draft-ietf-ice-dualstack-fairness-07.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 21:56:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment of the IETF. Title : ICE Multihomed and IPv4/IPv6 Dual Stack Guidelines Authors : Paal-Erik Martinsen Tirumaleswar Reddy Prashanth Patil Filename : draft-ietf-ice-dualstack-fairness-07.txt Pages : 10 Date : 2016-11-13 Abstract: This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backwards compatible with the original ICE specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ice-dualstack-fairness-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-dualstack-fairness-07 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 Sun Nov 13 16:27:09 2016 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 69252129648; Sun, 13 Nov 2016 16:27:04 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147908322440.5509.2124159960388884239.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 16:27:04 -0800 Archived-At: Cc: ice@ietf.org, ben@nostrum.com, Ari Keranen , draft-ietf-ice-dualstack-fairness@ietf.org, ice-chairs@ietf.org Subject: [Ice] Last Call: (ICE Multihomed and IPv4/IPv6 Dual Stack Guidelines) to Informational RFC X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 00:27:07 -0000 The IESG has received a request from the Interactive Connectivity Establishment WG (ice) to consider the following document: - 'ICE Multihomed and IPv4/IPv6 Dual Stack Guidelines' as Informational RFC This document was previously last called with an incorrect intended status. The correct intended status is Informational. Please focus comments on that change. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-11-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backwards compatible with the original ICE specification. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Nov 14 18:22:32 2016 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 9E4DB12969B for ; Mon, 14 Nov 2016 18:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LL2GseGUg5b5 for ; Mon, 14 Nov 2016 18:22:29 -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 4E6B312969A for ; Mon, 14 Nov 2016 18:22:29 -0800 (PST) X-AuditID: c1b4fb3a-c2aab98000000467-b2-582a71630baa Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id BB.C2.01127.3617A285; Tue, 15 Nov 2016 03:22:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0319.002; Tue, 15 Nov 2016 03:21:15 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: ICEbis: Ta default value is 50 ms Thread-Index: AdI+5vBWUgfEbnsWQ2SATPQmhv4aeQ== Date: Tue, 15 Nov 2016 02:21:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE36435@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE36435ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM2K7vW5yoVaEwdWp+hbfLtQ6MHosWfKT KYAxissmJTUnsyy1SN8ugStj3bOTrAUtEhWtO5rYGxini3YxcnJICJhIfL7Ty9zFyMUhJLCO UeLPhCZ2CGcJo8SReV0sXYwcHGwCFhLd/7RBGkQEFCVmtjxjBrGFBbQkGhcfZ4eI60tseryB CcLWk1j17TJYDYuAqsT9+XPYQGxeAV+JQ20fWUFsRgExie+n1oDVMwuIS9x6Mp8J4iABiSV7 zjND2KISLx//Y4WwlSRWbL/ECFGfL/Hs4w9miJmCEidnPmGZwCg4C8moWUjKZiEpg4jrSCzY /YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAgP/4Jbf VjsYDz53PMQowMGoxMNbcFEzQog1say4MvcQowQHs5IIb16eVoQQb0piZVVqUX58UWlOavEh RmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwcnFINjLNSV+zQ2f/l1+2fMgZWDAvbZEIFzqrE tU+qvhZdVHBKaXPK0+WvO+cHqrVcMz3502/JvYKojxcuVrB4vz+0JU/3ksFbV9FMm5QdkQtm zC5TdDl6xSzo+53HZ9LWM4icL/5yVHAX/9nF58vVHLL9te5kzFTaESLpePCy9OoIvmO3/1y4 oDjFKkKJpTgj0VCLuag4EQDsH6DgeAIAAA== Archived-At: Subject: [Ice] ICEbis: Ta default value is 50 ms X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 02:22:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE36435ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think I was a little unclear during my Ta presentation yesterday, so just= to clarify: The default value is 50 ms. The minimum value is 5 ms. I think I claimed that the default value is 5 ms. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4BE36435ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I think I was a little unclear during my Ta presenta= tion yesterday, so just to clarify:

 

The default value is 50 ms.

The minimum value is 5 ms.

 

I think I claimed that the default value is 5 ms.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4BE36435ESESSMB209erics_-- From nobody Tue Nov 15 16:13:40 2016 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 09DA41293D6 for ; Tue, 15 Nov 2016 16:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 mxXrsItbVBZg for ; Tue, 15 Nov 2016 16:13:36 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FA71293FE for ; Tue, 15 Nov 2016 16:13:35 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id 3so72256275pgd.0 for ; Tue, 15 Nov 2016 16:13:35 -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=tZEolMugDP2Ng0+NI9Iksi1wIULDi+47Tg2W44UXvtw=; b=Qr9oxkiB0a/3b/yHn73enmpjrZdjPZzfOL2uuD/FUi5zOKaBFNb0gqP2a30sdzjQyk kLKeBCeuSgjx0TNhWkMznZGwn1ZHn/opR5zksTqNcE9noJGX/zPosoGhKEyVNFsBFqfs ViRemnDOXm6kEp4mABsF2H4rbGWXxOnsz8VXY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tZEolMugDP2Ng0+NI9Iksi1wIULDi+47Tg2W44UXvtw=; b=HaqUDfSSPuDa3Y08eBqgL9H+BfQ0m3qmNmnjVn+sGXQfp1/eEDMF4Nf7xiM/K5UN8x R93TcIU1MlyykuvworuQpIp/bZybRSrqoATnrSSZLsIwHs0FJIeuQn4DT80V36RyumcM 7A2q+6mnLkKk/u9wCzP/4IYdp95u10glxxJp1Yr6pmSe2BkfjMLPnobSLeaJGgnv73yQ PQMQ0MTJn2ZlQEz+6LNtO8jnYl7xr7032VfHnMPc8p2D3QFhImP1KsDwbPZVF9gX96ft WyZUXktpISSEV7Os/NcvRS3qfZHVC6RxwjZTffF8H/FEcf2h4N9tRN2D835ZviOAfHwM 34jQ== X-Gm-Message-State: ABUngvfnlk2XThPPSVVFaxj8ge79nllHbNPSByb21K1awnS97gWwvAQwL0HHo6Z6Gz2iEkwo X-Received: by 10.98.14.143 with SMTP id 15mr396596pfo.11.1479255215487; Tue, 15 Nov 2016 16:13:35 -0800 (PST) Received: from ?IPv6:2620:101:80fc:224:34d8:61a7:5f1c:1537? ([2620:101:80fc:224:34d8:61a7:5f1c:1537]) by smtp.gmail.com with ESMTPSA id t20sm46576950pfk.48.2016.11.15.16.13.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 16:13:34 -0800 (PST) From: Nils Ohlmeier Message-Id: <8592E7AD-E010-4945-8C2D-BDB544516B75@mozilla.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_95EC445E-FCAA-45E5-9EF9-AB66D34494B6" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Tue, 15 Nov 2016 16:13:32 -0800 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE1AEAD@ESESSMB209.ericsson.se> To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B4BE1AEAD@ESESSMB209.ericsson.se> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: Definition of "base" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 00:13:39 -0000 --Apple-Mail=_95EC445E-FCAA-45E5-9EF9-AB66D34494B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 > On Nov 3, 2016, at 06:27, Christer Holmberg = wrote: >=20 > Actually, I=E2=80=99d prefer to call it =E2=80=9CCandidate base=E2=80=9D= . > =C2=A0 <> > From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 03 November 2016 13:42 > To: ice@ietf.org > Subject: Re: [Ice] 5245bis: Definition of "base" > =20 > Hi, > =20 > Suggestion for modified base definition: > =20 > "Base: The transport address that an agent sends from for a particular = candidate. For host-, server reflexive- and peer reflexive candidates = the base is the same as the host candidate. For relayed candidates the = base is the same as the relayed candidate.=E2=80=9D > =20 > With that, we=E2=80=99d remove all other sentences describing what a = base is. > =20 > Regards, > =20 > Christer > =20 > From: Ice > on = behalf of Christer Holmberg > > Date: Wednesday 2 November 2016 at 14:58 > To: "ice@ietf.org " > > Subject: [Ice] 5245bis: Definition of "base" > =20 > Hi, > =20 > Section 2.1 of draft-5245-bis says: > =20 > "We call the host candidate associated with a given server = reflexive candidate > the BASE.=E2=80=9D > "Note: "Base" refers to the address an agent sends from for a > particular candidate. Thus, as a degenerate case host = candidates > also have a base, but it's the same as the host candidate.=E2=80=9D= > Q1: The note seems to contradict with the text above, which says a = base is only associated with a server reflexive candidate. > =20 > Q2: The note is unclear on whether =E2=80=9Caddress=E2=80=9D also = includes the port. I assume it does, in which case I think it should be = =E2=80=9Ctransport address=E2=80=9D. > =20 > "If the agent is not behind a NAT, then the base candidate will be = the same as the server > reflexive candidate and the server reflexive candidate is redundant = and will be eliminated." > =E2=80=9CBase candidate=E2=80=9D is not defined anywhere (and, afaik, = not used elsewhere in the document). I assume we should say either = =E2=80=9Cbase=E2=80=9D or =E2=80=9Chost candidate=E2=80=9D. > =20 > =20 > Section 3 says: > =20 > "Base: The base of a server reflexive candidate is the host = candidate > from which it was derived. A host candidate is also said to = have > a base, equal to that candidate itself. Similarly, the base of = a > relayed candidate is that candidate itself." > Q3: This text talks about =E2=80=9Cderived=E2=80=9D, which is = different terminology than elsewhere. > =20 > =20 > Section 4.1.1 says: > =20 > "The base of a candidate is the candidate that an agent must send = from when using that candidate. > Q4: There are now 3 different places defining =E2=80=9Cbase=E2=80=9D, = all with different terminology. In=20 > =20 > SUGGESTION: We should only define =E2=80=9Cbase=E2=80=9D once, in = section 3. > =20 > Regards, > =20 > Christer > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice --Apple-Mail=_95EC445E-FCAA-45E5-9EF9-AB66D34494B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

On Nov 3, 2016, at 06:27, Christer Holmberg = <christer.holmberg@ericsson.com> wrote:

Actually, I=E2=80=99d prefer to call it = =E2=80=9CCandidate base=E2=80=9D.
 
From: Ice [mailto:ice-bounces@ietf.org] On Behalf = Of Christer = Holmberg
Sent: 03 November 2016 13:42
To: ice@ietf.org
Subject: Re: [Ice] 5245bis: = Definition of "base"
 
Hi,
 
Suggestion for modified base definition:
 
"Base: The transport = address that an agent sends from for a particular candidate. For host-, = server reflexive- and peer reflexive candidates the base is the same as = the host candidate. For relayed candidates the base is the same as the = relayed candidate.=E2=80=9D
 
With that, we=E2=80=99d remove all other sentences describing = what a base is.
 
Regards,
 
Christer
 
From: Ice <ice-bounces@ietf.org> on behalf of Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Wednesday 2 November = 2016 at 14:58
To: "ice@ietf.org" <ice@ietf.org>
Subject: [Ice] 5245bis: = Definition of "base"
 
Hi,
 
Section 2.1 of draft-5245-bis says:
 
   "We call the host candidate associated with a =
given server reflexive candidate
   the =
BASE.=E2=80=9D
      "Note: "Base" refers to the =
address an agent sends from for a
      particular candidate.  =
Thus, as a degenerate case host candidates
      also have a base, but it's the =
same as the host candidate.=E2=80=9D
Q1: The note seems to contradict with the text above, which =
says a base is only associated with a server reflexive candidate.
 
Q2: The note is unclear on whether =
=E2=80=9Caddress=E2=80=9D also includes the port. I assume it does, in =
which case I think it should be =E2=80=9Ctransport address=E2=80=9D.
 
   "If the agent is not behind a NAT, then the =
base candidate will be the same as the server
   reflexive candidate and the server reflexive =
candidate is redundant and will be eliminated."
=E2=80=9CBase candidate=E2=80=9D is not defined =
anywhere (and, afaik, not used elsewhere in the document). I assume we =
should say either =E2=80=9Cbase=E2=80=9D or =E2=80=9Chost =
candidate=E2=80=9D.
 
 
Section 3 says:
 
      "Base:  The base of a =
server reflexive candidate is the host candidate
      from which it was =
derived.  A host candidate is also said to have
      a base, equal to that =
candidate itself.  Similarly, the base of a
      relayed candidate is that =
candidate itself."
Q3: This text =
talks about =E2=80=9Cderived=E2=80=9D, which is different terminology =
than elsewhere.
 
 
Section  4.1.1 says:
 
   "The base of a candidate is the candidate that =
an agent must send from when using that candidate.
Q4: There are now 3 different places defining =
=E2=80=9Cbase=E2=80=9D, all with different terminology. In 
 
SUGGESTION: We should only define =
=E2=80=9Cbase=E2=80=9D once, in section 3.
 
Regards,
 
Christer
_______________________________________________
Ice mailing = list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice

= --Apple-Mail=_95EC445E-FCAA-45E5-9EF9-AB66D34494B6-- From nobody Tue Nov 15 16:26:34 2016 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 389F2129602 for ; Tue, 15 Nov 2016 16:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 zxVJwUqUBRwO for ; Tue, 15 Nov 2016 16:26:30 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::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 97A3B129528 for ; Tue, 15 Nov 2016 16:26:30 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id x23so69487659pgx.1 for ; Tue, 15 Nov 2016 16:26:30 -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=wae43cX+sR3DsFMDJNmZUcFRO2t6TsvfkqYwR/n6OLw=; b=QnmMhkX4V1cPTLYrxPN2rcE84WSKgtJUqyuRwzKIIa7Bt3zSBIWLQ0x6Y5/skjOL5a 6mwou4tHTFTBOmsCiLZGdCCHu95LKpydp1FaZbXxjQHnR2ZNKo7j3F5xsjdzTG3QY357 D3En96IW3ApV475AYmmq66anOmA7l+xoWsWyQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=wae43cX+sR3DsFMDJNmZUcFRO2t6TsvfkqYwR/n6OLw=; b=l2VIMDFIpVWh4wvnL+IcDhLx4Yati2q4NVRTLPrkphLrSrMimYvVVSuD1x2ib6az3T l9kTWl+oyGf2A2nrkfHy7zFGOudPyEdp0vP15zj1BI//QqvEyMy4eEcif1qwkH0zqNCM c1AGizLOEeZvw44XfX8Q6/Za3WEN+621KcgQ9NmTEGWKSHc0EY9rVxe0I/GEHjeQ0e/A P9I+mNqtQGjRA+yLdq/qlewdNQsDqatR9mYtOm4mspEpiDN/JPFhlSsq9JzSfnoFIT6P /9eP8vdaDQNpo3KlqyVwdfjH0hR6OSE1qf5vV5k4iRpaGtbXlbeS4WVU2x538UEOX/mH /m7A== X-Gm-Message-State: ABUngveqDoHHoPAA+FJ8rQfDtTAj2DoPGd6fU9efHlEvS1bdixhY0gu6WKSc/3bUqpgnDlds X-Received: by 10.98.11.71 with SMTP id t68mr471934pfi.136.1479255990033; Tue, 15 Nov 2016 16:26:30 -0800 (PST) Received: from ?IPv6:2620:101:80fc:224:34d8:61a7:5f1c:1537? ([2620:101:80fc:224:34d8:61a7:5f1c:1537]) by smtp.gmail.com with ESMTPSA id f132sm46602734pfa.72.2016.11.15.16.26.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 16:26:28 -0800 (PST) From: Nils Ohlmeier Message-Id: <444CEBD9-D85D-4760-9C8B-B40B1CB04172@mozilla.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D5C15D3B-53F3-4F21-BC66-809DF0A3AB27" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Tue, 15 Nov 2016 16:26:26 -0800 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE1C70E@ESESSMB209.ericsson.se> To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B4BE1C70E@ESESSMB209.ericsson.se> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: Discarding low-priority candidates X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 00:26:33 -0000 --Apple-Mail=_D5C15D3B-53F3-4F21-BC66-809DF0A3AB27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On Nov 3, 2016, at 11:17, Christer Holmberg = wrote: > Section 5.1.3.3 (Pruning the Pairs) of 5245bis contains the following = paragraph: > =20 > =E2=80=9CIn addition, in order to limit the attacks described in > Section 13.4.1, an agent MUST limit the total number of connectivity > checks the agent performs across all check lists to a specific = value, > and this value MUST be configurable. A default of 100 is > RECOMMENDED. This limit is enforced by discarding the = lower-priority > candidate pairs until there are less than 100. It is RECOMMENDED > that a lower value be utilized when possible, set to the maximum > number of plausible checks that might be seen in an actual = deployment > configuration. The requirement for configuration is meant to = provide > a tool for fixing this value in the field if, once deployed, it is > found to be problematic.=E2=80=9D > =20 > I guess we can have some text about removing low-priority candidate = pairs, but do we really need a number? The number appears to be taken from section 14.4.1. If there is no = number provided I think should suggest some heuristic to calculate such = a number. But I have no real idea how such a heuristic could look like. > And, if we need a number, do we need to take into consideration = multiple ICE instances (e.g., multiple browser tabs)? That appears to assume that the ICE implementation is shared across = multiple browser tabs, which could be the case or not. =20 > Also, is removing low-priority candidates really part of pruning? = Elsewhere in the document where pruning is mentioned there is no word = about removing low-priority candidates. So, if we want to keep the text = (or a modified version of it), perhaps it should be a separate section? To me pruning and this security measure are two different things. = Pruning is basically removing duplicates. I think a separate section would be appropriate. Best Nils Ohlmeier --Apple-Mail=_D5C15D3B-53F3-4F21-BC66-809DF0A3AB27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On Nov 3, 2016, at 11:17, = Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Section = 5.1.3.3 (Pruning the Pairs) of 5245bis contains the following = paragraph:
 
   =E2=80=9CIn addition, in order to limit the = attacks described in
  Section 13.4.1, an = agent MUST limit the total number of connectivity
   checks the agent performs across all check lists = to a specific value,
   and this value MUST = be configurable.  A default of 100 is
   RECOMMENDED.  This limit is enforced by = discarding the lower-priority
   candidate pairs = until there are less than 100.  It is RECOMMENDED
   that a lower value be utilized when possible, = set to the maximum
   number of plausible checks that might be seen in = an actual deployment
   = configuration.  The requirement for configuration is meant to = provide
   a tool for fixing this value in the field if, = once deployed, it is
   found to be = problematic.=E2=80=9D
 
I guess we can have some text about = removing low-priority candidate pairs, but do we really need a = number?

The = number appears to be taken from section 14.4.1. If there is no number = provided I think should suggest some heuristic to calculate such a = number. But I have no real idea how such a heuristic could look = like.

And, if = we need a number, do we need to take into consideration multiple ICE = instances (e.g., multiple browser tabs)?

That appears to assume that the ICE implementation is = shared across multiple browser tabs, which could be the case or = not.
 
Also, is removing low-priority candidates really part of = pruning? Elsewhere in the document where pruning is mentioned there is = no word about removing low-priority candidates. So, if we want to keep = the text (or a modified version of it), perhaps it should be a separate = section?

To me pruning and this security measure are two = different things. Pruning is basically removing duplicates.
I = think a separate section would be appropriate.

Best
  Nils Ohlmeier

= --Apple-Mail=_D5C15D3B-53F3-4F21-BC66-809DF0A3AB27-- From nobody Tue Nov 15 16:51:18 2016 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 6C87712941C for ; Tue, 15 Nov 2016 16:51:17 -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, 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 qsmJ3g9XAEvh for ; Tue, 15 Nov 2016 16:51:14 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D7501293F9 for ; Tue, 15 Nov 2016 16:51:14 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id x23so69710627pgx.1 for ; Tue, 15 Nov 2016 16:51:14 -0800 (PST) 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=cA64mIn78kXq96qEZFPCBYX65dqMDtCJJ3+qacareIw=; b=AWg99pD1QT4HSa7zwzPJrwl7t+MtJlH9CwjErxLoR+IPFvX/veRVtMbMdfjoH2AgDi y8zWdd4j5wE7bdl8UDhRJVeRNwg7h9tuMMjf8vIY2UDdiTHnczBBOIAEyJXacSjh5W4b yi1XM75doYyJYkZX7O5p3clAOPuTbGTxSCfbU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cA64mIn78kXq96qEZFPCBYX65dqMDtCJJ3+qacareIw=; b=XU38X7GSPPc5k93R7F+rBdOplvxzzu/HoFuUjSIKFlyl4BGND8l/e45gPgEamNKac7 CbbwuT5aM2cwNVWnl7P9K5qMFoQRyRXguqreqZpF60tlpR557K10bbSLOu6TbjlIiiNR VTGK6Zj9/5X/p0BuHqIMqFeVeaKCpH97T8JfjJ9XM0iYeuqFAwYTj1RZd3ijFWsd+1NA 9K1lH+VisiO6SOeOdxoGcoTLz75Lh1w4y385MLGtUX1qEStVIwb7WUOHIdiFo4LuMVVV Ugx3enGGIR14WxwnY2jeKKOiv8nLBH0uuA+v9rVcMfFoZTyrrH7kW7iwrKbRQP5RNUKA p/fg== X-Gm-Message-State: ABUngvfc02kyBhl/IsxB9OGqgbObYydd3nm3rcXDgMH2J4fYbzvqMVMXzBEb24mwsdxhzqLy X-Received: by 10.98.14.82 with SMTP id w79mr599495pfi.153.1479257473686; Tue, 15 Nov 2016 16:51:13 -0800 (PST) Received: from ?IPv6:2620:101:80fc:224:34d8:61a7:5f1c:1537? ([2620:101:80fc:224:34d8:61a7:5f1c:1537]) by smtp.gmail.com with ESMTPSA id b64sm46682787pfc.74.2016.11.15.16.51.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 16:51:12 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Nils Ohlmeier In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE1C36A@ESESSMB209.ericsson.se> Date: Tue, 15 Nov 2016 16:51:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <37F6A130-E058-4683-B566-AD250032AB3F@mozilla.com> <78810E33-18A5-4C8D-89F0-A4B943C4520F@mozilla.com> <85414E3B-744A-48A2-BA6C-DC96E677484D@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4BE1C36A@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Triggered checks are missing peer reflexive X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 00:51:17 -0000 Hi Christer, public shaming in WG meetings works :-) Sorry for going into hibernation early... > On Nov 3, 2016, at 08:46, Christer Holmberg = wrote: >=20 >> The only bit left is that if it took me that many readings to = understand the difference between the check list and=20 >> the valid list we might be interested in making the wording in that = sections a little bit stronger or more clear to=20 >> prevent other readers from wasting more time on this like I did. >=20 > 5245bis is a complex document to read, so whatever suggestions you = have for making things more clear I am happy to hear :)=20 >=20 > For example, regarding the difference between check list and valid = list, perhaps we could add some more text to the definitions in section = 3? I don=E2=80=99t think that would have helped in my case. My suggestion = would be something like this at the end of section 6.1.3.2.2: The pair is then added to the VALID LIST, but not to the CHECK LIST. BTW while we are on the topic of check vs valid list. Is there any = reason why the list names sometimes capitalized and sometimes not? If not it would be nice to make the names consistent in one way or the = other throughout the whole document. Best Nils > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >> On Oct 4, 2016, at 02:58, Christer Holmberg = wrote: >>=20 >> Hi Nils, >>=20 >> Sorry for the late reply. >>=20 >> If I understand the issue correctly, this could only happen with = trickle. >> Because, in normal cases pruning would take care of it. >>=20 >> Or? >>=20 >> Regards, >>=20 >> Christer >>=20 >> On 20/09/16 06:46, "Ice on behalf of Nils Ohlmeier"=20 >> wrote: >>=20 >>> After reading up on how the current Trickle ICE draft proposes to=20 >>> handle peer reflexive candidates it appears to me that my scenario=20= >>> below is relevant for ICE 5245bis if there is no STUN server. >>> And if there is a STUN server then it should only happen if B has=20 >>> trickled his public host candidate to A already. And A receives its=20= >>> binding response from B before it discovers his own server reflexive=20= >>> by receiving a binding response from the STUN server. >>>=20 >>> Even if we don=C2=B9t bother do try to optimize the = useless/redundant=20 >>> trigger check away I think we should: >>> - include peer reflexive candidates into the paragraph of 5245 which=20= >>> talks about trigger checks >>> - extend the paragraph in the trickle draft to not only mention=20 >>> discovering peer reflexive candidates via STUN binding request, but=20= >>> also from binding responses. >>>=20 >>> I would appreciate some feedback on this before trying to propose=20 >>> improved wording for both specs. >>>=20 >>> Best >>> Nils Ohlmeier >>>=20 >>>> On Sep 2, 2016, at 13:34, Nils Ohlmeier = wrote: >>>>=20 >>>> Hello, >>>>=20 >>>> I have identified something which I would be interested to hear the=20= >>>> opinions of the ICE experts about. >>>>=20 >>>> In RFC 5245 (section 7.2.1.4) and also in bis-04 (section = 6.1.3.1.4)=20 >>>> claim the following regarding receiving triggered checks: >>>> The local candidate will either be a host candidate (...) or a=20 >>>> relayed candidate (=C5=A0). The local candidate can never be a = server=20 >>>> reflexive candidate. >>>>=20 >>>> Which I think is missing the case where the local candidate can = also=20 >>>> a be a peer reflexive. And this is actually causing unnecessary=20 >>>> extra checks to be made. >>>>=20 >>>> Consider the following scenario: >>>>=20 >>>> - A sits behind symmetric NAT >>>> - B is on a publicly routable address with no NAT or firewall >>>> - No STUN servers (just makes the scenario less complex) >>>> - Host candidates get exchanged and candidate pairs A:B and B:A = get=20 >>>> created on both sides >>>> - A sends binding request to B >>>> - B receives binding request with transport address A=C2=B9 >>>> - B creates a peer reflexive candidate for A=C2=B9 and the a new = pair=20 >>>> B:A=C2=B9 and puts that new pair into its trigger check queue >>>> - B sends binding response to A=C2=B9 >>>> - A receives binding response, learns about A=C2=B9 and creates = A=C2=B9:B and=20 >>>> marks it as successful >>>> - Now B sends a binding request for it trigger check queue entry to=20= >>>> A=C2=B9 >>>> - When A receives this binding request is has no way to match this=20= >>>> to the successful pair A=C2=B9:B >>>> - Because of the wording in the above mentioned sections it will=20 >>>> match the request to the pair A:B >>>> - Which then in turn causes another triggered check to be created=20= >>>> because A:B is not in the success state >>>>=20 >>>> This additional triggered check from A is just waste of time and=20 >>>> resources. It does not hurt. But I=C2=B9m wondering how this could = be avoided. >>>>=20 >>>> If people agree I think section 6.1.3.1.4 should at least mention=20= >>>> the scenario that incoming binding requests can also match a peer=20= >>>> reflexive candidate. >>>>=20 >>>> As the incoming binding request does not contain the destination=20 >>>> address it got send to there is obviously no way for A to clearly=20= >>>> distinguish if the request got send to A or A=C2=B9. >>>>=20 >>>> For avoiding the additional triggered check on A=C2=B9s side the = only=20 >>>> solution I see right now is to go through the pairs which have A as=20= >>>> their foundation and if that list contains a pair which is marked = as=20 >>>> successful already assume no triggered check is needed. So far I=20 >>>> have not been able to identify a scenario where it hurts to skip=20 >>>> this extra round of triggered checks on A=C2=B9s side. >>>>=20 >>>> Best >>>> Nils Ohlmeier >>>>=20 >>>=20 >>=20 >=20 From nobody Tue Nov 15 17:00:25 2016 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 B31DF129592 for ; Tue, 15 Nov 2016 17:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEGe51H1ShjS for ; Tue, 15 Nov 2016 17:00:21 -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 CC18F1293D8 for ; Tue, 15 Nov 2016 17:00:20 -0800 (PST) X-AuditID: c1b4fb3a-c2aab98000000467-14-582bafa283bd Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 6C.2C.01127.2AFAB285; Wed, 16 Nov 2016 02:00:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0319.002; Wed, 16 Nov 2016 01:58:13 +0100 From: Christer Holmberg To: Nils Ohlmeier Thread-Topic: [Ice] Triggered checks are missing peer reflexive Thread-Index: AQHSBVlPEOYY7CCEV0C+dqegwGP6+aCBttwAgBacroCABbZ6AIApvL1AgBNk0wCAABI+4A== Date: Wed, 16 Nov 2016 00:58:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE38803@ESESSMB209.ericsson.se> References: <37F6A130-E058-4683-B566-AD250032AB3F@mozilla.com> <78810E33-18A5-4C8D-89F0-A4B943C4520F@mozilla.com> <85414E3B-744A-48A2-BA6C-DC96E677484D@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4BE1C36A@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2J7uO7i9doRBg/7mC2+Xai1uD5vMqMD k8eSJT+ZPPoOdLEGMEVx2aSk5mSWpRbp2yVwZVyf7Fswybli6d1epgbGLY5djJwcEgImEpe6 VrB2MXJxCAmsY5SYvncdE4SzhFHi55PLbF2MHBxsAhYS3f+0QUwRAU2JExv5QExmAUWJl3vV QMYIC9hJzFy3lQ3EFhGwlzizq4Mdwg6TWLP7OFicRUBVYsey16wgNq+Ar0Tvsq9Qmy4zSfR/ /sQIkuAEal6wfAlYEaOAmMT3U2uYQGxmAXGJW0/mM0HcLCCxZM95ZghbVOLl43+sELaSxIrt lxghbtOUWL9LH6JVUWJK90N2iL2CEidnPmGZwCg6C8nUWQgds5B0zELSsYCRZRWjaHFqcXFu upGRXmpRZnJxcX6eXl5qySZGYHQc3PLbagfjweeOhxgFOBiVeHgNorUjhFgTy4orcw8xSnAw K4nwPl8HFOJNSaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+uJBAemJJanZqakFqEUyWiYNTqoFR Vzl/RpAxA3vnd9OeyNyZ26cf4gsLMJn3IiOjfS27zwXFfZ1+JeZ/u9YVWPsbrG4+XDvNtij9 kpJQ0mpe0eRFD8xjl/YoyWceufzOvH7V2q3tpVWXru4Oyaq6GRs0o/FAp5eHfs46C1HP5dkP w98kdGTNW53E93ru6WjD4i2Gfw5bVnVXz1NiKc5INNRiLipOBACVHzUKigIAAA== Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Triggered checks are missing peer reflexive X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:00:24 -0000 SGksDQoNCkkgYW0gbm90IGF3YXJlIG9mIHNvbWV0aW1lcyB1c2luZyBjYXBpdGFsaXplZCBsaXN0 IG5hbWVzIGFuZCBzb21ldGltZXMgbm90LCBhbmQgSSBpbnRlbmQgdG8gYWxpZ24gdGhlIGxpc3Qg bmFtZXMgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJY2UgW21haWx0bzppY2UtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5pbHMgT2hsbWVpZXINClNlbnQ6IDE2IE5vdmVtYmVy IDIwMTYgMDI6NTENClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPg0KQ2M6IGljZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJY2VdIFRyaWdnZXJl ZCBjaGVja3MgYXJlIG1pc3NpbmcgcGVlciByZWZsZXhpdmUNCg0KSGkgQ2hyaXN0ZXIsDQoNCnB1 YmxpYyBzaGFtaW5nIGluIFdHIG1lZXRpbmdzIHdvcmtzIDotKQ0KU29ycnkgZm9yIGdvaW5nIGlu dG8gaGliZXJuYXRpb24gZWFybHkuLi4NCg0KPiBPbiBOb3YgMywgMjAxNiwgYXQgMDg6NDYsIENo cmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0K PiANCj4+IFRoZSBvbmx5IGJpdCBsZWZ0IGlzIHRoYXQgaWYgaXQgdG9vayBtZSB0aGF0IG1hbnkg cmVhZGluZ3MgdG8gDQo+PiB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGNo ZWNrIGxpc3QgYW5kIHRoZSB2YWxpZCBsaXN0IA0KPj4gd2UgbWlnaHQgYmUgaW50ZXJlc3RlZCBp biBtYWtpbmcgdGhlIHdvcmRpbmcgaW4gdGhhdCBzZWN0aW9ucyBhIGxpdHRsZSBiaXQgc3Ryb25n ZXIgb3IgbW9yZSBjbGVhciB0byBwcmV2ZW50IG90aGVyIHJlYWRlcnMgZnJvbSB3YXN0aW5nIG1v cmUgdGltZSBvbiB0aGlzIGxpa2UgSSBkaWQuDQo+IA0KPiA1MjQ1YmlzIGlzIGEgY29tcGxleCBk b2N1bWVudCB0byByZWFkLCBzbyB3aGF0ZXZlciBzdWdnZXN0aW9ucyB5b3UgDQo+IGhhdmUgZm9y IG1ha2luZyB0aGluZ3MgbW9yZSBjbGVhciBJIGFtIGhhcHB5IHRvIGhlYXIgOikNCj4gDQo+IEZv ciBleGFtcGxlLCByZWdhcmRpbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBjaGVjayBsaXN0IGFu ZCB2YWxpZCBsaXN0LCBwZXJoYXBzIHdlIGNvdWxkIGFkZCBzb21lIG1vcmUgdGV4dCB0byB0aGUg ZGVmaW5pdGlvbnMgaW4gc2VjdGlvbiAzPw0KDQpJIGRvbuKAmXQgdGhpbmsgdGhhdCB3b3VsZCBo YXZlIGhlbHBlZCBpbiBteSBjYXNlLiBNeSBzdWdnZXN0aW9uIHdvdWxkIGJlIHNvbWV0aGluZyBs aWtlIHRoaXMgYXQgdGhlIGVuZCBvZiBzZWN0aW9uIDYuMS4zLjIuMjoNCg0KICBUaGUgcGFpciBp cyB0aGVuIGFkZGVkIHRvIHRoZSBWQUxJRCBMSVNULCBidXQgbm90IHRvIHRoZSBDSEVDSyBMSVNU Lg0KDQpCVFcgd2hpbGUgd2UgYXJlIG9uIHRoZSB0b3BpYyBvZiBjaGVjayB2cyB2YWxpZCBsaXN0 LiBJcyB0aGVyZSBhbnkgcmVhc29uIHdoeSB0aGUgbGlzdCBuYW1lcyBzb21ldGltZXMgY2FwaXRh bGl6ZWQgYW5kIHNvbWV0aW1lcyBub3Q/DQpJZiBub3QgaXQgd291bGQgYmUgbmljZSB0byBtYWtl IHRoZSBuYW1lcyBjb25zaXN0ZW50IGluIG9uZSB3YXkgb3IgdGhlIG90aGVyIHRocm91Z2hvdXQg dGhlIHdob2xlIGRvY3VtZW50Lg0KDQpCZXN0DQogIE5pbHMNCg0KPiBSZWdhcmRzLA0KPiANCj4g Q2hyaXN0ZXINCj4gDQo+IA0KPiANCj4gDQo+PiBPbiBPY3QgNCwgMjAxNiwgYXQgMDI6NTgsIENo cmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0K Pj4gDQo+PiBIaSBOaWxzLA0KPj4gDQo+PiBTb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuDQo+PiAN Cj4+IElmIEkgdW5kZXJzdGFuZCB0aGUgaXNzdWUgY29ycmVjdGx5LCB0aGlzIGNvdWxkIG9ubHkg aGFwcGVuIHdpdGggdHJpY2tsZS4NCj4+IEJlY2F1c2UsIGluIG5vcm1hbCBjYXNlcyBwcnVuaW5n IHdvdWxkIHRha2UgY2FyZSBvZiBpdC4NCj4+IA0KPj4gT3I/DQo+PiANCj4+IFJlZ2FyZHMsDQo+ PiANCj4+IENocmlzdGVyDQo+PiANCj4+IE9uIDIwLzA5LzE2IDA2OjQ2LCAiSWNlIG9uIGJlaGFs ZiBvZiBOaWxzIE9obG1laWVyIiANCj4+IDxpY2UtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2Ygbm9obG1laWVyQG1vemlsbGEuY29tPiB3cm90ZToNCj4+IA0KPj4+IEFmdGVyIHJlYWRpbmcg dXAgb24gaG93IHRoZSBjdXJyZW50IFRyaWNrbGUgSUNFIGRyYWZ0IHByb3Bvc2VzIHRvIA0KPj4+ IGhhbmRsZSBwZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGVzIGl0IGFwcGVhcnMgdG8gbWUgdGhhdCBt eSBzY2VuYXJpbyANCj4+PiBiZWxvdyBpcyByZWxldmFudCBmb3IgSUNFIDUyNDViaXMgaWYgdGhl cmUgaXMgbm8gU1RVTiBzZXJ2ZXIuDQo+Pj4gQW5kIGlmIHRoZXJlIGlzIGEgU1RVTiBzZXJ2ZXIg dGhlbiBpdCBzaG91bGQgb25seSBoYXBwZW4gaWYgQiBoYXMgDQo+Pj4gdHJpY2tsZWQgaGlzIHB1 YmxpYyBob3N0IGNhbmRpZGF0ZSB0byBBIGFscmVhZHkuIEFuZCBBIHJlY2VpdmVzIGl0cyANCj4+ PiBiaW5kaW5nIHJlc3BvbnNlIGZyb20gQiBiZWZvcmUgaXQgZGlzY292ZXJzIGhpcyBvd24gc2Vy dmVyIHJlZmxleGl2ZSANCj4+PiBieSByZWNlaXZpbmcgYSBiaW5kaW5nIHJlc3BvbnNlIGZyb20g dGhlIFNUVU4gc2VydmVyLg0KPj4+IA0KPj4+IEV2ZW4gaWYgd2UgZG9uwrl0IGJvdGhlciBkbyB0 cnkgdG8gb3B0aW1pemUgdGhlIHVzZWxlc3MvcmVkdW5kYW50IA0KPj4+IHRyaWdnZXIgY2hlY2sg YXdheSBJIHRoaW5rIHdlIHNob3VsZDoNCj4+PiAtIGluY2x1ZGUgcGVlciByZWZsZXhpdmUgY2Fu ZGlkYXRlcyBpbnRvIHRoZSBwYXJhZ3JhcGggb2YgNTI0NSB3aGljaCANCj4+PiB0YWxrcyBhYm91 dCB0cmlnZ2VyIGNoZWNrcw0KPj4+IC0gZXh0ZW5kIHRoZSBwYXJhZ3JhcGggaW4gdGhlIHRyaWNr bGUgZHJhZnQgdG8gbm90IG9ubHkgbWVudGlvbiANCj4+PiBkaXNjb3ZlcmluZyBwZWVyIHJlZmxl eGl2ZSBjYW5kaWRhdGVzIHZpYSBTVFVOIGJpbmRpbmcgcmVxdWVzdCwgYnV0IA0KPj4+IGFsc28g ZnJvbSBiaW5kaW5nIHJlc3BvbnNlcy4NCj4+PiANCj4+PiBJIHdvdWxkIGFwcHJlY2lhdGUgc29t ZSBmZWVkYmFjayBvbiB0aGlzIGJlZm9yZSB0cnlpbmcgdG8gcHJvcG9zZSANCj4+PiBpbXByb3Zl ZCB3b3JkaW5nIGZvciBib3RoIHNwZWNzLg0KPj4+IA0KPj4+IEJlc3QNCj4+PiBOaWxzIE9obG1l aWVyDQo+Pj4gDQo+Pj4+IE9uIFNlcCAyLCAyMDE2LCBhdCAxMzozNCwgTmlscyBPaGxtZWllciA8 bm9obG1laWVyQG1vemlsbGEuY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IEhlbGxvLA0KPj4+PiAN Cj4+Pj4gSSBoYXZlIGlkZW50aWZpZWQgc29tZXRoaW5nIHdoaWNoIEkgd291bGQgYmUgaW50ZXJl c3RlZCB0byBoZWFyIHRoZSANCj4+Pj4gb3BpbmlvbnMgb2YgdGhlIElDRSBleHBlcnRzIGFib3V0 Lg0KPj4+PiANCj4+Pj4gSW4gUkZDIDUyNDUgKHNlY3Rpb24gNy4yLjEuNCkgYW5kIGFsc28gaW4g YmlzLTA0IChzZWN0aW9uIA0KPj4+PiA2LjEuMy4xLjQpIGNsYWltIHRoZSBmb2xsb3dpbmcgcmVn YXJkaW5nIHJlY2VpdmluZyB0cmlnZ2VyZWQgY2hlY2tzOg0KPj4+PiBUaGUgbG9jYWwgY2FuZGlk YXRlIHdpbGwgZWl0aGVyIGJlIGEgaG9zdCBjYW5kaWRhdGUgKC4uLikgb3IgYSANCj4+Pj4gcmVs YXllZCBjYW5kaWRhdGUgKMWgKS4gVGhlIGxvY2FsIGNhbmRpZGF0ZSBjYW4gbmV2ZXIgYmUgYSBz ZXJ2ZXIgDQo+Pj4+IHJlZmxleGl2ZSBjYW5kaWRhdGUuDQo+Pj4+IA0KPj4+PiBXaGljaCBJIHRo aW5rIGlzIG1pc3NpbmcgdGhlIGNhc2Ugd2hlcmUgdGhlIGxvY2FsIGNhbmRpZGF0ZSBjYW4gDQo+ Pj4+IGFsc28gYSBiZSBhIHBlZXIgcmVmbGV4aXZlLiBBbmQgdGhpcyBpcyBhY3R1YWxseSBjYXVz aW5nIA0KPj4+PiB1bm5lY2Vzc2FyeSBleHRyYSBjaGVja3MgdG8gYmUgbWFkZS4NCj4+Pj4gDQo+ Pj4+IENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW86DQo+Pj4+IA0KPj4+PiAtIEEgc2l0 cyBiZWhpbmQgc3ltbWV0cmljIE5BVA0KPj4+PiAtIEIgaXMgb24gYSBwdWJsaWNseSByb3V0YWJs ZSBhZGRyZXNzIHdpdGggbm8gTkFUIG9yIGZpcmV3YWxsDQo+Pj4+IC0gTm8gU1RVTiBzZXJ2ZXJz IChqdXN0IG1ha2VzIHRoZSBzY2VuYXJpbyBsZXNzIGNvbXBsZXgpDQo+Pj4+IC0gSG9zdCBjYW5k aWRhdGVzIGdldCBleGNoYW5nZWQgIGFuZCBjYW5kaWRhdGUgcGFpcnMgQTpCIGFuZCBCOkEgDQo+ Pj4+IGdldCBjcmVhdGVkIG9uIGJvdGggc2lkZXMNCj4+Pj4gLSBBIHNlbmRzIGJpbmRpbmcgcmVx dWVzdCB0byBCDQo+Pj4+IC0gQiByZWNlaXZlcyBiaW5kaW5nIHJlcXVlc3Qgd2l0aCB0cmFuc3Bv cnQgYWRkcmVzcyBBwrkNCj4+Pj4gLSBCIGNyZWF0ZXMgYSBwZWVyIHJlZmxleGl2ZSBjYW5kaWRh dGUgZm9yIEHCuSBhbmQgdGhlIGEgbmV3IHBhaXIgDQo+Pj4+IEI6QcK5IGFuZCBwdXRzIHRoYXQg bmV3IHBhaXIgaW50byBpdHMgdHJpZ2dlciBjaGVjayBxdWV1ZQ0KPj4+PiAtIEIgc2VuZHMgYmlu ZGluZyByZXNwb25zZSB0byBBwrkNCj4+Pj4gLSBBIHJlY2VpdmVzIGJpbmRpbmcgcmVzcG9uc2Us IGxlYXJucyBhYm91dCBBwrkgYW5kIGNyZWF0ZXMgQcK5OkIgYW5kIA0KPj4+PiBtYXJrcyBpdCBh cyBzdWNjZXNzZnVsDQo+Pj4+IC0gTm93IEIgc2VuZHMgYSBiaW5kaW5nIHJlcXVlc3QgZm9yIGl0 IHRyaWdnZXIgY2hlY2sgcXVldWUgZW50cnkgdG8gDQo+Pj4+IEHCuQ0KPj4+PiAtIFdoZW4gQSBy ZWNlaXZlcyB0aGlzIGJpbmRpbmcgcmVxdWVzdCBpcyBoYXMgbm8gd2F5IHRvIG1hdGNoIHRoaXMg DQo+Pj4+IHRvIHRoZSBzdWNjZXNzZnVsIHBhaXIgQcK5OkINCj4+Pj4gLSBCZWNhdXNlIG9mIHRo ZSB3b3JkaW5nIGluIHRoZSBhYm92ZSBtZW50aW9uZWQgc2VjdGlvbnMgaXQgd2lsbCANCj4+Pj4g bWF0Y2ggdGhlIHJlcXVlc3QgdG8gdGhlIHBhaXIgQTpCDQo+Pj4+IC0gV2hpY2ggdGhlbiBpbiB0 dXJuIGNhdXNlcyBhbm90aGVyIHRyaWdnZXJlZCBjaGVjayB0byBiZSBjcmVhdGVkIA0KPj4+PiBi ZWNhdXNlIEE6QiBpcyBub3QgaW4gdGhlIHN1Y2Nlc3Mgc3RhdGUNCj4+Pj4gDQo+Pj4+IFRoaXMg YWRkaXRpb25hbCB0cmlnZ2VyZWQgY2hlY2sgZnJvbSBBIGlzIGp1c3Qgd2FzdGUgb2YgdGltZSBh bmQgDQo+Pj4+IHJlc291cmNlcy4gSXQgZG9lcyBub3QgaHVydC4gQnV0IEnCuW0gd29uZGVyaW5n IGhvdyB0aGlzIGNvdWxkIGJlIGF2b2lkZWQuDQo+Pj4+IA0KPj4+PiBJZiBwZW9wbGUgYWdyZWUg SSB0aGluayBzZWN0aW9uIDYuMS4zLjEuNCBzaG91bGQgYXQgbGVhc3QgbWVudGlvbiANCj4+Pj4g dGhlIHNjZW5hcmlvIHRoYXQgaW5jb21pbmcgYmluZGluZyByZXF1ZXN0cyBjYW4gYWxzbyBtYXRj aCBhIHBlZXIgDQo+Pj4+IHJlZmxleGl2ZSBjYW5kaWRhdGUuDQo+Pj4+IA0KPj4+PiBBcyB0aGUg aW5jb21pbmcgYmluZGluZyByZXF1ZXN0IGRvZXMgbm90IGNvbnRhaW4gdGhlIGRlc3RpbmF0aW9u IA0KPj4+PiBhZGRyZXNzIGl0IGdvdCBzZW5kIHRvIHRoZXJlIGlzIG9idmlvdXNseSBubyB3YXkg Zm9yIEEgdG8gY2xlYXJseSANCj4+Pj4gZGlzdGluZ3Vpc2ggaWYgdGhlIHJlcXVlc3QgZ290IHNl bmQgdG8gQSBvciBBwrkuDQo+Pj4+IA0KPj4+PiBGb3IgYXZvaWRpbmcgdGhlIGFkZGl0aW9uYWwg dHJpZ2dlcmVkIGNoZWNrIG9uIEHCuXMgc2lkZSB0aGUgb25seSANCj4+Pj4gc29sdXRpb24gSSBz ZWUgcmlnaHQgbm93IGlzIHRvIGdvIHRocm91Z2ggdGhlIHBhaXJzIHdoaWNoIGhhdmUgQSBhcyAN Cj4+Pj4gdGhlaXIgZm91bmRhdGlvbiBhbmQgaWYgdGhhdCBsaXN0IGNvbnRhaW5zIGEgcGFpciB3 aGljaCBpcyBtYXJrZWQgDQo+Pj4+IGFzIHN1Y2Nlc3NmdWwgYWxyZWFkeSBhc3N1bWUgbm8gdHJp Z2dlcmVkIGNoZWNrIGlzIG5lZWRlZC4gU28gZmFyIEkgDQo+Pj4+IGhhdmUgbm90IGJlZW4gYWJs ZSB0byBpZGVudGlmeSBhIHNjZW5hcmlvIHdoZXJlIGl0IGh1cnRzIHRvIHNraXAgDQo+Pj4+IHRo aXMgZXh0cmEgcm91bmQgb2YgdHJpZ2dlcmVkIGNoZWNrcyBvbiBBwrlzIHNpZGUuDQo+Pj4+IA0K Pj4+PiBCZXN0DQo+Pj4+IE5pbHMgT2hsbWVpZXINCj4+Pj4gDQo+Pj4gDQo+PiANCj4gDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJY2UgbWFpbGlu ZyBsaXN0DQpJY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWNlDQo= From nobody Tue Nov 15 17:04:02 2016 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 7026D129431 for ; Tue, 15 Nov 2016 17:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RW6BwofE5sz0 for ; Tue, 15 Nov 2016 17:04:00 -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 EBE5A1293F9 for ; Tue, 15 Nov 2016 17:03:59 -0800 (PST) X-AuditID: c1b4fb30-dc07098000007ca6-c2-582bb07ed0c8 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 2C.E9.31910.E70BB285; Wed, 16 Nov 2016 02:03:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Wed, 16 Nov 2016 02:01:05 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: Name of check list check trigger timer Thread-Index: AdI/pOhgy0x4mzC3RSqNweMEsGzDWw== Date: Wed, 16 Nov 2016 01:01:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE38871@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE38871ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM2K7tG7dBu0Ig10nxC2+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG6imHWQp2iFdMPhvUwHhFpIuRg0NCwERi+7a4LkYuDiGBdYwS /aveskM4Sxgl5v54yAxSxCZgIdH9T7uLkZNDREBRYmbLM2YQWxgovLG1kRGkRETAVmLmi2yI Ej2Ju8cusoHYLAKqEqf/XGYHsXkFfCWav/WCtTIKiEl8P7WGCcRmFhCXuPVkPpgtISAgsWTP eWYIW1Ti5eN/rBC2ksSK7ZcYIerzJbqPHmGCmCkocXLmE5YJjIKzkIyahaRsFpIyiLiOxILd n9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMOQPbvlt sIPx5XPHQ4wCHIxKPLwG0doRQqyJZcWVuYcYJTiYlUR4n68DCvGmJFZWpRblxxeV5qQWH2KU 5mBREuc1W3k/XEggPbEkNTs1tSC1CCbLxMEp1cCoGpvCFmH/v5NVIoZd98zfdbwnzfMvp58W zVU1eXy9VkDpWe3qk5lCPWeCs5m2S2+tyc8yn3vK+S7POjGfQtG1TG6z735SuHzFyzrUr6T7 utiuvK/HjrToNZ7RsJFf+qGyJX7NyaSm4581mbZI9zdv3nstOVLQPFdScFt7Xoggz2wWnhcP QpVYijMSDbWYi4oTAem0Y7h1AgAA Archived-At: Subject: [Ice] 5245bis: Name of check list check trigger timer X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:04:01 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE38871ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Currently, the timer (Ta*N) which is eventually used to trigger check lists= checks does not have a name. My suggestion would be to give it a name, because it is then easier to refe= rence it. "Tc", or something. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4BE38871ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Currently, the timer (Ta*N) which is eventually used= to trigger check lists checks does not have a name.

 

My suggestion would be to give it a name, because it= is then easier to reference it. “Tc”, or something.=

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4BE38871ESESSMB209erics_-- From nobody Tue Nov 15 17:04:11 2016 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 40A3A1294B5 for ; Tue, 15 Nov 2016 17:04:09 -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, 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 92lzEr4L5Zux for ; Tue, 15 Nov 2016 17:04:06 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 25032129412 for ; Tue, 15 Nov 2016 17:04:06 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id f188so72390904pgc.3 for ; Tue, 15 Nov 2016 17:04:06 -0800 (PST) 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=a5zQ0CVNu2gP3dqIPtyIBoQNLGsGG50Ulz0MNt4RMNw=; b=D60/5vHkKMu2zu/vTvf56Yeu58Mf+bBGi5SLePK/L8kOo0J1kVeX9wdJERsFk2QlNa K9wRp+wzCSA4j1kUyVWqfgFVG+VX4j89T3oKYGfEb12fSFrd2U2alBJj10szBarKHvxP AgkDsxGptyur2rVepYKem2BVuwjoVyEc9r06Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=a5zQ0CVNu2gP3dqIPtyIBoQNLGsGG50Ulz0MNt4RMNw=; b=ktsQKvNRRzj5IOdl+S0dqfOOUspjhwH8zTGd4KMggni/caoeCvEqgs/lNTxUMsrFuK c+FNsOY4NxVql8AYU2x6/4o2y0Y7+hiRCSMXtL23SnPI5CaX2XSZvdeMo+ciKrlewW3v cp66gVwsxLDYxhbf+EbfeFU13Nz9vX27WqixrNSxFG3J3NLjJxTKrY8UDF0hN8GksLRv jKmB9+Pm6fmq/MOcSt4uuCJfR2pPtCbk2TQuySTzPiaLyR3rfYbSBfOIGoOg0Sx5buhL V8tZGMYMNvfh2qU1zDFMDzMQAniISs9gxXSEHRcps12uuJ05jHvfeRlWxTmmZ6YO2Ls8 f1GQ== X-Gm-Message-State: ABUngvfvrnYrfZIWUo5kZlgKDEYwesTR206VPF5R+KDJ0+aY7ZYh/ePX7L4subyPWO6LxdGA X-Received: by 10.99.122.92 with SMTP id j28mr2139690pgn.64.1479258245529; Tue, 15 Nov 2016 17:04:05 -0800 (PST) Received: from ?IPv6:2620:101:80fc:224:34d8:61a7:5f1c:1537? ([2620:101:80fc:224:34d8:61a7:5f1c:1537]) by smtp.gmail.com with ESMTPSA id g82sm46751580pfb.43.2016.11.15.17.04.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 17:04:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Nils Ohlmeier In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE224F2@ESESSMB209.ericsson.se> Date: Tue, 15 Nov 2016 17:04:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <66DAD2F7-0D54-4DAB-A343-DB2AFD2C27DE@mozilla.com> References: <37F6A130-E058-4683-B566-AD250032AB3F@mozilla.com> <78810E33-18A5-4C8D-89F0-A4B943C4520F@mozilla.com> <85414E3B-744A-48A2-BA6C-DC96E677484D@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4BE224F2@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Triggered checks are missing peer reflexive X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:04:09 -0000 Hi Christer, > On Nov 6, 2016, at 05:50, Christer Holmberg = wrote: >> Thanks for your reply. I don=E2=80=99t think that there is any = pruning happening when you >discover peer reflexive candidates (you are = suppose to check for an existing equal pair, >not sure if you consider = that as pruning at that step). >=20 > The spec does allow updating of the check list when peer reflexive = candidates have been discovered. But, currently they won't be pruned. >=20 > Could we say that pruning occur when the local candidate doesn't match = the base? That would cover both server reflexive and peer reflexive = candidates. Yes I think it would be help to broaden the scope of pruning like that. = So I would vote for Alt #2 from your slides in Seoul. Although I guess the real reason why pruning does not mention peer = reflexive is that the valid pair which resulted from the peer reflexive = discovery never enters the check list, and pruning only applies to the = check list, but not the valid list. I guess this makes the whole topic = void?! Best Nils Ohlmeier > Regards, >=20 > Christer >=20 >=20 >> On Oct 4, 2016, at 02:58, Christer Holmberg = wrote: >>=20 >> Hi Nils, >>=20 >> Sorry for the late reply. >>=20 >> If I understand the issue correctly, this could only happen with = trickle. >> Because, in normal cases pruning would take care of it. >>=20 >> Or? >>=20 >> Regards, >>=20 >> Christer >>=20 >> On 20/09/16 06:46, "Ice on behalf of Nils Ohlmeier"=20 >> wrote: >>=20 >>> After reading up on how the current Trickle ICE draft proposes to=20 >>> handle peer reflexive candidates it appears to me that my scenario=20= >>> below is relevant for ICE 5245bis if there is no STUN server. >>> And if there is a STUN server then it should only happen if B has=20 >>> trickled his public host candidate to A already. And A receives its=20= >>> binding response from B before it discovers his own server reflexive=20= >>> by receiving a binding response from the STUN server. >>>=20 >>> Even if we don=C2=B9t bother do try to optimize the = useless/redundant=20 >>> trigger check away I think we should: >>> - include peer reflexive candidates into the paragraph of 5245 which=20= >>> talks about trigger checks >>> - extend the paragraph in the trickle draft to not only mention=20 >>> discovering peer reflexive candidates via STUN binding request, but=20= >>> also from binding responses. >>>=20 >>> I would appreciate some feedback on this before trying to propose=20 >>> improved wording for both specs. >>>=20 >>> Best >>> Nils Ohlmeier >>>=20 >>>> On Sep 2, 2016, at 13:34, Nils Ohlmeier = wrote: >>>>=20 >>>> Hello, >>>>=20 >>>> I have identified something which I would be interested to hear the=20= >>>> opinions of the ICE experts about. >>>>=20 >>>> In RFC 5245 (section 7.2.1.4) and also in bis-04 (section = 6.1.3.1.4)=20 >>>> claim the following regarding receiving triggered checks: >>>> The local candidate will either be a host candidate (...) or a=20 >>>> relayed candidate (=C5=A0). The local candidate can never be a = server=20 >>>> reflexive candidate. >>>>=20 >>>> Which I think is missing the case where the local candidate can = also=20 >>>> a be a peer reflexive. And this is actually causing unnecessary=20 >>>> extra checks to be made. >>>>=20 >>>> Consider the following scenario: >>>>=20 >>>> - A sits behind symmetric NAT >>>> - B is on a publicly routable address with no NAT or firewall >>>> - No STUN servers (just makes the scenario less complex) >>>> - Host candidates get exchanged and candidate pairs A:B and B:A = get=20 >>>> created on both sides >>>> - A sends binding request to B >>>> - B receives binding request with transport address A=C2=B9 >>>> - B creates a peer reflexive candidate for A=C2=B9 and the a new = pair=20 >>>> B:A=C2=B9 and puts that new pair into its trigger check queue >>>> - B sends binding response to A=C2=B9 >>>> - A receives binding response, learns about A=C2=B9 and creates = A=C2=B9:B and=20 >>>> marks it as successful >>>> - Now B sends a binding request for it trigger check queue entry to=20= >>>> A=C2=B9 >>>> - When A receives this binding request is has no way to match this=20= >>>> to the successful pair A=C2=B9:B >>>> - Because of the wording in the above mentioned sections it will=20 >>>> match the request to the pair A:B >>>> - Which then in turn causes another triggered check to be created=20= >>>> because A:B is not in the success state >>>>=20 >>>> This additional triggered check from A is just waste of time and=20 >>>> resources. It does not hurt. But I=C2=B9m wondering how this could = be avoided. >>>>=20 >>>> If people agree I think section 6.1.3.1.4 should at least mention=20= >>>> the scenario that incoming binding requests can also match a peer=20= >>>> reflexive candidate. >>>>=20 >>>> As the incoming binding request does not contain the destination=20 >>>> address it got send to there is obviously no way for A to clearly=20= >>>> distinguish if the request got send to A or A=C2=B9. >>>>=20 >>>> For avoiding the additional triggered check on A=C2=B9s side the = only=20 >>>> solution I see right now is to go through the pairs which have A as=20= >>>> their foundation and if that list contains a pair which is marked = as=20 >>>> successful already assume no triggered check is needed. So far I=20 >>>> have not been able to identify a scenario where it hurts to skip=20 >>>> this extra round of triggered checks on A=C2=B9s side. >>>>=20 >>>> Best >>>> Nils Ohlmeier >>>>=20 >>>=20 >>=20 >=20 From nobody Tue Nov 15 17:11:42 2016 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 CC470129552 for ; Tue, 15 Nov 2016 17:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63LQcH8l6jJ9 for ; Tue, 15 Nov 2016 17:11:39 -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 DDC6C129646 for ; Tue, 15 Nov 2016 17:11:23 -0800 (PST) X-AuditID: c1b4fb3a-c2aab98000000467-50-582bb23a4d2e Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 19.AD.01127.A32BB285; Wed, 16 Nov 2016 02:11:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0319.002; Wed, 16 Nov 2016 02:09:30 +0100 From: Christer Holmberg To: Nils Ohlmeier Thread-Topic: [Ice] Triggered checks are missing peer reflexive Thread-Index: AQHSBVlPEOYY7CCEV0C+dqegwGP6+aCBttwAgBacroCABbZ6AIAuVBSwgA7RFQCAABETwA== Date: Wed, 16 Nov 2016 01:09:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE388C3@ESESSMB209.ericsson.se> References: <37F6A130-E058-4683-B566-AD250032AB3F@mozilla.com> <78810E33-18A5-4C8D-89F0-A4B943C4520F@mozilla.com> <85414E3B-744A-48A2-BA6C-DC96E677484D@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4BE224F2@ESESSMB209.ericsson.se> <66DAD2F7-0D54-4DAB-A343-DB2AFD2C27DE@mozilla.com> In-Reply-To: <66DAD2F7-0D54-4DAB-A343-DB2AFD2C27DE@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2K7hK7VJu0Ig1vrRSy+Xai1uD5vMqMD k8eSJT+ZPPoOdLEGMEVx2aSk5mSWpRbp2yVwZRx738BUcM2uovnoRKYGxg7bLkZODgkBE4kF 8xoYuxi5OIQE1jFKTDnzDMpZwijRuOI3kMPBwSZgIdH9TxvEFBHQlDixkQ/EZBZQlHi5Vw1k jLCAncTMdVvZQGwRAXuJM7s62CHsMImDi5+C2SwCqhJfP31gBrF5BXwlpi9qYoPYdJlJ4nDn fxaQmZxAzZe640FqGAXEJL6fWsMEYjMLiEvcejKfCeJkAYkle84zQ9iiEi8f/2OFsJUkVmy/ xAhxmqbE+l36EK2KElO6H7JDrBWUODnzCcsERtFZSKbOQuiYhaRjFpKOBYwsqxhFi1OLi3PT jYz0Uosyk4uL8/P08lJLNjECo+Pglt9WOxgPPnc8xCjAwajEw2sQrR0hxJpYVlyZe4hRgoNZ SYT3+TqgEG9KYmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYzF OoUbjLLlj3zVC1b4r94lelLuSbxKXZOiZM5BnS/i682+frnH6rNJ905QVm3bVE3V40L7hTKE ZN0kj/9cvtu335Bl+syqSS929N6R5vllnaWzmvn4E+E3+Ycmi149oL74NbOGRfTrvOaZS39W SOsnzI33d+E3fTr54Jld2xoUEv9aPO1qfqXEUpyRaKjFXFScCAD1O18zigIAAA== Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Triggered checks are missing peer reflexive X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:11:41 -0000 SGksDQoNCj4+PiBUaGFua3MgZm9yIHlvdXIgcmVwbHkuIEkgZG9u4oCZdCB0aGluayB0aGF0IHRo ZXJlIGlzIGFueSBwcnVuaW5nIGhhcHBlbmluZyB3aGVuIHlvdSANCj4+PiBkaXNjb3ZlciBwZWVy IHJlZmxleGl2ZSBjYW5kaWRhdGVzICh5b3UgYXJlIHN1cHBvc2UgdG8gY2hlY2sgZm9yIGFuIGV4 aXN0aW5nIGVxdWFsIHBhaXIsIA0KPj4+bm90IHN1cmUgaWYgeW91IGNvbnNpZGVyIHRoYXQgYXMg cHJ1bmluZyBhdCB0aGF0IHN0ZXApLg0KPj4gDQo+PiBUaGUgc3BlYyBkb2VzIGFsbG93IHVwZGF0 aW5nIG9mIHRoZSBjaGVjayBsaXN0IHdoZW4gcGVlciByZWZsZXhpdmUgY2FuZGlkYXRlcyBoYXZl IGJlZW4gZGlzY292ZXJlZC4gQnV0LCBjdXJyZW50bHkgdGhleSB3b24ndCBiZSBwcnVuZWQuDQo+ PiANCj4+IENvdWxkIHdlIHNheSB0aGF0IHBydW5pbmcgb2NjdXIgd2hlbiB0aGUgbG9jYWwgY2Fu ZGlkYXRlIGRvZXNuJ3QgbWF0Y2ggdGhlIGJhc2U/IFRoYXQgd291bGQgY292ZXIgYm90aCBzZXJ2 ZXIgcmVmbGV4aXZlIGFuZCBwZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGVzLg0KPg0KPiBZZXMgSSB0 aGluayBpdCB3b3VsZCBiZSBoZWxwIHRvIGJyb2FkZW4gdGhlIHNjb3BlIG9mIHBydW5pbmcgbGlr ZSB0aGF0LiBTbyBJIHdvdWxkIHZvdGUgZm9yIEFsdCAjMiBmcm9tIHlvdXIgc2xpZGVzIGluIFNl b3VsLg0KPg0KPiBBbHRob3VnaCBJIGd1ZXNzIHRoZSByZWFsIHJlYXNvbiB3aHkgcHJ1bmluZyBk b2VzIG5vdCBtZW50aW9uIHBlZXIgcmVmbGV4aXZlIGlzIHRoYXQgdGhlIHZhbGlkIHBhaXIgd2hp Y2ggcmVzdWx0ZWQgZnJvbSB0aGUgcGVlciByZWZsZXhpdmUgZGlzY292ZXJ5IG5ldmVyIGVudGVy cyB0aGUgY2hlY2sgPiBsaXN0LCBhbmQgcHJ1bmluZyBvbmx5IGFwcGxpZXMgdG8gdGhlIGNoZWNr IGxpc3QsIGJ1dCBub3QgdGhlIHZhbGlkIGxpc3QuIEkgZ3Vlc3MgdGhpcyBtYWtlcyB0aGUgd2hv bGUgdG9waWMgdm9pZD8hDQoNCkl0IGlzIHRydWUgdGhhdCB0aGUgSU5JVElBTCBjaGVjayBsaXN0 IGRvZXMgbm90IGNvbnRhaW4gcGVlciByZWZsZXhpdmUgY2FuZGlkYXRlcy4gQnV0LCB0aGUgc3Bl YyBzYXlzIHRoYXQsIG9uY2UgcGVlciByZWZsZXhpdmUgY2FuZGlkYXRlcyBhcmUgZGV0ZWN0ZWQs IHRoZSBjaGVjayBsaXN0IE1BWSBiZSB1cGRhdGVkIChhbmQgc2VudCB0byB0aGUgcGVlcikgd2l0 aCB0aG9zZSBjYW5kaWRhdGVzLiBXaGVuIHN1Y2ggdXBkYXRlIG9jY3VycywgSSBhc3N1bWUgdGhl IGNoZWNrIGxpc3Qgd2lsbCBiZSBwcnVuZWQgYWdhaW4gLSBldmVudGhvdWdoIHRoYXQgaXMgY3Vy cmVudGx5IG5vdCBleHBsaWNpdGx5IHNhaWQgaW4gdGhlIHNwZWMgYWZhaWsgKGl0IHdvdWxkIHBy b2JhYmx5IGJlIGdvb2QgdG8gYWRkIHRleHQgYWJvdXQgdGhhdCkuDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCg0KDQogDQo+PiBPbiBPY3QgNCwgMjAxNiwgYXQgMDI6NTgsIENocmlzdGVyIEhv bG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4gDQo+PiBI aSBOaWxzLA0KPj4gDQo+PiBTb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuDQo+PiANCj4+IElmIEkg dW5kZXJzdGFuZCB0aGUgaXNzdWUgY29ycmVjdGx5LCB0aGlzIGNvdWxkIG9ubHkgaGFwcGVuIHdp dGggdHJpY2tsZS4NCj4+IEJlY2F1c2UsIGluIG5vcm1hbCBjYXNlcyBwcnVuaW5nIHdvdWxkIHRh a2UgY2FyZSBvZiBpdC4NCj4+IA0KPj4gT3I/DQo+PiANCj4+IFJlZ2FyZHMsDQo+PiANCj4+IENo cmlzdGVyDQo+PiANCj4+IE9uIDIwLzA5LzE2IDA2OjQ2LCAiSWNlIG9uIGJlaGFsZiBvZiBOaWxz IE9obG1laWVyIiANCj4+IDxpY2UtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygbm9obG1l aWVyQG1vemlsbGEuY29tPiB3cm90ZToNCj4+IA0KPj4+IEFmdGVyIHJlYWRpbmcgdXAgb24gaG93 IHRoZSBjdXJyZW50IFRyaWNrbGUgSUNFIGRyYWZ0IHByb3Bvc2VzIHRvIA0KPj4+IGhhbmRsZSBw ZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGVzIGl0IGFwcGVhcnMgdG8gbWUgdGhhdCBteSBzY2VuYXJp byANCj4+PiBiZWxvdyBpcyByZWxldmFudCBmb3IgSUNFIDUyNDViaXMgaWYgdGhlcmUgaXMgbm8g U1RVTiBzZXJ2ZXIuDQo+Pj4gQW5kIGlmIHRoZXJlIGlzIGEgU1RVTiBzZXJ2ZXIgdGhlbiBpdCBz aG91bGQgb25seSBoYXBwZW4gaWYgQiBoYXMgDQo+Pj4gdHJpY2tsZWQgaGlzIHB1YmxpYyBob3N0 IGNhbmRpZGF0ZSB0byBBIGFscmVhZHkuIEFuZCBBIHJlY2VpdmVzIGl0cyANCj4+PiBiaW5kaW5n IHJlc3BvbnNlIGZyb20gQiBiZWZvcmUgaXQgZGlzY292ZXJzIGhpcyBvd24gc2VydmVyIHJlZmxl eGl2ZSANCj4+PiBieSByZWNlaXZpbmcgYSBiaW5kaW5nIHJlc3BvbnNlIGZyb20gdGhlIFNUVU4g c2VydmVyLg0KPj4+IA0KPj4+IEV2ZW4gaWYgd2UgZG9uwrl0IGJvdGhlciBkbyB0cnkgdG8gb3B0 aW1pemUgdGhlIHVzZWxlc3MvcmVkdW5kYW50IA0KPj4+IHRyaWdnZXIgY2hlY2sgYXdheSBJIHRo aW5rIHdlIHNob3VsZDoNCj4+PiAtIGluY2x1ZGUgcGVlciByZWZsZXhpdmUgY2FuZGlkYXRlcyBp bnRvIHRoZSBwYXJhZ3JhcGggb2YgNTI0NSB3aGljaCANCj4+PiB0YWxrcyBhYm91dCB0cmlnZ2Vy IGNoZWNrcw0KPj4+IC0gZXh0ZW5kIHRoZSBwYXJhZ3JhcGggaW4gdGhlIHRyaWNrbGUgZHJhZnQg dG8gbm90IG9ubHkgbWVudGlvbiANCj4+PiBkaXNjb3ZlcmluZyBwZWVyIHJlZmxleGl2ZSBjYW5k aWRhdGVzIHZpYSBTVFVOIGJpbmRpbmcgcmVxdWVzdCwgYnV0IA0KPj4+IGFsc28gZnJvbSBiaW5k aW5nIHJlc3BvbnNlcy4NCj4+PiANCj4+PiBJIHdvdWxkIGFwcHJlY2lhdGUgc29tZSBmZWVkYmFj ayBvbiB0aGlzIGJlZm9yZSB0cnlpbmcgdG8gcHJvcG9zZSANCj4+PiBpbXByb3ZlZCB3b3JkaW5n IGZvciBib3RoIHNwZWNzLg0KPj4+IA0KPj4+IEJlc3QNCj4+PiBOaWxzIE9obG1laWVyDQo+Pj4g DQo+Pj4+IE9uIFNlcCAyLCAyMDE2LCBhdCAxMzozNCwgTmlscyBPaGxtZWllciA8bm9obG1laWVy QG1vemlsbGEuY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IEhlbGxvLA0KPj4+PiANCj4+Pj4gSSBo YXZlIGlkZW50aWZpZWQgc29tZXRoaW5nIHdoaWNoIEkgd291bGQgYmUgaW50ZXJlc3RlZCB0byBo ZWFyIHRoZSANCj4+Pj4gb3BpbmlvbnMgb2YgdGhlIElDRSBleHBlcnRzIGFib3V0Lg0KPj4+PiAN Cj4+Pj4gSW4gUkZDIDUyNDUgKHNlY3Rpb24gNy4yLjEuNCkgYW5kIGFsc28gaW4gYmlzLTA0IChz ZWN0aW9uIA0KPj4+PiA2LjEuMy4xLjQpIGNsYWltIHRoZSBmb2xsb3dpbmcgcmVnYXJkaW5nIHJl Y2VpdmluZyB0cmlnZ2VyZWQgY2hlY2tzOg0KPj4+PiBUaGUgbG9jYWwgY2FuZGlkYXRlIHdpbGwg ZWl0aGVyIGJlIGEgaG9zdCBjYW5kaWRhdGUgKC4uLikgb3IgYSANCj4+Pj4gcmVsYXllZCBjYW5k aWRhdGUgKMWgKS4gVGhlIGxvY2FsIGNhbmRpZGF0ZSBjYW4gbmV2ZXIgYmUgYSBzZXJ2ZXIgDQo+ Pj4+IHJlZmxleGl2ZSBjYW5kaWRhdGUuDQo+Pj4+IA0KPj4+PiBXaGljaCBJIHRoaW5rIGlzIG1p c3NpbmcgdGhlIGNhc2Ugd2hlcmUgdGhlIGxvY2FsIGNhbmRpZGF0ZSBjYW4gDQo+Pj4+IGFsc28g YSBiZSBhIHBlZXIgcmVmbGV4aXZlLiBBbmQgdGhpcyBpcyBhY3R1YWxseSBjYXVzaW5nIA0KPj4+ PiB1bm5lY2Vzc2FyeSBleHRyYSBjaGVja3MgdG8gYmUgbWFkZS4NCj4+Pj4gDQo+Pj4+IENvbnNp ZGVyIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW86DQo+Pj4+IA0KPj4+PiAtIEEgc2l0cyBiZWhpbmQg c3ltbWV0cmljIE5BVA0KPj4+PiAtIEIgaXMgb24gYSBwdWJsaWNseSByb3V0YWJsZSBhZGRyZXNz IHdpdGggbm8gTkFUIG9yIGZpcmV3YWxsDQo+Pj4+IC0gTm8gU1RVTiBzZXJ2ZXJzIChqdXN0IG1h a2VzIHRoZSBzY2VuYXJpbyBsZXNzIGNvbXBsZXgpDQo+Pj4+IC0gSG9zdCBjYW5kaWRhdGVzIGdl dCBleGNoYW5nZWQgIGFuZCBjYW5kaWRhdGUgcGFpcnMgQTpCIGFuZCBCOkEgDQo+Pj4+IGdldCBj cmVhdGVkIG9uIGJvdGggc2lkZXMNCj4+Pj4gLSBBIHNlbmRzIGJpbmRpbmcgcmVxdWVzdCB0byBC DQo+Pj4+IC0gQiByZWNlaXZlcyBiaW5kaW5nIHJlcXVlc3Qgd2l0aCB0cmFuc3BvcnQgYWRkcmVz cyBBwrkNCj4+Pj4gLSBCIGNyZWF0ZXMgYSBwZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGUgZm9yIEHC uSBhbmQgdGhlIGEgbmV3IHBhaXIgDQo+Pj4+IEI6QcK5IGFuZCBwdXRzIHRoYXQgbmV3IHBhaXIg aW50byBpdHMgdHJpZ2dlciBjaGVjayBxdWV1ZQ0KPj4+PiAtIEIgc2VuZHMgYmluZGluZyByZXNw b25zZSB0byBBwrkNCj4+Pj4gLSBBIHJlY2VpdmVzIGJpbmRpbmcgcmVzcG9uc2UsIGxlYXJucyBh Ym91dCBBwrkgYW5kIGNyZWF0ZXMgQcK5OkIgYW5kIA0KPj4+PiBtYXJrcyBpdCBhcyBzdWNjZXNz ZnVsDQo+Pj4+IC0gTm93IEIgc2VuZHMgYSBiaW5kaW5nIHJlcXVlc3QgZm9yIGl0IHRyaWdnZXIg Y2hlY2sgcXVldWUgZW50cnkgdG8gDQo+Pj4+IEHCuQ0KPj4+PiAtIFdoZW4gQSByZWNlaXZlcyB0 aGlzIGJpbmRpbmcgcmVxdWVzdCBpcyBoYXMgbm8gd2F5IHRvIG1hdGNoIHRoaXMgDQo+Pj4+IHRv IHRoZSBzdWNjZXNzZnVsIHBhaXIgQcK5OkINCj4+Pj4gLSBCZWNhdXNlIG9mIHRoZSB3b3JkaW5n IGluIHRoZSBhYm92ZSBtZW50aW9uZWQgc2VjdGlvbnMgaXQgd2lsbCANCj4+Pj4gbWF0Y2ggdGhl IHJlcXVlc3QgdG8gdGhlIHBhaXIgQTpCDQo+Pj4+IC0gV2hpY2ggdGhlbiBpbiB0dXJuIGNhdXNl cyBhbm90aGVyIHRyaWdnZXJlZCBjaGVjayB0byBiZSBjcmVhdGVkIA0KPj4+PiBiZWNhdXNlIEE6 QiBpcyBub3QgaW4gdGhlIHN1Y2Nlc3Mgc3RhdGUNCj4+Pj4gDQo+Pj4+IFRoaXMgYWRkaXRpb25h bCB0cmlnZ2VyZWQgY2hlY2sgZnJvbSBBIGlzIGp1c3Qgd2FzdGUgb2YgdGltZSBhbmQgDQo+Pj4+ IHJlc291cmNlcy4gSXQgZG9lcyBub3QgaHVydC4gQnV0IEnCuW0gd29uZGVyaW5nIGhvdyB0aGlz IGNvdWxkIGJlIGF2b2lkZWQuDQo+Pj4+IA0KPj4+PiBJZiBwZW9wbGUgYWdyZWUgSSB0aGluayBz ZWN0aW9uIDYuMS4zLjEuNCBzaG91bGQgYXQgbGVhc3QgbWVudGlvbiANCj4+Pj4gdGhlIHNjZW5h cmlvIHRoYXQgaW5jb21pbmcgYmluZGluZyByZXF1ZXN0cyBjYW4gYWxzbyBtYXRjaCBhIHBlZXIg DQo+Pj4+IHJlZmxleGl2ZSBjYW5kaWRhdGUuDQo+Pj4+IA0KPj4+PiBBcyB0aGUgaW5jb21pbmcg YmluZGluZyByZXF1ZXN0IGRvZXMgbm90IGNvbnRhaW4gdGhlIGRlc3RpbmF0aW9uIA0KPj4+PiBh ZGRyZXNzIGl0IGdvdCBzZW5kIHRvIHRoZXJlIGlzIG9idmlvdXNseSBubyB3YXkgZm9yIEEgdG8g Y2xlYXJseSANCj4+Pj4gZGlzdGluZ3Vpc2ggaWYgdGhlIHJlcXVlc3QgZ290IHNlbmQgdG8gQSBv ciBBwrkuDQo+Pj4+IA0KPj4+PiBGb3IgYXZvaWRpbmcgdGhlIGFkZGl0aW9uYWwgdHJpZ2dlcmVk IGNoZWNrIG9uIEHCuXMgc2lkZSB0aGUgb25seSANCj4+Pj4gc29sdXRpb24gSSBzZWUgcmlnaHQg bm93IGlzIHRvIGdvIHRocm91Z2ggdGhlIHBhaXJzIHdoaWNoIGhhdmUgQSBhcyANCj4+Pj4gdGhl aXIgZm91bmRhdGlvbiBhbmQgaWYgdGhhdCBsaXN0IGNvbnRhaW5zIGEgcGFpciB3aGljaCBpcyBt YXJrZWQgDQo+Pj4+IGFzIHN1Y2Nlc3NmdWwgYWxyZWFkeSBhc3N1bWUgbm8gdHJpZ2dlcmVkIGNo ZWNrIGlzIG5lZWRlZC4gU28gZmFyIEkgDQo+Pj4+IGhhdmUgbm90IGJlZW4gYWJsZSB0byBpZGVu dGlmeSBhIHNjZW5hcmlvIHdoZXJlIGl0IGh1cnRzIHRvIHNraXAgDQo+Pj4+IHRoaXMgZXh0cmEg cm91bmQgb2YgdHJpZ2dlcmVkIGNoZWNrcyBvbiBBwrlzIHNpZGUuDQo+Pj4+IA0KPj4+PiBCZXN0 DQo+Pj4+IE5pbHMgT2hsbWVpZXINCj4+Pj4gDQo+Pj4gDQo+PiANCj4gDQoNCg== From nobody Tue Nov 15 17:13:40 2016 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 CB30C129532 for ; Tue, 15 Nov 2016 17:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 bgDBwxF9Dx2T for ; Tue, 15 Nov 2016 17:13:37 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::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 0B8A81294B5 for ; Tue, 15 Nov 2016 17:13:36 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id f188so72483018pgc.3 for ; Tue, 15 Nov 2016 17:13: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=9GzWJKIqkOE9WYNr2j3mbdLJhuaHkf60ePL4KZs3NVo=; b=GIdU4+M+Gvy0ji/fzm+eu44QAIUCMtYmQYAEM/KpF9xnlE5L05m2tj6b4kdanm6F+M mglgubLp6Otzlub4yAPtrE9UYHJaQsT30KzzZF9jXt1I0UXTSB2x/vym73RslWcwYhTr iv01oU4wp35Vrc8xyPZ0L7LJPr0t88wWqXY/E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9GzWJKIqkOE9WYNr2j3mbdLJhuaHkf60ePL4KZs3NVo=; b=XQiVkafRHWXDnLrtDVGg3rYckXkoQSD+nKKhftcqJppe57/+FOK12NhjkoHEs8ilB5 73fEV7PDxgTf/TXxbeQo+LE+tWaOcxK96paLMyc4UlE6LwJrFlCXyX/giFulwXCmaGc3 WkOWHXtWSApglciTolc1VE0Z+GSsKpZJPKetBGdoCtZ+KYE0/+iKBn3Zw3UNJQDQLDGs uQ5EKK7Acq9dmc8H/9QbhE26vfkLLqrRWehJUa4pNdCvdHf5uKtEXb3y7jc+JWQLtm7h NwdMOCzSkBVLAbvBB2XD33WATh+yTiOztjzr5gVnRt5JhqsnImj/8MlWm8bGvmBO/xTC CJJg== X-Gm-Message-State: ABUngvcWOAB49Xr5pI01zNdkvbC7tLapJuNxp4qtiRYSCYUZzxPVJ77K7Piq6wNM8e+YwjuV X-Received: by 10.99.110.203 with SMTP id j194mr2224095pgc.132.1479258816551; Tue, 15 Nov 2016 17:13:36 -0800 (PST) Received: from ?IPv6:2620:101:80fc:224:34d8:61a7:5f1c:1537? ([2620:101:80fc:224:34d8:61a7:5f1c:1537]) by smtp.gmail.com with ESMTPSA id w24sm44619788pfa.9.2016.11.15.17.13.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 17:13:35 -0800 (PST) From: Nils Ohlmeier Message-Id: <19AF4F58-A9C2-46FF-BC0F-1D3B852416C4@mozilla.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D4FAF92C-AFFE-46CA-A715-3267771C6EE0" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Tue, 15 Nov 2016 17:13:32 -0800 In-Reply-To: To: Christer Holmberg References: X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: From where to send triggered checks? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:13:40 -0000 --Apple-Mail=_D4FAF92C-AFFE-46CA-A715-3267771C6EE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On Nov 7, 2016, at 03:50, Christer Holmberg = wrote: > Section 5.1.4 of 5245bis says: > "When the timer fires and there is no triggered check to be sent, = the > agent MUST choose an ordinary check as follows: >=20 > o Find the highest-priority pair in that check list that is in the > Waiting state. >=20 > o If there is such a pair: >=20 > * Send a STUN check from the local candidate of that pair to = the > remote candidate of that pair. The procedures for forming = the > STUN request for this purpose are described in Section = 6.1.2.=E2=80=9D >=20 > Doesn=E2=80=99t the =E2=80=9CSend a STUN check=E2=80=A6=E2=80=9D text = also apply to triggered checks? My interpretation is yes. And the very first paragraph in section 5.1.4 = in my opinion describes exactly that: - take the first entry from the triggered check queue (which is a queue = and not a sorted list) - if triggered check queue is empty proceed to the check list Might be worth considering rolling that first paragraph up into the into = the action list in paragraph three of the same section. Best Nils --Apple-Mail=_D4FAF92C-AFFE-46CA-A715-3267771C6EE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On Nov 7, 2016, at 03:50, = Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Section 5.1.4 =
of 5245bis says:
   "When the =
timer fires and there is no triggered check to be sent, the
   agent MUST choose an ordinary check as follows:

   o  Find the highest-priority pair in that check list that is in the
      Waiting state.

   o  If there is such a pair:

      *  Send a STUN check from the local candidate of that pair to the
         remote candidate of that pair.  The procedures for forming the
         STUN request for this purpose are described in Section =
6.1.2.=E2=80=9D

Doesn=E2=80=99t =
the =E2=80=9CSend a STUN check=E2=80=A6=E2=80=9D text also apply to =
triggered checks?
My interpretation is yes. And the = very first paragraph in section 5.1.4 in my opinion describes exactly = that:
 - take the first entry from the = triggered check queue (which is a queue and not a sorted list)
 - if triggered check queue is empty proceed to the = check list

Might= be worth considering rolling that first paragraph up into the into the = action list in paragraph three of the same section.

Best
  Nils

= --Apple-Mail=_D4FAF92C-AFFE-46CA-A715-3267771C6EE0-- From nobody Tue Nov 15 17:16:27 2016 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 96C5A129538 for ; Tue, 15 Nov 2016 17:16:26 -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 emDxiXIuCOXq for ; Tue, 15 Nov 2016 17:16:23 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 AB7941293F9 for ; Tue, 15 Nov 2016 17:16:23 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id i88so39039911pfk.2 for ; Tue, 15 Nov 2016 17:16:23 -0800 (PST) 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=WBDqFbpn17Xt+bcLT6SAXpyC8cAzFnjcorcpaQtoGvo=; b=G3IeHLyV4FV7SIK53TB1UK/8sXwd3Ye44xrZi6Tc4rezXOi/TQZGTnDdq7JSI3jPKx K61+QWsnYfGBVeQgurNbbwZj3OE4Hft8nHxdF8e1hIvpOi0BS7RzKFqZS1tlGr+Vls7h GAAkrV/qt5mp/b/cX8itKHJTpHDCcrL5Ybylk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WBDqFbpn17Xt+bcLT6SAXpyC8cAzFnjcorcpaQtoGvo=; b=ApqTvX00z0h8qOD5qrzGWmBEhB0nmtCnrMpSU+uWbhrDEq47tHXfQMJR5ccFXy2TcD Igcao629SY8NLH7OGjMbh4bT6HxKu1+SulXJsIl3CKzfhWsMlT3XSRGxxRdwav/hDVlJ U2ndbMNXnc/t342MR4xExX3ufYBoL29/deuxjvY+vH6nS/I6cLi3OaF6QbigPhtD99L5 umFsgCq69tyYCLSRSH8TwK8ELfDA2AAIBHi4q0BZMtbkKyygEVvKrm6SwefhuIgAqmHJ NQXNn3q7UghsWA9pTWhFtQPqp2awo+GUTku5b3AdR1aGUA+VkDz+zXzRCMcHcVkUZGGw V1OA== X-Gm-Message-State: ABUngvf4oM6tNrMaTpbhp7A6Phe6MyZWvbIZtJVbjwvakFqbEYreDRgR4OkfQrSwuQ3CwhnO X-Received: by 10.99.39.132 with SMTP id n126mr2270285pgn.85.1479258983032; Tue, 15 Nov 2016 17:16:23 -0800 (PST) Received: from ?IPv6:2620:101:80fc:224:34d8:61a7:5f1c:1537? ([2620:101:80fc:224:34d8:61a7:5f1c:1537]) by smtp.gmail.com with ESMTPSA id o68sm8070259pfb.42.2016.11.15.17.16.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 17:16:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Nils Ohlmeier In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE388C3@ESESSMB209.ericsson.se> Date: Tue, 15 Nov 2016 17:16:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4B7AE197-0510-4453-BF5E-757045DF2C9B@mozilla.com> References: <37F6A130-E058-4683-B566-AD250032AB3F@mozilla.com> <78810E33-18A5-4C8D-89F0-A4B943C4520F@mozilla.com> <85414E3B-744A-48A2-BA6C-DC96E677484D@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4BE224F2@ESESSMB209.ericsson.se> <66DAD2F7-0D54-4DAB-A343-DB2AFD2C27DE@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4BE388C3@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Triggered checks are missing peer reflexive X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:16:26 -0000 > On Nov 15, 2016, at 17:09, Christer Holmberg = wrote: >>=20 >> Yes I think it would be help to broaden the scope of pruning like = that. So I would vote for Alt #2 from your slides in Seoul. >>=20 >> Although I guess the real reason why pruning does not mention peer = reflexive is that the valid pair which resulted from the peer reflexive = discovery never enters the check > list, and pruning only applies to the = check list, but not the valid list. I guess this makes the whole topic = void?! >=20 > It is true that the INITIAL check list does not contain peer reflexive = candidates. But, the spec says that, once peer reflexive candidates are = detected, the check list MAY be updated (and sent to the peer) with = those candidates. When such update occurs, I assume the check list will = be pruned again - eventhough that is currently not explicitly said in = the spec afaik (it would probably be good to add text about that). Now I got it. Yes for the special case of updating and sending your new list to the = peer you should prune that before handing it out. Probably would be good = to mention that explicitly in that paragraph. Best Nils >=20 >=20 >=20 >>> On Oct 4, 2016, at 02:58, Christer Holmberg = wrote: >>>=20 >>> Hi Nils, >>>=20 >>> Sorry for the late reply. >>>=20 >>> If I understand the issue correctly, this could only happen with = trickle. >>> Because, in normal cases pruning would take care of it. >>>=20 >>> Or? >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> On 20/09/16 06:46, "Ice on behalf of Nils Ohlmeier"=20 >>> wrote: >>>=20 >>>> After reading up on how the current Trickle ICE draft proposes to=20= >>>> handle peer reflexive candidates it appears to me that my scenario=20= >>>> below is relevant for ICE 5245bis if there is no STUN server. >>>> And if there is a STUN server then it should only happen if B has=20= >>>> trickled his public host candidate to A already. And A receives its=20= >>>> binding response from B before it discovers his own server = reflexive=20 >>>> by receiving a binding response from the STUN server. >>>>=20 >>>> Even if we don=C2=B9t bother do try to optimize the = useless/redundant=20 >>>> trigger check away I think we should: >>>> - include peer reflexive candidates into the paragraph of 5245 = which=20 >>>> talks about trigger checks >>>> - extend the paragraph in the trickle draft to not only mention=20 >>>> discovering peer reflexive candidates via STUN binding request, but=20= >>>> also from binding responses. >>>>=20 >>>> I would appreciate some feedback on this before trying to propose=20= >>>> improved wording for both specs. >>>>=20 >>>> Best >>>> Nils Ohlmeier >>>>=20 >>>>> On Sep 2, 2016, at 13:34, Nils Ohlmeier = wrote: >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> I have identified something which I would be interested to hear = the=20 >>>>> opinions of the ICE experts about. >>>>>=20 >>>>> In RFC 5245 (section 7.2.1.4) and also in bis-04 (section=20 >>>>> 6.1.3.1.4) claim the following regarding receiving triggered = checks: >>>>> The local candidate will either be a host candidate (...) or a=20 >>>>> relayed candidate (=C5=A0). The local candidate can never be a = server=20 >>>>> reflexive candidate. >>>>>=20 >>>>> Which I think is missing the case where the local candidate can=20 >>>>> also a be a peer reflexive. And this is actually causing=20 >>>>> unnecessary extra checks to be made. >>>>>=20 >>>>> Consider the following scenario: >>>>>=20 >>>>> - A sits behind symmetric NAT >>>>> - B is on a publicly routable address with no NAT or firewall >>>>> - No STUN servers (just makes the scenario less complex) >>>>> - Host candidates get exchanged and candidate pairs A:B and B:A=20= >>>>> get created on both sides >>>>> - A sends binding request to B >>>>> - B receives binding request with transport address A=C2=B9 >>>>> - B creates a peer reflexive candidate for A=C2=B9 and the a new = pair=20 >>>>> B:A=C2=B9 and puts that new pair into its trigger check queue >>>>> - B sends binding response to A=C2=B9 >>>>> - A receives binding response, learns about A=C2=B9 and creates = A=C2=B9:B and=20 >>>>> marks it as successful >>>>> - Now B sends a binding request for it trigger check queue entry = to=20 >>>>> A=C2=B9 >>>>> - When A receives this binding request is has no way to match this=20= >>>>> to the successful pair A=C2=B9:B >>>>> - Because of the wording in the above mentioned sections it will=20= >>>>> match the request to the pair A:B >>>>> - Which then in turn causes another triggered check to be created=20= >>>>> because A:B is not in the success state >>>>>=20 >>>>> This additional triggered check from A is just waste of time and=20= >>>>> resources. It does not hurt. But I=C2=B9m wondering how this could = be avoided. >>>>>=20 >>>>> If people agree I think section 6.1.3.1.4 should at least mention=20= >>>>> the scenario that incoming binding requests can also match a peer=20= >>>>> reflexive candidate. >>>>>=20 >>>>> As the incoming binding request does not contain the destination=20= >>>>> address it got send to there is obviously no way for A to clearly=20= >>>>> distinguish if the request got send to A or A=C2=B9. >>>>>=20 >>>>> For avoiding the additional triggered check on A=C2=B9s side the = only=20 >>>>> solution I see right now is to go through the pairs which have A = as=20 >>>>> their foundation and if that list contains a pair which is marked=20= >>>>> as successful already assume no triggered check is needed. So far = I=20 >>>>> have not been able to identify a scenario where it hurts to skip=20= >>>>> this extra round of triggered checks on A=C2=B9s side. >>>>>=20 >>>>> Best >>>>> Nils Ohlmeier >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Tue Nov 15 22:24:32 2016 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 69BEA1294C7 for ; Tue, 15 Nov 2016 22:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbGq_vtckYn2 for ; Tue, 15 Nov 2016 22:24: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 81E1B1295C0 for ; Tue, 15 Nov 2016 22:24:22 -0800 (PST) X-AuditID: c1b4fb2d-5b107980000009f7-66-582bfb94b5a0 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id FE.42.02551.49BFB285; Wed, 16 Nov 2016 07:24:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0319.002; Wed, 16 Nov 2016 07:20:15 +0100 From: Christer Holmberg To: Nils Ohlmeier Thread-Topic: [Ice] 5245bis: From where to send triggered checks? Thread-Index: AQHSOO0jZY7Qy8aFW0utoaf7Wn5sK6Dayq0AgABlteA= Date: Wed, 16 Nov 2016 06:20:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE38FB7@ESESSMB209.ericsson.se> References: <19AF4F58-A9C2-46FF-BC0F-1D3B852416C4@mozilla.com> In-Reply-To: <19AF4F58-A9C2-46FF-BC0F-1D3B852416C4@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE38FB7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbE9SnfKb+0Igy1TrS2+Xai1uD5vMqMD k8eSJT+ZPPoOdLEGMEVx2aSk5mSWpRbp2yVwZXw7u4OxoMu7oqd1J1MDY4NnFyMnh4SAiUTz 0j0sXYxcHEIC6xglluy8AeUsYZT49v0sYxcjBwebgIVE9z9tEFNEQFPixEY+EJNZQFHi5V41 kDHCAg4SCyYvYQaxRQQcJVa3r2ODsK0kHi1/wQ5iswioStxadJkFxOYV8JVYObEHLC4kUCAx 7f5NJpCRnAL2EpteJIGEGQXEJL6fWsMEYjMLiEvcejKfCeJiAYkle84zQ9iiEi8f/2OFsJUk Gpc8YYWoz5douf8OapWgxMmZT1gmMIrMQjJqFpKyWUjKZoE9pimxfpc+RImixJTuh+wQtoZE 65y57MjiCxjZVzGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIERtPBLb91dzCufu14iFGAg1GJ h9cgWjtCiDWxrLgy9xCjBAezkgjv+Q9AId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxmK++HCwmk J5akZqemFqQWwWSZODilGhizmBU1J200m6LkKl97sPHa5Z+FtwunnXy7/M+ZXRwzp0xU37GA aZ3BxhS1y5fdncov/J+ut2JX3am1xV+munwOzqyb8crptvcvW3Ump8hfC2rXsf1kVynZY35h x9s0p/wi8+o9m3/E7OLbyGO11WJu/pXGWqcyLjM304vveJe5sN3WMt8l8blQiaU4I9FQi7mo OBEAZYIWzKICAAA= Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: From where to send triggered checks? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 06:24:24 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE38FB7ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KU2VjdGlvbiA1LjEuNCBvZiA1MjQ1YmlzIHNheXM6DQoNCiAgICJXaGVuIHRoZSB0 aW1lciBmaXJlcyBhbmQgdGhlcmUgaXMgbm8gdHJpZ2dlcmVkIGNoZWNrIHRvIGJlIHNlbnQsIHRo ZQ0KDQogICBhZ2VudCBNVVNUIGNob29zZSBhbiBvcmRpbmFyeSBjaGVjayBhcyBmb2xsb3dzOg0K DQoNCg0KICAgbyAgRmluZCB0aGUgaGlnaGVzdC1wcmlvcml0eSBwYWlyIGluIHRoYXQgY2hlY2sg bGlzdCB0aGF0IGlzIGluIHRoZQ0KDQogICAgICBXYWl0aW5nIHN0YXRlLg0KDQoNCg0KICAgbyAg SWYgdGhlcmUgaXMgc3VjaCBhIHBhaXI6DQoNCg0KDQogICAgICAqICBTZW5kIGEgU1RVTiBjaGVj ayBmcm9tIHRoZSBsb2NhbCBjYW5kaWRhdGUgb2YgdGhhdCBwYWlyIHRvIHRoZQ0KDQogICAgICAg ICByZW1vdGUgY2FuZGlkYXRlIG9mIHRoYXQgcGFpci4gIFRoZSBwcm9jZWR1cmVzIGZvciBmb3Jt aW5nIHRoZQ0KDQogICAgICAgICBTVFVOIHJlcXVlc3QgZm9yIHRoaXMgcHVycG9zZSBhcmUgZGVz Y3JpYmVkIGluIFNlY3Rpb24gNi4xLjIu4oCdDQoNCg0KDQpEb2VzbuKAmXQgdGhlIOKAnFNlbmQg YSBTVFVOIGNoZWNr4oCm4oCdIHRleHQgYWxzbyBhcHBseSB0byB0cmlnZ2VyZWQgY2hlY2tzPw0K Pk15IGludGVycHJldGF0aW9uIGlzIHllcy4gQW5kIHRoZSB2ZXJ5IGZpcnN0IHBhcmFncmFwaCBp biBzZWN0aW9uIDUuMS40IGluIG15IG9waW5pb24gZGVzY3JpYmVzIGV4YWN0bHkgdGhhdDoNCj4g LSB0YWtlIHRoZSBmaXJzdCBlbnRyeSBmcm9tIHRoZSB0cmlnZ2VyZWQgY2hlY2sgcXVldWUgKHdo aWNoIGlzIGEgcXVldWUgYW5kIG5vdCBhIHNvcnRlZCBsaXN0KQ0KPiAtIGlmIHRyaWdnZXJlZCBj aGVjayBxdWV1ZSBpcyBlbXB0eSBwcm9jZWVkIHRvIHRoZSBjaGVjayBsaXN0DQo+DQo+IE1pZ2h0 IGJlIHdvcnRoIGNvbnNpZGVyaW5nIHJvbGxpbmcgdGhhdCBmaXJzdCBwYXJhZ3JhcGggdXAgaW50 byB0aGUgaW50byB0aGUgYWN0aW9uIGxpc3QgaW4gcGFyYWdyYXBoIHRocmVlIG9mIHRoZSBzYW1l IHNlY3Rpb24uDQoNCkNvcnJlY3QuIFRoZSBTVFVOIGNoZWNrIGlzIHNlbnQgaW4gdGhlIHNhbWUg d2F5IG5vIG1hdHRlciB3aGV0aGVyIHRoZSBjaGVjayBpcyB0cmlnZ2VyZWQgb3Igb3JkaW5hcnks IHNvIGl0IHNob3VsZCBiZSBlbm91Z2ggdG8gZGVzY3JpYmUgaG93IGl04oCZcyBzZW50IGluIG9u ZSBwbGFjZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== --_000_7594FB04B1934943A5C02806D1A2204B4BE38FB7ESESSMB209erics_ 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 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwcmU+U2VjdGlvbiA1LjEuNCBv ZiA1MjQ1YmlzIHNheXM6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFu dC1saWdhdHVyZXM6IG5vcm1hbDtvcnBoYW5zOiAyO3dpZG93czogMjt3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOyZuYnNwOyAmcXVvdDtXaGVuIHRoZSB0 aW1lciBmaXJlcyBhbmQgdGhlcmUgaXMgbm8gdHJpZ2dlcmVkIGNoZWNrIHRvIGJlIHNlbnQsIHRo ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhZ2VudCBNVVNUIGNob29zZSBh biBvcmRpbmFyeSBjaGVjayBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBvJm5ic3A7IEZpbmQgdGhlIGhp Z2hlc3QtcHJpb3JpdHkgcGFpciBpbiB0aGF0IGNoZWNrIGxpc3QgdGhhdCBpcyBpbiB0aGU8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2FpdGlu ZyBzdGF0ZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgbyZuYnNwOyBJZiB0aGVyZSBpcyBzdWNoIGEgcGFpcjo8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyBTZW5kIGEgU1RVTiBjaGVjayBmcm9tIHRoZSBs b2NhbCBjYW5kaWRhdGUgb2YgdGhhdCBwYWlyIHRvIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZW1vdGUg Y2FuZGlkYXRlIG9mIHRoYXQgcGFpci4mbmJzcDsgVGhlIHByb2NlZHVyZXMgZm9yIGZvcm1pbmcg dGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNUVU4gcmVxdWVzdCBmb3IgdGhpcyBwdXJwb3NlIGFyZSBkZXNj cmliZWQgaW4gU2VjdGlvbiA2LjEuMi7igJ08bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO29ycGhhbnM6IDI7d2lkb3dzOiAyO3dvcmQt d3JhcDogYnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtvcnBoYW5z OiAyO3dpZG93czogMjt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAi PkRvZXNu4oCZdCB0aGUg4oCcU2VuZCBhIFNUVU4gY2hlY2vigKbigJ0gdGV4dCBhbHNvIGFwcGx5 IHRvIHRyaWdnZXJlZCBjaGVja3M/PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O015 IGludGVycHJldGF0aW9uIGlzIHllcy4gQW5kIHRoZSB2ZXJ5IGZpcnN0IHBhcmFncmFwaCBpbiBz ZWN0aW9uIDUuMS40IGluIG15IG9waW5pb24gZGVzY3JpYmVzIGV4YWN0bHkgdGhhdDo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDst IHRha2UgdGhlIGZpcnN0IGVudHJ5IGZyb20gdGhlIHRyaWdnZXJlZCBjaGVjayBxdWV1ZSAod2hp Y2ggaXMgYSBxdWV1ZSBhbmQgbm90IGEgc29ydGVkIGxpc3QpPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7LSBpZiB0cmlnZ2VyZWQg Y2hlY2sgcXVldWUgaXMgZW1wdHkgcHJvY2VlZCB0byB0aGUgY2hlY2sgbGlzdDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBNaWdo dCBiZSB3b3J0aCBjb25zaWRlcmluZyByb2xsaW5nIHRoYXQgZmlyc3QgcGFyYWdyYXBoIHVwIGlu dG8gdGhlIGludG8gdGhlIGFjdGlvbiBsaXN0IGluIHBhcmFncmFwaCB0aHJlZSBvZiB0aGUgc2Ft ZSBzZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkNvcnJlY3QuIFRoZSBTVFVOIGNoZWNrIGlzIHNlbnQgaW4gdGhlIHNhbWUgd2F5 IG5vIG1hdHRlciB3aGV0aGVyIHRoZSBjaGVjayBpcyB0cmlnZ2VyZWQgb3Igb3JkaW5hcnksIHNv IGl0IHNob3VsZCBiZSBlbm91Z2ggdG8gZGVzY3JpYmUgaG93IGl04oCZcyBzZW50IGluIG9uZSBw bGFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hyaXN0ZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4BE38FB7ESESSMB209erics_-- From nobody Tue Nov 15 23:29:46 2016 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 E2E46129542 for ; Tue, 15 Nov 2016 23:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWTa5_vO_D1f for ; Tue, 15 Nov 2016 23:29:28 -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 05C81129565 for ; Tue, 15 Nov 2016 23:29:27 -0800 (PST) X-AuditID: c1b4fb30-dc07098000007ca6-fb-582c0ad5ef99 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by (Symantec Mail Security) with SMTP id 33.64.31910.5DA0C285; Wed, 16 Nov 2016 08:29:26 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0319.002; Wed, 16 Nov 2016 08:26:59 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: base of relayed candidate Thread-Index: AdI/2s/2yP/Ccs+QTRCSrGrj/0dWLg== Date: Wed, 16 Nov 2016 07:26:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE391B2@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE391B2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM2K7nO41Lp0Ig9sPeCy+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGkRvrmQrmKlfs/T6FvYHxnVwXIyeHhICJxInFrSxdjFwcQgLr GCW6enayQzhLGCUWHp3B1sXIwcEmYCHR/U8bpEFEQFFiZsszZhBbWEBb4snsc+wQcQOJ75Ma oWw9iUlPpzKC2CwCqhKTTi1hAbF5BXwlrsycBhZnFBCT+H5qDROIzSwgLnHryXwmiIMEJJbs Oc8MYYtKvHz8jxXCVpJoXPKEFaI+X+LU5YVsEDMFJU7OfMIygVFwFpJRs5CUzUJSBhHXkViw +xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBAb+wS2/ DXYwvnzueIhRgINRiYfXIFo7Qog1say4MvcQowQHs5IIbxSHToQQb0piZVVqUX58UWlOavEh RmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwcnFINjDlmuq+6n/6LEOLObBY62tVxRf267OGI uT+fiLqF7svcvvrX0qK4/TveKEq1bFx7jNs3eY/kyYwTenMyg/dkXND5v7xSX4Av5NtyXb1d GaxffWZXl/ezG/BPfvu8PXhj93sxmSkX5v6YuCw98kz3jAuHhefdP9BRv3pjaavIyuemJxbN 2p3V/FeJpTgj0VCLuag4EQDQBAeeeAIAAA== Archived-At: Subject: [Ice] 5245bis: base of relayed candidate X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 07:29:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE391B2ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The definition of "base" says: "Similarly, the base of a relayed candidate is that candidate itself." Also, section 4.1.1.2 says: "The base of a relayed candidate is that candidate itself. My understanding of above is that base refers to the transport address of t= he TURN server in case of a relayed candidiate. However, section 9.1.1 says: "Media sent from a relayed candidate is sent from the base through that = TURN server, using procedures defined in [RFC5766]." However, this seems to imply that base refers to the local transport addres= s of the agent also in case of relayed candidate. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4BE391B2ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The definition of “base” says:

 

“Similarly, the base of a relayed candidate is= that candidate itself.”

 

Also, section 4.1.1.2 says:

 

“The base of a relayed candidate is that candi= date itself.

 

My understanding of above is that base refers to the= transport address of the TURN server in case of a relayed candidiate.=

 

 

However, section 9.1.1 says:

 

   “Media sent from a relayed candid= ate is sent from the base through that TURN

   server, using procedures defined in [RF= C5766].”

 

However, this seems to imply that base refers to the= local transport address of the agent also in case of relayed candidate.

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B4BE391B2ESESSMB209erics_-- From nobody Tue Nov 15 23:35:34 2016 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 CFEF1129543 for ; Tue, 15 Nov 2016 23:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 Wybq3b3pRn37 for ; Tue, 15 Nov 2016 23:35:31 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::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 6AEBD12951A for ; Tue, 15 Nov 2016 23:35:31 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id p66so76335261pga.2 for ; Tue, 15 Nov 2016 23:35: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=xSqbp/6apntagrvL8BgUJBg5I+aFvl9ZLRIQtbZNrac=; b=M72rdiX1ONtHLCv6LCgHkq/ebc2n5YOjzR0N4zfvArrWQnsDBJfXrl4oR80bYamqj9 +4wmBjWcusFgXBAlaBJOcrygkUxGU1R8wpv9ApqdTys09pp6vlpPB1hSHpCe+OGUhQxc heh5fhW7EvwMcHDUh+ItDuZ9vL8G27cmF6j48= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xSqbp/6apntagrvL8BgUJBg5I+aFvl9ZLRIQtbZNrac=; b=AlCPhzr0DdOcPZgqRxob0hA+7i/oiCs746QGuu6TKXm/QiSiAahHhcBm58KLf892iA +L34IQ35NtBgH1zh+Kyz37lOLzfxJwVY6ATTzX76wiwd6tq5S+2H93RX5FQYCRFljTB9 oBIHae/eWq8/PXE7ooZZQhNllpxKUXl6liYt83htzdBuRF4EX1EP/7hmEs/iSmBMq9f+ 2aPovyUuE+nWW6N4sC3OKIBo2T4R1r1N24Tbqwk6Tf/6/jbVX8jHTa/PEGz2T5xYKSf8 CF4oEVMw36gWQ/VgrYhS6W/k2yquqD+rxIzykEDfm/mytvnDnhWkAPuqE+U6Qjx2cmUq 6CyA== X-Gm-Message-State: ABUngvfeuBY9fqiJxjW+LqEipcSbQ7KinSMvBmZU0Y2i/+TjYhr1t7rMaqL03YnNHXTSjBkS X-Received: by 10.99.56.19 with SMTP id f19mr5304139pga.72.1479281730764; Tue, 15 Nov 2016 23:35:30 -0800 (PST) Received: from ?IPv6:2601:647:4601:ec84:4862:f77a:eb5c:23be? ([2601:647:4601:ec84:4862:f77a:eb5c:23be]) by smtp.gmail.com with ESMTPSA id y189sm34650313pfy.32.2016.11.15.23.35.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 23:35:29 -0800 (PST) From: Nils Ohlmeier Message-Id: <7EE4CC0E-A662-45D0-9D51-C6DF485EEBC0@mozilla.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C9F81C60-1FFD-46BF-83B1-433EB1E47A21" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Tue, 15 Nov 2016 23:35:28 -0800 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE38FB7@ESESSMB209.ericsson.se> To: Christer Holmberg References: <19AF4F58-A9C2-46FF-BC0F-1D3B852416C4@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4BE38FB7@ESESSMB209.ericsson.se> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: From where to send triggered checks? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 07:35:34 -0000 --Apple-Mail=_C9F81C60-1FFD-46BF-83B1-433EB1E47A21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 15, 2016, at 22:20, Christer Holmberg = wrote: > > Might be worth considering rolling that first paragraph up into the = into the action list in paragraph three of the same section. > =20 > Correct. The STUN check is sent in the same way no matter whether the = check is triggered or ordinary, so it should be enough to describe how = it=E2=80=99s sent in one place. +1 Best Nils --Apple-Mail=_C9F81C60-1FFD-46BF-83B1-433EB1E47A21 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 15, 2016, at 22:20, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> Might be worth considering rolling that first = paragraph up into the into the action list in paragraph three of the = same section.
 
Correct. The STUN check is = sent in the same way no matter whether the check is triggered or = ordinary, so it should be enough to describe how it=E2=80=99s sent in = one place.

+1

Best
  Nils


= --Apple-Mail=_C9F81C60-1FFD-46BF-83B1-433EB1E47A21-- From nobody Tue Nov 15 23:39:29 2016 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 5F1FB129434 for ; Tue, 15 Nov 2016 23:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 IbCE3S6E8uUl for ; Tue, 15 Nov 2016 23:39:26 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 01C63127077 for ; Tue, 15 Nov 2016 23:39:25 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id i88so41323673pfk.2 for ; Tue, 15 Nov 2016 23:39:25 -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=g21KT9SRhAzrPtEDuvblKh9Q/RsbxhuWSTN82Ddc0Oc=; b=cX3Y3FtQ+0kEsWDQG1UlDCjjok/c6GRqcfVWO4qLlA0URfDB9iIhvg0Cfxork+hMC9 F+5copyMbybPhAiP0EfOAYm1UG2MP3TuSolz6aazBxvXv6LrdlMhp9lx1+pNYAcdI2Cl /3Acq/Gz6XeorYg3p20S5LPv/o/FQVvxGSxRY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=g21KT9SRhAzrPtEDuvblKh9Q/RsbxhuWSTN82Ddc0Oc=; b=V6nzTrKl3zD1IQfQzpLyWJCHzA2Tv+hCwBShZBmt3F74cS9ivBVx6cQHG6H88THiuX aH64+RxZAC5ucg88qi5KIMcDIPyyMoQcBiFv81hhdkQQ4gli1KLvNjKwr3iMkkXjpLvz q9fFpVJ1TWryy/cUBerv6GypCT3Yw9J6dxoWYYkVeOYAiwGOkDiO7PUjpC7kr71LSkae Y9PZDfJgwJV7CFiMJQ0VtTIMuv0GdVhSgPcONRt5W77wPHH8c3T2RSXx4IR5UZS4bIis x1pOeDXkJVPTAs4sS/UqSPTVKa0XjqnX0euLHJT7Hr85eTg5pZqKsIvutnrxAPsgRVms LpVQ== X-Gm-Message-State: ABUngvdGYJ1HpkCKi03zoHIFqEcNMPoKoDBN5i7e+dgOGXcfKIBrQZyknOUhW3ub/g0D0Sz/ X-Received: by 10.98.65.156 with SMTP id g28mr2568422pfd.110.1479281965526; Tue, 15 Nov 2016 23:39:25 -0800 (PST) Received: from ?IPv6:2601:647:4601:ec84:4862:f77a:eb5c:23be? ([2601:647:4601:ec84:4862:f77a:eb5c:23be]) by smtp.gmail.com with ESMTPSA id p67sm6240088pfb.2.2016.11.15.23.39.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 23:39:24 -0800 (PST) From: Nils Ohlmeier Message-Id: <9077DC29-1BDB-491E-AB26-56B726C1BCF2@mozilla.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E9D9B5E4-B5F6-401F-B8C5-59081E00A6A1" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Tue, 15 Nov 2016 23:39:23 -0800 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE391B2@ESESSMB209.ericsson.se> To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B4BE391B2@ESESSMB209.ericsson.se> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: base of relayed candidate X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 07:39:28 -0000 --Apple-Mail=_E9D9B5E4-B5F6-401F-B8C5-59081E00A6A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 15, 2016, at 23:26, Christer Holmberg = wrote: > However, section 9.1.1 says: > =20 > =E2=80=9CMedia sent from a relayed candidate is sent from the base = through that TURN > server, using procedures defined in [RFC5766].=E2=80=9D > =20 > However, this seems to imply that base refers to the local transport = address of the agent also in case of relayed candidate. That would have not been my interpretation of the above sentence. But = without a doubt the above sentence could be more clear on what the base = address is going to be in this case. Best Nils --Apple-Mail=_E9D9B5E4-B5F6-401F-B8C5-59081E00A6A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 15, 2016, at 23:26, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
However, = section 9.1.1 says:
 
   =E2=80=9CMedia sent from a relayed candidate is = sent from the base through that TURN
   server, using procedures = defined in [RFC5766].=E2=80=9D
 
However, this seems to imply that base = refers to the local transport address of the agent also in case of = relayed candidate.
That would have not been my interpretation of the = above sentence. But without a doubt the above sentence could be more = clear on what the base address is going to be in this = case.

Best
  = Nils


= --Apple-Mail=_E9D9B5E4-B5F6-401F-B8C5-59081E00A6A1-- From nobody Tue Nov 15 23:56:04 2016 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 9DF771295AB for ; Tue, 15 Nov 2016 23:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 t86SBBnpV020 for ; Tue, 15 Nov 2016 23:55:59 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB72C129589 for ; Tue, 15 Nov 2016 23:55:58 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id 3so76657053pgd.0 for ; Tue, 15 Nov 2016 23:55:58 -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=wMB1FLw4FZCTMgZYv7HUeiuRXrnURNFPuxHgRCS+DKQ=; b=ZyqBRrbLexoTs5GfZOHYMB1sDq9n5uvlpU9Nwtik0Kr4dKXxLvglS3U4OGCQ9kjQVI X203dpowadRtLB5jjLcuP3tWtANZeC3YXoDYBLNRZK9RfQb0cUi6/C1oXzkD6wFBlnXT y255DTFAB/66+54f767TenjepuHVyoqfLqCOU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=wMB1FLw4FZCTMgZYv7HUeiuRXrnURNFPuxHgRCS+DKQ=; b=gkPh0qSgtVlLRGXnWXKb8Lx3Mp2h7DS2Mx+tT0UTToBnj4vlNt5I2WgAH7H0BPEI/Y XzyN0Ex62aHovtBfWujTRf4hwe+gh+lWTZvfF/+gnWKom5+9FkAZxBgqAxAorrbE2qiR +5MGAMh/Bkec/B3Xg/sdSKEfXPA85Nvg1b2DQ9inTFUHXB4Zmc2AvZxfbWPeeyWUEq5J 9FGauZ7ENyM7e1DKf2ovYOGy+EGZanl2qESI26WQzEIpy2DPx68ldOxBoB+2cQK/tf5c Kdcj04t9mobVoBnF66sD2Vj7UY9UKEWzXmHEGdigG611nUynDYEmM8/Iqz4LggApYr5V 7vWw== X-Gm-Message-State: ABUngvdOxI1eNBeWG0Pu5TqxlynoV8Kj6BidOpf7iAUA+s4Hr/HMOepam+14rmlNFd/zIxvp X-Received: by 10.99.128.198 with SMTP id j189mr5446333pgd.151.1479282958416; Tue, 15 Nov 2016 23:55:58 -0800 (PST) Received: from ?IPv6:2601:647:4601:ec84:4862:f77a:eb5c:23be? ([2601:647:4601:ec84:4862:f77a:eb5c:23be]) by smtp.gmail.com with ESMTPSA id d197sm50267005pfd.38.2016.11.15.23.55.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 23:55:57 -0800 (PST) From: Nils Ohlmeier Message-Id: <8BA13317-ACC4-4217-80BA-44498F24FD1A@mozilla.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9AFBBB32-D67D-48B3-AE45-DCAE2A766BB9" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Tue, 15 Nov 2016 23:55:54 -0800 In-Reply-To: To: Christer Holmberg References: X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: active and frozen check lists X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 07:56:03 -0000 --Apple-Mail=_9AFBBB32-D67D-48B3-AE45-DCAE2A766BB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 6, 2016, at 23:33, Christer Holmberg = wrote: > Q1: Why can=E2=80=99t Frozen simply be a check list state? In our implementation that is the case. We have a Frozen state before = Running. > Q2: What=E2=80=99s the state of a Frozen check list? In our case =E2=80=9CFrozen=E2=80=9D :-) > Q3: What=E2=80=99s the difference between an active check list and an = active check list in Running state? None? Best Nils --Apple-Mail=_9AFBBB32-D67D-48B3-AE45-DCAE2A766BB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 6, 2016, at 23:33, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Q1: Why can=E2=80=99t Frozen simply be a = check list state?

In our implementation that is the case. We have a = Frozen state before Running.

Q2: What=E2=80=99s the state of a = Frozen check list?

In our case =E2=80=9CFrozen=E2=80=9D :-)

Q3: What=E2=80=99s the difference = between an active check list and an active check list in Running = state?

None?

Best
  Nils

= --Apple-Mail=_9AFBBB32-D67D-48B3-AE45-DCAE2A766BB9-- From nobody Wed Nov 16 00:01:58 2016 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 B785D12965E for ; Wed, 16 Nov 2016 00:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MJhBxOan0OT for ; Wed, 16 Nov 2016 00:01:53 -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 A0B03127077 for ; Wed, 16 Nov 2016 00:01:52 -0800 (PST) X-AuditID: c1b4fb2d-5b107980000009f7-cd-582c126e520d Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 0D.5E.02551.E621C285; Wed, 16 Nov 2016 09:01:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0319.002; Wed, 16 Nov 2016 08:56:29 +0100 From: Christer Holmberg To: Nils Ohlmeier Thread-Topic: [Ice] 5245bis: base of relayed candidate Thread-Index: AdI/2s/2yP/Ccs+QTRCSrGrj/0dWLv//8rWA///sDbA= Date: Wed, 16 Nov 2016 07:56:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE39334@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BE391B2@ESESSMB209.ericsson.se> <9077DC29-1BDB-491E-AB26-56B726C1BCF2@mozilla.com> In-Reply-To: <9077DC29-1BDB-491E-AB26-56B726C1BCF2@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE39334ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbHdXjdPSCfC4Ha/kcW3C7UW1+dNZnRg 8liy5CeTR9+BLtYApigum5TUnMyy1CJ9uwSujJ4nN9gKnrlWLHvk0sD4xrmLkZNDQsBE4sG6 V4wgtpDAOkaJww84uxi5gOwljBL3Ow+xdzFycLAJWEh0/9MGMUUENCVObOQDMZkFFCVe7lUD 6RQWMJVoe32dDaLCTGLNh1iQsIiAlcTS7oNMIGEWAVWJifMDQcK8Ar4Ss68tZ4XY2cQo8Xtq AIjNKWAvcWLCXCYQm1FATOL7qTVgNrOAuMStJ/OZIO4VkFiy5zwzhC0q8fLxP1YIW0micckT Voj6fInJZyDivAKCEidnPmGZwCgyC8moWUjKZiEpmwX2l6bE+l36ECWKElO6H7JD2BoSrXPm siOLL2BkX8UoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGEcHt/zW3cG4+rXjIUYBDkYlHl6D aO0IIdbEsuLK3EOMEhzMSiK8URw6EUK8KYmVValF+fFFpTmpxYcYpTlYlMR5zVbeDxcSSE8s Sc1OTS1ILYLJMnFwSjUwFrydubPm2PVOs1k7deXmf2EOmnrE78tbxu4lya/9aw9NaznuwdHw 9tyrqmNnp/at5Waba+StyXEj5XjyjWaunxr29jFT25VXi0fmzdA3kD2f/q/LsHnWnom+30OW 10Q6eLl0+vps7M5+rj1nfoelSZlcE1tTCMd7+399n38vSC/oavUM77JTYinOSDTUYi4qTgQA iiwwwJ8CAAA= Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: base of relayed candidate X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 08:01:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE39334ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCiAgIOKAnE1lZGlhIHNlbnQgZnJvbSBhIHJlbGF5ZWQgY2FuZGlkYXRlIGlzIHNlbnQg ZnJvbSB0aGUgYmFzZSB0aHJvdWdoIHRoYXQgVFVSTg0KICAgc2VydmVyLCB1c2luZyBwcm9jZWR1 cmVzIGRlZmluZWQgaW4gW1JGQzU3NjZdLuKAnQ0KDQpIb3dldmVyLCB0aGlzIHNlZW1zIHRvIGlt cGx5IHRoYXQgYmFzZSByZWZlcnMgdG8gdGhlIGxvY2FsIHRyYW5zcG9ydCBhZGRyZXNzIG9mIHRo ZSBhZ2VudCBhbHNvIGluIGNhc2Ugb2YgcmVsYXllZCBjYW5kaWRhdGUuDQoNCj5UaGF0IHdvdWxk IGhhdmUgbm90IGJlZW4gbXkgaW50ZXJwcmV0YXRpb24gb2YgdGhlIGFib3ZlIHNlbnRlbmNlLg0K DQpJdOKAmXMgdGhlIOKAnGZyb20gdGhlIGJhc2UgdGhyb3VnaCB0aGF0IFRVUk4gc2VydmVy4oCd IHN0YXRlbWVudCB0aGF0IG1ha2VzIG1lIGludGVycHJldCB0aGF0IGJhc2UgaXMgbm90IGFzc29j aWF0ZWQgd2l0aCB0aGUgVFVSTiBzZXJ2ZXIsIGJ1dCB0aGUgYWdlbnQgOikNCg0KKklGKiBiYXNl IGlzIHRoZSB0cmFuc3BvcnQgYWRkcmVzcyBvZiB0aGUgVFVSTiBzZXJ2ZXIsIHRoZSB0ZXh0IHNo b3VsZCBzYXkgc29tZXRoaW5nIGxpa2U6DQoNCuKAnE1lZGlhIHNlbnQgZnJvbSBhIHJlbGF5ZWQg Y2FuZGlkYXRlIGlzIHNlbnQgZnJvbSB0aGUgbG9jYWwgYWdlbnQsIGFuZCBmb3J3YXJkZWQgdGhy b3VnaCB0aGUgYmFzZSAobG9jYXRlZCBpbiB0aGUgVFVSTiBzZXJ2ZXIpLCB1c2luZyBwcm9jZWR1 cmVzIGRlZmluZWQgaW4gW1JGQzU3NjZdLuKAnQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN Cg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B4BE39334ESESSMB209erics_ 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 ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZu YnNwOyDigJxNZWRpYSBzZW50IGZyb20gYSByZWxheWVkIGNhbmRpZGF0ZSBpcyBzZW50IGZyb20g dGhlIGJhc2UgdGhyb3VnaCB0aGF0IFRVUk48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNw OyBzZXJ2ZXIsIHVzaW5nIHByb2NlZHVyZXMgZGVmaW5lZCBpbiBbUkZDNTc2Nl0u4oCdPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhvd2V2ZXIsIHRoaXMgc2Vl bXMgdG8gaW1wbHkgdGhhdCBiYXNlIHJlZmVycyB0byB0aGUgbG9jYWwgdHJhbnNwb3J0IGFkZHJl c3Mgb2YgdGhlIGFnZW50IGFsc28gaW4gY2FzZSBvZiByZWxheWVkIGNhbmRpZGF0ZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5UaGF0 IHdvdWxkIGhhdmUgbm90IGJlZW4gbXkgaW50ZXJwcmV0YXRpb24gb2YgdGhlIGFib3ZlIHNlbnRl bmNlLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkl04oCZcyB0aGUg4oCcZnJvbSB0aGUgYmFzZQ0KPGI+dGhyb3Vn aDwvYj4gdGhhdCBUVVJOIHNlcnZlcuKAnSBzdGF0ZW1lbnQgdGhhdCBtYWtlcyBtZSBpbnRlcnBy ZXQgdGhhdCBiYXNlIGlzIG5vdCBhc3NvY2lhdGVkIHdpdGggdGhlIFRVUk4gc2VydmVyLCBidXQg dGhlIGFnZW50IDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4q PGI+SUY8L2I+KiBiYXNlIGlzIHRoZSB0cmFuc3BvcnQgYWRkcmVzcyBvZiB0aGUgVFVSTiBzZXJ2 ZXIsIHRoZSB0ZXh0IHNob3VsZCBzYXkgc29tZXRoaW5nIGxpa2U6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAnDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPk1lZGlhIHNlbnQgZnJvbSBhIHJlbGF5ZWQgY2FuZGlkYXRlIGlzIHNlbnQgZnJvbSB0aGUg bG9jYWwgYWdlbnQsIGFuZCBmb3J3YXJkZWQgdGhyb3VnaA0KIHRoZSBiYXNlIChsb2NhdGVkIGlu IHRoZSBUVVJOIHNlcnZlciksIHVzaW5nIHByb2NlZHVyZXMgZGVmaW5lZCBpbiBbUkZDNTc2Nl0u 4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4BE39334ESESSMB209erics_-- From nobody Wed Nov 16 00:12:13 2016 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 8CE3D129662 for ; Wed, 16 Nov 2016 00:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 fx6jww8EbV1M for ; Wed, 16 Nov 2016 00:12:09 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 F0FA9129672 for ; Wed, 16 Nov 2016 00:12:08 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id c4so29722063pfb.1 for ; Wed, 16 Nov 2016 00:12:08 -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=hbDdy7sJtLIHC0lt3EYjjpXaYbJHSXgJHuAEXoZHd0I=; b=Hn5RF/JnoaliZK8v1T8P9o0hDoJGKOJgDicSYTaO+abDrTRoBh1zo4ltuwr5G71WVn 8Am5WNHkLO1JGhFiWu+WdtxjMOen5BE5/u8nXGzFnv/VlpaaMQlIEBPTZxYXYEuphS/J mcGCxvImQ14AtXBMhBXw05ytXgsSdAKWrak+k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hbDdy7sJtLIHC0lt3EYjjpXaYbJHSXgJHuAEXoZHd0I=; b=gJTy2wwtMGzyvzvyz8rk0aMZVnx/hsiHxDJkAVsEN9sXJ7+YhvmDgCpLcNW6GiRi6A 9+VG1+qWo0x8ueHO5004GSEuVBqJyoxe13dvgCiQ4nGBHYocqgUWi7VTtAJzrcDavaY/ B5Hl/UmUrVYjwdFT4SmtVWWXtg4FXAJcwac/OD+oAUiFkwVlOzsSmVJIA1tSrT3MVXUq m3LUzIPFunlPkWEW+EceForBS7x0QmMQsV2wdzbbQ6OPnpfDihiwvOy7sfWBJpug09hz Mogb/wvIbOpmL1zCm3f3IQOtd4bgFlCqsZWH1Iwqc9jeI2yukaVSF5gqUkffI114ZIzz S7Ag== X-Gm-Message-State: ABUngvccymJbvp17SBa/ywobXczQ8a28ztjizMyzj2eSgBgi+KMNGItvn/zFwOdpiJDdumMp X-Received: by 10.98.27.132 with SMTP id b126mr2720683pfb.171.1479283928411; Wed, 16 Nov 2016 00:12:08 -0800 (PST) Received: from ?IPv6:2601:647:4601:ec84:4862:f77a:eb5c:23be? ([2601:647:4601:ec84:4862:f77a:eb5c:23be]) by smtp.gmail.com with ESMTPSA id p25sm50454077pfk.20.2016.11.16.00.12.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 00:12:07 -0800 (PST) From: Nils Ohlmeier Message-Id: <1A0F4811-CAC6-4B49-85A4-6DCA455ED018@mozilla.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E5E52CC9-A3A4-4132-920D-87D0C6D26DE1" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Wed, 16 Nov 2016 00:12:05 -0800 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE39334@ESESSMB209.ericsson.se> To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B4BE391B2@ESESSMB209.ericsson.se> <9077DC29-1BDB-491E-AB26-56B726C1BCF2@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4BE39334@ESESSMB209.ericsson.se> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: base of relayed candidate X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 08:12:11 -0000 --Apple-Mail=_E5E52CC9-A3A4-4132-920D-87D0C6D26DE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 15, 2016, at 23:56, Christer Holmberg = wrote: > =E2=80=9CMedia sent from a relayed candidate is sent from the base = through that TURN > server, using procedures defined in [RFC5766].=E2=80=9D > =20 > However, this seems to imply that base refers to the local transport = address of the agent also in case of relayed candidate. > =20 > >That would have not been my interpretation of the above sentence. > =20 > It=E2=80=99s the =E2=80=9Cfrom the base through that TURN server=E2=80=9D= statement that makes me interpret that base is not associated with the = TURN server, but the agent :) > =20 > *IF* base is the transport address of the TURN server, the text should = say something like: > =20 > =E2=80=9CMedia sent from a relayed candidate is sent from the local = agent, and forwarded through the base (located in the TURN server), = using procedures defined in [RFC5766].=E2=80=9D Yes, that makes it a lot more clear in my opinion. Best Nils --Apple-Mail=_E5E52CC9-A3A4-4132-920D-87D0C6D26DE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 15, 2016, at 23:56, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
   =E2=80=9CMedia sent from a relayed candidate is = sent from the base through that TURN
   server, using procedures defined in = [RFC5766].=E2=80=9D
 
However, this seems to imply that base refers to the local = transport address of the agent also in case of relayed candidate.
 
>That would have not been my interpretation of the = above sentence.
 
It=E2=80=99s the = =E2=80=9Cfrom the base through that TURN server=E2=80=9D = statement that makes me interpret that base is not associated with the = TURN server, but the agent :)
 
*IF* = base is the transport address of the TURN server, the text should say = something like:
 
=E2=80=9CMedia sent from a relayed candidate is sent from the local = agent, and forwarded through the base (located in the TURN server), = using procedures defined in = [RFC5766].=E2=80=9D

Yes, that makes it a lot more clear in my = opinion.

Best
  = Nils

= --Apple-Mail=_E5E52CC9-A3A4-4132-920D-87D0C6D26DE1-- From nobody Wed Nov 16 19:12:54 2016 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 625FB129478 for ; Wed, 16 Nov 2016 19:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84Nu4-ubN8f4 for ; Wed, 16 Nov 2016 19:12:51 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0013C129619 for ; Wed, 16 Nov 2016 19:05:55 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id n21so202101027qka.3 for ; Wed, 16 Nov 2016 19:05:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ck3lAiZ5hXQwvFScIAzWNVLdcA/S4QXG17y4Ofb2t2U=; b=yh/GNpEonz6MDaww1iqCw0AiMoxR2yE10+LAPHntb9G3CZzLqHy+lV2vq23Zr4tflZ hn3DuRQy+va4tLK9h5flKPwHUKNIDvVbTbZlK5wi0Nf6gymCCvTCYz7+f22Pl3MuaAtT idbrLXOO0ohUfHloGyj8PZ+m/NaapecoJwA5j/0b0N8Fos5jK0xxnwKdNx5pibizqYxQ RlcPDVM39AWXLI+m6VFwAyswKVsCCsUYI11m33UluCP1iMF9Zk9+WXkTcfDUPJiPlmLF R2NxnWq511HfgorlGkZV2v7XnsaQ1dbKbXA1+bbDy345L0phUcxZ2m3xfjtVA+US2WT8 /mUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ck3lAiZ5hXQwvFScIAzWNVLdcA/S4QXG17y4Ofb2t2U=; b=NLXNEu6KpM6kYQLVRDVpG5do76/VyXTkA2SMhZS4WbbLnwTnJOWhQzhop5rdaU2L9R oOAZyLpKmJBwb0UQ95av9DSeBiki0wpXGQWGTHZSRKtVvIwLgxL7vd5QT7vYqzZnYa8t /lLW/IjQ8YduIATLM8dWRmltN8HlzvHksHiNPACWT7XY4DJjc1k3/scwDC+OtxYEa88z RdY9UWoJQaRww4kZ4BjMXXNLXU2R+SaZGCxNy3xF4CfVCh/ilaD+KsTX6qSRasP3aHb7 Ir8P0VBZO6UA9tooTLh0SL0XyOv1i1jnxN6ijuy5ulVQRt4K2C7POyf/E+XIjIB4ZIy+ pipw== X-Gm-Message-State: AKaTC01FvtneOcNWd0EkEG0SfGiHm6kIq5F0ynZqf0r7FMSrZs6DiB/POy08RrjBLrIXBQ== X-Received: by 10.55.220.69 with SMTP id v66mr893695qki.264.1479351955005; Wed, 16 Nov 2016 19:05:55 -0800 (PST) Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com. [209.85.220.174]) by smtp.gmail.com with ESMTPSA id x123sm457437qkx.46.2016.11.16.19.05.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 19:05:54 -0800 (PST) Received: by mail-qk0-f174.google.com with SMTP id n21so202100680qka.3; Wed, 16 Nov 2016 19:05:54 -0800 (PST) X-Received: by 10.55.6.14 with SMTP id 14mr904719qkg.167.1479351954205; Wed, 16 Nov 2016 19:05:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.135.243 with HTTP; Wed, 16 Nov 2016 19:05:53 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> From: Roman Shpount Date: Wed, 16 Nov 2016 22:05:53 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114d7564ba76f705417677a2 Archived-At: Cc: "mmusic@ietf.org" , ice@ietf.org Subject: Re: [Ice] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 03:12:52 -0000 --001a114d7564ba76f705417677a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Adding ICE group to this message. The approach always was that tcp candidates can potentially go only as far as SBC and then be terminated by UDP transport. Because of this everything transmitted over tcp candidate was still considered to be transmitted over the unreliable out-of-order transport. It is also assumed that candidates can switch from UDP to TCP based candidate during nomination. This is why, for instance, we run DTLS with RFC4571 framing over tcp candidates, not TLS. Because of this I always thought that ICE is UDP first with additional TCP transports for situation when UDP will not work. So, as a result, I think ICE-bis should specify that UDP MUST be supported and default candidate MUST be UDP. ICE SDP can reflect this, but I think this is the underlying protocol requirement. I also wanted to add that BFCP needs to examine how ICE support is implemented by this protocol. I think it is not covered in the current drafts. I also think I do not think it is possible for TCP/BFCP to run over ICE. On the other hand UDP/DTLS/BFCP and TCP/DTLS/BFCP would trivial based on current DTLS work. Regards, _____________ Roman Shpount On Wed, Nov 16, 2016 at 8:44 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > I have no problem with Roman=E2=80=99s must-support-UDP suggestion. I gue= ss the > question is whether the BFCP folks could accept that. Cullen did say that > TCP-based BFCP deployments have been around for a decade. But, do they > support ICE? > > > > If we decide to move forward with such approach, we need to ask ourselves > whether must-support-UDP should be an ICE requirement (in which case the > suggestion should be brought to the ICE WG) or whether it should only be = an > ICE-using-SIP-SDP requirement. > > > > Regards, > > > > Christer > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Roman > Shpount > *Sent:* 17 November 2016 00:52 > *To:* mmusic@ietf.org > *Subject:* [MMUSIC] m=3D line protocol in case of ICE > > > > Hi All, > > > > I just wanted to return to the m=3D line protocol issue that Christer rai= sed > during the last MMUSIC session. > > > > All the ICE implementations I've seen are primarily UDP based with suppor= t > for tcp host candidates which are primarily used to connect to end points > on public IP. If all ICE implementations are continue to be primarily UDP > based, then the simplest solution would be to require UDP support when an= y > given protocol is implemented over ICE. DTLS and RTP are already primaril= y > UDP based so this is a non-requirement. Even more, all protocols that are > implemented on top of ICE must assume that underling transports (includin= g > tcp candidates) are unreliable, since candidate pair can change at any ti= me > between reliable and unreliable transports, so this makes them different > from protocols implemented on plain TCP or TLS. > > > > So the first question I wanted to ask is anybody interested in TCP only > ICE implementation where the protocol running on top of such implementati= on > relies on the reliable delivery of underlying messages? By this I mean, > does anybody wants implement TCP based ICE, with simultaneous open, > reflexive and relay candidates in such a way that ICE implementation will > run from behind NAT without ever needing a UDP candidate? > > > > I understand that BFCP was used for a long time, but I do not think > TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I think only UDP/BFCP= , > UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE. > > > > I think both rfc4582bis and rfc4583bis need a careful review and > additional sections that describe ICE considerations. I think the most > obvious thing would be to specify that ICE can only be supported by > UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which cas= e > RFC4571 is used when tcp candidates are used. Furthermore, when tcp > candidate is selected with UDP/BFCP transport, it is not the same thing a= s > using TCP/BFCP and will need a different transport tag (something like > TCP/UDP/BFCP). Alternatively we can require that only secure versions of > BFCP are used with ICE and only allow ICE usage for UDP/DTLS/BFCP and > TCP/DTLS/BFCP. > > > > To conclude, I would argue that the simplest solution would be that for > all protocols implemented on top of ICE, UDP MUST be supported and defaul= t > candidates MUST be UDP based. This avoids building uncomfortable artifici= al > constructs to avoid ICE mismatch and requires minimal changes to existing > specifications. > > > > Regards, > > _____________ > Roman Shpount > --001a114d7564ba76f705417677a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adding ICE group to this message.

The approach always was that tcp candidates can potentially go only as far= as SBC and then be terminated by UDP transport. Because of this everything= transmitted over tcp candidate was still considered to be transmitted over= the unreliable out-of-order transport. It is also assumed that candidates = can switch from UDP to TCP based candidate during nomination. This is why, = for instance, we run DTLS with RFC4571 framing over tcp candidates, not TLS= . Because of this I always thought that ICE is UDP first with additional TC= P transports for situation when UDP will not work. So, as a result, I think= ICE-bis should specify that UDP MUST be supported and default candidate MU= ST be UDP. ICE SDP can reflect this, but I think this is the underlying pro= tocol requirement.

I also wanted to add that BFCP needs = to examine how ICE support is implemented by this protocol. I think it is n= ot covered in the current drafts. I also think I do not think it is possibl= e for TCP/BFCP to=C2=A0run over ICE. On the other hand UDP/DTLS/BFCP and TC= P/DTLS/BFCP would trivial based on current DTLS work.

Regards,
_____________
Roman Shpount
<= /div>
On Wed, Nov 16, 2016 at 8:44 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

I have no problem with Roman=E2=80=99s must-= support-UDP suggestion. I guess the question is whether the BFCP folks coul= d accept that. Cullen did say that TCP-based BFCP deployments have been around for a decade. But= , do they support ICE?

=C2=A0

If we decide to move forward with such appro= ach, we need to ask ourselves whether must-support-UDP should be an ICE req= uirement (in which case the suggestion should be brought to the ICE WG) or whether it s= hould only be an ICE-using-SIP-SDP requirement.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: mmusic [mailto:mmusic-bounces@ietf.or= g] On Behalf Of Roman Shpount
Sent: 17 November 2016 00:52
To: mmusic@ietf= .org
Subject: [MMUSIC] m=3D line protocol in case of ICE

=C2=A0

Hi All,

=C2=A0

I just wanted to return to the m=3D line protocol is= sue that Christer raised during the last MMUSIC session.

=C2=A0

All the ICE implementations I've seen are primar= ily UDP based with support for tcp host candidates which are primarily used= to connect to end points on public IP. If all ICE implementations are cont= inue to be primarily UDP based, then the simplest solution would be to require UDP support when any given protocol = is implemented over ICE. DTLS and RTP are already primarily UDP based so th= is is a non-requirement. Even more, all protocols that are implemented on t= op of ICE must assume that underling transports (including tcp candidates) are unreliable, since candidate pair= can change at any time between reliable and unreliable transports, so this= makes them different from protocols implemented on plain TCP or TLS.

=C2=A0

So the first question I wanted to ask is anybody int= erested in TCP only ICE implementation where the protocol running on top of= such implementation relies on the reliable delivery of underlying messages= ? By this I mean, does anybody wants implement TCP based ICE, with simultaneous open, reflexive and relay candi= dates in such a way that ICE implementation will run from behind NAT withou= t ever needing a UDP candidate?

=C2=A0

I understand that BFCP was used for a long time, but= I do not think TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I think= only UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE.=C2=A0=

=C2=A0

I think both=C2=A0rfc4582bis and rfc4583bis need a c= areful review and additional sections that describe ICE considerations. I t= hink the most obvious thing would be to specify that ICE can only be suppor= ted by UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which case RFC4571 is used when tcp candidates are us= ed. Furthermore, when tcp candidate is selected with UDP/BFCP transport, it= is not the same thing as using TCP/BFCP and will need a different transpor= t tag (something like TCP/UDP/BFCP). Alternatively we can require that only secure versions of BFCP are used wi= th ICE and only allow ICE usage for UDP/DTLS/BFCP and TCP/DTLS/BFCP.=

=C2=A0

To conclude, I would argue that the simplest solutio= n would be that for all protocols implemented on top of ICE, UDP MUST be su= pported and default candidates MUST be UDP based. This avoids building unco= mfortable artificial constructs to avoid ICE mismatch and requires minimal changes to existing specifications= .

=C2=A0

Regards,

_____________
Roman Shpount


--001a114d7564ba76f705417677a2-- From nobody Thu Nov 17 02:02:08 2016 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 1106F127077; Thu, 17 Nov 2016 02:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtmaK3YdT8jX; Thu, 17 Nov 2016 02:02: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 400B3129871; Thu, 17 Nov 2016 02:02:01 -0800 (PST) X-AuditID: c1b4fb25-ec9d598000007ee2-87-582d8017973c Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by (Symantec Mail Security) with SMTP id 77.1B.32482.7108D285; Thu, 17 Nov 2016 11:01:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0319.002; Thu, 17 Nov 2016 11:01:57 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] m= line protocol in case of ICE Thread-Index: AQHSQFwT8S0xdJKeakq1+K6kpgEs7aDcZjMAgAAHVICAAIUDVA== Date: Thu, 17 Nov 2016 10:01:56 +0000 Message-ID: <8D1DCEC3-CD4C-45DE-A603-D61EEA47EACD@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_8D1DCEC3CD4C45DEA603D61EEA47EACDericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbFdTle8QTfCYMc8VYtvF2otpi5/zGIx 48JUZgdmjyVLfjJ53JpSEMAUxWWTkpqTWZZapG+XwJWxv/MWS8GanIqP93axNDAeje5i5OSQ EDCRmHj/O0sXIxeHkMA6Ronjpx4yQjhLGCXWLt3D3MXIwcEmYCHR/U8bpEFEQFXi7/fJTCA2 s4CbRPPNfYwgJcICphITrktBlJhJbF64hBHCdpK496mfHcRmAWq9M3cbG0g5r4C9xMOJJRCb bjJK7Di1FayGUyBQ4syb92A2o4CYxPdTa6BWiUvcejKfCeJmAYkle84zQ9iiEi8f/2OFqEmW WLRpEguIzSsgKHFy5hOWCYzCs5C0z0JSNgtJGUTcQOL9ufnMELa2xLKFr6FsfYmNX84yIosv YGRfxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYQwe3/FbdwXj5jeMhRgEORiUe3g1rdCKE WBPLiitzDzFKcDArifA61epGCPGmJFZWpRblxxeV5qQWH2KU5mBREuc1W3k/XEggPbEkNTs1 tSC1CCbLxMEp1cAYYbrCPS2nQvWD+FOOguY6/dQj+ew7XRtyfvarFK1xWrLo2W2+4+857+y7 /37RYxXlMzWbbuneYXm6LGbF7hS9eW17HWRPFXWcTjh07rOF0ErhwzcFf13s5OPJuVKhJ+r0 98rePpUiwXl2Z0tD3SWWtPjm9BvEfrc3Or9G2Yq75P8Mm7vzv89UYinOSDTUYi4qTgQA9vkF Hp0CAAA= Archived-At: Cc: "mmusic@ietf.org" , "ice@ietf.org" Subject: Re: [Ice] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 10:02:05 -0000 --_000_8D1DCEC3CD4C45DEA603D61EEA47EACDericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I assume future QUIC candidates will also be considered UDP. Regards, Christer Sent from my iPhone On 17 Nov 2016, at 12.06, Roman Shpount > wrote: Adding ICE group to this message. The approach always was that tcp candidates can potentially go only as far = as SBC and then be terminated by UDP transport. Because of this everything = transmitted over tcp candidate was still considered to be transmitted over = the unreliable out-of-order transport. It is also assumed that candidates c= an switch from UDP to TCP based candidate during nomination. This is why, f= or instance, we run DTLS with RFC4571 framing over tcp candidates, not TLS.= Because of this I always thought that ICE is UDP first with additional TCP= transports for situation when UDP will not work. So, as a result, I think = ICE-bis should specify that UDP MUST be supported and default candidate MUS= T be UDP. ICE SDP can reflect this, but I think this is the underlying prot= ocol requirement. I also wanted to add that BFCP needs to examine how ICE support is implemen= ted by this protocol. I think it is not covered in the current drafts. I al= so think I do not think it is possible for TCP/BFCP to run over ICE. On the= other hand UDP/DTLS/BFCP and TCP/DTLS/BFCP would trivial based on current = DTLS work. Regards, _____________ Roman Shpount On Wed, Nov 16, 2016 at 8:44 PM, Christer Holmberg > wrote: I have no problem with Roman=92s must-support-UDP suggestion. I guess the q= uestion is whether the BFCP folks could accept that. Cullen did say that TC= P-based BFCP deployments have been around for a decade. But, do they suppor= t ICE? If we decide to move forward with such approach, we need to ask ourselves w= hether must-support-UDP should be an ICE requirement (in which case the sug= gestion should be brought to the ICE WG) or whether it should only be an IC= E-using-SIP-SDP requirement. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Roman Shpount Sent: 17 November 2016 00:52 To: mmusic@ietf.org Subject: [MMUSIC] m=3D line protocol in case of ICE Hi All, I just wanted to return to the m=3D line protocol issue that Christer raise= d during the last MMUSIC session. All the ICE implementations I've seen are primarily UDP based with support = for tcp host candidates which are primarily used to connect to end points o= n public IP. If all ICE implementations are continue to be primarily UDP ba= sed, then the simplest solution would be to require UDP support when any gi= ven protocol is implemented over ICE. DTLS and RTP are already primarily UD= P based so this is a non-requirement. Even more, all protocols that are imp= lemented on top of ICE must assume that underling transports (including tcp= candidates) are unreliable, since candidate pair can change at any time be= tween reliable and unreliable transports, so this makes them different from= protocols implemented on plain TCP or TLS. So the first question I wanted to ask is anybody interested in TCP only ICE= implementation where the protocol running on top of such implementation re= lies on the reliable delivery of underlying messages? By this I mean, does = anybody wants implement TCP based ICE, with simultaneous open, reflexive an= d relay candidates in such a way that ICE implementation will run from behi= nd NAT without ever needing a UDP candidate? I understand that BFCP was used for a long time, but I do not think TCP/BFC= P or TCP/TLS/BFCP can even be used with ICE. I think only UDP/BFCP, UDP/DTL= S/BFCP and TCP/DTLS/BFCP can even support ICE. I think both rfc4582bis and rfc4583bis need a careful review and additional= sections that describe ICE considerations. I think the most obvious thing = would be to specify that ICE can only be supported by UDP/BFCP, UDP/DTLS/BF= CP and TCP/DTLS/BFCP. It will also mean in which case RFC4571 is used when = tcp candidates are used. Furthermore, when tcp candidate is selected with U= DP/BFCP transport, it is not the same thing as using TCP/BFCP and will need= a different transport tag (something like TCP/UDP/BFCP). Alternatively we = can require that only secure versions of BFCP are used with ICE and only al= low ICE usage for UDP/DTLS/BFCP and TCP/DTLS/BFCP. To conclude, I would argue that the simplest solution would be that for all= protocols implemented on top of ICE, UDP MUST be supported and default can= didates MUST be UDP based. This avoids building uncomfortable artificial co= nstructs to avoid ICE mismatch and requires minimal changes to existing spe= cifications. Regards, _____________ Roman Shpount --_000_8D1DCEC3CD4C45DEA603D61EEA47EACDericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,

I assume future QUIC candidates will also be= considered UDP.

Regards,

Christer

Sent from my iPhone

On 17 Nov 2016, at 12.06, Roman Shpount <roman@telurix.com> wrote:

Adding ICE group to this message.

The approach always was that tcp candidates can potentially go only as far = as SBC and then be terminated by UDP transport. Because of this everything = transmitted over tcp candidate was still considered to be transmitted over = the unreliable out-of-order transport. It is also assumed that candidates can switch from UDP to TCP based candid= ate during nomination. This is why, for instance, we run DTLS with RFC4571 = framing over tcp candidates, not TLS. Because of this I always thought that= ICE is UDP first with additional TCP transports for situation when UDP will not work. So, as a result, I th= ink ICE-bis should specify that UDP MUST be supported and default candidate= MUST be UDP. ICE SDP can reflect this, but I think this is the underlying = protocol requirement.

I also wanted to add that BFCP needs to examine how ICE support is imp= lemented by this protocol. I think it is not covered in the current drafts.= I also think I do not think it is possible for TCP/BFCP to run over I= CE. On the other hand UDP/DTLS/BFCP and TCP/DTLS/BFCP would trivial based on current DTLS work.

Regards,
_____________
Roman Shpount

On Wed, Nov 16, 2016 at 8:44 PM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

I have no problem with Roman=92s must-suppor= t-UDP suggestion. I guess the question is whether the BFCP folks could acce= pt that. Cullen did say that TCP-based BFCP deployments have been around for a decade. But, do they support ICE?<= /span>

 

If we decide to move forward with such appro= ach, we need to ask ourselves whether must-support-UDP should be an ICE req= uirement (in which case the suggestion should be brought to the ICE WG) or whether it should only be an ICE-using= -SIP-SDP requirement.

 

Regards,

 

Christer

 

From: mmusic [mailto:mmusic-bounces@ietf.or= g] On Behalf Of Roman Shpount
Sent: 17 November 2016 00:52
To: mmusic@ietf= .org
Subject: [MMUSIC] m=3D line protocol in case of ICE

 

Hi All,

 

I just wanted to return to the m=3D line protocol is= sue that Christer raised during the last MMUSIC session.

 

All the ICE implementations I've seen are primarily = UDP based with support for tcp host candidates which are primarily used to = connect to end points on public IP. If all ICE implementations are continue= to be primarily UDP based, then the simplest solution would be to require UDP support when any given protocol = is implemented over ICE. DTLS and RTP are already primarily UDP based so th= is is a non-requirement. Even more, all protocols that are implemented on t= op of ICE must assume that underling transports (including tcp candidates) are unreliable, since candidate pair= can change at any time between reliable and unreliable transports, so this= makes them different from protocols implemented on plain TCP or TLS.

 

So the first question I wanted to ask is anybody int= erested in TCP only ICE implementation where the protocol running on top of= such implementation relies on the reliable delivery of underlying messages= ? By this I mean, does anybody wants implement TCP based ICE, with simultaneous open, reflexive and relay candi= dates in such a way that ICE implementation will run from behind NAT withou= t ever needing a UDP candidate?

 

I understand that BFCP was used for a long time, but= I do not think TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I think= only UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE. =

 

I think both rfc4582bis and rfc4583bis need a c= areful review and additional sections that describe ICE considerations. I t= hink the most obvious thing would be to specify that ICE can only be suppor= ted by UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which case RFC4571 is used when tcp candidates are us= ed. Furthermore, when tcp candidate is selected with UDP/BFCP transport, it= is not the same thing as using TCP/BFCP and will need a different transpor= t tag (something like TCP/UDP/BFCP). Alternatively we can require that only secure versions of BFCP are used wi= th ICE and only allow ICE usage for UDP/DTLS/BFCP and TCP/DTLS/BFCP.=

 

To conclude, I would argue that the simplest solutio= n would be that for all protocols implemented on top of ICE, UDP MUST be su= pported and default candidates MUST be UDP based. This avoids building unco= mfortable artificial constructs to avoid ICE mismatch and requires minimal changes to existing specifications= .

 

Regards,

_____________
Roman Shpount


--_000_8D1DCEC3CD4C45DEA603D61EEA47EACDericssoncom_-- From nobody Thu Nov 17 17:14:28 2016 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 1F6E2129860; Thu, 17 Nov 2016 17:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 AEAplgJhpqxy; Thu, 17 Nov 2016 17:14:23 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 57FC7129859; Thu, 17 Nov 2016 17:14:18 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id x23so18965219pgx.3; Thu, 17 Nov 2016 17:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=XH3G2uhBWPIri1cT58DZd1RCccr5mQzeFHiuvaR5Brw=; b=movMiXpQCHl6nbQdAzGNTJ4R/d8fu3WvBlp3rI45wamesBZt9sCRsHUAG/dQcAZYz6 6EvkbMTMMS6SjxC875VAzXvOZT6a11EJ20wGcZo7230OGTAtJfL6Lf/vw3MkwhwXax4g j/Jbvv/W9IVlI9qNsIKNTx3TV14i7Z+E6qlLdsKKY6wsOJAGLjisGbj+lU8b/p1FA/6b 9soNXchPGP6PF2Od+2o21g8+/w7IEBEmeyRujo7F856wdXc9zB3oEaBwVT7umnSOdwSi 9ojPFIidr7y943EcX/o7zJR47wzXeZ/gcaM35EkU2z0YiFwkDjFp8cqwWzuXOw94+qyX VPsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=XH3G2uhBWPIri1cT58DZd1RCccr5mQzeFHiuvaR5Brw=; b=JDoQf3YSaA63BenhgLlRiEt0j/e46Mo7yfw3UHXloketN10DR6uphGXBrBHhdRoPoC e65ZXdgQh1rSXUT9yolJVfkk53KqYbFK69mEnEbUwYLj3OLsXf7hKDyW5mEcmB/0n2hH C3nojlaa4TMIUjbBeOZoGNewDlQc7kOIgafr233i4fMGgCU9k4me70XLwyuJrI9JhAI5 oOrSQ61amQ/XpK5hTzXmUFvO6tv5eHG7/hIDoN2YXxb+TIl909wWWVevtuUNVXZ88+6B HJZXeHcy4qSxhapF2TlEbELsQ0OHPk4FAUMcU9yz0LVomJp028/l0rU7dwahASshTFsU 5pCg== X-Gm-Message-State: ABUngvd7SSFgwNMtchNMI66UtGm2rNWrSIvwU7Lofb1CCrHtUQL/s7dgal9B5bLAQtfn2Q== X-Received: by 10.99.43.8 with SMTP id r8mr13118830pgr.83.1479431657265; Thu, 17 Nov 2016 17:14:17 -0800 (PST) Received: from t2001067c03700128e1d8ba8f9f586209.v6.meeting.ietf.org ([2001:67c:370:128:e1d8:ba8f:9f58:6209]) by smtp.gmail.com with ESMTPSA id u23sm11235098pfg.86.2016.11.17.17.14.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Nov 2016 17:14:16 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FCD11268-A7C3-4EED-8FFB-B12215DC4799" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: Date: Fri, 18 Nov 2016 01:14:10 +0000 Message-Id: References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> To: Roman Shpount X-Mailer: Apple Mail (2.3124) Archived-At: Cc: bfcpbis@ietf.org, ice@ietf.org, "mmusic@ietf.org" , Christer Holmberg Subject: Re: [Ice] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 01:14:26 -0000 --Apple-Mail=_FCD11268-A7C3-4EED-8FFB-B12215DC4799 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adding bfcpbis. You raise a good point Roman - there=E2=80=99s no definition of how to = actually use ICE with BFCP at the protocol level - this only came up in = some very late reviews of 4582bis. The initial suggestion was to use the = same text as in draft-ietf-mmusic-sctp-sdp-19, but it then raised the = point that, given BFCP does not have a MTI protocol, if the offerer = supported both they would include their preferred option, but if the = receiver supported the other variant, there=E2=80=99s no way to = immediately negotiate that without a re-INVITE. Christer=E2=80=99s suggestion to relax the requirement that the m-line = protocol in the answer matches one of the ICE candidates would support = the case where the offerer supports both but prefers UDP, but the = answerer only supports TCP. Although no implementations currently do ICE = here, this relaxation would leave the door open to gaining this = negotiation flexibility in bfcpbis implementations. There seems no = reason to have this requirement applied to the answer in the first = place. I don=E2=80=99t understand the comment about SBCs; today, tcp candidates = are used for media and data channels end-to-end in WebRTC, to name but = one implementation. Regards, Alan > On 17 Nov 2016, at 03:05, Roman Shpount wrote: >=20 > Adding ICE group to this message. >=20 > The approach always was that tcp candidates can potentially go only as = far as SBC and then be terminated by UDP transport. Because of this = everything transmitted over tcp candidate was still considered to be = transmitted over the unreliable out-of-order transport. It is also = assumed that candidates can switch from UDP to TCP based candidate = during nomination. This is why, for instance, we run DTLS with RFC4571 = framing over tcp candidates, not TLS. Because of this I always thought = that ICE is UDP first with additional TCP transports for situation when = UDP will not work. So, as a result, I think ICE-bis should specify that = UDP MUST be supported and default candidate MUST be UDP. ICE SDP can = reflect this, but I think this is the underlying protocol requirement. >=20 > I also wanted to add that BFCP needs to examine how ICE support is = implemented by this protocol. I think it is not covered in the current = drafts. I also think I do not think it is possible for TCP/BFCP to run = over ICE. On the other hand UDP/DTLS/BFCP and TCP/DTLS/BFCP would = trivial based on current DTLS work. >=20 > Regards, > _____________ > Roman Shpount >=20 > On Wed, Nov 16, 2016 at 8:44 PM, Christer Holmberg = > = wrote: > I have no problem with Roman=E2=80=99s must-support-UDP suggestion. I = guess the question is whether the BFCP folks could accept that. Cullen = did say that TCP-based BFCP deployments have been around for a decade. = But, do they support ICE? >=20 > =20 >=20 > If we decide to move forward with such approach, we need to ask = ourselves whether must-support-UDP should be an ICE requirement (in = which case the suggestion should be brought to the ICE WG) or whether it = should only be an ICE-using-SIP-SDP requirement. >=20 > =20 >=20 > Regards, >=20 > =20 >=20 > Christer >=20 > =C2=A0 <> > From: mmusic [mailto:mmusic-bounces@ietf.org = ] On Behalf Of Roman Shpount > Sent: 17 November 2016 00:52 > To: mmusic@ietf.org > Subject: [MMUSIC] m=3D line protocol in case of ICE >=20 > =20 >=20 > Hi All, >=20 > =20 >=20 > I just wanted to return to the m=3D line protocol issue that Christer = raised during the last MMUSIC session. >=20 > =20 >=20 > All the ICE implementations I've seen are primarily UDP based with = support for tcp host candidates which are primarily used to connect to = end points on public IP. If all ICE implementations are continue to be = primarily UDP based, then the simplest solution would be to require UDP = support when any given protocol is implemented over ICE. DTLS and RTP = are already primarily UDP based so this is a non-requirement. Even more, = all protocols that are implemented on top of ICE must assume that = underling transports (including tcp candidates) are unreliable, since = candidate pair can change at any time between reliable and unreliable = transports, so this makes them different from protocols implemented on = plain TCP or TLS. >=20 > =20 >=20 > So the first question I wanted to ask is anybody interested in TCP = only ICE implementation where the protocol running on top of such = implementation relies on the reliable delivery of underlying messages? = By this I mean, does anybody wants implement TCP based ICE, with = simultaneous open, reflexive and relay candidates in such a way that ICE = implementation will run from behind NAT without ever needing a UDP = candidate? >=20 > =20 >=20 > I understand that BFCP was used for a long time, but I do not think = TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I think only = UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE.=20 >=20 > =20 >=20 > I think both rfc4582bis and rfc4583bis need a careful review and = additional sections that describe ICE considerations. I think the most = obvious thing would be to specify that ICE can only be supported by = UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which = case RFC4571 is used when tcp candidates are used. Furthermore, when tcp = candidate is selected with UDP/BFCP transport, it is not the same thing = as using TCP/BFCP and will need a different transport tag (something = like TCP/UDP/BFCP). Alternatively we can require that only secure = versions of BFCP are used with ICE and only allow ICE usage for = UDP/DTLS/BFCP and TCP/DTLS/BFCP. >=20 > =20 >=20 > To conclude, I would argue that the simplest solution would be that = for all protocols implemented on top of ICE, UDP MUST be supported and = default candidates MUST be UDP based. This avoids building uncomfortable = artificial constructs to avoid ICE mismatch and requires minimal changes = to existing specifications. >=20 > =20 >=20 > Regards, >=20 > _____________ > Roman Shpount >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail=_FCD11268-A7C3-4EED-8FFB-B12215DC4799 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Adding bfcpbis.

You raise a good point Roman - there=E2=80=99s no definition = of how to actually use ICE with BFCP at the protocol level - this only = came up in some very late reviews of 4582bis. The initial suggestion was = to use the same text as in draft-ietf-mmusic-sctp-sdp-19, but it = then raised the point that, given BFCP does not have a MTI protocol, if = the offerer supported both they would include their preferred option, = but if the receiver supported the other variant, there=E2=80=99s no way = to immediately negotiate that without a re-INVITE.

Christer=E2=80=99s = suggestion to relax the requirement that the m-line protocol in the answer matches one of the ICE candidates = would support the case where the offerer supports both but prefers UDP, = but the answerer only supports TCP. Although no implementations = currently do ICE here, this relaxation would leave the door open to = gaining this negotiation flexibility in bfcpbis implementations. There = seems no reason to have this requirement applied to the answer in the = first place.

I = don=E2=80=99t understand the comment about SBCs; today, tcp candidates = are used for media and data channels end-to-end in WebRTC, to name but = one implementation.

Regards,
Alan

On 17 Nov 2016, at 03:05, Roman Shpount = <roman@telurix.com> wrote:

Adding ICE group to this message.

The approach always was that tcp = candidates can potentially go only as far as SBC and then be terminated = by UDP transport. Because of this everything transmitted over tcp = candidate was still considered to be transmitted over the unreliable = out-of-order transport. It is also assumed that candidates can switch = from UDP to TCP based candidate during nomination. This is why, for = instance, we run DTLS with RFC4571 framing over tcp candidates, not TLS. = Because of this I always thought that ICE is UDP first with additional = TCP transports for situation when UDP will not work. So, as a result, I = think ICE-bis should specify that UDP MUST be supported and default = candidate MUST be UDP. ICE SDP can reflect this, but I think this is the = underlying protocol requirement.

I also wanted to add that BFCP needs to examine how ICE = support is implemented by this protocol. I think it is not covered in = the current drafts. I also think I do not think it is possible for = TCP/BFCP to run over ICE. On the other hand UDP/DTLS/BFCP and = TCP/DTLS/BFCP would trivial based on current DTLS work.

Regards,
_____________
Roman Shpount

On Wed, Nov 16, 2016 at 8:44 = PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

I have no problem with Roman=E2=80=99s must-support-UDP = suggestion. I guess the question is whether the BFCP folks could accept = that. Cullen did say that TCP-based BFCP deployments have been around for a decade. = But, do they support ICE?

 

If we decide to move forward with such approach, we need = to ask ourselves whether must-support-UDP should be an ICE requirement = (in which case the suggestion should be brought to the ICE WG) or whether = it should only be an ICE-using-SIP-SDP requirement.

 

Regards,

 

Christer

 

From: = mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 17 November 2016 00:52
To: mmusic@ietf.org
Subject: [MMUSIC] m=3D line protocol in case of ICE

 

Hi All,

 

I just wanted to return to the m=3D= line protocol issue that Christer raised during the last MMUSIC = session.

 

All the ICE implementations I've = seen are primarily UDP based with support for tcp host candidates which = are primarily used to connect to end points on public IP. If all ICE = implementations are continue to be primarily UDP based, then the simplest solution would be to require UDP support when any given = protocol is implemented over ICE. DTLS and RTP are already primarily UDP = based so this is a non-requirement. Even more, all protocols that are = implemented on top of ICE must assume that underling transports (including tcp candidates) are unreliable, since candidate = pair can change at any time between reliable and unreliable transports, = so this makes them different from protocols implemented on plain TCP or = TLS.

 

So the first question I wanted to = ask is anybody interested in TCP only ICE implementation where the = protocol running on top of such implementation relies on the reliable = delivery of underlying messages? By this I mean, does anybody wants implement TCP based ICE, with simultaneous open, reflexive and relay = candidates in such a way that ICE implementation will run from behind = NAT without ever needing a UDP candidate?

 

I understand that BFCP was used = for a long time, but I do not think TCP/BFCP or TCP/TLS/BFCP can even be = used with ICE. I think only UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP = can even support ICE. 

 

I think both rfc4582bis and = rfc4583bis need a careful review and additional sections that describe = ICE considerations. I think the most obvious thing would be to specify = that ICE can only be supported by UDP/BFCP, UDP/DTLS/BFCP and = TCP/DTLS/BFCP. It will also mean in which case RFC4571 is used when tcp candidates are = used. Furthermore, when tcp candidate is selected with UDP/BFCP = transport, it is not the same thing as using TCP/BFCP and will need a = different transport tag (something like TCP/UDP/BFCP). Alternatively we can require that only secure versions of BFCP are used = with ICE and only allow ICE usage for UDP/DTLS/BFCP and TCP/DTLS/BFCP.

 

To conclude, I would argue that = the simplest solution would be that for all protocols implemented on top = of ICE, UDP MUST be supported and default candidates MUST be UDP based. = This avoids building uncomfortable artificial constructs to avoid ICE mismatch and requires minimal changes to existing = specifications.

 

Regards,

_____________
Roman Shpount


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

= --Apple-Mail=_FCD11268-A7C3-4EED-8FFB-B12215DC4799-- From nobody Thu Nov 17 18:14:02 2016 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 9A1971299F6 for ; Thu, 17 Nov 2016 18:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1Kf-YpS-Cfq for ; Thu, 17 Nov 2016 18:13:43 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7788A1299F4 for ; Thu, 17 Nov 2016 18:13:40 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id n204so246857410qke.2 for ; Thu, 17 Nov 2016 18:13:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dV/qmnlO2+OPkoqFfjqH+Gal6URXXR+yGtlOYbLAltA=; b=Usuij8RpHaq3fAexrFlQZVicD7csoHPSd8Sl+L5Gmf2LvT9RPmyUCpuQfHIaPnqXcq 459dV1iRqeyenY0K3vdoGIwe9MPQR2vfAJ3SsJNP/DExs+X9SPPOnkw9N3zclJoFZBaE VkpVbPKso2wbgigC9DmGDeUPlcKenexaJh806aOKp9swNyvoPGUGovo6lTaS/qoh4Z6r kdbZ3Cf72koqF5HUC8ngEhaI2cuIslN9vFrU5/ZUPFlvYhCew92LriXYc5XVkX6lBYjN cnISgSU7f1eQSHOdNcEJOVFRQT1hvcHifk/eRCCXGv/zLfUwzWh7qkzGPldYs9AuxnPL fyuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dV/qmnlO2+OPkoqFfjqH+Gal6URXXR+yGtlOYbLAltA=; b=HB+ymmn/aD76Y+Q1lmq/untFiNe/yiUSNbI9Q4FHE8CUNM5rIz4RgTzZOCoMX+sPle ruQg0MfRmpHVj/WqE5z5q2bU1/lV6jHjTKEzAVRaCjdgclGFIxQSC8zj0h5bqNqzrfFV 9lu0BMF1AeCPUiO1YIKsIJLJEMJ8u429BqZTmD9cOkHulis3qdoBYx3igci8QIOe3cF4 yHzNYvk++6aJ2DytVpbgmYXiVLnPWieCAjHp/r2Tip7ixfu/r9VJCZiJYiL9ZLON+Ouo Rbk/wrIM7iCJq1Psn+7ZYiGCiJkYxFEsTfSs+RkT48Fi8rYIS1XuKqADUBKA6ywKj7Mj StKQ== X-Gm-Message-State: AKaTC01c+zXH1mMMoVGYu24yXNnH7ARwfUnzwrg285w2efYfD39LxAZgYccXBnRC3mBu7g== X-Received: by 10.55.41.159 with SMTP id p31mr7477348qkp.212.1479435219548; Thu, 17 Nov 2016 18:13:39 -0800 (PST) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com. [209.85.220.171]) by smtp.gmail.com with ESMTPSA id p19sm2953796qte.23.2016.11.17.18.13.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 18:13:39 -0800 (PST) Received: by mail-qk0-f171.google.com with SMTP id x190so246222065qkb.0; Thu, 17 Nov 2016 18:13:39 -0800 (PST) X-Received: by 10.55.97.204 with SMTP id v195mr7461859qkb.158.1479435216426; Thu, 17 Nov 2016 18:13:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.135.243 with HTTP; Thu, 17 Nov 2016 18:13:35 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> From: Roman Shpount Date: Thu, 17 Nov 2016 21:13:35 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan Ford Content-Type: multipart/alternative; boundary=94eb2c05c7ca8b226c054189da93 Archived-At: Cc: bfcpbis@ietf.org, ice@ietf.org, "mmusic@ietf.org" , Christer Holmberg Subject: Re: [Ice] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 02:13:45 -0000 --94eb2c05c7ca8b226c054189da93 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, There are three comments I wanted to make regarding general nature of all existing protocols designed to work ICE 1. Protocols running on top of ICE assume that regardless what candidate pair is used, including tcp candidates, the underlying network transport is unordered and unreliable. During nomination, including continuous nomination, candidate pairs can switch, including switching from udp to tcp or from tcp to udp. This typically means that protocol re-transmit timers are operational, packets are re-ordered at the protocol level, and UDP-friendly packet sizes are used even when packets are sent over tcp candidates. For instance DTLS and SCTP re-transmit timers, reordering, and fragmentation support are still running when tcp candidates are used. 2. Protocols do not assume that particular candidate network transport runs all the way from origination to final destination of the protocol packets. For instance there are SBC which only handle ICE. These SBC run the ICE state machine and then transmit the underlying protocol data to the final destination using public IP. Because of this, it is not unusual for RTP to run over tcp candidate until SBC and then run over UDP to the final destination. This is one more reason why re-transmit timers and other mechanisms used to deal with UDP are still running over tcp candidates. 3. I am not aware of any current protocol running over ICE tcp candidates which is not using RFC4571 framing. For instance DTLS could have been implemented using DTLS protocol framing without RFC4571 over tcp candidates, but this was not the case. This is partially done to simplify implementation of SBC which terminate ICE and transmit protocol data using UDP. By using RFC 4571 framing, SBC can packetize/de-packetize data transmitted over tcp candidates without knowing protocol details. To conclude, up until this point ICE tcp candidates were not treated as reliable transport and served simply as another way to transmit UDP packets through firewalls. Because of this, I would argue that BFCP running over tcp candidate is not the same as TCP/BFCP, in the same way as DTLS running over tcp candidate is not TLS. I would also argue that any protocol running over ICE is, in essence, a UDP based protocol, using tcp candidates only as a fall back mechanism for firewall traversal, same way as when data is relayed over TURN TCP, it is still considered sent over UDP at the protocol level. If ICE group agrees, I think this should be documented by saying that UDP is a MUST implement for any protocol using ICE and that default candidate should be UDP based. Regards, _____________ Roman Shpount On Thu, Nov 17, 2016 at 8:14 PM, Alan Ford wrote: > Adding bfcpbis. > > You raise a good point Roman - there=E2=80=99s no definition of how to ac= tually > use ICE with BFCP at the protocol level - this only came up in some very > late reviews of 4582bis. The initial suggestion was to use the same text = as > in draft-ietf-mmusic-sctp-sdp-19, but it then raised the point that, > given BFCP does not have a MTI protocol, if the offerer supported both th= ey > would include their preferred option, but if the receiver supported the > other variant, there=E2=80=99s no way to immediately negotiate that witho= ut a > re-INVITE. > > Christer=E2=80=99s suggestion to relax the requirement that the m-line pr= otocol *in > the answer* matches one of the ICE candidates would support the case > where the offerer supports both but prefers UDP, but the answerer only > supports TCP. Although no implementations currently do ICE here, this > relaxation would leave the door open to gaining this negotiation > flexibility in bfcpbis implementations. There seems no reason to have thi= s > requirement applied to the answer in the first place. > > I don=E2=80=99t understand the comment about SBCs; today, tcp candidates = are used > for media and data channels end-to-end in WebRTC, to name but one > implementation. > > Regards, > Alan > > On 17 Nov 2016, at 03:05, Roman Shpount wrote: > > Adding ICE group to this message. > > The approach always was that tcp candidates can potentially go only as fa= r > as SBC and then be terminated by UDP transport. Because of this everythin= g > transmitted over tcp candidate was still considered to be transmitted ove= r > the unreliable out-of-order transport. It is also assumed that candidates > can switch from UDP to TCP based candidate during nomination. This is why= , > for instance, we run DTLS with RFC4571 framing over tcp candidates, not > TLS. Because of this I always thought that ICE is UDP first with addition= al > TCP transports for situation when UDP will not work. So, as a result, I > think ICE-bis should specify that UDP MUST be supported and default > candidate MUST be UDP. ICE SDP can reflect this, but I think this is the > underlying protocol requirement. > > I also wanted to add that BFCP needs to examine how ICE support is > implemented by this protocol. I think it is not covered in the current > drafts. I also think I do not think it is possible for TCP/BFCP to run ov= er > ICE. On the other hand UDP/DTLS/BFCP and TCP/DTLS/BFCP would trivial base= d > on current DTLS work. > > Regards, > _____________ > Roman Shpount > > On Wed, Nov 16, 2016 at 8:44 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> I have no problem with Roman=E2=80=99s must-support-UDP suggestion. I gu= ess the >> question is whether the BFCP folks could accept that. Cullen did say tha= t >> TCP-based BFCP deployments have been around for a decade. But, do they >> support ICE? >> >> >> >> If we decide to move forward with such approach, we need to ask ourselve= s >> whether must-support-UDP should be an ICE requirement (in which case the >> suggestion should be brought to the ICE WG) or whether it should only be= an >> ICE-using-SIP-SDP requirement. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Roman >> Shpount >> *Sent:* 17 November 2016 00:52 >> *To:* mmusic@ietf.org >> *Subject:* [MMUSIC] m=3D line protocol in case of ICE >> >> >> >> Hi All, >> >> >> >> I just wanted to return to the m=3D line protocol issue that Christer >> raised during the last MMUSIC session. >> >> >> >> All the ICE implementations I've seen are primarily UDP based with >> support for tcp host candidates which are primarily used to connect to e= nd >> points on public IP. If all ICE implementations are continue to be >> primarily UDP based, then the simplest solution would be to require UDP >> support when any given protocol is implemented over ICE. DTLS and RTP ar= e >> already primarily UDP based so this is a non-requirement. Even more, all >> protocols that are implemented on top of ICE must assume that underling >> transports (including tcp candidates) are unreliable, since candidate pa= ir >> can change at any time between reliable and unreliable transports, so th= is >> makes them different from protocols implemented on plain TCP or TLS. >> >> >> >> So the first question I wanted to ask is anybody interested in TCP only >> ICE implementation where the protocol running on top of such implementat= ion >> relies on the reliable delivery of underlying messages? By this I mean, >> does anybody wants implement TCP based ICE, with simultaneous open, >> reflexive and relay candidates in such a way that ICE implementation wil= l >> run from behind NAT without ever needing a UDP candidate? >> >> >> >> I understand that BFCP was used for a long time, but I do not think >> TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I think only UDP/BFC= P, >> UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE. >> >> >> >> I think both rfc4582bis and rfc4583bis need a careful review and >> additional sections that describe ICE considerations. I think the most >> obvious thing would be to specify that ICE can only be supported by >> UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which ca= se >> RFC4571 is used when tcp candidates are used. Furthermore, when tcp >> candidate is selected with UDP/BFCP transport, it is not the same thing = as >> using TCP/BFCP and will need a different transport tag (something like >> TCP/UDP/BFCP). Alternatively we can require that only secure versions of >> BFCP are used with ICE and only allow ICE usage for UDP/DTLS/BFCP and >> TCP/DTLS/BFCP. >> >> >> >> To conclude, I would argue that the simplest solution would be that for >> all protocols implemented on top of ICE, UDP MUST be supported and defau= lt >> candidates MUST be UDP based. This avoids building uncomfortable artific= ial >> constructs to avoid ICE mismatch and requires minimal changes to existin= g >> specifications. >> >> >> >> Regards, >> >> _____________ >> Roman Shpount >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --94eb2c05c7ca8b226c054189da93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

There are three comments = I wanted to make regarding general nature of all existing protocols designe= d to work ICE

1. Protocols running on top of ICE assume = that regardless what candidate pair is used, including tcp candidates, the = underlying network transport is unordered and unreliable. During nomination= , including continuous nomination, candidate pairs can switch, including sw= itching from udp to tcp or from tcp to udp. This typically means that proto= col re-transmit timers are operational, packets are re-ordered at the proto= col level, and =C2=A0UDP-friendly packet sizes are used even when packets a= re sent over tcp candidates. For instance DTLS and SCTP re-transmit timers,= reordering, and fragmentation support are still running when tcp candidate= s are used.

2. Protocols do not assume that partic= ular candidate network transport runs all the way from origination to final= destination of the protocol packets. For instance there are SBC which only= handle ICE. These SBC run the ICE state machine and then transmit the unde= rlying protocol data to the final destination using public IP. Because of t= his, it is not unusual for RTP to run over tcp candidate until SBC and then= run over UDP to the final destination. This is one more reason why re-tran= smit timers and other mechanisms used to deal with UDP are still running ov= er tcp candidates.

3. I am not aware of any curren= t protocol running over ICE tcp candidates which is not using RFC4571 frami= ng. For instance DTLS could have been implemented using DTLS protocol frami= ng without RFC4571 over tcp candidates, but this was not the case. This is = partially done to simplify implementation of SBC which terminate ICE and tr= ansmit protocol data using UDP. By using RFC 4571 framing, SBC can packetiz= e/de-packetize data transmitted over tcp candidates without knowing protoco= l details.

To conclude, up until this point ICE tc= p candidates were not treated as reliable transport and served simply as an= other way to transmit UDP packets through firewalls. Because of this, I wou= ld argue that BFCP running over tcp candidate is not the same as TCP/BFCP, = in the same way as DTLS running over tcp candidate is not TLS.
I would also argue that any protocol running over ICE is, in e= ssence, a UDP based protocol, using tcp candidates only as a fall back mech= anism for firewall traversal, same way as when data is relayed over TURN TC= P, it is still considered sent over UDP at the protocol level.
If ICE group agrees, I think this should be documented by sayi= ng that UDP is a MUST implement for any protocol using ICE and that default= candidate should be UDP based.

Regards,
_____________
Roman= Shpount

On Thu, Nov 17, 2016 at 8:14 PM, Alan Ford <= span dir=3D"ltr"><alan.ford@gmail.com> wrote:
Adding bfcpbis.<= div>
You raise a good point Roman - there=E2=80=99s no defini= tion of how to actually use ICE with BFCP at the protocol level - this only= came up in some very late reviews of 4582bis. The initial suggestion was t= o use the same text as in=C2=A0draft-ietf-mmusic-sctp-sdp-19, but it t= hen raised the point that, given BFCP does not have a MTI protocol, if the = offerer supported both they would include their preferred option, but if th= e receiver supported the other variant, there=E2=80=99s no way to immediate= ly negotiate that without a re-INVITE.

Christer=E2= =80=99s suggestion to relax the requirement that the m-line protocol in = the answer=C2=A0matches one of the ICE candidates would support the cas= e where the offerer supports both but prefers UDP, but the answerer only su= pports TCP. Although no implementations currently do ICE here, this relaxat= ion would leave the door open to gaining this negotiation flexibility in bf= cpbis implementations. There seems no reason to have this requirement appli= ed to the answer in the first place.

I don=E2=80= =99t understand the comment about SBCs; today, tcp candidates are used for = media and data channels end-to-end in WebRTC, to name but one implementatio= n.

Regards,
Alan

On 17 No= v 2016, at 03:05, Roman Shpount <roman@telurix.com> wrote:

Adding ICE group to this message.

The approach always was that tcp candidates can potential= ly go only as far as SBC and then be terminated by UDP transport. Because o= f this everything transmitted over tcp candidate was still considered to be= transmitted over the unreliable out-of-order transport. It is also assumed= that candidates can switch from UDP to TCP based candidate during nominati= on. This is why, for instance, we run DTLS with RFC4571 framing over tcp ca= ndidates, not TLS. Because of this I always thought that ICE is UDP first w= ith additional TCP transports for situation when UDP will not work. So, as = a result, I think ICE-bis should specify that UDP MUST be supported and def= ault candidate MUST be UDP. ICE SDP can reflect this, but I think this is t= he underlying protocol requirement.

I also wanted to add= that BFCP needs to examine how ICE support is implemented by this protocol= . I think it is not covered in the current drafts. I also think I do not th= ink it is possible for TCP/BFCP to=C2=A0run over ICE. On the other hand UDP= /DTLS/BFCP and TCP/DTLS/BFCP would trivial based on current DTLS work.
<= div>

Regards= ,
_____________
Roman Shpount

On Wed, Nov 16, 2016 at 8:44 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wr= ote:

I have no problem with Roman=E2=80=99= s must-support-UDP suggestion. I guess the question is whether the BFCP fol= ks could accept that. Cullen did say that TCP-based BFCP deployments have been around for a decade. But= , do they support ICE?

= =C2=A0

If we decide to move= forward with such approach, we need to ask ourselves whether must-support-= UDP should be an ICE requirement (in which case the suggestion should be brought to the ICE WG) or whether it s= hould only be an ICE-using-SIP-SDP requirement.

=C2=A0

Regards,

=C2=A0

Christer

= =C2=A0

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 17 November 2016 00:52
To: mmusic@ietf= .org
Subject: [MMUSIC] m=3D line protocol in case of ICE

=C2=A0

Hi All,

=C2=A0

I just wanted to return to the m=3D line protoc= ol issue that Christer raised during the last MMUSIC session.=

=C2=A0

All the ICE implementations I've seen are p= rimarily UDP based with support for tcp host candidates which are primarily= used to connect to end points on public IP. If all ICE implementations are= continue to be primarily UDP based, then the simplest solution would be to require UDP support when any given protocol = is implemented over ICE. DTLS and RTP are already primarily UDP based so th= is is a non-requirement. Even more, all protocols that are implemented on t= op of ICE must assume that underling transports (including tcp candidates) are unreliable, since candidate pair= can change at any time between reliable and unreliable transports, so this= makes them different from protocols implemented on plain TCP or TLS.

=C2=A0

So the first question I wanted to ask is anybod= y interested in TCP only ICE implementation where the protocol running on t= op of such implementation relies on the reliable delivery of underlying mes= sages? By this I mean, does anybody wants implement TCP based ICE, with simultaneous open, reflexive and relay candi= dates in such a way that ICE implementation will run from behind NAT withou= t ever needing a UDP candidate?

=C2=A0

I understand that BFCP was used for a long time= , but I do not think TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I = think only UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE.= =C2=A0

=C2=A0

I think both=C2=A0rfc4582bis and rfc4583bis nee= d a careful review and additional sections that describe ICE considerations= . I think the most obvious thing would be to specify that ICE can only be s= upported by UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which case RFC4571 is used when tcp candidates are us= ed. Furthermore, when tcp candidate is selected with UDP/BFCP transport, it= is not the same thing as using TCP/BFCP and will need a different transpor= t tag (something like TCP/UDP/BFCP). Alternatively we can require that only secure versions of BFCP are used wi= th ICE and only allow ICE usage for UDP/DTLS/BFCP and TCP/DTLS/BFCP.=

=C2=A0

To conclude, I would argue that the simplest so= lution would be that for all protocols implemented on top of ICE, UDP MUST = be supported and default candidates MUST be UDP based. This avoids building= uncomfortable artificial constructs to avoid ICE mismatch and requires minimal changes to existing specifications= .

=C2=A0

Regards,

_____________
Roman Shpount


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


--94eb2c05c7ca8b226c054189da93-- From nobody Fri Nov 18 03:41:10 2016 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 8A1AD129615 for ; Fri, 18 Nov 2016 03:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRlLxwT3gx-F for ; Fri, 18 Nov 2016 03:41:07 -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 E895A1294F3 for ; Fri, 18 Nov 2016 03:41:06 -0800 (PST) X-AuditID: c1b4fb2d-48ecb98000000994-82-582ee8d0dc52 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 77.E8.02452.0D8EE285; Fri, 18 Nov 2016 12:41:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Fri, 18 Nov 2016 12:40:47 +0100 From: Christer Holmberg To: Nils Ohlmeier Thread-Topic: [Ice] Triggered checks are missing peer reflexive - pull request Thread-Index: AdJBkJiK/dT1pdyQSP2z1otjNVEw6w== Date: Fri, 18 Nov 2016 11:40:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE3D7A5@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM2J7oO7FF3oRBqv72Sy+Xai1uD5vMqMD k8eSJT+ZPPoOdLEGMEVx2aSk5mSWpRbp2yVwZeyZtpC1YIFbxfnNnxgbGHe4dDFyckgImEhM Wf2UHcQWEljHKPF/hlAXIxeQvYRRYtqWP0AJDg42AQuJ7n/aIKaIgKbEiY18ICazgKLEy71q IJ3CAr4Sc+bPYQKxRQQCJE7e3MUGYetJ3L/7gRXEZhFQlej/uJ8ZxOYFqv+18yXYVkYBMYnv p9aA9TILiEvcejKfCeIyAYkle84zQ9iiEi8f/2OFsJUkGpc8YYU4QVNi/S59iFZFiSndD9kh xgtKnJz5hGUCo/AsJFNnIXTMQtIxC0nHAkaWVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiB oX5wy2/dHYyrXzseYhTgYFTi4TX4pxshxJpYVlyZe4hRgoNZSYRX5blehBBvSmJlVWpRfnxR aU5q8SFGaQ4WJXFes5X3w4UE0hNLUrNTUwtSi2CyTBycUg2M0YESj9ZemcbT0zMz2TfjooXt xGnnEk+8rZZaZHJm4Urm++suCXBNU1L5vDN4WX7B9asfP768WzJR3rgpaVaGR3JnpZFWnJVq ZVDYUZvXD62dTJu+qM27OElr3cGApSKS2Tvs+KyORs/oYDkmszJU/dO7OYv/2vzUlfvclCrF uSewS/H7yasaSizFGYmGWsxFxYkARrY1WXECAAA= Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Triggered checks are missing peer reflexive - pull request X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 11:41:09 -0000 SGksDQoNCkkndmUgY3JlYXRlZCBhIHB1bGwgcmVxdWVzdCBmb3IgdGhpczoNCg0KaHR0cHM6Ly9n aXRodWIuY29tL2ljZS13Zy9yZmM1MjQ1YmlzL3B1bGwvMjINCg0KTm93LCBpbnN0ZWFkIG9mICJz ZXJ2ZXIgcmVmbGV4aXZlIiwgdGhlIHRleHQgc2F5cyB0aGF0IHBydW5pbmcgaXMgZG9uZSBmb3Ig InJlZmxleGl2ZSIgY2FuZGlkYXRlcywgd2hpY2ggaW5jbHVkZXMgYm90aCBwZWVyLSBhbmQgc2Vy dmVyIHJlZmxleGl2ZS4gQnV0LCBpZiB3ZSB0aGluayB0aGF0IGFsc28gbm9uLXJlZmxleGl2ZSBj YW5kaWRhdGVzIHNoYWxsIGJlIHBydW5lZCwgSSB3aWxsIG1ha2UgdGhlIHRleHQgZXZlbiBtb3Jl IGdlbmVyaWMuDQoNCkFzIHlvdSBjYW4gc2VlLCBJIGRvbid0IG9ubHkgc2F5IHRoYXQgdGhlIHBy dW5pbmcgaXMgZG9uZSB3aGVuIGEgY2hlY2sgbGlzdCBpcyB1cGRhdGVkLCBidXQgYWxsIHByb2Nl ZHVyZXMgKGZvcm1pbmcgcGFpcnMgZXRjKS4NCg0KSW4gYWRkaXRpb24sIEkgYWRkZWQgdGhlIHRl eHQgb24gcmVtb3ZpbmcgbG93ZXItcHJpb3JpdHkgY2FuZGlkYXRlcyBpbnRvIGEgc2VwYXJhdGUg c2VjdGlvbi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IE5pbHMgT2hsbWVpZXIgW21haWx0bzpub2hsbWVpZXJAbW96aWxsYS5jb21d IA0KU2VudDogMTYgTm92ZW1iZXIgMjAxNiAwMzoxNg0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogaWNlQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW0ljZV0gVHJpZ2dlcmVkIGNoZWNrcyBhcmUgbWlzc2luZyBwZWVyIHJlZmxleGl2ZQ0K DQoNCj4gT24gTm92IDE1LCAyMDE2LCBhdCAxNzowOSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+PiANCj4+IFllcyBJIHRoaW5rIGl0 IHdvdWxkIGJlIGhlbHAgdG8gYnJvYWRlbiB0aGUgc2NvcGUgb2YgcHJ1bmluZyBsaWtlIHRoYXQu IFNvIEkgd291bGQgdm90ZSBmb3IgQWx0ICMyIGZyb20geW91ciBzbGlkZXMgaW4gU2VvdWwuDQo+ PiANCj4+IEFsdGhvdWdoIEkgZ3Vlc3MgdGhlIHJlYWwgcmVhc29uIHdoeSBwcnVuaW5nIGRvZXMg bm90IG1lbnRpb24gcGVlciByZWZsZXhpdmUgaXMgdGhhdCB0aGUgdmFsaWQgcGFpciB3aGljaCBy ZXN1bHRlZCBmcm9tIHRoZSBwZWVyIHJlZmxleGl2ZSBkaXNjb3ZlcnkgbmV2ZXIgZW50ZXJzIHRo ZSBjaGVjayA+IGxpc3QsIGFuZCBwcnVuaW5nIG9ubHkgYXBwbGllcyB0byB0aGUgY2hlY2sgbGlz dCwgYnV0IG5vdCB0aGUgdmFsaWQgbGlzdC4gSSBndWVzcyB0aGlzIG1ha2VzIHRoZSB3aG9sZSB0 b3BpYyB2b2lkPyENCj4gDQo+IEl0IGlzIHRydWUgdGhhdCB0aGUgSU5JVElBTCBjaGVjayBsaXN0 IGRvZXMgbm90IGNvbnRhaW4gcGVlciByZWZsZXhpdmUgY2FuZGlkYXRlcy4gQnV0LCB0aGUgc3Bl YyBzYXlzIHRoYXQsIG9uY2UgcGVlciByZWZsZXhpdmUgY2FuZGlkYXRlcyBhcmUgZGV0ZWN0ZWQs IHRoZSBjaGVjayBsaXN0IE1BWSBiZSB1cGRhdGVkIChhbmQgc2VudCB0byB0aGUgcGVlcikgd2l0 aCB0aG9zZSBjYW5kaWRhdGVzLiBXaGVuIHN1Y2ggdXBkYXRlIG9jY3VycywgSSBhc3N1bWUgdGhl IGNoZWNrIGxpc3Qgd2lsbCBiZSBwcnVuZWQgYWdhaW4gLSBldmVudGhvdWdoIHRoYXQgaXMgY3Vy cmVudGx5IG5vdCBleHBsaWNpdGx5IHNhaWQgaW4gdGhlIHNwZWMgYWZhaWsgKGl0IHdvdWxkIHBy b2JhYmx5IGJlIGdvb2QgdG8gYWRkIHRleHQgYWJvdXQgdGhhdCkuDQoNCk5vdyBJIGdvdCBpdC4N ClllcyBmb3IgdGhlIHNwZWNpYWwgY2FzZSBvZiB1cGRhdGluZyBhbmQgc2VuZGluZyB5b3VyIG5l dyBsaXN0IHRvIHRoZSBwZWVyIHlvdSBzaG91bGQgcHJ1bmUgdGhhdCBiZWZvcmUgaGFuZGluZyBp dCBvdXQuIFByb2JhYmx5IHdvdWxkIGJlIGdvb2QgdG8gbWVudGlvbiB0aGF0IGV4cGxpY2l0bHkg aW4gdGhhdCBwYXJhZ3JhcGguDQoNCkJlc3QNCiAgTmlscw0KDQo+IA0KPiANCj4gDQo+Pj4gT24g T2N0IDQsIDIwMTYsIGF0IDAyOjU4LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+PiANCj4+PiBIaSBOaWxzLA0KPj4+IA0KPj4+IFNv cnJ5IGZvciB0aGUgbGF0ZSByZXBseS4NCj4+PiANCj4+PiBJZiBJIHVuZGVyc3RhbmQgdGhlIGlz c3VlIGNvcnJlY3RseSwgdGhpcyBjb3VsZCBvbmx5IGhhcHBlbiB3aXRoIHRyaWNrbGUuDQo+Pj4g QmVjYXVzZSwgaW4gbm9ybWFsIGNhc2VzIHBydW5pbmcgd291bGQgdGFrZSBjYXJlIG9mIGl0Lg0K Pj4+IA0KPj4+IE9yPw0KPj4+IA0KPj4+IFJlZ2FyZHMsDQo+Pj4gDQo+Pj4gQ2hyaXN0ZXINCj4+ PiANCj4+PiBPbiAyMC8wOS8xNiAwNjo0NiwgIkljZSBvbiBiZWhhbGYgb2YgTmlscyBPaGxtZWll ciIgDQo+Pj4gPGljZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBub2hsbWVpZXJAbW96 aWxsYS5jb20+IHdyb3RlOg0KPj4+IA0KPj4+PiBBZnRlciByZWFkaW5nIHVwIG9uIGhvdyB0aGUg Y3VycmVudCBUcmlja2xlIElDRSBkcmFmdCBwcm9wb3NlcyB0byANCj4+Pj4gaGFuZGxlIHBlZXIg cmVmbGV4aXZlIGNhbmRpZGF0ZXMgaXQgYXBwZWFycyB0byBtZSB0aGF0IG15IHNjZW5hcmlvIA0K Pj4+PiBiZWxvdyBpcyByZWxldmFudCBmb3IgSUNFIDUyNDViaXMgaWYgdGhlcmUgaXMgbm8gU1RV TiBzZXJ2ZXIuDQo+Pj4+IEFuZCBpZiB0aGVyZSBpcyBhIFNUVU4gc2VydmVyIHRoZW4gaXQgc2hv dWxkIG9ubHkgaGFwcGVuIGlmIEIgaGFzIA0KPj4+PiB0cmlja2xlZCBoaXMgcHVibGljIGhvc3Qg Y2FuZGlkYXRlIHRvIEEgYWxyZWFkeS4gQW5kIEEgcmVjZWl2ZXMgaXRzIA0KPj4+PiBiaW5kaW5n IHJlc3BvbnNlIGZyb20gQiBiZWZvcmUgaXQgZGlzY292ZXJzIGhpcyBvd24gc2VydmVyIA0KPj4+ PiByZWZsZXhpdmUgYnkgcmVjZWl2aW5nIGEgYmluZGluZyByZXNwb25zZSBmcm9tIHRoZSBTVFVO IHNlcnZlci4NCj4+Pj4gDQo+Pj4+IEV2ZW4gaWYgd2UgZG9uwrl0IGJvdGhlciBkbyB0cnkgdG8g b3B0aW1pemUgdGhlIHVzZWxlc3MvcmVkdW5kYW50IA0KPj4+PiB0cmlnZ2VyIGNoZWNrIGF3YXkg SSB0aGluayB3ZSBzaG91bGQ6DQo+Pj4+IC0gaW5jbHVkZSBwZWVyIHJlZmxleGl2ZSBjYW5kaWRh dGVzIGludG8gdGhlIHBhcmFncmFwaCBvZiA1MjQ1IA0KPj4+PiB3aGljaCB0YWxrcyBhYm91dCB0 cmlnZ2VyIGNoZWNrcw0KPj4+PiAtIGV4dGVuZCB0aGUgcGFyYWdyYXBoIGluIHRoZSB0cmlja2xl IGRyYWZ0IHRvIG5vdCBvbmx5IG1lbnRpb24gDQo+Pj4+IGRpc2NvdmVyaW5nIHBlZXIgcmVmbGV4 aXZlIGNhbmRpZGF0ZXMgdmlhIFNUVU4gYmluZGluZyByZXF1ZXN0LCBidXQgDQo+Pj4+IGFsc28g ZnJvbSBiaW5kaW5nIHJlc3BvbnNlcy4NCj4+Pj4gDQo+Pj4+IEkgd291bGQgYXBwcmVjaWF0ZSBz b21lIGZlZWRiYWNrIG9uIHRoaXMgYmVmb3JlIHRyeWluZyB0byBwcm9wb3NlIA0KPj4+PiBpbXBy b3ZlZCB3b3JkaW5nIGZvciBib3RoIHNwZWNzLg0KPj4+PiANCj4+Pj4gQmVzdA0KPj4+PiBOaWxz IE9obG1laWVyDQo+Pj4+IA0KPj4+Pj4gT24gU2VwIDIsIDIwMTYsIGF0IDEzOjM0LCBOaWxzIE9o bG1laWVyIDxub2hsbWVpZXJAbW96aWxsYS5jb20+IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+PiBIZWxs bywNCj4+Pj4+IA0KPj4+Pj4gSSBoYXZlIGlkZW50aWZpZWQgc29tZXRoaW5nIHdoaWNoIEkgd291 bGQgYmUgaW50ZXJlc3RlZCB0byBoZWFyIA0KPj4+Pj4gdGhlIG9waW5pb25zIG9mIHRoZSBJQ0Ug ZXhwZXJ0cyBhYm91dC4NCj4+Pj4+IA0KPj4+Pj4gSW4gUkZDIDUyNDUgKHNlY3Rpb24gNy4yLjEu NCkgYW5kIGFsc28gaW4gYmlzLTA0IChzZWN0aW9uDQo+Pj4+PiA2LjEuMy4xLjQpIGNsYWltIHRo ZSBmb2xsb3dpbmcgcmVnYXJkaW5nIHJlY2VpdmluZyB0cmlnZ2VyZWQgY2hlY2tzOg0KPj4+Pj4g VGhlIGxvY2FsIGNhbmRpZGF0ZSB3aWxsIGVpdGhlciBiZSBhIGhvc3QgY2FuZGlkYXRlICguLi4p IG9yIGEgDQo+Pj4+PiByZWxheWVkIGNhbmRpZGF0ZSAoxaApLiBUaGUgbG9jYWwgY2FuZGlkYXRl IGNhbiBuZXZlciBiZSBhIHNlcnZlciANCj4+Pj4+IHJlZmxleGl2ZSBjYW5kaWRhdGUuDQo+Pj4+ PiANCj4+Pj4+IFdoaWNoIEkgdGhpbmsgaXMgbWlzc2luZyB0aGUgY2FzZSB3aGVyZSB0aGUgbG9j YWwgY2FuZGlkYXRlIGNhbiANCj4+Pj4+IGFsc28gYSBiZSBhIHBlZXIgcmVmbGV4aXZlLiBBbmQg dGhpcyBpcyBhY3R1YWxseSBjYXVzaW5nIA0KPj4+Pj4gdW5uZWNlc3NhcnkgZXh0cmEgY2hlY2tz IHRvIGJlIG1hZGUuDQo+Pj4+PiANCj4+Pj4+IENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgc2NlbmFy aW86DQo+Pj4+PiANCj4+Pj4+IC0gQSBzaXRzIGJlaGluZCBzeW1tZXRyaWMgTkFUDQo+Pj4+PiAt IEIgaXMgb24gYSBwdWJsaWNseSByb3V0YWJsZSBhZGRyZXNzIHdpdGggbm8gTkFUIG9yIGZpcmV3 YWxsDQo+Pj4+PiAtIE5vIFNUVU4gc2VydmVycyAoanVzdCBtYWtlcyB0aGUgc2NlbmFyaW8gbGVz cyBjb21wbGV4KQ0KPj4+Pj4gLSBIb3N0IGNhbmRpZGF0ZXMgZ2V0IGV4Y2hhbmdlZCAgYW5kIGNh bmRpZGF0ZSBwYWlycyBBOkIgYW5kIEI6QSANCj4+Pj4+IGdldCBjcmVhdGVkIG9uIGJvdGggc2lk ZXMNCj4+Pj4+IC0gQSBzZW5kcyBiaW5kaW5nIHJlcXVlc3QgdG8gQg0KPj4+Pj4gLSBCIHJlY2Vp dmVzIGJpbmRpbmcgcmVxdWVzdCB3aXRoIHRyYW5zcG9ydCBhZGRyZXNzIEHCuQ0KPj4+Pj4gLSBC IGNyZWF0ZXMgYSBwZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGUgZm9yIEHCuSBhbmQgdGhlIGEgbmV3 IHBhaXIgDQo+Pj4+PiBCOkHCuSBhbmQgcHV0cyB0aGF0IG5ldyBwYWlyIGludG8gaXRzIHRyaWdn ZXIgY2hlY2sgcXVldWUNCj4+Pj4+IC0gQiBzZW5kcyBiaW5kaW5nIHJlc3BvbnNlIHRvIEHCuQ0K Pj4+Pj4gLSBBIHJlY2VpdmVzIGJpbmRpbmcgcmVzcG9uc2UsIGxlYXJucyBhYm91dCBBwrkgYW5k IGNyZWF0ZXMgQcK5OkIgDQo+Pj4+PiBhbmQgbWFya3MgaXQgYXMgc3VjY2Vzc2Z1bA0KPj4+Pj4g LSBOb3cgQiBzZW5kcyBhIGJpbmRpbmcgcmVxdWVzdCBmb3IgaXQgdHJpZ2dlciBjaGVjayBxdWV1 ZSBlbnRyeSANCj4+Pj4+IHRvIEHCuQ0KPj4+Pj4gLSBXaGVuIEEgcmVjZWl2ZXMgdGhpcyBiaW5k aW5nIHJlcXVlc3QgaXMgaGFzIG5vIHdheSB0byBtYXRjaCB0aGlzIA0KPj4+Pj4gdG8gdGhlIHN1 Y2Nlc3NmdWwgcGFpciBBwrk6Qg0KPj4+Pj4gLSBCZWNhdXNlIG9mIHRoZSB3b3JkaW5nIGluIHRo ZSBhYm92ZSBtZW50aW9uZWQgc2VjdGlvbnMgaXQgd2lsbCANCj4+Pj4+IG1hdGNoIHRoZSByZXF1 ZXN0IHRvIHRoZSBwYWlyIEE6Qg0KPj4+Pj4gLSBXaGljaCB0aGVuIGluIHR1cm4gY2F1c2VzIGFu b3RoZXIgdHJpZ2dlcmVkIGNoZWNrIHRvIGJlIGNyZWF0ZWQgDQo+Pj4+PiBiZWNhdXNlIEE6QiBp cyBub3QgaW4gdGhlIHN1Y2Nlc3Mgc3RhdGUNCj4+Pj4+IA0KPj4+Pj4gVGhpcyBhZGRpdGlvbmFs IHRyaWdnZXJlZCBjaGVjayBmcm9tIEEgaXMganVzdCB3YXN0ZSBvZiB0aW1lIGFuZCANCj4+Pj4+ IHJlc291cmNlcy4gSXQgZG9lcyBub3QgaHVydC4gQnV0IEnCuW0gd29uZGVyaW5nIGhvdyB0aGlz IGNvdWxkIGJlIGF2b2lkZWQuDQo+Pj4+PiANCj4+Pj4+IElmIHBlb3BsZSBhZ3JlZSBJIHRoaW5r IHNlY3Rpb24gNi4xLjMuMS40IHNob3VsZCBhdCBsZWFzdCBtZW50aW9uIA0KPj4+Pj4gdGhlIHNj ZW5hcmlvIHRoYXQgaW5jb21pbmcgYmluZGluZyByZXF1ZXN0cyBjYW4gYWxzbyBtYXRjaCBhIHBl ZXIgDQo+Pj4+PiByZWZsZXhpdmUgY2FuZGlkYXRlLg0KPj4+Pj4gDQo+Pj4+PiBBcyB0aGUgaW5j b21pbmcgYmluZGluZyByZXF1ZXN0IGRvZXMgbm90IGNvbnRhaW4gdGhlIGRlc3RpbmF0aW9uIA0K Pj4+Pj4gYWRkcmVzcyBpdCBnb3Qgc2VuZCB0byB0aGVyZSBpcyBvYnZpb3VzbHkgbm8gd2F5IGZv ciBBIHRvIGNsZWFybHkgDQo+Pj4+PiBkaXN0aW5ndWlzaCBpZiB0aGUgcmVxdWVzdCBnb3Qgc2Vu ZCB0byBBIG9yIEHCuS4NCj4+Pj4+IA0KPj4+Pj4gRm9yIGF2b2lkaW5nIHRoZSBhZGRpdGlvbmFs IHRyaWdnZXJlZCBjaGVjayBvbiBBwrlzIHNpZGUgdGhlIG9ubHkgDQo+Pj4+PiBzb2x1dGlvbiBJ IHNlZSByaWdodCBub3cgaXMgdG8gZ28gdGhyb3VnaCB0aGUgcGFpcnMgd2hpY2ggaGF2ZSBBIA0K Pj4+Pj4gYXMgdGhlaXIgZm91bmRhdGlvbiBhbmQgaWYgdGhhdCBsaXN0IGNvbnRhaW5zIGEgcGFp ciB3aGljaCBpcyANCj4+Pj4+IG1hcmtlZCBhcyBzdWNjZXNzZnVsIGFscmVhZHkgYXNzdW1lIG5v IHRyaWdnZXJlZCBjaGVjayBpcyBuZWVkZWQuIA0KPj4+Pj4gU28gZmFyIEkgaGF2ZSBub3QgYmVl biBhYmxlIHRvIGlkZW50aWZ5IGEgc2NlbmFyaW8gd2hlcmUgaXQgaHVydHMgDQo+Pj4+PiB0byBz a2lwIHRoaXMgZXh0cmEgcm91bmQgb2YgdHJpZ2dlcmVkIGNoZWNrcyBvbiBBwrlzIHNpZGUuDQo+ Pj4+PiANCj4+Pj4+IEJlc3QNCj4+Pj4+IE5pbHMgT2hsbWVpZXINCj4+Pj4+IA0KPj4+PiANCj4+ PiANCj4+IA0KPiANCg0K From nobody Fri Nov 18 04:07:58 2016 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 C6708129615 for ; Fri, 18 Nov 2016 04:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gwe1zhDTy-yz for ; Fri, 18 Nov 2016 04:07:55 -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 16A7A129609 for ; Fri, 18 Nov 2016 04:07:53 -0800 (PST) X-AuditID: c1b4fb2d-48ecb98000000994-87-582eef188f78 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 80.8E.02452.81FEE285; Fri, 18 Nov 2016 13:07:52 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Fri, 18 Nov 2016 13:07:52 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: NOMINATED vs SELECTED Thread-Index: AdJBk5IukpG3WEP8RAuuqWoy5t1HNw== Date: Fri, 18 Nov 2016 12:07:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE3D803@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE3D803ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM2K7tK7Ee70Ig2ddUhbfLtQ6MHosWfKT KYAxissmJTUnsyy1SN8ugSvj/uu3LAXdoRVL7xo2MDZ4dzFyckgImEh03+9l7GLk4hASWMco 0X6gnRnCWcIoceLOHtYuRg4ONgELie5/2iANIgKKEjNbnjGD2MIC6hIfW74zQsR1JHa8OsUM YetJfPi9nhGklUVAVeLxPDuQMK+Ar8St3zvZQGxGATGJ76fWMIHYzALiEreezGeCuEdAYsme 88wQtqjEy8f/WCFsJYnGJU9YIerzJXp/L2WBmCkocXLmE5YJjIKzkIyahaRsFpIyiLiOxILd n9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMOgPbvmt u4Nx9WvHQ4wCHIxKPLwG/3QjhFgTy4orcw8xSnAwK4nwXn+tFyHEm5JYWZValB9fVJqTWnyI UZqDRUmc12zl/XAhgfTEktTs1NSC1CKYLBMHp1QDY/Hd/4oeM/7snL7axKBXMHCbX1IA6/TL b8P3duRzaxW1ZrTp9f+YsXLHP98r0twxqz7zu979WGxbMa2er6zW/1VMT9Nt2cvibKnRk9kW 28wLm/uKo8BQomO72Xkh/kavtnnbZ3D9nL4zMjVvl/SXtWvjF88R/lckYT+TO72Fr7WQZ7aC ZsRRJZbijERDLeai4kQAk0QND3YCAAA= Archived-At: Subject: [Ice] 5245bis: NOMINATED vs SELECTED X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 12:07:58 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE3D803ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 2.6 says: "Consequently, ICE assigns one of the agents in the role of the CONTROLLING AGENT, and the other of the CONTROLLED AGENT. The controlling agent gets to nominate which candidate pairs will get used for media amongst the ones that are valid. When nominating, the controlling agent lets the checks continue until at least one valid candidate pair for each media stream is found. Then, it picks amongst those that are valid, and sends a second STUN request on its NOMINATED candidate pair, but this time with a flag set to tell the peer that this pair has been nominated for use. This is shown in Figure 4. Once the STUN transaction with the flag completes, both sides cancel any future checks for that media stream. ICE will now send media using this pair. The pair an ICE agent is using for media is called the SELECTED PAIR." Now, if I understand the text above correctly, the only difference between = NOMINATED and SELECTED is that SELECTED means that the nomination STUN tran= saction has succeeded. However, e.g., in section 5.1.3.4 is the following text: "Completed: In this state, ICE checks have produced nominated pairs for each component of the media stream." Q1: Shouldn't a check list be placed in Completed state once the nomination= procedure has actually succeeded, i.e., one ICE checks has produced SELECT= ED pairs? In addition, due to the previous nomination changes, I don't thin= k a check list is Completed just because a pair is nominated. Q2: Is there a need to separate between NOMINATED and SELECTED? Especially = with the removal of aggressive nomination, there may be multiple NOMINATED = pairs. Regards, Christer Completed: In this state, ICE checks have produced nominated pairs for each component of the media stream. --_000_7594FB04B1934943A5C02806D1A2204B4BE3D803ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 2.6 says:

 

   “Consequentl= y, ICE assigns one of the agents in the role of the

   CONTROLLING AGENT,= and the other of the CONTROLLED AGENT.  The

   controlling agent = gets to nominate which candidate pairs will get

   used for media amo= ngst the ones that are valid.

 

   When nominating, t= he controlling agent lets the checks continue until

   at least one valid= candidate pair for each media stream is found.

   Then, it picks amo= ngst those that are valid, and sends a second STUN

   request on its NOM= INATED candidate pair, but this time with a flag

   set to tell the pe= er that this pair has been nominated for use.  This<= /p>

   is shown in Figure= 4.

 

   <picture>

 

   Once the STUN tran= saction with the flag completes, both sides cancel

   any future checks = for that media stream.  ICE will now send media

   using this pair.&n= bsp; The pair an ICE agent is using for media is called

   the SELECTED PAIR.= ”

 

Now, if I understand the text above correctly, the o= nly difference between NOMINATED and SELECTED is that SELECTED means that t= he nomination STUN transaction has succeeded.

 

However, e.g., in section 5.1.3.4 is the following t= ext:

 

      “Completed:  In this state, =
ICE checks have produced nominated pairs
      for each component of the media stream.=
”
 

Q1: Shouldn’t a check list be placed in Comple= ted state once the nomination procedure has actually succeeded, i.e., one I= CE checks has produced SELECTED pairs? In addition, due to the previous nom= ination changes, I don’t think a check list is Completed just because a pair is nominated.

 

Q2: Is there a need to separate between NOMINATED an= d SELECTED? Especially with the removal of aggressive nomination, there may= be multiple NOMINATED pairs.

 

Regards,

 

Christer

 

 

 

 

Completed:  In this state, ICE checks have produced nominated pai=
rs
      for each component of the media stream.=

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B4BE3D803ESESSMB209erics_-- From nobody Fri Nov 18 06:45:30 2016 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 D9A8412945B for ; Fri, 18 Nov 2016 06:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qx5IQ0yQAaJW for ; Fri, 18 Nov 2016 06:45:25 -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 32B2112941C for ; Fri, 18 Nov 2016 06:45:24 -0800 (PST) X-AuditID: c1b4fb3a-233ff70000005ff3-64-582f1402334b Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 7E.19.24563.2041F285; Fri, 18 Nov 2016 15:45:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Fri, 18 Nov 2016 15:45:10 +0100 From: Christer Holmberg To: Christer Holmberg , "ice@ietf.org" Thread-Topic: 5245bis: NOMINATED vs SELECTED Thread-Index: AdJBk5IukpG3WEP8RAuuqWoy5t1HNwAFUGKw Date: Fri, 18 Nov 2016 14:45:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE3EAFC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BE3D803@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE3D803@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE3EAFCESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7qy6TiH6EQdMeNYtvF2odGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJWx5NtH5oLH9RXTrneyNTCeLuhi5OSQEDCR2PTzA3sXIxeHkMA6 RokF8z4xQjhLGCXm9T4Acjg42AQsJLr/aYM0iAiES9x5eZMNJCwsoC3xa2kYRFhHYserU8wQ tpHEoc4GMJtFQFXi0KZ5LCA2r4CvRNul3awgthCQvXTrBTCbU8BP4mDHQjCbUUBM4vupNUwg NrOAuMStJ/OZIO4UkFiy5zwzhC0q8fLxP1YIW0li7eHtLBD1+RK3Zq9ih9glKHFy5hOWCYzC s5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tbg4N93ISC+1KDO5 uDg/Ty8vtWQTIzBODm75bbWD8eBzx0OMAhyMSjy8Bv90I4RYE8uKK3MPMUpwMCuJ8E4W0o8Q 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgbHI6CPjGwnJ Yqcge/W+0lqzQL5j0XM7FaQ/NFXaG7y1dfv3S6VabV3nDK0HrfN3SgQfq7OTM3fPYNP5mfD1 bn+P3vme8/KFv28LW8kw7TKI3vu8l23a5zNaK/kutBZsu9Z/8mKB34ZzLTIckb8mL9v4ZUFs 82oz7rq8vZvFOU9NXCQxdc2tOUosxRmJhlrMRcWJAHoUoMqPAgAA Archived-At: Subject: Re: [Ice] 5245bis: NOMINATED vs SELECTED X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 14:45:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE3EAFCESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I need to re-formulate my previous e-mail. First, the text in Section 2.6 that I referenced needs to be modified, due = to the removal of aggressive nomination. At least the following sentence I think shall be modified, as it suggests (= at least in my reading) that media cannot be sent before nomination: OLD: "The controlling agent gets to nominate which candidate pairs will get used for media amongst the ones that are valid." NEW: "The controlling agent gets to nominate which candidate pairs will get used for media amongst the ones that are valid. Before the controlling agent nominates a pair media can be sent on any valid candidate pair." My questions slightly modified: Q1: Shouldn't a check list be placed in Completed state once the nomination= procedure has actually succeeded, i.e., one ICE checks has produced SELECT= ED pairs? I removed Q2, because it is not important at this point. Regards, Christer From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 18 November 2016 14:08 To: ice@ietf.org Subject: [Ice] 5245bis: NOMINATED vs SELECTED Section 2.6 says: "Consequently, ICE assigns one of the agents in the role of the CONTROLLING AGENT, and the other of the CONTROLLED AGENT. The controlling agent gets to nominate which candidate pairs will get used for media amongst the ones that are valid. When nominating, the controlling agent lets the checks continue until at least one valid candidate pair for each media stream is found. Then, it picks amongst those that are valid, and sends a second STUN request on its NOMINATED candidate pair, but this time with a flag set to tell the peer that this pair has been nominated for use. This is shown in Figure 4. Once the STUN transaction with the flag completes, both sides cancel any future checks for that media stream. ICE will now send media using this pair. The pair an ICE agent is using for media is called the SELECTED PAIR." Now, if I understand the text above correctly, the only difference between = NOMINATED and SELECTED is that SELECTED means that the nomination STUN tran= saction has succeeded. However, e.g., in section 5.1.3.4 is the following text: "Completed: In this state, ICE checks have produced nominated pairs for each component of the media stream." Q1: Shouldn't a check list be placed in Completed state once the nomination= procedure has actually succeeded, i.e., one ICE checks has produced SELECT= ED pairs? In addition, due to the previous nomination changes, I don't thin= k a check list is Completed just because a pair is nominated. Q2: Is there a need to separate between NOMINATED and SELECTED? Especially = with the removal of aggressive nomination, there may be multiple NOMINATED = pairs. Regards, Christer Completed: In this state, ICE checks have produced nominated pairs for each component of the media stream. --_000_7594FB04B1934943A5C02806D1A2204B4BE3EAFCESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I need to re-formulate= my previous e-mail.

 

First, the text in Sec= tion 2.6 that I referenced needs to be modified, due to the removal of aggr= essive nomination.

 

At least the following= sentence I think shall be modified, as it suggests (at least in my reading= ) that media cannot be sent before nomination:

 

OLD:=

 

   “The control= ling agent gets to nominate which candidate pairs will get

   used for media amo= ngst the ones that are valid.”

 

NEW:=

 

   “The control= ling agent gets to nominate which candidate pairs will get

   used for media amo= ngst the ones that are valid. Before the controlling

   agent nominates a = pair media can be sent on any valid candidate pair.”

 

My questions slightly = modified:

 

Q1: Shouldn’t a check list be placed in Comple= ted state once the nomination procedure has actually succeeded, i.e., one I= CE checks has produced SELECTED pairs?

 

I removed Q2, because it is not important at this po= int.

 

Regards,

 

Christer

 

 

From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 18 November 2016 14:08
To: ice@ietf.org
Subject: [Ice] 5245bis: NOMINATED vs SELECTED

 

Section 2.6 says:

 

   “Consequentl= y, ICE assigns one of the agents in the role of the

   CONTROLLING AGENT,= and the other of the CONTROLLED AGENT.  The

   controlling agent = gets to nominate which candidate pairs will get

   used for media amo= ngst the ones that are valid.

 

   When nominating, t= he controlling agent lets the checks continue until

   at least one valid= candidate pair for each media stream is found.

   Then, it picks amo= ngst those that are valid, and sends a second STUN

   request on its NOM= INATED candidate pair, but this time with a flag

   set to tell the pe= er that this pair has been nominated for use.  This<= /p>

   is shown in Figure= 4.

 

   <picture>

 

   Once the STUN tran= saction with the flag completes, both sides cancel

   any future checks = for that media stream.  ICE will now send media

   using this pair.&n= bsp; The pair an ICE agent is using for media is called

   the SELECTED PAIR.= ”

 

Now, if I understand the text above correctly, the o= nly difference between NOMINATED and SELECTED is that SELECTED means that t= he nomination STUN transaction has succeeded.

 

However, e.g., in section 5.1.3.4 is the following t= ext:

 

      “Completed:  In this state, =
ICE checks have produced nominated pairs
      for each component of the media stream.=
”
 

Q1: Shouldn’t a check list be placed in Comple= ted state once the nomination procedure has actually succeeded, i.e., one I= CE checks has produced SELECTED pairs? In addition, due to the previous nom= ination changes, I don’t think a check list is Completed just because a pair is nominated.

 

Q2: Is there a need to separate between NOMINATED an= d SELECTED? Especially with the removal of aggressive nomination, there may= be multiple NOMINATED pairs.

 

Regards,

 

Christer

 

 

 

 

Completed:  In this state, ICE checks have produced nominated pai=
rs
      for each component of the media stream.=

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B4BE3EAFCESESSMB209erics_-- From nobody Fri Nov 18 07:08:15 2016 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 21A4012941C for ; Fri, 18 Nov 2016 07:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbdHqPQCovau for ; Fri, 18 Nov 2016 07:08:11 -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 C9CF4128B44 for ; Fri, 18 Nov 2016 07:08:10 -0800 (PST) X-AuditID: c1b4fb25-adbff70000007ee2-c6-582f1958ecbf Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by (Symantec Mail Security) with SMTP id 18.C8.32482.8591F285; Fri, 18 Nov 2016 16:08:09 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0319.002; Fri, 18 Nov 2016 16:08:08 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: Check list candidate pair state correction - pull request Thread-Index: AdJBrP51CWUc0pUzSfK1GqLXF1HVog== Date: Fri, 18 Nov 2016 15:08:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE3EB2B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE3EB2BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM2K7nG6kpH6Ewf2P3BbfLtQ6MHosWfKT KYAxissmJTUnsyy1SN8ugStja5drwXXNijcPLzM1MG5U6WLk5JAQMJGYufUWO4gtJLCOUaJ3 t0wXIxeQvYRR4sGEFWxdjBwcbAIWEt3/tEFqRAQUJWa2PGMGsYUFvCX29cxng4gHSSx7cZUR wtaT2HjwEAuIzSKgKnHo3lewGl4BX4klq/4ygdiMAmIS30+tAbOZBcQlbj2ZzwRxj4DEkj3n mSFsUYmXj/+xQthKEmsPb2eBqM+X2LPiOxPETEGJkzOfsExgFJyFZNQsJGWzkJRBxHUkFuz+ xAZha0ssW/iaGcY+c+AxE7L4Akb2VYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBQX9wy2/V HYyX3zgeYhTgYFTi4S0Q148QYk0sK67MPcQowcGsJMKrKgYU4k1JrKxKLcqPLyrNSS0+xCjN waIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgbGtj4PvodvXwAUZT4Wjn3D36zzbI7507suo /tl7lzE1+Ln92pQT2u7SYKPy316/6oX21LOzpyrNmzHlSAlr266w5QXL1N0XBTlOMf1TLT+/ cv5SI84jHPPqD1f8rT8Xfn9X77xbEQW7F12WDTY/PzHoUuXKzI+vdA7E/rq+a9aEfR8Xt6W0 rhBSYinOSDTUYi4qTgQAED2JonYCAAA= Archived-At: Subject: [Ice] 5245bis: Check list candidate pair state correction - pull request X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 15:08:13 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE3EB2BESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In Seoul I claimed that the definitions of the candidate pair states "Waiti= ng" and "Frozen" are incorrect. Section 5.1.3.4 contains the following definitions: "Waiting: A check has not been performed for this pair, and can be perform= ed as soon as it is the highest-priority Waiting pair on the check list." I claimed that checks are not performed solely based on priority - it also = depends on whether the check is triggered or ordinary. But, we don't need t= o go into those details in the state definition. "Frozen: A check for this pair hasn't been performed, and it can't yet be = performed until some other check succeeds, allowing this pair to unfreeze a= nd move into the Waiting state.." I claimed that pairs can be unfrozen even if other checks have not succeede= d. Based on the discussions, I've created a pull request: https://github.com/ice-wg/rfc5245bis/pull/23 I've also done some text/terminology alignment among all states. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4BE3EB2BESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In Seoul I claimed that the definitions of the candi= date pair states “Waiting” and “Frozen” are incorre= ct.

 

Section 5.1.3.4 contains the following definitions:<= o:p>

 

“Waiting:  A check has not been= performed for this pair, and can be performed as soon as it is the highest-priority Waiting pair on the check list= .”

 

I claimed that checks are not performed solely based= on priority – it also depends on whether the check is triggered or o= rdinary. But, we don’t need to go into those details in the state def= inition.

 

“Frozen:  A check for this pair= hasn't been performed, and it can't yet be performed until some other check succeeds, allowing this pair to unfreeze and = move into the Waiting state..”

 

I claimed that pairs can be unfrozen even if other c= hecks have not succeeded.

 

 

Based on the discussions, I’ve created a pull = request:

 

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

 

I’ve also done some text/terminology alignment= among all states.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4BE3EB2BESESSMB209erics_-- From nobody Sat Nov 19 01:27:21 2016 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 974C6129467 for ; Sat, 19 Nov 2016 01:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nboBHiLKQjoh for ; Sat, 19 Nov 2016 01:27:16 -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 2A5191294C7 for ; Sat, 19 Nov 2016 01:27:14 -0800 (PST) X-AuditID: c1b4fb30-57fff70000001942-99-58301af04b56 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 72.0A.06466.0FA10385; Sat, 19 Nov 2016 10:27:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0319.002; Sat, 19 Nov 2016 10:27:12 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? Thread-Index: AdJCRurmAgGp6u03Tl6w25hg1S1vSQ== Date: Sat, 19 Nov 2016 09:27:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE742CE@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE742CEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM2K7h+5HKYMIg0UvxCy+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG+/XTWAo2aFUsfnacsYHxlEoXIyeHhICJxJ8VnSxdjFwcQgLr GCWaVq5ngnAWM0pcuTWZtYuRg4NNwEKi+582SIOIgKLEzJZnzCA1wgL9jBJvV89jA3FEBKYw Spy5s4YFokpPou3BT0YQm0VAVaLlyzqwOK+Ar8T/uxPZQGxGATGJ76fWMIHYzALiEreezGeC OElAYsme88wQtqjEy8f/WCFsJYlFtz9D1edL/F72FWqmoMTJmU9YJjAKzkIyahaSsllIyiDi OhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMDg P7jlt8EOxpfPHQ8xCnAwKvHwFojrRwixJpYVV+YeYpTgYFYS4ZWQNIgQ4k1JrKxKLcqPLyrN SS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgTHfLYbvf9nChbk9PHKb59194el/ I57JdFKFxls1NlWJ8mVb1rBLJ17u6fr4S3Sa8LTceFc7/gVXHdiSjK+rSDhFHn11RSNhz+u1 x4RlnB7+1WgpLNBab213e8XJNp11DkpPp964yvHCIHHFfH21R5Es4rNW5BTPLPFP+HTFaXbb FDlnkQYGayWW4oxEQy3mouJEAKwE/Ch6AgAA Archived-At: Subject: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 09:27:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE742CEESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One potential issue that came to my mind while reading the SDP m- line thre= ad. Previously, before removal of aggressive nomination, while and endpoint mig= ht support both UDP and TCP for a protocol, it didn't have to be able to si= multaneously use the protocol with both UDP and TCP, and switching between.= Because, until nomination was done, no protocol data was sent. And, once n= omination had been done, endpoints used the protocol with the selected tran= sport. Now, with the allowed-to-send-media-before-nomination rules, protocols basi= cally have to support switch of transport (from UDP to TCP, and vice versa)= , until the nomination takes place. Now, even people always say that a good designed protocol should be transpo= rt-independent, isn't *mandating* transport switching on-the-fly (before no= mination takes place) by all protocols supporting ICE and multiple transpor= ts a bad thing to do? Perhaps the ICE considerations of each protocol (RTP, BFCP etc) should indi= cate whether transport switching is supported, and whether there are protoc= ol specific procedures associated with that. I guess a protocol could also = specify that data shouldn't be sent in the first place before nomination ha= s been done, if there are good reasons for that. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4BE742CEESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One potential issue that came to my mind while readi= ng the SDP m- line thread.

 

Previously, before removal of aggressive nomination,= while and endpoint might support both UDP and TCP for a protocol, it didn&= #8217;t have to be able to simultaneously use the protocol with both UDP an= d TCP, and switching between. Because, until nomination was done, no protocol data was sent. And, once nomination had b= een done, endpoints used the protocol with the selected transport.

 

Now, with the allowed-to-send-media-before-nominatio= n rules, protocols basically have to support switch of transport (from UDP = to TCP, and vice versa), until the nomination takes place.

 

Now, even people always say that a good designed pro= tocol should be transport-independent, isn’t *mandating* trans= port switching on-the-fly (before nomination takes place) by all protocols = supporting ICE and multiple transports a bad thing to do?

 

Perhaps the ICE considerations of each protocol (RTP= , BFCP etc) should indicate whether transport switching is supported, and w= hether there are protocol specific procedures associated with that. I guess= a protocol could also specify that data shouldn’t be sent in the first place before nomination has been= done, if there are good reasons for that.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4BE742CEESESSMB209erics_-- From nobody Sat Nov 19 18:22:39 2016 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 3FB9A12952B for ; Sat, 19 Nov 2016 18:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 woibTKhKJ6lf for ; Sat, 19 Nov 2016 18:22:35 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8061129400 for ; Sat, 19 Nov 2016 18:22:35 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id w194so195960967vkw.2 for ; Sat, 19 Nov 2016 18:22:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TYklkMBqiTGhht1tLQToDSs8F6Z1Y5KWpuyzNVSM4uA=; b=TP6P74NYC5ksNGbAxG2O/nr7qbEt6lQoxIAnpA1kFCPi00fIfrF5C3aHsruXAJbhXS 5NkVzIFQOLq/j5qG+x1ztFJtZgSIjJaJhmwgkpTwdkVZsWMZdkPMJYubn15VN80/DHnv vJIPnhL+RXdWC2/0hSosCgMjkcxAFPvG9SIENPtnRGJfthYFD2yzjwX/7UdsHKiPrACJ oXPOybKt29swh8dkD8fc0HgHxuEkrXVXSyc7tp4p00T+iZWDjE3sc9A6uq4PByojdybe bHUKWcsYXqsapSC3j4W6tQOaRNP66aIznuqlGZ2F4ib6BTbuIwqMizaC8pYaYbnH3B4w XrFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TYklkMBqiTGhht1tLQToDSs8F6Z1Y5KWpuyzNVSM4uA=; b=OJ6jPBnHchPkfygsN2cUksOYtQV2q9velgGdkTY6D6xjvyWvFysU/zgQE2tMBz9zxA IwxrJ+Eab3jXf6s4fxHJ3lxGYmF84ThBxYwMAV4YYwv3jXi1Y7JtjftI8i20KcALM3rm hF9vNxZ1G3FTeYHgpx5mlrVHHThX7Q0aEtBnWihBR3mobRgz94sG7LBxFyrSeqOpAzwP TCEhcW8XMQO0B6BnSlPV65y6Sie9+ZahtUrWVGMRR2fVJR+z30GVsBdCXUzWLdeAbI7D EWHz5fZFuI2e0xQ1br0cUe/OCr2d/ycqc4xgOw/nh+RUjJhwfkp37HRz2BJmdU0nmpEL 95TA== X-Gm-Message-State: AKaTC02fU0X4u5vmqXHZJy6soNbMBEG2wNcDAnE66ohqwXnkT51Gu69ITsUzhgg0FLY7Wk9VHKQb4c//lN7Ufw== X-Received: by 10.31.220.4 with SMTP id t4mr3691996vkg.143.1479608554260; Sat, 19 Nov 2016 18:22:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Sat, 19 Nov 2016 18:22:33 -0800 (PST) Received: by 10.176.16.10 with HTTP; Sat, 19 Nov 2016 18:22:33 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE742CE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BE742CE@ESESSMB209.ericsson.se> From: Bernard Aboba Date: Sat, 19 Nov 2016 18:22:33 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c07aaee488e8d0541b23674 Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 02:22:38 -0000 --94eb2c07aaee488e8d0541b23674 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christer -- With aggressive nomination, a TCP candidate-pair could be nominated, and then a UDP candidate-pair could be nominated, and data could be sent on a successful pair. So "switching" can also occur. Given that the controlled peer needs to be able to receive on any successful pair, it has to be prepared for receiving both UDP and TCP packets at the same time. So how is "passive-aggressive" nomination more onerous than aggressive in this respect? On Nov 19, 2016 1:27 AM, "Christer Holmberg" wrote: > Hi, > > > > One potential issue that came to my mind while reading the SDP m- line > thread. > > > > Previously, before removal of aggressive nomination, while and endpoint > might support both UDP and TCP for a protocol, it didn=E2=80=99t have to = be able to > simultaneously use the protocol with both UDP and TCP, and switching > between. Because, until nomination was done, no protocol data was sent. > And, once nomination had been done, endpoints used the protocol with the > selected transport. > > > > Now, with the allowed-to-send-media-before-nomination rules, protocols > basically have to support switch of transport (from UDP to TCP, and vice > versa), until the nomination takes place. > > > > Now, even people always say that a good designed protocol should be > transport-independent, isn=E2=80=99t **mandating** transport switching on= -the-fly > (before nomination takes place) by all protocols supporting ICE and > multiple transports a bad thing to do? > > > > Perhaps the ICE considerations of each protocol (RTP, BFCP etc) should > indicate whether transport switching is supported, and whether there are > protocol specific procedures associated with that. I guess a protocol cou= ld > also specify that data shouldn=E2=80=99t be sent in the first place befor= e > nomination has been done, if there are good reasons for that. > > > > Regards, > > > > Christer > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --94eb2c07aaee488e8d0541b23674 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Christer --

With aggressive nomination, a TCP candidate-pair could be no= minated, and then a UDP candidate-pair could be nominated, and data could b= e sent on a successful pair.=C2=A0 So "switching" can also occur.= =C2=A0 Given that the controlled peer needs to be able to receive on any su= ccessful pair, it has to be prepared for receiving both UDP and TCP packets= at the same time.

So how is "passive-aggressive" nomination more one= rous than aggressive in this respect?


On Nov 19, 2016 1= :27 AM, "Christer Holmberg" <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

One potential issue that came to my mind while readi= ng the SDP m- line thread.

=C2=A0

Previously, before removal of aggressive nomination,= while and endpoint might support both UDP and TCP for a protocol, it didn= =E2=80=99t have to be able to simultaneously use the protocol with both UDP= and TCP, and switching between. Because, until nomination was done, no protocol data was sent. And, once nomination had b= een done, endpoints used the protocol with the selected transport.

=C2=A0

Now, with the allowed-to-send-media-before-nomi= nation rules, protocols basically have to support switch of transport (from= UDP to TCP, and vice versa), until the nomination takes place.

=C2=A0

Now, even people always say that a good designed pro= tocol should be transport-independent, isn=E2=80=99t *mandating* tra= nsport switching on-the-fly (before nomination takes place) by all protocol= s supporting ICE and multiple transports a bad thing to do?

=C2=A0

Perhaps the ICE considerations of each protocol (RTP= , BFCP etc) should indicate whether transport switching is supported, and w= hether there are protocol specific procedures associated with that. I guess= a protocol could also specify that data shouldn=E2=80=99t be sent in the first place before nomination has be= en done, if there are good reasons for that.

=C2=A0

Regards,

=C2=A0

Christer


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

--94eb2c07aaee488e8d0541b23674-- From nobody Sun Nov 20 15:20:56 2016 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 6C86112949F for ; Sun, 20 Nov 2016 15:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmbfWGH7iI3f for ; Sun, 20 Nov 2016 15:20:53 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D8A1293E3 for ; Sun, 20 Nov 2016 15:20:52 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id p16so192495567qta.0 for ; Sun, 20 Nov 2016 15:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eoqPjAlTbaxQfaHernMfhJBqebxXowfbgO3izmJIFkM=; b=fhND5J5LntHQ+pxNBxENK+YAa/PIMtm/jnXBfSWwi7bIpV/FHvB96ewAqv52FmOhzl GGab1ICupCa0rgy/Dwjxxp0zcFQOe6k+YMj9BT529VNbmYinXxB1XOLp98clrDhogsLr jDtJ2B5YDENicVwMwUGq7G3KtDBl7a7HjG1Sl/XFdZQHX8WZAH89Zsx+7wA3jq2tt9tm cHtnbG+Wx9N4vX2Vgh+2j6Fs3pyVoEl8EkzQ1BTFQHoWsdr9VkpqvX8anQFB9BKy4E/5 jAl9oa6uwpM423NSgrBkyYoew7h31dKmqKeS+na7wleTlhMVnWhzigrgGj4qaka27yoB j70A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eoqPjAlTbaxQfaHernMfhJBqebxXowfbgO3izmJIFkM=; b=nOTtS6YJFHiDsN8TRd2iKejOkEhMX0zw4X9LG160pj//aNsqgBeHCzMsbSu5aXyJH/ +AZ8ns/qVgVg3Y3e5lF7n0Bsyt2OC3Imya6mUEuhkZvwglvf508CGf8Q4L2uVYDAPXE1 I3XwS28D9alEdps/zecaz9Y4VpB13owCWPHexCSA5hgiye+dlN+cVy9ALGisAEIdtEV2 mBfkA396L6JNQkbtaZQtZW1CCaV3iEAIeYrFQqq3UKPQ5KQFcT/QzjlZeheleqaPPnpD ZWVx8ZP8RAG5ieJl8yonLMGS0UEr8z8ajyyrCLgfc+ld8IgfdyuXrj06ACkQc7D72tws OBww== X-Gm-Message-State: AKaTC00if87s91ynFoVPTQo4wYphwg94xXJJIQPsGVN237hJYidaGIUybBLYjgA5G7jLEg== X-Received: by 10.200.39.43 with SMTP id g40mr7154288qtg.58.1479684052004; Sun, 20 Nov 2016 15:20:52 -0800 (PST) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com. [209.85.220.171]) by smtp.gmail.com with ESMTPSA id d15sm9807666qkb.10.2016.11.20.15.20.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Nov 2016 15:20:51 -0800 (PST) Received: by mail-qk0-f171.google.com with SMTP id n204so330671091qke.2 for ; Sun, 20 Nov 2016 15:20:51 -0800 (PST) X-Received: by 10.55.107.71 with SMTP id g68mr11740597qkc.259.1479684051030; Sun, 20 Nov 2016 15:20:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.135.243 with HTTP; Sun, 20 Nov 2016 15:20:50 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BE742CE@ESESSMB209.ericsson.se> From: Roman Shpount Date: Sun, 20 Nov 2016 18:20:50 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114ff8e83df7920541c3ca61 Archived-At: Cc: Bernard Aboba , ice@ietf.org Subject: Re: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 23:20:55 -0000 --001a114ff8e83df7920541c3ca61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Christer, Bernard have already addressed the issues related to aggressive nomination. I also wanted to bring up that this group is also actively working on continuous nomination. With continuous nomination "switching" between candidate pairs can occur for a fairly long time and protocol cannot wait for the nomination to complete. Requiring for the protocol to wait until nomination is complete will make it incompatible with continuous nomination= . Finally, and most importantly, I wanted this group to examine the purpose of tcp candidates. The way RFC 6544 is written, it implies that ICE creates a complete framework for setting up TCP connections between two end points with one or both of these end points located behind NAT. The document talks about simultaneous open candidates, reflexive TCP candidates and setting up relay for TCP connections. At the same time, in the actual implementations tcp relay and reflexive candidate are redundant, and tcp candidates are only used as a fail-over for udp candidates when udp is blocked by firewall and one of the end points is on public IP address. I have not seen anybody implementing the simultaneous open candidates and such candidates are impossible to implement on some of the operating systems. All I see are host active tcp candidates on the end points located behind NAT and host passive tcp candidates on the end points located on public internet. I would argue that creating a full framework for TCP connections and only using tcp candidates for udp fail-over are two very different use cases. They should be specified differently and cannot be used at the same time. I think it would be better to spell this out and limit the tcp candidate use case. For instance, in case of BFCP, TCP/BFCP can be used with TCP connection framework, which would require a direct host to host connections, so connections to reflexive addresses and some support for relay. This framework however, is not ICE, and will not support UDP and will use BFCP native framing. On the other hand, UDP/BFCP can naturally run on top of ICE, use both udp and tcp candidates. The only tcp candidates used in this case would be host candidates and BFCP running over tcp candidates will be UDP/BFCP with RFC 4571 framing as required by RFC 6544 ( https://tools.ietf.org/html/rfc6544#section-10.1). I think most of this discussion is due to very limited design and analysis that went into specification of BFCP with ICE. Once BFCP over ICE would be well defined most of those issues will disappear. Regards, _____________ Roman Shpount On Sat, Nov 19, 2016 at 9:22 PM, Bernard Aboba wrote: > Christer -- > > With aggressive nomination, a TCP candidate-pair could be nominated, and > then a UDP candidate-pair could be nominated, and data could be sent on a > successful pair. So "switching" can also occur. Given that the controll= ed > peer needs to be able to receive on any successful pair, it has to be > prepared for receiving both UDP and TCP packets at the same time. > > So how is "passive-aggressive" nomination more onerous than aggressive in > this respect? > > On Nov 19, 2016 1:27 AM, "Christer Holmberg" com> wrote: > >> Hi, >> >> >> >> One potential issue that came to my mind while reading the SDP m- line >> thread. >> >> >> >> Previously, before removal of aggressive nomination, while and endpoint >> might support both UDP and TCP for a protocol, it didn=E2=80=99t have to= be able to >> simultaneously use the protocol with both UDP and TCP, and switching >> between. Because, until nomination was done, no protocol data was sent. >> And, once nomination had been done, endpoints used the protocol with the >> selected transport. >> >> >> >> Now, with the allowed-to-send-media-before-nomination rules, protocols >> basically have to support switch of transport (from UDP to TCP, and vice >> versa), until the nomination takes place. >> >> >> >> Now, even people always say that a good designed protocol should be >> transport-independent, isn=E2=80=99t **mandating** transport switching >> on-the-fly (before nomination takes place) by all protocols supporting I= CE >> and multiple transports a bad thing to do? >> >> >> >> Perhaps the ICE considerations of each protocol (RTP, BFCP etc) should >> indicate whether transport switching is supported, and whether there are >> protocol specific procedures associated with that. I guess a protocol co= uld >> also specify that data shouldn=E2=80=99t be sent in the first place befo= re >> nomination has been done, if there are good reasons for that. >> >> >> >> Regards, >> >> >> >> Christer >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >> > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --001a114ff8e83df7920541c3ca61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christer,

Bernard have already addre= ssed the issues related to aggressive nomination.

= I also wanted to bring up that this group is also actively working on conti= nuous nomination. With continuous nomination "switching" between = candidate pairs can occur for a fairly long time and protocol cannot wait f= or the nomination to complete. Requiring for the protocol to wait until nom= ination is complete will make it incompatible with continuous nomination.

Finally, and most importantly, I wanted this group = to examine the purpose of tcp candidates. The way RFC 6544 is written, it i= mplies that ICE creates a complete framework for setting up TCP connections= between two end points with one or both of these end points located behind= NAT. The document talks about simultaneous open candidates, reflexive TCP = candidates and setting up relay for TCP connections. At the same time, in t= he actual implementations tcp relay and reflexive candidate are redundant, = and tcp candidates are only used as a fail-over for udp candidates when udp= is blocked by firewall and one of the end points is on public IP address. = I have not seen anybody implementing the simultaneous open candidates and s= uch candidates are impossible to implement on some of the operating systems= . All I see are host active tcp candidates on the end points located behind= NAT and host passive tcp candidates on the end points located on public in= ternet.

I would argue that creating a full framewo= rk for TCP connections and only using tcp candidates for udp fail-over are = two very different use cases. They should be specified differently and cann= ot be used at the same time. I think it would be better to spell this out a= nd limit the tcp candidate use case.

For instance,= in case of BFCP, TCP/BFCP can be used with TCP connection framework, which= would require a direct host to host connections, so connections to reflexi= ve addresses and some support for relay. This framework however, is not ICE= , and will not support UDP and will use BFCP native framing. On the other h= and, UDP/BFCP can naturally run on top of ICE, use both udp and tcp candida= tes. The only tcp candidates used in this case would be host candidates and= BFCP running over tcp=C2=A0candidates will be UDP/BFCP with =C2=A0RFC 4571= framing as required by RFC 6544 (https://tools.ietf.org/html/rfc6544#section-10.1).<= /div>

I think most of this discussion is due to very lim= ited design and analysis that went into specification of BFCP with ICE. Onc= e BFCP over ICE would be well defined most of those issues will disappear.<= /div>

Regards,
_____________
Roman Shpount

On Sat, Nov 19, 2016 at 9:22 PM, Bernard Abo= ba <bernard.aboba@gmail.com> wrote:

Christer --

With aggressive nomination, a TCP candidate-pair could be no= minated, and then a UDP candidate-pair could be nominated, and data could b= e sent on a successful pair.=C2=A0 So "switching" can also occur.= =C2=A0 Given that the controlled peer needs to be able to receive on any su= ccessful pair, it has to be prepared for receiving both UDP and TCP packets= at the same time.

So how is "passive-aggressive" nomination more one= rous than aggressive in this respect?


On Nov 19, 2016 1:27 AM, "Christer Holmberg" <christer.holmb= erg@ericsson.com> wrote:

Hi,

=C2=A0

One potential issue that came to my mind while readi= ng the SDP m- line thread.

=C2=A0

Previously, before removal of aggressive nomination,= while and endpoint might support both UDP and TCP for a protocol, it didn= =E2=80=99t have to be able to simultaneously use the protocol with both UDP= and TCP, and switching between. Because, until nomination was done, no protocol data was sent. And, once nomination had b= een done, endpoints used the protocol with the selected transport.

=C2=A0

Now, with the allowed-to-send-media-before-nomi= nation rules, protocols basically have to support switch of transport (from= UDP to TCP, and vice versa), until the nomination takes place.

=C2=A0

Now, even people always say that a good designed pro= tocol should be transport-independent, isn=E2=80=99t *mandating* tra= nsport switching on-the-fly (before nomination takes place) by all protocol= s supporting ICE and multiple transports a bad thing to do?

=C2=A0

Perhaps the ICE considerations of each protocol (RTP= , BFCP etc) should indicate whether transport switching is supported, and w= hether there are protocol specific procedures associated with that. I guess= a protocol could also specify that data shouldn=E2=80=99t be sent in the first place before nomination has be= en done, if there are good reasons for that.

=C2=A0

Regards,

=C2=A0

Christer


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


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


--001a114ff8e83df7920541c3ca61-- From nobody Sun Nov 20 15:23:33 2016 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 1587D1294B4 for ; Sun, 20 Nov 2016 15:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX94xzXGzZfV for ; Sun, 20 Nov 2016 15:23:29 -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 0C6361293E3 for ; Sun, 20 Nov 2016 15:23:29 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id c47so194303579qtc.2 for ; Sun, 20 Nov 2016 15:23:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wWcatBvKhIDZCpN21sL7YRhc3RG13DReFcX3xrwFiAI=; b=tCQEhtfMuYUKywY7srOZLM8mUqrKO4JEpQdz0bS0CH9suMh3mshnyeVkct6upTbYeK 5GndiKzPgFrX2ehrq3MBTLkCqW25pNNRykSLnlY0AJYdHu1VIXs+RhfAmL5ZpO9ERH8Q 3xZ5xnwZ2XPieCI4iz4OvXj9hI4HVMhrHS+NPY0N7ETrW05bBBhMvcOkdHSjEFc9QCxL 3a22SFxnRG1apJLwuCEL6MQvOLpqysWCZmuH2zV6EJDCDmY7t8TLDAqBpRTUpBGrW7K7 bsqntv7CHsv+RPqw6PWKbwI62QJfDXp/Vltb0Nze8nECFjInyOlJZ6abwMzDOFU5kqoV Uk1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wWcatBvKhIDZCpN21sL7YRhc3RG13DReFcX3xrwFiAI=; b=bYHFik40QZJSKjWXvZvC8JTK8JAzzdcnzF3YjYuOrSAlS2H7yMa5pZh3USOXadLVGY xL4mRvv7K1UhWo+CuGZ3eSygIV5/87cK5E5+GhDdovlZsybAX2YFnWpRwXHfSKQEO3zM 60sDHmpbaYs7xC6jBJh7j82cjUTiHrGfc4jRwg5ZOQA6uBGJu7fyG7/P6RQIaiYUI+O/ UJkgqITuKFL9TdO4FVS+lwEg/O1CIdl8GiTwDZtJwVRYB+P05TMo7R9NXMMTWFuRiR1V SEpuVPPiBw9DB0YdGlfYzwyRiaijTLraGyg8/pOS8GYWq0qd74BAh5QSPgkyDUI+l/Vm U8Xg== X-Gm-Message-State: AKaTC017jNnenCRWwAS1SStwD+VUj+8U6xtV+rteyrhZ2+L+92Cg/SEWfvMbOX6Lr/5l+A== X-Received: by 10.237.62.110 with SMTP id m43mr6469104qtf.195.1479684208153; Sun, 20 Nov 2016 15:23:28 -0800 (PST) Received: from mail-qt0-f173.google.com (mail-qt0-f173.google.com. [209.85.216.173]) by smtp.gmail.com with ESMTPSA id f7sm7242223qtf.48.2016.11.20.15.23.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Nov 2016 15:23:27 -0800 (PST) Received: by mail-qt0-f173.google.com with SMTP id c47so194303471qtc.2; Sun, 20 Nov 2016 15:23:27 -0800 (PST) X-Received: by 10.200.37.101 with SMTP id 34mr6254612qtn.273.1479684207450; Sun, 20 Nov 2016 15:23:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.135.243 with HTTP; Sun, 20 Nov 2016 15:23:26 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> From: Roman Shpount Date: Sun, 20 Nov 2016 18:23:26 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan Ford Content-Type: multipart/alternative; boundary=001a11404b3290a43e0541c3d344 Archived-At: Cc: bfcpbis@ietf.org, ice@ietf.org, "mmusic@ietf.org" , Christer Holmberg Subject: Re: [Ice] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 23:23:32 -0000 --001a11404b3290a43e0541c3d344 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, I just wanted to add to my previous email, that according to RFC 6544 protocols running over tcp candidates MUST use RFC 4571 framing ( https://tools.ietf.org/html/rfc6544#section-10.1). This means that BFCP running over tcp candidate is not TCP/BFCP and will require a different transport tag. Regards, _____________ Roman Shpount On Thu, Nov 17, 2016 at 9:13 PM, Roman Shpount wrote: > Hi All, > > There are three comments I wanted to make regarding general nature of all > existing protocols designed to work ICE > > 1. Protocols running on top of ICE assume that regardless what candidate > pair is used, including tcp candidates, the underlying network transport = is > unordered and unreliable. During nomination, including continuous > nomination, candidate pairs can switch, including switching from udp to t= cp > or from tcp to udp. This typically means that protocol re-transmit timers > are operational, packets are re-ordered at the protocol level, and > UDP-friendly packet sizes are used even when packets are sent over tcp > candidates. For instance DTLS and SCTP re-transmit timers, reordering, an= d > fragmentation support are still running when tcp candidates are used. > > 2. Protocols do not assume that particular candidate network transport > runs all the way from origination to final destination of the protocol > packets. For instance there are SBC which only handle ICE. These SBC run > the ICE state machine and then transmit the underlying protocol data to t= he > final destination using public IP. Because of this, it is not unusual for > RTP to run over tcp candidate until SBC and then run over UDP to the fina= l > destination. This is one more reason why re-transmit timers and other > mechanisms used to deal with UDP are still running over tcp candidates. > > 3. I am not aware of any current protocol running over ICE tcp candidates > which is not using RFC4571 framing. For instance DTLS could have been > implemented using DTLS protocol framing without RFC4571 over tcp > candidates, but this was not the case. This is partially done to simplify > implementation of SBC which terminate ICE and transmit protocol data usin= g > UDP. By using RFC 4571 framing, SBC can packetize/de-packetize data > transmitted over tcp candidates without knowing protocol details. > > To conclude, up until this point ICE tcp candidates were not treated as > reliable transport and served simply as another way to transmit UDP packe= ts > through firewalls. Because of this, I would argue that BFCP running over > tcp candidate is not the same as TCP/BFCP, in the same way as DTLS runnin= g > over tcp candidate is not TLS. > > I would also argue that any protocol running over ICE is, in essence, a > UDP based protocol, using tcp candidates only as a fall back mechanism fo= r > firewall traversal, same way as when data is relayed over TURN TCP, it is > still considered sent over UDP at the protocol level. > > If ICE group agrees, I think this should be documented by saying that UDP > is a MUST implement for any protocol using ICE and that default candidate > should be UDP based. > > Regards, > _____________ > Roman Shpount > > On Thu, Nov 17, 2016 at 8:14 PM, Alan Ford wrote: > >> Adding bfcpbis. >> >> You raise a good point Roman - there=E2=80=99s no definition of how to a= ctually >> use ICE with BFCP at the protocol level - this only came up in some very >> late reviews of 4582bis. The initial suggestion was to use the same text= as >> in draft-ietf-mmusic-sctp-sdp-19, but it then raised the point that, >> given BFCP does not have a MTI protocol, if the offerer supported both t= hey >> would include their preferred option, but if the receiver supported the >> other variant, there=E2=80=99s no way to immediately negotiate that with= out a >> re-INVITE. >> >> Christer=E2=80=99s suggestion to relax the requirement that the m-line p= rotocol *in >> the answer* matches one of the ICE candidates would support the case >> where the offerer supports both but prefers UDP, but the answerer only >> supports TCP. Although no implementations currently do ICE here, this >> relaxation would leave the door open to gaining this negotiation >> flexibility in bfcpbis implementations. There seems no reason to have th= is >> requirement applied to the answer in the first place. >> >> I don=E2=80=99t understand the comment about SBCs; today, tcp candidates= are used >> for media and data channels end-to-end in WebRTC, to name but one >> implementation. >> >> Regards, >> Alan >> >> On 17 Nov 2016, at 03:05, Roman Shpount wrote: >> >> Adding ICE group to this message. >> >> The approach always was that tcp candidates can potentially go only as >> far as SBC and then be terminated by UDP transport. Because of this >> everything transmitted over tcp candidate was still considered to be >> transmitted over the unreliable out-of-order transport. It is also assum= ed >> that candidates can switch from UDP to TCP based candidate during >> nomination. This is why, for instance, we run DTLS with RFC4571 framing >> over tcp candidates, not TLS. Because of this I always thought that ICE = is >> UDP first with additional TCP transports for situation when UDP will not >> work. So, as a result, I think ICE-bis should specify that UDP MUST be >> supported and default candidate MUST be UDP. ICE SDP can reflect this, b= ut >> I think this is the underlying protocol requirement. >> >> I also wanted to add that BFCP needs to examine how ICE support is >> implemented by this protocol. I think it is not covered in the current >> drafts. I also think I do not think it is possible for TCP/BFCP to run o= ver >> ICE. On the other hand UDP/DTLS/BFCP and TCP/DTLS/BFCP would trivial bas= ed >> on current DTLS work. >> >> Regards, >> _____________ >> Roman Shpount >> >> On Wed, Nov 16, 2016 at 8:44 PM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> I have no problem with Roman=E2=80=99s must-support-UDP suggestion. I g= uess the >>> question is whether the BFCP folks could accept that. Cullen did say th= at >>> TCP-based BFCP deployments have been around for a decade. But, do they >>> support ICE? >>> >>> >>> >>> If we decide to move forward with such approach, we need to ask >>> ourselves whether must-support-UDP should be an ICE requirement (in whi= ch >>> case the suggestion should be brought to the ICE WG) or whether it shou= ld >>> only be an ICE-using-SIP-SDP requirement. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> >>> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Roman >>> Shpount >>> *Sent:* 17 November 2016 00:52 >>> *To:* mmusic@ietf.org >>> *Subject:* [MMUSIC] m=3D line protocol in case of ICE >>> >>> >>> >>> Hi All, >>> >>> >>> >>> I just wanted to return to the m=3D line protocol issue that Christer >>> raised during the last MMUSIC session. >>> >>> >>> >>> All the ICE implementations I've seen are primarily UDP based with >>> support for tcp host candidates which are primarily used to connect to = end >>> points on public IP. If all ICE implementations are continue to be >>> primarily UDP based, then the simplest solution would be to require UDP >>> support when any given protocol is implemented over ICE. DTLS and RTP a= re >>> already primarily UDP based so this is a non-requirement. Even more, al= l >>> protocols that are implemented on top of ICE must assume that underling >>> transports (including tcp candidates) are unreliable, since candidate p= air >>> can change at any time between reliable and unreliable transports, so t= his >>> makes them different from protocols implemented on plain TCP or TLS. >>> >>> >>> >>> So the first question I wanted to ask is anybody interested in TCP only >>> ICE implementation where the protocol running on top of such implementa= tion >>> relies on the reliable delivery of underlying messages? By this I mean, >>> does anybody wants implement TCP based ICE, with simultaneous open, >>> reflexive and relay candidates in such a way that ICE implementation wi= ll >>> run from behind NAT without ever needing a UDP candidate? >>> >>> >>> >>> I understand that BFCP was used for a long time, but I do not think >>> TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I think only UDP/BF= CP, >>> UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE. >>> >>> >>> >>> I think both rfc4582bis and rfc4583bis need a careful review and >>> additional sections that describe ICE considerations. I think the most >>> obvious thing would be to specify that ICE can only be supported by >>> UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which c= ase >>> RFC4571 is used when tcp candidates are used. Furthermore, when tcp >>> candidate is selected with UDP/BFCP transport, it is not the same thing= as >>> using TCP/BFCP and will need a different transport tag (something like >>> TCP/UDP/BFCP). Alternatively we can require that only secure versions o= f >>> BFCP are used with ICE and only allow ICE usage for UDP/DTLS/BFCP and >>> TCP/DTLS/BFCP. >>> >>> >>> >>> To conclude, I would argue that the simplest solution would be that for >>> all protocols implemented on top of ICE, UDP MUST be supported and defa= ult >>> candidates MUST be UDP based. This avoids building uncomfortable artifi= cial >>> constructs to avoid ICE mismatch and requires minimal changes to existi= ng >>> specifications. >>> >>> >>> >>> Regards, >>> >>> _____________ >>> Roman Shpount >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> > --001a11404b3290a43e0541c3d344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I just wanted to add to my prev= ious email, that according to RFC 6544=C2=A0protocols running over tcp cand= idates MUST use =C2=A0RFC 4571 framing (https://tools.ietf.org/html/rfc6544#section-10.1<= /a>). This means that BFCP running over tcp candidate is not TCP/BFCP and w= ill require a different transport tag.


_____________
Roman Sh= pount

On Thu, Nov 17, 2016 at 9:13 PM, Roman Shpou= nt <roman@telurix.com> wrote:
Hi All,

There are three comme= nts I wanted to make regarding general nature of all existing protocols des= igned to work ICE

1. Protocols running on top of ICE ass= ume that regardless what candidate pair is used, including tcp candidates, = the underlying network transport is unordered and unreliable. During nomina= tion, including continuous nomination, candidate pairs can switch, includin= g switching from udp to tcp or from tcp to udp. This typically means that p= rotocol re-transmit timers are operational, packets are re-ordered at the p= rotocol level, and =C2=A0UDP-friendly packet sizes are used even when packe= ts are sent over tcp candidates. For instance DTLS and SCTP re-transmit tim= ers, reordering, and fragmentation support are still running when tcp candi= dates are used.

2. Protocols do not assume that pa= rticular candidate network transport runs all the way from origination to f= inal destination of the protocol packets. For instance there are SBC which = only handle ICE. These SBC run the ICE state machine and then transmit the = underlying protocol data to the final destination using public IP. Because = of this, it is not unusual for RTP to run over tcp candidate until SBC and = then run over UDP to the final destination. This is one more reason why re-= transmit timers and other mechanisms used to deal with UDP are still runnin= g over tcp candidates.

3. I am not aware of any cu= rrent protocol running over ICE tcp candidates which is not using RFC4571 f= raming. For instance DTLS could have been implemented using DTLS protocol f= raming without RFC4571 over tcp candidates, but this was not the case. This= is partially done to simplify implementation of SBC which terminate ICE an= d transmit protocol data using UDP. By using RFC 4571 framing, SBC can pack= etize/de-packetize data transmitted over tcp candidates without knowing pro= tocol details.

To conclude, up until this point IC= E tcp candidates were not treated as reliable transport and served simply a= s another way to transmit UDP packets through firewalls. Because of this, I= would argue that BFCP running over tcp candidate is not the same as TCP/BF= CP, in the same way as DTLS running over tcp candidate is not TLS.

I would also argue that any protocol running over ICE is, = in essence, a UDP based protocol, using tcp candidates only as a fall back = mechanism for firewall traversal, same way as when data is relayed over TUR= N TCP, it is still considered sent over UDP at the protocol level.

If ICE group agrees, I think this should be documented by = saying that UDP is a MUST implement for any protocol using ICE and that def= ault candidate should be UDP based.

Regards,
_____________
Roman S= hpount

On Thu, Nov 17, 2016 at 8:14 PM, Alan Ford <= span dir=3D"ltr"><alan.ford@gmail.com> wrote:
Adding bfcpbis.<= div>
You raise a good point Roman - there=E2=80=99s no defini= tion of how to actually use ICE with BFCP at the protocol level - this only= came up in some very late reviews of 4582bis. The initial suggestion was t= o use the same text as in=C2=A0draft-ietf-mmusic-sctp-sdp-19, but it t= hen raised the point that, given BFCP does not have a MTI protocol, if the = offerer supported both they would include their preferred option, but if th= e receiver supported the other variant, there=E2=80=99s no way to immediate= ly negotiate that without a re-INVITE.

Christer=E2= =80=99s suggestion to relax the requirement that the m-line protocol in = the answer=C2=A0matches one of the ICE candidates would support the cas= e where the offerer supports both but prefers UDP, but the answerer only su= pports TCP. Although no implementations currently do ICE here, this relaxat= ion would leave the door open to gaining this negotiation flexibility in bf= cpbis implementations. There seems no reason to have this requirement appli= ed to the answer in the first place.

I don=E2=80= =99t understand the comment about SBCs; today, tcp candidates are used for = media and data channels end-to-end in WebRTC, to name but one implementatio= n.

Regards,
Alan

On 17 Nov 2016, at 03:05, Roman Shpount <roman@telurix.com> wrote:
Adding ICE group to this message.
<= br>
The approach always was that tcp candidates can potentially go onl= y as far as SBC and then be terminated by UDP transport. Because of this ev= erything transmitted over tcp candidate was still considered to be transmit= ted over the unreliable out-of-order transport. It is also assumed that can= didates can switch from UDP to TCP based candidate during nomination. This = is why, for instance, we run DTLS with RFC4571 framing over tcp candidates,= not TLS. Because of this I always thought that ICE is UDP first with addit= ional TCP transports for situation when UDP will not work. So, as a result,= I think ICE-bis should specify that UDP MUST be supported and default cand= idate MUST be UDP. ICE SDP can reflect this, but I think this is the underl= ying protocol requirement.

I also wanted to add that BFC= P needs to examine how ICE support is implemented by this protocol. I think= it is not covered in the current drafts. I also think I do not think it is= possible for TCP/BFCP to=C2=A0run over ICE. On the other hand UDP/DTLS/BFC= P and TCP/DTLS/BFCP would trivial based on current DTLS work.

Regards,
_____________
Roman Shpount

On Wed, Nov 16, 2016 at 8:44 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wr= ote:

I have no probl= em with Roman=E2=80=99s must-support-UDP suggestion. I guess the question i= s whether the BFCP folks could accept that. Cullen did say that TCP-based BFCP deployments have been around for a decade. But= , do they support ICE?

= =C2=A0

If we decide to move= forward with such approach, we need to ask ourselves whether must-support-= UDP should be an ICE requirement (in which case the suggestion should be brought to the ICE WG) or whether it s= hould only be an ICE-using-SIP-SDP requirement.

=C2=A0

Regards,

=C2=A0

Christer

= =C2=A0

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 17 November 2016 00:52
To: mmusic@ietf= .org
Subject: [MMUSIC] m=3D line protocol in case of ICE

=C2=A0

Hi All,

=C2=A0

I just wanted to return to the m=3D line protoc= ol issue that Christer raised during the last MMUSIC session.=

=C2=A0

All the ICE implementations I've seen are p= rimarily UDP based with support for tcp host candidates which are primarily= used to connect to end points on public IP. If all ICE implementations are= continue to be primarily UDP based, then the simplest solution would be to require UDP support when any given protocol = is implemented over ICE. DTLS and RTP are already primarily UDP based so th= is is a non-requirement. Even more, all protocols that are implemented on t= op of ICE must assume that underling transports (including tcp candidates) are unreliable, since candidate pair= can change at any time between reliable and unreliable transports, so this= makes them different from protocols implemented on plain TCP or TLS.

=C2=A0

So the first question I wanted to ask is anybod= y interested in TCP only ICE implementation where the protocol running on t= op of such implementation relies on the reliable delivery of underlying mes= sages? By this I mean, does anybody wants implement TCP based ICE, with simultaneous open, reflexive and relay candi= dates in such a way that ICE implementation will run from behind NAT withou= t ever needing a UDP candidate?

=C2=A0

I understand that BFCP was used for a long time= , but I do not think TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I = think only UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE.= =C2=A0

=C2=A0

I think both=C2=A0rfc4582bis and rfc4583bis nee= d a careful review and additional sections that describe ICE considerations= . I think the most obvious thing would be to specify that ICE can only be s= upported by UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which case RFC4571 is used when tcp candidates are us= ed. Furthermore, when tcp candidate is selected with UDP/BFCP transport, it= is not the same thing as using TCP/BFCP and will need a different transpor= t tag (something like TCP/UDP/BFCP). Alternatively we can require that only secure versions of BFCP are used wi= th ICE and only allow ICE usage for UDP/DTLS/BFCP and TCP/DTLS/BFCP.=

=C2=A0

To conclude, I would argue that the simplest so= lution would be that for all protocols implemented on top of ICE, UDP MUST = be supported and default candidates MUST be UDP based. This avoids building= uncomfortable artificial constructs to avoid ICE mismatch and requires minimal changes to existing specifications= .

=C2=A0

Regards,

_____________
Roman Shpount


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



--001a11404b3290a43e0541c3d344-- From nobody Sun Nov 20 15:28:14 2016 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 8A64B12946D for ; Sun, 20 Nov 2016 15:28:10 -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, 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=aliax-net.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 cLdwH3tEZC_m for ; Sun, 20 Nov 2016 15:28:08 -0800 (PST) Received: from mail-wj0-x234.google.com (mail-wj0-x234.google.com [IPv6:2a00:1450:400c:c01::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 0A9C61293E3 for ; Sun, 20 Nov 2016 15:28:08 -0800 (PST) Received: by mail-wj0-x234.google.com with SMTP id v7so19838311wjy.2 for ; Sun, 20 Nov 2016 15:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vzBmfAOvxxZIB9aJXSNpaOqgQ4liCxBsvTKG+v3QcFE=; b=ZgCAa2BAyjG+1RbDEL8iEiax47nBgT1OfcPDXxbd4rYL7rdcAd8ELNXSUmMH2JvO2C YL+P6Uwv/LIDQxg8qCJeBGMTANe4Y29FCBqM9k80859YSfRHQfSFdXhJIpa+gtdo930e 4KaaPoJn4pqoSWiWSTQkEuVtzCjaPyGV2RtS12ggs6Ju0EWJjT46wVvy4Bk6/HA0EeVb M+6QNK3EaXJO2B9CQ1bRvEmcmuZKCi7OyWCovL7mEmOkpSAOPhPspqiw0gvLM8ehm3fE KvR6Q9tfpGrpGvnBcJRG7nbi+LyrnJ5WTdAdR02plJspARUU8U0WMcVPN5Lf9tket+nK xzbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vzBmfAOvxxZIB9aJXSNpaOqgQ4liCxBsvTKG+v3QcFE=; b=NjGkU/R8QGJLooCKccKImENxlI0QkULarOM/PxlRVUhTEOS7SHyJLmA2/rmIl41+NB gyQKjS0ggfoi7Nv9t3uO2/60OnUQPg5HdSsY0LOsJlNRbW7UKQxWgPlTbjWXguXfRjHJ ec/ucgD55F5mj0r3LXFA6YJiUSV6tPo8iGfzxFl2ROQAf2Ws2jDLONgfncqxBP18OvIa 4SfkrjdEqql98cJf3MnVZJy/VsVBJwulQTm96n3Bvu3l4krgyB5Gv+ujB3LE6jfZAdz9 tXYjeP8Tt8cRN15ZKbnrpVgH1Xf72j2/wt8HF5xQNxF8W5V59qgM2RvNowAx6qDLF7aw FBGQ== X-Gm-Message-State: AKaTC0040wM2E11jsbWB2OstCELiaDnUxBsn418sSZrzAknhLlG4WkzuMUt6G49JbNTpPINmFXWZCkG1sHhYIA== X-Received: by 10.194.222.202 with SMTP id qo10mr6921781wjc.115.1479684486601; Sun, 20 Nov 2016 15:28:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.23.196 with HTTP; Sun, 20 Nov 2016 15:27:46 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 21 Nov 2016 00:27:46 +0100 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ice@ietf.org, bfcpbis@ietf.org, Christer Holmberg , "mmusic@ietf.org" , Alan Ford Subject: Re: [Ice] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 23:28:10 -0000 2016-11-21 0:23 GMT+01:00 Roman Shpount : > I just wanted to add to my previous email, that according to RFC 6544 > protocols running over tcp candidates MUST use RFC 4571 framing > (https://tools.ietf.org/html/rfc6544#section-10.1). This means that BFCP > running over tcp candidate is not TCP/BFCP and will require a different > transport tag. IMHO the exact transport is just "ICE". ICE itself is a "virtual transport" that can use many "real transports" (UDP, TCP+RFC4571, etc). So ICE/BFCP would be my way to go. --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 21 01:25:56 2016 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 55BF71298A6; Mon, 21 Nov 2016 01:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUC7GBCvHqHr; Mon, 21 Nov 2016 01:25:51 -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 737A61298A0; Mon, 21 Nov 2016 01:25:50 -0800 (PST) X-AuditID: c1b4fb25-ec9d598000007ee2-e6-5832bd9c9ab0 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id DC.0D.32482.C9DB2385; Mon, 21 Nov 2016 10:25:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Mon, 21 Nov 2016 10:25:47 +0100 From: Christer Holmberg To: Roman Shpount , Alan Ford Thread-Topic: [MMUSIC] m= line protocol in case of ICE Thread-Index: AQHSQFwT8S0xdJKeakq1+K6kpgEs7aDcZjMAgAAHVICAAXMfAIAAEJmAgASHdQCAALfl8A== Date: Mon, 21 Nov 2016 09:25:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE823C9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE823C9ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7ge6cvUYRBgfn6lusPLeC2eLfuqNM Ft8u1FpMXf6YxWLGhanMDqweO2fdZfdYsuQnk8etKQUBzFFcNimpOZllqUX6dglcGY/aVjMX TLnFVPHw1nS2BsYJF5m6GDk5JARMJObdbGXvYuTiEBJYxygxbcUMKGcxo8Sna8uZuxg5ONgE LCS6/2mDmCICbhKT95iB9DIL5Etc33+TGcQWFjCV2HT8MhuILSJgJrF54RJGiPIwiY8PPUBM FgFViXU33UEqeAV8JY483M8KsWgOs8SGnrVgYzgFAiX+vD3AAmIzCohJfD+1hglilbjErSfz oU4WkFiy5zwzhC0q8fLxP1YIW0micckTVpjTvny/wAaxTFDi5MwnLBMYRWYhGTULSdksJGWz gE5lFtCUWL9LH6JEUWJK90N2CFtDonXOXHZk8QWM7KsYRYtTi5Ny042M9VKLMpOLi/Pz9PJS SzYxAiPv4JbfqjsYL79xPMQowMGoxMNbcNMgQog1say4MvcQowQHs5II74Q9RhFCvCmJlVWp RfnxRaU5qcWHGKU5WJTEec1W3g8XEkhPLEnNTk0tSC2CyTJxcEo1MMY7bnF1U938I/N148Wq kvKOtQ3zkifYqiUxxmrZbWEMDbw26UptC0PO8r3a+QvqjyYXnz9TICvEf3rGX8XzgdH2CXYr Za+2iZww6JRt3eErYXu4fhnv7Pu9M5dWc+9/vP3k+40sly8omdm4+J/eZCgZ0rLsy4Szovdv dbz7V/m7V7zX+cDcJ0osxRmJhlrMRcWJAPSFtme4AgAA Archived-At: Cc: "bfcpbis@ietf.org" , "mmusic@ietf.org" , "ice@ietf.org" Subject: Re: [Ice] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 09:25:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE823C9ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQoNCkdvb2QgY2F0Y2guDQoNClRoYXQgYmFzaWNhbGx5IG1lYW5zIHRoYXQgYmZj cGJpcyB3b3VsZCBoYXZlIHRvIGRvY3VtZW50IHRoZSB1c2FnZSBvZiBmcmFtaW5nIGZvciBCRkNQ LVRDUCDigJMgYXNzdW1pbmcgdGhleSB3YW50IEJGQ1AtVENQIHRvIHdvcmsgd2l0aCBJQ0UuDQoN CkkgYXNzdW1lIHRoZSBzYW1lIGFwcGxpZXMgdG8gTVNSUCAod2hlbiBub3QgdXNpbmcgYW4gTVNS UCByZWxheSkuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTogUm9tYW4gU2hwb3Vu dCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KU2VudDogMjEgTm92ZW1iZXIgMjAxNiAwMToy Mw0KVG86IEFsYW4gRm9yZCA8YWxhbi5mb3JkQGdtYWlsLmNvbT4NCkNjOiBDaHJpc3RlciBIb2xt YmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgbW11c2ljQGlldGYub3JnOyBp Y2VAaWV0Zi5vcmc7IGJmY3BiaXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBtPSBs aW5lIHByb3RvY29sIGluIGNhc2Ugb2YgSUNFDQoNCkhpIEFsbCwNCg0KSSBqdXN0IHdhbnRlZCB0 byBhZGQgdG8gbXkgcHJldmlvdXMgZW1haWwsIHRoYXQgYWNjb3JkaW5nIHRvIFJGQyA2NTQ0IHBy b3RvY29scyBydW5uaW5nIG92ZXIgdGNwIGNhbmRpZGF0ZXMgTVVTVCB1c2UgIFJGQyA0NTcxIGZy YW1pbmcgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTQ0I3NlY3Rpb24tMTAuMSku IFRoaXMgbWVhbnMgdGhhdCBCRkNQIHJ1bm5pbmcgb3ZlciB0Y3AgY2FuZGlkYXRlIGlzIG5vdCBU Q1AvQkZDUCBhbmQgd2lsbCByZXF1aXJlIGEgZGlmZmVyZW50IHRyYW5zcG9ydCB0YWcuDQoNClJl Z2FyZHMsDQoNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gVGh1LCBOb3YgMTcs IDIwMTYgYXQgOToxMyBQTSwgUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRv OnJvbWFuQHRlbHVyaXguY29tPj4gd3JvdGU6DQpIaSBBbGwsDQoNClRoZXJlIGFyZSB0aHJlZSBj b21tZW50cyBJIHdhbnRlZCB0byBtYWtlIHJlZ2FyZGluZyBnZW5lcmFsIG5hdHVyZSBvZiBhbGwg ZXhpc3RpbmcgcHJvdG9jb2xzIGRlc2lnbmVkIHRvIHdvcmsgSUNFDQoNCjEuIFByb3RvY29scyBy dW5uaW5nIG9uIHRvcCBvZiBJQ0UgYXNzdW1lIHRoYXQgcmVnYXJkbGVzcyB3aGF0IGNhbmRpZGF0 ZSBwYWlyIGlzIHVzZWQsIGluY2x1ZGluZyB0Y3AgY2FuZGlkYXRlcywgdGhlIHVuZGVybHlpbmcg bmV0d29yayB0cmFuc3BvcnQgaXMgdW5vcmRlcmVkIGFuZCB1bnJlbGlhYmxlLiBEdXJpbmcgbm9t aW5hdGlvbiwgaW5jbHVkaW5nIGNvbnRpbnVvdXMgbm9taW5hdGlvbiwgY2FuZGlkYXRlIHBhaXJz IGNhbiBzd2l0Y2gsIGluY2x1ZGluZyBzd2l0Y2hpbmcgZnJvbSB1ZHAgdG8gdGNwIG9yIGZyb20g dGNwIHRvIHVkcC4gVGhpcyB0eXBpY2FsbHkgbWVhbnMgdGhhdCBwcm90b2NvbCByZS10cmFuc21p dCB0aW1lcnMgYXJlIG9wZXJhdGlvbmFsLCBwYWNrZXRzIGFyZSByZS1vcmRlcmVkIGF0IHRoZSBw cm90b2NvbCBsZXZlbCwgYW5kICBVRFAtZnJpZW5kbHkgcGFja2V0IHNpemVzIGFyZSB1c2VkIGV2 ZW4gd2hlbiBwYWNrZXRzIGFyZSBzZW50IG92ZXIgdGNwIGNhbmRpZGF0ZXMuIEZvciBpbnN0YW5j ZSBEVExTIGFuZCBTQ1RQIHJlLXRyYW5zbWl0IHRpbWVycywgcmVvcmRlcmluZywgYW5kIGZyYWdt ZW50YXRpb24gc3VwcG9ydCBhcmUgc3RpbGwgcnVubmluZyB3aGVuIHRjcCBjYW5kaWRhdGVzIGFy ZSB1c2VkLg0KDQoyLiBQcm90b2NvbHMgZG8gbm90IGFzc3VtZSB0aGF0IHBhcnRpY3VsYXIgY2Fu ZGlkYXRlIG5ldHdvcmsgdHJhbnNwb3J0IHJ1bnMgYWxsIHRoZSB3YXkgZnJvbSBvcmlnaW5hdGlv biB0byBmaW5hbCBkZXN0aW5hdGlvbiBvZiB0aGUgcHJvdG9jb2wgcGFja2V0cy4gRm9yIGluc3Rh bmNlIHRoZXJlIGFyZSBTQkMgd2hpY2ggb25seSBoYW5kbGUgSUNFLiBUaGVzZSBTQkMgcnVuIHRo ZSBJQ0Ugc3RhdGUgbWFjaGluZSBhbmQgdGhlbiB0cmFuc21pdCB0aGUgdW5kZXJseWluZyBwcm90 b2NvbCBkYXRhIHRvIHRoZSBmaW5hbCBkZXN0aW5hdGlvbiB1c2luZyBwdWJsaWMgSVAuIEJlY2F1 c2Ugb2YgdGhpcywgaXQgaXMgbm90IHVudXN1YWwgZm9yIFJUUCB0byBydW4gb3ZlciB0Y3AgY2Fu ZGlkYXRlIHVudGlsIFNCQyBhbmQgdGhlbiBydW4gb3ZlciBVRFAgdG8gdGhlIGZpbmFsIGRlc3Rp bmF0aW9uLiBUaGlzIGlzIG9uZSBtb3JlIHJlYXNvbiB3aHkgcmUtdHJhbnNtaXQgdGltZXJzIGFu ZCBvdGhlciBtZWNoYW5pc21zIHVzZWQgdG8gZGVhbCB3aXRoIFVEUCBhcmUgc3RpbGwgcnVubmlu ZyBvdmVyIHRjcCBjYW5kaWRhdGVzLg0KDQozLiBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgY3VycmVu dCBwcm90b2NvbCBydW5uaW5nIG92ZXIgSUNFIHRjcCBjYW5kaWRhdGVzIHdoaWNoIGlzIG5vdCB1 c2luZyBSRkM0NTcxIGZyYW1pbmcuIEZvciBpbnN0YW5jZSBEVExTIGNvdWxkIGhhdmUgYmVlbiBp bXBsZW1lbnRlZCB1c2luZyBEVExTIHByb3RvY29sIGZyYW1pbmcgd2l0aG91dCBSRkM0NTcxIG92 ZXIgdGNwIGNhbmRpZGF0ZXMsIGJ1dCB0aGlzIHdhcyBub3QgdGhlIGNhc2UuIFRoaXMgaXMgcGFy dGlhbGx5IGRvbmUgdG8gc2ltcGxpZnkgaW1wbGVtZW50YXRpb24gb2YgU0JDIHdoaWNoIHRlcm1p bmF0ZSBJQ0UgYW5kIHRyYW5zbWl0IHByb3RvY29sIGRhdGEgdXNpbmcgVURQLiBCeSB1c2luZyBS RkMgNDU3MSBmcmFtaW5nLCBTQkMgY2FuIHBhY2tldGl6ZS9kZS1wYWNrZXRpemUgZGF0YSB0cmFu c21pdHRlZCBvdmVyIHRjcCBjYW5kaWRhdGVzIHdpdGhvdXQga25vd2luZyBwcm90b2NvbCBkZXRh aWxzLg0KDQpUbyBjb25jbHVkZSwgdXAgdW50aWwgdGhpcyBwb2ludCBJQ0UgdGNwIGNhbmRpZGF0 ZXMgd2VyZSBub3QgdHJlYXRlZCBhcyByZWxpYWJsZSB0cmFuc3BvcnQgYW5kIHNlcnZlZCBzaW1w bHkgYXMgYW5vdGhlciB3YXkgdG8gdHJhbnNtaXQgVURQIHBhY2tldHMgdGhyb3VnaCBmaXJld2Fs bHMuIEJlY2F1c2Ugb2YgdGhpcywgSSB3b3VsZCBhcmd1ZSB0aGF0IEJGQ1AgcnVubmluZyBvdmVy IHRjcCBjYW5kaWRhdGUgaXMgbm90IHRoZSBzYW1lIGFzIFRDUC9CRkNQLCBpbiB0aGUgc2FtZSB3 YXkgYXMgRFRMUyBydW5uaW5nIG92ZXIgdGNwIGNhbmRpZGF0ZSBpcyBub3QgVExTLg0KDQpJIHdv dWxkIGFsc28gYXJndWUgdGhhdCBhbnkgcHJvdG9jb2wgcnVubmluZyBvdmVyIElDRSBpcywgaW4g ZXNzZW5jZSwgYSBVRFAgYmFzZWQgcHJvdG9jb2wsIHVzaW5nIHRjcCBjYW5kaWRhdGVzIG9ubHkg YXMgYSBmYWxsIGJhY2sgbWVjaGFuaXNtIGZvciBmaXJld2FsbCB0cmF2ZXJzYWwsIHNhbWUgd2F5 IGFzIHdoZW4gZGF0YSBpcyByZWxheWVkIG92ZXIgVFVSTiBUQ1AsIGl0IGlzIHN0aWxsIGNvbnNp ZGVyZWQgc2VudCBvdmVyIFVEUCBhdCB0aGUgcHJvdG9jb2wgbGV2ZWwuDQoNCklmIElDRSBncm91 cCBhZ3JlZXMsIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgZG9jdW1lbnRlZCBieSBzYXlpbmcgdGhh dCBVRFAgaXMgYSBNVVNUIGltcGxlbWVudCBmb3IgYW55IHByb3RvY29sIHVzaW5nIElDRSBhbmQg dGhhdCBkZWZhdWx0IGNhbmRpZGF0ZSBzaG91bGQgYmUgVURQIGJhc2VkLg0KDQpSZWdhcmRzLA0K X19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQpPbiBUaHUsIE5vdiAxNywgMjAxNiBhdCA4 OjE0IFBNLCBBbGFuIEZvcmQgPGFsYW4uZm9yZEBnbWFpbC5jb208bWFpbHRvOmFsYW4uZm9yZEBn bWFpbC5jb20+PiB3cm90ZToNCkFkZGluZyBiZmNwYmlzLg0KDQpZb3UgcmFpc2UgYSBnb29kIHBv aW50IFJvbWFuIC0gdGhlcmXigJlzIG5vIGRlZmluaXRpb24gb2YgaG93IHRvIGFjdHVhbGx5IHVz ZSBJQ0Ugd2l0aCBCRkNQIGF0IHRoZSBwcm90b2NvbCBsZXZlbCAtIHRoaXMgb25seSBjYW1lIHVw IGluIHNvbWUgdmVyeSBsYXRlIHJldmlld3Mgb2YgNDU4MmJpcy4gVGhlIGluaXRpYWwgc3VnZ2Vz dGlvbiB3YXMgdG8gdXNlIHRoZSBzYW1lIHRleHQgYXMgaW4gZHJhZnQtaWV0Zi1tbXVzaWMtc2N0 cC1zZHAtMTksIGJ1dCBpdCB0aGVuIHJhaXNlZCB0aGUgcG9pbnQgdGhhdCwgZ2l2ZW4gQkZDUCBk b2VzIG5vdCBoYXZlIGEgTVRJIHByb3RvY29sLCBpZiB0aGUgb2ZmZXJlciBzdXBwb3J0ZWQgYm90 aCB0aGV5IHdvdWxkIGluY2x1ZGUgdGhlaXIgcHJlZmVycmVkIG9wdGlvbiwgYnV0IGlmIHRoZSBy ZWNlaXZlciBzdXBwb3J0ZWQgdGhlIG90aGVyIHZhcmlhbnQsIHRoZXJl4oCZcyBubyB3YXkgdG8g aW1tZWRpYXRlbHkgbmVnb3RpYXRlIHRoYXQgd2l0aG91dCBhIHJlLUlOVklURS4NCg0KQ2hyaXN0 ZXLigJlzIHN1Z2dlc3Rpb24gdG8gcmVsYXggdGhlIHJlcXVpcmVtZW50IHRoYXQgdGhlIG0tbGlu ZSBwcm90b2NvbCBpbiB0aGUgYW5zd2VyIG1hdGNoZXMgb25lIG9mIHRoZSBJQ0UgY2FuZGlkYXRl cyB3b3VsZCBzdXBwb3J0IHRoZSBjYXNlIHdoZXJlIHRoZSBvZmZlcmVyIHN1cHBvcnRzIGJvdGgg YnV0IHByZWZlcnMgVURQLCBidXQgdGhlIGFuc3dlcmVyIG9ubHkgc3VwcG9ydHMgVENQLiBBbHRo b3VnaCBubyBpbXBsZW1lbnRhdGlvbnMgY3VycmVudGx5IGRvIElDRSBoZXJlLCB0aGlzIHJlbGF4 YXRpb24gd291bGQgbGVhdmUgdGhlIGRvb3Igb3BlbiB0byBnYWluaW5nIHRoaXMgbmVnb3RpYXRp b24gZmxleGliaWxpdHkgaW4gYmZjcGJpcyBpbXBsZW1lbnRhdGlvbnMuIFRoZXJlIHNlZW1zIG5v IHJlYXNvbiB0byBoYXZlIHRoaXMgcmVxdWlyZW1lbnQgYXBwbGllZCB0byB0aGUgYW5zd2VyIGlu IHRoZSBmaXJzdCBwbGFjZS4NCg0KSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIGNvbW1lbnQgYWJv dXQgU0JDczsgdG9kYXksIHRjcCBjYW5kaWRhdGVzIGFyZSB1c2VkIGZvciBtZWRpYSBhbmQgZGF0 YSBjaGFubmVscyBlbmQtdG8tZW5kIGluIFdlYlJUQywgdG8gbmFtZSBidXQgb25lIGltcGxlbWVu dGF0aW9uLg0KDQpSZWdhcmRzLA0KQWxhbg0KDQpPbiAxNyBOb3YgMjAxNiwgYXQgMDM6MDUsIFJv bWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+ IHdyb3RlOg0KDQpBZGRpbmcgSUNFIGdyb3VwIHRvIHRoaXMgbWVzc2FnZS4NCg0KVGhlIGFwcHJv YWNoIGFsd2F5cyB3YXMgdGhhdCB0Y3AgY2FuZGlkYXRlcyBjYW4gcG90ZW50aWFsbHkgZ28gb25s eSBhcyBmYXIgYXMgU0JDIGFuZCB0aGVuIGJlIHRlcm1pbmF0ZWQgYnkgVURQIHRyYW5zcG9ydC4g QmVjYXVzZSBvZiB0aGlzIGV2ZXJ5dGhpbmcgdHJhbnNtaXR0ZWQgb3ZlciB0Y3AgY2FuZGlkYXRl IHdhcyBzdGlsbCBjb25zaWRlcmVkIHRvIGJlIHRyYW5zbWl0dGVkIG92ZXIgdGhlIHVucmVsaWFi bGUgb3V0LW9mLW9yZGVyIHRyYW5zcG9ydC4gSXQgaXMgYWxzbyBhc3N1bWVkIHRoYXQgY2FuZGlk YXRlcyBjYW4gc3dpdGNoIGZyb20gVURQIHRvIFRDUCBiYXNlZCBjYW5kaWRhdGUgZHVyaW5nIG5v bWluYXRpb24uIFRoaXMgaXMgd2h5LCBmb3IgaW5zdGFuY2UsIHdlIHJ1biBEVExTIHdpdGggUkZD NDU3MSBmcmFtaW5nIG92ZXIgdGNwIGNhbmRpZGF0ZXMsIG5vdCBUTFMuIEJlY2F1c2Ugb2YgdGhp cyBJIGFsd2F5cyB0aG91Z2h0IHRoYXQgSUNFIGlzIFVEUCBmaXJzdCB3aXRoIGFkZGl0aW9uYWwg VENQIHRyYW5zcG9ydHMgZm9yIHNpdHVhdGlvbiB3aGVuIFVEUCB3aWxsIG5vdCB3b3JrLiBTbywg YXMgYSByZXN1bHQsIEkgdGhpbmsgSUNFLWJpcyBzaG91bGQgc3BlY2lmeSB0aGF0IFVEUCBNVVNU IGJlIHN1cHBvcnRlZCBhbmQgZGVmYXVsdCBjYW5kaWRhdGUgTVVTVCBiZSBVRFAuIElDRSBTRFAg Y2FuIHJlZmxlY3QgdGhpcywgYnV0IEkgdGhpbmsgdGhpcyBpcyB0aGUgdW5kZXJseWluZyBwcm90 b2NvbCByZXF1aXJlbWVudC4NCg0KSSBhbHNvIHdhbnRlZCB0byBhZGQgdGhhdCBCRkNQIG5lZWRz IHRvIGV4YW1pbmUgaG93IElDRSBzdXBwb3J0IGlzIGltcGxlbWVudGVkIGJ5IHRoaXMgcHJvdG9j b2wuIEkgdGhpbmsgaXQgaXMgbm90IGNvdmVyZWQgaW4gdGhlIGN1cnJlbnQgZHJhZnRzLiBJIGFs c28gdGhpbmsgSSBkbyBub3QgdGhpbmsgaXQgaXMgcG9zc2libGUgZm9yIFRDUC9CRkNQIHRvIHJ1 biBvdmVyIElDRS4gT24gdGhlIG90aGVyIGhhbmQgVURQL0RUTFMvQkZDUCBhbmQgVENQL0RUTFMv QkZDUCB3b3VsZCB0cml2aWFsIGJhc2VkIG9uIGN1cnJlbnQgRFRMUyB3b3JrLg0KDQpSZWdhcmRz LA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQpPbiBXZWQsIE5vdiAxNiwgMjAxNiBh dCA4OjQ0IFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkkgaGF2 ZSBubyBwcm9ibGVtIHdpdGggUm9tYW7igJlzIG11c3Qtc3VwcG9ydC1VRFAgc3VnZ2VzdGlvbi4g SSBndWVzcyB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB0aGUgQkZDUCBmb2xrcyBjb3VsZCBhY2Nl cHQgdGhhdC4gQ3VsbGVuIGRpZCBzYXkgdGhhdCBUQ1AtYmFzZWQgQkZDUCBkZXBsb3ltZW50cyBo YXZlIGJlZW4gYXJvdW5kIGZvciBhIGRlY2FkZS4gQnV0LCBkbyB0aGV5IHN1cHBvcnQgSUNFPw0K DQpJZiB3ZSBkZWNpZGUgdG8gbW92ZSBmb3J3YXJkIHdpdGggc3VjaCBhcHByb2FjaCwgd2UgbmVl ZCB0byBhc2sgb3Vyc2VsdmVzIHdoZXRoZXIgbXVzdC1zdXBwb3J0LVVEUCBzaG91bGQgYmUgYW4g SUNFIHJlcXVpcmVtZW50IChpbiB3aGljaCBjYXNlIHRoZSBzdWdnZXN0aW9uIHNob3VsZCBiZSBi cm91Z2h0IHRvIHRoZSBJQ0UgV0cpIG9yIHdoZXRoZXIgaXQgc2hvdWxkIG9ubHkgYmUgYW4gSUNF LXVzaW5nLVNJUC1TRFAgcmVxdWlyZW1lbnQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZy b206IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptbXVzaWMt Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBSb21hbiBTaHBvdW50DQpTZW50OiAxNyBO b3ZlbWJlciAyMDE2IDAwOjUyDQpUbzogbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBbTU1VU0lDXSBtPSBsaW5lIHByb3RvY29sIGluIGNhc2Ugb2YgSUNF DQoNCkhpIEFsbCwNCg0KSSBqdXN0IHdhbnRlZCB0byByZXR1cm4gdG8gdGhlIG09IGxpbmUgcHJv dG9jb2wgaXNzdWUgdGhhdCBDaHJpc3RlciByYWlzZWQgZHVyaW5nIHRoZSBsYXN0IE1NVVNJQyBz ZXNzaW9uLg0KDQpBbGwgdGhlIElDRSBpbXBsZW1lbnRhdGlvbnMgSSd2ZSBzZWVuIGFyZSBwcmlt YXJpbHkgVURQIGJhc2VkIHdpdGggc3VwcG9ydCBmb3IgdGNwIGhvc3QgY2FuZGlkYXRlcyB3aGlj aCBhcmUgcHJpbWFyaWx5IHVzZWQgdG8gY29ubmVjdCB0byBlbmQgcG9pbnRzIG9uIHB1YmxpYyBJ UC4gSWYgYWxsIElDRSBpbXBsZW1lbnRhdGlvbnMgYXJlIGNvbnRpbnVlIHRvIGJlIHByaW1hcmls eSBVRFAgYmFzZWQsIHRoZW4gdGhlIHNpbXBsZXN0IHNvbHV0aW9uIHdvdWxkIGJlIHRvIHJlcXVp cmUgVURQIHN1cHBvcnQgd2hlbiBhbnkgZ2l2ZW4gcHJvdG9jb2wgaXMgaW1wbGVtZW50ZWQgb3Zl ciBJQ0UuIERUTFMgYW5kIFJUUCBhcmUgYWxyZWFkeSBwcmltYXJpbHkgVURQIGJhc2VkIHNvIHRo aXMgaXMgYSBub24tcmVxdWlyZW1lbnQuIEV2ZW4gbW9yZSwgYWxsIHByb3RvY29scyB0aGF0IGFy ZSBpbXBsZW1lbnRlZCBvbiB0b3Agb2YgSUNFIG11c3QgYXNzdW1lIHRoYXQgdW5kZXJsaW5nIHRy YW5zcG9ydHMgKGluY2x1ZGluZyB0Y3AgY2FuZGlkYXRlcykgYXJlIHVucmVsaWFibGUsIHNpbmNl IGNhbmRpZGF0ZSBwYWlyIGNhbiBjaGFuZ2UgYXQgYW55IHRpbWUgYmV0d2VlbiByZWxpYWJsZSBh bmQgdW5yZWxpYWJsZSB0cmFuc3BvcnRzLCBzbyB0aGlzIG1ha2VzIHRoZW0gZGlmZmVyZW50IGZy b20gcHJvdG9jb2xzIGltcGxlbWVudGVkIG9uIHBsYWluIFRDUCBvciBUTFMuDQoNClNvIHRoZSBm aXJzdCBxdWVzdGlvbiBJIHdhbnRlZCB0byBhc2sgaXMgYW55Ym9keSBpbnRlcmVzdGVkIGluIFRD UCBvbmx5IElDRSBpbXBsZW1lbnRhdGlvbiB3aGVyZSB0aGUgcHJvdG9jb2wgcnVubmluZyBvbiB0 b3Agb2Ygc3VjaCBpbXBsZW1lbnRhdGlvbiByZWxpZXMgb24gdGhlIHJlbGlhYmxlIGRlbGl2ZXJ5 IG9mIHVuZGVybHlpbmcgbWVzc2FnZXM/IEJ5IHRoaXMgSSBtZWFuLCBkb2VzIGFueWJvZHkgd2Fu dHMgaW1wbGVtZW50IFRDUCBiYXNlZCBJQ0UsIHdpdGggc2ltdWx0YW5lb3VzIG9wZW4sIHJlZmxl eGl2ZSBhbmQgcmVsYXkgY2FuZGlkYXRlcyBpbiBzdWNoIGEgd2F5IHRoYXQgSUNFIGltcGxlbWVu dGF0aW9uIHdpbGwgcnVuIGZyb20gYmVoaW5kIE5BVCB3aXRob3V0IGV2ZXIgbmVlZGluZyBhIFVE UCBjYW5kaWRhdGU/DQoNCkkgdW5kZXJzdGFuZCB0aGF0IEJGQ1Agd2FzIHVzZWQgZm9yIGEgbG9u ZyB0aW1lLCBidXQgSSBkbyBub3QgdGhpbmsgVENQL0JGQ1Agb3IgVENQL1RMUy9CRkNQIGNhbiBl dmVuIGJlIHVzZWQgd2l0aCBJQ0UuIEkgdGhpbmsgb25seSBVRFAvQkZDUCwgVURQL0RUTFMvQkZD UCBhbmQgVENQL0RUTFMvQkZDUCBjYW4gZXZlbiBzdXBwb3J0IElDRS4NCg0KSSB0aGluayBib3Ro IHJmYzQ1ODJiaXMgYW5kIHJmYzQ1ODNiaXMgbmVlZCBhIGNhcmVmdWwgcmV2aWV3IGFuZCBhZGRp dGlvbmFsIHNlY3Rpb25zIHRoYXQgZGVzY3JpYmUgSUNFIGNvbnNpZGVyYXRpb25zLiBJIHRoaW5r IHRoZSBtb3N0IG9idmlvdXMgdGhpbmcgd291bGQgYmUgdG8gc3BlY2lmeSB0aGF0IElDRSBjYW4g b25seSBiZSBzdXBwb3J0ZWQgYnkgVURQL0JGQ1AsIFVEUC9EVExTL0JGQ1AgYW5kIFRDUC9EVExT L0JGQ1AuIEl0IHdpbGwgYWxzbyBtZWFuIGluIHdoaWNoIGNhc2UgUkZDNDU3MSBpcyB1c2VkIHdo ZW4gdGNwIGNhbmRpZGF0ZXMgYXJlIHVzZWQuIEZ1cnRoZXJtb3JlLCB3aGVuIHRjcCBjYW5kaWRh dGUgaXMgc2VsZWN0ZWQgd2l0aCBVRFAvQkZDUCB0cmFuc3BvcnQsIGl0IGlzIG5vdCB0aGUgc2Ft ZSB0aGluZyBhcyB1c2luZyBUQ1AvQkZDUCBhbmQgd2lsbCBuZWVkIGEgZGlmZmVyZW50IHRyYW5z cG9ydCB0YWcgKHNvbWV0aGluZyBsaWtlIFRDUC9VRFAvQkZDUCkuIEFsdGVybmF0aXZlbHkgd2Ug Y2FuIHJlcXVpcmUgdGhhdCBvbmx5IHNlY3VyZSB2ZXJzaW9ucyBvZiBCRkNQIGFyZSB1c2VkIHdp dGggSUNFIGFuZCBvbmx5IGFsbG93IElDRSB1c2FnZSBmb3IgVURQL0RUTFMvQkZDUCBhbmQgVENQ L0RUTFMvQkZDUC4NCg0KVG8gY29uY2x1ZGUsIEkgd291bGQgYXJndWUgdGhhdCB0aGUgc2ltcGxl c3Qgc29sdXRpb24gd291bGQgYmUgdGhhdCBmb3IgYWxsIHByb3RvY29scyBpbXBsZW1lbnRlZCBv biB0b3Agb2YgSUNFLCBVRFAgTVVTVCBiZSBzdXBwb3J0ZWQgYW5kIGRlZmF1bHQgY2FuZGlkYXRl cyBNVVNUIGJlIFVEUCBiYXNlZC4gVGhpcyBhdm9pZHMgYnVpbGRpbmcgdW5jb21mb3J0YWJsZSBh cnRpZmljaWFsIGNvbnN0cnVjdHMgdG8gYXZvaWQgSUNFIG1pc21hdGNoIGFuZCByZXF1aXJlcyBt aW5pbWFsIGNoYW5nZXMgdG8gZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMuDQoNClJlZ2FyZHMsDQpf X19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5v cmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbW11c2ljDQoNCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B4BE823C9ESESSMB209erics_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5tLTYxNjg3MDQ2OTQ4ODQ4NTY0NTFnbWFpbC0NCgl7 bXNvLXN0eWxlLW5hbWU6bV8tNjE2ODcwNDY5NDg4NDg1NjQ1MWdtYWlsLTt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBSb21hbiw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkdvb2QgY2F0Y2guPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGF0IGJhc2ljYWxseSBtZWFucyB0 aGF0IGJmY3BiaXMgd291bGQgaGF2ZSB0byBkb2N1bWVudCB0aGUgdXNhZ2Ugb2YgZnJhbWluZyBm b3IgQkZDUC1UQ1Ag4oCTIGFzc3VtaW5nIHRoZXkgd2FudCBCRkNQLVRDUCB0byB3b3JrIHdpdGgN CiBJQ0UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGFzc3VtZSB0 aGUgc2FtZSBhcHBsaWVzIHRvIE1TUlAgKHdoZW4gbm90IHVzaW5nIGFuIE1TUlAgcmVsYXkpLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IDIxIE5vdmVtYmVyIDIwMTYgMDE6MjM8YnI+DQo8Yj5Ubzo8L2I+ IEFsYW4gRm9yZCAmbHQ7YWxhbi5mb3JkQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IENo cmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7OyBt bXVzaWNAaWV0Zi5vcmc7IGljZUBpZXRmLm9yZzsgYmZjcGJpc0BpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gbT0gbGluZSBwcm90b2NvbCBpbiBjYXNlIG9mIElDRTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFsbCw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkganVzdCB3YW50ZWQgdG8gYWRkIHRv IG15IHByZXZpb3VzIGVtYWlsLCB0aGF0IGFjY29yZGluZyB0byBSRkMgNjU0NCZuYnNwO3Byb3Rv Y29scyBydW5uaW5nIG92ZXIgdGNwIGNhbmRpZGF0ZXMgTVVTVCB1c2UgJm5ic3A7UkZDIDQ1NzEg ZnJhbWluZyAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY1NDQjc2Vj dGlvbi0xMC4xIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjU0NCNzZWN0aW9uLTEw LjE8L2E+KS4NCiBUaGlzIG1lYW5zIHRoYXQgQkZDUCBydW5uaW5nIG92ZXIgdGNwIGNhbmRpZGF0 ZSBpcyBub3QgVENQL0JGQ1AgYW5kIHdpbGwgcmVxdWlyZSBhIGRpZmZlcmVudCB0cmFuc3BvcnQg dGFnLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91 bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUs IE5vdiAxNywgMjAxNiBhdCA5OjEzIFBNLCBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWls dG86cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdldD0iX2JsYW5rIj5yb21hbkB0ZWx1cml4LmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSB0aHJlZSBjb21tZW50cyBJIHdhbnRlZCB0byBt YWtlIHJlZ2FyZGluZyBnZW5lcmFsIG5hdHVyZSBvZiBhbGwgZXhpc3RpbmcgcHJvdG9jb2xzIGRl c2lnbmVkIHRvIHdvcmsgSUNFPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4xLiBQcm90b2NvbHMgcnVubmluZyBvbiB0b3Agb2YgSUNFIGFzc3VtZSB0aGF0IHJl Z2FyZGxlc3Mgd2hhdCBjYW5kaWRhdGUgcGFpciBpcyB1c2VkLCBpbmNsdWRpbmcgdGNwIGNhbmRp ZGF0ZXMsIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgdHJhbnNwb3J0IGlzIHVub3JkZXJlZCBhbmQg dW5yZWxpYWJsZS4gRHVyaW5nIG5vbWluYXRpb24sIGluY2x1ZGluZyBjb250aW51b3VzIG5vbWlu YXRpb24sIGNhbmRpZGF0ZQ0KIHBhaXJzIGNhbiBzd2l0Y2gsIGluY2x1ZGluZyBzd2l0Y2hpbmcg ZnJvbSB1ZHAgdG8gdGNwIG9yIGZyb20gdGNwIHRvIHVkcC4gVGhpcyB0eXBpY2FsbHkgbWVhbnMg dGhhdCBwcm90b2NvbCByZS10cmFuc21pdCB0aW1lcnMgYXJlIG9wZXJhdGlvbmFsLCBwYWNrZXRz IGFyZSByZS1vcmRlcmVkIGF0IHRoZSBwcm90b2NvbCBsZXZlbCwgYW5kICZuYnNwO1VEUC1mcmll bmRseSBwYWNrZXQgc2l6ZXMgYXJlIHVzZWQgZXZlbiB3aGVuIHBhY2tldHMgYXJlIHNlbnQNCiBv dmVyIHRjcCBjYW5kaWRhdGVzLiBGb3IgaW5zdGFuY2UgRFRMUyBhbmQgU0NUUCByZS10cmFuc21p dCB0aW1lcnMsIHJlb3JkZXJpbmcsIGFuZCBmcmFnbWVudGF0aW9uIHN1cHBvcnQgYXJlIHN0aWxs IHJ1bm5pbmcgd2hlbiB0Y3AgY2FuZGlkYXRlcyBhcmUgdXNlZC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gUHJvdG9jb2xzIGRvIG5vdCBh c3N1bWUgdGhhdCBwYXJ0aWN1bGFyIGNhbmRpZGF0ZSBuZXR3b3JrIHRyYW5zcG9ydCBydW5zIGFs bCB0aGUgd2F5IGZyb20gb3JpZ2luYXRpb24gdG8gZmluYWwgZGVzdGluYXRpb24gb2YgdGhlIHBy b3RvY29sIHBhY2tldHMuIEZvciBpbnN0YW5jZSB0aGVyZSBhcmUgU0JDIHdoaWNoIG9ubHkgaGFu ZGxlIElDRS4gVGhlc2UgU0JDIHJ1biB0aGUgSUNFIHN0YXRlIG1hY2hpbmUNCiBhbmQgdGhlbiB0 cmFuc21pdCB0aGUgdW5kZXJseWluZyBwcm90b2NvbCBkYXRhIHRvIHRoZSBmaW5hbCBkZXN0aW5h dGlvbiB1c2luZyBwdWJsaWMgSVAuIEJlY2F1c2Ugb2YgdGhpcywgaXQgaXMgbm90IHVudXN1YWwg Zm9yIFJUUCB0byBydW4gb3ZlciB0Y3AgY2FuZGlkYXRlIHVudGlsIFNCQyBhbmQgdGhlbiBydW4g b3ZlciBVRFAgdG8gdGhlIGZpbmFsIGRlc3RpbmF0aW9uLiBUaGlzIGlzIG9uZSBtb3JlIHJlYXNv biB3aHkgcmUtdHJhbnNtaXQNCiB0aW1lcnMgYW5kIG90aGVyIG1lY2hhbmlzbXMgdXNlZCB0byBk ZWFsIHdpdGggVURQIGFyZSBzdGlsbCBydW5uaW5nIG92ZXIgdGNwIGNhbmRpZGF0ZXMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuIEkgYW0g bm90IGF3YXJlIG9mIGFueSBjdXJyZW50IHByb3RvY29sIHJ1bm5pbmcgb3ZlciBJQ0UgdGNwIGNh bmRpZGF0ZXMgd2hpY2ggaXMgbm90IHVzaW5nIFJGQzQ1NzEgZnJhbWluZy4gRm9yIGluc3RhbmNl IERUTFMgY291bGQgaGF2ZSBiZWVuIGltcGxlbWVudGVkIHVzaW5nIERUTFMgcHJvdG9jb2wgZnJh bWluZyB3aXRob3V0IFJGQzQ1NzEgb3ZlciB0Y3AgY2FuZGlkYXRlcywgYnV0IHRoaXMgd2FzIG5v dA0KIHRoZSBjYXNlLiBUaGlzIGlzIHBhcnRpYWxseSBkb25lIHRvIHNpbXBsaWZ5IGltcGxlbWVu dGF0aW9uIG9mIFNCQyB3aGljaCB0ZXJtaW5hdGUgSUNFIGFuZCB0cmFuc21pdCBwcm90b2NvbCBk YXRhIHVzaW5nIFVEUC4gQnkgdXNpbmcgUkZDIDQ1NzEgZnJhbWluZywgU0JDIGNhbiBwYWNrZXRp emUvZGUtcGFja2V0aXplIGRhdGEgdHJhbnNtaXR0ZWQgb3ZlciB0Y3AgY2FuZGlkYXRlcyB3aXRo b3V0IGtub3dpbmcgcHJvdG9jb2wgZGV0YWlscy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gY29uY2x1ZGUsIHVwIHVudGlsIHRoaXMgcG9p bnQgSUNFIHRjcCBjYW5kaWRhdGVzIHdlcmUgbm90IHRyZWF0ZWQgYXMgcmVsaWFibGUgdHJhbnNw b3J0IGFuZCBzZXJ2ZWQgc2ltcGx5IGFzIGFub3RoZXIgd2F5IHRvIHRyYW5zbWl0IFVEUCBwYWNr ZXRzIHRocm91Z2ggZmlyZXdhbGxzLiBCZWNhdXNlIG9mIHRoaXMsIEkgd291bGQgYXJndWUgdGhh dCBCRkNQIHJ1bm5pbmcgb3ZlciB0Y3AgY2FuZGlkYXRlIGlzDQogbm90IHRoZSBzYW1lIGFzIFRD UC9CRkNQLCBpbiB0aGUgc2FtZSB3YXkgYXMgRFRMUyBydW5uaW5nIG92ZXIgdGNwIGNhbmRpZGF0 ZSBpcyBub3QgVExTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIHdvdWxkIGFsc28gYXJndWUgdGhhdCBhbnkgcHJvdG9jb2wgcnVubmluZyBv dmVyIElDRSBpcywgaW4gZXNzZW5jZSwgYSBVRFAgYmFzZWQgcHJvdG9jb2wsIHVzaW5nIHRjcCBj YW5kaWRhdGVzIG9ubHkgYXMgYSBmYWxsIGJhY2sgbWVjaGFuaXNtIGZvciBmaXJld2FsbCB0cmF2 ZXJzYWwsIHNhbWUgd2F5IGFzIHdoZW4gZGF0YSBpcyByZWxheWVkIG92ZXIgVFVSTiBUQ1AsIGl0 IGlzIHN0aWxsIGNvbnNpZGVyZWQNCiBzZW50IG92ZXIgVURQIGF0IHRoZSBwcm90b2NvbCBsZXZl bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SWYgSUNFIGdyb3VwIGFncmVlcywgSSB0aGluayB0aGlzIHNob3VsZCBiZSBkb2N1bWVudGVkIGJ5 IHNheWluZyB0aGF0IFVEUCBpcyBhIE1VU1QgaW1wbGVtZW50IGZvciBhbnkgcHJvdG9jb2wgdXNp bmcgSUNFIGFuZCB0aGF0IGRlZmF1bHQgY2FuZGlkYXRlIHNob3VsZCBiZSBVRFAgYmFzZWQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5fX19fX19fX19fX19fPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFu IGNsYXNzPSJob2VuemIiPlJvbWFuIFNocG91bnQ8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBO b3YgMTcsIDIwMTYgYXQgODoxNCBQTSwgQWxhbiBGb3JkICZsdDs8YSBocmVmPSJtYWlsdG86YWxh bi5mb3JkQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFsYW4uZm9yZEBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QWRkaW5nIGJmY3BiaXMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Zb3UgcmFpc2UgYSBnb29kIHBvaW50IFJvbWFuIC0gdGhlcmXigJlz IG5vIGRlZmluaXRpb24gb2YgaG93IHRvIGFjdHVhbGx5IHVzZSBJQ0Ugd2l0aCBCRkNQIGF0IHRo ZSBwcm90b2NvbCBsZXZlbCAtIHRoaXMgb25seSBjYW1lIHVwIGluIHNvbWUgdmVyeSBsYXRlIHJl dmlld3Mgb2YgNDU4MmJpcy4gVGhlIGluaXRpYWwgc3VnZ2VzdGlvbiB3YXMgdG8gdXNlIHRoZSBz YW1lIHRleHQgYXMgaW4mbmJzcDtkcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcC0xOSwNCiBidXQg aXQgdGhlbiByYWlzZWQgdGhlIHBvaW50IHRoYXQsIGdpdmVuIEJGQ1AgZG9lcyBub3QgaGF2ZSBh IE1USSBwcm90b2NvbCwgaWYgdGhlIG9mZmVyZXIgc3VwcG9ydGVkIGJvdGggdGhleSB3b3VsZCBp bmNsdWRlIHRoZWlyIHByZWZlcnJlZCBvcHRpb24sIGJ1dCBpZiB0aGUgcmVjZWl2ZXIgc3VwcG9y dGVkIHRoZSBvdGhlciB2YXJpYW50LCB0aGVyZeKAmXMgbm8gd2F5IHRvIGltbWVkaWF0ZWx5IG5l Z290aWF0ZSB0aGF0IHdpdGhvdXQgYSByZS1JTlZJVEUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNocmlzdGVy4oCZcyBzdWdnZXN0aW9uIHRv IHJlbGF4IHRoZSByZXF1aXJlbWVudCB0aGF0IHRoZSBtLWxpbmUgcHJvdG9jb2wNCjxpPmluIHRo ZSBhbnN3ZXI8L2k+Jm5ic3A7bWF0Y2hlcyBvbmUgb2YgdGhlIElDRSBjYW5kaWRhdGVzIHdvdWxk IHN1cHBvcnQgdGhlIGNhc2Ugd2hlcmUgdGhlIG9mZmVyZXIgc3VwcG9ydHMgYm90aCBidXQgcHJl ZmVycyBVRFAsIGJ1dCB0aGUgYW5zd2VyZXIgb25seSBzdXBwb3J0cyBUQ1AuIEFsdGhvdWdoIG5v IGltcGxlbWVudGF0aW9ucyBjdXJyZW50bHkgZG8gSUNFIGhlcmUsIHRoaXMgcmVsYXhhdGlvbiB3 b3VsZCBsZWF2ZSB0aGUgZG9vciBvcGVuIHRvDQogZ2FpbmluZyB0aGlzIG5lZ290aWF0aW9uIGZs ZXhpYmlsaXR5IGluIGJmY3BiaXMgaW1wbGVtZW50YXRpb25zLiBUaGVyZSBzZWVtcyBubyByZWFz b24gdG8gaGF2ZSB0aGlzIHJlcXVpcmVtZW50IGFwcGxpZWQgdG8gdGhlIGFuc3dlciBpbiB0aGUg Zmlyc3QgcGxhY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBjb21tZW50IGFib3V0IFNCQ3M7IHRv ZGF5LCB0Y3AgY2FuZGlkYXRlcyBhcmUgdXNlZCBmb3IgbWVkaWEgYW5kIGRhdGEgY2hhbm5lbHMg ZW5kLXRvLWVuZCBpbiBXZWJSVEMsIHRvIG5hbWUgYnV0IG9uZSBpbXBsZW1lbnRhdGlvbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFs YW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTcgTm92IDIwMTYsIGF0IDAzOjA1LCBS b21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdl dD0iX2JsYW5rIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFkZGluZyBJQ0UgZ3JvdXAgdG8gdGhpcyBtZXNzYWdlLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBhcHByb2FjaCBhbHdheXMg d2FzIHRoYXQgdGNwIGNhbmRpZGF0ZXMgY2FuIHBvdGVudGlhbGx5IGdvIG9ubHkgYXMgZmFyIGFz IFNCQyBhbmQgdGhlbiBiZSB0ZXJtaW5hdGVkIGJ5IFVEUCB0cmFuc3BvcnQuIEJlY2F1c2Ugb2Yg dGhpcyBldmVyeXRoaW5nIHRyYW5zbWl0dGVkIG92ZXIgdGNwIGNhbmRpZGF0ZSB3YXMgc3RpbGwg Y29uc2lkZXJlZCB0byBiZSB0cmFuc21pdHRlZCBvdmVyIHRoZSB1bnJlbGlhYmxlDQogb3V0LW9m LW9yZGVyIHRyYW5zcG9ydC4gSXQgaXMgYWxzbyBhc3N1bWVkIHRoYXQgY2FuZGlkYXRlcyBjYW4g c3dpdGNoIGZyb20gVURQIHRvIFRDUCBiYXNlZCBjYW5kaWRhdGUgZHVyaW5nIG5vbWluYXRpb24u IFRoaXMgaXMgd2h5LCBmb3IgaW5zdGFuY2UsIHdlIHJ1biBEVExTIHdpdGggUkZDNDU3MSBmcmFt aW5nIG92ZXIgdGNwIGNhbmRpZGF0ZXMsIG5vdCBUTFMuIEJlY2F1c2Ugb2YgdGhpcyBJIGFsd2F5 cyB0aG91Z2h0IHRoYXQgSUNFIGlzDQogVURQIGZpcnN0IHdpdGggYWRkaXRpb25hbCBUQ1AgdHJh bnNwb3J0cyBmb3Igc2l0dWF0aW9uIHdoZW4gVURQIHdpbGwgbm90IHdvcmsuIFNvLCBhcyBhIHJl c3VsdCwgSSB0aGluayBJQ0UtYmlzIHNob3VsZCBzcGVjaWZ5IHRoYXQgVURQIE1VU1QgYmUgc3Vw cG9ydGVkIGFuZCBkZWZhdWx0IGNhbmRpZGF0ZSBNVVNUIGJlIFVEUC4gSUNFIFNEUCBjYW4gcmVm bGVjdCB0aGlzLCBidXQgSSB0aGluayB0aGlzIGlzIHRoZSB1bmRlcmx5aW5nIHByb3RvY29sDQog cmVxdWlyZW1lbnQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGFsc28gd2FudGVkIHRvIGFkZCB0aGF0IEJGQ1AgbmVlZHMgdG8gZXhhbWluZSBob3cgSUNF IHN1cHBvcnQgaXMgaW1wbGVtZW50ZWQgYnkgdGhpcyBwcm90b2NvbC4gSSB0aGluayBpdCBpcyBu b3QgY292ZXJlZCBpbiB0aGUgY3VycmVudCBkcmFmdHMuIEkgYWxzbyB0aGluayBJIGRvIG5vdCB0 aGluayBpdCBpcyBwb3NzaWJsZSBmb3IgVENQL0JGQ1AgdG8mbmJzcDtydW4gb3ZlciBJQ0UuIE9u IHRoZSBvdGhlciBoYW5kDQogVURQL0RUTFMvQkZDUCBhbmQgVENQL0RUTFMvQkZDUCB3b3VsZCB0 cml2aWFsIGJhc2VkIG9uIGN1cnJlbnQgRFRMUyB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPGJyIGNsZWFyPSJhbGwiPg0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19f X19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBOb3YgMTYsIDIwMTYgYXQgODo0NCBQTSwgQ2hyaXN0 ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgaGF2 ZSBubyBwcm9ibGVtIHdpdGggUm9tYW7igJlzIG11c3Qtc3VwcG9ydC1VRFAgc3VnZ2VzdGlvbi4g SSBndWVzcyB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB0aGUgQkZDUA0KIGZvbGtzIGNvdWxkIGFj Y2VwdCB0aGF0LiBDdWxsZW4gZGlkIHNheSB0aGF0IFRDUC1iYXNlZCBCRkNQIGRlcGxveW1lbnRz IGhhdmUgYmVlbiBhcm91bmQgZm9yIGEgZGVjYWRlLiBCdXQsIGRvIHRoZXkgc3VwcG9ydCBJQ0U/ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgd2UgZGVj aWRlIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHN1Y2ggYXBwcm9hY2gsIHdlIG5lZWQgdG8gYXNrIG91 cnNlbHZlcyB3aGV0aGVyIG11c3Qtc3VwcG9ydC1VRFANCiBzaG91bGQgYmUgYW4gSUNFIHJlcXVp cmVtZW50IChpbiB3aGljaCBjYXNlIHRoZSBzdWdnZXN0aW9uIHNob3VsZCBiZSBicm91Z2h0IHRv IHRoZSBJQ0UgV0cpIG9yIHdoZXRoZXIgaXQgc2hvdWxkIG9ubHkgYmUgYW4gSUNFLXVzaW5nLVNJ UC1TRFAgcmVxdWlyZW1lbnQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48YSBuYW1lPSJtXy02MTY4NzA0Njk0ODg0ODU2NDUxX21fMjAxODQ5MTQ5MDg3ODk1 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBt bXVzaWMNCiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+Um9tYW4gU2hwb3VudDxicj4NCjxiPlNlbnQ6PC9iPiAxNyBOb3ZlbWJlciAyMDE2 IDAwOjUyPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBb TU1VU0lDXSBtPSBsaW5lIHByb3RvY29sIGluIGNhc2Ugb2YgSUNFPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgQWxsLDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkganVzdCB3YW50ZWQgdG8g cmV0dXJuIHRvIHRoZSBtPSBsaW5lIHByb3RvY29sIGlzc3VlIHRoYXQgQ2hyaXN0ZXIgcmFpc2Vk IGR1cmluZyB0aGUgbGFzdCBNTVVTSUMgc2Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsbCB0aGUgSUNFIGltcGxlbWVudGF0 aW9ucyBJJ3ZlIHNlZW4gYXJlIHByaW1hcmlseSBVRFAgYmFzZWQgd2l0aCBzdXBwb3J0IGZvciB0 Y3AgaG9zdCBjYW5kaWRhdGVzIHdoaWNoIGFyZSBwcmltYXJpbHkgdXNlZCB0byBjb25uZWN0IHRv IGVuZCBwb2ludHMgb24gcHVibGljIElQLiBJZiBhbGwgSUNFIGltcGxlbWVudGF0aW9ucw0KIGFy ZSBjb250aW51ZSB0byBiZSBwcmltYXJpbHkgVURQIGJhc2VkLCB0aGVuIHRoZSBzaW1wbGVzdCBz b2x1dGlvbiB3b3VsZCBiZSB0byByZXF1aXJlIFVEUCBzdXBwb3J0IHdoZW4gYW55IGdpdmVuIHBy b3RvY29sIGlzIGltcGxlbWVudGVkIG92ZXIgSUNFLiBEVExTIGFuZCBSVFAgYXJlIGFscmVhZHkg cHJpbWFyaWx5IFVEUCBiYXNlZCBzbyB0aGlzIGlzIGEgbm9uLXJlcXVpcmVtZW50LiBFdmVuIG1v cmUsIGFsbCBwcm90b2NvbHMgdGhhdCBhcmUNCiBpbXBsZW1lbnRlZCBvbiB0b3Agb2YgSUNFIG11 c3QgYXNzdW1lIHRoYXQgdW5kZXJsaW5nIHRyYW5zcG9ydHMgKGluY2x1ZGluZyB0Y3AgY2FuZGlk YXRlcykgYXJlIHVucmVsaWFibGUsIHNpbmNlIGNhbmRpZGF0ZSBwYWlyIGNhbiBjaGFuZ2UgYXQg YW55IHRpbWUgYmV0d2VlbiByZWxpYWJsZSBhbmQgdW5yZWxpYWJsZSB0cmFuc3BvcnRzLCBzbyB0 aGlzIG1ha2VzIHRoZW0gZGlmZmVyZW50IGZyb20gcHJvdG9jb2xzIGltcGxlbWVudGVkIG9uIHBs YWluDQogVENQIG9yIFRMUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlNvIHRoZSBmaXJzdCBxdWVzdGlvbiBJIHdhbnRlZCB0byBhc2sg aXMgYW55Ym9keSBpbnRlcmVzdGVkIGluIFRDUCBvbmx5IElDRSBpbXBsZW1lbnRhdGlvbiB3aGVy ZSB0aGUgcHJvdG9jb2wgcnVubmluZyBvbiB0b3Agb2Ygc3VjaCBpbXBsZW1lbnRhdGlvbiByZWxp ZXMgb24gdGhlIHJlbGlhYmxlIGRlbGl2ZXJ5DQogb2YgdW5kZXJseWluZyBtZXNzYWdlcz8gQnkg dGhpcyBJIG1lYW4sIGRvZXMgYW55Ym9keSB3YW50cyBpbXBsZW1lbnQgVENQIGJhc2VkIElDRSwg d2l0aCBzaW11bHRhbmVvdXMgb3BlbiwgcmVmbGV4aXZlIGFuZCByZWxheSBjYW5kaWRhdGVzIGlu IHN1Y2ggYSB3YXkgdGhhdCBJQ0UgaW1wbGVtZW50YXRpb24gd2lsbCBydW4gZnJvbSBiZWhpbmQg TkFUIHdpdGhvdXQgZXZlciBuZWVkaW5nIGEgVURQIGNhbmRpZGF0ZT88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdW5kZXJzdGFuZCB0 aGF0IEJGQ1Agd2FzIHVzZWQgZm9yIGEgbG9uZyB0aW1lLCBidXQgSSBkbyBub3QgdGhpbmsgVENQ L0JGQ1Agb3IgVENQL1RMUy9CRkNQIGNhbiBldmVuIGJlIHVzZWQgd2l0aCBJQ0UuIEkgdGhpbmsg b25seSBVRFAvQkZDUCwgVURQL0RUTFMvQkZDUCBhbmQgVENQL0RUTFMvQkZDUCBjYW4NCiBldmVu IHN1cHBvcnQgSUNFLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayBib3RoJm5ic3A7cmZjNDU4MmJpcyBhbmQgcmZj NDU4M2JpcyBuZWVkIGEgY2FyZWZ1bCByZXZpZXcgYW5kIGFkZGl0aW9uYWwgc2VjdGlvbnMgdGhh dCBkZXNjcmliZSBJQ0UgY29uc2lkZXJhdGlvbnMuIEkgdGhpbmsgdGhlIG1vc3Qgb2J2aW91cyB0 aGluZyB3b3VsZCBiZSB0byBzcGVjaWZ5IHRoYXQgSUNFDQogY2FuIG9ubHkgYmUgc3VwcG9ydGVk IGJ5IFVEUC9CRkNQLCBVRFAvRFRMUy9CRkNQIGFuZCBUQ1AvRFRMUy9CRkNQLiBJdCB3aWxsIGFs c28gbWVhbiBpbiB3aGljaCBjYXNlIFJGQzQ1NzEgaXMgdXNlZCB3aGVuIHRjcCBjYW5kaWRhdGVz IGFyZSB1c2VkLiBGdXJ0aGVybW9yZSwgd2hlbiB0Y3AgY2FuZGlkYXRlIGlzIHNlbGVjdGVkIHdp dGggVURQL0JGQ1AgdHJhbnNwb3J0LCBpdCBpcyBub3QgdGhlIHNhbWUgdGhpbmcgYXMgdXNpbmcg VENQL0JGQ1ANCiBhbmQgd2lsbCBuZWVkIGEgZGlmZmVyZW50IHRyYW5zcG9ydCB0YWcgKHNvbWV0 aGluZyBsaWtlIFRDUC9VRFAvQkZDUCkuIEFsdGVybmF0aXZlbHkgd2UgY2FuIHJlcXVpcmUgdGhh dCBvbmx5IHNlY3VyZSB2ZXJzaW9ucyBvZiBCRkNQIGFyZSB1c2VkIHdpdGggSUNFIGFuZCBvbmx5 IGFsbG93IElDRSB1c2FnZSBmb3IgVURQL0RUTFMvQkZDUCBhbmQgVENQL0RUTFMvQkZDUC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRv IGNvbmNsdWRlLCBJIHdvdWxkIGFyZ3VlIHRoYXQgdGhlIHNpbXBsZXN0IHNvbHV0aW9uIHdvdWxk IGJlIHRoYXQgZm9yIGFsbCBwcm90b2NvbHMgaW1wbGVtZW50ZWQgb24gdG9wIG9mIElDRSwgVURQ IE1VU1QgYmUgc3VwcG9ydGVkIGFuZCBkZWZhdWx0IGNhbmRpZGF0ZXMgTVVTVCBiZSBVRFAgYmFz ZWQuDQogVGhpcyBhdm9pZHMgYnVpbGRpbmcgdW5jb21mb3J0YWJsZSBhcnRpZmljaWFsIGNvbnN0 cnVjdHMgdG8gYXZvaWQgSUNFIG1pc21hdGNoIGFuZCByZXF1aXJlcyBtaW5pbWFsIGNoYW5nZXMg dG8gZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19f X19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJtLTYxNjg3MDQ2OTQ4ODQ4NTY0NTFnbWFpbC0iPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4N CjxzcGFuIGNsYXNzPSJtLTYxNjg3MDQ2OTQ4ODQ4NTY0NTFnbWFpbC0iPm1tdXNpYyBtYWlsaW5n IGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Im0tNjE2ODcwNDY5NDg4NDg1NjQ1MWdtYWls LSI+PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNp Y0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Im0tNjE2ODcwNDY5NDg4NDg1 NjQ1MWdtYWlsLSI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21tdXNpYzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4BE823C9ESESSMB209erics_-- From nobody Mon Nov 21 01:28:14 2016 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 897601298B2; Mon, 21 Nov 2016 01:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYt6Cch7N_IQ; Mon, 21 Nov 2016 01:28:06 -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 D7F461298B1; Mon, 21 Nov 2016 01:28:05 -0800 (PST) X-AuditID: c1b4fb30-96c1b98000001942-57-5832be23e21e Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id FF.00.06466.32EB2385; Mon, 21 Nov 2016 10:28:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0319.002; Mon, 21 Nov 2016 10:27:14 +0100 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Roman Shpount Thread-Topic: [MMUSIC] m= line protocol in case of ICE Thread-Index: AQHSQFwT8S0xdJKeakq1+K6kpgEs7aDcZjMAgAAHVICAAXMfAIAAEJmAgASHdQCAAAE2AIAAt+ug Date: Mon, 21 Nov 2016 09:27:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE823F6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2J7lK7KPqMIg8/XuS1WnlvBbPFv3VEm i+n7bCy+Xai1mLr8MYvFjAtTmR3YPM41vGf32DnrLrvHkiU/mTxuTSkIYInisklJzcksSy3S t0vgynh9T6agg6PiwZrvjA2Mb9i7GDk4JARMJP6+4+1i5OIQEljHKLH//08WCGcxo8T6uROY QIrYBCwkuv9pdzFycogIJEosmTmbHaSGWWACo8Tyv3/YQRLCAqYSm45fZoMoMpPYvHAJI4Qd JXF99h5WEJtFQFXi+eoNYPW8Ar4Sh3q/sIDYQgKPmSUmXuIFsTkFAiVO9t8Dm8MoICbx/dQa JhCbWUBc4taT+WC2hICAxJI955khbFGJl4//sULYShKNS56wgtzMLKApsX6XPkSrosSU7odQ awUlTs58wjKBUXQWkqmzEDpmIemYhaRjASPLKkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzA uDq45bfBDsaXzx0PMQpwMCrx8BbcNIgQYk0sK67MPcQowcGsJMLLtdcoQog3JbGyKrUoP76o NCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQbGEpdQo/elpVnvbvF+qykXXXmP Ozdv7yOTQ6kqv1rWvOCdVWN0p2Dddt569swQicbyubOdt0sLFx37Py0+e2NeXFf7JvZpSu7y a9/ZfDkQ9lZaiWv1NkGLr5oHxD4duv9yToP3k1Mxus+8owK/9/3dy+bp4LfGNd2dt1xTUS08 27vI7O+fsodKLMUZiYZazEXFiQBlyfYupwIAAA== Archived-At: Cc: "ice@ietf.org" , "bfcpbis@ietf.org" , "mmusic@ietf.org" , Alan Ford Subject: Re: [Ice] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 09:28:07 -0000 SGksDQoNCj4+IEkganVzdCB3YW50ZWQgdG8gYWRkIHRvIG15IHByZXZpb3VzIGVtYWlsLCB0aGF0 IGFjY29yZGluZyB0byBSRkMgNjU0NCANCj4+IHByb3RvY29scyBydW5uaW5nIG92ZXIgdGNwIGNh bmRpZGF0ZXMgTVVTVCB1c2UgIFJGQyA0NTcxIGZyYW1pbmcgDQo+PiAoaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzY1NDQjc2VjdGlvbi0xMC4xKS4gVGhpcyBtZWFucyB0aGF0IA0KPj4g QkZDUCBydW5uaW5nIG92ZXIgdGNwIGNhbmRpZGF0ZSBpcyBub3QgVENQL0JGQ1AgYW5kIHdpbGwg cmVxdWlyZSBhIA0KPj4gZGlmZmVyZW50IHRyYW5zcG9ydCB0YWcuDQo+DQo+IElNSE8gdGhlIGV4 YWN0IHRyYW5zcG9ydCBpcyBqdXN0ICJJQ0UiLiBJQ0UgaXRzZWxmIGlzIGEgInZpcnR1YWwgdHJh bnNwb3J0IiB0aGF0IGNhbiB1c2UgDQo+IG1hbnkgInJlYWwgdHJhbnNwb3J0cyIgKFVEUCwgVENQ K1JGQzQ1NzEsIGV0YykuDQo+DQo+IFNvIElDRS9CRkNQIHdvdWxkIGJlIG15IHdheSB0byBnby4N Cg0KVGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgYmVmb3JlOiB0aGUgcHJvY2VkdXJlcyBoYXZlIHRv IGJlIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCBub24tSUNFIGVuZHBvaW50cy4NCg0KSWYgYW55 b25lIHdhbnRzIHRvIGRlZmluZSBuZXcgIklDRSB0cmFuc3BvcnRzIiwgdGhhdCdzIGZpbmUsIGJ1 dCBpdCBzaG91bGQgYmUgZG9uZSBhcyBhIHNlcGFyYXRlIHRhc2suDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCg0K From nobody Mon Nov 21 01:56:05 2016 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 C724712998D for ; Mon, 21 Nov 2016 01:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdofwyZfKF0d for ; Mon, 21 Nov 2016 01:55:59 -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 7DDED129473 for ; Mon, 21 Nov 2016 01:55:58 -0800 (PST) X-AuditID: c1b4fb30-96c1b98000001942-20-5832c4ac3489 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id C7.C7.06466.CA4C2385; Mon, 21 Nov 2016 10:55:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0319.002; Mon, 21 Nov 2016 10:55:13 +0100 From: Christer Holmberg To: Bernard Aboba Thread-Topic: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? Thread-Index: AdJCRurmAgGp6u03Tl6w25hg1S1vSQAhaaqAAEON55A= Date: Mon, 21 Nov 2016 09:55:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE82520@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BE742CE@ESESSMB209.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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE82520ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7ru6aI0YRBteXWVhs2Pef2eLbhVoH Jo+ds+6yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK2P/xTOMBX1djBVtHZ+ZGxi3tDF2MXJySAiY SOxd8pq5i5GLQ0hgHaPErCOtTCAJIYHFjBJfPkh0MXJwsAlYSHT/0wYJiwhoS/R928cEEmYW UJR4uVcNpFVYYCajxPfllxlBHBGBWYwSXS++MEI0WEn8OHoHzGYRUJU4drUdbD6vgK/EsRd7 WCAWT2GUmLGmhxkkwSkQKNEwdR1YA6OAmMT3U2vAGpgFxCVuPZnPBHG1gMSSPeeZIWxRiZeP /7FC2EoSjUuesELU50t87/zEBrFMUOLkzCcsExhFZiEZNQtJ2SwkZbPAntOUWL9LH6JEUWJK 90N2CFtDonXOXHZk8QWM7KsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAiPr4JbfBjsYXz53 PMQowMGoxMNbcNMgQog1say4MvcQowQHs5IIrwwwLoV4UxIrq1KL8uOLSnNSiw8xSnOwKInz mq28Hy4kkJ5YkpqdmlqQWgSTZeLglGpg7CnXuPm9/FO6nwnHVIeO4ooVx6LTdWVOvArm3rZR W9u3aNeTxp5esQ6/03yJ14+6h4vrnuNWdd5vmZ3JXPXAuF6h0dPCMqPhi0nT/JdizaZH9LNP G1Zwriv8WL3GoMv/ZK4NZxSDzMyLSd4FnTU9GdONLqzcXf1W+7xb4KEOzxD786oPHiixFGck GmoxFxUnAgBpMKR/qAIAAA== Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 09:56:04 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE82520ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVybmFyZCwNCg0KWW91IGFyZSBjb3JyZWN0IOKAkyB0aGUgcHJvYmxlbSBhbHJlYWR5IGV4 aXN0ZWQgaW4gUkZDIDUyNDUuDQoNClRoZXJlIGlzIGEgZGlmZmVyZW5jZSwgdGhvdWdoOg0KDQpX aGVuIHVzaW5nIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiAoUkZDIDUyNDUpIHRoZSBlbmRwb2ludHMg Y291bGQgbm90IHN3aXRjaCBiZXR3ZWVuIHZhbGlkIGNhbmRpZGF0ZSBwYWlycyBhcyB0aGV5IHdp c2guIEF0IGFueSBnaXZlbiB0aW1lLCBvbmx5IHRoZSBub21pbmF0ZWQgcGFpciB3aXRoIHRoZSBo aWdoZXN0LXByaW9yaXR5IGNvdWxkIGJlIHVzZWQsIG1lYW5pbmcgdGhhdCB0aGVyZSB3YXMgb25s eSBvbmUgc2VsZWN0ZWQgcGFpciBhdCBhbnkgZ2l2ZW4gdGltZS4NCg0KSW4gNTI0NWJpcywgbWVk aWEgY2FuIGJlIHNlbnQgb24gYW55IHBhaXIsIGFuZCB0aGUgc3dpdGNoaW5nIGNhbiBiZSBkb25l IHdoZW5ldmVyLCBob3dldmVyLCBhbmQgdGhlcmUgaXMgbm8gbmVlZCB0byBub21pbmF0ZSB0byBi ZWdpbiB3aXRoLCBwcmlvciB0byBzZW5kaW5nIG1lZGlhLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQoNCkZyb206IEJlcm5hcmQgQWJvYmEgW21haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNv bV0NClNlbnQ6IDIwIE5vdmVtYmVyIDIwMTYgMDQ6MjMNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6IGljZUBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtJY2VdIERvIHdlIHdhbnQgdG8gbWFuZGF0ZSBhbGwgcHJvdG9jb2xzIHN1cHBvcnRp bmcgSUNFIGFuZCBtdWx0aXBsZSB0cmFuc3BvcnRzIHRvIHN1cHBvcnQgdHJhbnNwb3J0IHN3aXRj aCBvbi10aGUtZmx5IGJlZm9yZSBub21pbmF0aW9uPw0KDQoNCkNocmlzdGVyIC0tDQoNCldpdGgg YWdncmVzc2l2ZSBub21pbmF0aW9uLCBhIFRDUCBjYW5kaWRhdGUtcGFpciBjb3VsZCBiZSBub21p bmF0ZWQsIGFuZCB0aGVuIGEgVURQIGNhbmRpZGF0ZS1wYWlyIGNvdWxkIGJlIG5vbWluYXRlZCwg YW5kIGRhdGEgY291bGQgYmUgc2VudCBvbiBhIHN1Y2Nlc3NmdWwgcGFpci4gIFNvICJzd2l0Y2hp bmciIGNhbiBhbHNvIG9jY3VyLiAgR2l2ZW4gdGhhdCB0aGUgY29udHJvbGxlZCBwZWVyIG5lZWRz IHRvIGJlIGFibGUgdG8gcmVjZWl2ZSBvbiBhbnkgc3VjY2Vzc2Z1bCBwYWlyLCBpdCBoYXMgdG8g YmUgcHJlcGFyZWQgZm9yIHJlY2VpdmluZyBib3RoIFVEUCBhbmQgVENQIHBhY2tldHMgYXQgdGhl IHNhbWUgdGltZS4NCg0KU28gaG93IGlzICJwYXNzaXZlLWFnZ3Jlc3NpdmUiIG5vbWluYXRpb24g bW9yZSBvbmVyb3VzIHRoYW4gYWdncmVzc2l2ZSBpbiB0aGlzIHJlc3BlY3Q/DQoNCk9uIE5vdiAx OSwgMjAxNiAxOjI3IEFNLCAiQ2hyaXN0ZXIgSG9sbWJlcmciIDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3Rl Og0KSGksDQoNCk9uZSBwb3RlbnRpYWwgaXNzdWUgdGhhdCBjYW1lIHRvIG15IG1pbmQgd2hpbGUg cmVhZGluZyB0aGUgU0RQIG0tIGxpbmUgdGhyZWFkLg0KDQpQcmV2aW91c2x5LCBiZWZvcmUgcmVt b3ZhbCBvZiBhZ2dyZXNzaXZlIG5vbWluYXRpb24sIHdoaWxlIGFuZCBlbmRwb2ludCBtaWdodCBz dXBwb3J0IGJvdGggVURQIGFuZCBUQ1AgZm9yIGEgcHJvdG9jb2wsIGl0IGRpZG7igJl0IGhhdmUg dG8gYmUgYWJsZSB0byBzaW11bHRhbmVvdXNseSB1c2UgdGhlIHByb3RvY29sIHdpdGggYm90aCBV RFAgYW5kIFRDUCwgYW5kIHN3aXRjaGluZyBiZXR3ZWVuLiBCZWNhdXNlLCB1bnRpbCBub21pbmF0 aW9uIHdhcyBkb25lLCBubyBwcm90b2NvbCBkYXRhIHdhcyBzZW50LiBBbmQsIG9uY2Ugbm9taW5h dGlvbiBoYWQgYmVlbiBkb25lLCBlbmRwb2ludHMgdXNlZCB0aGUgcHJvdG9jb2wgd2l0aCB0aGUg c2VsZWN0ZWQgdHJhbnNwb3J0Lg0KDQpOb3csIHdpdGggdGhlIGFsbG93ZWQtdG8tc2VuZC1tZWRp YS1iZWZvcmUtbm9taW5hdGlvbiBydWxlcywgcHJvdG9jb2xzIGJhc2ljYWxseSBoYXZlIHRvIHN1 cHBvcnQgc3dpdGNoIG9mIHRyYW5zcG9ydCAoZnJvbSBVRFAgdG8gVENQLCBhbmQgdmljZSB2ZXJz YSksIHVudGlsIHRoZSBub21pbmF0aW9uIHRha2VzIHBsYWNlLg0KDQpOb3csIGV2ZW4gcGVvcGxl IGFsd2F5cyBzYXkgdGhhdCBhIGdvb2QgZGVzaWduZWQgcHJvdG9jb2wgc2hvdWxkIGJlIHRyYW5z cG9ydC1pbmRlcGVuZGVudCwgaXNu4oCZdCAqbWFuZGF0aW5nKiB0cmFuc3BvcnQgc3dpdGNoaW5n IG9uLXRoZS1mbHkgKGJlZm9yZSBub21pbmF0aW9uIHRha2VzIHBsYWNlKSBieSBhbGwgcHJvdG9j b2xzIHN1cHBvcnRpbmcgSUNFIGFuZCBtdWx0aXBsZSB0cmFuc3BvcnRzIGEgYmFkIHRoaW5nIHRv IGRvPw0KDQpQZXJoYXBzIHRoZSBJQ0UgY29uc2lkZXJhdGlvbnMgb2YgZWFjaCBwcm90b2NvbCAo UlRQLCBCRkNQIGV0Yykgc2hvdWxkIGluZGljYXRlIHdoZXRoZXIgdHJhbnNwb3J0IHN3aXRjaGlu ZyBpcyBzdXBwb3J0ZWQsIGFuZCB3aGV0aGVyIHRoZXJlIGFyZSBwcm90b2NvbCBzcGVjaWZpYyBw cm9jZWR1cmVzIGFzc29jaWF0ZWQgd2l0aCB0aGF0LiBJIGd1ZXNzIGEgcHJvdG9jb2wgY291bGQg YWxzbyBzcGVjaWZ5IHRoYXQgZGF0YSBzaG91bGRu4oCZdCBiZSBzZW50IGluIHRoZSBmaXJzdCBw bGFjZSBiZWZvcmUgbm9taW5hdGlvbiBoYXMgYmVlbiBkb25lLCBpZiB0aGVyZSBhcmUgZ29vZCBy ZWFzb25zIGZvciB0aGF0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWNlIG1haWxpbmcgbGlzdA0KSWNl QGlldGYub3JnPG1haWx0bzpJY2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2ljZQ0K --_000_7594FB04B1934943A5C02806D1A2204B4BE82520ESESSMB209erics_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkhpIEJlcm5hcmQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5Zb3UgYXJlIGNvcnJlY3Qg4oCTIHRoZSBwcm9ibGVtIGFscmVhZHkgZXhpc3RlZCBpbiBSRkMg NTI0NS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZXJlIGlzIGEg ZGlmZmVyZW5jZSwgdGhvdWdoOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+V2hlbiB1c2luZyBhZ2dyZXNzaXZlIG5vbWluYXRpb24gKFJGQyA1MjQ1KSB0aGUgZW5kcG9p bnRzIGNvdWxkIG5vdCBzd2l0Y2ggYmV0d2VlbiB2YWxpZCBjYW5kaWRhdGUgcGFpcnMgYXMgdGhl eSB3aXNoLiBBdCBhbnkgZ2l2ZW4NCiB0aW1lLCBvbmx5IHRoZSBub21pbmF0ZWQgcGFpciB3aXRo IHRoZSBoaWdoZXN0LXByaW9yaXR5IGNvdWxkIGJlIHVzZWQsIG1lYW5pbmcgdGhhdCB0aGVyZSB3 YXMgb25seSBvbmUgc2VsZWN0ZWQgcGFpciBhdCBhbnkgZ2l2ZW4gdGltZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkluIDUyNDViaXMsIG1lZGlhIGNhbiBiZSBzZW50 IG9uIGFueSBwYWlyLCBhbmQgdGhlIHN3aXRjaGluZyBjYW4gYmUgZG9uZSB3aGVuZXZlciwgaG93 ZXZlciwgYW5kIHRoZXJlIGlzIG5vIG5lZWQgdG8gbm9taW5hdGUgdG8gYmVnaW4NCiB3aXRoLCBw cmlvciB0byBzZW5kaW5nIG1lZGlhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJlcm5hcmQgQWJvYmEgW21haWx0 bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyMCBOb3ZlbWJl ciAyMDE2IDA0OjIzPGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gaWNlQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWNlXSBEbyB3ZSB3YW50IHRvIG1hbmRhdGUgYWxs IHByb3RvY29scyBzdXBwb3J0aW5nIElDRSBhbmQgbXVsdGlwbGUgdHJhbnNwb3J0cyB0byBzdXBw b3J0IHRyYW5zcG9ydCBzd2l0Y2ggb24tdGhlLWZseSBiZWZvcmUgbm9taW5hdGlvbj88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwPkNocmlzdGVyIC0tPG86cD48L286cD48L3A+DQo8cD5XaXRoIGFnZ3Jlc3NpdmUgbm9t aW5hdGlvbiwgYSBUQ1AgY2FuZGlkYXRlLXBhaXIgY291bGQgYmUgbm9taW5hdGVkLCBhbmQgdGhl biBhIFVEUCBjYW5kaWRhdGUtcGFpciBjb3VsZCBiZSBub21pbmF0ZWQsIGFuZCBkYXRhIGNvdWxk IGJlIHNlbnQgb24gYSBzdWNjZXNzZnVsIHBhaXIuJm5ic3A7IFNvICZxdW90O3N3aXRjaGluZyZx dW90OyBjYW4gYWxzbyBvY2N1ci4mbmJzcDsgR2l2ZW4gdGhhdCB0aGUgY29udHJvbGxlZCBwZWVy IG5lZWRzIHRvIGJlIGFibGUgdG8gcmVjZWl2ZQ0KIG9uIGFueSBzdWNjZXNzZnVsIHBhaXIsIGl0 IGhhcyB0byBiZSBwcmVwYXJlZCBmb3IgcmVjZWl2aW5nIGJvdGggVURQIGFuZCBUQ1AgcGFja2V0 cyBhdCB0aGUgc2FtZSB0aW1lLg0KPG86cD48L286cD48L3A+DQo8cD5TbyBob3cgaXMgJnF1b3Q7 cGFzc2l2ZS1hZ2dyZXNzaXZlJnF1b3Q7IG5vbWluYXRpb24gbW9yZSBvbmVyb3VzIHRoYW4gYWdn cmVzc2l2ZSBpbiB0aGlzIHJlc3BlY3Q/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gTm92IDE5LCAyMDE2IDE6MjcgQU0sICZxdW90O0NocmlzdGVyIEhvbG1iZXJnJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5j aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T25lIHBvdGVudGlhbCBpc3N1ZSB0aGF0IGNhbWUgdG8gbXkgbWluZCB3aGlsZSBy ZWFkaW5nIHRoZSBTRFAgbS0gbGluZSB0aHJlYWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5QcmV2aW91c2x5LCBiZWZvcmUgcmVtb3ZhbCBvZiBhZ2dyZXNzaXZlIG5vbWluYXRpb24sIHdo aWxlIGFuZCBlbmRwb2ludCBtaWdodCBzdXBwb3J0IGJvdGggVURQIGFuZCBUQ1AgZm9yIGEgcHJv dG9jb2wsIGl0IGRpZG7igJl0IGhhdmUgdG8gYmUgYWJsZSB0byBzaW11bHRhbmVvdXNseSB1c2Ug dGhlIHByb3RvY29sDQogd2l0aCBib3RoIFVEUCBhbmQgVENQLCBhbmQgc3dpdGNoaW5nIGJldHdl ZW4uIEJlY2F1c2UsIHVudGlsIG5vbWluYXRpb24gd2FzIGRvbmUsIG5vIHByb3RvY29sIGRhdGEg d2FzIHNlbnQuIEFuZCwgb25jZSBub21pbmF0aW9uIGhhZCBiZWVuIGRvbmUsIGVuZHBvaW50cyB1 c2VkIHRoZSBwcm90b2NvbCB3aXRoIHRoZSBzZWxlY3RlZCB0cmFuc3BvcnQuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5Ob3csIHdpdGggdGhlIGFsbG93ZWQtdG8tc2VuZC1tZWRpYS1iZWZv cmUtbm9taW5hdGlvbiBydWxlcywgcHJvdG9jb2xzIGJhc2ljYWxseSBoYXZlIHRvIHN1cHBvcnQg c3dpdGNoIG9mIHRyYW5zcG9ydCAoZnJvbSBVRFAgdG8gVENQLCBhbmQgdmljZSB2ZXJzYSksIHVu dGlsIHRoZSBub21pbmF0aW9uIHRha2VzDQogcGxhY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5Ob3csIGV2ZW4gcGVvcGxlIGFsd2F5cyBzYXkgdGhhdCBhIGdvb2QgZGVzaWduZWQgcHJv dG9jb2wgc2hvdWxkIGJlIHRyYW5zcG9ydC1pbmRlcGVuZGVudCwgaXNu4oCZdCAqPGI+bWFuZGF0 aW5nPC9iPiogdHJhbnNwb3J0IHN3aXRjaGluZyBvbi10aGUtZmx5IChiZWZvcmUgbm9taW5hdGlv biB0YWtlcyBwbGFjZSkNCiBieSBhbGwgcHJvdG9jb2xzIHN1cHBvcnRpbmcgSUNFIGFuZCBtdWx0 aXBsZSB0cmFuc3BvcnRzIGEgYmFkIHRoaW5nIHRvIGRvPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+UGVyaGFwcyB0aGUgSUNFIGNvbnNpZGVyYXRpb25zIG9mIGVhY2ggcHJvdG9jb2wgKFJU UCwgQkZDUCBldGMpIHNob3VsZCBpbmRpY2F0ZSB3aGV0aGVyIHRyYW5zcG9ydCBzd2l0Y2hpbmcg aXMgc3VwcG9ydGVkLCBhbmQgd2hldGhlciB0aGVyZSBhcmUgcHJvdG9jb2wgc3BlY2lmaWMgcHJv Y2VkdXJlcyBhc3NvY2lhdGVkDQogd2l0aCB0aGF0LiBJIGd1ZXNzIGEgcHJvdG9jb2wgY291bGQg YWxzbyBzcGVjaWZ5IHRoYXQgZGF0YSBzaG91bGRu4oCZdCBiZSBzZW50IGluIHRoZSBmaXJzdCBw bGFjZSBiZWZvcmUgbm9taW5hdGlvbiBoYXMgYmVlbiBkb25lLCBpZiB0aGVyZSBhcmUgZ29vZCBy ZWFzb25zIGZvciB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNocmlzdGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCkljZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWNlQGlldGYub3JnIj5J Y2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pY2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2ljZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4BE82520ESESSMB209erics_-- From nobody Mon Nov 21 02:03:26 2016 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 B236E129522 for ; Mon, 21 Nov 2016 02:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOqrLy741LQe for ; Mon, 21 Nov 2016 02:03:23 -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 5F1C312997D for ; Mon, 21 Nov 2016 02:03:23 -0800 (PST) X-AuditID: c1b4fb25-aefff70000007ee2-f8-5832c667d72a Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 7E.E6.32482.766C2385; Mon, 21 Nov 2016 11:03:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Mon, 21 Nov 2016 11:03:19 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? Thread-Index: AdJCRurmAgGp6u03Tl6w25hg1S1vSQAhaaqAACvx7gAAGFl6QA== Date: Mon, 21 Nov 2016 10:03:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE8254A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BE742CE@ESESSMB209.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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE8254AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7gW7mMaMIgykP9Cw27PvPbPHtQq3F jAtTmR2YPXbOusvusWTJTyaPW1MKApijuGxSUnMyy1KL9O0SuDK+9j1lKbh0i7Fi9da/7A2M H64wdjFyckgImEic/NzB3sXIxSEksI5RYvrhFVDOYkaJ7u49rF2MHBxsAhYS3f+0QRpEBFQl /n6fzARiMwt4SbSc2c8GUi8sMJNR4vvyy4wgjojALEaJrhdfGCE6nCTOXF3BBDKIBah73W4H kDCvgK/Et33rwUqEBG4zSpx+XwlicwoESvzq3sUKYjMKiEl8P7UGapm4xK0n85kgrhaQWLLn PDOELSrx8vE/VghbSaJxyRNWiPp8iYMzP7ND7BKUODnzCcsERpFZSEbNQlI2C0nZLKBLmQU0 Jdbv0ocoUZSY0v2QHcLWkGidM5cdWXwBI/sqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMBY O7jlt+oOxstvHA8xCnAwKvHwFtw0iBBiTSwrrsw9xCjBwawkwnv2iFGEEG9KYmVValF+fFFp TmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYytj881cxdpvhNuzXYtV1Z1ETto ZBD9bbbanLjbhbcP3poSlOj67G1xRcj5d21LRZ+suCC1xHz2kgNs334qWDOW3D6z6AjTfI3d HFtevHLKLWL+b3wwUXlm+7vg1esvfV6XtPOba8/Wqkb/N/qm8ydb/drBfOTSjZmMLSId67sk CvZFX2i69WumEktxRqKhFnNRcSIAZVhs47ECAAA= Archived-At: Cc: Bernard Aboba , "ice@ietf.org" Subject: Re: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 10:03:26 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE8254AESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIHRleHQgaW4gNTI0NWJpcyB0 aGF0IGV4cGxpY2l0bHkgc2F5cyB0aGF0IGVpdGhlciBlbmRwb2ludHMgc3VwcG9ydGluZyBwcm90 b2NvbCBYIG5lZWQgdG8gYmUgYWJsZSB0byBzd2l0Y2ggYmV0d2VlbiBjYW5kaWRhdGUgcGFpcnMg KGV2ZW4gaWYgdGhleSB1c2UgZGlmZmVyZW50IHRyYW5zcG9ydCksIE9SIHByb3RvY29sIFggZGF0 YSBtdXN0IG5vdCBiZSBkb25lIHByaW9yIHRvIG5vbWluYXRpb24gKHdoaWNoLCBvZiBjb3Vyc2Us IHdvdWxkIG5vdCB3b3JrIGluIGNvbnRpbnVvdXMgbm9taW5hdGlvbiBzY2VuYXJpb3MpLg0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5A dGVsdXJpeC5jb21dDQpTZW50OiAyMSBOb3ZlbWJlciAyMDE2IDAxOjIxDQpUbzogQ2hyaXN0ZXIg SG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNjOiBpY2VAaWV0Zi5v cmc7IEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPg0KU3ViamVjdDogUmU6 IFtJY2VdIERvIHdlIHdhbnQgdG8gbWFuZGF0ZSBhbGwgcHJvdG9jb2xzIHN1cHBvcnRpbmcgSUNF IGFuZCBtdWx0aXBsZSB0cmFuc3BvcnRzIHRvIHN1cHBvcnQgdHJhbnNwb3J0IHN3aXRjaCBvbi10 aGUtZmx5IGJlZm9yZSBub21pbmF0aW9uPw0KDQpIaSBDaHJpc3RlciwNCg0KQmVybmFyZCBoYXZl IGFscmVhZHkgYWRkcmVzc2VkIHRoZSBpc3N1ZXMgcmVsYXRlZCB0byBhZ2dyZXNzaXZlIG5vbWlu YXRpb24uDQoNCkkgYWxzbyB3YW50ZWQgdG8gYnJpbmcgdXAgdGhhdCB0aGlzIGdyb3VwIGlzIGFs c28gYWN0aXZlbHkgd29ya2luZyBvbiBjb250aW51b3VzIG5vbWluYXRpb24uIFdpdGggY29udGlu dW91cyBub21pbmF0aW9uICJzd2l0Y2hpbmciIGJldHdlZW4gY2FuZGlkYXRlIHBhaXJzIGNhbiBv Y2N1ciBmb3IgYSBmYWlybHkgbG9uZyB0aW1lIGFuZCBwcm90b2NvbCBjYW5ub3Qgd2FpdCBmb3Ig dGhlIG5vbWluYXRpb24gdG8gY29tcGxldGUuIFJlcXVpcmluZyBmb3IgdGhlIHByb3RvY29sIHRv IHdhaXQgdW50aWwgbm9taW5hdGlvbiBpcyBjb21wbGV0ZSB3aWxsIG1ha2UgaXQgaW5jb21wYXRp YmxlIHdpdGggY29udGludW91cyBub21pbmF0aW9uLg0KDQpGaW5hbGx5LCBhbmQgbW9zdCBpbXBv cnRhbnRseSwgSSB3YW50ZWQgdGhpcyBncm91cCB0byBleGFtaW5lIHRoZSBwdXJwb3NlIG9mIHRj cCBjYW5kaWRhdGVzLiBUaGUgd2F5IFJGQyA2NTQ0IGlzIHdyaXR0ZW4sIGl0IGltcGxpZXMgdGhh dCBJQ0UgY3JlYXRlcyBhIGNvbXBsZXRlIGZyYW1ld29yayBmb3Igc2V0dGluZyB1cCBUQ1AgY29u bmVjdGlvbnMgYmV0d2VlbiB0d28gZW5kIHBvaW50cyB3aXRoIG9uZSBvciBib3RoIG9mIHRoZXNl IGVuZCBwb2ludHMgbG9jYXRlZCBiZWhpbmQgTkFULiBUaGUgZG9jdW1lbnQgdGFsa3MgYWJvdXQg c2ltdWx0YW5lb3VzIG9wZW4gY2FuZGlkYXRlcywgcmVmbGV4aXZlIFRDUCBjYW5kaWRhdGVzIGFu ZCBzZXR0aW5nIHVwIHJlbGF5IGZvciBUQ1AgY29ubmVjdGlvbnMuIEF0IHRoZSBzYW1lIHRpbWUs IGluIHRoZSBhY3R1YWwgaW1wbGVtZW50YXRpb25zIHRjcCByZWxheSBhbmQgcmVmbGV4aXZlIGNh bmRpZGF0ZSBhcmUgcmVkdW5kYW50LCBhbmQgdGNwIGNhbmRpZGF0ZXMgYXJlIG9ubHkgdXNlZCBh cyBhIGZhaWwtb3ZlciBmb3IgdWRwIGNhbmRpZGF0ZXMgd2hlbiB1ZHAgaXMgYmxvY2tlZCBieSBm aXJld2FsbCBhbmQgb25lIG9mIHRoZSBlbmQgcG9pbnRzIGlzIG9uIHB1YmxpYyBJUCBhZGRyZXNz LiBJIGhhdmUgbm90IHNlZW4gYW55Ym9keSBpbXBsZW1lbnRpbmcgdGhlIHNpbXVsdGFuZW91cyBv cGVuIGNhbmRpZGF0ZXMgYW5kIHN1Y2ggY2FuZGlkYXRlcyBhcmUgaW1wb3NzaWJsZSB0byBpbXBs ZW1lbnQgb24gc29tZSBvZiB0aGUgb3BlcmF0aW5nIHN5c3RlbXMuIEFsbCBJIHNlZSBhcmUgaG9z dCBhY3RpdmUgdGNwIGNhbmRpZGF0ZXMgb24gdGhlIGVuZCBwb2ludHMgbG9jYXRlZCBiZWhpbmQg TkFUIGFuZCBob3N0IHBhc3NpdmUgdGNwIGNhbmRpZGF0ZXMgb24gdGhlIGVuZCBwb2ludHMgbG9j YXRlZCBvbiBwdWJsaWMgaW50ZXJuZXQuDQoNCkkgd291bGQgYXJndWUgdGhhdCBjcmVhdGluZyBh IGZ1bGwgZnJhbWV3b3JrIGZvciBUQ1AgY29ubmVjdGlvbnMgYW5kIG9ubHkgdXNpbmcgdGNwIGNh bmRpZGF0ZXMgZm9yIHVkcCBmYWlsLW92ZXIgYXJlIHR3byB2ZXJ5IGRpZmZlcmVudCB1c2UgY2Fz ZXMuIFRoZXkgc2hvdWxkIGJlIHNwZWNpZmllZCBkaWZmZXJlbnRseSBhbmQgY2Fubm90IGJlIHVz ZWQgYXQgdGhlIHNhbWUgdGltZS4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gc3BlbGwg dGhpcyBvdXQgYW5kIGxpbWl0IHRoZSB0Y3AgY2FuZGlkYXRlIHVzZSBjYXNlLg0KDQpGb3IgaW5z dGFuY2UsIGluIGNhc2Ugb2YgQkZDUCwgVENQL0JGQ1AgY2FuIGJlIHVzZWQgd2l0aCBUQ1AgY29u bmVjdGlvbiBmcmFtZXdvcmssIHdoaWNoIHdvdWxkIHJlcXVpcmUgYSBkaXJlY3QgaG9zdCB0byBo b3N0IGNvbm5lY3Rpb25zLCBzbyBjb25uZWN0aW9ucyB0byByZWZsZXhpdmUgYWRkcmVzc2VzIGFu ZCBzb21lIHN1cHBvcnQgZm9yIHJlbGF5LiBUaGlzIGZyYW1ld29yayBob3dldmVyLCBpcyBub3Qg SUNFLCBhbmQgd2lsbCBub3Qgc3VwcG9ydCBVRFAgYW5kIHdpbGwgdXNlIEJGQ1AgbmF0aXZlIGZy YW1pbmcuIE9uIHRoZSBvdGhlciBoYW5kLCBVRFAvQkZDUCBjYW4gbmF0dXJhbGx5IHJ1biBvbiB0 b3Agb2YgSUNFLCB1c2UgYm90aCB1ZHAgYW5kIHRjcCBjYW5kaWRhdGVzLiBUaGUgb25seSB0Y3Ag Y2FuZGlkYXRlcyB1c2VkIGluIHRoaXMgY2FzZSB3b3VsZCBiZSBob3N0IGNhbmRpZGF0ZXMgYW5k IEJGQ1AgcnVubmluZyBvdmVyIHRjcCBjYW5kaWRhdGVzIHdpbGwgYmUgVURQL0JGQ1Agd2l0aCAg UkZDIDQ1NzEgZnJhbWluZyBhcyByZXF1aXJlZCBieSBSRkMgNjU0NCAoaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzY1NDQjc2VjdGlvbi0xMC4xKS4NCg0KSSB0aGluayBtb3N0IG9mIHRo aXMgZGlzY3Vzc2lvbiBpcyBkdWUgdG8gdmVyeSBsaW1pdGVkIGRlc2lnbiBhbmQgYW5hbHlzaXMg dGhhdCB3ZW50IGludG8gc3BlY2lmaWNhdGlvbiBvZiBCRkNQIHdpdGggSUNFLiBPbmNlIEJGQ1Ag b3ZlciBJQ0Ugd291bGQgYmUgd2VsbCBkZWZpbmVkIG1vc3Qgb2YgdGhvc2UgaXNzdWVzIHdpbGwg ZGlzYXBwZWFyLg0KDQpSZWdhcmRzLA0KDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoN Ck9uIFNhdCwgTm92IDE5LCAyMDE2IGF0IDk6MjIgUE0sIEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQu YWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4+IHdyb3RlOg0K DQpDaHJpc3RlciAtLQ0KDQpXaXRoIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiwgYSBUQ1AgY2FuZGlk YXRlLXBhaXIgY291bGQgYmUgbm9taW5hdGVkLCBhbmQgdGhlbiBhIFVEUCBjYW5kaWRhdGUtcGFp ciBjb3VsZCBiZSBub21pbmF0ZWQsIGFuZCBkYXRhIGNvdWxkIGJlIHNlbnQgb24gYSBzdWNjZXNz ZnVsIHBhaXIuICBTbyAic3dpdGNoaW5nIiBjYW4gYWxzbyBvY2N1ci4gIEdpdmVuIHRoYXQgdGhl IGNvbnRyb2xsZWQgcGVlciBuZWVkcyB0byBiZSBhYmxlIHRvIHJlY2VpdmUgb24gYW55IHN1Y2Nl c3NmdWwgcGFpciwgaXQgaGFzIHRvIGJlIHByZXBhcmVkIGZvciByZWNlaXZpbmcgYm90aCBVRFAg YW5kIFRDUCBwYWNrZXRzIGF0IHRoZSBzYW1lIHRpbWUuDQoNClNvIGhvdyBpcyAicGFzc2l2ZS1h Z2dyZXNzaXZlIiBub21pbmF0aW9uIG1vcmUgb25lcm91cyB0aGFuIGFnZ3Jlc3NpdmUgaW4gdGhp cyByZXNwZWN0Pw0KDQpPbiBOb3YgMTksIDIwMTYgMToyNyBBTSwgIkNocmlzdGVyIEhvbG1iZXJn IiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQpPbmUgcG90ZW50aWFsIGlzc3VlIHRoYXQg Y2FtZSB0byBteSBtaW5kIHdoaWxlIHJlYWRpbmcgdGhlIFNEUCBtLSBsaW5lIHRocmVhZC4NCg0K UHJldmlvdXNseSwgYmVmb3JlIHJlbW92YWwgb2YgYWdncmVzc2l2ZSBub21pbmF0aW9uLCB3aGls ZSBhbmQgZW5kcG9pbnQgbWlnaHQgc3VwcG9ydCBib3RoIFVEUCBhbmQgVENQIGZvciBhIHByb3Rv Y29sLCBpdCBkaWRu4oCZdCBoYXZlIHRvIGJlIGFibGUgdG8gc2ltdWx0YW5lb3VzbHkgdXNlIHRo ZSBwcm90b2NvbCB3aXRoIGJvdGggVURQIGFuZCBUQ1AsIGFuZCBzd2l0Y2hpbmcgYmV0d2Vlbi4g QmVjYXVzZSwgdW50aWwgbm9taW5hdGlvbiB3YXMgZG9uZSwgbm8gcHJvdG9jb2wgZGF0YSB3YXMg c2VudC4gQW5kLCBvbmNlIG5vbWluYXRpb24gaGFkIGJlZW4gZG9uZSwgZW5kcG9pbnRzIHVzZWQg dGhlIHByb3RvY29sIHdpdGggdGhlIHNlbGVjdGVkIHRyYW5zcG9ydC4NCg0KTm93LCB3aXRoIHRo ZSBhbGxvd2VkLXRvLXNlbmQtbWVkaWEtYmVmb3JlLW5vbWluYXRpb24gcnVsZXMsIHByb3RvY29s cyBiYXNpY2FsbHkgaGF2ZSB0byBzdXBwb3J0IHN3aXRjaCBvZiB0cmFuc3BvcnQgKGZyb20gVURQ IHRvIFRDUCwgYW5kIHZpY2UgdmVyc2EpLCB1bnRpbCB0aGUgbm9taW5hdGlvbiB0YWtlcyBwbGFj ZS4NCg0KTm93LCBldmVuIHBlb3BsZSBhbHdheXMgc2F5IHRoYXQgYSBnb29kIGRlc2lnbmVkIHBy b3RvY29sIHNob3VsZCBiZSB0cmFuc3BvcnQtaW5kZXBlbmRlbnQsIGlzbuKAmXQgKm1hbmRhdGlu ZyogdHJhbnNwb3J0IHN3aXRjaGluZyBvbi10aGUtZmx5IChiZWZvcmUgbm9taW5hdGlvbiB0YWtl cyBwbGFjZSkgYnkgYWxsIHByb3RvY29scyBzdXBwb3J0aW5nIElDRSBhbmQgbXVsdGlwbGUgdHJh bnNwb3J0cyBhIGJhZCB0aGluZyB0byBkbz8NCg0KUGVyaGFwcyB0aGUgSUNFIGNvbnNpZGVyYXRp b25zIG9mIGVhY2ggcHJvdG9jb2wgKFJUUCwgQkZDUCBldGMpIHNob3VsZCBpbmRpY2F0ZSB3aGV0 aGVyIHRyYW5zcG9ydCBzd2l0Y2hpbmcgaXMgc3VwcG9ydGVkLCBhbmQgd2hldGhlciB0aGVyZSBh cmUgcHJvdG9jb2wgc3BlY2lmaWMgcHJvY2VkdXJlcyBhc3NvY2lhdGVkIHdpdGggdGhhdC4gSSBn dWVzcyBhIHByb3RvY29sIGNvdWxkIGFsc28gc3BlY2lmeSB0aGF0IGRhdGEgc2hvdWxkbuKAmXQg YmUgc2VudCBpbiB0aGUgZmlyc3QgcGxhY2UgYmVmb3JlIG5vbWluYXRpb24gaGFzIGJlZW4gZG9u ZSwgaWYgdGhlcmUgYXJlIGdvb2QgcmVhc29ucyBmb3IgdGhhdC4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkljZSBtYWlsaW5nIGxpc3QNCkljZUBpZXRmLm9yZzxtYWlsdG86SWNlQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkljZSBtYWlsaW5nIGxpc3QNCkljZUBp ZXRmLm9yZzxtYWlsdG86SWNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pY2UNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4BE8254AESESSMB209erics_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MjEwMjg3MzI1MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTEzMDE1MzgwNiAxMzQ4MDc1NjkgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4 MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OTt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBo YXZlIHRleHQgaW4gNTI0NWJpcyB0aGF0IGV4cGxpY2l0bHkgc2F5cyB0aGF0IGVpdGhlciBlbmRw b2ludHMgc3VwcG9ydGluZyBwcm90b2NvbCBYIG5lZWQgdG8gYmUgYWJsZSB0bw0KIHN3aXRjaCBi ZXR3ZWVuIGNhbmRpZGF0ZSBwYWlycyAoZXZlbiBpZiB0aGV5IHVzZSBkaWZmZXJlbnQgdHJhbnNw b3J0KSwgT1IgcHJvdG9jb2wgWCBkYXRhIG11c3Qgbm90IGJlIGRvbmUgcHJpb3IgdG8gbm9taW5h dGlvbiAod2hpY2gsIG9mIGNvdXJzZSwgd291bGQgbm90IHdvcmsgaW4gY29udGludW91cyBub21p bmF0aW9uIHNjZW5hcmlvcykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0 ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJf TWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSb21hbiBTaHBvdW50IFttYWls dG86cm9tYW5AdGVsdXJpeC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjEgTm92ZW1iZXIgMjAx NiAwMToyMTxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGljZUBpZXRmLm9yZzsgQmVy bmFyZCBBYm9iYSAmbHQ7YmVybmFyZC5hYm9iYUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbSWNlXSBEbyB3ZSB3YW50IHRvIG1hbmRhdGUgYWxsIHByb3RvY29scyBzdXBw b3J0aW5nIElDRSBhbmQgbXVsdGlwbGUgdHJhbnNwb3J0cyB0byBzdXBwb3J0IHRyYW5zcG9ydCBz d2l0Y2ggb24tdGhlLWZseSBiZWZvcmUgbm9taW5hdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSBDaHJpc3Rlciw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJlcm5hcmQgaGF2ZSBhbHJlYWR5IGFkZHJlc3NlZCB0aGUgaXNz dWVzIHJlbGF0ZWQgdG8gYWdncmVzc2l2ZSBub21pbmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFsc28gd2FudGVkIHRvIGJyaW5n IHVwIHRoYXQgdGhpcyBncm91cCBpcyBhbHNvIGFjdGl2ZWx5IHdvcmtpbmcgb24gY29udGludW91 cyBub21pbmF0aW9uLiBXaXRoIGNvbnRpbnVvdXMgbm9taW5hdGlvbiAmcXVvdDtzd2l0Y2hpbmcm cXVvdDsgYmV0d2VlbiBjYW5kaWRhdGUgcGFpcnMgY2FuIG9jY3VyIGZvciBhIGZhaXJseSBsb25n IHRpbWUgYW5kIHByb3RvY29sIGNhbm5vdCB3YWl0IGZvciB0aGUgbm9taW5hdGlvbiB0bw0KIGNv bXBsZXRlLiBSZXF1aXJpbmcgZm9yIHRoZSBwcm90b2NvbCB0byB3YWl0IHVudGlsIG5vbWluYXRp b24gaXMgY29tcGxldGUgd2lsbCBtYWtlIGl0IGluY29tcGF0aWJsZSB3aXRoIGNvbnRpbnVvdXMg bm9taW5hdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RmluYWxseSwgYW5kIG1vc3QgaW1wb3J0YW50bHksIEkgd2FudGVkIHRoaXMgZ3Jv dXAgdG8gZXhhbWluZSB0aGUgcHVycG9zZSBvZiB0Y3AgY2FuZGlkYXRlcy4gVGhlIHdheSBSRkMg NjU0NCBpcyB3cml0dGVuLCBpdCBpbXBsaWVzIHRoYXQgSUNFIGNyZWF0ZXMgYSBjb21wbGV0ZSBm cmFtZXdvcmsgZm9yIHNldHRpbmcgdXAgVENQIGNvbm5lY3Rpb25zIGJldHdlZW4gdHdvIGVuZCBw b2ludHMgd2l0aCBvbmUgb3INCiBib3RoIG9mIHRoZXNlIGVuZCBwb2ludHMgbG9jYXRlZCBiZWhp bmQgTkFULiBUaGUgZG9jdW1lbnQgdGFsa3MgYWJvdXQgc2ltdWx0YW5lb3VzIG9wZW4gY2FuZGlk YXRlcywgcmVmbGV4aXZlIFRDUCBjYW5kaWRhdGVzIGFuZCBzZXR0aW5nIHVwIHJlbGF5IGZvciBU Q1AgY29ubmVjdGlvbnMuIEF0IHRoZSBzYW1lIHRpbWUsIGluIHRoZSBhY3R1YWwgaW1wbGVtZW50 YXRpb25zIHRjcCByZWxheSBhbmQgcmVmbGV4aXZlIGNhbmRpZGF0ZSBhcmUgcmVkdW5kYW50LA0K IGFuZCB0Y3AgY2FuZGlkYXRlcyBhcmUgb25seSB1c2VkIGFzIGEgZmFpbC1vdmVyIGZvciB1ZHAg Y2FuZGlkYXRlcyB3aGVuIHVkcCBpcyBibG9ja2VkIGJ5IGZpcmV3YWxsIGFuZCBvbmUgb2YgdGhl IGVuZCBwb2ludHMgaXMgb24gcHVibGljIElQIGFkZHJlc3MuIEkgaGF2ZSBub3Qgc2VlbiBhbnli b2R5IGltcGxlbWVudGluZyB0aGUgc2ltdWx0YW5lb3VzIG9wZW4gY2FuZGlkYXRlcyBhbmQgc3Vj aCBjYW5kaWRhdGVzIGFyZSBpbXBvc3NpYmxlIHRvDQogaW1wbGVtZW50IG9uIHNvbWUgb2YgdGhl IG9wZXJhdGluZyBzeXN0ZW1zLiBBbGwgSSBzZWUgYXJlIGhvc3QgYWN0aXZlIHRjcCBjYW5kaWRh dGVzIG9uIHRoZSBlbmQgcG9pbnRzIGxvY2F0ZWQgYmVoaW5kIE5BVCBhbmQgaG9zdCBwYXNzaXZl IHRjcCBjYW5kaWRhdGVzIG9uIHRoZSBlbmQgcG9pbnRzIGxvY2F0ZWQgb24gcHVibGljIGludGVy bmV0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIHdvdWxkIGFyZ3VlIHRoYXQgY3JlYXRpbmcgYSBmdWxsIGZyYW1ld29yayBmb3IgVENQIGNv bm5lY3Rpb25zIGFuZCBvbmx5IHVzaW5nIHRjcCBjYW5kaWRhdGVzIGZvciB1ZHAgZmFpbC1vdmVy IGFyZSB0d28gdmVyeSBkaWZmZXJlbnQgdXNlIGNhc2VzLiBUaGV5IHNob3VsZCBiZSBzcGVjaWZp ZWQgZGlmZmVyZW50bHkgYW5kIGNhbm5vdCBiZSB1c2VkIGF0IHRoZSBzYW1lIHRpbWUuIEkgdGhp bmsgaXQgd291bGQNCiBiZSBiZXR0ZXIgdG8gc3BlbGwgdGhpcyBvdXQgYW5kIGxpbWl0IHRoZSB0 Y3AgY2FuZGlkYXRlIHVzZSBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgaW5zdGFuY2UsIGluIGNhc2Ugb2YgQkZDUCwgVENQL0JG Q1AgY2FuIGJlIHVzZWQgd2l0aCBUQ1AgY29ubmVjdGlvbiBmcmFtZXdvcmssIHdoaWNoIHdvdWxk IHJlcXVpcmUgYSBkaXJlY3QgaG9zdCB0byBob3N0IGNvbm5lY3Rpb25zLCBzbyBjb25uZWN0aW9u cyB0byByZWZsZXhpdmUgYWRkcmVzc2VzIGFuZCBzb21lIHN1cHBvcnQgZm9yIHJlbGF5LiBUaGlz IGZyYW1ld29yayBob3dldmVyLCBpcyBub3QgSUNFLA0KIGFuZCB3aWxsIG5vdCBzdXBwb3J0IFVE UCBhbmQgd2lsbCB1c2UgQkZDUCBuYXRpdmUgZnJhbWluZy4gT24gdGhlIG90aGVyIGhhbmQsIFVE UC9CRkNQIGNhbiBuYXR1cmFsbHkgcnVuIG9uIHRvcCBvZiBJQ0UsIHVzZSBib3RoIHVkcCBhbmQg dGNwIGNhbmRpZGF0ZXMuIFRoZSBvbmx5IHRjcCBjYW5kaWRhdGVzIHVzZWQgaW4gdGhpcyBjYXNl IHdvdWxkIGJlIGhvc3QgY2FuZGlkYXRlcyBhbmQgQkZDUCBydW5uaW5nIG92ZXIgdGNwJm5ic3A7 Y2FuZGlkYXRlcw0KIHdpbGwgYmUgVURQL0JGQ1Agd2l0aCAmbmJzcDtSRkMgNDU3MSBmcmFtaW5n IGFzIHJlcXVpcmVkIGJ5IFJGQyA2NTQ0ICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNjU0NCNzZWN0aW9uLTEwLjEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM2NTQ0I3NlY3Rpb24tMTAuMTwvYT4pLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIG1vc3Qgb2YgdGhpcyBkaXNjdXNzaW9uIGlz IGR1ZSB0byB2ZXJ5IGxpbWl0ZWQgZGVzaWduIGFuZCBhbmFseXNpcyB0aGF0IHdlbnQgaW50byBz cGVjaWZpY2F0aW9uIG9mIEJGQ1Agd2l0aCBJQ0UuIE9uY2UgQkZDUCBvdmVyIElDRSB3b3VsZCBi ZSB3ZWxsIGRlZmluZWQgbW9zdCBvZiB0aG9zZSBpc3N1ZXMgd2lsbCBkaXNhcHBlYXIuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgTm92IDE5LCAy MDE2IGF0IDk6MjIgUE0sIEJlcm5hcmQgQWJvYmEgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXJuYXJk LmFib2JhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJlcm5hcmQuYWJvYmFAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHA+Q2hyaXN0ZXIg LS08bzpwPjwvbzpwPjwvcD4NCjxwPldpdGggYWdncmVzc2l2ZSBub21pbmF0aW9uLCBhIFRDUCBj YW5kaWRhdGUtcGFpciBjb3VsZCBiZSBub21pbmF0ZWQsIGFuZCB0aGVuIGEgVURQIGNhbmRpZGF0 ZS1wYWlyIGNvdWxkIGJlIG5vbWluYXRlZCwgYW5kIGRhdGEgY291bGQgYmUgc2VudCBvbiBhIHN1 Y2Nlc3NmdWwgcGFpci4mbmJzcDsgU28gJnF1b3Q7c3dpdGNoaW5nJnF1b3Q7IGNhbiBhbHNvIG9j Y3VyLiZuYnNwOyBHaXZlbiB0aGF0IHRoZSBjb250cm9sbGVkIHBlZXIgbmVlZHMgdG8gYmUgYWJs ZSB0byByZWNlaXZlDQogb24gYW55IHN1Y2Nlc3NmdWwgcGFpciwgaXQgaGFzIHRvIGJlIHByZXBh cmVkIGZvciByZWNlaXZpbmcgYm90aCBVRFAgYW5kIFRDUCBwYWNrZXRzIGF0IHRoZSBzYW1lIHRp bWUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPlNvIGhvdyBpcyAmcXVvdDtwYXNzaXZlLWFnZ3Jlc3Np dmUmcXVvdDsgbm9taW5hdGlvbiBtb3JlIG9uZXJvdXMgdGhhbiBhZ2dyZXNzaXZlIGluIHRoaXMg cmVzcGVjdD88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE5vdiAxOSwgMjAxNiAxOjI3IEFNLCAmcXVvdDtDaHJpc3RlciBIb2xtYmVyZyZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk9uZSBwb3RlbnRpYWwgaXNzdWUgdGhhdCBjYW1lIHRvIG15IG1pbmQg d2hpbGUgcmVhZGluZyB0aGUgU0RQIG0tIGxpbmUgdGhyZWFkLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+UHJldmlvdXNseSwgYmVmb3JlIHJlbW92YWwgb2YgYWdncmVzc2l2ZSBub21pbmF0 aW9uLCB3aGlsZSBhbmQgZW5kcG9pbnQgbWlnaHQgc3VwcG9ydCBib3RoIFVEUCBhbmQgVENQIGZv ciBhIHByb3RvY29sLCBpdCBkaWRu4oCZdCBoYXZlIHRvIGJlIGFibGUgdG8gc2ltdWx0YW5lb3Vz bHkgdXNlIHRoZSBwcm90b2NvbA0KIHdpdGggYm90aCBVRFAgYW5kIFRDUCwgYW5kIHN3aXRjaGlu ZyBiZXR3ZWVuLiBCZWNhdXNlLCB1bnRpbCBub21pbmF0aW9uIHdhcyBkb25lLCBubyBwcm90b2Nv bCBkYXRhIHdhcyBzZW50LiBBbmQsIG9uY2Ugbm9taW5hdGlvbiBoYWQgYmVlbiBkb25lLCBlbmRw b2ludHMgdXNlZCB0aGUgcHJvdG9jb2wgd2l0aCB0aGUgc2VsZWN0ZWQgdHJhbnNwb3J0LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm93LCB3aXRoIHRoZSBhbGxvd2VkLXRvLXNlbmQtbWVk aWEtYmVmb3JlLW5vbWluYXRpb24gcnVsZXMsIHByb3RvY29scyBiYXNpY2FsbHkgaGF2ZSB0byBz dXBwb3J0IHN3aXRjaCBvZiB0cmFuc3BvcnQgKGZyb20gVURQIHRvIFRDUCwgYW5kIHZpY2UgdmVy c2EpLCB1bnRpbCB0aGUgbm9taW5hdGlvbiB0YWtlcw0KIHBsYWNlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Tm93LCBldmVuIHBlb3BsZSBhbHdheXMgc2F5IHRoYXQgYSBnb29kIGRlc2ln bmVkIHByb3RvY29sIHNob3VsZCBiZSB0cmFuc3BvcnQtaW5kZXBlbmRlbnQsIGlzbuKAmXQgKjxi Pm1hbmRhdGluZzwvYj4qIHRyYW5zcG9ydCBzd2l0Y2hpbmcgb24tdGhlLWZseSAoYmVmb3JlIG5v bWluYXRpb24gdGFrZXMgcGxhY2UpDQogYnkgYWxsIHByb3RvY29scyBzdXBwb3J0aW5nIElDRSBh bmQgbXVsdGlwbGUgdHJhbnNwb3J0cyBhIGJhZCB0aGluZyB0byBkbz88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlBlcmhhcHMgdGhlIElDRSBjb25zaWRlcmF0aW9ucyBvZiBlYWNoIHByb3Rv Y29sIChSVFAsIEJGQ1AgZXRjKSBzaG91bGQgaW5kaWNhdGUgd2hldGhlciB0cmFuc3BvcnQgc3dp dGNoaW5nIGlzIHN1cHBvcnRlZCwgYW5kIHdoZXRoZXIgdGhlcmUgYXJlIHByb3RvY29sIHNwZWNp ZmljIHByb2NlZHVyZXMgYXNzb2NpYXRlZA0KIHdpdGggdGhhdC4gSSBndWVzcyBhIHByb3RvY29s IGNvdWxkIGFsc28gc3BlY2lmeSB0aGF0IGRhdGEgc2hvdWxkbuKAmXQgYmUgc2VudCBpbiB0aGUg Zmlyc3QgcGxhY2UgYmVmb3JlIG5vbWluYXRpb24gaGFzIGJlZW4gZG9uZSwgaWYgdGhlcmUgYXJl IGdvb2QgcmVhc29ucyBmb3IgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpJY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkljZUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPkljZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpJY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOkljZUBpZXRmLm9yZyI+SWNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2U8L2E+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4BE8254AESESSMB209erics_-- From nobody Mon Nov 21 07:39:15 2016 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 6A1A21296BD for ; Mon, 21 Nov 2016 07:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 nO7q8SML321m for ; Mon, 21 Nov 2016 07:39:04 -0800 (PST) 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 5FF59129680 for ; Mon, 21 Nov 2016 07:39:04 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id g23so153988735wme.1 for ; Mon, 21 Nov 2016 07:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lhB1xuZ87INJAATfkBXKTvb19/H9i+ZEVwfhLQhR2Ts=; b=Y0dcpyfDofTnIuqQjQ8dyygmqoundxU625SSZ7JOqstZS7+UN3gukoUKYgAExuJvKa AW76o8vAF1VKB/j546keXXD0yHtw3t9VR1l3yEYgLN+Pn5FXwUggYWAjh5vjaegbu7Ir hXvt8Z3f1MU1uwFR/fC+/HLtCBbRTTtndUlBnUyYzmlD/xVPrp5EI+CAr9OL8nZ1D0+/ zeYFroNsb+oM/L7TR0l2aOTDhrPdlkiVgaaOD4Z9xDcXadVd0n6t7dOLwuBZyOiNU836 s8K6ejcWXb2gPbuHdTpha7KZg5rppEtQhwtuacZsQMRUaK+rlX8lGRIi9KrViXkejdtv JxXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lhB1xuZ87INJAATfkBXKTvb19/H9i+ZEVwfhLQhR2Ts=; b=nH3WQj63B8sWqG0iP9T+FaM7HylzQZYXPsk5v8DdD/y6ZIBpHo/2J46iSyyZr/kZBh yTpW6/PVUw1Y5J9cu5hqBWN+rCsXJWbDbyE2CKow+bdn73WCy9h86ZwqNv5A9yzBGK6m BwppdnqVPMYlQD7PVQfdWYrrad/I9PrPkgTFTPbaoYfQ+uFdKQJVBAHc6PDXHLhZRsgl RkKz48iKteJbrXBDOQ0YitqJjPmiDWkW11VG6tlGMMB9nnfWL8v8Fk4sLJvGi6fTMB6A ykUx86W6L/qX7ACnyogIQ0tHCwyCI4kLsvgG39c4RxlMG0apPdNX20upnNjXNqh6LWkU fPow== X-Gm-Message-State: AKaTC02W61PQukV/l9W5M1RFvU4elFH0zgngHi/Sr4XmuHUQQuYeJFd8XUzzGxfR2eB6Yuk56XL4RxMpK9tifg== X-Received: by 10.194.222.202 with SMTP id qo10mr9739275wjc.115.1479742742928; Mon, 21 Nov 2016 07:39:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.23.196 with HTTP; Mon, 21 Nov 2016 07:38:42 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE823F6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BE823F6@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 21 Nov 2016 16:38:42 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ice@ietf.org" , "bfcpbis@ietf.org" , "mmusic@ietf.org" , Roman Shpount , Alan Ford Subject: Re: [Ice] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 15:39:08 -0000 2016-11-21 10:27 GMT+01:00 Christer Holmberg : > This has been discussed before: the procedures have to be backward compat= ible with non-ICE endpoints. I'd rather deprecate non-ICE endpoints. --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 21 09:58:50 2016 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 98954129A9D for ; Mon, 21 Nov 2016 09:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 yGJytSi2C9iX for ; Mon, 21 Nov 2016 09:58:47 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 A406112958F for ; Mon, 21 Nov 2016 09:58:47 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id y198so30293791oia.1 for ; Mon, 21 Nov 2016 09:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=k00w0yJMAkoCbaknyH7xlNyg7CJELBYmObhUgPsW4AM=; b=IgtPUoADox2oNSEzCAydRyjBFFiHd/LdfirciontZfxjszKi+H+yl+J8K4u8B+07Nz fLuaee0peP5HUfYarFvIh94TrS78gpRoaYENyN4vgBQailHjrYPYT6xltnuwbvJ80d6c AQkdvi/KXUjGeOHghFKu4I+jVVz5cZrxEuTWd2N75iAg17TT4SyZjr/zG2xjiAPLrXXp muN9xct3ed5gcDiMbu4UgqpLX5NjqfJbJeg9nZ0xysBYoa3myYxKHWGH5kGimzVms5j+ D4UrKs2dGte7Qz2HIu7D5q+qOlLzV02JXD8IFs6RhlAj3yo0XEAjy8XK9QRgf+gTh7HG m+Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=k00w0yJMAkoCbaknyH7xlNyg7CJELBYmObhUgPsW4AM=; b=CQmc5EED7U/WE7VbU4Ld5rdqSKw8tyqfhIrBpqOHDBL1umduuwbRWpL40HJm3qxcNt p9DK9t+SL9A+ZKruZZ7LIfKg1Skat4MlJu13WtEfD5QHInBS/HMZ329d6AFBvr6NvLkB geMVmNQY93FF6uiJ9YJCl6aFMpc3f9MuE5jHZg+HA8Y6LZsm2GKxY0vFLlv8IqejoV3n p5haj/T+c/jJ3HmqwXqCivvVQrzLO37GlidLxWwplyVXaknSEcvPEAOG5qaD2vM4ynBK Wmf+pNs42a2MvnXDl6WjWnAw/TQYQG6aUAph5V9whheDJt/kWRl8n7CO/JqyDDh83PC9 U6SQ== X-Gm-Message-State: AKaTC03RU0tz3Nj8HoybW4a/CRkItrXPGEqdfr0Yz0bVNVx+x8GnxQdzMxgRRv6kqa0aZQ== X-Received: by 10.157.31.59 with SMTP id x56mr9895462otd.191.1479751126869; Mon, 21 Nov 2016 09:58:46 -0800 (PST) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id x36sm7301980ota.5.2016.11.21.09.58.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Nov 2016 09:58:45 -0800 (PST) To: Roman Shpount , Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B4BE742CE@ESESSMB209.ericsson.se> From: Emil Ivov Message-ID: Date: Mon, 21 Nov 2016 11:58:44 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ice@ietf.org, Bernard Aboba Subject: Re: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 17:58:49 -0000 On 11/20/16 5:20 PM, Roman Shpount wrote: > I also wanted to bring up that this group is also actively working on > continuous nomination. Personally I am not aware of any active work on this in the group. Am I missing something? I am also opposed to trying to squeeze this into ICE's current version. Think we should think about a more serious redesign first. Emil -- https://jitsi.org From nobody Mon Nov 21 10:33:28 2016 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 AB1E512965D for ; Mon, 21 Nov 2016 10:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntwzP-EwsaTN for ; Mon, 21 Nov 2016 10:33:23 -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 8F91F12944E for ; Mon, 21 Nov 2016 10:33:23 -0800 (PST) X-AuditID: c1b4fb3a-97bff70000007918-dd-58333defb27e Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 58.FC.31000.FED33385; Mon, 21 Nov 2016 19:33:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0319.002; Mon, 21 Nov 2016 19:33:19 +0100 From: Christer Holmberg To: Emil Ivov Thread-Topic: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? Thread-Index: AdJCRurmAgGp6u03Tl6w25hg1S1vSQAhaaqAACvx7gAAJwrOAAADTaU6 Date: Mon, 21 Nov 2016 18:33:18 +0000 Message-ID: <1BDE19E2-7E3F-41CF-BBDF-BFC34953130E@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B4BE742CE@ESESSMB209.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbFdV/ejrXGEQcsDPYsN+/4zW6zZOYHF 4tuFWosZF6YyO7B47Jx1l91jyZKfTB7/3wR63JpSEMASxWWTkpqTWZZapG+XwJXR03OFuWA/ a8X65pksDYxrWboYOTkkBEwkejsmANlcHEIC6xglfh7/xAaSEBJYzCgxq82oi5GDg03AQqL7 nzZIWERAXqK7bRETiM0skC+x5vNNVpBeYYGZjBJrJv5hBHFEBGYxSnS9+MII0eEmsfDGEWYQ m0VAVeLO6o8sIEN5BewlFj8KhVjcwySx7PtKsKmcArYSr77uBOtlFBCT+H5qDdQ2cYlbT+Yz QVwtILFkz3lmCFtU4uXjf6wQNToSC3ZDPMAsoC2xbOFrsBpeAUGJkzOfsExgFJmFZNQsJC2z kLTMQtKygJFlFaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgzBzc8ttqB+PB546HGAU4GJV4 eDdcNooQYk0sK67MPcQowcGsJML7zMY4Qog3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC 6YklqdmpqQWpRTBZJg5OqQbGSlE7toAPJ6wuqBre81b3vt7288keHpEDKzd5ursyfOO/svrA u94DJtx3nnEvLlvHeN8gt1f32ISdvAsviivEC2hf/pBypW9qW1/TBVYTv2DtBRPZwmbuvMfz VPKPSaM96/l71le8gyXfLb+f8Zb58eEJLH5Tdj2Yu2TC5Cv7Z54zfq99svFWtRJLcUaioRZz UXEiALEXmV+VAgAA Archived-At: Cc: "ice@ietf.org" , Roman Shpount , Bernard Aboba Subject: Re: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 18:33:25 -0000 Doesn't 5245bis already implement "continuous nomination", by making nomina= ting "optional" (as you can send media before nomination)? Regards, Christer=20 Sent from my iPhone > On 21 Nov 2016, at 19.58, Emil Ivov wrote: >=20 >> On 11/20/16 5:20 PM, Roman Shpount wrote: >> I also wanted to bring up that this group is also actively working on >> continuous nomination. >=20 > Personally I am not aware of any active work on this in the group. Am I m= issing something? >=20 > I am also opposed to trying to squeeze this into ICE's current version. T= hink we should think about a more serious redesign first. >=20 > Emil >=20 > --=20 > https://jitsi.org From nobody Mon Nov 21 12:30:19 2016 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 D0EFF12949E for ; Mon, 21 Nov 2016 12:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 t4IRbDapUk4i for ; Mon, 21 Nov 2016 12:30:15 -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 9DA4D129B8E for ; Mon, 21 Nov 2016 12:30:15 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id 51so236509254uai.1 for ; Mon, 21 Nov 2016 12:30:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KDwp+YI5u2oC67QsuJj8/JpXHYgX5XmT4sbQXA5aBPk=; b=GMH2cvhij/O4+9FYTwMnDaEA6+8mJpryzCrS4S3MzYBlg3lt+CQUKktuIgSNOS/YAm gKVIDjCMC1sIUDzJcD7WRV1zI+gf/7bTCg1dyLTxa2eF39y+kal7JKt21iEHcaQiKJDW gXM5oOF0EfQ/h2cwj/bbFB4+c/9CusOG3lFVpQ25dxLYLxfdwCULsdSxHIbd5SGWNHKp dmo01eYz1nE+8NZ1UgFH50I5WY5wjG2OiX/Tep5t03MyhYICgmxj8nLNnM/442gP/b08 yOHV0cUTCoXq0bHkDm+TOX8nE03omK+CAeMwNPd7YS2y0FKDBH/XwDN7vYuamoIDW78B HtaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KDwp+YI5u2oC67QsuJj8/JpXHYgX5XmT4sbQXA5aBPk=; b=maw3D4AH/6ilIsBZrndd/bGl2cCR6Nm75N+X3Th4QJSp/8k1d9X3AAsi0ycHDUsfgf HTeAq9MJA2Zcm9hCT3nGp3oDA8K1m3GPTMTjdZHj/Z0fgbsIEgfzk0PiSZhr912LHV0a JYfnYuYOf6vXF11Pv71EsL4toaC6Kr4RIZIkdES/RAhffxX/ALqScg+SCqk4E87WwClG Y9qI5h/eNNvjwASaI+5h/ScL5Pwg7G6iH5UIvMZGleXl9UAh6ChvPtJb4Pb1gbiEMuSt GCdy6hrm3/C/uxv9sR7kx1PgBPJxRvFpd13gbUA3hrr01801uJXsF06YOzAK3aPXztm8 cGAQ== X-Gm-Message-State: AKaTC02mRhvbi/lfXfMnEkFaZWnZ00TGjNhxRRevD5m2lUYF5gTBZF9dszGoAJwflSHqAVE+bKSyS0ofPqEPNg== X-Received: by 10.176.84.207 with SMTP id q15mr6993123uaa.177.1479760214455; Mon, 21 Nov 2016 12:30:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Mon, 21 Nov 2016 12:29:53 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE82520@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BE742CE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BE82520@ESESSMB209.ericsson.se> From: Bernard Aboba Date: Mon, 21 Nov 2016 12:29:53 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c1b03b6ef7b1d0541d58569 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 20:30:18 -0000 --94eb2c1b03b6ef7b1d0541d58569 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christer said: "When using aggressive nomination (RFC 5245) the endpoints could not switch between valid candidate pairs as they wish. At any given time, only the nominated pair with the highest-priority could be used, meaning that there was only one selected pair at any given time." [BA] Without multi-path RTP, peers may only send media on a single pair at a time. However, the receiving side may see intermingling of media on multiple pairs, due to reordering or RTX, so a receiver needs to be prepared to deal with that. Note that ICEbis Section 4.3 requires an agent to be prepared to receive media once candidate information is sent (even before sending a response to a check!): " Once an agent has sent its candidate information, that agent MUST be prepared to receive both STUN and media packets on each candidate." So in practice, "highest-priority" isn't of much help to the receiver (it can't use that to stop listening on one or more candidates). "In 5245bis, media can be sent on any pair, and the switching can be done whenever, however, and there is no need to nominate to begin with, prior to sending media." [BA] While a "passive-aggressive" implementation may send media on any valid pair and switch between them , unless multi-path RTP is negotiated, it cannot send media on multiple pairs at once. On the receiving side, as with aggressive nomination, intermingling may occur. So I'm not clear that for a receiver things are all that different. On Mon, Nov 21, 2016 at 1:55 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Bernard, > > > > You are correct =E2=80=93 the problem already existed in RFC 5245. > > > > There is a difference, though: > > > > When using aggressive nomination (RFC 5245) the endpoints could not switc= h > between valid candidate pairs as they wish. At any given time, only the > nominated pair with the highest-priority could be used, meaning that ther= e > was only one selected pair at any given time. > > > > In 5245bis, media can be sent on any pair, and the switching can be done > whenever, however, and there is no need to nominate to begin with, prior = to > sending media. > > > > Regards, > > > > Christer > > > > > > *From:* Bernard Aboba [mailto:bernard.aboba@gmail.com] > *Sent:* 20 November 2016 04:23 > *To:* Christer Holmberg > *Cc:* ice@ietf.org > *Subject:* Re: [Ice] Do we want to mandate all protocols supporting ICE > and multiple transports to support transport switch on-the-fly before > nomination? > > > > Christer -- > > With aggressive nomination, a TCP candidate-pair could be nominated, and > then a UDP candidate-pair could be nominated, and data could be sent on a > successful pair. So "switching" can also occur. Given that the controll= ed > peer needs to be able to receive on any successful pair, it has to be > prepared for receiving both UDP and TCP packets at the same time. > > So how is "passive-aggressive" nomination more onerous than aggressive in > this respect? > > > > On Nov 19, 2016 1:27 AM, "Christer Holmberg" com> wrote: > > Hi, > > > > One potential issue that came to my mind while reading the SDP m- line > thread. > > > > Previously, before removal of aggressive nomination, while and endpoint > might support both UDP and TCP for a protocol, it didn=E2=80=99t have to = be able to > simultaneously use the protocol with both UDP and TCP, and switching > between. Because, until nomination was done, no protocol data was sent. > And, once nomination had been done, endpoints used the protocol with the > selected transport. > > > > Now, with the allowed-to-send-media-before-nomination rules, protocols > basically have to support switch of transport (from UDP to TCP, and vice > versa), until the nomination takes place. > > > > Now, even people always say that a good designed protocol should be > transport-independent, isn=E2=80=99t **mandating** transport switching on= -the-fly > (before nomination takes place) by all protocols supporting ICE and > multiple transports a bad thing to do? > > > > Perhaps the ICE considerations of each protocol (RTP, BFCP etc) should > indicate whether transport switching is supported, and whether there are > protocol specific procedures associated with that. I guess a protocol cou= ld > also specify that data shouldn=E2=80=99t be sent in the first place befor= e > nomination has been done, if there are good reasons for that. > > > > Regards, > > > > Christer > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --94eb2c1b03b6ef7b1d0541d58569 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christer said:=C2=A0

"Whe= n using aggressive nomination (RFC 5245) the endpoints could not switch bet= ween valid candidate pairs as they wish. At any given time, only the nomina= ted pair with the highest-priority could be used, meaning that there was on= ly one selected pair at any given time."
[BA] Without multi-path RTP, peers may only send= media on a single pair at a time.=C2=A0 However, the receiving side may se= e intermingling of media on multiple pairs, due to reordering or RTX, so a = receiver needs to be prepared to deal with that.
<= br>
Note that ICEbis Section 4.3 requires an agent= to be prepared to receive media once candidate information is sent (even b= efore sending a response to a check!):

=
" Once an agent has sent its candidate information, that agent M= UST be
=C2=A0 =C2=A0prepared to receive both STUN and media packets on each cand= idate."

= So in practice, =C2=A0"highest-priority" isn't o= f much help to the receiver (it can't use that to stop listening on one= or more candidates).

=C2=A0

<= span style=3D"color:rgb(31,73,125);font-family:calibri,sans-serif;font-size= :11pt">"In 5245bis, media can be sent on any pair, and the switching c= an be done whenever, however, and there is no need to nominate to begin wit= h, prior to sending media."

[BA] While= a "passive-aggressive" implementation may send media on any vali= d pair and switch between them , unless multi-path RTP is negotiated, it ca= nnot send media on multiple pairs at once.=C2=A0 On the receiving side, as = with aggressive nomination, intermingling may occur.=C2=A0 So I'm not c= lear that for a receiver things are all that different.

On Mon, Nov 21, 2016 at 1= :55 AM, Christer Holmberg <christer.holmberg@ericsson.com= > wrote:

Hi Bernard,

=C2=A0

You are correct =E2=80=93 the problem= already existed in RFC 5245.

=C2=A0

There is a difference, though:=

=C2=A0

When using aggressive nomination (RFC= 5245) the endpoints could not switch between valid candidate pairs as they= wish. At any given time, only the nominated pair with the highest-priority could be used, mea= ning that there was only one selected pair at any given time.=

=C2=A0

In 5245bis, media can be sent on any = pair, and the switching can be done whenever, however, and there is no need= to nominate to begin with, prior to sending media.

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: = Bernard Aboba [mailto:bernard.aboba@gmail.com]
Sent: 20 November 2016 04:23
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: ice@ietf.org
Subject: Re: [Ice] Do we want to mandate all protocols supporting IC= E and multiple transports to support transport switch on-the-fly before nom= ination?

=C2=A0

Christer --

With aggressive nomination, a TCP candidate-pair could be nominated, and= then a UDP candidate-pair could be nominated, and data could be sent on a = successful pair.=C2=A0 So "switching" can also occur.=C2=A0 Given= that the controlled peer needs to be able to receive on any successful pair, it has to be prepared for receiving both UDP and T= CP packets at the same time.

So how is "passive-aggressive" nomination more onerous than ag= gressive in this respect?

=C2=A0

On Nov 19, 2016 1:27 AM, "Christer Holmberg&quo= t; <= christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

One potential issue that came to my mind while readi= ng the SDP m- line thread.

=C2=A0

Previously, before removal of aggressive nomination,= while and endpoint might support both UDP and TCP for a protocol, it didn= =E2=80=99t have to be able to simultaneously use the protocol with both UDP and TCP, and switching between. Because, until nomination wa= s done, no protocol data was sent. And, once nomination had been done, endp= oints used the protocol with the selected transport.

=C2=A0

Now, with the allowed-to-send-media-before-nomi= nation rules, protocols basically have to support switch of transport (from= UDP to TCP, and vice versa), until the nomination takes place.

=C2=A0

Now, even people always say that a good designed pro= tocol should be transport-independent, isn=E2=80=99t *mandating* tra= nsport switching on-the-fly (before nomination takes place) by all protocols supporting ICE and multiple transports a bad thing to do?=

=C2=A0

Perhaps the ICE considerations of each protocol (RTP= , BFCP etc) should indicate whether transport switching is supported, and w= hether there are protocol specific procedures associated with that. I guess a protocol could also specify that data shouldn=E2=80= =99t be sent in the first place before nomination has been done, if there a= re good reasons for that.

=C2=A0

Regards,

=C2=A0

Christer


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


--94eb2c1b03b6ef7b1d0541d58569-- From nobody Mon Nov 21 12:47:07 2016 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 58433129BB1 for ; Mon, 21 Nov 2016 12:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4oFtIr6bvDWz for ; Mon, 21 Nov 2016 12:47:04 -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 A8493129BAE for ; Mon, 21 Nov 2016 12:47:04 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id x186so228910754vkd.1 for ; Mon, 21 Nov 2016 12:47:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dJHmkTxAf6OENkBBoBdtFi/Xj53fn9zI9BNg/VqgQYs=; b=fozl3SJjz1cBwYKwaFu8JxciTQvSqO7sjYnQgAbVXUnQ/4kWTzLCPxp8jVF1K8+Yyy z+Uf2YudCo9D8cNTvRTh9EGPVD7aTeHau9H45CbdoUN716C/WADrJ2a0IXBqYE1XlWnI pa3fMAgwjSo8jfqmw5uk5MMlAD1Jr0cpTXMPRgNR8+Y6glnIXyOz/XvpjR1r0Seobv7N iXQK3YaCPtt3kt4h+qHoLAzc4j89ejUjmdHnprGFZPofTgG474PAD+Bw+3acvp3XpM6Y GiebG2T0A5l4e6IVUSdMH+a8lcQPl3QMHo+l80mz5p5jxJOpzDlGp8HmrgksqU4yPvem rnzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dJHmkTxAf6OENkBBoBdtFi/Xj53fn9zI9BNg/VqgQYs=; b=mYgPFMEjpZWla9OQj2UGNEV6qtc/D6VeHNU8mC++jFCGxsDPucUljvkIa7g2Cj4ve+ 9he3Euw942byYRohCiy0oQq4EJv+L9plSsPBL2s4VpHoJaaitlPO5t1GTDoa1jlQlt6Z sPu+Ud1BAmUuPJGgzNfZTUbbCQJ5fLW23kYQtCe2v6aw+7RE4cI8CUR5xLEcHzspeiP3 CgbiGCrPNpe3QVAqkW9EjEyfEISGhJhtUNnJ9fHRd+Pt8KHM/L1DBNq/aEnVEW9Aixdw Yk70Cfe6w1aMVeasa5M6WGax/nkuWpQG9oBwMn/w4Gth5gGnRhbpAQvZMWiUFoSFU1km gyfg== X-Gm-Message-State: AKaTC03Cbrg0Ad5IXSSvDuBmO6TGNKYk8TEjEjE9PCmJVTStwYuDNyPA7P3nxGHuru3gz5BE5rqmhmsQLmXAWw== X-Received: by 10.31.1.215 with SMTP id 206mr8374253vkb.126.1479761223662; Mon, 21 Nov 2016 12:47:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Mon, 21 Nov 2016 12:46:43 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BE742CE@ESESSMB209.ericsson.se> From: Bernard Aboba Date: Mon, 21 Nov 2016 12:46:43 -0800 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a113dc58816c0c20541d5c25f Archived-At: Cc: ice@ietf.org, Roman Shpount , Christer Holmberg Subject: Re: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 20:47:06 -0000 --001a113dc58816c0c20541d5c25f Content-Type: text/plain; charset=UTF-8 Emil said: " Personally I am not aware of any active work on this in the group. Am I missing something? I am also opposed to trying to squeeze this into ICE's current version. Think we should think about a more serious redesign first." [BA] Since we are deprecating aggressive nomination, my understanding is that the term "Continuous nomination" refers to an implementation that utilizes "passive-aggressive" nomination, but does not nominate a candidate-pair. Such an implementation can send on any successful pair (but only on one pair at a time, absent support for multi-path RTP). If that understanding is correct (is it?) then "continuous nomination" is not a "thing", but rather the absence of something, namely nomination (e.g. "continuous non-nomination"?). So you may not be missing "something", so much as the "absence of something". It is somewhat awkward to talk about "active work" on an absence of something or squeezing an absence into something, which may explain why you may not have been aware of its (non)-existence. On Mon, Nov 21, 2016 at 9:58 AM, Emil Ivov wrote: > On 11/20/16 5:20 PM, Roman Shpount wrote: > >> I also wanted to bring up that this group is also actively working on >> continuous nomination. >> > > Personally I am not aware of any active work on this in the group. Am I > missing something? > > I am also opposed to trying to squeeze this into ICE's current version. > Think we should think about a more serious redesign first. > > Emil > > -- > https://jitsi.org > --001a113dc58816c0c20541d5c25f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Emil said:=C2=A0

"
Personally I am not aware of any active work on this= in the group. Am I missing something?

I am = also opposed to trying to squeeze this into ICE's current version. Thin= k we should think about a more serious redesign first."

[BA] Since we are deprecating aggressive nomination, my u= nderstanding is that the term "Continuous nomination" refers to a= n implementation that utilizes "passive-aggressive" nomination, b= ut does not nominate a candidate-pair.=C2=A0 Such an implementation can sen= d on any successful pair (but only on one pair at a time, absent support fo= r multi-path RTP).=C2=A0

If that understanding is = correct (is it?) then "continuous nomination" is not a "thin= g", but rather the absence of something, namely nomination (e.g. "= ;continuous non-nomination"?).=C2=A0

So you m= ay not be missing "something", so much as the "absence of so= mething".=C2=A0 It is somewhat awkward to talk about "active work= " on an absence of something or squeezing an absence into something, w= hich may explain why you may not have been aware of its (non)-existence.





On Mon, Nov 21, 2016 at= 9:58 AM, Emil Ivov <emcho@jitsi.org> wrote:
On 11/20/16 5:20 PM, Roman Shpount wrote:=
I also wanted to bring up that this group is also actively working on
continuous nomination.

 Personally I am not aware of any active work on this in the group. Am I mis= sing something?

I am also opposed to trying to squeeze this into ICE's current version.= Think we should think about a more serious redesign first.

Emil

--
https://= jitsi.org

--001a113dc58816c0c20541d5c25f-- From nobody Mon Nov 21 14:44:47 2016 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 95BC11295FC for ; Mon, 21 Nov 2016 14:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 v98VPPL8e5A8 for ; Mon, 21 Nov 2016 14:44:39 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 A02241297BC for ; Mon, 21 Nov 2016 14:44:38 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id b35so144148uaa.3 for ; Mon, 21 Nov 2016 14:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o+PRm0M2O/iS5H63QE5YRfpqzWL9EHjMgR7yPXwwf0s=; b=L3jNANnrRSOyvIkBb4YmNYkTzOpmuc7mKT02+NlvnOgsp0SWt35OaJyPVexMKKo7uu D6Oxl37JLxgsfjaYF+s8Wl8bl16w2Be0QktjCLTlweo7rH9RI0Gvn6cso2I2arD7R/21 nX5vlK09OEzIXaSE++Ld3bGQvYm67uPHz7rXY2M96CKTB1KJG2+uo5VAwdjvYO+dEP/Z SMnusoeUPYfY1MDSPo9SglNieSlZhXKv52BcuyEMQIn28AcjxxGsVvv4O1IU8UCKncY0 d7inVk+bIMu9NkF9RRz2WBfCQgOfJU2vuHBPV33sRP+Xl3rIBGI8gHzDHuw5Y9vF/zCB +3AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o+PRm0M2O/iS5H63QE5YRfpqzWL9EHjMgR7yPXwwf0s=; b=bo4vt4AUfQBfrihFCaZydmqwfRuwcypbfT+Xl3o/IT90eg786bre+fjP2zp+4h6l04 ADdH4w0kL3M88ulpSb2n5HSf/KeHKMeR8Mg7cdsNzGm1xkYBbVJpkBezQPDgxScDRylU tmOrBVAgdirIpDcDTwAFwSgOPAwDtV5vFrhBMiuEyV7jzyoi68XSprV8iOLNFHiPR9MB NlJVYHPiCmX4MUbA2q72MFV9IT6Dav5YH7GEXuTEQxMsOYaicB/gb46u4L0T5LmuhO5x iBvKJ3mVQK+Yv4uoCNt73VihreRrp3iPjQ14JKccfUwgqlnXlvaEwd0/qfapP+XrkkS0 7AFA== X-Gm-Message-State: AKaTC03L0AJd+GYeGJlyUeNH16O6YLzqqfr9Ke1G4BFt78Fqm6pqgZ0ZnMZR5kmhrenFckImPmIzadpYwPgn0w== X-Received: by 10.176.84.207 with SMTP id q15mr7284812uaa.177.1479768277414; Mon, 21 Nov 2016 14:44:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Mon, 21 Nov 2016 14:44:17 -0800 (PST) In-Reply-To: <1BDE19E2-7E3F-41CF-BBDF-BFC34953130E@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B4BE742CE@ESESSMB209.ericsson.se> <1BDE19E2-7E3F-41CF-BBDF-BFC34953130E@ericsson.com> From: Bernard Aboba Date: Mon, 21 Nov 2016 14:44:17 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c1b03b686791f0541d7665b Archived-At: Cc: Emil Ivov , Roman Shpount , "ice@ietf.org" Subject: Re: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 22:44:44 -0000 --94eb2c1b03b686791f0541d7665b Content-Type: text/plain; charset=UTF-8 Christer said: "Doesn't RFC 5245bis already implement "continuous nomination" by making nominating "optional" (as you can send media before nomination)?" [BA] While RFC 52452bis makes it possible send media before nomination, I don't think the current text enables an implementation to dispense with nomination entirely. For example, the text requires an implementation to be ready to receive as soon as it sends candidate information. That implies that resources cannot be freed until a candidate-pair has been nominated. Since keeping resources alive indefinitely is problematic (e.g. from an energy consumption standpoint), the implementations I am familiar with utilize mechanisms to identify needed versus unneeded pairs. For example, a candidate removal extension can be used to identify pairs that can be discarded (or pairs not to be checked), or consent mechanisms can be used to identify pairs to be kept. However, without these extensions or clarifications, I don't think we can really say that RFC 5245bis enables nomination to be made optional. BTW, since we are really talking about making nomination optional, "continuous nomination" does not strike me as a good term to describe what we're talking about. On Mon, Nov 21, 2016 at 10:33 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Doesn't 5245bis already implement "continuous nomination", by making > nominating "optional" (as you can send media before nomination)? > > Regards, > > Christer > > Sent from my iPhone > > > On 21 Nov 2016, at 19.58, Emil Ivov wrote: > > > >> On 11/20/16 5:20 PM, Roman Shpount wrote: > >> I also wanted to bring up that this group is also actively working on > >> continuous nomination. > > > > Personally I am not aware of any active work on this in the group. Am I > missing something? > > > > I am also opposed to trying to squeeze this into ICE's current version. > Think we should think about a more serious redesign first. > > > > Emil > > > > -- > > https://jitsi.org > --94eb2c1b03b686791f0541d7665b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christer said:=C2=A0

"Doesn't = RFC 5245bis already implement "continuous nomination" by making n= ominating "optional" (as you can send media before nomination)?&q= uot;

[BA] =C2=A0While RFC 52452bis makes it possib= le send media before nomination, I don't think the current text enables= an implementation to dispense with nomination entirely.=C2=A0
For example, the text requires an implementation to be ready t= o receive as soon as it sends candidate information. That implies that reso= urces cannot be freed until a candidate-pair has been nominated.=C2=A0

Since keeping resources alive indefinitely is problema= tic (e.g. from an energy consumption standpoint), the implementations I am = familiar with utilize mechanisms to identify needed versus unneeded pairs.= =C2=A0 For example, a candidate removal extension can be used to identify p= airs that can be discarded (or pairs not to be checked), or consent mechani= sms can be used to identify pairs to be kept.=C2=A0

However, without these extensions or clarifications, I don't think we= can really say that RFC 5245bis enables nomination to be made optional.=C2= =A0

BTW, since we are really talking about making = nomination optional, "continuous nomination" does not strike me a= s a good term to describe what we're talking about. =C2=A0




On Mon, Nov 21, 2016 at 10:33 AM,= Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Doesn't 5245bis already i= mplement "continuous nomination", by making nominating "opti= onal" (as you can send media before nomination)?

Regards,

Christer

Sent from my iPhone

> On 21 Nov 2016, at 19.58, Emil Ivov <emcho@jitsi.org> wrote:
>
>> On 11/20/16 5:20 PM, Roman Shpount wrote:
>> I also wanted to bring up that this group is also actively working= on
>> continuous nomination.
>
> Personally I am not aware of any active work on this in the group. Am = I missing something?
>
> I am also opposed to trying to squeeze this into ICE's current ver= sion. Think we should think about a more serious redesign first.
>
> Emil
>
> --
> htt= ps://jitsi.org

--94eb2c1b03b686791f0541d7665b-- From nobody Mon Nov 21 21:48:31 2016 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 C30211294B5 for ; Mon, 21 Nov 2016 21:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 307DkMLoCFE1 for ; Mon, 21 Nov 2016 21:48:25 -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 1753C129439 for ; Mon, 21 Nov 2016 21:48:24 -0800 (PST) X-AuditID: c1b4fb30-96c1b98000001942-05-5833dc26fb93 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id AF.29.06466.62CD3385; Tue, 22 Nov 2016 06:48:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Tue, 22 Nov 2016 06:48:21 +0100 From: Christer Holmberg To: Bernard Aboba Thread-Topic: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? Thread-Index: AdJCRurmAgGp6u03Tl6w25hg1S1vSQAhaaqAAEON55AAFLY4gAAVTgJQ Date: Tue, 22 Nov 2016 05:48:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE8E996@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BE742CE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BE82520@ESESSMB209.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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE8E996ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7q676HeMIg0tT2Cw27PvPbPHtQq0D k8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfGt+RJbwa9bjBUTNv5jb2CccZWxi5GTQ0LA RKL7+zcwW0hgHaPExYlJXYxcQPZiRonHVxaydjFycLAJWEh0/9MGqRER0Jbo+7aPCSTMLKAo 8XKvGki5sMBMRonvyy8zgjgiArMYJbpefGEEKRIRcJNoaiwA6WURUJXY17KIBcTmFfCV2Lbg MyPErvlMEi8PnmAGSXAKBEosOrGOCcRmFBCT+H5qDZjNLCAucevJfCaIowUkluw5zwxhi0q8 fPyPFcJWklh0+zNUfb7EwcY9TBDLBCVOznzCMoFRZBaSUbOQlM1CUjYL7DdNifW79CFKFCWm dD9kh7A1JFrnzGVHFl/AyL6KUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzCuDm75bbCD8eVz x0OMAhyMSjy8Bi7GEUKsiWXFlbmHGCU4mJVEeD/fBArxpiRWVqUW5ccXleakFh9ilOZgURLn NVt5P1xIID2xJDU7NbUgtQgmy8TBKdXAGGJr/8LrfAarsJHICxFXTvaXS0VOT92W6h2vHC03 aTnHdI9W8dNL86yOKV1inhQl8VKmQk8jOsus5eaXbewbHiq+KlNbtkJ9iYnpYvfXZVa/rv41 nm/s4psWyrj/3/Scq3xyOT9c569Zo1RtvPGm1cQdJ2/PMOOcevdu4Klj1/q971dNjPL3U2Ip zkg01GIuKk4EAKtADaSnAgAA Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 05:48:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE8E996ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVybmFyZCwNCg0KVG8gY2xhcmlmeTogaW4gYWxsIGNhc2VzIGJlbG93LCBJIGFncmVlIHBl ZXJzIGNhbiBvbmx5IHNlbmQgbWVkaWEgb24gYSBzaW5nbGUgcGFpciBhdCBhIHRpbWUuIE15IGlz c3VlIHdhcyBob3cgdGhhdCBzaW5nbGUgcGFpciBpcyBjaG9zZW46IFJGQyBhbGxvd3MgcGVlcnMg dG8gc2VuZC1tZWRpYS1vbi1oaWdoZXN0LXByaW9yaXR5LXZhbGlkLXBhaXIgd2hpbGUgSUNFYmlz IGFsbG93cyBwZWVycyB0byBzZW5kLW1lZGlhLW9uLWFueS12YWxpZC1wYWlyLg0KDQrigKYNCg0K PltCQV0gV2l0aG91dCBtdWx0aS1wYXRoIFJUUCwgcGVlcnMgbWF5IG9ubHkgc2VuZCBtZWRpYSBv biBhIHNpbmdsZSBwYWlyIGF0IGEgdGltZS4gIEhvd2V2ZXIsIHRoZSByZWNlaXZpbmcgc2lkZSBt YXkgc2VlDQo+aW50ZXJtaW5nbGluZyBvZiBtZWRpYSBvbiBtdWx0aXBsZSBwYWlycywgZHVlIHRv IHJlb3JkZXJpbmcgb3IgUlRYLCBzbyBhIHJlY2VpdmVyIG5lZWRzIHRvIGJlIHByZXBhcmVkIHRv IGRlYWwgd2l0aCB0aGF0Lg0KDQpDb3JyZWN0LiBQcm9iYWJseSBhbm90aGVyIHRoaW5nIHdvcnRo IHRvIGV4cGxpY2l0bHkgcG9pbnQgb3V0IGluIHRoZSBzcGVjLg0KDQo+Tm90ZSB0aGF0IElDRWJp cyBTZWN0aW9uIDQuMyByZXF1aXJlcyBhbiBhZ2VudCB0byBiZSBwcmVwYXJlZCB0byByZWNlaXZl IG1lZGlhIG9uY2UgY2FuZGlkYXRlIGluZm9ybWF0aW9uIGlzIHNlbnQgKGV2ZW4gYmVmb3JlIHNl bmRpbmcgYSByZXNwb25zZSB0byBhIGNoZWNrISk6DQo+DQo+IiBPbmNlIGFuIGFnZW50IGhhcyBz ZW50IGl0cyBjYW5kaWRhdGUgaW5mb3JtYXRpb24sIHRoYXQgYWdlbnQgTVVTVCBiZQ0KPiAgIHBy ZXBhcmVkIHRvIHJlY2VpdmUgYm90aCBTVFVOIGFuZCBtZWRpYSBwYWNrZXRzIG9uIGVhY2ggY2Fu ZGlkYXRlLiINCj4NCj5TbyBpbiBwcmFjdGljZSwgICJoaWdoZXN0LXByaW9yaXR5IiBpc24ndCBv ZiBtdWNoIGhlbHAgdG8gdGhlIHJlY2VpdmVyIChpdCBjYW4ndCB1c2UgdGhhdCB0byBzdG9wIGxp c3RlbmluZyBvbiBvbmUgb3IgbW9yZSBjYW5kaWRhdGVzKS4NCg0KV2UgY291bGQgYWx3YXlzIG1h a2UgdGhpbmdzIG1vcmUgc3RyaWN0IGluIElDRWJpcywgYW5kIHNheSB0aGF0IG1lZGlhIGNhbiBv bmx5IGJlIHNlbnQgb24gdmFsaWQgcGFpcnMuIEJlY2F1c2UsIGhvdyBkb2VzIHRoZSBtZWRpYSBz ZW5kZXIgZXZlbiBrbm93IHRoYXQgc3VjaCBtZWRpYSB3b3VsZCBldmVuIHJlYWNoIHRoZSBwZWVy Pw0KUmVnYXJkcywNCkNocmlzdGVyDQoNCg0KT24gTW9uLCBOb3YgMjEsIDIwMTYgYXQgMTo1NSBB TSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBCZXJuYXJkLA0K DQpZb3UgYXJlIGNvcnJlY3Qg4oCTIHRoZSBwcm9ibGVtIGFscmVhZHkgZXhpc3RlZCBpbiBSRkMg NTI0NS4NCg0KVGhlcmUgaXMgYSBkaWZmZXJlbmNlLCB0aG91Z2g6DQoNCldoZW4gdXNpbmcgYWdn cmVzc2l2ZSBub21pbmF0aW9uIChSRkMgNTI0NSkgdGhlIGVuZHBvaW50cyBjb3VsZCBub3Qgc3dp dGNoIGJldHdlZW4gdmFsaWQgY2FuZGlkYXRlIHBhaXJzIGFzIHRoZXkgd2lzaC4gQXQgYW55IGdp dmVuIHRpbWUsIG9ubHkgdGhlIG5vbWluYXRlZCBwYWlyIHdpdGggdGhlIGhpZ2hlc3QtcHJpb3Jp dHkgY291bGQgYmUgdXNlZCwgbWVhbmluZyB0aGF0IHRoZXJlIHdhcyBvbmx5IG9uZSBzZWxlY3Rl ZCBwYWlyIGF0IGFueSBnaXZlbiB0aW1lLg0KDQpJbiA1MjQ1YmlzLCBtZWRpYSBjYW4gYmUgc2Vu dCBvbiBhbnkgcGFpciwgYW5kIHRoZSBzd2l0Y2hpbmcgY2FuIGJlIGRvbmUgd2hlbmV2ZXIsIGhv d2V2ZXIsIGFuZCB0aGVyZSBpcyBubyBuZWVkIHRvIG5vbWluYXRlIHRvIGJlZ2luIHdpdGgsIHBy aW9yIHRvIHNlbmRpbmcgbWVkaWEuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTog QmVybmFyZCBBYm9iYSBbbWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJu YXJkLmFib2JhQGdtYWlsLmNvbT5dDQpTZW50OiAyMCBOb3ZlbWJlciAyMDE2IDA0OjIzDQpUbzog Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NCkNjOiBpY2VAaWV0Zi5vcmc8bWFpbHRv OmljZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWNlXSBEbyB3ZSB3YW50IHRvIG1hbmRhdGUg YWxsIHByb3RvY29scyBzdXBwb3J0aW5nIElDRSBhbmQgbXVsdGlwbGUgdHJhbnNwb3J0cyB0byBz dXBwb3J0IHRyYW5zcG9ydCBzd2l0Y2ggb24tdGhlLWZseSBiZWZvcmUgbm9taW5hdGlvbj8NCg0K DQpDaHJpc3RlciAtLQ0KDQpXaXRoIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiwgYSBUQ1AgY2FuZGlk YXRlLXBhaXIgY291bGQgYmUgbm9taW5hdGVkLCBhbmQgdGhlbiBhIFVEUCBjYW5kaWRhdGUtcGFp ciBjb3VsZCBiZSBub21pbmF0ZWQsIGFuZCBkYXRhIGNvdWxkIGJlIHNlbnQgb24gYSBzdWNjZXNz ZnVsIHBhaXIuICBTbyAic3dpdGNoaW5nIiBjYW4gYWxzbyBvY2N1ci4gIEdpdmVuIHRoYXQgdGhl IGNvbnRyb2xsZWQgcGVlciBuZWVkcyB0byBiZSBhYmxlIHRvIHJlY2VpdmUgb24gYW55IHN1Y2Nl c3NmdWwgcGFpciwgaXQgaGFzIHRvIGJlIHByZXBhcmVkIGZvciByZWNlaXZpbmcgYm90aCBVRFAg YW5kIFRDUCBwYWNrZXRzIGF0IHRoZSBzYW1lIHRpbWUuDQoNClNvIGhvdyBpcyAicGFzc2l2ZS1h Z2dyZXNzaXZlIiBub21pbmF0aW9uIG1vcmUgb25lcm91cyB0aGFuIGFnZ3Jlc3NpdmUgaW4gdGhp cyByZXNwZWN0Pw0KDQpPbiBOb3YgMTksIDIwMTYgMToyNyBBTSwgIkNocmlzdGVyIEhvbG1iZXJn IiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQpPbmUgcG90ZW50aWFsIGlzc3VlIHRoYXQg Y2FtZSB0byBteSBtaW5kIHdoaWxlIHJlYWRpbmcgdGhlIFNEUCBtLSBsaW5lIHRocmVhZC4NCg0K UHJldmlvdXNseSwgYmVmb3JlIHJlbW92YWwgb2YgYWdncmVzc2l2ZSBub21pbmF0aW9uLCB3aGls ZSBhbmQgZW5kcG9pbnQgbWlnaHQgc3VwcG9ydCBib3RoIFVEUCBhbmQgVENQIGZvciBhIHByb3Rv Y29sLCBpdCBkaWRu4oCZdCBoYXZlIHRvIGJlIGFibGUgdG8gc2ltdWx0YW5lb3VzbHkgdXNlIHRo ZSBwcm90b2NvbCB3aXRoIGJvdGggVURQIGFuZCBUQ1AsIGFuZCBzd2l0Y2hpbmcgYmV0d2Vlbi4g QmVjYXVzZSwgdW50aWwgbm9taW5hdGlvbiB3YXMgZG9uZSwgbm8gcHJvdG9jb2wgZGF0YSB3YXMg c2VudC4gQW5kLCBvbmNlIG5vbWluYXRpb24gaGFkIGJlZW4gZG9uZSwgZW5kcG9pbnRzIHVzZWQg dGhlIHByb3RvY29sIHdpdGggdGhlIHNlbGVjdGVkIHRyYW5zcG9ydC4NCg0KTm93LCB3aXRoIHRo ZSBhbGxvd2VkLXRvLXNlbmQtbWVkaWEtYmVmb3JlLW5vbWluYXRpb24gcnVsZXMsIHByb3RvY29s cyBiYXNpY2FsbHkgaGF2ZSB0byBzdXBwb3J0IHN3aXRjaCBvZiB0cmFuc3BvcnQgKGZyb20gVURQ IHRvIFRDUCwgYW5kIHZpY2UgdmVyc2EpLCB1bnRpbCB0aGUgbm9taW5hdGlvbiB0YWtlcyBwbGFj ZS4NCg0KTm93LCBldmVuIHBlb3BsZSBhbHdheXMgc2F5IHRoYXQgYSBnb29kIGRlc2lnbmVkIHBy b3RvY29sIHNob3VsZCBiZSB0cmFuc3BvcnQtaW5kZXBlbmRlbnQsIGlzbuKAmXQgKm1hbmRhdGlu ZyogdHJhbnNwb3J0IHN3aXRjaGluZyBvbi10aGUtZmx5IChiZWZvcmUgbm9taW5hdGlvbiB0YWtl cyBwbGFjZSkgYnkgYWxsIHByb3RvY29scyBzdXBwb3J0aW5nIElDRSBhbmQgbXVsdGlwbGUgdHJh bnNwb3J0cyBhIGJhZCB0aGluZyB0byBkbz8NCg0KUGVyaGFwcyB0aGUgSUNFIGNvbnNpZGVyYXRp b25zIG9mIGVhY2ggcHJvdG9jb2wgKFJUUCwgQkZDUCBldGMpIHNob3VsZCBpbmRpY2F0ZSB3aGV0 aGVyIHRyYW5zcG9ydCBzd2l0Y2hpbmcgaXMgc3VwcG9ydGVkLCBhbmQgd2hldGhlciB0aGVyZSBh cmUgcHJvdG9jb2wgc3BlY2lmaWMgcHJvY2VkdXJlcyBhc3NvY2lhdGVkIHdpdGggdGhhdC4gSSBn dWVzcyBhIHByb3RvY29sIGNvdWxkIGFsc28gc3BlY2lmeSB0aGF0IGRhdGEgc2hvdWxkbuKAmXQg YmUgc2VudCBpbiB0aGUgZmlyc3QgcGxhY2UgYmVmb3JlIG5vbWluYXRpb24gaGFzIGJlZW4gZG9u ZSwgaWYgdGhlcmUgYXJlIGdvb2QgcmVhc29ucyBmb3IgdGhhdC4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkljZSBtYWlsaW5nIGxpc3QNCkljZUBpZXRmLm9yZzxtYWlsdG86SWNlQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4BE8E996ESESSMB209erics_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBCZXJuYXJkLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VG8gY2xhcmlmeTogaW4gYWxs IGNhc2VzIGJlbG93LCBJIGFncmVlIHBlZXJzIGNhbiBvbmx5IHNlbmQgbWVkaWEgb24gYSBzaW5n bGUgcGFpciBhdCBhIHRpbWUuIE15IGlzc3VlIHdhcyBob3cgdGhhdCBzaW5nbGUgcGFpciBpcw0K IGNob3NlbjogUkZDIGFsbG93cyBwZWVycyB0byBzZW5kLW1lZGlhLW9uLWhpZ2hlc3QtcHJpb3Jp dHktdmFsaWQtcGFpciB3aGlsZSBJQ0ViaXMgYWxsb3dzIHBlZXJzIHRvIHNlbmQtbWVkaWEtb24t YW55LXZhbGlkLXBhaXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj7i gKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltC QV0gV2l0aG91dCBtdWx0aS1wYXRoIFJUUCwgcGVlcnMgbWF5IG9ubHkgc2VuZCBtZWRpYSBvbiBh IHNpbmdsZSBwYWlyIGF0IGEgdGltZS4mbmJzcDsgSG93ZXZlciwgdGhlIHJlY2VpdmluZyBzaWRl IG1heSBzZWU8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5pbnRlcm1pbmdsaW5nIG9mIG1lZGlhIG9uIG11bHRpcGxlIHBhaXJzLCBkdWUgdG8gcmVv cmRlcmluZyBvciBSVFgsIHNvIGEgcmVjZWl2ZXIgbmVlZHMNCiB0byBiZSBwcmVwYXJlZCB0byBk ZWFsIHdpdGggdGhhdC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q29y cmVjdC4gUHJvYmFibHkgYW5vdGhlciB0aGluZyB3b3J0aCB0byBleHBsaWNpdGx5IHBvaW50IG91 dCBpbiB0aGUgc3BlYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5Ob3RlIHRoYXQgSUNFYmlzIFNlY3Rpb24gNC4zIHJlcXVpcmVzIGFuIGFnZW50 IHRvIGJlIHByZXBhcmVkIHRvIHJlY2VpdmUgbWVkaWEgb25jZSBjYW5kaWRhdGUgaW5mb3JtYXRp b24gaXMgc2VudCAoZXZlbiBiZWZvcmUgc2VuZGluZyBhIHJlc3BvbnNlDQogdG8gYSBjaGVjayEp Ojwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+JnF1b3Q7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjpibGFjayI+IE9uY2UgYW4gYWdlbnQgaGFzIHNlbnQgaXRzIGNhbmRpZGF0ZSBpbmZv cm1hdGlvbiwgdGhhdCBhZ2VudCBNVVNUIGJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZndDs8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtwcmVwYXJlZCB0 byByZWNlaXZlIGJvdGggU1RVTiBhbmQgbWVkaWEgcGFja2V0cyBvbiBlYWNoIGNhbmRpZGF0ZS48 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mcXVvdDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U28gaW4g cHJhY3RpY2UsICZuYnNwOyZxdW90O2hpZ2hlc3QtcHJpb3JpdHkmcXVvdDsgaXNuJ3Qgb2YgbXVj aCBoZWxwIHRvIHRoZSByZWNlaXZlciAoaXQgY2FuJ3QgdXNlIHRoYXQgdG8gc3RvcCBsaXN0ZW5p bmcgb24gb25lIG9yIG1vcmUgY2FuZGlkYXRlcykuPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XZSBj b3VsZCBhbHdheXMgbWFrZSB0aGluZ3MgbW9yZSBzdHJpY3QgaW4gSUNFYmlzLCBhbmQgc2F5IHRo YXQgbWVkaWEgY2FuIG9ubHkgYmUgc2VudCBvbiB2YWxpZCBwYWlycy4gQmVjYXVzZSwgaG93IGRv ZXMgdGhlIG1lZGlhIHNlbmRlciBldmVuIGtub3cgdGhhdCBzdWNoIG1lZGlhIHdvdWxkIGV2ZW4N CiByZWFjaCB0aGUgcGVlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaHJpc3Rlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gTW9uLCBOb3YgMjEsIDIwMTYgYXQgMTo1NSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcg Jmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdl dD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEJlcm5hcmQsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WW91IGFyZSBjb3JyZWN0 IOKAkyB0aGUgcHJvYmxlbSBhbHJlYWR5IGV4aXN0ZWQgaW4gUkZDIDUyNDUuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlcmUgaXMgYSBkaWZmZXJlbmNl LCB0aG91Z2g6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ V2hlbiB1c2luZyBhZ2dyZXNzaXZlIG5vbWluYXRpb24gKFJGQyA1MjQ1KSB0aGUgZW5kcG9pbnRz IGNvdWxkIG5vdCBzd2l0Y2ggYmV0d2VlbiB2YWxpZCBjYW5kaWRhdGUNCiBwYWlycyBhcyB0aGV5 IHdpc2guIEF0IGFueSBnaXZlbiB0aW1lLCBvbmx5IHRoZSBub21pbmF0ZWQgcGFpciB3aXRoIHRo ZSBoaWdoZXN0LXByaW9yaXR5IGNvdWxkIGJlIHVzZWQsIG1lYW5pbmcgdGhhdCB0aGVyZSB3YXMg b25seSBvbmUgc2VsZWN0ZWQgcGFpciBhdCBhbnkgZ2l2ZW4gdGltZS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiA1MjQ1YmlzLCBtZWRpYSBjYW4gYmUg c2VudCBvbiBhbnkgcGFpciwgYW5kIHRoZSBzd2l0Y2hpbmcgY2FuIGJlIGRvbmUgd2hlbmV2ZXIs IGhvd2V2ZXIsIGFuZCB0aGVyZQ0KIGlzIG5vIG5lZWQgdG8gbm9taW5hdGUgdG8gYmVnaW4gd2l0 aCwgcHJpb3IgdG8gc2VuZGluZyBtZWRpYS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fLTI3 NTA0MTE1Mjg0NTQxMDk1NTVfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQmVybmFyZA0KIEFib2JhIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmVy bmFyZC5hYm9iYUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDIwIE5vdmVtYmVy IDIwMTYgMDQ6MjM8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVm PSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxh IGhyZWY9Im1haWx0bzppY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pY2VAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWNlXSBEbyB3ZSB3YW50IHRvIG1hbmRhdGUg YWxsIHByb3RvY29scyBzdXBwb3J0aW5nIElDRSBhbmQgbXVsdGlwbGUgdHJhbnNwb3J0cyB0byBz dXBwb3J0IHRyYW5zcG9ydCBzd2l0Y2ggb24tdGhlLWZseSBiZWZvcmUgbm9taW5hdGlvbj88L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5DaHJpc3RlciAtLTxvOnA+PC9vOnA+PC9wPg0KPHA+ V2l0aCBhZ2dyZXNzaXZlIG5vbWluYXRpb24sIGEgVENQIGNhbmRpZGF0ZS1wYWlyIGNvdWxkIGJl IG5vbWluYXRlZCwgYW5kIHRoZW4gYSBVRFAgY2FuZGlkYXRlLXBhaXIgY291bGQgYmUgbm9taW5h dGVkLCBhbmQgZGF0YSBjb3VsZCBiZSBzZW50IG9uIGEgc3VjY2Vzc2Z1bCBwYWlyLiZuYnNwOyBT byAmcXVvdDtzd2l0Y2hpbmcmcXVvdDsgY2FuIGFsc28gb2NjdXIuJm5ic3A7IEdpdmVuIHRoYXQg dGhlIGNvbnRyb2xsZWQgcGVlciBuZWVkcyB0byBiZSBhYmxlIHRvIHJlY2VpdmUNCiBvbiBhbnkg c3VjY2Vzc2Z1bCBwYWlyLCBpdCBoYXMgdG8gYmUgcHJlcGFyZWQgZm9yIHJlY2VpdmluZyBib3Ro IFVEUCBhbmQgVENQIHBhY2tldHMgYXQgdGhlIHNhbWUgdGltZS4NCjxvOnA+PC9vOnA+PC9wPg0K PHA+U28gaG93IGlzICZxdW90O3Bhc3NpdmUtYWdncmVzc2l2ZSZxdW90OyBub21pbmF0aW9uIG1v cmUgb25lcm91cyB0aGFuIGFnZ3Jlc3NpdmUgaW4gdGhpcyByZXNwZWN0PzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBOb3YgMTksIDIwMTYgMToyNyBBTSwgJnF1 b3Q7Q2hyaXN0ZXIgSG9sbWJlcmcmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T25lIHBvdGVu dGlhbCBpc3N1ZSB0aGF0IGNhbWUgdG8gbXkgbWluZCB3aGlsZSByZWFkaW5nIHRoZSBTRFAgbS0g bGluZSB0aHJlYWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QcmV2aW91c2x5LCBiZWZv cmUgcmVtb3ZhbCBvZiBhZ2dyZXNzaXZlIG5vbWluYXRpb24sIHdoaWxlIGFuZCBlbmRwb2ludCBt aWdodCBzdXBwb3J0IGJvdGggVURQIGFuZCBUQ1AgZm9yIGEgcHJvdG9jb2wsIGl0IGRpZG7igJl0 IGhhdmUgdG8gYmUgYWJsZSB0byBzaW11bHRhbmVvdXNseSB1c2UgdGhlIHByb3RvY29sDQogd2l0 aCBib3RoIFVEUCBhbmQgVENQLCBhbmQgc3dpdGNoaW5nIGJldHdlZW4uIEJlY2F1c2UsIHVudGls IG5vbWluYXRpb24gd2FzIGRvbmUsIG5vIHByb3RvY29sIGRhdGEgd2FzIHNlbnQuIEFuZCwgb25j ZSBub21pbmF0aW9uIGhhZCBiZWVuIGRvbmUsIGVuZHBvaW50cyB1c2VkIHRoZSBwcm90b2NvbCB3 aXRoIHRoZSBzZWxlY3RlZCB0cmFuc3BvcnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5O b3csIHdpdGggdGhlIGFsbG93ZWQtdG8tc2VuZC1tZWRpYS1iZWZvcmUtbm9taW5hdGlvbiBydWxl cywgcHJvdG9jb2xzIGJhc2ljYWxseSBoYXZlIHRvIHN1cHBvcnQgc3dpdGNoIG9mIHRyYW5zcG9y dCAoZnJvbSBVRFAgdG8gVENQLCBhbmQgdmljZSB2ZXJzYSksIHVudGlsIHRoZSBub21pbmF0aW9u IHRha2VzDQogcGxhY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ob3csIGV2ZW4gcGVv cGxlIGFsd2F5cyBzYXkgdGhhdCBhIGdvb2QgZGVzaWduZWQgcHJvdG9jb2wgc2hvdWxkIGJlIHRy YW5zcG9ydC1pbmRlcGVuZGVudCwgaXNu4oCZdCAqPGI+bWFuZGF0aW5nPC9iPiogdHJhbnNwb3J0 IHN3aXRjaGluZyBvbi10aGUtZmx5IChiZWZvcmUgbm9taW5hdGlvbiB0YWtlcyBwbGFjZSkNCiBi eSBhbGwgcHJvdG9jb2xzIHN1cHBvcnRpbmcgSUNFIGFuZCBtdWx0aXBsZSB0cmFuc3BvcnRzIGEg YmFkIHRoaW5nIHRvIGRvPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UGVyaGFwcyB0aGUg SUNFIGNvbnNpZGVyYXRpb25zIG9mIGVhY2ggcHJvdG9jb2wgKFJUUCwgQkZDUCBldGMpIHNob3Vs ZCBpbmRpY2F0ZSB3aGV0aGVyIHRyYW5zcG9ydCBzd2l0Y2hpbmcgaXMgc3VwcG9ydGVkLCBhbmQg d2hldGhlciB0aGVyZSBhcmUgcHJvdG9jb2wgc3BlY2lmaWMgcHJvY2VkdXJlcyBhc3NvY2lhdGVk DQogd2l0aCB0aGF0LiBJIGd1ZXNzIGEgcHJvdG9jb2wgY291bGQgYWxzbyBzcGVjaWZ5IHRoYXQg ZGF0YSBzaG91bGRu4oCZdCBiZSBzZW50IGluIHRoZSBmaXJzdCBwbGFjZSBiZWZvcmUgbm9taW5h dGlvbiBoYXMgYmVlbiBkb25lLCBpZiB0aGVyZSBhcmUgZ29vZCByZWFzb25zIGZvciB0aGF0Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkNocmlzdGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCkljZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWNlQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+SWNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2U8L2E+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4BE8E996ESESSMB209erics_-- From nobody Mon Nov 21 21:57:00 2016 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 6DFF3129512 for ; Mon, 21 Nov 2016 21:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VL5k30h47-su for ; Mon, 21 Nov 2016 21:56:56 -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 D06671294B5 for ; Mon, 21 Nov 2016 21:56:55 -0800 (PST) X-AuditID: c1b4fb25-ec9d598000007ee2-c6-5833de25547d Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id A4.22.32482.52ED3385; Tue, 22 Nov 2016 06:56:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0319.002; Tue, 22 Nov 2016 06:56:34 +0100 From: Christer Holmberg To: Bernard Aboba Thread-Topic: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? Thread-Index: AdJCRurmAgGp6u03Tl6w25hg1S1vSQAhaaqAACvx7gAAJwrOAAADTaU6AAarX4AAEPL5UA== Date: Tue, 22 Nov 2016 05:56:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE8E9DA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BE742CE@ESESSMB209.ericsson.se> <1BDE19E2-7E3F-41CF-BBDF-BFC34953130E@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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BE8E9DAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7sa7aPeMIg8WruSw27PvPbLFm5wQW i28Xai1mXJjK7MDisXPWXXaPJUt+Mnn8fxPocWtKQQBLFJdNSmpOZllqkb5dAlfGmhlXmQsO lFS0vTvM2sC4prCLkZNDQsBE4tjhNyxdjFwcQgLrGCUmPH7FBOEsZpR4/OEKUIaDg03AQqL7 nzZIg4iAtkTft31MIDazQLLE7o3bmUHqhQVmMkp8X36ZEcQREZjFKNH14gsjREeYxOpfe8Bs FgFViXX/F4J18wr4SjxacQZqdTezxMbjk1lBtnEKBErcOV8CUsMoICbx/dQaqG3iEreezGeC OFtAYsme88wQtqjEy8f/WCFsJYlFtz9D1edLnF+7E2qXoMTJmU9YJjCKzEIyahaSsllIymYB XcEsoCmxfpc+RImixJTuh+wQtoZE65y57MjiCxjZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWW bGIExt7BLb9VdzBefuN4iFGAg1GJh9fAxThCiDWxrLgy9xCjBAezkgjv55tAId6UxMqq1KL8 +KLSnNTiQ4zSHCxK4rxmK++HCwmkJ5akZqemFqQWwWSZODilGhh1laPL2afzzAmqjfnH6sNQ UsAcNsP5hSAbX6267dpJCyLLny/RWrFKLD7z9gqZ/nqH/ukpJd5vfNb+eySg4Hgrc66fzA3z R/qmqgfLxNP5N7fId/Jc4lSZYP3mnz9L0CGPU5mTvFMKL33U3c3H2alxfL+QymW5hRpOMyuX 3tW8GztBU8r3uBJLcUaioRZzUXEiAJwKlH65AgAA Archived-At: Cc: Emil Ivov , Roman Shpount , "ice@ietf.org" Subject: Re: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination? X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 05:56:58 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BE8E9DAESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj4+IkRvZXNuJ3QgUkZDIDUyNDViaXMgYWxyZWFkeSBpbXBsZW1lbnQgImNvbnRpbnVv dXMgbm9taW5hdGlvbiIgYnkgbWFraW5nIG5vbWluYXRpbmcgIm9wdGlvbmFsIiAoYXMgeW91IGNh biBzZW5kIG1lZGlhIGJlZm9yZSBub21pbmF0aW9uKT8iDQo+DQo+W0JBXSAgV2hpbGUgUkZDIDUy NDUyYmlzIG1ha2VzIGl0IHBvc3NpYmxlIHNlbmQgbWVkaWEgYmVmb3JlIG5vbWluYXRpb24sIEkg ZG9uJ3QgdGhpbmsgdGhlIGN1cnJlbnQgdGV4dCBlbmFibGVzIGFuIGltcGxlbWVudGF0aW9uIHRv IGRpc3BlbnNlIHdpdGggPm5vbWluYXRpb24gZW50aXJlbHkuDQo+DQo+Rm9yIGV4YW1wbGUsIHRo ZSB0ZXh0IHJlcXVpcmVzIGFuIGltcGxlbWVudGF0aW9uIHRvIGJlIHJlYWR5IHRvIHJlY2VpdmUg YXMgc29vbiBhcyBpdCBzZW5kcyBjYW5kaWRhdGUgaW5mb3JtYXRpb24uIFRoYXQgaW1wbGllcyB0 aGF0IHJlc291cmNlcyBjYW5ub3QgYmUgPmZyZWVkIHVudGlsIGEgY2FuZGlkYXRlLXBhaXIgaGFz IGJlZW4gbm9taW5hdGVkLg0KPg0KPlNpbmNlIGtlZXBpbmcgcmVzb3VyY2VzIGFsaXZlIGluZGVm aW5pdGVseSBpcyBwcm9ibGVtYXRpYyAoZS5nLiBmcm9tIGFuIGVuZXJneSBjb25zdW1wdGlvbiBz dGFuZHBvaW50KSwgdGhlIGltcGxlbWVudGF0aW9ucyBJIGFtIGZhbWlsaWFyIHdpdGggdXRpbGl6 ZSA+bWVjaGFuaXNtcyB0byBpZGVudGlmeSBuZWVkZWQgdmVyc3VzIHVubmVlZGVkIHBhaXJzLiAg Rm9yIGV4YW1wbGUsIGEgY2FuZGlkYXRlIHJlbW92YWwgZXh0ZW5zaW9uIGNhbiBiZSB1c2VkIHRv IGlkZW50aWZ5IHBhaXJzIHRoYXQgY2FuIGJlIGRpc2NhcmRlZCAob3IgPnBhaXJzIG5vdCB0byBi ZSBjaGVja2VkKSwgb3IgY29uc2VudCBtZWNoYW5pc21zIGNhbiBiZSB1c2VkIHRvIGlkZW50aWZ5 IHBhaXJzIHRvIGJlIGtlcHQuDQoNCkkgZG8gYWdyZWUgdGhhdCB0aGVyZSBhcmUgZ29vZCByZWFz b25zIHdoeSB5b3Ugc2hvdWxkIG5vbWluYXRlLCBhbmQgbWF5YmUgd2UgbmVlZCB0byBhZGQgc29t ZSB0ZXh0IGFib3V0IHRoYXQsIGFuZCBzb21lIGd1aWRhbmNlIHJlZ2FyZGluZyB3aGVuIG5vbWlu YXRpb24gc2hvdWxkIGF0IGxhdGVzdCBiZSBkb25lLg0KDQpGb3IgZXhhbXBsZSwgaWYgdGhlcmUg YXJlIG5vIG1vcmUgcGFpcnMgdG8gdGVzdCwgc2hvdWxkIHdlIHNheSB0aGF0IG5vbWluYXRpb24g bXVzdCBiZSBkb25lIGF0IHRoYXQgcG9pbnQ/IFRoYXQgd291bGQgYWxzbyBjb3ZlciB0cmlja2xl LCBhcyBpbiB0aGUgY2FzZSBvZiB0cmlja2x5IHRoZXJlIHdvdWxkIGJlIG1vcmUgcGFpcnMgdG8g dGVzdCA6KQ0KDQpNeSBwb2ludCB3YXMgdGhhdCB0aGluZ3Mgd2lsbCB3b3JrIChhdCBsZWFzdCBp biB0aGVvcnkpIGV2ZW4gaWYgeW91IGRvbuKAmXQgbm9taW5hdGUuDQoNCj5Ib3dldmVyLCB3aXRo b3V0IHRoZXNlIGV4dGVuc2lvbnMgb3IgY2xhcmlmaWNhdGlvbnMsIEkgZG9uJ3QgdGhpbmsgd2Ug Y2FuIHJlYWxseSBzYXkgdGhhdCBSRkMgNTI0NWJpcyBlbmFibGVzIG5vbWluYXRpb24gdG8gYmUg bWFkZSBvcHRpb25hbC4NCg0K4oCcb3B0aW9uYWzigJ0gd2FzIHBlcmhhcHMgd3Jvbmcgd29yZGlu Zy4NCg0KPkJUVywgc2luY2Ugd2UgYXJlIHJlYWxseSB0YWxraW5nIGFib3V0IG1ha2luZyBub21p bmF0aW9uIG9wdGlvbmFsLCAiY29udGludW91cyBub21pbmF0aW9uIiBkb2VzIG5vdCBzdHJpa2Ug bWUgYXMgYSBnb29kIHRlcm0gdG8gZGVzY3JpYmUgd2hhdCB3ZSdyZSA+dGFsa2luZyBhYm91dC4N Cg0KSSBhZ3JlZSA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCk9uIE1vbiwg Tm92IDIxLCAyMDE2IGF0IDEwOjMzIEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+ PiB3cm90ZToNCkRvZXNuJ3QgNTI0NWJpcyBhbHJlYWR5IGltcGxlbWVudCAiY29udGludW91cyBu b21pbmF0aW9uIiwgYnkgbWFraW5nIG5vbWluYXRpbmcgIm9wdGlvbmFsIiAoYXMgeW91IGNhbiBz ZW5kIG1lZGlhIGJlZm9yZSBub21pbmF0aW9uKT8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K U2VudCBmcm9tIG15IGlQaG9uZQ0KDQo+IE9uIDIxIE5vdiAyMDE2LCBhdCAxOS41OCwgRW1pbCBJ dm92IDxlbWNob0BqaXRzaS5vcmc8bWFpbHRvOmVtY2hvQGppdHNpLm9yZz4+IHdyb3RlOg0KPg0K Pj4gT24gMTEvMjAvMTYgNToyMCBQTSwgUm9tYW4gU2hwb3VudCB3cm90ZToNCj4+IEkgYWxzbyB3 YW50ZWQgdG8gYnJpbmcgdXAgdGhhdCB0aGlzIGdyb3VwIGlzIGFsc28gYWN0aXZlbHkgd29ya2lu ZyBvbg0KPj4gY29udGludW91cyBub21pbmF0aW9uLg0KPg0KPiBQZXJzb25hbGx5IEkgYW0gbm90 IGF3YXJlIG9mIGFueSBhY3RpdmUgd29yayBvbiB0aGlzIGluIHRoZSBncm91cC4gQW0gSSBtaXNz aW5nIHNvbWV0aGluZz8NCj4NCj4gSSBhbSBhbHNvIG9wcG9zZWQgdG8gdHJ5aW5nIHRvIHNxdWVl emUgdGhpcyBpbnRvIElDRSdzIGN1cnJlbnQgdmVyc2lvbi4gVGhpbmsgd2Ugc2hvdWxkIHRoaW5r IGFib3V0IGEgbW9yZSBzZXJpb3VzIHJlZGVzaWduIGZpcnN0Lg0KPg0KPiBFbWlsDQo+DQo+IC0t DQo+IGh0dHBzOi8vaml0c2kub3JnDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B4BE8E9DAESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7JnF1b3Q7RG9lc24n dCBSRkMgNTI0NWJpcyBhbHJlYWR5IGltcGxlbWVudCAmcXVvdDtjb250aW51b3VzIG5vbWluYXRp b24mcXVvdDsgYnkgbWFraW5nIG5vbWluYXRpbmcgJnF1b3Q7b3B0aW9uYWwmcXVvdDsgKGFzIHlv dSBjYW4gc2VuZCBtZWRpYSBiZWZvcmUgbm9taW5hdGlvbik/JnF1b3Q7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7W0JBXSAmbmJz cDtXaGlsZSBSRkMgNTI0NTJiaXMgbWFrZXMgaXQgcG9zc2libGUgc2VuZCBtZWRpYSBiZWZvcmUg bm9taW5hdGlvbiwgSSBkb24ndCB0aGluayB0aGUgY3VycmVudCB0ZXh0IGVuYWJsZXMgYW4gaW1w bGVtZW50YXRpb24gdG8gZGlzcGVuc2Ugd2l0aCAmZ3Q7bm9taW5hdGlvbiBlbnRpcmVseS4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDtGb3IgZXhhbXBsZSwgdGhlIHRleHQgcmVxdWlyZXMgYW4gaW1wbGVtZW50YXRpb24g dG8gYmUgcmVhZHkgdG8gcmVjZWl2ZSBhcyBzb29uIGFzIGl0IHNlbmRzIGNhbmRpZGF0ZSBpbmZv cm1hdGlvbi4gVGhhdCBpbXBsaWVzIHRoYXQgcmVzb3VyY2VzIGNhbm5vdCBiZSAmZ3Q7ZnJlZWQg dW50aWwgYSBjYW5kaWRhdGUtcGFpciBoYXMgYmVlbiBub21pbmF0ZWQuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7U2lu Y2Uga2VlcGluZyByZXNvdXJjZXMgYWxpdmUgaW5kZWZpbml0ZWx5IGlzIHByb2JsZW1hdGljIChl LmcuIGZyb20gYW4gZW5lcmd5IGNvbnN1bXB0aW9uIHN0YW5kcG9pbnQpLCB0aGUgaW1wbGVtZW50 YXRpb25zIEkgYW0gZmFtaWxpYXIgd2l0aCB1dGlsaXplICZndDttZWNoYW5pc21zIHRvIGlkZW50 aWZ5IG5lZWRlZCB2ZXJzdXMgdW5uZWVkZWQgcGFpcnMuJm5ic3A7IEZvciBleGFtcGxlLCBhIGNh bmRpZGF0ZSByZW1vdmFsDQogZXh0ZW5zaW9uIGNhbiBiZSB1c2VkIHRvIGlkZW50aWZ5IHBhaXJz IHRoYXQgY2FuIGJlIGRpc2NhcmRlZCAob3IgJmd0O3BhaXJzIG5vdCB0byBiZSBjaGVja2VkKSwg b3IgY29uc2VudCBtZWNoYW5pc21zIGNhbiBiZSB1c2VkIHRvIGlkZW50aWZ5IHBhaXJzIHRvIGJl IGtlcHQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+SSBkbyBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBnb29kIHJlYXNvbnMgd2h5IHlv dSBzaG91bGQgbm9taW5hdGUsIGFuZCBtYXliZSB3ZSBuZWVkIHRvIGFkZCBzb21lIHRleHQgYWJv dXQgdGhhdCwgYW5kIHNvbWUgZ3VpZGFuY2UgcmVnYXJkaW5nIHdoZW4gbm9taW5hdGlvbiBzaG91 bGQgYXQgbGF0ZXN0DQogYmUgZG9uZS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZvciBleGFtcGxlLCBpZiB0 aGVyZSBhcmUgbm8gbW9yZSBwYWlycyB0byB0ZXN0LCBzaG91bGQgd2Ugc2F5IHRoYXQgbm9taW5h dGlvbiBtdXN0IGJlIGRvbmUgYXQgdGhhdCBwb2ludD8gVGhhdCB3b3VsZCBhbHNvIGNvdmVyIHRy aWNrbGUsIGFzIGluIHRoZSBjYXNlIG9mIHRyaWNrbHkgdGhlcmUgd291bGQNCiBiZSBtb3JlIHBh aXJzIHRvIHRlc3QgOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TXkgcG9pbnQgd2FzIHRoYXQgdGhpbmdzIHdp bGwgd29yayAoYXQgbGVhc3QgaW4gdGhlb3J5KSBldmVuIGlmIHlvdSBkb27igJl0IG5vbWluYXRl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0O0hvd2V2ZXIsIHdpdGhvdXQgdGhlc2UgZXh0ZW5zaW9ucyBvciBj bGFyaWZpY2F0aW9ucywgSSBkb24ndCB0aGluayB3ZSBjYW4gcmVhbGx5IHNheSB0aGF0IFJGQyA1 MjQ1YmlzIGVuYWJsZXMgbm9taW5hdGlvbiB0byBiZSBtYWRlIG9wdGlvbmFsLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKAnG9w dGlvbmFs4oCdIHdhcyBwZXJoYXBzIHdyb25nIHdvcmRpbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtC VFcsIHNpbmNlIHdlIGFyZSByZWFsbHkgdGFsa2luZyBhYm91dCBtYWtpbmcgbm9taW5hdGlvbiBv cHRpb25hbCwgJnF1b3Q7Y29udGludW91cyBub21pbmF0aW9uJnF1b3Q7IGRvZXMgbm90IHN0cmlr ZSBtZSBhcyBhIGdvb2QgdGVybSB0byBkZXNjcmliZSB3aGF0IHdlJ3JlICZndDt0YWxraW5nIGFi b3V0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkkgYWdyZWUgOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Q2hyaXN0ZXI8L3NwYW4+ICZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1vbiwgTm92IDIxLCAyMDE2IGF0IDEwOjMzIEFNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXNuJ3QgNTI0 NWJpcyBhbHJlYWR5IGltcGxlbWVudCAmcXVvdDtjb250aW51b3VzIG5vbWluYXRpb24mcXVvdDss IGJ5IG1ha2luZyBub21pbmF0aW5nICZxdW90O29wdGlvbmFsJnF1b3Q7IChhcyB5b3UgY2FuIHNl bmQgbWVkaWEgYmVmb3JlIG5vbWluYXRpb24pPzxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJy Pg0KQ2hyaXN0ZXI8YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgaVBob25lPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZndDsgT24gMjEgTm92 IDIwMTYsIGF0IDE5LjU4LCBFbWlsIEl2b3YgJmx0OzxhIGhyZWY9Im1haWx0bzplbWNob0BqaXRz aS5vcmciPmVtY2hvQGppdHNpLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7 Jmd0OyBPbiAxMS8yMC8xNiA1OjIwIFBNLCBSb21hbiBTaHBvdW50IHdyb3RlOjxicj4NCiZndDsm Z3Q7IEkgYWxzbyB3YW50ZWQgdG8gYnJpbmcgdXAgdGhhdCB0aGlzIGdyb3VwIGlzIGFsc28gYWN0 aXZlbHkgd29ya2luZyBvbjxicj4NCiZndDsmZ3Q7IGNvbnRpbnVvdXMgbm9taW5hdGlvbi48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBQZXJzb25hbGx5IEkgYW0gbm90IGF3YXJlIG9mIGFueSBhY3RpdmUg d29yayBvbiB0aGlzIGluIHRoZSBncm91cC4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz88YnI+DQom Z3Q7PGJyPg0KJmd0OyBJIGFtIGFsc28gb3Bwb3NlZCB0byB0cnlpbmcgdG8gc3F1ZWV6ZSB0aGlz IGludG8gSUNFJ3MgY3VycmVudCB2ZXJzaW9uLiBUaGluayB3ZSBzaG91bGQgdGhpbmsgYWJvdXQg YSBtb3JlIHNlcmlvdXMgcmVkZXNpZ24gZmlyc3QuPGJyPg0KJmd0Ozxicj4NCiZndDsgRW1pbDxi cj4NCiZndDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2ppdHNpLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vaml0c2kub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_7594FB04B1934943A5C02806D1A2204B4BE8E9DAESESSMB209erics_-- From nobody Tue Nov 22 05:31:28 2016 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 865F3129A2E for ; Tue, 22 Nov 2016 05:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xV7NInLcMOb for ; Tue, 22 Nov 2016 05:31:23 -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 A28B51299F1 for ; Tue, 22 Nov 2016 05:31:22 -0800 (PST) X-AuditID: c1b4fb25-ec9d598000007ee2-4c-583448a84dfe Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id C7.F9.32482.8A844385; Tue, 22 Nov 2016 14:31:20 +0100 (CET) Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.319.2; Tue, 22 Nov 2016 14:31:19 +0100 To: From: Miika Komu Organization: Ericsson AB Message-ID: <92176d2b-d883-4b11-7137-4b5f26dd987c@ericsson.com> Date: Tue, 22 Nov 2016 15:31:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM2K7k+4KD5MIg0+XbSy+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGt7UNTAW/3jBW7J/yna2Bcd9Sxi5GTg4JAROJLzcmANlcHEIC 6xglmq52sYEkhATWMEq8aysDsUUEhCR6b98Ei7MJaEmsunOdGcQWFrCQmNjVzgpi8wtISmxo 2A0W5xWwl3i2ZQ8TiM0ioCrxtrkVLC4qECGx6escFogaQYmTM5+A2cxAc2bOP88IYWtLLFv4 GqieA+gGFYmLx4InMPLNQtIxC0nHLCQdCxiZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIE htTBLb9VdzBefuN4iFGAg1GJh9fAxThCiDWxrLgy9xCjBAezkgivj7tJhBBvSmJlVWpRfnxR aU5q8SFGaQ4WJXFes5X3w4UE0hNLUrNTUwtSi2CyTBycUg2M/iXzgh9l/dWr0HXS6us33tRk kiv1ttXncbaaVJxpU/7aA8/azxq7feg3ktjfMP3h+qrT/JJvzT0Cu9oyDqYaeP3cUryIP3u/ 1e4JSy/Nbbjo+lkx6+vu/GcqXh4nuDvZj31mnbxFrSL0sc6qNxzHkyJKM/L4X19aapUj1/PK JcyINe5lzwclluKMREMt5qLiRACEIaTYJQIAAA== Archived-At: Subject: [Ice] an extra review of draft-ietf-ice-rfc5245bis-05 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 13:31:26 -0000 Hi folks, I have promised offline Christer some feedback about the ICE-bis draft.=20 It's mostly nits and descriptions that were difficult to follow. Here=20 goes nothing :) > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5= > 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 6= > 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 8= > 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 10= > 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 11= > 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 12= > 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 13= > 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 13= > 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 14= > 2.8. Usages of ICE . . . . . . . . . . . . . . . . . . . . . . 15= > 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15= > 4. ICE Candidate Gathering and Exchange . . . . . . . . . . . . 18= > 4.1. Procedures for Full Implementation . . . . . . . . . . . 19= > 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19= > 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 20= > 4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 21= > 4.1.1.3. Computing Foundations . . . . . . . . . . . . . . 23= > 4.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . 23= > 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 23= > 4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 24= > 4.1.2.2. Guidelines for Choosing Type and Local > Preferences . . . . . . . . . . . . . . . . . . . 25= > 4.1.3. Eliminating Redundant Candidates . . . . . . . . . . 26= > 4.2. Lite Implementation Procedures . . . . . . . . . . . . . 26= > 4.3. Encoding the Candidate Information . . . . . . . . . . . 27= As visible from the table of contents, the text is a bit heavily nested=20 which makes it a bit hard to read. My editorial suggestion would be to=20 remind the reader about the context always when you go back in hierarchy = e.g. from 4.1.1.4. to 4.1.2 as follows: 4.1.2. Prioritizing Candidates After completing candidate gathering, the next step for a full implementation is to prioritize candidates. [...] > 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 I really liked the example in the end even though the scenario was a bit simplified (i.e., one end had a public address). I was somehow=20 expecting was packet diagrams for ICE-based STUN messages, but they are not included at all. > 2.6. Concluding ICE > > ICE checks are performed in a specific sequence, so that high- > priority candidate pairs are checked first, followed by lower- > priority ones. One way to conclude ICE is to declare victory as soon= > as a check for each component of each media stream completes > successfully. Indeed, this is a reasonable algorithm, and details > for it are provided below. However, it is possible that a packet > loss will cause a higher-priority check to take longer to complete. > In that case, allowing ICE to run a little longer might produce > better results. More fundamentally, however, the prioritization > defined by this specification may not yield "optimal" results. As an= > example, if the aim is to select low-latency media paths, usage of a > relay is a hint that latencies may be higher, but it is nothing more > than a hint. An actual round-trip time (RTT) measurement could be > made, and it might demonstrate that a pair with lower priority is > actually better than one with higher priority. > > Consequently, ICE assigns one of the agents in the role of the > CONTROLLING AGENT, and the other of the CONTROLLED AGENT. The > controlling agent gets to nominate which candidate pairs will get > used for media amongst the ones that are valid. > > When nominating, the controlling agent lets the checks continue until= > at least one valid candidate pair for each media stream is found. > Then, it picks amongst those that are valid, and sends a second STUN > request on its NOMINATED candidate pair, but this time with a flag > set to tell the peer that this pair has been nominated for use. This= > is shown in Figure 4. > > > L R > - - > STUN request -> \ L's > <- STUN response / check > > <- STUN request \ R's > STUN response -> / check > > STUN request + flag -> \ L's > <- STUN response / check > > > Figure 4: Nomination > > Once the STUN transaction with the flag completes, both sides cancel > any future checks for that media stream. ICE will now send media > using this pair. The pair an ICE agent is using for media is called > the SELECTED PAIR. > > Once ICE is concluded, it can be restarted at any time for one or all= > of the media streams by either agent. This is done by sending an > updated candidate information indicating a restart. I would clarify that both sides check separately for connectivity even=20 when using the aggressive nomination. > 2.7. Lite Implementations > > In order for ICE to be used in a call, both agents need to support > it. However, certain agents will always be connected to the public > Internet and have a public IP address at which it can receive packets= > from any correspondent. To make it easier for these devices to > support ICE, ICE defines a special type of implementation called LITE= > (in contrast to the normal FULL implementation). A lite > implementation doesn't gather candidates; it includes only host > candidates for any media stream. Lite agents do not generate > connectivity checks or run the state machines, though they need to be= > able to respond to connectivity checks. When a lite implementation > connects with a full implementation, the full agent takes the role of= > the controlling agent, and the lite agent takes on the controlled > role. When two lite implementations connect, no checks are sent. The last sentence left me in limbo; how are addresses selected then?=20 It's explained later, but some hint would be great here. > 2.8. Usages of ICE > > This document specifies generic use of ICE with protocols that > provide means to exchange candidate information between the ICE > Peers. The specific details of (i.e how to encode candidate > information and the actual candidate exchange process) for different > protocols using ICE are described in separate usage documents. One > possible way the agents can exchange the candidate information is to > use [RFC3264] based Offer/Answer semantics as part of the SIP > [RFC3261] protocol [I-D.ietf-mmusic-ice-sip-sdp]. > > 3. Terminology > > [...] > > Foundation: An arbitrary string that is the same for two candidates > that have the same type, base IP address, protocol (UDP, TCP, > etc.), and STUN or TURN server. If any of these are different, > then the foundation will be different. Two candidate pairs with > the same foundation pairs are likely to have similar network > characteristics. Foundations are used in the frozen algorithm. What do you mean by type? This is explained later, but some hint would=20 be good here. > Check List: An ordered set of candidate pairs that an agent will use= > to generate checks. How many check lists are there? One per media stream? > 4.1.3. Eliminating Redundant Candidates > > Next, the agent eliminates redundant candidates. A candidate is > redundant if its transport address equals another candidate, and its > base equals the base of that other candidate. Note that two > candidates can have the same transport address yet have different > bases, and these would not be considered redundant. When does this occur (multihoming?)? > Frequently, a > server reflexive candidate and a host candidate will be redundant > when the agent is not behind a NAT. The agent SHOULD eliminate the > redundant candidate with the lower priority. > > This process is common across the initiating and responding agents. I would clarify that the process is about eliminating *local* candidates (i.e. not pairs which is called pruning). It's easy to mix=20 the terms... > 4.2. Lite Implementation Procedures > > Lite implementations only utilize host candidates. A lite > implementation MUST, for each component of each media stream, > allocate zero or one IPv4 candidates. It MAY allocate zero or more > IPv6 candidates, but no more than one per each IPv6 address utilized > by the host. Since there can be no more than one IPv4 candidate per > component of each media stream, if an agent has multiple IPv4 > addresses, it MUST choose one for allocating the candidate. If a > host is dual-stack, it is RECOMMENDED that it allocate one IPv4 > candidate and one global IPv6 address. With the lite implementation,= > ICE cannot be used to dynamically choose amongst candidates. > Therefore, including more than one candidate from a particular scope > is NOT RECOMMENDED, since only a connectivity check can truly > determine whether to use one address or the other. I didn't quite follow the last sentence, please rephrase? > Each component has an ID assigned to it, called the component ID. > For RTP-based media streams, unless RTCP is multiplexed in the same > port with RTP, the RTP itself has a component ID of 1, and RTCP a > component ID of 2. If an agent is using RTCP without multiplexing, > it MUST obtain candidates for it. However, absence of a component ID= > 2 as such does not imply use of RTCP/RTP multiplexing, as it could > also mean that RTCP is not used. > > Each candidate is assigned a foundation. The foundation MUST be > different for two candidates allocated from different IP addresses, > and MUST be the same otherwise. What do you mean by allocation? Please elaborate. > 5.1.3.1. Forming Candidate Pairs > > First, the agent takes each of its candidates for a media stream > (called LOCAL CANDIDATES) and pairs them with the candidates it > received from its peer (called REMOTE CANDIDATES) for that media > stream. In order to prevent the attacks described in Section 13.4.1,= > agents MAY limit the number of candidates they'll accept in an > candidate exchange process. A local candidate is paired with a > remote candidate if and only if the two candidates have the same > component ID and have the same IP address version. It is possible > that some of the local candidates won't get paired with remote > candidates, and some of the remote candidates won't get paired with > local candidates. This can happen if one agent doesn't include > candidates for the all of the components for a media stream. If this= > happens, the number of components for that media stream is > effectively reduced, and considered to be equal to the minimum across= > both agents of the maximum component ID provided by each agent across= > all components for the media stream. I didn't quite follow the last statement. > 5.1.3.2. Computing Pair Priority and Ordering Pairs > > Once the pairs are formed, a candidate pair priority is computed. > Let G be the priority for the candidate provided by the controlling > agent. Let D be the priority for the candidate provided by the > controlled agent. The priority for a pair is computed as: > > pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) > > Where G>D?1:0 is an expression whose value is 1 if G is greater than > D, and 0 otherwise. Once the priority is assigned, the agent sorts > the candidate pairs in decreasing order of priority. If two pairs > have identical priority, the ordering amongst them is arbitrary. Please clarify that the pair priority should be stored in 64-bit integer in an implementation. > 5.1.3.3. Pruning the Pairs > > This sorted list of candidate pairs is used to determine a sequence > of connectivity checks that will be performed. Each check involves > sending a request from a local candidate to a remote candidate. > Since an agent cannot send requests directly from a reflexive > candidate, but only from its base, the agent next goes through the > sorted list of candidate pairs. For each pair where the local > candidate is server reflexive, the server reflexive candidate MUST be= > replaced by its base. Once this has been done, the agent MUST prune > the list. This is done by removing a pair if its local and remote > candidates are identical to the local and remote candidates of a pair= > higher up on the priority list. The result is a sequence of ordered > candidate pairs, called the check list for that media stream. > > In addition, in order to limit the attacks described in > Section 13.4.1, an agent MUST limit the total number of connectivity > checks the agent performs across all check lists to a specific value,= > and this value MUST be configurable. A default of 100 is > RECOMMENDED. This limit is enforced by discarding the lower-priority= > candidate pairs until there are less than 100. Does 100 include retransmissions? It is RECOMMENDED > that a lower value be utilized when possible, set to the maximum > number of plausible checks that might be seen in an actual deployment= > configuration. The requirement for configuration is meant to provide= > a tool for fixing this value in the field if, once deployed, it is > found to be problematic. I would clarify that pruning refers to filtering out candidate *pairs* (i.e. not local addresses, which would be "eliminating redundant candidates". It's easy to mix the terms... > 5.2. Lite Implementation Procedures > > Lite implementations skips most of the steps in Section 5 except for > verifying the peer's ICE support and determining its role in the ICE > processing. > > On determining the role for a lite implementation being the > controlling agent means selecting a candidate pair based on the ones > in the candidate exchange (for IPv4, there is only ever one pair), > and then updating the peer with the new candidate information > reflecting that selection, when needed (it is never needed for an > IPv4-only host). Why it's not needed for an IPv4-only host? > The controlled agent is told which candidate pairs > to use for each media stream, and no further candidate updates are > needed to signal this information. Who tells the controlled agent? Why further updates are not needed? > 6.1.2.1. PRIORITY > > An agent MUST include the PRIORITY attribute in its Binding request. > The attribute MUST be set equal to the priority that would be > assigned, based on the algorithm in Section 4.1.2, to a peer > reflexive candidate, should one be learned as a consequence of this > check (see Section 6.1.2.4.2.1 for how peer reflexive candidates are > learned). This priority value will be computed identically to how > the priority for the local candidate of the pair was computed, except= > that the type preference is set to the value for peer reflexive > candidate types. This was difficult to follow, please elaborate: * Is the priority attribute for a single local address or address pair? * What if reflexive address is not learned? > 6.1.2.2. USE-CANDIDATE > > The controlling agent includes the USE-CANDIDATE attribute in order > to nominate a candidate pair Section 6.2.1.1. The controlled agent > MUST NOT include the USE-CANDIDATE attribute in its Binding request. =2E..*in* Section... > 6.1.2.3. ICE-CONTROLLED and ICE-CONTROLLING > > The agent MUST include the ICE-CONTROLLED attribute in the request if= > it is in the controlled role, and MUST include the ICE-CONTROLLING > attribute in the request if it is in the controlling role. > > The content of either attribute are used as tie-breaker values when > an ICE role conflict occurs Section 6.1.3.1.1. > > The ICE-CONTROLLED and ICE-CONTROLLING attributes are defined in > Section 14.1. Are ICE-CONTROLLED and ICE-CONTROLLING supposed to be set in all connectivity checks (including responses)? If yes, is this mentioned in the document? I read about this from here: https://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01 "Note that, even if a using protocol does not need to use the role conflict detection mechanism, it must include the ICE-CONTOLLED and ICE-CONTROLLING attributes in its connectivity checks as described in Section 7 of ICE. This ensures that it is possible to easily build gateways between different protocols using ICE." (Btw, I didn't quite understand the gateway comment) > 6.1.2.4.1. Failure Cases > > [...] > > Agents MAY support receipt of ICMP errors for connectivity checks. > If the STUN transaction generates an ICMP error, the agent sets the > state of the pair to Failed. If the STUN transaction generates a > STUN error response that is unrecoverable (as defined in [RFC5389]) > or times out, the agent sets the state of the pair to Failed. ICMP messages can be forged easier than STUN messages. This could be used to block STUN agents without being a man-in-the-middle? > 6.1.2.4.2.1. Discovering Peer Reflexive Candidates > > The agent checks the mapped address from the STUN response. If the > transport address does not match any of the local candidates that the= > agent knows about, the mapped address represents a new candidate -- a= > peer reflexive candidate. Like other candidates, it has a type, > base, priority, and foundation. They are computed as follows: > > o Its type is equal to peer reflexive. > > o Its base is set equal to the local candidate of the candidate pair= > from which the STUN check was sent. > > o Its priority is set equal to the value of the PRIORITY attribute > in the Binding request. > > o Its foundation is selected as described in Section 4.1.1.3. > > This peer reflexive candidate is then added to the list of local > candidates for the media stream. Its username fragment and password > are the same as all other local candidates for that media stream. > However, the peer reflexive candidate is not paired with other remote= > candidates. This is not necessary; a valid pair will be generated > from it momentarily based on the procedures in Section 6.1.2.4.2.2. > If an agent wishes to pair the peer reflexive candidate with other > remote candidates besides the one in the valid pair that will be > generated, the agent MAY generate an update the peer with the > candidate information that includes the peer reflexive candidate. I think the update procedure has not been defined yet, so maybe reference the corresponding section in the draft? > 6.1.2.4.2.2. Constructing a Valid Pair > > The agent constructs a candidate pair whose local candidate equals > the mapped address of the response, and whose remote candidate equals= > the destination address to which the request was sent. This is > called a valid pair, since it has been validated by a STUN > connectivity check. The valid pair may equal the pair that generated= > the check, may equal a different pair in the check list, or may be a > pair not currently on any check list. If the pair equals the pair > that generated the check or is on a check list currently, it is also > added to the VALID LIST, which is maintained by the agent for each > media stream. This list is empty at the start of ICE processing, and= > fills as checks are performed, resulting in valid candidate pairs. > > It will be very common that the pair will not be on any check list. > Recall that the check list has pairs whose local candidates are never= > server reflexive; those pairs had their local candidates converted to= > the base of the server reflexive candidates, and then pruned if they > were redundant. When the response to the STUN check arrives, the > mapped address will be reflexive if there is a NAT between the two. > In that case, the valid pair will have a local candidate that doesn't= > match any of the pairs in the check list. > > If the pair is not on any check list, the agent computes the priority= > for the pair based on the priority of each candidate, using the > algorithm in Section 5.1.3. The priority of the local candidate > depends on its type. If it is not peer reflexive, it is equal to the= > priority signaled for that candidate in the candidate exchange. If > it is peer reflexive, it is equal to the PRIORITY attribute the agent= > placed in the Binding request that just completed. The priority of > the remote candidate is taken from the candidate information of the > peer. If the candidate does not appear there, then the check must > have been a triggered check to a new remote candidate. Where there? Who triggered the check? > 6.1.2.4.2.3. Updating Pair States > > 2. If there is a pair in the valid list for every component of this > media stream (where this is the actual number of components being= > used, in cases where the number of components signaled in the > candidate exchange differs from initiating to responding agent), > the success of this check may unfreeze checks for other media > streams. I didn't quite follow the remark in the parenthesis. Please elaborate? > 6.1.3.1.2. Computing Mapped Address > > For requests being received on a relayed candidate, the source > transport address used for STUN processing (namely, generation of the= > XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the= > TURN server. That source transport address will be present in the > XOR-PEER-ADDRESS attribute of a Data Indication message, if the > Binding request was delivered through a Data Indication. If the > Binding request was delivered through a ChannelData message, the > source transport address is the one that was bound to the channel. ChannelData has not been introduced yet in the document. > 6.1.3.1.3. Learning Peer Reflexive Candidates > > [...] > > o The foundation of the candidate is set to an arbitrary value, > different from the foundation for all other remote candidates. If= > any subsequent candidate exchanges contain this peer reflexive > candidate, it will signal the actual foundation for the candidate.= What do you mean by the last statement? Please elaborate? > [...] > This candidate is added to the list of remote candidates. However, > the agent does not pair this candidate with any local candidates. Why? This leaves the reader in a limbo... > 6.1.3.1.4. Triggered Checks > > [...] > > These steps are done to facilitate rapid completion of ICE when both > agents are behind NAT. > > o If the pair is not already on the check list: > > * The pair is inserted into the check list based on its priority.= > > * Its state is set to Waiting. > > * The pair is enqueued into the triggered check queue. Does this refer to peer reflexive candidates? If so, I guess this contradicts with 6.1.3.1.3 (check my previous comment)? > 6.1.3.1.5. Updating the Nominated Flag > > [...] > o If the state of this pair is In-Progress, if its check produces a > successful result, the resulting valid pair has its nominated flag= > set when the response arrives. This may end ICE processing for > this media stream when it arrives; see Section 6.2. =2E..In-Progress, *and* if its check... > 11.3. RTO > > During the ICE gathering phase, ICE agents SHOULD calculate the RTO > value using the following formula: > > > > RTO =3D MAX (500ms, Ta * (Num-Of-Pairs)) > > > Num-Of-Pairs: the number of pairs of candidates > with STUN or TURN servers. What do you mean with number of pairs of candidates here? Please elaborat= e? > 12. Example > > The example is based on the simplified topology of Figure 8. > > > +-------+ > |STUN | > |Server | > +-------+ > | > +---------------------+ > | | > | Internet | > | | > +---------------------+ > | | > | | > +---------+ | > | NAT | | > +---------+ | > | | > | | > +-----+ +-----+ > | L | | R | > +-----+ +-----+ > > Figure 8: Example Topology I suggest adding the IP addresses and ports also into the figure for easier referencing. > [...] > L NAT STUN R > |RTP STUN alloc. | | > |(1) STUN Req | | | > |S=3D$L-PRIV-1 | | | > |D=3D$STUN-PUB-1 | | | > |------------->| | | > | |(2) STUN Req | | > | |S=3D$NAT-PUB-1 | | > | |D=3D$STUN-PUB-1 | | > | |------------->| | > | |(3) STUN Res | | > | |S=3D$STUN-PUB-1 | | > | |D=3D$NAT-PUB-1 | | > | |MA=3D$NAT-PUB-1 | | > | |<-------------| | > |(4) STUN Res | | | > |S=3D$STUN-PUB-1 | | | > |D=3D$L-PRIV-1 | | | > |MA=3D$NAT-PUB-1 | | | > |<-------------| | | > |(5) L's Candidate Information| | > |------------------------------------------->| > | | | | RTP STUN > | | | | alloc. > | | |(6) STUN Req | > | | |S=3D$R-PUB-1 | > | | |D=3D$STUN-PUB-1 | > | | |<-------------| > | | |(7) STUN Res | > | | |S=3D$STUN-PUB-1 | > | | |D=3D$R-PUB-1 | > | | |MA=3D$R-PUB-1 | > | | |------------->| > |(8) R's Candidate Information| | > |<-------------------------------------------| > | |(9) Bind Req | |Begin > | |S=3D$R-PUB-1 | |Connectivit= y > | |D=3DL-PRIV-1 | |Checks > | |<----------------------------| > | |Dropped | | I think the packet (9) should be dropped earlier (between STUN and R). > [...] > Agents L and R both pair up the candidates. They both initially have= > two pairs. Why don't you list all the pairs explicitly here? > [...] > Soon after receipt of the STUN Binding request from agent L (message > 11), agent R will generate its triggered check. This check happens > to match the next one on its check list -- from its host candidate to= > agent L's server reflexive candidate. What is the significance of the check matching the next on its check list? This was brought up, but not explained. > 13.1. Attacks on Connectivity Checks > > [...] > Forcing the fake valid result works in a similar way. The agent > needs to wait for the Binding request from each agent, and inject a > fake success response. =2E...The *attacker* needs to wait... > 13.3. Attacks on Relayed Candidate Gathering > > An attacker might attempt to disrupt the gathering of relayed > candidates, forcing the client to believe it has a false relayed > candidate. Exchanges with the TURN server are authenticated using a > long-term credential. Consequently, injection of fake responses or > requests will not work. In addition, unlike Binding requests, > Allocate requests are not susceptible to replay attacks with modified= > source IP addresses and ports, since the source IP address and port > are not utilized to provide the client with its relayed candidate. =2E..source IP address and port in *packet headers*... (right?) From nobody Tue Nov 22 12:43:41 2016 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 24F5E12944B for ; Tue, 22 Nov 2016 12:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmW6ecg1bgCG for ; Tue, 22 Nov 2016 12:43:32 -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 8052A12943C for ; Tue, 22 Nov 2016 12:43:32 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id c47so20422942qtc.2 for ; Tue, 22 Nov 2016 12:43:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3iKSBzFQaKMjedQ3r42H65d//wDAyff7B7Du8hxDSyM=; b=cFd7CzaB2LLmCw2V2MbJ0mZFYUwb4XUChOEpR9oGbbiRAb+X26e2o2LV7tnejSIB0m 5XWotjAKII0CgR/T96/oZCsoUa+qeFvbGewsg1paEplmtcm78s1lmN4taUb4jgC9uSPb jcdNojYMnmMhxTNXPQs69zap/st7usb0NzSMsYzDiQTYxgRFUl6Uujf4ixwoUoKDXXvm 35sioseqZqrFRnRSVIifAVTymiqVZ9lnEkMImGrkYaNn9INyAAOIzX7S3+UcaIGRh+Ek B3aEIPz0ZuO/Dz8nmf+47jOVoV9uqasgRrMLVookU6t0DGyVfvZOa6dMi110VGVmb6M6 n6CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3iKSBzFQaKMjedQ3r42H65d//wDAyff7B7Du8hxDSyM=; b=TgC2neqc4y8tXcj8pxp5Li8El+/YaN1AHjGhOlAu+u8oYZPReet6Ki5IR4cXwNxoqe xaJv37S9xxSiKn6UOIA+tbKUws2TPAs8kADwTnHyh2TOhwiBZPB5QdXhVduzmJ2fp7ZZ GU266w6hQNlS3mEycNuck8un0HvmHcRAXZxEc2aZbsQV38WZ0b8uS0bxUJ2ghLiB1Qz+ GlSwmeR/h/rbBlYSuARoWFRDPQORyDigeJ+TEg/bTTP+7tmvg76qS9e/QnxqnbIuC29I BG4jpr6Z5L+4RHbAP2p+WcrBRmMrdhXVcme0jtup2Jf7JROnYbbxErr6feGESyoxPzon hnOw== X-Gm-Message-State: AKaTC00oyhK5A39j5TiAj2crSm9C9ABLfOHS0opYrS7vjV4Bm26ydAJ+HCgtm6FOqZ9+jA== X-Received: by 10.200.52.143 with SMTP id w15mr12531379qtb.187.1479847411491; Tue, 22 Nov 2016 12:43:31 -0800 (PST) Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com. [209.85.216.180]) by smtp.gmail.com with ESMTPSA id 96sm14571503qkz.40.2016.11.22.12.43.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2016 12:43:30 -0800 (PST) Received: by mail-qt0-f180.google.com with SMTP id n6so20491181qtd.1; Tue, 22 Nov 2016 12:43:30 -0800 (PST) X-Received: by 10.200.56.88 with SMTP id r24mr14801386qtb.39.1479847410534; Tue, 22 Nov 2016 12:43:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.135.243 with HTTP; Tue, 22 Nov 2016 12:43:30 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE823C9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BE823C9@ESESSMB209.ericsson.se> From: Roman Shpount Date: Tue, 22 Nov 2016 15:43:30 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113ce4763a35620541e9d344 Archived-At: Cc: "bfcpbis@ietf.org" , "ice@ietf.org" , "mmusic@ietf.org" , Alan Ford Subject: Re: [Ice] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 20:43:36 -0000 --001a113ce4763a35620541e9d344 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christer, I think this is another way around -- BFCP would have to use RFC 4571 framing when using tcp candidates. There is deployed equipment (SBC) that rely on the fact that RFC 4571 framing is used by tcp candidates in ICE. I am not sure there are ICE implementations of BFCP. I think new implementation should be updated to comply with existing standards, not another way around. Can someone provide some insight regarding BFCP with UDP and ICE implementation? Are there implementations of either? I see the RFC for TCP/BFCP, but it looks like UDP/BFCP and BFCP with ICE only exist in drafts= . My proposal either to limit ICE support to UDP/DTLS/BFCP and TCP/DTLS/BFCP, or define new transport tag DBFCP (datagram BFCP), and define ICE support for UDP/DBFCP and TCP/DBFCP, where UDP version of BFCP is used over udp and tcp ICE candidates, with RFC 4571 framing used in case of tcp candidates. If this is done, we can make UDP/DTLS/BFCP MUST implement if ICE is supported for encrypted (and UDP/DBFCP for non-encrypted), make default candidate UDP, and all the ICE problems disappear. Not sure about the current state of MSRP and ICE, but I do not think there are any implementations of it. Probably the best way to implement it now would be over datachannel or quick. Regards, _____________ Roman Shpount On Mon, Nov 21, 2016 at 4:25 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Roman, > > > > Good catch. > > > > That basically means that bfcpbis would have to document the usage of > framing for BFCP-TCP =E2=80=93 assuming they want BFCP-TCP to work with I= CE. > > > > I assume the same applies to MSRP (when not using an MSRP relay). > > > > Regards, > > > > Christer > > > > > > *From:* Roman Shpount [mailto:roman@telurix.com] > *Sent:* 21 November 2016 01:23 > *To:* Alan Ford > *Cc:* Christer Holmberg ; mmusic@ietf.org= ; > ice@ietf.org; bfcpbis@ietf.org > *Subject:* Re: [MMUSIC] m=3D line protocol in case of ICE > > > > Hi All, > > > > I just wanted to add to my previous email, that according to RFC > 6544 protocols running over tcp candidates MUST use RFC 4571 framing ( > https://tools.ietf.org/html/rfc6544#section-10.1). This means that BFCP > running over tcp candidate is not TCP/BFCP and will require a different > transport tag. > > > > Regards, > > > _____________ > Roman Shpount > > > > On Thu, Nov 17, 2016 at 9:13 PM, Roman Shpount wrote: > > Hi All, > > > > There are three comments I wanted to make regarding general nature of all > existing protocols designed to work ICE > > > > 1. Protocols running on top of ICE assume that regardless what candidate > pair is used, including tcp candidates, the underlying network transport = is > unordered and unreliable. During nomination, including continuous > nomination, candidate pairs can switch, including switching from udp to t= cp > or from tcp to udp. This typically means that protocol re-transmit timers > are operational, packets are re-ordered at the protocol level, and > UDP-friendly packet sizes are used even when packets are sent over tcp > candidates. For instance DTLS and SCTP re-transmit timers, reordering, an= d > fragmentation support are still running when tcp candidates are used. > > > > 2. Protocols do not assume that particular candidate network transport > runs all the way from origination to final destination of the protocol > packets. For instance there are SBC which only handle ICE. These SBC run > the ICE state machine and then transmit the underlying protocol data to t= he > final destination using public IP. Because of this, it is not unusual for > RTP to run over tcp candidate until SBC and then run over UDP to the fina= l > destination. This is one more reason why re-transmit timers and other > mechanisms used to deal with UDP are still running over tcp candidates. > > > > 3. I am not aware of any current protocol running over ICE tcp candidates > which is not using RFC4571 framing. For instance DTLS could have been > implemented using DTLS protocol framing without RFC4571 over tcp > candidates, but this was not the case. This is partially done to simplify > implementation of SBC which terminate ICE and transmit protocol data usin= g > UDP. By using RFC 4571 framing, SBC can packetize/de-packetize data > transmitted over tcp candidates without knowing protocol details. > > > > To conclude, up until this point ICE tcp candidates were not treated as > reliable transport and served simply as another way to transmit UDP packe= ts > through firewalls. Because of this, I would argue that BFCP running over > tcp candidate is not the same as TCP/BFCP, in the same way as DTLS runnin= g > over tcp candidate is not TLS. > > > > I would also argue that any protocol running over ICE is, in essence, a > UDP based protocol, using tcp candidates only as a fall back mechanism fo= r > firewall traversal, same way as when data is relayed over TURN TCP, it is > still considered sent over UDP at the protocol level. > > > > If ICE group agrees, I think this should be documented by saying that UDP > is a MUST implement for any protocol using ICE and that default candidate > should be UDP based. > > > > Regards, > > _____________ > Roman Shpount > > > > On Thu, Nov 17, 2016 at 8:14 PM, Alan Ford wrote: > > Adding bfcpbis. > > > > You raise a good point Roman - there=E2=80=99s no definition of how to ac= tually > use ICE with BFCP at the protocol level - this only came up in some very > late reviews of 4582bis. The initial suggestion was to use the same text = as > in draft-ietf-mmusic-sctp-sdp-19, but it then raised the point that, > given BFCP does not have a MTI protocol, if the offerer supported both th= ey > would include their preferred option, but if the receiver supported the > other variant, there=E2=80=99s no way to immediately negotiate that witho= ut a > re-INVITE. > > > > Christer=E2=80=99s suggestion to relax the requirement that the m-line pr= otocol *in > the answer* matches one of the ICE candidates would support the case > where the offerer supports both but prefers UDP, but the answerer only > supports TCP. Although no implementations currently do ICE here, this > relaxation would leave the door open to gaining this negotiation > flexibility in bfcpbis implementations. There seems no reason to have thi= s > requirement applied to the answer in the first place. > > > > I don=E2=80=99t understand the comment about SBCs; today, tcp candidates = are used > for media and data channels end-to-end in WebRTC, to name but one > implementation. > > > > Regards, > > Alan > > > > On 17 Nov 2016, at 03:05, Roman Shpount wrote: > > > > Adding ICE group to this message. > > > > The approach always was that tcp candidates can potentially go only as fa= r > as SBC and then be terminated by UDP transport. Because of this everythin= g > transmitted over tcp candidate was still considered to be transmitted ove= r > the unreliable out-of-order transport. It is also assumed that candidates > can switch from UDP to TCP based candidate during nomination. This is why= , > for instance, we run DTLS with RFC4571 framing over tcp candidates, not > TLS. Because of this I always thought that ICE is UDP first with addition= al > TCP transports for situation when UDP will not work. So, as a result, I > think ICE-bis should specify that UDP MUST be supported and default > candidate MUST be UDP. ICE SDP can reflect this, but I think this is the > underlying protocol requirement. > > > > I also wanted to add that BFCP needs to examine how ICE support is > implemented by this protocol. I think it is not covered in the current > drafts. I also think I do not think it is possible for TCP/BFCP to run ov= er > ICE. On the other hand UDP/DTLS/BFCP and TCP/DTLS/BFCP would trivial base= d > on current DTLS work. > > > > Regards, > > _____________ > Roman Shpount > > > > On Wed, Nov 16, 2016 at 8:44 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > I have no problem with Roman=E2=80=99s must-support-UDP suggestion. I gue= ss the > question is whether the BFCP folks could accept that. Cullen did say that > TCP-based BFCP deployments have been around for a decade. But, do they > support ICE? > > > > If we decide to move forward with such approach, we need to ask ourselves > whether must-support-UDP should be an ICE requirement (in which case the > suggestion should be brought to the ICE WG) or whether it should only be = an > ICE-using-SIP-SDP requirement. > > > > Regards, > > > > Christer > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Roman > Shpount > *Sent:* 17 November 2016 00:52 > *To:* mmusic@ietf.org > *Subject:* [MMUSIC] m=3D line protocol in case of ICE > > > > Hi All, > > > > I just wanted to return to the m=3D line protocol issue that Christer rai= sed > during the last MMUSIC session. > > > > All the ICE implementations I've seen are primarily UDP based with suppor= t > for tcp host candidates which are primarily used to connect to end points > on public IP. If all ICE implementations are continue to be primarily UDP > based, then the simplest solution would be to require UDP support when an= y > given protocol is implemented over ICE. DTLS and RTP are already primaril= y > UDP based so this is a non-requirement. Even more, all protocols that are > implemented on top of ICE must assume that underling transports (includin= g > tcp candidates) are unreliable, since candidate pair can change at any ti= me > between reliable and unreliable transports, so this makes them different > from protocols implemented on plain TCP or TLS. > > > > So the first question I wanted to ask is anybody interested in TCP only > ICE implementation where the protocol running on top of such implementati= on > relies on the reliable delivery of underlying messages? By this I mean, > does anybody wants implement TCP based ICE, with simultaneous open, > reflexive and relay candidates in such a way that ICE implementation will > run from behind NAT without ever needing a UDP candidate? > > > > I understand that BFCP was used for a long time, but I do not think > TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I think only UDP/BFCP= , > UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE. > > > > I think both rfc4582bis and rfc4583bis need a careful review and > additional sections that describe ICE considerations. I think the most > obvious thing would be to specify that ICE can only be supported by > UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which cas= e > RFC4571 is used when tcp candidates are used. Furthermore, when tcp > candidate is selected with UDP/BFCP transport, it is not the same thing a= s > using TCP/BFCP and will need a different transport tag (something like > TCP/UDP/BFCP). Alternatively we can require that only secure versions of > BFCP are used with ICE and only allow ICE usage for UDP/DTLS/BFCP and > TCP/DTLS/BFCP. > > > > To conclude, I would argue that the simplest solution would be that for > all protocols implemented on top of ICE, UDP MUST be supported and defaul= t > candidates MUST be UDP based. This avoids building uncomfortable artifici= al > constructs to avoid ICE mismatch and requires minimal changes to existing > specifications. > > > > Regards, > > _____________ > Roman Shpount > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > > --001a113ce4763a35620541e9d344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christer,

I think this is another way a= round -- BFCP would have to use RFC 4571 framing when using tcp candidates.=

There is deployed equipment (SBC) that rely on th= e fact that RFC 4571 framing is used by tcp candidates in ICE. I am not sur= e there are ICE implementations of BFCP. I think new implementation should = be updated to comply with existing standards, not another way around.
=

Can someone provide some insight regarding BFCP with UD= P and ICE implementation? Are there implementations of either? I see the RF= C for TCP/BFCP, but it looks like UDP/BFCP and BFCP with ICE only exist in = drafts.

My proposal either to limit ICE support to= UDP/DTLS/BFCP and TCP/DTLS/BFCP, or define new transport tag DBFCP (datagr= am BFCP), and define ICE support for UDP/DBFCP and TCP/DBFCP, where UDP ver= sion of BFCP is used over udp and tcp ICE candidates, with =C2=A0RFC 4571 f= raming used in case of tcp candidates.

If this is = done, we can make UDP/DTLS/BFCP MUST implement if ICE is supported for encr= ypted (and UDP/DBFCP for non-encrypted), make default candidate UDP, and=C2= =A0all the ICE problems disappear.=C2=A0

Not sure = about the current state of MSRP and ICE, but I do not think there are any i= mplementations of it. Probably the best way to implement it now would be ov= er datachannel or quick.

Regards,

_____________
Roman Shpount

On Mon, Nov 21, 2016 at 4:25 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

Hi Roman,

=C2=A0

Good catch.

=C2=A0

That basically means that bfcpbis wou= ld have to document the usage of framing for BFCP-TCP =E2=80=93 assuming th= ey want BFCP-TCP to work with ICE.

=C2=A0

I assume the same applies to MSRP (wh= en not using an MSRP relay).

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">=C2=A0

From: = Roman Shpount [mailto:roman@telurix.com]
Sent: 21 November 2016 01:23
To: Alan Ford <alan.ford@gmail.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>; mmusic@ietf.org; ice@ietf.org; bfcpbis@ietf.org
Subject: Re: [MMUSIC] m=3D line protocol in case of ICE

=C2=A0

Hi All,

=C2=A0

I just wanted to add to my previous email, that acco= rding to RFC 6544=C2=A0protocols running over tcp candidates MUST use =C2= =A0RFC 4571 framing (https://tools.ietf.org/html/rfc6544#section-1= 0.1). This means that BFCP running over tcp candidate is not TCP/BFCP and will r= equire a different transport tag.

=C2=A0

Regards,


_____________
Roman Shpount

=C2=A0

On Thu, Nov 17, 2016 at 9:13 PM, Roman Shpount <<= a href=3D"mailto:roman@telurix.com" target=3D"_blank">roman@telurix.com= > wrote:

Hi All,

=C2=A0

There are three comments I wanted to make regarding = general nature of all existing protocols designed to work ICE=

=C2=A0

1. Protocols running on top of ICE assume that regar= dless what candidate pair is used, including tcp candidates, the underlying= network transport is unordered and unreliable. During nomination, includin= g continuous nomination, candidate pairs can switch, including switching from udp to tcp or from tcp to udp. = This typically means that protocol re-transmit timers are operational, pack= ets are re-ordered at the protocol level, and =C2=A0UDP-friendly packet siz= es are used even when packets are sent over tcp candidates. For instance DTLS and SCTP re-transmit timers, reorde= ring, and fragmentation support are still running when tcp candidates are u= sed.

=C2=A0

2. Protocols do not assume that particular candidate= network transport runs all the way from origination to final destination o= f the protocol packets. For instance there are SBC which only handle ICE. T= hese SBC run the ICE state machine and then transmit the underlying protocol data to the final destination us= ing public IP. Because of this, it is not unusual for RTP to run over tcp c= andidate until SBC and then run over UDP to the final destination. This is = one more reason why re-transmit timers and other mechanisms used to deal with UDP are still running over t= cp candidates.

=C2=A0

3. I am not aware of any current protocol running ov= er ICE tcp candidates which is not using RFC4571 framing. For instance DTLS= could have been implemented using DTLS protocol framing without RFC4571 ov= er tcp candidates, but this was not the case. This is partially done to simplify implementation of SBC which t= erminate ICE and transmit protocol data using UDP. By using RFC 4571 framin= g, SBC can packetize/de-packetize data transmitted over tcp candidates with= out knowing protocol details.

=C2=A0

To conclude, up until this point ICE tcp candidates = were not treated as reliable transport and served simply as another way to = transmit UDP packets through firewalls. Because of this, I would argue that= BFCP running over tcp candidate is not the same as TCP/BFCP, in the same way as DTLS running over tcp candida= te is not TLS.

=C2=A0

I would also argue that any protocol running over IC= E is, in essence, a UDP based protocol, using tcp candidates only as a fall= back mechanism for firewall traversal, same way as when data is relayed ov= er TURN TCP, it is still considered sent over UDP at the protocol level.

=C2=A0

If ICE group agrees, I think this should be document= ed by saying that UDP is a MUST implement for any protocol using ICE and th= at default candidate should be UDP based.

=C2=A0

Regards,

_____________
Roman Shpount=

=C2=A0

On Thu, Nov 17, 2016 at 8:14 PM, Alan Ford <alan.ford@gmail.com= > wrote:

Adding bfcpbis.

=C2=A0

You raise a good point Roman - there=E2=80=99s no de= finition of how to actually use ICE with BFCP at the protocol level - this = only came up in some very late reviews of 4582bis. The initial suggestion w= as to use the same text as in=C2=A0draft-ietf-mmusic-sctp-sdp-19, but it then raised the point that, given BFCP does not have a MTI protocol= , if the offerer supported both they would include their preferred option, = but if the receiver supported the other variant, there=E2=80=99s no way to = immediately negotiate that without a re-INVITE.

=C2=A0

Christer=E2=80=99s suggestion to relax the requireme= nt that the m-line protocol in the answer=C2=A0matches one of the ICE candidates would support t= he case where the offerer supports both but prefers UDP, but the answerer o= nly supports TCP. Although no implementations currently do ICE here, this r= elaxation would leave the door open to gaining this negotiation flexibility in bfcpbis implementations. There see= ms no reason to have this requirement applied to the answer in the first pl= ace.

=C2=A0

I don=E2=80=99t understand the comment about SBCs; t= oday, tcp candidates are used for media and data channels end-to-end in Web= RTC, to name but one implementation.

=C2=A0

Regards,

Alan

=C2=A0

On 17 Nov 2016, at 03:05, Roman Shpount <roman@telurix.com> w= rote:

=C2=A0

Adding ICE group to this message.

=C2=A0

The approach always was that tcp candidates can pote= ntially go only as far as SBC and then be terminated by UDP transport. Beca= use of this everything transmitted over tcp candidate was still considered = to be transmitted over the unreliable out-of-order transport. It is also assumed that candidates can switch from= UDP to TCP based candidate during nomination. This is why, for instance, w= e run DTLS with RFC4571 framing over tcp candidates, not TLS. Because of th= is I always thought that ICE is UDP first with additional TCP transports for situation when UDP will not w= ork. So, as a result, I think ICE-bis should specify that UDP MUST be suppo= rted and default candidate MUST be UDP. ICE SDP can reflect this, but I thi= nk this is the underlying protocol requirement.

=C2=A0

I also wanted to add that BFCP needs to examine how = ICE support is implemented by this protocol. I think it is not covered in t= he current drafts. I also think I do not think it is possible for TCP/BFCP = to=C2=A0run over ICE. On the other hand UDP/DTLS/BFCP and TCP/DTLS/BFCP would trivial based on current DTLS work.<= u>

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0

On Wed, Nov 16, 2016 at 8:44 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

I have no problem with Roman=E2=80=99= s must-support-UDP suggestion. I guess the question is whether the BFCP folks could accept that. Cullen did say that TCP-based BFCP deployments ha= ve been around for a decade. But, do they support ICE?=

=C2=A0

If we decide to move forward with suc= h approach, we need to ask ourselves whether must-support-UDP should be an ICE requirement (in which case the suggestion should be broug= ht to the ICE WG) or whether it should only be an ICE-using-SIP-SDP require= ment.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = mmusic [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 17 November 2016 00:52
To: mmusic@ietf= .org
Subject: [MMUSIC] m=3D line protocol in case of ICE=

=C2=A0

Hi All,

=C2=A0

I just wanted to return to the m=3D line protocol is= sue that Christer raised during the last MMUSIC session.

=C2=A0

All the ICE implementations I've seen are primar= ily UDP based with support for tcp host candidates which are primarily used= to connect to end points on public IP. If all ICE implementations are continue to be primarily UDP based, then the simplest solution would b= e to require UDP support when any given protocol is implemented over ICE. D= TLS and RTP are already primarily UDP based so this is a non-requirement. E= ven more, all protocols that are implemented on top of ICE must assume that underling transports (including= tcp candidates) are unreliable, since candidate pair can change at any tim= e between reliable and unreliable transports, so this makes them different = from protocols implemented on plain TCP or TLS.

=C2=A0

So the first question I wanted to ask is anybody int= erested in TCP only ICE implementation where the protocol running on top of= such implementation relies on the reliable delivery of underlying messages? By this I mean, does anybody wants implement TCP b= ased ICE, with simultaneous open, reflexive and relay candidates in such a = way that ICE implementation will run from behind NAT without ever needing a= UDP candidate?

=C2=A0

I understand that BFCP was used for a long time, but= I do not think TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I think= only UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE.=C2=A0

=C2=A0

I think both=C2=A0rfc4582bis and rfc4583bis need a c= areful review and additional sections that describe ICE considerations. I t= hink the most obvious thing would be to specify that ICE can only be supported by UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It wil= l also mean in which case RFC4571 is used when tcp candidates are used. Fur= thermore, when tcp candidate is selected with UDP/BFCP transport, it is not= the same thing as using TCP/BFCP and will need a different transport tag (something like TCP/UDP/BFCP). Alt= ernatively we can require that only secure versions of BFCP are used with I= CE and only allow ICE usage for UDP/DTLS/BFCP and TCP/DTLS/BFCP.<= /u>

=C2=A0

To conclude, I would argue that the simplest solutio= n would be that for all protocols implemented on top of ICE, UDP MUST be su= pported and default candidates MUST be UDP based. This avoids building uncomfortable artificial constructs to avoid ICE mism= atch and requires minimal changes to existing specifications.=

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0

_______________________________________________ mmusic ma= iling list
mmusic@ietf.org https:/= /www.ietf.org/mailman/listinfo/mmusic

=C2=A0

=C2=A0

=C2=A0


--001a113ce4763a35620541e9d344-- From nobody Tue Nov 22 14:15:45 2016 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 5E073129BA1 for ; Tue, 22 Nov 2016 14:15:38 -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, 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=aliax-net.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 M4OfzC3TkXSx for ; Tue, 22 Nov 2016 14:15:37 -0800 (PST) Received: from mail-wj0-x22c.google.com (mail-wj0-x22c.google.com [IPv6:2a00:1450:400c:c01::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 21BA7129B91 for ; Tue, 22 Nov 2016 14:15:35 -0800 (PST) Received: by mail-wj0-x22c.google.com with SMTP id xy5so49965058wjc.0 for ; Tue, 22 Nov 2016 14:15:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=l3PKl8t2B6Tv7rUn2nEqupK0WsZ0RGpPtF5UXnDPMy8=; b=ZxHwnHIqvMdSA5AoqmN6VBzn8LWFcaAabSJZ0bMuh1YQW9jCZ7mgqF9GFX/ENmdQ2U otuuZAzuniA7CAux/eImOIgbDR0G9aae2iah+ZVimAl8nqh/MjgdkX4M533J/OQ9K1rM zU87VvhMZnWWdS2GhF7JbkNpSIAItjU8QDIlhDyhxrzSS/8PbVecR+vF6AtSXWeaZeIx WWMdBB++6TmmqwiezkQd+1AXDq3XxI6nyNp8F9/zAhQTvXqmKAF+4Kn1B+1PyNp1Tg4C 8l6BiVaB+pES5TPmCo1qXKlPzLvDN91/ReptEBlZ1nYPzqLJ00nglxTWGILbZ3e1EBkJ JMBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=l3PKl8t2B6Tv7rUn2nEqupK0WsZ0RGpPtF5UXnDPMy8=; b=DQFtAS2lg7ktCEVjKrF8XkbsjC21BqTxj8sSEycL+23JAUiKAQ4i1DZ91dOeFUlrVH uHsz11ahFhlOuXImy8I+ry5v4IqNHtLpZvPs7Vbzm3ZoOvl/WOpLEK1Xp3xgkFV4anlb gl/9Z7zvY6lq+Z87Rxd9jD9kYVnrqTINwFhwcvI4bmXOzSJMh8CyTNQ9k28z3BZuKjyf r3cqX/naQWRqaQIRyAhsXkKzE1iS/hhZTtpB4/PXefE6xziPTB4LWqTPGzz6gr3AL3pD GZxjZRNSf8QZSOmbwKZ5L4UEpDPAWufXSakFwBBVTAYYZHELdFWuXICqtG1XQ+1KkSbk pT4A== X-Gm-Message-State: AKaTC01U+XEQzr7Zj4JtbgkctlqA/idTRG36Hj3jFcGtVHYnIVAHNoAQEtu8rpzBRFZ9g8lPSosX8gWzAnXPEA== X-Received: by 10.194.113.2 with SMTP id iu2mr449442wjb.32.1479852933634; Tue, 22 Nov 2016 14:15:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.146.48 with HTTP; Tue, 22 Nov 2016 14:15:13 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BE823C9@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 22 Nov 2016 23:15:13 +0100 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ice@ietf.org" , "bfcpbis@ietf.org" , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [Ice] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 22:15:38 -0000 2016-11-22 21:43 GMT+01:00 Roman Shpount : > Can someone provide some insight regarding BFCP with UDP and ICE > implementation? Are there implementations of either? I bet there is no one implementation. In fact, I implemented "JSFCP" (JSON version of BFCP) over WebSocket. > Not sure about the current state of MSRP and ICE, but I do not think ther= e > are any implementations of it. Of course not. And the fact that there are MSRP relays (by spec) makes it even more difficult to move to more efficient solutions such as "anything" over UDP/ICE/DTLS/SCTP or similar. --=20 I=C3=B1aki Baz Castillo From nobody Tue Nov 22 21:17:00 2016 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 7D3E4129488; Tue, 22 Nov 2016 21:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4a-w48SYCkbq; Tue, 22 Nov 2016 21:16:49 -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 57D4F129401; Tue, 22 Nov 2016 21:16:48 -0800 (PST) X-AuditID: c1b4fb30-96c1b98000001942-7c-5835263e18f7 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id E3.D6.06466.E3625385; Wed, 23 Nov 2016 06:16:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0319.002; Wed, 23 Nov 2016 06:16:05 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Roman Shpount Thread-Topic: [MMUSIC] m= line protocol in case of ICE Thread-Index: AQHSQFwT8S0xdJKeakq1+K6kpgEs7aDcZjMAgAAHVICAAXMfAIAAEJmAgASHdQCAALfl8IACQBUAgAAZoICAAIi5AA== Date: Wed, 23 Nov 2016 05:16:05 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BE823C9@ESESSMB209.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.6.9.160926 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <67D824805D603D4AA6683DEC18690CA1@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM+Jvja6dmmmEwbzLyhb/1h1lspi+z8bi 24Vai6nLH7NYzLgwldmB1eNcw3t2jyVLfjJ53JpSEMAcxWWTkpqTWZZapG+XwJWx/cMF1oK3 zBXNvz6zNjA2MXcxcnJICJhIHPjwkaWLkYtDSGA9o8TuQ4fZIZzFjBLHDm9m7WLk4GATsJDo /qcN0iAiECdxb/t0NhCbWSBf4sjPpywgJcICphITrktBlJhJbF64hBHCzpK4uHoNK4jNIqAq sWPaXrC9vALWEvOuNTBCrHrHItE5fyYLSIJTIFBibuMvsGZGATGJ76fWMEHsEpe49WQ+E8TR AhJL9pyHekBU4uXjf2BnigroSay5HwYRVpT4+GofI0SrnsSNqVOgTraWOLbtN5StLbFs4Wuo ewQlTs58wjKBUXwWkm2zkLTPQtI+C0n7LCTtCxhZVzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWW bGIExuPBLb8NdjC+fO54iFGAg1GJh7cg1iRCiDWxrLgy9xCjBAezkghvrJxphBBvSmJlVWpR fnxRaU5q8SFGaQ4WJXFes5X3w4UE0hNLUrNTUwtSi2CyTBycUg2MRSU3P4mLpvab+T/6cD/0 Ro3UoX71D6JF3d82aWz1XbkneWkVq2LiwtxT76bn7HmbkM958fiF+JkHJkm9etAlHB5vUDlX K7yMyULA3eTvibS8ulMfO5/vcmW5nRGUaXZ4qa3m62c/yh2ik9fyScb+Cv+/57LIHN7fOh2f X1np/P07++z0rmc1SizFGYmGWsxFxYkAXgcm4sMCAAA= Archived-At: Cc: "bfcpbis@ietf.org" , "mmusic@ietf.org" , "ice@ietf.org" Subject: Re: [Ice] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 05:16:50 -0000 Hi, >> Not sure about the current state of MSRP and ICE, but I do not think >>there >> are any implementations of it. > >Of course not. And the fact that there are MSRP relays (by spec) makes >it even more difficult to move to more efficient solutions such as >"anything" over UDP/ICE/DTLS/SCTP or similar. The deployments I am aware of don=B9t use relays. Anyway, *IF* someone want= s to define ICE support for MSRP, he/she can =B3write a draft=B2 :) Regards, Christer From nobody Tue Nov 22 23:55:34 2016 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 DE10F129568 for ; Tue, 22 Nov 2016 23:55: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 1CPj3wg10Ekz for ; Tue, 22 Nov 2016 23:55:30 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F8312948A for ; Tue, 22 Nov 2016 23:55:30 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id 3so3368660pgd.0 for ; Tue, 22 Nov 2016 23:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=/CsG6kAk+MJshSm82v3VZHr+lzy2Wvz9vzi8+yO3KeM=; b=C+HJJvxmnMHq3uti3rLFz8FF1rcUvQdJh3Pt5GeIE6/QHGAyTWaxlS8Bq/frxvjrpw uiTSQvvdZWVnterDcICW+ZthxT1g5IKXzIv94DtqaH3yAsb0uigERiHq1xv10oAQRHBC 8SRnEmVnRVmeUCKlFU+fDdo4a1CcBsZckhKU0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=/CsG6kAk+MJshSm82v3VZHr+lzy2Wvz9vzi8+yO3KeM=; b=NFtqhmU8QZCpYoTUbt9tCbH1Kb/Egaj5uJQGhc1EogTiG6HJEdaXaQbH91d46LuY38 pTpqNQeHnV45dUaZZ+B406r6Wd0902Me8j0lRu7i33CU613lAa+HF4Ud0VCpucs3+alm guACBNUebl0Exkxgc2aKN1mo+U1pRgTIXG0aqhqriHqn4tTBvYk6jAd0oxF4LbAGebrI M5jfWasuOmuxqjiwF1b9zS47dtudt6G2nfDAxWAt8Y+OpMPhP83aAwAM7ZtoN7YqnGqP mbnBLYnJG1MIAtwEfGT/NOby38uvO8SWOE+fhe2U+p27zWxb+eCXFVTQhEkXZL9Qk0Cw C4Ig== X-Gm-Message-State: AKaTC00q+cvdFiw4PkhRzRck9e3ym2MX7c9kAwwv9cLcoSUeEO0Yw9ZMI8KgOHj/9uY76qW3 X-Received: by 10.84.134.3 with SMTP id 3mr4013301plg.90.1479887729416; Tue, 22 Nov 2016 23:55:29 -0800 (PST) Received: from ?IPv6:2601:647:4601:ec84:70ce:d492:84d1:7849? ([2601:647:4601:ec84:70ce:d492:84d1:7849]) by smtp.gmail.com with ESMTPSA id p67sm36038354pfb.2.2016.11.22.23.55.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2016 23:55:28 -0800 (PST) From: Nils Ohlmeier Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Tue, 22 Nov 2016 23:55:27 -0800 To: "ice@ietf.org" X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [Ice] Missing amplification attack in RFC 5245 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 07:55:33 -0000 Hi, After reading about the STUN amplification attack described in section = 13.4.1 of 5245bis I think that paragraph is actually missing a small = variation. My reading of the section is that the inside attacker uses = the signaling to send bogus candidates to the responding ICE agent. I = think even easier would it be for an inside attacker to simply send tons = of fake check requests from the transport address of the victim. If the = responding ICE agent receives these check requests (through NAT and/or = firewall) it will create peer reflexive candidates, which causes binding = response to be send to the victim. Followed by triggered check requests, = which get highest priority on the next free cycles for new check = requests. Agents SHOULD limit the total number of connectivity checks they perform to 100. Additionally, agents MAY limit the number of candidates they'll accept. Theoretically an ICE implementation which limits the over all number of = connectivity checks to 100 should limit the peer reflexive amplification = attack as well. But I could easily see that implementers tried to = implement the recommended protection here by limiting the number of = candidates received via signaling, which would then be bypassed by this = attack. Best Nils Ohlmeier From nobody Wed Nov 23 00:28:29 2016 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 188AE129478 for ; Wed, 23 Nov 2016 00:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsQUgAxkfELv for ; Wed, 23 Nov 2016 00:28:27 -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 E1E631293D8 for ; Wed, 23 Nov 2016 00:28:25 -0800 (PST) X-AuditID: c1b4fb3a-98fff70000007918-58-58355326db37 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 4E.4F.31000.62355385; Wed, 23 Nov 2016 09:28:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0319.002; Wed, 23 Nov 2016 09:28:22 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: Coming soon: draft-5245bis-06 Thread-Index: AQHSRWOMf/0yBF5kqkCeZ8zvYtUw7w== Date: Wed, 23 Nov 2016 08:28:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D45B21C21369Achristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2K7va5GsGmEwY1eUYtvF2odGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJXRdm4hY0Evb8WpDyeYGhgfcHcxcnJICJhIvHh7nhHEFhJYxygx c2ZYFyMXkL2YUaLlwGz2LkYODjYBC4nuf9ogNSICihIzW54xg4SFBdQkbt0ohQhrSxzoOssK YetJbLrwhQXEZhFQlVi87i2YzStgLTFn4WawVYwCYhLfT61hArGZBcQlbj2ZzwRxjoDEkj3n mSFsUYmXj/+xgqwSBZq55n4YiCkBdMHyfjkQk1kgQeLRVm+I4YISJ2c+YZnAKDQLycxZCFWz kFRBlOhILNj9iQ3C1pZYtvA1M4x95sBjJgjbWqL1zBV2ZDULGDlWMYoWpxYX56YbGemlFmUm Fxfn5+nlpZZsYgRGx8Etv612MB587niIUYCDUYmHtyDWJEKINbGsuDL3EKMEB7OSCK94kGmE EG9KYmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYw1Vt9Phkmu tp5qn/FL+o7OXb9gjbdCtRMTjxm6cH9nuiiw4hxjZoQvW5wZP+Pqn9O+PHdI9Vb72rvPtDfR tPP3pm/b+WX4Nfg/3ueWz56W7mccd4Nltf8u9ZuvBZgiLjb+3Oz9keW0HM/f/m8vj4vsPdhQ +nSX+ONte5VDb/cIa0q3W78NLFZiKc5INNRiLipOBAC55HkIigIAAA== Archived-At: Subject: [Ice] Coming soon: draft-5245bis-06 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 08:28:28 -0000 --_000_D45B21C21369Achristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I intend to submit a new version of draft-5245bis soon, which will implemen= t the following pull requests: https://github.com/ice-wg/rfc5245bis/pull/23 https://github.com/ice-wg/rfc5245bis/pull/22 (Contains technical changes!) https://github.com/ice-wg/rfc5245bis/pull/21 Regards, Christer --_000_D45B21C21369Achristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I intend to submit a new version of draft-5245bis soon, which will imp= lement the following pull requests:

https://githu= b.com/ice-wg/rfc5245bis/pull/22 (Contains technical changes!)

Regards,

Christer
--_000_D45B21C21369Achristerholmbergericssoncom_-- From nobody Wed Nov 23 00:31:57 2016 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 00ABB129634 for ; Wed, 23 Nov 2016 00:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsxMSmFrl0La for ; Wed, 23 Nov 2016 00:31:55 -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 52C8C129635 for ; Wed, 23 Nov 2016 00:31:54 -0800 (PST) X-AuditID: c1b4fb30-96c1b98000001942-79-583553f838f2 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 1C.6F.06466.8F355385; Wed, 23 Nov 2016 09:31:52 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0319.002; Wed, 23 Nov 2016 09:31:52 +0100 From: Christer Holmberg To: Nils Ohlmeier , "ice@ietf.org" Thread-Topic: [Ice] Missing amplification attack in RFC 5245 Thread-Index: AQHSRV77+NPfKTfsdUiNWhsitoDJCaDmP7QA Date: Wed, 23 Nov 2016 08:31:51 +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.6.9.160926 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-ID: <7BF0B01BBF71414CBE3CC746E2361F71@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbFdRfdHsGmEwbafOhbfLtRaXJ83mdGB yWPJkp9MHn0HulgDmKK4bFJSczLLUov07RK4Mg7N+MJYsJW9YtoPyQbGX6xdjJwcEgImEh0r JrKA2EIC6xglLl7I7mLkArIXM0r8nN4AlODgYBOwkOj+pw1SIyLgIfF+9SVmEFtYwFqiY2sP WImIgI3EmdZciBIjiZajKxlBbBYBVYn+6f/YQWxeoPK/73cyQqyyk3h9qZEdpJVTwF5if78v SJhRQEzi+6k1TCA2s4C4xK0n85kgrhSQWLLnPDOELSrx8vE/VpBWUQE9iTX3wyDCihJXpy+H atWRWLD7ExuEbS1xaPEdVghbW2LZwtfMENcISpyc+YRlAqPYLCTbZiFpn4WkfRaS9llI2hcw sq5iFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIylg1t+G+xgfPnc8RCjAAejEg9vQaxJhBBr YllxZe4hRgkOZiURXvEg0wgh3pTEyqrUovz4otKc1OJDjNIcLErivGYr74cLCaQnlqRmp6YW pBbBZJk4OKUaGOvPlfs8f/uXf1OQmUY4/3refVdipngod28v2ps2aZu93o+Vlye2ZRp06R+J 6FO+Jzr1msp+Z/0+t3WisuLHvJNuPkxYV5UhlnCw9j/T/WsKrke4f6Yk3jVe+W1VzJevIeHf Xk0KPCKXX/B/samfza0pHz5r9NW/rPLTymxqvJ8v9XSOtrZvgRJLcUaioRZzUXEiAEU46T2h AgAA Archived-At: Subject: Re: [Ice] Missing amplification attack in RFC 5245 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 08:31:56 -0000 Hi, >After reading about the STUN amplification attack described in section >13.4.1 of 5245bis I think that paragraph is actually missing a small >variation. My reading of the section is that the inside attacker uses the >signaling to send bogus candidates to the responding ICE agent. I think >even easier would it be for an inside attacker to simply send tons of >fake check requests from the transport address of the victim. If the >responding ICE agent receives these check requests (through NAT and/or >firewall) it will create peer reflexive candidates, which causes binding >response to be send to the victim. Not only that - currently, as was indicated in another e-mail, MEDIA can also be sent. My suggestion would be to say that media must only be sent on valid candidate pairs. Now, that may not prevent the attack, but at least it requires a little more work as a pair has to be nominated. Regards, Christer From nobody Wed Nov 23 01:58:51 2016 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 3BC751299B8 for ; Wed, 23 Nov 2016 01:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 XSQKA6u8zDa0 for ; Wed, 23 Nov 2016 01:58:44 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74A1129AD7 for ; Wed, 23 Nov 2016 01:58:37 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id t79so15758077wmt.0 for ; Wed, 23 Nov 2016 01:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Bg972yPZM83TuMN93G4BVhIrPJK89zFmtnMmVAlpqKc=; b=I8qrU4HplY0gsuGf5IhUXGins5uD6vW+/zWc6P/CQYmLha/8fbFQ/9mzhUkVdjLNGm A4x+MLS+ApZaoCT82FkGG1Yk5J/mrBoxGEoWk8AOBGN2xp82iWDFsYvq3VKnO29xwLfV KAB2F5sqhBTzUuzNEDJ1odbNdiyjRp157w+kpdoub9+U2LikgnVjUkoRyBkeX623vvd+ d63hMPBID7n14+3x50NoYIXNIZr2XtTje3GFC/z+eVQ00SW7gSIBw+DsJ4FTwopBBop+ 7iiSEjrBNNj/r/JEo0I+HdP6MP7d5BluJBcpbNQJqwO1/sKh96MlDHHPAkZPHpY9/I5O W1SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Bg972yPZM83TuMN93G4BVhIrPJK89zFmtnMmVAlpqKc=; b=Qo6JBOp7Y81LKxWrWQWvk3It6mf16ONjovx/XZNq7yMDKqRwRZjYxlyIXax3BBifoy d4VhO4v84A87KSPTb2qKCNZvM2cGnmcBhrWK6n9Z1A8PRvV+KaOXxHGtnLA6iMZ3xlVm ugSQ/Gg0cJeNFJyWGNLTunaNBkE+15RQYUR4CiZWbtwVNJi2A8u3iUSZeScBuJvucns6 4SWncWVJpyY72+/8atEyORTVqBtOvXxzxd1udYKWRO70fzCMiMw996K2V8wQpnsW6dQ6 sG0BYDzAAJaUDNtJOSwjbl59nnYW+o5n6dyDkluJJ5HRo8R2LJecOwVZebPj82tgH0Q3 UNXA== X-Gm-Message-State: AKaTC01KAB5KoM80jzPMKEKaE/jRUzM9ceBM7g5ZrwGzGy9z3gQ5JqIfIVyEduLevaCFxOkbPnkioAUSBUjLCQ== X-Received: by 10.28.51.211 with SMTP id z202mr6838202wmz.125.1479895116251; Wed, 23 Nov 2016 01:58:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.146.48 with HTTP; Wed, 23 Nov 2016 01:58:15 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BE823C9@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 23 Nov 2016 10:58:15 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "bfcpbis@ietf.org" , "mmusic@ietf.org" , Roman Shpount , "ice@ietf.org" Subject: Re: [Ice] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 09:58:46 -0000 2016-11-23 6:16 GMT+01:00 Christer Holmberg : >>Of course not. And the fact that there are MSRP relays (by spec) makes >>it even more difficult to move to more efficient solutions such as >>"anything" over UDP/ICE/DTLS/SCTP or similar. > > The deployments I am aware of don=C2=B9t use relays. Yep. I'm pretty sure those deployments don't use Outbound/GRUU (RFC 5626/5627) nor MSRP relay servers (RFC 4976). Probably they all use their own private SIP extensions to handle TCP based connections and probably they implement middle-boxes that prevent SIP body encryption (draft-ietf-simple-msrp-sessmatch) because those magic middle-boxes need to mangle the SDP for things to work in walled gardens. However, the IETF is supposed to do stuff for the real Internet, and there are still good guys building real stuff on top of real Internet standards: http://msrprelay.org/ --=20 I=C3=B1aki Baz Castillo From nobody Wed Nov 23 11:55:42 2016 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 012A212A37C for ; Wed, 23 Nov 2016 11:55:41 -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 WMDjZgCJMugq for ; Wed, 23 Nov 2016 11:55:38 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BB512A31B for ; Wed, 23 Nov 2016 11:55:37 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id f188so9281967pgc.3 for ; Wed, 23 Nov 2016 11:55:37 -0800 (PST) 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=mDegsSMAXEXUvXIBPgAaweknyPv/oPhwSi5XeNqjZOU=; b=QydMy20ZHqUEmSodDM6rnlg/YUXdQw6eIlNyhUb0B5o3ezye3ZoDT2MLFHWEhx0fSR hcUQErU/sFHMzNrWMy5MpEHsMo1CovoOXFhFFF6kuf2/UzqIKiIFcqEg040x+OBgIa1x HY/V7/MQ4APRAyzf5J+lMu9KNqeDPRMrgRcFw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mDegsSMAXEXUvXIBPgAaweknyPv/oPhwSi5XeNqjZOU=; b=e0CqiUGkd5sGYMq1f/T/qjqPx0NlRaNSV3m6FHDKgzL4CX2qswmDfQHLyql3yWXetX jJh0r5pwKGoKamcCRIkQzBr15kHMY6UJsu6fkSwu0sWplhNtl9y6n3esRv9r3G+MDcni 9xSHiRo1g/zwCj30TBLtZok6GqsjLyE4zipj8iPRF0VFgl17CLW+IZh9YO/1nvGkCDAz eg6qckiwLsBZLPA+r3xZBpoKf0PF1n6aA5Al555Q/ORQW9fuXjowq+w9Q89Hy0U8Ya2X cmbNHzUZRAr8mRj0AUo/XaDctBF3PbdHIfNPNHdGKiHfaCe3XXNOtkO+2xUIZJ4cMta4 X9ZA== X-Gm-Message-State: AKaTC004LCYzeq86+EKfVtfvSOOG2uQFVt8j1ltSbBVH7kahhCuWWpvJpm4iqxtB0qLHd73c X-Received: by 10.84.143.162 with SMTP id 31mr10198922plz.2.1479930937439; Wed, 23 Nov 2016 11:55:37 -0800 (PST) Received: from ?IPv6:2620:101:80fc:224:69d5:5cd9:d9be:f882? ([2620:101:80fc:224:69d5:5cd9:d9be:f882]) by smtp.gmail.com with ESMTPSA id p26sm36737234pgn.11.2016.11.23.11.55.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Nov 2016 11:55:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Nils Ohlmeier In-Reply-To: Date: Wed, 23 Nov 2016 11:55:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2E094E44-EB86-48B5-89D4-167FCC624317@mozilla.com> References: To: Christer Holmberg X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Missing amplification attack in RFC 5245 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 19:55:41 -0000 > On Nov 23, 2016, at 00:31, Christer Holmberg = wrote: >=20 > Hi, >=20 >> After reading about the STUN amplification attack described in = section >> 13.4.1 of 5245bis I think that paragraph is actually missing a small >> variation. My reading of the section is that the inside attacker uses = the >> signaling to send bogus candidates to the responding ICE agent. I = think >> even easier would it be for an inside attacker to simply send tons of >> fake check requests from the transport address of the victim. If the >> responding ICE agent receives these check requests (through NAT = and/or >> firewall) it will create peer reflexive candidates, which causes = binding >> response to be send to the victim. >=20 > Not only that - currently, as was indicated in another e-mail, MEDIA = can > also be sent. Good point. > My suggestion would be to say that media must only be sent on valid > candidate pairs. Now, that may not prevent the attack, but at least it > requires a little more work as a pair has to be nominated. I=E2=80=99m not sure if you are suggesting to require nomination in = general before sending media?! To me it would make sense to not allow sending media over peer reflexive = candidates until they are nominated. But for pairs which have been = learned from signaling the valid status is enough to start sending = media. Although that makes things obviously more complex. This would = also raise the question if another state between =E2=80=98valid=E2=80=99 = and =E2=80=98nominated=E2=80=99 is needed which indicates that sending = media on this pair is permitted. Best Nils= From nobody Wed Nov 23 12:11:15 2016 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 4AC96129B49 for ; Wed, 23 Nov 2016 12:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Er4cDl8bIk7k for ; Wed, 23 Nov 2016 12:11:13 -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 C10DB129678 for ; Wed, 23 Nov 2016 12:11:12 -0800 (PST) X-AuditID: c1b4fb25-aefff70000007ee2-da-5835f7dc8a8c Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id CA.EC.32482.CD7F5385; Wed, 23 Nov 2016 21:11:11 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Wed, 23 Nov 2016 21:11:08 +0100 From: Christer Holmberg To: Nils Ohlmeier Thread-Topic: [Ice] Missing amplification attack in RFC 5245 Thread-Index: AQHSRV77+NPfKTfsdUiNWhsitoDJCaDmP7QAgACr5ICAABM1EA== Date: Wed, 23 Nov 2016 20:11:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BE9E9D1@ESESSMB209.ericsson.se> References: <2E094E44-EB86-48B5-89D4-167FCC624317@mozilla.com> In-Reply-To: <2E094E44-EB86-48B5-89D4-167FCC624317@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM2K7ge7976YRBo0zmCy+Xai1uD5vMqMD k8eSJT+ZPPoOdLEGMEVx2aSk5mSWpRbp2yVwZUycM4u9oEO84t+29SwNjHvEuhg5OCQETCSu /7XsYuTiEBJYxyixqPMHG4SzmFFi9Zo9zCBFbAIWEt3/tEFMEQFNiRMb+UBMZgFFiZd71UBM YQFriWk9VhAFNhJnWnO7GDmBTCeJcx/WMIPYLAKqEgeeTmcBsXkFfCUOX/zCCLFnKaPEws45 YAlOAXuJuetOsILYjAJiEt9PrWECsZkFxCVuPZkPZksICEgs2XOeGcIWlXj5+B8rhK0k0bjk CSvEZZoS63fpQ7QqSkzpfsgOsVdQ4uTMJywTGEVnIZk6C6FjFpKOWUg6FjCyrGIULU4tTspN NzLWSy3KTC4uzs/Ty0st2cQIjIyDW36r7mC8/MbxEKMAB6MSD++HdaYRQqyJZcWVuYcYJTiY lUR4J30DCvGmJFZWpRblxxeV5qQWH2KU5mBREuc1W3k/XEggPbEkNTs1tSC1CCbLxMEp1cDY MqX8epvjyVsPUhWKV78IVo3dfkzu26oYGcGDnedW73zy7/9Cy9mnWy51lTF0F2qadT4UmlR/ IePgGZvYV3Lslz7rR+b9PHJeQ0CAO3yx4YJOTrGNJtd0Z6w466K7qHC1hU5vxETl35dO+ckt 1SyZGD4le/2ePqZtiyXkpLIFIjZskGhhOHNViaU4I9FQi7moOBEARDWEnogCAAA= Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Missing amplification attack in RFC 5245 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 20:11:14 -0000 SGksDQoNCj4+PiBBZnRlciByZWFkaW5nIGFib3V0IHRoZSBTVFVOIGFtcGxpZmljYXRpb24gYXR0 YWNrIGRlc2NyaWJlZCBpbiANCj4+PiBzZWN0aW9uDQo+Pj4gMTMuNC4xIG9mIDUyNDViaXMgSSB0 aGluayB0aGF0IHBhcmFncmFwaCBpcyBhY3R1YWxseSBtaXNzaW5nIGEgc21hbGwgDQo+Pj4gdmFy aWF0aW9uLiBNeSByZWFkaW5nIG9mIHRoZSBzZWN0aW9uIGlzIHRoYXQgdGhlIGluc2lkZSBhdHRh Y2tlciB1c2VzIA0KPj4+IHRoZSBzaWduYWxpbmcgdG8gc2VuZCBib2d1cyBjYW5kaWRhdGVzIHRv IHRoZSByZXNwb25kaW5nIElDRSBhZ2VudC4gSSANCj4+PiB0aGluayBldmVuIGVhc2llciB3b3Vs ZCBpdCBiZSBmb3IgYW4gaW5zaWRlIGF0dGFja2VyIHRvIHNpbXBseSBzZW5kIA0KPj4+IHRvbnMg b2YgZmFrZSBjaGVjayByZXF1ZXN0cyBmcm9tIHRoZSB0cmFuc3BvcnQgYWRkcmVzcyBvZiB0aGUg dmljdGltLiANCj4+PiBJZiB0aGUgcmVzcG9uZGluZyBJQ0UgYWdlbnQgcmVjZWl2ZXMgdGhlc2Ug Y2hlY2sgcmVxdWVzdHMgKHRocm91Z2ggDQo+Pj4gTkFUIGFuZC9vcg0KPj4+IGZpcmV3YWxsKSBp dCB3aWxsIGNyZWF0ZSBwZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGVzLCB3aGljaCBjYXVzZXMgDQo+ Pj4gYmluZGluZyByZXNwb25zZSB0byBiZSBzZW5kIHRvIHRoZSB2aWN0aW0uDQo+PiANCj4+IE5v dCBvbmx5IHRoYXQgLSBjdXJyZW50bHksIGFzIHdhcyBpbmRpY2F0ZWQgaW4gYW5vdGhlciBlLW1h aWwsIE1FRElBIA0KPj4gY2FuIGFsc28gYmUgc2VudC4NCj4NCj4gR29vZCBwb2ludC4NCj4NCj4+ IE15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gc2F5IHRoYXQgbWVkaWEgbXVzdCBvbmx5IGJlIHNl bnQgb24gdmFsaWQgDQo+PiBjYW5kaWRhdGUgcGFpcnMuIE5vdywgdGhhdCBtYXkgbm90IHByZXZl bnQgdGhlIGF0dGFjaywgYnV0IGF0IGxlYXN0IGl0IA0KPj4gcmVxdWlyZXMgYSBsaXR0bGUgbW9y ZSB3b3JrIGFzIGEgcGFpciBoYXMgdG8gYmUgbm9taW5hdGVkLg0KPg0KPiBJ4oCZbSBub3Qgc3Vy ZSBpZiB5b3UgYXJlIHN1Z2dlc3RpbmcgdG8gcmVxdWlyZSBub21pbmF0aW9uIGluIGdlbmVyYWwg YmVmb3JlIHNlbmRpbmcgbWVkaWE/IQ0KDQpOby4NCg0KVGhlIHNwZWMgY3VycmVudGx5IHNheXMg dGhhdCBtZWRpYSBjYW4gYmUgc2VudCBvbiBhIHZhbGlkIHBhaXIsIGFuZCBteSBzdWdnZXN0aW9u IHdvdWxkIGJlIHRvIHNheSB0aGF0IG1lZGlhIHNob3VsZCBhbHNvIG9ubHkgYmUgYWNjZXB0ZWQg b24gYSB2YWxpZCBwYWlyLg0KDQo+VG8gbWUgaXQgd291bGQgbWFrZSBzZW5zZSB0byBub3QgYWxs b3cgc2VuZGluZyBtZWRpYSBvdmVyIHBlZXIgcmVmbGV4aXZlIGNhbmRpZGF0ZXMgdW50aWwgdGhl eSBhcmUgbm9taW5hdGVkLiBCdXQgZm9yIHBhaXJzIHdoaWNoIGhhdmUgYmVlbiBsZWFybmVkIGZy b20gc2lnbmFsaW5nIHRoZSA+dmFsaWQgc3RhdHVzIGlzIGVub3VnaCB0byBzdGFydCBzZW5kaW5n IG1lZGlhLg0KDQpXaGF0IGRvIHlvdSBtZWFuIGJ5ICJzaWduYWxsaW5nIHRoZSB2YWxpZCBzdGF0 dXMiPw0KDQo+QWx0aG91Z2ggdGhhdCBtYWtlcyB0aGluZ3Mgb2J2aW91c2x5IG1vcmUgY29tcGxl eC4gVGhpcyB3b3VsZCBhbHNvIHJhaXNlIHRoZSBxdWVzdGlvbiBpZiBhbm90aGVyIHN0YXRlIGJl dHdlZW4g4oCYdmFsaWTigJkgYW5kIOKAmG5vbWluYXRlZOKAmSBpcyBuZWVkZWQgd2hpY2ggaW5k aWNhdGVzIHRoYXQgPnNlbmRpbmcgbWVkaWEgb24gdGhpcyBwYWlyIGlzIHBlcm1pdHRlZC4NCg0K S2VlcCBpbiBtaW5kIHRoYXQsIGFjY29yZGluZyB0byA1MjQ1YmlzLCB0aGVyZSBpcyBubyBuZWVk IHRvIG5vbWluYXRlIGJlZm9yZSBzZW5kaW5nIG1lZGlhLg0KDQpBbHNvLCBhcyBhIHNpZGUgbm90 ZSwgIm5vbWluYXRlZCIgb25seSBtZWFucyB0aGF0IHRoZSBjb250cm9sbGluZyBlbmRwb2ludCBo YXMgc2V0IHRoZSBub21pbmF0ZSBmbGFnIGluIHRoZSBTVFVOIHJlcXVlc3QgLSBub3QgdGhhdCB0 aGUgY29udHJvbGxlZCBwYWlyIGhhcyBzZW50IGEgU1RVTiByZXNwb25zZS4gT25jZSB0aGUgY29u dHJvbGxlZCBlbmRwb2ludCBoYXMgYWNjZXB0ZWQgdGhlIG5vbWluYXRpb24sIHRoZSBwYWlyIGJl Y29tZXMgInNlbGVjdGVkIiA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Wed Nov 23 16:48:06 2016 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 4587D129412 for ; Wed, 23 Nov 2016 16:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 oMHR_n0-EMtC for ; Wed, 23 Nov 2016 16:48:02 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::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 4E01E1293E0 for ; Wed, 23 Nov 2016 16:48:02 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id x23so11706436pgx.1 for ; Wed, 23 Nov 2016 16:48:02 -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=lfo+8QZ/b/YZdCMbQw7hs3oQbsMQRrejETqd/vTvMIc=; b=OFd6mqanKNmr7rJLaldP8KGujmruGmrdSN1gQ2Fpi4dj1D/TFzhytqDlW4K1/mS3A1 7XyP2EJRwcbXlDVCSjlnjJWrVdDnUo7pswAt7Tw/75LTUTbo5XXOD7DLl9wKeowtaxUy b6FoTrZXDJld1+YA686eQftZ4jV2B3+0cqGdI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lfo+8QZ/b/YZdCMbQw7hs3oQbsMQRrejETqd/vTvMIc=; b=GOBqVNPSB7QHhTajojiQOS9cStSyRp495fiw+SF1iGq+BaiNAhpJSjnjsdvl82XnGd uUwpgrdwCAfZsoH9FYHiGPzGnnLi9z2cv2DeLVqn+kDRp8UajMq+fIA040lj8CKu8pc/ jQjuK0EHkH2PC9zj0qUORExGlVIpmxj80HryO0ZwGG/KBDiKfiyVlqpXKx8LDPa4wGTa OHvF/hhTNkao+6qHSRwplXDR6gYGE7iLTQKi1amFR8JiOv2UODLLoRpWW8d2TNSCZDhn mkhCzKlp7F6AxjK485wf73yVsW2Q/SbkLUNZ7VMQjTcAiy2N2E9QEXAMLneUI5bzvtZx N3rw== X-Gm-Message-State: AKaTC02LajXVE+dBJcRcGvbtfh81rD5iVJMPzEHARGephUn7zYRp4Kld+CWsIqzbdu6QiyS9 X-Received: by 10.99.170.79 with SMTP id x15mr10067473pgo.14.1479948481492; Wed, 23 Nov 2016 16:48:01 -0800 (PST) Received: from ?IPv6:2620:101:80fc:224:69d5:5cd9:d9be:f882? ([2620:101:80fc:224:69d5:5cd9:d9be:f882]) by smtp.gmail.com with ESMTPSA id x90sm55286546pfk.73.2016.11.23.16.48.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Nov 2016 16:48:00 -0800 (PST) From: Nils Ohlmeier Message-Id: <58463A33-214F-4B26-BFAD-E1D34418C1A1@mozilla.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8E5685C8-9568-4BAC-80B8-9890B279BF67" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Wed, 23 Nov 2016 16:47:58 -0800 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BE9E9D1@ESESSMB209.ericsson.se> To: Christer Holmberg References: <2E094E44-EB86-48B5-89D4-167FCC624317@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4BE9E9D1@ESESSMB209.ericsson.se> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Missing amplification attack in RFC 5245 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 00:48:05 -0000 --Apple-Mail=_8E5685C8-9568-4BAC-80B8-9890B279BF67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 23, 2016, at 12:11, Christer Holmberg = wrote: >=20 > Hi, >=20 >>> My suggestion would be to say that media must only be sent on valid=20= >>> candidate pairs. Now, that may not prevent the attack, but at least = it=20 >>> requires a little more work as a pair has to be nominated. >>=20 >> I=E2=80=99m not sure if you are suggesting to require nomination in = general before sending media?! >=20 > No. >=20 > The spec currently says that media can be sent on a valid pair, and my = suggestion would be to say that media should also only be accepted on a = valid pair. =E2=80=9CAccepted=E2=80=9D sound like the receiving side to me. But to = limit the amplification we need to restrict the sender side at the = amplifier, agreed? Everything I write below is from the amplifiers point of view. >> To me it would make sense to not allow sending media over peer = reflexive candidates until they are nominated. But for pairs which have = been learned from signaling the >valid status is enough to start sending = media. >=20 > What do you mean by "signalling the valid status=E2=80=9D? Sorry I did not realize that my sentence could be parsed wrong. Here is = hopefully a better breakdown which avoids confusion. There are three ways to learn about remote candidates: 1) from signaling: - they cause check request to be sent to the victim=20 - this is described in section 13.4.1 of the draft - but you can=E2=80=99t send media to them as they are not in the = valid list yet and the victim hopefully never answers with a valid check = response - this is non peer reflexive candidate 2) as the STUN server from binding requests (assuming source IP/port are = forged): - they will cause STUN binding response to be send to the victim - this creates a new remote peer reflexive candidate - this also causes the new pair to be inserted into the triggered = check queue, which results in more STUN traffic for the victim - but no media gets send as the pair is not on the valid list (and = won=E2=80=99t be unless the victim sends a valid check response) - this attack I think is missing from the draft/spec 3) as the STUN client from a binding response: - this creates local peer reflexive candidate - a valid pair gets created for this, which allows sending media - but I don=E2=80=99t see how this applies to the amplification attack >> Although that makes things obviously more complex. This would also = raise the question if another state between =E2=80=98valid=E2=80=99 and = =E2=80=98nominated=E2=80=99 is needed which indicates that >sending = media on this pair is permitted. >=20 > Keep in mind that, according to 5245bis, there is no need to nominate = before sending media. >=20 > Also, as a side note, "nominated" only means that the controlling = endpoint has set the nominate flag in the STUN request - not that the = controlled pair has sent a STUN response. Once the controlled endpoint = has accepted the nomination, the pair becomes "selected" :) After looking at the above list please disregard my suggestion for a new = state. I don=E2=80=99t see how media could actually be send as part of = the amplification attack. BTW I got massively confused by the fact that apparently the editor = draft on github.io is really outdated. Could you = either update it or take it down to avoid further confusion? Thanks Nils --Apple-Mail=_8E5685C8-9568-4BAC-80B8-9890B279BF67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 23, 2016, at 12:11, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,
My suggestion would be = to say that media must only be sent on valid
candidate = pairs. Now, that may not prevent the attack, but at least it
requires a little more work as a pair has to be nominated.

I=E2=80=99m not sure if you are = suggesting to require nomination in general before sending media?!

No.

The spec currently says that media can be sent on a valid = pair, and my suggestion would be to say that media should also only be = accepted on a valid pair.

=E2=80=9CAccepted=E2=80=9D sound like the receiving = side to me. But to limit the amplification we need to restrict the = sender side at the amplifier, agreed?

Everything I write below is from the amplifiers = point of view.

To me it would make sense to not allow sending media over = peer reflexive candidates until they are nominated. But for pairs which = have been learned from signaling the >valid status is enough to start = sending media.

What do you = mean by "signalling the valid status=E2=80=9D?

Sorry I = did not realize that my sentence could be parsed wrong. Here is = hopefully a better breakdown which avoids confusion.

There are three ways to learn about remote = candidates:
1) from signaling:
  - they cause = check request to be sent to the victim 
  - this is = described in section 13.4.1 of the draft
  - but you = can=E2=80=99t send media to them as they are not in the valid list yet = and the victim hopefully never answers with a valid check = response
  - this is non peer reflexive = candidate
2) as the STUN server from binding requests = (assuming source IP/port are forged):
  - they will cause = STUN binding response to be send to the victim
  - this = creates a new remote peer reflexive candidate
  - this = also causes the new pair to be inserted into the triggered check queue, = which results in more STUN traffic for the victim
  - but = no media gets send as the pair is not on the valid list (and won=E2=80=99t= be unless the victim sends a valid check response)
  - = this attack I think is missing from the draft/spec
3) as the = STUN client from a binding response:
  - this creates = local peer reflexive candidate
  - a valid pair gets = created for this, which allows sending media
  - but I = don=E2=80=99t see how this applies to the amplification = attack

Although = that makes things obviously more complex. This would also raise the = question if another state between =E2=80=98valid=E2=80=99 and = =E2=80=98nominated=E2=80=99 is needed which indicates that >sending = media on this pair is permitted.

Keep in mind that, according to 5245bis, there is no need to = nominate before sending media.

Also, as a = side note, "nominated" only means that the controlling endpoint has set = the nominate flag in the STUN request - not that the controlled pair has = sent a STUN response. Once the controlled endpoint has accepted the = nomination, the pair becomes "selected" :)

After = looking at the above list please disregard my suggestion for a new = state. I don=E2=80=99t see how media could actually be send as part of = the amplification attack.

BTW I got = massively confused by the fact that apparently the editor draft on github.io is really = outdated. Could you either update it or take it down to avoid further = confusion?

Thanks
 Nils
= --Apple-Mail=_8E5685C8-9568-4BAC-80B8-9890B279BF67-- From nobody Tue Nov 29 09:48:58 2016 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 6CD9A12955D; Tue, 29 Nov 2016 09:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa5NTHMNhzMR; Tue, 29 Nov 2016 09:48:31 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD57129464; Tue, 29 Nov 2016 09:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30350; q=dns/txt; s=iport; t=1480441700; x=1481651300; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TiuFCVcjlcGi384Y+O/fCUBI2oa0yd5yk+b6zu8i2jw=; b=JpHLghisojiLYBiVJzTqDplKQfC8scBg8pwLIHa3iFJHOXFwGTZfVC3d 562leQLj47iwNihiZEduPHJl1ldBKmI5JmyuN+YEeGu3PXRZqP4QnFKZA Sc5mJQ4KTm32UV7jE4CU/1ar05F5uOG4HKHcpdlLFHrBBtqRYFxqP5bf4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAQBQvj1Y/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnM3DgEBAQEBH1iBAweNPJchh3KNA4IHHgEKhS9KAhqBVT8UAQI?= =?us-ascii?q?BAQEBAQEBYiiEaAEBAQQBAQEgSQILEAIBCBEDAQEBKAMCAgIfBgsUCQgCBAENB?= =?us-ascii?q?RuIOAMXDqwFgikvhxUNg3cBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYg7gl6CSII?= =?us-ascii?q?hFoJOLYIwBYk/hTOFeoU0NQGJV4NYg1aQMolAhDGECwEeN4EXIg4BAYMnHIFdc?= =?us-ascii?q?ocAgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.31,717,1473120000"; d="scan'208,217";a="174989161" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Nov 2016 17:48:18 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uATHmIGY014650 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Nov 2016 17:48:18 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 29 Nov 2016 11:48:18 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Tue, 29 Nov 2016 11:48:18 -0600 From: "Charles Eckel (eckelcu)" To: Alan Ford , Roman Shpount Thread-Topic: [bfcpbis] [MMUSIC] m= line protocol in case of ICE Thread-Index: AQHSQFwSEnIqX9JFq0OJWjTO/qYWEKDczAiAgAAW2ICAAXMeAIAR2UqA Date: Tue, 29 Nov 2016 17:48:18 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.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/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.182.35] Content-Type: multipart/alternative; boundary="_000_D0210B5A138A4C868D146E1FEC011E33ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "bfcpbis@ietf.org" , Christer Holmberg , "mmusic@ietf.org" , "ice@ietf.org" Subject: Re: [Ice] [bfcpbis] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 17:48:41 -0000 --_000_D0210B5A138A4C868D146E1FEC011E33ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgbW9zdCBzdHJhaWdodGZvcndhcmQgYXBwcm9hY2ggd291 bGQgYmUgdG8gbWFuZGF0ZSBzdXBwb3J0IGZvciBCRkNQIG92ZXIgVURQIHdoZW4gdXNpbmcgSUNF LCB1c2UgVURQIGFzIHRoZSBkZWZhdWx0IGNhbmRpZGF0ZSwgYW5kIHNpZ25hbCB0aGUgQkZDUCBt LWxpbmUgYXMgaWYgaXQgaXMgQkZDUCBvdmVyIFVEUC4gSWYgd2UgY2FuIG1hbmRhdGUgdGhlIHVz ZSBvZiBEVExTLCB0aGF0IHdvdWxkIGJlIGV2ZW4gYmV0dGVyLg0KVGhvdWdodHM/DQoNCkNoYXJs ZXMNCg0KRnJvbTogYmZjcGJpcyA8YmZjcGJpcy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYg b2YgQWxhbiBGb3JkIDxhbGFuLmZvcmRAZ21haWwuY29tPg0KRGF0ZTogVGh1cnNkYXksIE5vdmVt YmVyIDE3LCAyMDE2IGF0IDU6MTQgUE0NClRvOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4 LmNvbT4NCkNjOiAiYmZjcGJpc0BpZXRmLm9yZyIgPGJmY3BiaXNAaWV0Zi5vcmc+LCAiaWNlQGll dGYub3JnIiA8aWNlQGlldGYub3JnPiwgIm1tdXNpY0BpZXRmLm9yZyIgPG1tdXNpY0BpZXRmLm9y Zz4sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpT dWJqZWN0OiBSZTogW2JmY3BiaXNdIFtNTVVTSUNdIG09IGxpbmUgcHJvdG9jb2wgaW4gY2FzZSBv ZiBJQ0UNCg0KQWRkaW5nIGJmY3BiaXMuDQoNCllvdSByYWlzZSBhIGdvb2QgcG9pbnQgUm9tYW4g LSB0aGVyZeKAmXMgbm8gZGVmaW5pdGlvbiBvZiBob3cgdG8gYWN0dWFsbHkgdXNlIElDRSB3aXRo IEJGQ1AgYXQgdGhlIHByb3RvY29sIGxldmVsIC0gdGhpcyBvbmx5IGNhbWUgdXAgaW4gc29tZSB2 ZXJ5IGxhdGUgcmV2aWV3cyBvZiA0NTgyYmlzLiBUaGUgaW5pdGlhbCBzdWdnZXN0aW9uIHdhcyB0 byB1c2UgdGhlIHNhbWUgdGV4dCBhcyBpbiBkcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcC0xOSwg YnV0IGl0IHRoZW4gcmFpc2VkIHRoZSBwb2ludCB0aGF0LCBnaXZlbiBCRkNQIGRvZXMgbm90IGhh dmUgYSBNVEkgcHJvdG9jb2wsIGlmIHRoZSBvZmZlcmVyIHN1cHBvcnRlZCBib3RoIHRoZXkgd291 bGQgaW5jbHVkZSB0aGVpciBwcmVmZXJyZWQgb3B0aW9uLCBidXQgaWYgdGhlIHJlY2VpdmVyIHN1 cHBvcnRlZCB0aGUgb3RoZXIgdmFyaWFudCwgdGhlcmXigJlzIG5vIHdheSB0byBpbW1lZGlhdGVs eSBuZWdvdGlhdGUgdGhhdCB3aXRob3V0IGEgcmUtSU5WSVRFLg0KDQpDaHJpc3RlcuKAmXMgc3Vn Z2VzdGlvbiB0byByZWxheCB0aGUgcmVxdWlyZW1lbnQgdGhhdCB0aGUgbS1saW5lIHByb3RvY29s IGluIHRoZSBhbnN3ZXIgbWF0Y2hlcyBvbmUgb2YgdGhlIElDRSBjYW5kaWRhdGVzIHdvdWxkIHN1 cHBvcnQgdGhlIGNhc2Ugd2hlcmUgdGhlIG9mZmVyZXIgc3VwcG9ydHMgYm90aCBidXQgcHJlZmVy cyBVRFAsIGJ1dCB0aGUgYW5zd2VyZXIgb25seSBzdXBwb3J0cyBUQ1AuIEFsdGhvdWdoIG5vIGlt cGxlbWVudGF0aW9ucyBjdXJyZW50bHkgZG8gSUNFIGhlcmUsIHRoaXMgcmVsYXhhdGlvbiB3b3Vs ZCBsZWF2ZSB0aGUgZG9vciBvcGVuIHRvIGdhaW5pbmcgdGhpcyBuZWdvdGlhdGlvbiBmbGV4aWJp bGl0eSBpbiBiZmNwYmlzIGltcGxlbWVudGF0aW9ucy4gVGhlcmUgc2VlbXMgbm8gcmVhc29uIHRv IGhhdmUgdGhpcyByZXF1aXJlbWVudCBhcHBsaWVkIHRvIHRoZSBhbnN3ZXIgaW4gdGhlIGZpcnN0 IHBsYWNlLg0KDQpJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgY29tbWVudCBhYm91dCBTQkNzOyB0 b2RheSwgdGNwIGNhbmRpZGF0ZXMgYXJlIHVzZWQgZm9yIG1lZGlhIGFuZCBkYXRhIGNoYW5uZWxz IGVuZC10by1lbmQgaW4gV2ViUlRDLCB0byBuYW1lIGJ1dCBvbmUgaW1wbGVtZW50YXRpb24uDQoN ClJlZ2FyZHMsDQpBbGFuDQoNCk9uIDE3IE5vdiAyMDE2LCBhdCAwMzowNSwgUm9tYW4gU2hwb3Vu dCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4gd3JvdGU6DQoN CkFkZGluZyBJQ0UgZ3JvdXAgdG8gdGhpcyBtZXNzYWdlLg0KDQpUaGUgYXBwcm9hY2ggYWx3YXlz IHdhcyB0aGF0IHRjcCBjYW5kaWRhdGVzIGNhbiBwb3RlbnRpYWxseSBnbyBvbmx5IGFzIGZhciBh cyBTQkMgYW5kIHRoZW4gYmUgdGVybWluYXRlZCBieSBVRFAgdHJhbnNwb3J0LiBCZWNhdXNlIG9m IHRoaXMgZXZlcnl0aGluZyB0cmFuc21pdHRlZCBvdmVyIHRjcCBjYW5kaWRhdGUgd2FzIHN0aWxs IGNvbnNpZGVyZWQgdG8gYmUgdHJhbnNtaXR0ZWQgb3ZlciB0aGUgdW5yZWxpYWJsZSBvdXQtb2Yt b3JkZXIgdHJhbnNwb3J0LiBJdCBpcyBhbHNvIGFzc3VtZWQgdGhhdCBjYW5kaWRhdGVzIGNhbiBz d2l0Y2ggZnJvbSBVRFAgdG8gVENQIGJhc2VkIGNhbmRpZGF0ZSBkdXJpbmcgbm9taW5hdGlvbi4g VGhpcyBpcyB3aHksIGZvciBpbnN0YW5jZSwgd2UgcnVuIERUTFMgd2l0aCBSRkM0NTcxIGZyYW1p bmcgb3ZlciB0Y3AgY2FuZGlkYXRlcywgbm90IFRMUy4gQmVjYXVzZSBvZiB0aGlzIEkgYWx3YXlz IHRob3VnaHQgdGhhdCBJQ0UgaXMgVURQIGZpcnN0IHdpdGggYWRkaXRpb25hbCBUQ1AgdHJhbnNw b3J0cyBmb3Igc2l0dWF0aW9uIHdoZW4gVURQIHdpbGwgbm90IHdvcmsuIFNvLCBhcyBhIHJlc3Vs dCwgSSB0aGluayBJQ0UtYmlzIHNob3VsZCBzcGVjaWZ5IHRoYXQgVURQIE1VU1QgYmUgc3VwcG9y dGVkIGFuZCBkZWZhdWx0IGNhbmRpZGF0ZSBNVVNUIGJlIFVEUC4gSUNFIFNEUCBjYW4gcmVmbGVj dCB0aGlzLCBidXQgSSB0aGluayB0aGlzIGlzIHRoZSB1bmRlcmx5aW5nIHByb3RvY29sIHJlcXVp cmVtZW50Lg0KDQpJIGFsc28gd2FudGVkIHRvIGFkZCB0aGF0IEJGQ1AgbmVlZHMgdG8gZXhhbWlu ZSBob3cgSUNFIHN1cHBvcnQgaXMgaW1wbGVtZW50ZWQgYnkgdGhpcyBwcm90b2NvbC4gSSB0aGlu ayBpdCBpcyBub3QgY292ZXJlZCBpbiB0aGUgY3VycmVudCBkcmFmdHMuIEkgYWxzbyB0aGluayBJ IGRvIG5vdCB0aGluayBpdCBpcyBwb3NzaWJsZSBmb3IgVENQL0JGQ1AgdG8gcnVuIG92ZXIgSUNF LiBPbiB0aGUgb3RoZXIgaGFuZCBVRFAvRFRMUy9CRkNQIGFuZCBUQ1AvRFRMUy9CRkNQIHdvdWxk IHRyaXZpYWwgYmFzZWQgb24gY3VycmVudCBEVExTIHdvcmsuDQoNClJlZ2FyZHMsDQpfX19fX19f X19fX19fDQpSb21hbiBTaHBvdW50DQoNCk9uIFdlZCwgTm92IDE2LCAyMDE2IGF0IDg6NDQgUE0s IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRv OmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSSBoYXZlIG5vIHByb2Js ZW0gd2l0aCBSb21hbuKAmXMgbXVzdC1zdXBwb3J0LVVEUCBzdWdnZXN0aW9uLiBJIGd1ZXNzIHRo ZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZSBCRkNQIGZvbGtzIGNvdWxkIGFjY2VwdCB0aGF0LiBD dWxsZW4gZGlkIHNheSB0aGF0IFRDUC1iYXNlZCBCRkNQIGRlcGxveW1lbnRzIGhhdmUgYmVlbiBh cm91bmQgZm9yIGEgZGVjYWRlLiBCdXQsIGRvIHRoZXkgc3VwcG9ydCBJQ0U/DQoNCklmIHdlIGRl Y2lkZSB0byBtb3ZlIGZvcndhcmQgd2l0aCBzdWNoIGFwcHJvYWNoLCB3ZSBuZWVkIHRvIGFzayBv dXJzZWx2ZXMgd2hldGhlciBtdXN0LXN1cHBvcnQtVURQIHNob3VsZCBiZSBhbiBJQ0UgcmVxdWly ZW1lbnQgKGluIHdoaWNoIGNhc2UgdGhlIHN1Z2dlc3Rpb24gc2hvdWxkIGJlIGJyb3VnaHQgdG8g dGhlIElDRSBXRykgb3Igd2hldGhlciBpdCBzaG91bGQgb25seSBiZSBhbiBJQ0UtdXNpbmctU0lQ LVNEUCByZXF1aXJlbWVudC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogbW11c2lj IFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpYy1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmIE9mIFJvbWFuIFNocG91bnQNClNlbnQ6IDE3IE5vdmVtYmVyIDIw MTYgMDA6NTINClRvOiBtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NClN1 YmplY3Q6IFtNTVVTSUNdIG09IGxpbmUgcHJvdG9jb2wgaW4gY2FzZSBvZiBJQ0UNCg0KSGkgQWxs LA0KDQpJIGp1c3Qgd2FudGVkIHRvIHJldHVybiB0byB0aGUgbT0gbGluZSBwcm90b2NvbCBpc3N1 ZSB0aGF0IENocmlzdGVyIHJhaXNlZCBkdXJpbmcgdGhlIGxhc3QgTU1VU0lDIHNlc3Npb24uDQoN CkFsbCB0aGUgSUNFIGltcGxlbWVudGF0aW9ucyBJJ3ZlIHNlZW4gYXJlIHByaW1hcmlseSBVRFAg YmFzZWQgd2l0aCBzdXBwb3J0IGZvciB0Y3AgaG9zdCBjYW5kaWRhdGVzIHdoaWNoIGFyZSBwcmlt YXJpbHkgdXNlZCB0byBjb25uZWN0IHRvIGVuZCBwb2ludHMgb24gcHVibGljIElQLiBJZiBhbGwg SUNFIGltcGxlbWVudGF0aW9ucyBhcmUgY29udGludWUgdG8gYmUgcHJpbWFyaWx5IFVEUCBiYXNl ZCwgdGhlbiB0aGUgc2ltcGxlc3Qgc29sdXRpb24gd291bGQgYmUgdG8gcmVxdWlyZSBVRFAgc3Vw cG9ydCB3aGVuIGFueSBnaXZlbiBwcm90b2NvbCBpcyBpbXBsZW1lbnRlZCBvdmVyIElDRS4gRFRM UyBhbmQgUlRQIGFyZSBhbHJlYWR5IHByaW1hcmlseSBVRFAgYmFzZWQgc28gdGhpcyBpcyBhIG5v bi1yZXF1aXJlbWVudC4gRXZlbiBtb3JlLCBhbGwgcHJvdG9jb2xzIHRoYXQgYXJlIGltcGxlbWVu dGVkIG9uIHRvcCBvZiBJQ0UgbXVzdCBhc3N1bWUgdGhhdCB1bmRlcmxpbmcgdHJhbnNwb3J0cyAo aW5jbHVkaW5nIHRjcCBjYW5kaWRhdGVzKSBhcmUgdW5yZWxpYWJsZSwgc2luY2UgY2FuZGlkYXRl IHBhaXIgY2FuIGNoYW5nZSBhdCBhbnkgdGltZSBiZXR3ZWVuIHJlbGlhYmxlIGFuZCB1bnJlbGlh YmxlIHRyYW5zcG9ydHMsIHNvIHRoaXMgbWFrZXMgdGhlbSBkaWZmZXJlbnQgZnJvbSBwcm90b2Nv bHMgaW1wbGVtZW50ZWQgb24gcGxhaW4gVENQIG9yIFRMUy4NCg0KU28gdGhlIGZpcnN0IHF1ZXN0 aW9uIEkgd2FudGVkIHRvIGFzayBpcyBhbnlib2R5IGludGVyZXN0ZWQgaW4gVENQIG9ubHkgSUNF IGltcGxlbWVudGF0aW9uIHdoZXJlIHRoZSBwcm90b2NvbCBydW5uaW5nIG9uIHRvcCBvZiBzdWNo IGltcGxlbWVudGF0aW9uIHJlbGllcyBvbiB0aGUgcmVsaWFibGUgZGVsaXZlcnkgb2YgdW5kZXJs eWluZyBtZXNzYWdlcz8gQnkgdGhpcyBJIG1lYW4sIGRvZXMgYW55Ym9keSB3YW50cyBpbXBsZW1l bnQgVENQIGJhc2VkIElDRSwgd2l0aCBzaW11bHRhbmVvdXMgb3BlbiwgcmVmbGV4aXZlIGFuZCBy ZWxheSBjYW5kaWRhdGVzIGluIHN1Y2ggYSB3YXkgdGhhdCBJQ0UgaW1wbGVtZW50YXRpb24gd2ls bCBydW4gZnJvbSBiZWhpbmQgTkFUIHdpdGhvdXQgZXZlciBuZWVkaW5nIGEgVURQIGNhbmRpZGF0 ZT8NCg0KSSB1bmRlcnN0YW5kIHRoYXQgQkZDUCB3YXMgdXNlZCBmb3IgYSBsb25nIHRpbWUsIGJ1 dCBJIGRvIG5vdCB0aGluayBUQ1AvQkZDUCBvciBUQ1AvVExTL0JGQ1AgY2FuIGV2ZW4gYmUgdXNl ZCB3aXRoIElDRS4gSSB0aGluayBvbmx5IFVEUC9CRkNQLCBVRFAvRFRMUy9CRkNQIGFuZCBUQ1Av RFRMUy9CRkNQIGNhbiBldmVuIHN1cHBvcnQgSUNFLg0KDQpJIHRoaW5rIGJvdGggcmZjNDU4MmJp cyBhbmQgcmZjNDU4M2JpcyBuZWVkIGEgY2FyZWZ1bCByZXZpZXcgYW5kIGFkZGl0aW9uYWwgc2Vj dGlvbnMgdGhhdCBkZXNjcmliZSBJQ0UgY29uc2lkZXJhdGlvbnMuIEkgdGhpbmsgdGhlIG1vc3Qg b2J2aW91cyB0aGluZyB3b3VsZCBiZSB0byBzcGVjaWZ5IHRoYXQgSUNFIGNhbiBvbmx5IGJlIHN1 cHBvcnRlZCBieSBVRFAvQkZDUCwgVURQL0RUTFMvQkZDUCBhbmQgVENQL0RUTFMvQkZDUC4gSXQg d2lsbCBhbHNvIG1lYW4gaW4gd2hpY2ggY2FzZSBSRkM0NTcxIGlzIHVzZWQgd2hlbiB0Y3AgY2Fu ZGlkYXRlcyBhcmUgdXNlZC4gRnVydGhlcm1vcmUsIHdoZW4gdGNwIGNhbmRpZGF0ZSBpcyBzZWxl Y3RlZCB3aXRoIFVEUC9CRkNQIHRyYW5zcG9ydCwgaXQgaXMgbm90IHRoZSBzYW1lIHRoaW5nIGFz IHVzaW5nIFRDUC9CRkNQIGFuZCB3aWxsIG5lZWQgYSBkaWZmZXJlbnQgdHJhbnNwb3J0IHRhZyAo c29tZXRoaW5nIGxpa2UgVENQL1VEUC9CRkNQKS4gQWx0ZXJuYXRpdmVseSB3ZSBjYW4gcmVxdWly ZSB0aGF0IG9ubHkgc2VjdXJlIHZlcnNpb25zIG9mIEJGQ1AgYXJlIHVzZWQgd2l0aCBJQ0UgYW5k IG9ubHkgYWxsb3cgSUNFIHVzYWdlIGZvciBVRFAvRFRMUy9CRkNQIGFuZCBUQ1AvRFRMUy9CRkNQ Lg0KDQpUbyBjb25jbHVkZSwgSSB3b3VsZCBhcmd1ZSB0aGF0IHRoZSBzaW1wbGVzdCBzb2x1dGlv biB3b3VsZCBiZSB0aGF0IGZvciBhbGwgcHJvdG9jb2xzIGltcGxlbWVudGVkIG9uIHRvcCBvZiBJ Q0UsIFVEUCBNVVNUIGJlIHN1cHBvcnRlZCBhbmQgZGVmYXVsdCBjYW5kaWRhdGVzIE1VU1QgYmUg VURQIGJhc2VkLiBUaGlzIGF2b2lkcyBidWlsZGluZyB1bmNvbWZvcnRhYmxlIGFydGlmaWNpYWwg Y29uc3RydWN0cyB0byBhdm9pZCBJQ0UgbWlzbWF0Y2ggYW5kIHJlcXVpcmVzIG1pbmltYWwgY2hh bmdlcyB0byBleGlzdGluZyBzcGVjaWZpY2F0aW9ucy4NCg0KUmVnYXJkcywNCl9fX19fX19fX19f X18NClJvbWFuIFNocG91bnQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86 bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWMNCg0K --_000_D0210B5A138A4C868D146E1FEC011E33ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <70BC3ED1CB932547BA62AE36708A4914@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u bXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIi Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBtb3N0IHN0 cmFpZ2h0Zm9yd2FyZCBhcHByb2FjaCB3b3VsZCBiZSB0byBtYW5kYXRlIHN1cHBvcnQgZm9yIEJG Q1Agb3ZlciBVRFAgd2hlbiB1c2luZyBJQ0UsIHVzZSBVRFAgYXMgdGhlIGRlZmF1bHQgY2FuZGlk YXRlLCBhbmQgc2lnbmFsIHRoZSBCRkNQIG0tbGluZSBhcyBpZiBpdCBpcyBCRkNQIG92ZXIgVURQ LiBJZiB3ZSBjYW4gbWFuZGF0ZSB0aGUgdXNlIG9mIERUTFMsDQogdGhhdCB3b3VsZCBiZSBldmVu IGJldHRlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRob3VnaHRzPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFybGVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+YmZjcGJpcyAmbHQ7YmZjcGJp cy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgQWxhbiBGb3JkICZsdDthbGFuLmZv cmRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgTm92ZW1iZXIgMTcs IDIwMTYgYXQgNToxNCBQTTxicj4NCjxiPlRvOiA8L2I+Um9tYW4gU2hwb3VudCAmbHQ7cm9tYW5A dGVsdXJpeC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtiZmNwYmlzQGlldGYub3JnJnF1 b3Q7ICZsdDtiZmNwYmlzQGlldGYub3JnJmd0OywgJnF1b3Q7aWNlQGlldGYub3JnJnF1b3Q7ICZs dDtpY2VAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDttbXVzaWNAaWV0Zi5vcmcmcXVvdDsgJmx0O21tdXNp Y0BpZXRmLm9yZyZndDssIENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbYmZjcGJpc10gW01NVVNJ Q10gbT0gbGluZSBwcm90b2NvbCBpbiBjYXNlIG9mIElDRTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZGRpbmcgYmZjcGJpcy4gPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgcmFpc2UgYSBnb29kIHBv aW50IFJvbWFuIC0gdGhlcmXigJlzIG5vIGRlZmluaXRpb24gb2YgaG93IHRvIGFjdHVhbGx5IHVz ZSBJQ0Ugd2l0aCBCRkNQIGF0IHRoZSBwcm90b2NvbCBsZXZlbCAtIHRoaXMgb25seSBjYW1lIHVw IGluIHNvbWUgdmVyeSBsYXRlIHJldmlld3Mgb2YgNDU4MmJpcy4gVGhlIGluaXRpYWwgc3VnZ2Vz dGlvbiB3YXMgdG8gdXNlIHRoZSBzYW1lIHRleHQgYXMgaW4mbmJzcDtkcmFmdC1pZXRmLW1tdXNp Yy1zY3RwLXNkcC0xOSwNCiBidXQgaXQgdGhlbiByYWlzZWQgdGhlIHBvaW50IHRoYXQsIGdpdmVu IEJGQ1AgZG9lcyBub3QgaGF2ZSBhIE1USSBwcm90b2NvbCwgaWYgdGhlIG9mZmVyZXIgc3VwcG9y dGVkIGJvdGggdGhleSB3b3VsZCBpbmNsdWRlIHRoZWlyIHByZWZlcnJlZCBvcHRpb24sIGJ1dCBp ZiB0aGUgcmVjZWl2ZXIgc3VwcG9ydGVkIHRoZSBvdGhlciB2YXJpYW50LCB0aGVyZeKAmXMgbm8g d2F5IHRvIGltbWVkaWF0ZWx5IG5lZ290aWF0ZSB0aGF0IHdpdGhvdXQgYSByZS1JTlZJVEUuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNocmlz dGVy4oCZcyBzdWdnZXN0aW9uIHRvIHJlbGF4IHRoZSByZXF1aXJlbWVudCB0aGF0IHRoZSBtLWxp bmUgcHJvdG9jb2wNCjxpPmluIHRoZSBhbnN3ZXI8L2k+Jm5ic3A7bWF0Y2hlcyBvbmUgb2YgdGhl IElDRSBjYW5kaWRhdGVzIHdvdWxkIHN1cHBvcnQgdGhlIGNhc2Ugd2hlcmUgdGhlIG9mZmVyZXIg c3VwcG9ydHMgYm90aCBidXQgcHJlZmVycyBVRFAsIGJ1dCB0aGUgYW5zd2VyZXIgb25seSBzdXBw b3J0cyBUQ1AuIEFsdGhvdWdoIG5vIGltcGxlbWVudGF0aW9ucyBjdXJyZW50bHkgZG8gSUNFIGhl cmUsIHRoaXMgcmVsYXhhdGlvbiB3b3VsZCBsZWF2ZSB0aGUgZG9vciBvcGVuIHRvDQogZ2Fpbmlu ZyB0aGlzIG5lZ290aWF0aW9uIGZsZXhpYmlsaXR5IGluIGJmY3BiaXMgaW1wbGVtZW50YXRpb25z LiBUaGVyZSBzZWVtcyBubyByZWFzb24gdG8gaGF2ZSB0aGlzIHJlcXVpcmVtZW50IGFwcGxpZWQg dG8gdGhlIGFuc3dlciBpbiB0aGUgZmlyc3QgcGxhY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBj b21tZW50IGFib3V0IFNCQ3M7IHRvZGF5LCB0Y3AgY2FuZGlkYXRlcyBhcmUgdXNlZCBmb3IgbWVk aWEgYW5kIGRhdGEgY2hhbm5lbHMgZW5kLXRvLWVuZCBpbiBXZWJSVEMsIHRvIG5hbWUgYnV0IG9u ZSBpbXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFsYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE3IE5vdiAyMDE2LCBhdCAw MzowNSwgUm9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29t Ij5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFkZGluZyBJQ0UgZ3JvdXAgdG8gdGhpcyBt ZXNzYWdlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSBhcHByb2FjaCBhbHdheXMgd2FzIHRoYXQgdGNwIGNhbmRpZGF0ZXMgY2FuIHBvdGVudGlhbGx5 IGdvIG9ubHkgYXMgZmFyIGFzIFNCQyBhbmQgdGhlbiBiZSB0ZXJtaW5hdGVkIGJ5IFVEUCB0cmFu c3BvcnQuIEJlY2F1c2Ugb2YgdGhpcyBldmVyeXRoaW5nIHRyYW5zbWl0dGVkIG92ZXIgdGNwIGNh bmRpZGF0ZSB3YXMgc3RpbGwgY29uc2lkZXJlZCB0byBiZSB0cmFuc21pdHRlZCBvdmVyIHRoZSB1 bnJlbGlhYmxlDQogb3V0LW9mLW9yZGVyIHRyYW5zcG9ydC4gSXQgaXMgYWxzbyBhc3N1bWVkIHRo YXQgY2FuZGlkYXRlcyBjYW4gc3dpdGNoIGZyb20gVURQIHRvIFRDUCBiYXNlZCBjYW5kaWRhdGUg ZHVyaW5nIG5vbWluYXRpb24uIFRoaXMgaXMgd2h5LCBmb3IgaW5zdGFuY2UsIHdlIHJ1biBEVExT IHdpdGggUkZDNDU3MSBmcmFtaW5nIG92ZXIgdGNwIGNhbmRpZGF0ZXMsIG5vdCBUTFMuIEJlY2F1 c2Ugb2YgdGhpcyBJIGFsd2F5cyB0aG91Z2h0IHRoYXQgSUNFIGlzDQogVURQIGZpcnN0IHdpdGgg YWRkaXRpb25hbCBUQ1AgdHJhbnNwb3J0cyBmb3Igc2l0dWF0aW9uIHdoZW4gVURQIHdpbGwgbm90 IHdvcmsuIFNvLCBhcyBhIHJlc3VsdCwgSSB0aGluayBJQ0UtYmlzIHNob3VsZCBzcGVjaWZ5IHRo YXQgVURQIE1VU1QgYmUgc3VwcG9ydGVkIGFuZCBkZWZhdWx0IGNhbmRpZGF0ZSBNVVNUIGJlIFVE UC4gSUNFIFNEUCBjYW4gcmVmbGVjdCB0aGlzLCBidXQgSSB0aGluayB0aGlzIGlzIHRoZSB1bmRl cmx5aW5nIHByb3RvY29sDQogcmVxdWlyZW1lbnQuIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbHNvIHdhbnRlZCB0byBhZGQgdGhhdCBCRkNQIG5lZWRz IHRvIGV4YW1pbmUgaG93IElDRSBzdXBwb3J0IGlzIGltcGxlbWVudGVkIGJ5IHRoaXMgcHJvdG9j b2wuIEkgdGhpbmsgaXQgaXMgbm90IGNvdmVyZWQgaW4gdGhlIGN1cnJlbnQgZHJhZnRzLiBJIGFs c28gdGhpbmsgSSBkbyBub3QgdGhpbmsgaXQgaXMgcG9zc2libGUgZm9yIFRDUC9CRkNQIHRvJm5i c3A7cnVuIG92ZXIgSUNFLiBPbiB0aGUgb3RoZXIgaGFuZA0KIFVEUC9EVExTL0JGQ1AgYW5kIFRD UC9EVExTL0JGQ1Agd291bGQgdHJpdmlhbCBiYXNlZCBvbiBjdXJyZW50IERUTFMgd29yay48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRz LDxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTm92IDE2LCAyMDE2 IGF0IDg6NDQgUE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5 N0QiPkkgaGF2ZSBubyBwcm9ibGVtIHdpdGggUm9tYW7igJlzIG11c3Qtc3VwcG9ydC1VRFAgc3Vn Z2VzdGlvbi4gSSBndWVzcyB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB0aGUgQkZDUA0KIGZvbGtz IGNvdWxkIGFjY2VwdCB0aGF0LiBDdWxsZW4gZGlkIHNheSB0aGF0IFRDUC1iYXNlZCBCRkNQIGRl cGxveW1lbnRzIGhhdmUgYmVlbiBhcm91bmQgZm9yIGEgZGVjYWRlLiBCdXQsIGRvIHRoZXkgc3Vw cG9ydCBJQ0U/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj5JZiB3ZSBkZWNpZGUgdG8gbW92ZSBmb3J3 YXJkIHdpdGggc3VjaCBhcHByb2FjaCwgd2UgbmVlZCB0byBhc2sgb3Vyc2VsdmVzIHdoZXRoZXIg bXVzdC1zdXBwb3J0LVVEUA0KIHNob3VsZCBiZSBhbiBJQ0UgcmVxdWlyZW1lbnQgKGluIHdoaWNo IGNhc2UgdGhlIHN1Z2dlc3Rpb24gc2hvdWxkIGJlIGJyb3VnaHQgdG8gdGhlIElDRSBXRykgb3Ig d2hldGhlciBpdCBzaG91bGQgb25seSBiZSBhbiBJQ0UtdXNpbmctU0lQLVNEUCByZXF1aXJlbWVu dC4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0Qi PkNocmlzdGVyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fNDMxNTY5MjQyMzg5OTc3OTgxM19f TWFpbEVuZENvbXBvc2UiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2E+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPiBtbXVzaWMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bW11c2ljLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWMtYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvbWFuIFNocG91bnQ8YnI+DQo8Yj5TZW50OjwvYj4gMTcg Tm92ZW1iZXIgMjAxNiAwMDo1Mjxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm1tdXNp Y0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gW01NVVNJQ10gbT0gbGluZSBwcm90b2NvbCBpbiBjYXNlIG9mIElDRTwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiI+SGkgQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIj5JIGp1c3Qgd2FudGVkIHRvIHJldHVybiB0byB0aGUgbT0gbGluZSBwcm90b2NvbCBpc3N1 ZSB0aGF0IENocmlzdGVyIHJhaXNlZCBkdXJpbmcgdGhlIGxhc3QgTU1VU0lDIHNlc3Npb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+QWxsIHRo ZSBJQ0UgaW1wbGVtZW50YXRpb25zIEkndmUgc2VlbiBhcmUgcHJpbWFyaWx5IFVEUCBiYXNlZCB3 aXRoIHN1cHBvcnQgZm9yIHRjcCBob3N0IGNhbmRpZGF0ZXMgd2hpY2ggYXJlIHByaW1hcmlseSB1 c2VkIHRvIGNvbm5lY3QgdG8gZW5kIHBvaW50cyBvbiBwdWJsaWMNCiBJUC4gSWYgYWxsIElDRSBp bXBsZW1lbnRhdGlvbnMgYXJlIGNvbnRpbnVlIHRvIGJlIHByaW1hcmlseSBVRFAgYmFzZWQsIHRo ZW4gdGhlIHNpbXBsZXN0IHNvbHV0aW9uIHdvdWxkIGJlIHRvIHJlcXVpcmUgVURQIHN1cHBvcnQg d2hlbiBhbnkgZ2l2ZW4gcHJvdG9jb2wgaXMgaW1wbGVtZW50ZWQgb3ZlciBJQ0UuIERUTFMgYW5k IFJUUCBhcmUgYWxyZWFkeSBwcmltYXJpbHkgVURQIGJhc2VkIHNvIHRoaXMgaXMgYSBub24tcmVx dWlyZW1lbnQuIEV2ZW4NCiBtb3JlLCBhbGwgcHJvdG9jb2xzIHRoYXQgYXJlIGltcGxlbWVudGVk IG9uIHRvcCBvZiBJQ0UgbXVzdCBhc3N1bWUgdGhhdCB1bmRlcmxpbmcgdHJhbnNwb3J0cyAoaW5j bHVkaW5nIHRjcCBjYW5kaWRhdGVzKSBhcmUgdW5yZWxpYWJsZSwgc2luY2UgY2FuZGlkYXRlIHBh aXIgY2FuIGNoYW5nZSBhdCBhbnkgdGltZSBiZXR3ZWVuIHJlbGlhYmxlIGFuZCB1bnJlbGlhYmxl IHRyYW5zcG9ydHMsIHNvIHRoaXMgbWFrZXMgdGhlbSBkaWZmZXJlbnQgZnJvbQ0KIHByb3RvY29s cyBpbXBsZW1lbnRlZCBvbiBwbGFpbiBUQ1Agb3IgVExTLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPlNvIHRoZSBmaXJzdCBxdWVzdGlvbiBJIHdh bnRlZCB0byBhc2sgaXMgYW55Ym9keSBpbnRlcmVzdGVkIGluIFRDUCBvbmx5IElDRSBpbXBsZW1l bnRhdGlvbiB3aGVyZSB0aGUgcHJvdG9jb2wgcnVubmluZyBvbiB0b3Agb2Ygc3VjaCBpbXBsZW1l bnRhdGlvbiByZWxpZXMgb24NCiB0aGUgcmVsaWFibGUgZGVsaXZlcnkgb2YgdW5kZXJseWluZyBt ZXNzYWdlcz8gQnkgdGhpcyBJIG1lYW4sIGRvZXMgYW55Ym9keSB3YW50cyBpbXBsZW1lbnQgVENQ IGJhc2VkIElDRSwgd2l0aCBzaW11bHRhbmVvdXMgb3BlbiwgcmVmbGV4aXZlIGFuZCByZWxheSBj YW5kaWRhdGVzIGluIHN1Y2ggYSB3YXkgdGhhdCBJQ0UgaW1wbGVtZW50YXRpb24gd2lsbCBydW4g ZnJvbSBiZWhpbmQgTkFUIHdpdGhvdXQgZXZlciBuZWVkaW5nIGEgVURQIGNhbmRpZGF0ZT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5JIHVuZGVy c3RhbmQgdGhhdCBCRkNQIHdhcyB1c2VkIGZvciBhIGxvbmcgdGltZSwgYnV0IEkgZG8gbm90IHRo aW5rIFRDUC9CRkNQIG9yIFRDUC9UTFMvQkZDUCBjYW4gZXZlbiBiZSB1c2VkIHdpdGggSUNFLiBJ IHRoaW5rIG9ubHkgVURQL0JGQ1AsIFVEUC9EVExTL0JGQ1AgYW5kDQogVENQL0RUTFMvQkZDUCBj YW4gZXZlbiBzdXBwb3J0IElDRS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5JIHRoaW5rIGJvdGgmbmJzcDtyZmM0NTgyYmlzIGFuZCBy ZmM0NTgzYmlzIG5lZWQgYSBjYXJlZnVsIHJldmlldyBhbmQgYWRkaXRpb25hbCBzZWN0aW9ucyB0 aGF0IGRlc2NyaWJlIElDRSBjb25zaWRlcmF0aW9ucy4gSSB0aGluayB0aGUgbW9zdCBvYnZpb3Vz IHRoaW5nIHdvdWxkIGJlDQogdG8gc3BlY2lmeSB0aGF0IElDRSBjYW4gb25seSBiZSBzdXBwb3J0 ZWQgYnkgVURQL0JGQ1AsIFVEUC9EVExTL0JGQ1AgYW5kIFRDUC9EVExTL0JGQ1AuIEl0IHdpbGwg YWxzbyBtZWFuIGluIHdoaWNoIGNhc2UgUkZDNDU3MSBpcyB1c2VkIHdoZW4gdGNwIGNhbmRpZGF0 ZXMgYXJlIHVzZWQuIEZ1cnRoZXJtb3JlLCB3aGVuIHRjcCBjYW5kaWRhdGUgaXMgc2VsZWN0ZWQg d2l0aCBVRFAvQkZDUCB0cmFuc3BvcnQsIGl0IGlzIG5vdCB0aGUgc2FtZSB0aGluZw0KIGFzIHVz aW5nIFRDUC9CRkNQIGFuZCB3aWxsIG5lZWQgYSBkaWZmZXJlbnQgdHJhbnNwb3J0IHRhZyAoc29t ZXRoaW5nIGxpa2UgVENQL1VEUC9CRkNQKS4gQWx0ZXJuYXRpdmVseSB3ZSBjYW4gcmVxdWlyZSB0 aGF0IG9ubHkgc2VjdXJlIHZlcnNpb25zIG9mIEJGQ1AgYXJlIHVzZWQgd2l0aCBJQ0UgYW5kIG9u bHkgYWxsb3cgSUNFIHVzYWdlIGZvciBVRFAvRFRMUy9CRkNQIGFuZCBUQ1AvRFRMUy9CRkNQLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPlRvIGNv bmNsdWRlLCBJIHdvdWxkIGFyZ3VlIHRoYXQgdGhlIHNpbXBsZXN0IHNvbHV0aW9uIHdvdWxkIGJl IHRoYXQgZm9yIGFsbCBwcm90b2NvbHMgaW1wbGVtZW50ZWQgb24gdG9wIG9mIElDRSwgVURQIE1V U1QgYmUgc3VwcG9ydGVkIGFuZCBkZWZhdWx0IGNhbmRpZGF0ZXMNCiBNVVNUIGJlIFVEUCBiYXNl ZC4gVGhpcyBhdm9pZHMgYnVpbGRpbmcgdW5jb21mb3J0YWJsZSBhcnRpZmljaWFsIGNvbnN0cnVj dHMgdG8gYXZvaWQgSUNFIG1pc21hdGNoIGFuZCByZXF1aXJlcyBtaW5pbWFsIGNoYW5nZXMgdG8g ZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tR0IiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_D0210B5A138A4C868D146E1FEC011E33ciscocom_-- From nobody Tue Nov 29 10:38:34 2016 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 24034129C2C for ; Tue, 29 Nov 2016 10:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU6T1FMG5-zs for ; Tue, 29 Nov 2016 10:38:31 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393FA129C2B for ; Tue, 29 Nov 2016 10:38:31 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id c47so164427240qtc.2 for ; Tue, 29 Nov 2016 10:38:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7qqLdS9vp6TTnjBbwJmv7u7xqixov4ZHULXOeKEcOFA=; b=jl2/umngtMNHaMlYI4g/ALsYOy0W0AUY2p0/tXXFZZ2QEc78HJuWgJ2QwOx8AE6mFn xFNlX9N++I0rQNo7XiCwmYuSPKn6tqZxFXiSvXbO3qe4BMjNvsjBaQ3P424aUMtrFJxs 0MTEIlYgz9q/p0SHe1mhss9BroWwOmVOvS53HR42sKmDP0RjmuTjofKFUou1Ko+LLQVc jQNUhRgitUm+LzLoDUsAvK1wsHK+ReSgkCToY8o7SPQabeDZYiDL+qLlIl+/HgmUnEym 24f4sINwlbAVTUBCrHqHY4xBhN1aOaep4jAJ+Ol4v/gdTTO4l7T+wTInC7lTTg7IQwzB D/fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7qqLdS9vp6TTnjBbwJmv7u7xqixov4ZHULXOeKEcOFA=; b=Y1cEWOi5agwwbIG2mlydW73G0jE9F+r/oxG82/nk4HNzc+u2Zj/3AIf767wawv2v22 VOThlI/71uyIF8Pp3dVHOuMXsbhufgWKTVGNiXn0DNTkZhPHd9H9BzOaWR7CzEX45F3p ypIX1XOIwcFDrRprxooL27J4MrTb/uQpsdmuNzxd7N2BJcdzlDumchT7qpXmtakZVbwv Luw0CGofLodf4mdKY6deWfLdOmOxy4SF39nDak8T5I6Y+F34EKWHWwbiQFvi6goQ+iAU j47VKfcdyHH8p9tVWdpim5g7G73RIB34YISIZkkpDehElV7xHkzBIm+Vkm1P2D+/xuxb 8Ftg== X-Gm-Message-State: AKaTC00zGM7KffuXlMi5icEWP5hpBifbM3j65uHR9EnJGszkkgqGOl7wN0V1Yd6+80bQ8w== X-Received: by 10.237.47.227 with SMTP id m90mr25673550qtd.120.1480444710349; Tue, 29 Nov 2016 10:38:30 -0800 (PST) Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com. [209.85.220.169]) by smtp.gmail.com with ESMTPSA id r15sm31476683qte.9.2016.11.29.10.38.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Nov 2016 10:38:29 -0800 (PST) Received: by mail-qk0-f169.google.com with SMTP id n21so184167373qka.3; Tue, 29 Nov 2016 10:38:29 -0800 (PST) X-Received: by 10.55.197.6 with SMTP id p6mr27881287qki.239.1480444709772; Tue, 29 Nov 2016 10:38:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.205 with HTTP; Tue, 29 Nov 2016 10:38:29 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> From: Roman Shpount Date: Tue, 29 Nov 2016 13:38:29 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a1149a18c092c8e054274e565 Archived-At: Cc: "ice@ietf.org" , "bfcpbis@ietf.org" , Christer Holmberg , "mmusic@ietf.org" , Alan Ford Subject: Re: [Ice] [bfcpbis] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 18:38:33 -0000 --001a1149a18c092c8e054274e565 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eckelcu) wrote: > It seems to me that the most straightforward approach would be to mandate > support for BFCP over UDP when using ICE, use UDP as the default candidate, > and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate the > use of DTLS, that would be even better. > > Thoughts? > > > I agree. The only issue that I still have, if DTLS is not used, what protocol is used when ICE tcp candidate is selected for transport. Is this TCP/BFCP (which goes against RFC6544) or is it UDP/BFCP with RFC4571 framing? If it is UDP/BFCP with RFC4571 framing, what transport tag should be used in the re-INVITE which is sent after ICE nomination with only selected candidate? Should it be TCP/UDP/BFCP or something similar? Regards, _____________ Roman Shpount --001a1149a18c092c8e054274e565 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eckelcu) <eckelcu@ci= sco.com> wrote:

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

Thoughts?

=C2=A0


<= /div>
I agree.

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

Regards,
_____________
Roman Shpount
=C2= =A0
--001a1149a18c092c8e054274e565-- From nobody Tue Nov 29 11:31:20 2016 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 81A0D129C39; Tue, 29 Nov 2016 11:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh4zrAIHQtbv; Tue, 29 Nov 2016 11:31:15 -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 E58B11299A1; Tue, 29 Nov 2016 11:31:14 -0800 (PST) X-AuditID: c1b4fb25-ec9d598000007ee2-0d-583dd78126a4 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id FE.CF.32482.187DD385; Tue, 29 Nov 2016 20:31:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0319.002; Tue, 29 Nov 2016 20:31:11 +0100 From: Christer Holmberg To: Roman Shpount , "Charles Eckel (eckelcu)" Thread-Topic: [bfcpbis] [MMUSIC] m= line protocol in case of ICE Thread-Index: AQHSQFwT8S0xdJKeakq1+K6kpgEs7aDcZjMAgAAHVICAAXMfAIASX2cAgAAOBYCAAB8loA== Date: Tue, 29 Nov 2016 19:31:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BEB1151@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BEB1151ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2J7iG7jddsIgx27xSxWnlvBbPFv3VEm i02zvrBZfLtQazF1+WMWixkXpjI7sHlM+b2R1WPnrLvsHkuW/GTyuDWlIIAlissmJTUnsyy1 SN8ugSvj/d9GtoIDQRUX+u6wNzDOCehi5OSQEDCRmHFqAlsXIxeHkMA6RonGid1QzmJGiYkX zzB3MXJwsAlYSHT/0wZpEBEIk+ifuwKshllgAqPE8r9/2EESwgL2EjM3djJDFDlITN2xiBWm 4er3VjYQm0VAVeLn5D1sIDN5BXwlLvxihNjVwSzx7v8MRpA4p0CgxIRtuSDljAJiEt9PrWEC sZkFxCVuPZnPBHG0gMSSPeeZIWxRiZeP/7FC2EoSK7ZfAhvDLJAvsbnfBiTMKyAocXLmE5YJ jCKzkEyahVA1C0kVRFhTYv0ufYhqRYkp3Q/ZIWwNidY5c9mRxRcwsq9iFC1OLU7KTTcy1kst ykwuLs7P08tLLdnECIzEg1t+q+5gvPzG8RCjAAejEg/vh+m2EUKsiWXFlbmHGCU4mJVEeEOu AIV4UxIrq1KL8uOLSnNSiw8xSnOwKInzmq28Hy4kkJ5YkpqdmlqQWgSTZeLglGpgLGVjPfvn cuBR8QgfmboZBy/uj78oXFm305TnfZVM/w3GTT80jvydLTFZ2W8tr7DasR6OUoG0Qxn8iSHf Xk0R1tr27IuJUOum45dmXJuS735VeKae6JcNlnrZq643SabxPQ0I07lYzb86M3/2pUvfF025 qxoY7rs5wEtl5u+LPBo37n+Zkez4TYmlOCPRUIu5qDgRAE3DnUXAAgAA Archived-At: Cc: "ice@ietf.org" , "bfcpbis@ietf.org" , "mmusic@ietf.org" , Alan Ford Subject: Re: [Ice] [bfcpbis] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 19:31:18 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BEB1151ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIGFncmVlLg0KDQpNb3JlIGdlbmVyYWxseSwgSSBzdWdnZXN0IHRoYXQgQU5ZIHByb3Rv Y29sIHN1cHBvcnRpbmcgSUNFIHNob3VsZCBhbHdheXMgaGF2ZSBhIE1USSB0cmFuc3BvcnQsIHdo aWNoIGluIHRoZSBjYXNlIG9mIElDRS1TRFAgYWxzbyBNVVNUIGJlIHVzZWQgYXMgZGVmYXVsdCBj YW5kaWRhdGUuIFRoYXQgd2F5IHdlIHdvdWxkIGF2b2lkIG9mZmVycyB3aXRoIG0tIGxpbmUgdHJh bnNwb3J0IHZhbHVlcyBub3Qgc3VwcG9ydGVkIGJ5IHRoZSBhbnN3ZXJlci4NCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg0KRnJvbTogUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXgu Y29tXQ0KU2VudDogMjkgTm92ZW1iZXIgMjAxNiAyMDozOA0KVG86IENoYXJsZXMgRWNrZWwgKGVj a2VsY3UpIDxlY2tlbGN1QGNpc2NvLmNvbT4NCkNjOiBBbGFuIEZvcmQgPGFsYW4uZm9yZEBnbWFp bC5jb20+OyBiZmNwYmlzQGlldGYub3JnOyBpY2VAaWV0Zi5vcmc7IG1tdXNpY0BpZXRmLm9yZzsg Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NClN1Ympl Y3Q6IFJlOiBbYmZjcGJpc10gW01NVVNJQ10gbT0gbGluZSBwcm90b2NvbCBpbiBjYXNlIG9mIElD RQ0KDQpPbiBUdWUsIE5vdiAyOSwgMjAxNiBhdCAxMjo0OCBQTSwgQ2hhcmxlcyBFY2tlbCAoZWNr ZWxjdSkgPGVja2VsY3VAY2lzY28uY29tPG1haWx0bzplY2tlbGN1QGNpc2NvLmNvbT4+IHdyb3Rl Og0KSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgbW9zdCBzdHJhaWdodGZvcndhcmQgYXBwcm9hY2gg d291bGQgYmUgdG8gbWFuZGF0ZSBzdXBwb3J0IGZvciBCRkNQIG92ZXIgVURQIHdoZW4gdXNpbmcg SUNFLCB1c2UgVURQIGFzIHRoZSBkZWZhdWx0IGNhbmRpZGF0ZSwgYW5kIHNpZ25hbCB0aGUgQkZD UCBtLWxpbmUgYXMgaWYgaXQgaXMgQkZDUCBvdmVyIFVEUC4gSWYgd2UgY2FuIG1hbmRhdGUgdGhl IHVzZSBvZiBEVExTLCB0aGF0IHdvdWxkIGJlIGV2ZW4gYmV0dGVyLg0KVGhvdWdodHM/DQoNCg0K SSBhZ3JlZS4NCg0KVGhlIG9ubHkgaXNzdWUgdGhhdCBJIHN0aWxsIGhhdmUsIGlmIERUTFMgaXMg bm90IHVzZWQsIHdoYXQgcHJvdG9jb2wgaXMgdXNlZCB3aGVuIElDRSB0Y3AgY2FuZGlkYXRlIGlz IHNlbGVjdGVkIGZvciB0cmFuc3BvcnQuIElzIHRoaXMgVENQL0JGQ1AgKHdoaWNoIGdvZXMgYWdh aW5zdCBSRkM2NTQ0KSAgb3IgaXMgaXQgVURQL0JGQ1Agd2l0aCBSRkM0NTcxIGZyYW1pbmc/IElm IGl0IGlzIFVEUC9CRkNQIHdpdGggUkZDNDU3MSBmcmFtaW5nLCB3aGF0IHRyYW5zcG9ydCB0YWcg c2hvdWxkIGJlIHVzZWQgaW4gdGhlIHJlLUlOVklURSB3aGljaCBpcyBzZW50IGFmdGVyIElDRSBu b21pbmF0aW9uIHdpdGggb25seSBzZWxlY3RlZCBjYW5kaWRhdGU/IFNob3VsZCBpdCBiZSBUQ1Av VURQL0JGQ1Agb3Igc29tZXRoaW5nIHNpbWlsYXI/DQoNClJlZ2FyZHMsDQpfX19fX19fX19fX19f DQpSb21hbiBTaHBvdW50DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B4BEB1151ESESSMB209erics_ 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 cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGFsc28gYWdyZWUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Nb3JlIGdlbmVyYWxseSwgSSBzdWdn ZXN0IHRoYXQgQU5ZIHByb3RvY29sIHN1cHBvcnRpbmcgSUNFIHNob3VsZCBhbHdheXMgaGF2ZSBh IE1USSB0cmFuc3BvcnQsIHdoaWNoIGluIHRoZSBjYXNlIG9mIElDRS1TRFAgYWxzbyBNVVNUDQog YmUgdXNlZCBhcyBkZWZhdWx0IGNhbmRpZGF0ZS4gVGhhdCB3YXkgd2Ugd291bGQgYXZvaWQgb2Zm ZXJzIHdpdGggbS0gbGluZSB0cmFuc3BvcnQgdmFsdWVzIG5vdCBzdXBwb3J0ZWQgYnkgdGhlIGFu c3dlcmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21w b3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRl bHVyaXguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDI5IE5vdmVtYmVyIDIwMTYgMjA6Mzg8YnI+ DQo8Yj5Ubzo8L2I+IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpICZsdDtlY2tlbGN1QGNpc2NvLmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IEFsYW4gRm9yZCAmbHQ7YWxhbi5mb3JkQGdtYWlsLmNvbSZn dDs7IGJmY3BiaXNAaWV0Zi5vcmc7IGljZUBpZXRmLm9yZzsgbW11c2ljQGlldGYub3JnOyBDaHJp c3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW2JmY3BiaXNdIFtNTVVTSUNdIG09IGxpbmUgcHJvdG9jb2wg aW4gY2FzZSBvZiBJQ0U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE5vdiAyOSwgMjAxNiBhdCAxMjo0OCBQTSwgQ2hhcmxl cyBFY2tlbCAoZWNrZWxjdSkgJmx0OzxhIGhyZWY9Im1haWx0bzplY2tlbGN1QGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmVja2VsY3VAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkl0IHNlZW1zIHRvIG1l IHRoYXQgdGhlIG1vc3Qgc3RyYWlnaHRmb3J3YXJkIGFwcHJvYWNoIHdvdWxkIGJlIHRvIG1hbmRh dGUgc3VwcG9ydCBmb3IgQkZDUCBvdmVyIFVEUCB3aGVuIHVzaW5nIElDRSwgdXNlIFVEUCBhcyB0 aGUgZGVmYXVsdCBjYW5kaWRhdGUsIGFuZCBzaWduYWwNCiB0aGUgQkZDUCBtLWxpbmUgYXMgaWYg aXQgaXMgQkZDUCBvdmVyIFVEUC4gSWYgd2UgY2FuIG1hbmRhdGUgdGhlIHVzZSBvZiBEVExTLCB0 aGF0IHdvdWxkIGJlIGV2ZW4gYmV0dGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRob3VnaHRzPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgb25seSBpc3N1ZSB0aGF0IEkg c3RpbGwgaGF2ZSwgaWYgRFRMUyBpcyBub3QgdXNlZCwgd2hhdCBwcm90b2NvbCBpcyB1c2VkIHdo ZW4gSUNFIHRjcCBjYW5kaWRhdGUgaXMmbmJzcDtzZWxlY3RlZCBmb3IgdHJhbnNwb3J0LiBJcyB0 aGlzIFRDUC9CRkNQICh3aGljaCBnb2VzIGFnYWluc3QgUkZDNjU0NCkgJm5ic3A7b3IgaXMgaXQg VURQL0JGQ1Agd2l0aCBSRkM0NTcxIGZyYW1pbmc/IElmIGl0IGlzIFVEUC9CRkNQIHdpdGgNCiBS RkM0NTcxIGZyYW1pbmcsIHdoYXQgdHJhbnNwb3J0IHRhZyBzaG91bGQgYmUgdXNlZCBpbiB0aGUg cmUtSU5WSVRFIHdoaWNoIGlzIHNlbnQgYWZ0ZXIgSUNFIG5vbWluYXRpb24gd2l0aCBvbmx5IHNl bGVjdGVkIGNhbmRpZGF0ZT8gU2hvdWxkIGl0IGJlIFRDUC9VRFAvQkZDUCBvciBzb21ldGhpbmcg c2ltaWxhcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4BEB1151ESESSMB209erics_-- From nobody Wed Nov 30 03:52:21 2016 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 78F6812A002; Wed, 30 Nov 2016 03:52:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.38.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148050673748.6832.12617389383043878814.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 03:52:17 -0800 Archived-At: Cc: ice@ietf.org Subject: [Ice] I-D Action: draft-ietf-ice-rfc5245bis-06.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 11:52:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment of the IETF. Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal Authors : Ari Keranen Christer Holmberg Jonathan Rosenberg Filename : draft-ietf-ice-rfc5245bis-06.txt Pages : 95 Date : 2016-11-30 Abstract: This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-rfc5245bis-06 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 Wed Nov 30 04:02:21 2016 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 4E1031296BE for ; Wed, 30 Nov 2016 04:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJtSqD23-syd for ; Wed, 30 Nov 2016 04:02:18 -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 BE7FD129FF9 for ; Wed, 30 Nov 2016 04:01:34 -0800 (PST) X-AuditID: c1b4fb2d-4612998000001117-fb-583ebf9c34b4 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 49.1D.04375.C9FBE385; Wed, 30 Nov 2016 13:01:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Wed, 30 Nov 2016 13:01:07 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: Draft new version: draft-ietf-ice-rfc5245bis-06 Thread-Index: AQHSSwFu1fPav4uu3keUR8I6XNFFAA== Date: Wed, 30 Nov 2016 12:01:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D4648E3313DFDchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7ge7c/XYRBldWsFt8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6MOSvPsRbc5KtY0jaJvYFxB08XIyeHhICJRMPyHaxdjFwcQgLr GCU+nrvACOEsZpTYP6+XpYuRg4NNwEKi+582SIOIgKLEzJZnzCC2MFD4zrIuNoi4rcSbIzeZ IGw9icfLtoPVsAioSszv/c4IYvMKWEtM+XsPrJ5RQEzi+6k1YPXMAuISt57MZ4I4SEBiyZ7z zBC2qMTLx/9YQU4QBZq55n4YRFhRYufZdmaI1gSJ3kmzmSHGC0qcnPmEZQKj0CwkU2chKZuF pAwibiDx/tx8ZghbW2LZwtdQtr7Exi9nGSFsa4k3r/YyIatZwMixilG0OLW4ODfdyFgvtSgz ubg4P08vL7VkEyMwTg5u+a27g3H1a8dDjAIcjEo8vB+m20YIsSaWFVfmHmKU4GBWEuGdvtsu Qog3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQbGOGOlX2IH tFN/lJR7RTGE2K55n3Gv44n+6YiVEy+XThNUFjB62mT8jDPc+2/hvbaIVv5Z7/I3zLQTf9Gx SFjj6KvqjTMXH/EtmijHWnRtuU3FC02X3j8fbPTmmejf4Pu2+/9sngeRdlmPtdgkTQ/ERy7s nM11ue/d3iKt7d9f8S+WWbz95gUzJZbijERDLeai4kQAtT7ycY8CAAA= Archived-At: Subject: [Ice] Draft new version: draft-ietf-ice-rfc5245bis-06 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 12:02:20 -0000 --_000_D4648E3313DFDchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I=92ve submitted a new version (-06) of draft-5245bis. Please take a look =96 especially if you didn=92t check the pull requests t= hat the new version is based on =96 because there has been a number of chan= ges, e.g., related to pruning and some leftovers from the removal of aggres= sive nomination. Next I=92ll put together a pull request for the change Emil suggested in Be= rlin (known as =93Emil=92s table=94). Note that it will be a TECHNICAL chan= ge. Regards, Christer --_000_D4648E3313DFDchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1D185E40CDA3D84E97035BC155589816@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I=92ve submitted a new version (-06) of draft-5245bis.

Please take a look =96 especially if you didn=92t check the pull reque= sts that the new version is based on =96 because there has been a number of= changes, e.g., related to pruning and some leftovers from the removal of a= ggressive nomination.

Next I=92ll put together a pull request for the change Emil suggested = in Berlin (known as =93Emil=92s table=94). Note that it will be a TECHNICAL= change.

Regards,

Christer
--_000_D4648E3313DFDchristerholmbergericssoncom_-- From nobody Wed Nov 30 06:27:49 2016 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 946851294C7 for ; Wed, 30 Nov 2016 06:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87byz7MJIaGr for ; Wed, 30 Nov 2016 06:27:45 -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 57449129418 for ; Wed, 30 Nov 2016 06:27:45 -0800 (PST) X-AuditID: c1b4fb3a-97bff70000007918-49-583ee1deaaf3 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id A6.BC.31000.ED1EE385; Wed, 30 Nov 2016 15:27:43 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Wed, 30 Nov 2016 15:27:42 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: Pull request to implement unfreezing change suggested by Emil in Berlin Thread-Index: AQHSSxXorlHm1na3CketC7w+fvIBQQ== Date: Wed, 30 Nov 2016 14:27:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D464B08F13E57christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7pe79h3YRBvfO6lh8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6MrU8XsBXMFK14N6GPvYHxm2AXIyeHhICJxL6Od2xdjFwcQgLr GCW23O1nhnAWM0qseHaOqYuRg4NNwEKi+582SIOIgKLEzJZnzCC2sEC0xMcPbawQ8QSJs8uP Qtl6Eq37m8BsFgFVibtHHoLV8wpYS6xr/whmMwqISXw/tYYJxGYWEJe49WQ+E8RBAhJL9pxn hrBFJV4+/scKcoIo0Mw198MgwkoSPzZcYgEJMwOt/Xw7C2K6oMTJmU9YJjAKzUIydBZC1Swk VRAlBhLvz81nhrC1JZYtfA1l60ts/HKWEcK2lljzbB47spoFjByrGEWLU4uLc9ONjPRSizKT i4vz8/TyUks2MQJj5OCW31Y7GA8+dzzEKMDBqMTD+2G6bYQQa2JZcWXuIUYJDmYlEd4tD+wi hHhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamDkf9v6fzHj ZbXJ6z5fNewN/FOz8NS6W1eKLoW/EZp0+0bghHxPiajZl9UZ25Kezvp4+2Xmj2WbbPqs9E4s PD9zNm/Lqzc8C0/XCW9Rkp1+y+9U04rboheOJxb+/7VMSOrdFtF7fYE+YU3bNugevSfg0vW/ 5ca/qY8KpnROUTh7/OPECXI8r8669SuxFGckGmoxFxUnAgAOE3RVjQIAAA== Archived-At: Subject: [Ice] 5245bis: Pull request to implement unfreezing change suggested by Emil in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 14:27:47 -0000 --_000_D464B08F13E57christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Based on the discussions in Berlin (yes, Berlin), where Emil presented a ch= ange to the initial candidate unfreezing procedure, I have created a pull r= equest. I ask people to take a look: https://github.com/ice-wg/rfc5245bis/pull/24 The main change is: Previously, only candidate pairs (one pair per foundation) in the first che= ck list were placed in the Waiting state. The paris in all other lists rema= ined Frozen. With the change, candidate pairs (still, only one pair per foundation) thro= ughout all check lists will be placed in the Waiting state. Emil used a very nice table (=93Emil=92s table=94) in Berlin to illustrate = this. I have not implemented the table in the pull request, but if people t= hink it=92s needed it=92s something we can work on. Regards, Christer --_000_D464B08F13E57christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Based on the discussions in Berlin (yes, Berlin), where Emil presented= a change to the initial candidate unfreezing procedure, I have created a p= ull request. I ask people to take a look:


The main change is:

Previously, only candidate pairs (one pair per foundation) in the firs= t check list were placed in the Waiting state. The paris in all other lists= remained Frozen.

With the change, candidate pairs (still, only one pair per foundation)= throughout all check lists will be placed in= the Waiting state.

Emil used a very nice table (=93Emil=92s table=94) in Berlin to illust= rate this. I have not implemented the table in the pull request, but if peo= ple think it=92s needed it=92s something we can work on.

Regards,

Christer 
--_000_D464B08F13E57christerholmbergericssoncom_-- From nobody Wed Nov 30 10:35:24 2016 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 2C09B129698 for ; Wed, 30 Nov 2016 10:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzbky4hZJnQC for ; Wed, 30 Nov 2016 10:35:19 -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 94F54129669 for ; Wed, 30 Nov 2016 10:35:19 -0800 (PST) X-AuditID: c1b4fb30-851fe70000000c18-7b-583f1be3a442 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id E7.79.03096.3EB1F385; Wed, 30 Nov 2016 19:35:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0319.002; Wed, 30 Nov 2016 19:35:15 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: Pull request to implement unfreezing change suggested by Emil in Berlin Thread-Index: AQHSSxXorlHm1na3CketC7w+fvIBQaDx2o2A Date: Wed, 30 Nov 2016 18:35:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BEB3517@ESESSMB209.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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BEB3517ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2K7uu4zafsIg1NLGS2+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGs6OXGQsueFf0vP3D3sD4y7mLkZNDQsBE4sCz8ywgtpDAOkaJ me+Uuhi5gOzFjBJP1xxj7WLk4GATsJDo/qcNUiMioCgxs+UZM0hYWCBe4v2XdIhwgsTZ5UdZ IWwjiY3nG8FGsgioSrw59ICti5Gdg1fAV+KqOsQia4n38/6yg9icAjYSf4+fA+tkFBCT+H5q DROIzSwgLnHryXwmiCMFJJbsOc8MYYtKvHz8jxXCVpJYdPszE8gxzAL5EmdvmIGEeQUEJU7O fMIygVF4FpJJsxCqZiGpgijRkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxihanFiflphsZ 6aUWZSYXF+fn6eWllmxiBEbHwS2/DXYwvnzueIhRgINRiYe34KVdhBBrYllxZe4hRgkOZiUR XlFJ+wgh3pTEyqrUovz4otKc1OJDjNIcLErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGLOc /4ScmMwevM12xk7O4qywt3lXd+Y/SJO7+HlCLafZAsm9DD03/0tsYzls/fqYdxvn5EuHPZ8l SJ3wlLv1MDPqtPaBrHt2KyQTepSPufFfOfs1MCuMea+a36Sv3zVCvt8Tm/373mzprDsnWvep sK3rybJzl3xz4INN9aZZZjNvzpU4tXPnqttKLMUZiYZazEXFiQAThjmcigIAAA== Archived-At: Subject: Re: [Ice] 5245bis: Pull request to implement unfreezing change suggested by Emil in Berlin X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 18:35:22 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BEB3517ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The pull request also contained a number of editorial changes, which made i= t difficult to parse the change based on Emil's suggestion. So, I've create= d a new pull request, without the editorial changes. https://github.com/ice-wg/rfc5245bis/pull/25 Regards, Christer From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 30 November 2016 16:28 To: ice@ietf.org Subject: [Ice] 5245bis: Pull request to implement unfreezing change suggest= ed by Emil in Berlin Hi, Based on the discussions in Berlin (yes, Berlin), where Emil presented a ch= ange to the initial candidate unfreezing procedure, I have created a pull r= equest. I ask people to take a look: https://github.com/ice-wg/rfc5245bis/pull/24 The main change is: Previously, only candidate pairs (one pair per foundation) in the first che= ck list were placed in the Waiting state. The paris in all other lists rema= ined Frozen. With the change, candidate pairs (still, only one pair per foundation) thro= ughout all check lists will be placed in the Waiting state. Emil used a very nice table ("Emil's table") in Berlin to illustrate this. = I have not implemented the table in the pull request, but if people think i= t's needed it's something we can work on. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4BEB3517ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

The pull r= equest also contained a number of editorial changes, which made it difficul= t to parse the change based on Emil’s suggestion. So, I’ve created a new pull request, without the editorial changes.<= o:p>

 = ;

https://github.com/ice-wg/rf= c5245bis/pull/25

 = ;

Regards,

 = ;

Christer

 

From: = Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 30 November 2016 16:28
To: ice@ietf.org
Subject: [Ice] 5245bis: Pull request to implement unfreezing change = suggested by Emil in Berlin

 

Hi,

 

Based on the discussions in Berlin (yes= , Berlin), where Emil presented a change to the initial candidate unfreezin= g procedure, I have created a pull request. I ask people to take a look:

 

 

The main change is:

 

Previously, only candidate pairs (one p= air per foundation) in the first check list were placed in the Waiting stat= e. The paris in all other lists remained Frozen.

 

With the change, candidate pairs (still= , only one pair per foundation) throughout all check lists will be placed in the Waiting state.

 

Emil used a very nice table (“Emi= l’s table”) in Berlin to illustrate this. I have not implemente= d the table in the pull request, but if people think it’s needed it’s something we can work on.

 

Regards,

 

Christer 

--_000_7594FB04B1934943A5C02806D1A2204B4BEB3517ESESSMB209erics_--