From nobody Fri Jun 7 15:15:29 2019 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 101C7120044; Fri, 7 Jun 2019 15:15:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ice-chairs@ietf.org, adam@nostrum.com, pthatcher@google.com, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155994572800.6104.11745789084409277679.idtracker@ietfa.amsl.com> Date: Fri, 07 Jun 2019 15:15:28 -0700 Archived-At: Subject: [Ice] ice - New Meeting Session Request for IETF 105 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 22:15:28 -0000 A new meeting session request has just been submitted by Peter Thatcher, a Chair of the ice working group. --------------------------------------------------------- Working Group Name: Interactive Connectivity Establishment Area Name: Applications and Real-Time Area Session Requester: Peter Thatcher Number of Sessions: 1 Length of Session(s): 30 Minutes Number of Attendees: 15 Conflicts to Avoid: First Priority: rtcweb, mmusic, quic, avtcore People who must be present: Adam Roach Ari Keranen Peter Thatcher Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jun 7 15:21:35 2019 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 B46051200BA; Fri, 7 Jun 2019 15:21:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ice-chairs@ietf.org, adam@nostrum.com, pthatcher@google.com, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155994609369.6015.15815665903288354210.idtracker@ietfa.amsl.com> Date: Fri, 07 Jun 2019 15:21:33 -0700 Archived-At: Subject: [Ice] ice - Update to a Meeting Session Request for IETF 105 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 22:21:34 -0000 An update to a meeting session request has just been submitted by Peter Thatcher, a Chair of the ice working group. --------------------------------------------------------- Working Group Name: Interactive Connectivity Establishment Area Name: Applications and Real-Time Area Session Requester: Peter Thatcher Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 15 Conflicts to Avoid: First Priority: rtcweb mmusic quic avtcore People who must be present: Adam Roach Ari Keranen Peter Thatcher Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jun 22 23:08:36 2019 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715EC120128 for ; Sat, 22 Jun 2019 23:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwkqzQGXSTSh for ; Sat, 22 Jun 2019 23:08:31 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5327120098 for ; Sat, 22 Jun 2019 23:08:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id EE1937C0581; Sun, 23 Jun 2019 08:08:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoZQLTvgEQBY; Sun, 23 Jun 2019 08:08:26 +0200 (CEST) Received: from [10.196.213.203] (7-197.icannmeeting.org [199.91.197.7]) by mork.alvestrand.no (Postfix) with ESMTPSA id 99EBD7C049E; Sun, 23 Jun 2019 08:08:25 +0200 (CEST) To: Christer Holmberg , Justin Uberti , Nils Ohlmeier Cc: Roman Shpount , "ice@ietf.org" References: From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= mQINBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABtC9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPokCPgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryG5Ag0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAGJAiUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <1aa5aac7-af59-4e3b-8651-18f6e6431a2d@alvestrand.no> Date: Sun, 23 Jun 2019 08:08:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------40318308C313017A091D7A70" Content-Language: en-GB Archived-At: Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2019 06:08:34 -0000 This is a multi-part message in MIME format. --------------40318308C313017A091D7A70 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 5/28/19 1:54 PM, Christer Holmberg wrote: > > Hi, > >   > > We need to move forward with this. > >   > > There are two main questions at the moment: > >   > > 1. When does an endpoint start the timer ("minimum-time-to-run-ICE" > timer, based on previous discussions)? > 2. What is the duration of the timer? > >   > > Regarding 1), my understanding is that people suggest alternative c), > which starts the timer when an endpoint has sent (in an offer or > answer) at least one local candidate (or EOC). > >   > >   > > Regarding 2), it has been suggested that the duration would be the > same as the max duration of a connectivity check transaction. Do we > think that is enough, no matter how many media streams and components > are used? > Go for it. It is much better than having nothing. >   > > Regards, > >   > > Christer > >   > >   > >   > >   > >   > >   > >   > >   > >   > > *From: *Ice on behalf of Christer Holmberg > > *Date: *Friday, 3 May 2019 at 15.02 > *To: *Justin Uberti , Nils Ohlmeier > > *Cc: *Roman Shpount , "ice@ietf.org" > *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting for > possible peer reflexive candidates? > >   > > Hi, > >   > > I don’t think there will be any interoperability issues. At the end of > the day PAC is only about how long to wait for candidates, so the > worse thing that can happen is than an agent declares ICE failure too > early. > >   > > And, no matter whether an agent knows that the peer supports PAC or > not,  it should aim at sending it’s candidates to its peer as soon as > possible, depending on whatever local policies. The agent should not > delay sending candidates just because it assumes that the peer will > anyway wait for them. > >   > > Regards, > >   > > Christer > >   > > *From: *Justin Uberti > *Date: *Thursday, 2 May 2019 at 22.28 > *To: *Nils Ohlmeier > *Cc: *Christer Holmberg , Roman > Shpount , "ice@ietf.org" > *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting for > possible peer reflexive candidates? > >   > >   > >   > > On Thu, May 2, 2019 at 12:22 PM Nils Ohlmeier > wrote: > >   > > > > > On May 2, 2019, at 12:13, Justin Uberti > wrote: > >   > >   > >   > > On Thu, May 2, 2019 at 10:07 AM Nils Ohlmeier > > wrote: > > > >> I do think Nils' point is important though, i.e., if we > have a bad server it will take a very long time to decide > on 'last set of candidates', > >> which is probably not helpful. As such I think the > potential positions we can take are: > >> a) Start the timer as soon as we have an answer, > regardless of any candidates. > >> b) a) + receipt of at least one remote candidate (or > remote EOC). (This is Nils' suggestion). > >> c) a) + sending at least one local candidate (or local > EOC). > > As we are mostly concerned about the remote side: 1) not > providing us with candidates, or 2) providing us with > unusable candidates or 3) providing us with candidates > really late I don’t see how option c) would help in any of > these scenarios. > From my point of view we should choose either a) or b). > >   > > c) is just a clarification of a), in that you can't expect to > receive prflx candidates until you've at least provided the > other side with a candidate, so that may be the right time for > the timer to start. I don't feel super strongly about this > though.  > >   > > Ok. I hadn’t looked at it from that angle. So c) being a stronger > a) I guess it would be okay. > >   > > I guess my only concern is that in Firefox we stopped doing a) > because it caused to many problems. With that in mind would it > cause interop problems if we leave up to the implementor to choose > to implement either b) or c)? > >   > > I'd be fine with that, but I'd want to describe what to watch out for. > Can you explain a bit more?  > > > > > > >> b) has a problem if the remote side doesn't send any > candidates, which we want to explicitly allow. > > > > True.  > > Just to make sure we are all on the same page: b) is only > a problem in the scenario where the remote side doesn’t > send any candidates but also does not send EOC.  > > > The EOC should allow agents which explicitly don’t want to > provide candidate to get the timer started soon. > I think that leaves us with scenarios where the remote > doesn’t provide host candidates, and it’s reflexive or > relay candidates take for ever because of slow servers. > >   > > Correct, but we can't control which endpoints will send us an > EOC or not. So that will always be a possibility.  > >   > > Fair enough. > > > > > > >> I tend to lean towards a) as the simplest option. > > > > Keep in mind that RFC 8445 is generic, so we need to to > define what we mean by "answer". I guess it means some > kind of indication that makes the agent assume that the > remote peer has been contacted. In ice-sip-sdp we can then > map that to an SDP answer. > > Good point. We basically treat the SDP answer here to be > something like an beginning of ICE, because we don’t have > an explicit signal for that. I think in SDP based worlds > there is no need for an extra signal like that. Not sure > if other use cases of ICE would benefit from an explicit > begin signal. > >   > > The answer in some ways is an explicit begin signal, because > it contains the username/password information needed to start > ICE checks.  > >   > > Yeah I didn’t see your reply before hitting send on mine. Using > the availability sounds like a good idea as the minimum gating > function/signal. > >   > > Best > >   Nils > >   > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice -- Surveillance is pervasive. Go Dark. --------------40318308C313017A091D7A70 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/28/19 1:54 PM, Christer Holmberg wrote:

Hi,

 

We need to move forward with this.

 

There are two main questions at the moment:

 

  1. When does an endpoint start the timer ("minimum-time-to-run-ICE" timer, based on previous discussions)?
  2. What is the duration of the timer?

 

Regarding 1), my understanding is that people suggest alternative c), which starts the timer when an endpoint has sent (in an offer or answer) at least one local candidate (or EOC).

 

 

Regarding 2), it has been suggested that the duration would be the same as the max duration of a connectivity check transaction. Do we think that is enough, no matter how many media streams and components are used?


Go for it. It is much better than having nothing.


 

Regards,

 

Christer

 

 

 

 

 

 

 

 

 

From: Ice <ice-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Date: Friday, 3 May 2019 at 15.02
To: Justin Uberti <juberti@google.com>, Nils Ohlmeier <nohlmeier@mozilla.com>
Cc: Roman Shpount <roman@telurix.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?

 

Hi,

 

I don’t think there will be any interoperability issues. At the end of the day PAC is only about how long to wait for candidates, so the worse thing that can happen is than an agent declares ICE failure too early.

 

And, no matter whether an agent knows that the peer supports PAC or not,  it should aim at sending it’s candidates to its peer as soon as possible, depending on whatever local policies. The agent should not delay sending candidates just because it assumes that the peer will anyway wait for them.

 

Regards,

 

Christer

 

From: Justin Uberti <juberti@google.com>
Date: Thursday, 2 May 2019 at 22.28
To: Nils Ohlmeier <nohlmeier@mozilla.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Roman Shpount <roman@telurix.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?

 

 

 

On Thu, May 2, 2019 at 12:22 PM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

 




On May 2, 2019, at 12:13, Justin Uberti <juberti@google.com> wrote:

 

 

 

On Thu, May 2, 2019 at 10:07 AM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:


>> I do think Nils' point is important though, i.e., if we have a bad server it will take a very long time to decide on 'last set of candidates',
>> which is probably not helpful. As such I think the potential positions we can take are:
>> a) Start the timer as soon as we have an answer, regardless of any candidates.
>> b) a) + receipt of at least one remote candidate (or remote EOC). (This is Nils' suggestion).
>> c) a) + sending at least one local candidate (or local EOC).

As we are mostly concerned about the remote side: 1) not providing us with candidates, or 2) providing us with unusable candidates or 3) providing us with candidates really late I don’t see how option c) would help in any of these scenarios.
From my point of view we should choose either a) or b).

 

c) is just a clarification of a), in that you can't expect to receive prflx candidates until you've at least provided the other side with a candidate, so that may be the right time for the timer to start. I don't feel super strongly about this though. 

 

Ok. I hadn’t looked at it from that angle. So c) being a stronger a) I guess it would be okay.

 

I guess my only concern is that in Firefox we stopped doing a) because it caused to many problems. With that in mind would it cause interop problems if we leave up to the implementor to choose to implement either b) or c)?

 

I'd be fine with that, but I'd want to describe what to watch out for. Can you explain a bit more? 





>> b) has a problem if the remote side doesn't send any candidates, which we want to explicitly allow.
>
> True. 

Just to make sure we are all on the same page: b) is only a problem in the scenario where the remote side doesn’t send any candidates but also does not send EOC. 


The EOC should allow agents which explicitly don’t want to provide candidate to get the timer started soon.
I think that leaves us with scenarios where the remote doesn’t provide host candidates, and it’s reflexive or relay candidates take for ever because of slow servers.

 

Correct, but we can't control which endpoints will send us an EOC or not. So that will always be a possibility. 

 

Fair enough.





>> I tend to lean towards a) as the simplest option.
>
> Keep in mind that RFC 8445 is generic, so we need to to define what we mean by "answer". I guess it means some kind of indication that makes the agent assume that the remote peer has been contacted. In ice-sip-sdp we can then map that to an SDP answer.

Good point. We basically treat the SDP answer here to be something like an beginning of ICE, because we don’t have an explicit signal for that. I think in SDP based worlds there is no need for an extra signal like that. Not sure if other use cases of ICE would benefit from an explicit begin signal.

 

The answer in some ways is an explicit begin signal, because it contains the username/password information needed to start ICE checks. 

 

Yeah I didn’t see your reply before hitting send on mine. Using the availability sounds like a good idea as the minimum gating function/signal.

 

Best

  Nils

 


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



-- 
Surveillance is pervasive. Go Dark.
--------------40318308C313017A091D7A70-- From nobody Mon Jun 24 03:07:06 2019 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BED31202C3 for ; Mon, 24 Jun 2019 03:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOamPFu19uGf for ; Mon, 24 Jun 2019 03:07:01 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50082.outbound.protection.outlook.com [40.107.5.82]) (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 766021202D4 for ; Mon, 24 Jun 2019 03:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H4NiHwKO+82Z2diNP8GDKKYw6iadu93H3pdvwGFG7nE=; b=R1zKip8qWn76vE081QTj8cHk7mN2by+dxzbPyG4r6pMK8QETfQuQB7/NGGwdlgoDYQUUtoPVWUb/mcJNCFBxBz+LPU23IN48c/oCA5U9nV3JUFEdmIc2E/bjaa5tdUk5zkOGt4MJXT4rjolV4T04b033kPCqvAtsozvKuEtdY0U= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3257.eurprd07.prod.outlook.com (10.170.246.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.12; Mon, 24 Jun 2019 10:06:57 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd%7]) with mapi id 15.20.2008.014; Mon, 24 Jun 2019 10:06:57 +0000 From: Christer Holmberg To: Harald Alvestrand , Justin Uberti , Nils Ohlmeier CC: Roman Shpount , "ice@ietf.org" Thread-Topic: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart Thread-Index: AQHVFUwc5tNKLJLjCke9cDBba/EsEKao6YiAgAIHR4A= Date: Mon, 24 Jun 2019 10:06:57 +0000 Message-ID: <66678ADA-7C02-4D9D-B9D2-308873BC0125@ericsson.com> References: <1aa5aac7-af59-4e3b-8651-18f6e6431a2d@alvestrand.no> In-Reply-To: <1aa5aac7-af59-4e3b-8651-18f6e6431a2d@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ae615056-2f70-4f7e-3ed9-08d6f88bb152 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3257; x-ms-traffictypediagnostic: HE1PR07MB3257: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 007814487B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(136003)(366004)(396003)(346002)(51444003)(199004)(189003)(606006)(14454004)(81156014)(5660300002)(81166006)(316002)(6506007)(53936002)(6246003)(76176011)(6436002)(8676002)(11346002)(8936002)(110136005)(99286004)(2906002)(53546011)(6486002)(229853002)(33656002)(3846002)(58126008)(66446008)(66556008)(64756008)(6512007)(236005)(66476007)(73956011)(66946007)(6116002)(6306002)(54896002)(54906003)(44832011)(66066001)(446003)(486006)(86362001)(25786009)(71200400001)(71190400001)(76116006)(68736007)(36756003)(7736002)(966005)(4326008)(102836004)(26005)(14444005)(2616005)(256004)(476003)(478600001)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3257; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: sAOPfE4XVBskGb+rY2e5Ux2O4XCWft/T6DaDH9XFUJ6LkEObNy8xtl481+gUs4DrxzzTcdOIcRKSGC3dDWETCWHldUT0VRAZgGNzQoSnbiGIUsStePF8HQOK4TkrhIp1tG+p4sB/TlvRwU6ZAQDBTSQRRkkyjfWvCq/4pRHsHmyCo0I9TzYIVOvXKozx0mxLZH/JaCp3C1+RFvTR84AQJkA6xx7wbJtpRLh76Z8XUiLxYM9a85qQUFsVtQqs1lLCvCybfj7tj81szxaybaQHt+FLM/7w72Zm153V8LKVR6Oq+uqDSyq0f7YpvLoygvxzzLcXDDI6J+UW76oY6cK++BaCveoVYLN7lAzyZG7oC7YIeKuXnwDgI1wY7dPl/ZPfVMCFR+761bKKfX5As7lpZxlBMufNoEj52QgcYM10Vqo= Content-Type: multipart/alternative; boundary="_000_66678ADA7C024D9DB9D2308873BC0125ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ae615056-2f70-4f7e-3ed9-08d6f88bb152 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2019 10:06:57.6904 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3257 Archived-At: Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 10:07:05 -0000 --_000_66678ADA7C024D9DB9D2308873BC0125ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkdvIGZvciB3aGF0PyDwn5iKDQoNClJlZ2FyZGluZyAxKSwgZXZlbnRob3VnaCBpdOKA mXMgbm90IG15IHBlcnNvbmFsIHByZWZlcmVuY2UgdG8gc3RhcnQgdGhlIHRpbWVyIHdoZW4gdGhl IGZpcnN0IG9mZmVyL2Fuc3dlciBpcyBzZW50LCBJIGNvdWxkIGxpdmUgd2l0aCBpdC4NCg0KUmVn YXJkaW5nIDIpLCBob3dldmVyLCBJIHdvdWxkIHJlYWxseSBsaWtlIHNvbWUgaW5wdXQgb24gd2hl dGhlciB0aGUgZHVyYXRpb24gc2hvdWxkIGJlIGluZGVwZW5kZW50IG9mIHRoZSBudW1iZXIgb2Yg c3RyZWFtcywgY29tcG9uZW50cyBldGMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206 IEhhcmFsZCBBbHZlc3RyYW5kIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubz4NCkRhdGU6IFN1bmRheSwg MjMgSnVuZSAyMDE5IGF0IDkuMDgNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPiwgSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUuY29tPiwg TmlscyBPaGxtZWllciA8bm9obG1laWVyQG1vemlsbGEuY29tPg0KQ2M6IFJvbWFuIFNocG91bnQg PHJvbWFuQHRlbHVyaXguY29tPiwgImljZUBpZXRmLm9yZyIgPGljZUBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbSWNlXSBJQ0UgUEFDOiBXaGVuIHRvIHN0YXJ0IHRoZSB0aW1lciB3YWl0aW5nIGZv ciBwb3NzaWJsZSBwZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGVzPyAtIGRpc2N1c3Npb24gcmVzdGFy dA0KDQpPbiA1LzI4LzE5IDE6NTQgUE0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KSGksDQoN CldlIG5lZWQgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhpcy4NCg0KVGhlcmUgYXJlIHR3byBtYWlu IHF1ZXN0aW9ucyBhdCB0aGUgbW9tZW50Og0KDQoNCiAgMS4gIFdoZW4gZG9lcyBhbiBlbmRwb2lu dCBzdGFydCB0aGUgdGltZXIgKCJtaW5pbXVtLXRpbWUtdG8tcnVuLUlDRSIgdGltZXIsIGJhc2Vk IG9uIHByZXZpb3VzIGRpc2N1c3Npb25zKT8NCiAgMi4gIFdoYXQgaXMgdGhlIGR1cmF0aW9uIG9m IHRoZSB0aW1lcj8NCg0KUmVnYXJkaW5nIDEpLCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgcGVv cGxlIHN1Z2dlc3QgYWx0ZXJuYXRpdmUgYyksIHdoaWNoIHN0YXJ0cyB0aGUgdGltZXIgd2hlbiBh biBlbmRwb2ludCBoYXMgc2VudCAoaW4gYW4gb2ZmZXIgb3IgYW5zd2VyKSBhdCBsZWFzdCBvbmUg bG9jYWwgY2FuZGlkYXRlIChvciBFT0MpLg0KDQoNClJlZ2FyZGluZyAyKSwgaXQgaGFzIGJlZW4g c3VnZ2VzdGVkIHRoYXQgdGhlIGR1cmF0aW9uIHdvdWxkIGJlIHRoZSBzYW1lIGFzIHRoZSBtYXgg ZHVyYXRpb24gb2YgYSBjb25uZWN0aXZpdHkgY2hlY2sgdHJhbnNhY3Rpb24uIERvIHdlIHRoaW5r IHRoYXQgaXMgZW5vdWdoLCBubyBtYXR0ZXIgaG93IG1hbnkgbWVkaWEgc3RyZWFtcyBhbmQgY29t cG9uZW50cyBhcmUgdXNlZD8NCg0KDQoNCkdvIGZvciBpdC4gSXQgaXMgbXVjaCBiZXR0ZXIgdGhh biBoYXZpbmcgbm90aGluZy4NCg0KDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0K DQoNCg0KDQpGcm9tOiBJY2UgPGljZS1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86aWNlLWJvdW5j ZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPjxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t Pg0KRGF0ZTogRnJpZGF5LCAzIE1heSAyMDE5IGF0IDE1LjAyDQpUbzogSnVzdGluIFViZXJ0aSA8 anViZXJ0aUBnb29nbGUuY29tPjxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPiwgTmlscyBPaGxt ZWllciA8bm9obG1laWVyQG1vemlsbGEuY29tPjxtYWlsdG86bm9obG1laWVyQG1vemlsbGEuY29t Pg0KQ2M6IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPjxtYWlsdG86cm9tYW5AdGVs dXJpeC5jb20+LCAiaWNlQGlldGYub3JnIjxtYWlsdG86aWNlQGlldGYub3JnPiA8aWNlQGlldGYu b3JnPjxtYWlsdG86aWNlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJY2VdIElDRSBQQUM6IFdo ZW4gdG8gc3RhcnQgdGhlIHRpbWVyIHdhaXRpbmcgZm9yIHBvc3NpYmxlIHBlZXIgcmVmbGV4aXZl IGNhbmRpZGF0ZXM/DQoNCkhpLA0KDQpJIGRvbuKAmXQgdGhpbmsgdGhlcmUgd2lsbCBiZSBhbnkg aW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMuIEF0IHRoZSBlbmQgb2YgdGhlIGRheSBQQUMgaXMgb25s eSBhYm91dCBob3cgbG9uZyB0byB3YWl0IGZvciBjYW5kaWRhdGVzLCBzbyB0aGUgd29yc2UgdGhp bmcgdGhhdCBjYW4gaGFwcGVuIGlzIHRoYW4gYW4gYWdlbnQgZGVjbGFyZXMgSUNFIGZhaWx1cmUg dG9vIGVhcmx5Lg0KDQpBbmQsIG5vIG1hdHRlciB3aGV0aGVyIGFuIGFnZW50IGtub3dzIHRoYXQg dGhlIHBlZXIgc3VwcG9ydHMgUEFDIG9yIG5vdCwgIGl0IHNob3VsZCBhaW0gYXQgc2VuZGluZyBp dOKAmXMgY2FuZGlkYXRlcyB0byBpdHMgcGVlciBhcyBzb29uIGFzIHBvc3NpYmxlLCBkZXBlbmRp bmcgb24gd2hhdGV2ZXIgbG9jYWwgcG9saWNpZXMuIFRoZSBhZ2VudCBzaG91bGQgbm90IGRlbGF5 IHNlbmRpbmcgY2FuZGlkYXRlcyBqdXN0IGJlY2F1c2UgaXQgYXNzdW1lcyB0aGF0IHRoZSBwZWVy IHdpbGwgYW55d2F5IHdhaXQgZm9yIHRoZW0uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZy b206IEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29vZ2xlLmNvbT48bWFpbHRvOmp1YmVydGlAZ29v Z2xlLmNvbT4NCkRhdGU6IFRodXJzZGF5LCAyIE1heSAyMDE5IGF0IDIyLjI4DQpUbzogTmlscyBP aGxtZWllciA8bm9obG1laWVyQG1vemlsbGEuY29tPjxtYWlsdG86bm9obG1laWVyQG1vemlsbGEu Y29tPg0KQ2M6IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20+PG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+LCBSb21hbiBTaHBvdW50 IDxyb21hbkB0ZWx1cml4LmNvbT48bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPiwgImljZUBpZXRm Lm9yZyI8bWFpbHRvOmljZUBpZXRmLm9yZz4gPGljZUBpZXRmLm9yZz48bWFpbHRvOmljZUBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbSWNlXSBJQ0UgUEFDOiBXaGVuIHRvIHN0YXJ0IHRoZSB0aW1l ciB3YWl0aW5nIGZvciBwb3NzaWJsZSBwZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGVzPw0KDQoNCg0K T24gVGh1LCBNYXkgMiwgMjAxOSBhdCAxMjoyMiBQTSBOaWxzIE9obG1laWVyIDxub2hsbWVpZXJA bW96aWxsYS5jb208bWFpbHRvOm5vaGxtZWllckBtb3ppbGxhLmNvbT4+IHdyb3RlOg0KDQoNCg0K DQoNCk9uIE1heSAyLCAyMDE5LCBhdCAxMjoxMywgSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29n bGUuY29tPG1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KDQoNCk9uIFRodSwg TWF5IDIsIDIwMTkgYXQgMTA6MDcgQU0gTmlscyBPaGxtZWllciA8bm9obG1laWVyQG1vemlsbGEu Y29tPG1haWx0bzpub2hsbWVpZXJAbW96aWxsYS5jb20+PiB3cm90ZToNCg0KPj4gSSBkbyB0aGlu ayBOaWxzJyBwb2ludCBpcyBpbXBvcnRhbnQgdGhvdWdoLCBpLmUuLCBpZiB3ZSBoYXZlIGEgYmFk IHNlcnZlciBpdCB3aWxsIHRha2UgYSB2ZXJ5IGxvbmcgdGltZSB0byBkZWNpZGUgb24gJ2xhc3Qg c2V0IG9mIGNhbmRpZGF0ZXMnLA0KPj4gd2hpY2ggaXMgcHJvYmFibHkgbm90IGhlbHBmdWwuIEFz IHN1Y2ggSSB0aGluayB0aGUgcG90ZW50aWFsIHBvc2l0aW9ucyB3ZSBjYW4gdGFrZSBhcmU6DQo+ PiBhKSBTdGFydCB0aGUgdGltZXIgYXMgc29vbiBhcyB3ZSBoYXZlIGFuIGFuc3dlciwgcmVnYXJk bGVzcyBvZiBhbnkgY2FuZGlkYXRlcy4NCj4+IGIpIGEpICsgcmVjZWlwdCBvZiBhdCBsZWFzdCBv bmUgcmVtb3RlIGNhbmRpZGF0ZSAob3IgcmVtb3RlIEVPQykuIChUaGlzIGlzIE5pbHMnIHN1Z2dl c3Rpb24pLg0KPj4gYykgYSkgKyBzZW5kaW5nIGF0IGxlYXN0IG9uZSBsb2NhbCBjYW5kaWRhdGUg KG9yIGxvY2FsIEVPQykuDQoNCkFzIHdlIGFyZSBtb3N0bHkgY29uY2VybmVkIGFib3V0IHRoZSBy ZW1vdGUgc2lkZTogMSkgbm90IHByb3ZpZGluZyB1cyB3aXRoIGNhbmRpZGF0ZXMsIG9yIDIpIHBy b3ZpZGluZyB1cyB3aXRoIHVudXNhYmxlIGNhbmRpZGF0ZXMgb3IgMykgcHJvdmlkaW5nIHVzIHdp dGggY2FuZGlkYXRlcyByZWFsbHkgbGF0ZSBJIGRvbuKAmXQgc2VlIGhvdyBvcHRpb24gYykgd291 bGQgaGVscCBpbiBhbnkgb2YgdGhlc2Ugc2NlbmFyaW9zLg0KRnJvbSBteSBwb2ludCBvZiB2aWV3 IHdlIHNob3VsZCBjaG9vc2UgZWl0aGVyIGEpIG9yIGIpLg0KDQpjKSBpcyBqdXN0IGEgY2xhcmlm aWNhdGlvbiBvZiBhKSwgaW4gdGhhdCB5b3UgY2FuJ3QgZXhwZWN0IHRvIHJlY2VpdmUgcHJmbHgg Y2FuZGlkYXRlcyB1bnRpbCB5b3UndmUgYXQgbGVhc3QgcHJvdmlkZWQgdGhlIG90aGVyIHNpZGUg d2l0aCBhIGNhbmRpZGF0ZSwgc28gdGhhdCBtYXkgYmUgdGhlIHJpZ2h0IHRpbWUgZm9yIHRoZSB0 aW1lciB0byBzdGFydC4gSSBkb24ndCBmZWVsIHN1cGVyIHN0cm9uZ2x5IGFib3V0IHRoaXMgdGhv dWdoLg0KDQpPay4gSSBoYWRu4oCZdCBsb29rZWQgYXQgaXQgZnJvbSB0aGF0IGFuZ2xlLiBTbyBj KSBiZWluZyBhIHN0cm9uZ2VyIGEpIEkgZ3Vlc3MgaXQgd291bGQgYmUgb2theS4NCg0KSSBndWVz cyBteSBvbmx5IGNvbmNlcm4gaXMgdGhhdCBpbiBGaXJlZm94IHdlIHN0b3BwZWQgZG9pbmcgYSkg YmVjYXVzZSBpdCBjYXVzZWQgdG8gbWFueSBwcm9ibGVtcy4gV2l0aCB0aGF0IGluIG1pbmQgd291 bGQgaXQgY2F1c2UgaW50ZXJvcCBwcm9ibGVtcyBpZiB3ZSBsZWF2ZSB1cCB0byB0aGUgaW1wbGVt ZW50b3IgdG8gY2hvb3NlIHRvIGltcGxlbWVudCBlaXRoZXIgYikgb3IgYyk/DQoNCkknZCBiZSBm aW5lIHdpdGggdGhhdCwgYnV0IEknZCB3YW50IHRvIGRlc2NyaWJlIHdoYXQgdG8gd2F0Y2ggb3V0 IGZvci4gQ2FuIHlvdSBleHBsYWluIGEgYml0IG1vcmU/DQoNCg0KDQoNCg0KPj4gYikgaGFzIGEg cHJvYmxlbSBpZiB0aGUgcmVtb3RlIHNpZGUgZG9lc24ndCBzZW5kIGFueSBjYW5kaWRhdGVzLCB3 aGljaCB3ZSB3YW50IHRvIGV4cGxpY2l0bHkgYWxsb3cuDQo+DQo+IFRydWUuDQpKdXN0IHRvIG1h a2Ugc3VyZSB3ZSBhcmUgYWxsIG9uIHRoZSBzYW1lIHBhZ2U6IGIpIGlzIG9ubHkgYSBwcm9ibGVt IGluIHRoZSBzY2VuYXJpbyB3aGVyZSB0aGUgcmVtb3RlIHNpZGUgZG9lc27igJl0IHNlbmQgYW55 IGNhbmRpZGF0ZXMgYnV0IGFsc28gZG9lcyBub3Qgc2VuZCBFT0MuDQoNClRoZSBFT0Mgc2hvdWxk IGFsbG93IGFnZW50cyB3aGljaCBleHBsaWNpdGx5IGRvbuKAmXQgd2FudCB0byBwcm92aWRlIGNh bmRpZGF0ZSB0byBnZXQgdGhlIHRpbWVyIHN0YXJ0ZWQgc29vbi4NCkkgdGhpbmsgdGhhdCBsZWF2 ZXMgdXMgd2l0aCBzY2VuYXJpb3Mgd2hlcmUgdGhlIHJlbW90ZSBkb2VzbuKAmXQgcHJvdmlkZSBo b3N0IGNhbmRpZGF0ZXMsIGFuZCBpdOKAmXMgcmVmbGV4aXZlIG9yIHJlbGF5IGNhbmRpZGF0ZXMg dGFrZSBmb3IgZXZlciBiZWNhdXNlIG9mIHNsb3cgc2VydmVycy4NCg0KQ29ycmVjdCwgYnV0IHdl IGNhbid0IGNvbnRyb2wgd2hpY2ggZW5kcG9pbnRzIHdpbGwgc2VuZCB1cyBhbiBFT0Mgb3Igbm90 LiBTbyB0aGF0IHdpbGwgYWx3YXlzIGJlIGEgcG9zc2liaWxpdHkuDQoNCkZhaXIgZW5vdWdoLg0K DQoNCg0KDQoNCj4+IEkgdGVuZCB0byBsZWFuIHRvd2FyZHMgYSkgYXMgdGhlIHNpbXBsZXN0IG9w dGlvbi4NCj4NCj4gS2VlcCBpbiBtaW5kIHRoYXQgUkZDIDg0NDUgaXMgZ2VuZXJpYywgc28gd2Ug bmVlZCB0byB0byBkZWZpbmUgd2hhdCB3ZSBtZWFuIGJ5ICJhbnN3ZXIiLiBJIGd1ZXNzIGl0IG1l YW5zIHNvbWUga2luZCBvZiBpbmRpY2F0aW9uIHRoYXQgbWFrZXMgdGhlIGFnZW50IGFzc3VtZSB0 aGF0IHRoZSByZW1vdGUgcGVlciBoYXMgYmVlbiBjb250YWN0ZWQuIEluIGljZS1zaXAtc2RwIHdl IGNhbiB0aGVuIG1hcCB0aGF0IHRvIGFuIFNEUCBhbnN3ZXIuDQoNCkdvb2QgcG9pbnQuIFdlIGJh c2ljYWxseSB0cmVhdCB0aGUgU0RQIGFuc3dlciBoZXJlIHRvIGJlIHNvbWV0aGluZyBsaWtlIGFu IGJlZ2lubmluZyBvZiBJQ0UsIGJlY2F1c2Ugd2UgZG9u4oCZdCBoYXZlIGFuIGV4cGxpY2l0IHNp Z25hbCBmb3IgdGhhdC4gSSB0aGluayBpbiBTRFAgYmFzZWQgd29ybGRzIHRoZXJlIGlzIG5vIG5l ZWQgZm9yIGFuIGV4dHJhIHNpZ25hbCBsaWtlIHRoYXQuIE5vdCBzdXJlIGlmIG90aGVyIHVzZSBj YXNlcyBvZiBJQ0Ugd291bGQgYmVuZWZpdCBmcm9tIGFuIGV4cGxpY2l0IGJlZ2luIHNpZ25hbC4N Cg0KVGhlIGFuc3dlciBpbiBzb21lIHdheXMgaXMgYW4gZXhwbGljaXQgYmVnaW4gc2lnbmFsLCBi ZWNhdXNlIGl0IGNvbnRhaW5zIHRoZSB1c2VybmFtZS9wYXNzd29yZCBpbmZvcm1hdGlvbiBuZWVk ZWQgdG8gc3RhcnQgSUNFIGNoZWNrcy4NCg0KWWVhaCBJIGRpZG7igJl0IHNlZSB5b3VyIHJlcGx5 IGJlZm9yZSBoaXR0aW5nIHNlbmQgb24gbWluZS4gVXNpbmcgdGhlIGF2YWlsYWJpbGl0eSBzb3Vu ZHMgbGlrZSBhIGdvb2QgaWRlYSBhcyB0aGUgbWluaW11bSBnYXRpbmcgZnVuY3Rpb24vc2lnbmFs Lg0KDQpCZXN0DQogIE5pbHMNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KSWNlIG1haWxpbmcgbGlzdA0KDQpJY2VAaWV0Zi5vcmc8bWFp bHRvOkljZUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pY2UNCg0KDQoNCi0tDQoNClN1cnZlaWxsYW5jZSBpcyBwZXJ2YXNpdmUuIEdvIERhcmsuDQo= --_000_66678ADA7C024D9DB9D2308873BC0125ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdp bi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2 Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7fQ0K c3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzAuODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6NzgyNTc5OTg2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDM2NzI4MDUwO30N CkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjk0NjQ5OTcwMzsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIyMzgxOTE1OCA2NzY5ODcwNSA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R28gZm9yIHdoYXQ/IDxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcHBsZSBDb2xvciBFbW9qaSZxdW90OyI+JiMxMjg1MjI7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkaW5nIDEpLCBldmVu dGhvdWdoIGl04oCZcyBub3QgbXkgcGVyc29uYWwgcHJlZmVyZW5jZSB0byBzdGFydCB0aGUgdGlt ZXIgd2hlbiB0aGUgZmlyc3Qgb2ZmZXIvYW5zd2VyIGlzIHNlbnQsIEkgY291bGQgbGl2ZSB3aXRo IGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkaW5nIDIpLCBob3dldmVyLCBJIHdvdWxkIHJl YWxseSBsaWtlIHNvbWUgaW5wdXQgb24gd2hldGhlciB0aGUgZHVyYXRpb24gc2hvdWxkIGJlIGlu ZGVwZW5kZW50IG9mIHRoZSBudW1iZXIgb2Ygc3RyZWFtcywgY29tcG9uZW50cyBldGMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkhhcmFsZCBBbHZlc3RyYW5kICZsdDtoYXJhbGRAYWx2ZXN0cmFuZC5ubyZn dDs8YnI+DQo8Yj5EYXRlOiA8L2I+U3VuZGF5LCAyMyBKdW5lIDIwMTkgYXQgOS4wODxicj4NCjxi PlRvOiA8L2I+Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbSZndDssIEp1c3RpbiBVYmVydGkgJmx0O2p1YmVydGlAZ29vZ2xlLmNvbSZndDssIE5pbHMg T2hsbWVpZXIgJmx0O25vaGxtZWllckBtb3ppbGxhLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPlJv bWFuIFNocG91bnQgJmx0O3JvbWFuQHRlbHVyaXguY29tJmd0OywgJnF1b3Q7aWNlQGlldGYub3Jn JnF1b3Q7ICZsdDtpY2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWNl XSBJQ0UgUEFDOiBXaGVuIHRvIHN0YXJ0IHRoZSB0aW1lciB3YWl0aW5nIGZvciBwb3NzaWJsZSBw ZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGVzPyAtIGRpc2N1c3Npb24gcmVzdGFydDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNS8y OC8xOSAxOjU0IFBNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPldlIG5lZWQgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhpcy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPlRoZXJlIGFyZSB0d28gbWFpbiBxdWVzdGlvbnMgYXQgdGhlIG1vbWVu dDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4t dG9wOjBjbSIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj48c3BhbiBs YW5nPSJFTi1VUyI+V2hlbiBkb2VzIGFuIGVuZHBvaW50IHN0YXJ0IHRoZSB0aW1lciAoJnF1b3Q7 bWluaW11bS10aW1lLXRvLXJ1bi1JQ0UmcXVvdDsgdGltZXIsIGJhc2VkIG9uIHByZXZpb3VzIGRp c2N1c3Npb25zKT88L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+PHNw YW4gbGFuZz0iRU4tVVMiPldoYXQgaXMgdGhlIGR1cmF0aW9uIG9mIHRoZSB0aW1lcj88L3NwYW4+ PG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZGluZyAxKSwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0 IHBlb3BsZSBzdWdnZXN0IGFsdGVybmF0aXZlIGMpLCB3aGljaCBzdGFydHMgdGhlIHRpbWVyIHdo ZW4gYW4gZW5kcG9pbnQgaGFzIHNlbnQgKGluIGFuIG9mZmVyIG9yIGFuc3dlcikgYXQgbGVhc3Qg b25lIGxvY2FsIGNhbmRpZGF0ZSAob3IgRU9DKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5SZWdhcmRpbmcgMiksIGl0IGhhcyBiZWVuIHN1Z2dlc3RlZCB0aGF0IHRoZSBkdXJhdGlv biB3b3VsZCBiZSB0aGUgc2FtZSBhcyB0aGUgbWF4IGR1cmF0aW9uIG9mIGEgY29ubmVjdGl2aXR5 IGNoZWNrIHRyYW5zYWN0aW9uLiBEbyB3ZSB0aGluayB0aGF0IGlzIGVub3VnaCwgbm8gbWF0dGVy IGhvdyBtYW55IG1lZGlhIHN0cmVhbXMgYW5kIGNvbXBvbmVudHMgYXJlIHVzZWQ/PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cD5HbyBmb3IgaXQuIEl0IGlzIG11Y2ggYmV0dGVyIHRoYW4gaGF2aW5nIG5vdGhpbmcuPG86cD48 L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+SWNlDQo8YSBocmVmPSJtYWlsdG86aWNlLWJvdW5jZXNA aWV0Zi5vcmciPiZsdDtpY2UtYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+IG9uIGJlaGFsZiBvZiBD aHJpc3RlciBIb2xtYmVyZw0KPGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbSI+Jmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs8L2E+PGJyPg0K PGI+RGF0ZTogPC9iPkZyaWRheSwgMyBNYXkgMjAxOSBhdCAxNS4wMjxicj4NCjxiPlRvOiA8L2I+ SnVzdGluIFViZXJ0aSA8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIj4mbHQ7anVi ZXJ0aUBnb29nbGUuY29tJmd0OzwvYT4sIE5pbHMgT2hsbWVpZXINCjxhIGhyZWY9Im1haWx0bzpu b2hsbWVpZXJAbW96aWxsYS5jb20iPiZsdDtub2hsbWVpZXJAbW96aWxsYS5jb20mZ3Q7PC9hPjxi cj4NCjxiPkNjOiA8L2I+Um9tYW4gU2hwb3VudCA8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJp eC5jb20iPiZsdDtyb21hbkB0ZWx1cml4LmNvbSZndDs8L2E+LA0KPGEgaHJlZj0ibWFpbHRvOmlj ZUBpZXRmLm9yZyI+JnF1b3Q7aWNlQGlldGYub3JnJnF1b3Q7PC9hPiA8YSBocmVmPSJtYWlsdG86 aWNlQGlldGYub3JnIj4mbHQ7aWNlQGlldGYub3JnJmd0OzwvYT48YnI+DQo8Yj5TdWJqZWN0OiA8 L2I+UmU6IFtJY2VdIElDRSBQQUM6IFdoZW4gdG8gc3RhcnQgdGhlIHRpbWVyIHdhaXRpbmcgZm9y IHBvc3NpYmxlIHBlZXIgcmVmbGV4aXZlIGNhbmRpZGF0ZXM/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBkb27igJl0IHRoaW5rIHRoZXJlIHdpbGwgYmUgYW55 IGludGVyb3BlcmFiaWxpdHkgaXNzdWVzLiBBdCB0aGUgZW5kIG9mIHRoZSBkYXkgUEFDIGlzIG9u bHkgYWJvdXQgaG93IGxvbmcgdG8gd2FpdCBmb3IgY2FuZGlkYXRlcywgc28gdGhlIHdvcnNlIHRo aW5nIHRoYXQgY2FuIGhhcHBlbiBpcyB0aGFuIGFuIGFnZW50IGRlY2xhcmVzIElDRSBmYWlsdXJl IHRvbyBlYXJseS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFuZCwgbm8gbWF0dGVyIHdoZXRoZXIgYW4g YWdlbnQga25vd3MgdGhhdCB0aGUgcGVlciBzdXBwb3J0cyBQQUMgb3Igbm90LCAmbmJzcDtpdCBz aG91bGQgYWltIGF0IHNlbmRpbmcgaXTigJlzIGNhbmRpZGF0ZXMgdG8gaXRzIHBlZXIgYXMgc29v biBhcyBwb3NzaWJsZSwgZGVwZW5kaW5nIG9uIHdoYXRldmVyIGxvY2FsIHBvbGljaWVzLiBUaGUg YWdlbnQgc2hvdWxkIG5vdCBkZWxheSBzZW5kaW5nDQogY2FuZGlkYXRlcyBqdXN0IGJlY2F1c2Ug aXQgYXNzdW1lcyB0aGF0IHRoZSBwZWVyIHdpbGwgYW55d2F5IHdhaXQgZm9yIHRoZW0uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hyaXN0ZXI8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkp1c3RpbiBVYmVydGkNCjxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2ds ZS5jb20iPiZsdDtqdWJlcnRpQGdvb2dsZS5jb20mZ3Q7PC9hPjxicj4NCjxiPkRhdGU6IDwvYj5U aHVyc2RheSwgMiBNYXkgMjAxOSBhdCAyMi4yODxicj4NCjxiPlRvOiA8L2I+TmlscyBPaGxtZWll ciA8YSBocmVmPSJtYWlsdG86bm9obG1laWVyQG1vemlsbGEuY29tIj4mbHQ7bm9obG1laWVyQG1v emlsbGEuY29tJmd0OzwvYT48YnI+DQo8Yj5DYzogPC9iPkNocmlzdGVyIEhvbG1iZXJnIDxhIGhy ZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPiZsdDtjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PC9hPiwgUm9tYW4gU2hwb3VudA0KPGEgaHJlZj0ibWFp bHRvOnJvbWFuQHRlbHVyaXguY29tIj4mbHQ7cm9tYW5AdGVsdXJpeC5jb20mZ3Q7PC9hPiwgPGEg aHJlZj0ibWFpbHRvOmljZUBpZXRmLm9yZyI+DQomcXVvdDtpY2VAaWV0Zi5vcmcmcXVvdDs8L2E+ IDxhIGhyZWY9Im1haWx0bzppY2VAaWV0Zi5vcmciPiZsdDtpY2VAaWV0Zi5vcmcmZ3Q7PC9hPjxi cj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0ljZV0gSUNFIFBBQzogV2hlbiB0byBzdGFydCB0aGUg dGltZXIgd2FpdGluZyBmb3IgcG9zc2libGUgcGVlciByZWZsZXhpdmUgY2FuZGlkYXRlcz88L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFRodSwgTWF5IDIsIDIwMTkgYXQgMTI6MjIgUE0gTmlscyBPaGxtZWllciAmbHQ7PGEg aHJlZj0ibWFpbHRvOm5vaGxtZWllckBtb3ppbGxhLmNvbSI+bm9obG1laWVyQG1vemlsbGEuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gTWF5IDIsIDIwMTksIGF0IDEyOjEzLCBKdXN0aW4gVWJlcnRpICZsdDs8 YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0 aUBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1heSAyLCAyMDE5IGF0IDEwOjA3IEFNIE5pbHMg T2hsbWVpZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpub2hsbWVpZXJAbW96aWxsYS5jb20iIHRhcmdl dD0iX2JsYW5rIj5ub2hsbWVpZXJAbW96aWxsYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7Jmd0OyBJIGRvIHRoaW5rIE5p bHMnIHBvaW50IGlzIGltcG9ydGFudCB0aG91Z2gsIGkuZS4sIGlmIHdlIGhhdmUgYSBiYWQgc2Vy dmVyIGl0IHdpbGwgdGFrZSBhIHZlcnkgbG9uZyB0aW1lIHRvIGRlY2lkZSBvbiAnbGFzdCBzZXQg b2YgY2FuZGlkYXRlcycsDQo8YnI+DQomZ3Q7Jmd0OyB3aGljaCBpcyBwcm9iYWJseSBub3QgaGVs cGZ1bC4gQXMgc3VjaCBJIHRoaW5rIHRoZSBwb3RlbnRpYWwgcG9zaXRpb25zIHdlIGNhbiB0YWtl IGFyZTo8YnI+DQomZ3Q7Jmd0OyBhKSBTdGFydCB0aGUgdGltZXIgYXMgc29vbiBhcyB3ZSBoYXZl IGFuIGFuc3dlciwgcmVnYXJkbGVzcyBvZiBhbnkgY2FuZGlkYXRlcy48YnI+DQomZ3Q7Jmd0OyBi KSBhKSAmIzQzOyByZWNlaXB0IG9mIGF0IGxlYXN0IG9uZSByZW1vdGUgY2FuZGlkYXRlIChvciBy ZW1vdGUgRU9DKS4gKFRoaXMgaXMgTmlscycgc3VnZ2VzdGlvbikuPGJyPg0KJmd0OyZndDsgYykg YSkgJiM0Mzsgc2VuZGluZyBhdCBsZWFzdCBvbmUgbG9jYWwgY2FuZGlkYXRlIChvciBsb2NhbCBF T0MpLjxicj4NCjxicj4NCkFzIHdlIGFyZSBtb3N0bHkgY29uY2VybmVkIGFib3V0IHRoZSByZW1v dGUgc2lkZTogMSkgbm90IHByb3ZpZGluZyB1cyB3aXRoIGNhbmRpZGF0ZXMsIG9yIDIpIHByb3Zp ZGluZyB1cyB3aXRoIHVudXNhYmxlIGNhbmRpZGF0ZXMgb3IgMykgcHJvdmlkaW5nIHVzIHdpdGgg Y2FuZGlkYXRlcyByZWFsbHkgbGF0ZSBJIGRvbuKAmXQgc2VlIGhvdyBvcHRpb24gYykgd291bGQg aGVscCBpbiBhbnkgb2YgdGhlc2Ugc2NlbmFyaW9zLjxicj4NCkZyb20gbXkgcG9pbnQgb2Ygdmll dyB3ZSBzaG91bGQgY2hvb3NlIGVpdGhlciBhKSBvciBiKS48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmMpIGlzIGp1c3QgYSBjbGFy aWZpY2F0aW9uIG9mIGEpLCBpbiB0aGF0IHlvdSBjYW4ndCBleHBlY3QgdG8gcmVjZWl2ZSBwcmZs eCBjYW5kaWRhdGVzIHVudGlsIHlvdSd2ZSBhdCBsZWFzdCBwcm92aWRlZCB0aGUgb3RoZXIgc2lk ZSB3aXRoIGEgY2FuZGlkYXRlLCBzbyB0aGF0IG1heSBiZSB0aGUgcmlnaHQgdGltZSBmb3IgdGhl IHRpbWVyIHRvIHN0YXJ0LiBJIGRvbid0IGZlZWwgc3VwZXIgc3Ryb25nbHkgYWJvdXQNCiB0aGlz IHRob3VnaC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Pay4gSSBoYWRu4oCZ dCBsb29rZWQgYXQgaXQgZnJvbSB0aGF0IGFuZ2xlLiBTbyBjKSBiZWluZyBhIHN0cm9uZ2VyIGEp IEkgZ3Vlc3MgaXQgd291bGQgYmUgb2theS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBndWVzcyBteSBvbmx5IGNvbmNlcm4gaXMgdGhhdCBp biBGaXJlZm94IHdlIHN0b3BwZWQgZG9pbmcgYSkgYmVjYXVzZSBpdCBjYXVzZWQgdG8gbWFueSBw cm9ibGVtcy4gV2l0aCB0aGF0IGluIG1pbmQgd291bGQgaXQgY2F1c2UgaW50ZXJvcCBwcm9ibGVt cyBpZiB3ZSBsZWF2ZSB1cCB0byB0aGUgaW1wbGVtZW50b3IgdG8gY2hvb3NlIHRvIGltcGxlbWVu dCBlaXRoZXIgYikgb3IgYyk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdkIGJlIGZpbmUgd2l0aCB0 aGF0LCBidXQgSSdkIHdhbnQgdG8gZGVzY3JpYmUgd2hhdCB0byB3YXRjaCBvdXQgZm9yLiBDYW4g eW91IGV4cGxhaW4gYSBiaXQgbW9yZT8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBj bTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZndDsm Z3Q7IGIpIGhhcyBhIHByb2JsZW0gaWYgdGhlIHJlbW90ZSBzaWRlIGRvZXNuJ3Qgc2VuZCBhbnkg Y2FuZGlkYXRlcywgd2hpY2ggd2Ugd2FudCB0byBleHBsaWNpdGx5IGFsbG93Lg0KPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFRydWUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkp1c3QgdG8gbWFrZSBzdXJlIHdlIGFyZSBhbGwgb24gdGhlIHNhbWUgcGFn ZTogYikgaXMgb25seSBhIHByb2JsZW0gaW4gdGhlIHNjZW5hcmlvIHdoZXJlIHRoZSByZW1vdGUg c2lkZSBkb2VzbuKAmXQgc2VuZCBhbnkgY2FuZGlkYXRlcyBidXQgYWxzbyBkb2VzIG5vdCBzZW5k IEVPQy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KVGhlIEVPQyBzaG91bGQgYWxsb3cgYWdlbnRzIHdoaWNoIGV4cGxpY2l0bHkgZG9u4oCZ dCB3YW50IHRvIHByb3ZpZGUgY2FuZGlkYXRlIHRvIGdldCB0aGUgdGltZXIgc3RhcnRlZCBzb29u Ljxicj4NCkkgdGhpbmsgdGhhdCBsZWF2ZXMgdXMgd2l0aCBzY2VuYXJpb3Mgd2hlcmUgdGhlIHJl bW90ZSBkb2VzbuKAmXQgcHJvdmlkZSBob3N0IGNhbmRpZGF0ZXMsIGFuZCBpdOKAmXMgcmVmbGV4 aXZlIG9yIHJlbGF5IGNhbmRpZGF0ZXMgdGFrZSBmb3IgZXZlciBiZWNhdXNlIG9mIHNsb3cgc2Vy dmVycy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkNvcnJlY3QsIGJ1dCB3ZSBjYW4ndCBjb250cm9sIHdoaWNoIGVuZHBvaW50cyB3 aWxsIHNlbmQgdXMgYW4gRU9DIG9yIG5vdC4gU28gdGhhdCB3aWxsIGFsd2F5cyBiZSBhIHBvc3Np YmlsaXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZhaXIgZW5vdWdoLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyZndDsgSSB0ZW5kIHRvIGxlYW4gdG93YXJkcyBhKSBh cyB0aGUgc2ltcGxlc3Qgb3B0aW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBLZWVwIGluIG1pbmQg dGhhdCBSRkMgODQ0NSBpcyBnZW5lcmljLCBzbyB3ZSBuZWVkIHRvIHRvIGRlZmluZSB3aGF0IHdl IG1lYW4gYnkgJnF1b3Q7YW5zd2VyJnF1b3Q7LiBJIGd1ZXNzIGl0IG1lYW5zIHNvbWUga2luZCBv ZiBpbmRpY2F0aW9uIHRoYXQgbWFrZXMgdGhlIGFnZW50IGFzc3VtZSB0aGF0IHRoZSByZW1vdGUg cGVlciBoYXMgYmVlbiBjb250YWN0ZWQuIEluIGljZS1zaXAtc2RwIHdlIGNhbiB0aGVuIG1hcCB0 aGF0IHRvIGFuIFNEUCBhbnN3ZXIuPGJyPg0KPGJyPg0KR29vZCBwb2ludC4gV2UgYmFzaWNhbGx5 IHRyZWF0IHRoZSBTRFAgYW5zd2VyIGhlcmUgdG8gYmUgc29tZXRoaW5nIGxpa2UgYW4gYmVnaW5u aW5nIG9mIElDRSwgYmVjYXVzZSB3ZSBkb27igJl0IGhhdmUgYW4gZXhwbGljaXQgc2lnbmFsIGZv ciB0aGF0LiBJIHRoaW5rIGluIFNEUCBiYXNlZCB3b3JsZHMgdGhlcmUgaXMgbm8gbmVlZCBmb3Ig YW4gZXh0cmEgc2lnbmFsIGxpa2UgdGhhdC4gTm90IHN1cmUgaWYgb3RoZXIgdXNlIGNhc2VzIG9m IElDRSB3b3VsZA0KIGJlbmVmaXQgZnJvbSBhbiBleHBsaWNpdCBiZWdpbiBzaWduYWwuPG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgYW5zd2VyIGluIHNvbWUgd2F5cyBpcyBhbiBleHBsaWNpdCBiZWdpbiBzaWduYWwsIGJlY2F1 c2UgaXQgY29udGFpbnMgdGhlIHVzZXJuYW1lL3Bhc3N3b3JkIGluZm9ybWF0aW9uIG5lZWRlZCB0 byBzdGFydCBJQ0UgY2hlY2tzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlll YWggSSBkaWRu4oCZdCBzZWUgeW91ciByZXBseSBiZWZvcmUgaGl0dGluZyBzZW5kIG9uIG1pbmUu IFVzaW5nIHRoZSBhdmFpbGFiaWxpdHkgc291bmRzIGxpa2UgYSBnb29kIGlkZWEgYXMgdGhlIG1p bmltdW0gZ2F0aW5nIGZ1bmN0aW9uL3NpZ25hbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IE5pbHM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5JY2UgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRv OkljZUBpZXRmLm9yZyI+SWNlQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZTwvYT48bzpwPjwvbzpwPjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPlN1cnZlaWxsYW5jZSBpcyBwZXJ2YXNpdmUuIEdvIERhcmsuPG86cD48 L286cD48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_66678ADA7C024D9DB9D2308873BC0125ericssoncom_-- From nobody Mon Jun 24 06:20:26 2019 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE29412027E for ; Mon, 24 Jun 2019 06:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 A2bfZg0fINd7 for ; Mon, 24 Jun 2019 06:20:21 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B50B12010C for ; Mon, 24 Jun 2019 06:20:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id DC0F37C34E9; Mon, 24 Jun 2019 15:20:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO9gfyNt41-o; Mon, 24 Jun 2019 15:20:07 +0200 (CEST) Received: from [IPv6:2620:f:8000:210:13f2:d048:4384:5c7e] (unknown [IPv6:2620:f:8000:210:13f2:d048:4384:5c7e]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7C4E57C3C4D; Mon, 24 Jun 2019 15:19:49 +0200 (CEST) To: Christer Holmberg , Justin Uberti , Nils Ohlmeier Cc: Roman Shpount , "ice@ietf.org" References: <1aa5aac7-af59-4e3b-8651-18f6e6431a2d@alvestrand.no> <66678ADA-7C02-4D9D-B9D2-308873BC0125@ericsson.com> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= mQINBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABtC9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPokCPgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryG5Ag0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAGJAiUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <7a829bc0-d066-a3be-b7be-9b39ce799821@alvestrand.no> Date: Mon, 24 Jun 2019 15:19:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <66678ADA-7C02-4D9D-B9D2-308873BC0125@ericsson.com> Content-Type: multipart/alternative; boundary="------------6B270AC58DBB5D3800241DC5" Content-Language: en-GB Archived-At: Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 13:20:25 -0000 This is a multi-part message in MIME format. --------------6B270AC58DBB5D3800241DC5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 6/24/19 12:06 PM, Christer Holmberg wrote: > > Hi, > >   > > Go for what? 😊 > I was noting the month of silence, and thinking that I should encoruage a decision to be taken - "analysis paralysis" is not a good thing! >   > > Regarding 1), eventhough it’s not my personal preference to start the > timer when the first offer/answer is sent, I could live with it. > It's a well defined time, and is observable by the entity that has to act when the timer expires, so I think it is much better than "undefined". That's my requirement :-) >   > > Regarding 2), however, I would really like some input on whether the > duration should be independent of the number of streams, components etc. > I think having a single number is preferable to having a complex number that could change over time (for instance, if we don't reset the timer when adding streams, then adding or removing streams after the timer started will lead to hard-to-define behavior). But my main concern is that we get this stuff done and get the basic timer mechanism into interoperable code - having a spec to implement from now is better than having a spec that has had slightly more discussion, but no fundamental changes, 6 months from now. >   > > Regards, > >   > > Christer > >   > > *From: *Harald Alvestrand > *Date: *Sunday, 23 June 2019 at 9.08 > *To: *Christer Holmberg , Justin > Uberti , Nils Ohlmeier > *Cc: *Roman Shpount , "ice@ietf.org" > *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting for > possible peer reflexive candidates? - discussion restart > >   > > On 5/28/19 1:54 PM, Christer Holmberg wrote: > > Hi, > >   > > We need to move forward with this. > >   > > There are two main questions at the moment: > >   > > 1. When does an endpoint start the timer > ("minimum-time-to-run-ICE" timer, based on previous discussions)? > 2. What is the duration of the timer? > >   > > Regarding 1), my understanding is that people suggest alternative > c), which starts the timer when an endpoint has sent (in an offer > or answer) at least one local candidate (or EOC). > >   > >   > > Regarding 2), it has been suggested that the duration would be the > same as the max duration of a connectivity check transaction. Do > we think that is enough, no matter how many media streams and > components are used? > >   > > Go for it. It is much better than having nothing. > >   > >   > > Regards, > >   > > Christer > >   > >   > >   > >   > >   > >   > >   > >   > >   > > *From: *Ice > on behalf of Christer Holmberg > > *Date: *Friday, 3 May 2019 at 15.02 > *To: *Justin Uberti > , Nils Ohlmeier > > *Cc: *Roman Shpount > , "ice@ietf.org" > > *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting for > possible peer reflexive candidates? > >   > > Hi, > >   > > I don’t think there will be any interoperability issues. At the > end of the day PAC is only about how long to wait for candidates, > so the worse thing that can happen is than an agent declares ICE > failure too early. > >   > > And, no matter whether an agent knows that the peer supports PAC > or not,  it should aim at sending it’s candidates to its peer as > soon as possible, depending on whatever local policies. The agent > should not delay sending candidates just because it assumes that > the peer will anyway wait for them. > >   > > Regards, > >   > > Christer > >   > > *From: *Justin Uberti > *Date: *Thursday, 2 May 2019 at 22.28 > *To: *Nils Ohlmeier > > *Cc: *Christer Holmberg > , Roman Shpount > , "ice@ietf.org" > > *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting for > possible peer reflexive candidates? > >   > >   > >   > > On Thu, May 2, 2019 at 12:22 PM Nils Ohlmeier > > wrote: > >   > > > > > > On May 2, 2019, at 12:13, Justin Uberti > > wrote: > >   > >   > >   > > On Thu, May 2, 2019 at 10:07 AM Nils Ohlmeier > > wrote: > > > >> I do think Nils' point is important though, i.e., > if we have a bad server it will take a very long time > to decide on 'last set of candidates', > >> which is probably not helpful. As such I think the > potential positions we can take are: > >> a) Start the timer as soon as we have an answer, > regardless of any candidates. > >> b) a) + receipt of at least one remote candidate > (or remote EOC). (This is Nils' suggestion). > >> c) a) + sending at least one local candidate (or > local EOC). > > As we are mostly concerned about the remote side: 1) > not providing us with candidates, or 2) providing us > with unusable candidates or 3) providing us with > candidates really late I don’t see how option c) would > help in any of these scenarios. > From my point of view we should choose either a) or b). > >   > > c) is just a clarification of a), in that you can't expect > to receive prflx candidates until you've at least provided > the other side with a candidate, so that may be the right > time for the timer to start. I don't feel super strongly > about this though.  > >   > > Ok. I hadn’t looked at it from that angle. So c) being a > stronger a) I guess it would be okay. > >   > > I guess my only concern is that in Firefox we stopped doing a) > because it caused to many problems. With that in mind would it > cause interop problems if we leave up to the implementor to > choose to implement either b) or c)? > >   > > I'd be fine with that, but I'd want to describe what to watch out > for. Can you explain a bit more?  > > > > > > > >> b) has a problem if the remote side doesn't send > any candidates, which we want to explicitly allow. > > > > True.  > > Just to make sure we are all on the same page: b) is > only a problem in the scenario where the remote side > doesn’t send any candidates but also does not send EOC.  > > > The EOC should allow agents which explicitly don’t > want to provide candidate to get the timer started soon. > I think that leaves us with scenarios where the remote > doesn’t provide host candidates, and it’s reflexive or > relay candidates take for ever because of slow servers. > >   > > Correct, but we can't control which endpoints will send us > an EOC or not. So that will always be a possibility.  > >   > > Fair enough. > > > > > > > >> I tend to lean towards a) as the simplest option. > > > > Keep in mind that RFC 8445 is generic, so we need to > to define what we mean by "answer". I guess it means > some kind of indication that makes the agent assume > that the remote peer has been contacted. In > ice-sip-sdp we can then map that to an SDP answer. > > Good point. We basically treat the SDP answer here to > be something like an beginning of ICE, because we > don’t have an explicit signal for that. I think in SDP > based worlds there is no need for an extra signal like > that. Not sure if other use cases of ICE would benefit > from an explicit begin signal. > >   > > The answer in some ways is an explicit begin signal, > because it contains the username/password information > needed to start ICE checks.  > >   > > Yeah I didn’t see your reply before hitting send on mine. > Using the availability sounds like a good idea as the minimum > gating function/signal. > >   > > Best > >   Nils > >   > > > > _______________________________________________ > > Ice mailing list > > Ice@ietf.org > > https://www.ietf.org/mailman/listinfo/ice > >   > > -- > Surveillance is pervasive. Go Dark. -- Surveillance is pervasive. Go Dark. --------------6B270AC58DBB5D3800241DC5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/24/19 12:06 PM, Christer Holmberg wrote:

Hi,

 

Go for what? 😊

I was noting the month of silence, and thinking that I should encoruage a decision to be taken - "analysis paralysis" is not a good thing!

 

Regarding 1), eventhough it’s not my personal preference to start the timer when the first offer/answer is sent, I could live with it.


It's a well defined time, and is observable by the entity that has to act when the timer expires, so I think it is much better than "undefined".

That's my requirement :-)


 

Regarding 2), however, I would really like some input on whether the duration should be independent of the number of streams, components etc.

I think having a single number is preferable to having a complex number that could change over time (for instance, if we don't reset the timer when adding streams, then adding or removing streams after the timer started will lead to hard-to-define behavior).


But my main concern is that we get this stuff done and get the basic timer mechanism into interoperable code - having a spec to implement from now is better than having a spec that has had slightly more discussion, but no fundamental changes, 6 months from now.


 

Regards,

 

Christer

 

From: Harald Alvestrand <harald@alvestrand.no>
Date: Sunday, 23 June 2019 at 9.08
To: Christer Holmberg <christer.holmberg@ericsson.com>, Justin Uberti <juberti@google.com>, Nils Ohlmeier <nohlmeier@mozilla.com>
Cc: Roman Shpount <roman@telurix.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart

 

On 5/28/19 1:54 PM, Christer Holmberg wrote:

Hi,

 

We need to move forward with this.

 

There are two main questions at the moment:

 

  1. When does an endpoint start the timer ("minimum-time-to-run-ICE" timer, based on previous discussions)?
  2. What is the duration of the timer?

 

Regarding 1), my understanding is that people suggest alternative c), which starts the timer when an endpoint has sent (in an offer or answer) at least one local candidate (or EOC).

 

 

Regarding 2), it has been suggested that the duration would be the same as the max duration of a connectivity check transaction. Do we think that is enough, no matter how many media streams and components are used?

 

Go for it. It is much better than having nothing.

 

 

Regards,

 

Christer

 

 

 

 

 

 

 

 

 

From: Ice <ice-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Date: Friday, 3 May 2019 at 15.02
To: Justin Uberti <juberti@google.com>, Nils Ohlmeier <nohlmeier@mozilla.com>
Cc: Roman Shpount <roman@telurix.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?

 

Hi,

 

I don’t think there will be any interoperability issues. At the end of the day PAC is only about how long to wait for candidates, so the worse thing that can happen is than an agent declares ICE failure too early.

 

And, no matter whether an agent knows that the peer supports PAC or not,  it should aim at sending it’s candidates to its peer as soon as possible, depending on whatever local policies. The agent should not delay sending candidates just because it assumes that the peer will anyway wait for them.

 

Regards,

 

Christer

 

From: Justin Uberti <juberti@google.com>
Date: Thursday, 2 May 2019 at 22.28
To: Nils Ohlmeier <nohlmeier@mozilla.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Roman Shpount <roman@telurix.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?

 

 

 

On Thu, May 2, 2019 at 12:22 PM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

 





On May 2, 2019, at 12:13, Justin Uberti <juberti@google.com> wrote:

 

 

 

On Thu, May 2, 2019 at 10:07 AM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:


>> I do think Nils' point is important though, i.e., if we have a bad server it will take a very long time to decide on 'last set of candidates',
>> which is probably not helpful. As such I think the potential positions we can take are:
>> a) Start the timer as soon as we have an answer, regardless of any candidates.
>> b) a) + receipt of at least one remote candidate (or remote EOC). (This is Nils' suggestion).
>> c) a) + sending at least one local candidate (or local EOC).

As we are mostly concerned about the remote side: 1) not providing us with candidates, or 2) providing us with unusable candidates or 3) providing us with candidates really late I don’t see how option c) would help in any of these scenarios.
From my point of view we should choose either a) or b).

 

c) is just a clarification of a), in that you can't expect to receive prflx candidates until you've at least provided the other side with a candidate, so that may be the right time for the timer to start. I don't feel super strongly about this though. 

 

Ok. I hadn’t looked at it from that angle. So c) being a stronger a) I guess it would be okay.

 

I guess my only concern is that in Firefox we stopped doing a) because it caused to many problems. With that in mind would it cause interop problems if we leave up to the implementor to choose to implement either b) or c)?

 

I'd be fine with that, but I'd want to describe what to watch out for. Can you explain a bit more? 






>> b) has a problem if the remote side doesn't send any candidates, which we want to explicitly allow.
>
> True. 

Just to make sure we are all on the same page: b) is only a problem in the scenario where the remote side doesn’t send any candidates but also does not send EOC. 


The EOC should allow agents which explicitly don’t want to provide candidate to get the timer started soon.
I think that leaves us with scenarios where the remote doesn’t provide host candidates, and it’s reflexive or relay candidates take for ever because of slow servers.

 

Correct, but we can't control which endpoints will send us an EOC or not. So that will always be a possibility. 

 

Fair enough.






>> I tend to lean towards a) as the simplest option.
>
> Keep in mind that RFC 8445 is generic, so we need to to define what we mean by "answer". I guess it means some kind of indication that makes the agent assume that the remote peer has been contacted. In ice-sip-sdp we can then map that to an SDP answer.

Good point. We basically treat the SDP answer here to be something like an beginning of ICE, because we don’t have an explicit signal for that. I think in SDP based worlds there is no need for an extra signal like that. Not sure if other use cases of ICE would benefit from an explicit begin signal.

 

The answer in some ways is an explicit begin signal, because it contains the username/password information needed to start ICE checks. 

 

Yeah I didn’t see your reply before hitting send on mine. Using the availability sounds like a good idea as the minimum gating function/signal.

 

Best

  Nils

 



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

 

-- 
Surveillance is pervasive. Go Dark.


-- 
Surveillance is pervasive. Go Dark.
--------------6B270AC58DBB5D3800241DC5-- From nobody Fri Jun 28 16:08:46 2019 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 6EBF8120A63; Fri, 28 Jun 2019 15:58:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: adam@nostrum.com, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176269344.11015.6379275141133488714.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:58:13 -0700 Archived-At: Subject: [Ice] ice - Requested session has been scheduled for IETF 105 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 23:07:25 -0000 Dear Peter Thatcher, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ice Session 1 (1:00 requested) Friday, 26 July 2019, Morning Session I 1000-1200 Room Name: Notre Dame size: 50 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/ice.ics Request Information: --------------------------------------------------------- Working Group Name: Interactive Connectivity Establishment Area Name: Applications and Real-Time Area Session Requester: Peter Thatcher Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 15 Conflicts to Avoid: First Priority: rtcweb mmusic quic avtcore People who must be present: Adam Roach Ari Keranen Peter Thatcher Resources Requested: Special Requests: ---------------------------------------------------------