From nobody Sat Jul 8 18:14:55 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2299412F28C for ; Sat, 8 Jul 2017 18:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 txTW831xBWbI for ; Sat, 8 Jul 2017 18:14:52 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 16DB3126CC7 for ; Sat, 8 Jul 2017 18:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1499562891; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GUel/VbLEBDt5Dgi+nPQYL37z+31FT8SwGtdVy87GTU=; b=l7Zb687J6/l0UhV/HInpfQIEQZz53sAghRwc3olAK9So8o9Bsurb6ejxZ5/m5mnn Gg5Bi67HtzLnWahlwaTWEh1pOsdkXaSSXbD/LAcLVIkuUfhfW6Jaouzsgxy8Zig4 cbcqvMRqfWXlIy+scnZ0JiB+mXMB038achFGkB/pw/Tcdj/p2uQ6Zq0Kh0iXqjuh jSb+PelbOwqTdGdYg3Bu5BMrOmc0jeFRXnNhR7xSSFOE8fPZ9ZAawaraxAMNOAAq 7zhsY1HS+Ovy9muipi2xBS9w5p8EzRe65U86RpiGy7VmiZOkAoKugfaxxQv0+KSG PsUr9Xe3IlZholtvjQH8kA==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 28.42.07214.B8381695; Sat, 8 Jul 2017 18:14:51 -0700 (PDT) X-AuditID: 11973e11-327ff70000001c2e-ac-5961838b8817 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by relay3.apple.com (Apple SCV relay) with SMTP id B3.2E.09863.B8381695; Sat, 8 Jul 2017 18:14:51 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_y9zhcJ7zkYggclu4gjLNKQ)" Received: from [17.234.122.247] (unknown [17.234.122.247]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSS00CXUU4QGO10@nwk-mmpp-sz13.apple.com>; Sat, 08 Jul 2017 18:14:51 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Sat, 08 Jul 2017 18:14:50 -0700 In-reply-to: Cc: "Eric Vyncke (evyncke)" , "captive-portals@ietf.org" , David Bird To: Dave Dolson References: <201705031442.50683.heiko.folkerts@bsi.bund.de> <1BB90528-B35F-43F0-AF18-0215DC735FF0@cable.comcast.com> <754719c5-c74c-fbdc-405e-b8c91478c0a5@netcologne.de> X-Mailer: Apple Mail (2.3439) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUi2FAYrNvdnBhpMPOvpsXcWQ2sFp9+bGe0 2LrsIbvFl/0LGB1YPKb83sjqsWBTqceSJT+ZPL5u3s4awBLFZZOSmpNZllqkb5fAlfFi3jzG ggvTmSpmz9jK1sB47jNjFyMnh4SAicS+hklsXYxcHEICq5kkvl9pZ4VJXHk8gxEicYhRYn7j B2aQBK+AoMSPyfdYQGxmgTCJuQ872SGKJjNJzPl0Eqibg0NYQEJi855EkBo2ARWJ4982QPXa SNzec4kdxBYWcJc49uIN2BUsAqoSP7atAbM5BQIk3i4/zAwyk1mgk1FiwoYdYM0iAmoSS298 YoVY1skmMbF5EQvIMgkBWYmlf0JA4hICi9glPu3fyjaBUWgWkmNnITl2FlALs4C6xJQpuRBh bYkn7y6wQthqEgt/L2JCFl/AyLaKUSg3MTNHNzPPSC+xoCAnVS85P3cTIyhuptsJ7mA8vsrq EKMAB6MSD+8HicRIIdbEsuLK3EOM0hwsSuK8YqfiIoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SgHj4czStuUxO14v2r0sbwaTcrvxkxl/1WdLz15ceOq8oLjp74WXp3G+ago4qfLUrrllKVvD uU25/XtzFm0N93GQUNiwuHTfiy3XGdkuLTvJOEM1ymjSzLhppY41u08/WiTWvfC2ihS3wpnY gPypqndz7pkp9Es9nCa37o3v5579tpon7D/u2XkySomlOCPRUIu5qDgRAEbLzNl8AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsUi2FB8Q7e7OTHSYOoEZYu5sxpYLT792M5o sXXZQ3aLL/sXMDqweEz5vZHVY8GmUo8lS34yeXzdvJ01gCXK2iYtv6g8sShFoSi5oMRWqTgj MSW/PN7S2MjUIbGgICdVLzk/V0nfziYlNSezLLUImZVgnfFi3jzGggvTmSpmz9jK1sB47jNj FyMnh4SAicSVxzOAbC4OIYFDjBLzGz8wgyR4BQQlfky+xwJiMwuEScx92MkOUTSZSWLOp5Os XYwcHMICEhKb9ySC1LAJqEgc/7YBqtdG4vaeS+wgtrCAu8SxF2/AlrEIqEr82LYGzOYUCJB4 u/wwM8hMZoFORokJG3aANYsIqEksvfGJFWJZJ5vExOZFLCDLJARkJZb+CZnAyD8LyX2zkNw3 C6iKWUBdYsqUXIiwtsSTdxdYIWw1iYW/FzEhiy9gZFvFKFCUmpNYaawHD8FNjOBIKgzewfhn mdUhRgEORiUeXg/pxEgh1sSy4spcYCBxMCuJ8E7kAgrxpiRWVqUW5ccXleakFh9i3M8I9OVE ZinR5HxgnOeVxBsaWxhbmlgYGJhYmpkQFjYxMTAxNjYzNjY3MaelsJI4rwlfbKSQQHpiSWp2 ampBahHMC0wcnFINjEJGy41OiP1YbLkgsuJb/bcm8dtCLaFPtvi35G76ddJaYuPOJTleN95v +XXS+NWiMBeB1q1BF6/myW+O35m3L7c46ml/IL+jUM3hkuKNp7InxnBEmE73jhVdnNO7bG/v /mOpWkcy57yKacva0ytwMSqxPFngsb7QnGPs3y8ffqH8I3z7b0ehDiUWYPo21GIuKk4EAGVD 55JFAwAA Archived-At: Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal" X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 01:14:54 -0000 --Boundary_(ID_y9zhcJ7zkYggclu4gjLNKQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Jun 27, 2017, at 12:46 PM, Dave Dolson = wrote: >=20 > Eric, > Do I understand correctly from = https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-00#= section-5.5 = > that the intention is for the JSON key =E2=80=9CcaptivePortal=E2=80=9D = to indicate that the specified URL is to be visited by the browser to = navigate the requirements for exiting captivity? > =20 > If so, would you say this URL should be used in place of performing a = capport detection strategy (e.g., canary HTTP request)? The idea with explicit PvD discovery is that it would, as a step, = replace a separate captive portal detection strategy. My overall concern with discovery mechanisms that are specific to only = captive portals is that this is an extra step that is performed = potentially on every network association, that may have limited = extensibility for non-captive use cases. Since the explicit PvD design = promises a way to discover many properties beyond captivity, and is = bootstrapped very early on in the network association, it should = hopefully allow clients to avoid the extra probe. > =20 > =20 > =20 > Note: the same =E2=80=9CcaptivePortal=E2=80=9D key is also defined in = section 5.3 as a Boolean. Should I consider this to be a defect in the = draft, or am I missing something? The updated version of the draft = (https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-01= = ) leaves out the specific keys for captive portals, and discusses it = more abstractly. That would be a good thing to nail down at the Prague = meeting. If PvD detection is done generically on network association, = then a boolean or some way to indicate that this is *not* a captive = portal will allow the device to not perform extra probing. If there is a = captive network, we should be able to get the page or instructions on = how to get beyond captivity. Thanks, Tommy > =20 > -Dave > =20 > =20 > =20 > From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com]=20 > Sent: Sunday, June 25, 2017 8:27 PM > To: Dave Dolson; captive-portals@ietf.org > Cc: David Bird > Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive = Portal" > =20 > At least Erik Kline and myself are following the captive-portal list = :-) > =20 > And the more we think about it, PvD could really be useful and we, the = PvD I-D authors, would be pleased to present at your WG > =20 > -=C3=A9ric > =20 > From: Captive-portals on behalf of = Dave Dolson > Date: Friday 23 June 2017 at 11:57 > To: "captive-portals@ietf.org" > Cc: David Bird > Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive = Portal" > =20 > [resend with fewer recipients to avoid mailing list problems] > =20 > To echo David=E2=80=99s request, > > If the authors of the PvD concept (re-)present their I-D to the = mailing list, and stick around for discussion, that would be helpful. > =20 > =20 > From: David Bird [mailto:dbird@google.com]=20 > Sent: Wednesday, June 14, 2017 9:36 AM > To: Erik Kline > Cc: Gunther Nitzsche; Mark Townsley; Heiko Folkerts; Martin Thomson; = captive-portals@ietf.org; Livingood, Jason; Herzig, Willi; Warren = Kumari; Dave Dolson > Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive = Portal" > =20 > On Sun, Jun 11, 2017 at 11:17 PM, Erik Kline > wrote: > I'm not sure we have enough input on whether 511 is useful or not. = There seemed to be some suggestion it would help, and some that it = wouldn't. Perhaps one question we could ask is whether it's harmful? = And if we agree it's not harmful, is it worth developing some = recommendations for its use? > =20 > =20 > In of itself, I don't believe it is harmful. However, if vendors use = it as a reason to continue to terminate TLS connection in order to = deliver the 511, then perhaps it is a bit harmful - or at least = misleading. As the world moves to TLS (and QUIC), I think the time for = the 511 code has already passed, to some degree. That, combined with the = fact you may still have browsers not handling that return code properly, = I don't see the value for any vendor or venue to implement this. > =20 > =20 > As for the ICMP unreachable option, I certainly don't think it would = be harmful (with the extra URL bits removed for now). Is that something = we wish to progress? > =20 > =20 > I will work on a new draft that is only the basics. The additional = fields could always be add in their own draft as extensions.=20 > =20 > =20 > Given that we're probably looking at a portal detection method based = on entirely new work, it seems to me we're free to look at new things = like utilizing the PVD detection scheme (DNS queries for "provisioning = domain names", followed by other interaction still TBD). Have the = portal implementors reviewed this and given consideration as to whether = its useful? (I think of the discovery of the portal and subsequent = interaction with it as 2 separate processes conducted, obviously, in = serial.) > =20 > =20 > I believe there are several talking points here, as the PvD method = seems to have several possible implementations.=20 > =20 > I think requiring Ipv6 to configure Ipv4 is weird (I believe that was = one proposed method to convey configuration) > =20 > Several points I made in the thread "Arguments against any Capport = API" regarding a web service - detached from the NAS - controlling the = UE/station I think are relevant. > =20 > If the authors of the PvD concept (re-)present their I-D to the = mailing list, and stick around for discussion, that would be helpful.=20 > =20 > =20 > Thoughts? >=20 > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals = > =20 > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals --Boundary_(ID_y9zhcJ7zkYggclu4gjLNKQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On Jun 27, 2017, at 12:46 PM, Dave Dolson <ddolson@sandvine.com> wrote:

Eric,
Do I understand correctly from https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-= domains-00#section-5.5
that the intention is for the JSON key =E2=80=9CcaptivePortal=E2= =80=9D to indicate that the specified URL is to be visited by the = browser to navigate the requirements for exiting captivity?
 
If so, would you say = this URL should be used in place of performing a capport detection = strategy (e.g., canary HTTP = request)?

The idea with explicit PvD discovery is that it = would, as a step, replace a separate captive portal detection = strategy.

My overall concern with = discovery mechanisms that are specific to only captive portals is that = this is an extra step that is performed potentially on every network = association, that may have limited extensibility for non-captive use = cases. Since the explicit PvD design promises a way to discover many = properties beyond captivity, and is bootstrapped very early on in the = network association, it should hopefully allow clients to avoid the = extra probe.

 
 
 
Note: the same = =E2=80=9CcaptivePortal=E2=80=9D key is also defined in section 5.3 as a = Boolean. Should I consider this to be a defect in the draft, or am I = missing something?

The updated version of the draft (https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-= domains-01) leaves out the specific keys for captive portals, and = discusses it more abstractly. That would be a good thing to nail down at = the Prague meeting. If PvD detection is done generically on network = association, then a boolean or some way to indicate that this is *not* a = captive portal will allow the device to not perform extra probing. If = there is a captive network, we should be able to get the page or = instructions on how to get beyond captivity.

Thanks,
Tommy

 
-Dave
 
 
 
From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com] 
Sent: Sunday, June 25, 2017 8:27 = PM
To: Dave Dolson; captive-portals@ietf.org
Cc: David= Bird
Subject: Re: [Captive-portals] Use = Case: "Carrier Grade Captive Portal"
 
At least Erik Kline and = myself are following the captive-portal list :-)
 
And the more we = think about it, PvD could really be useful and we, the PvD I-D authors, = would be pleased to present at your WG
 
-=C3=A9ric
 
From: Captive-portals = <captive-portals-bounces@ietf.org> on behalf of Dave = Dolson <ddolson@sandvine.com>
Date: Friday 23 June 2017 at = 11:57
To: "captive-portals@ietf.org" <captive-portals@ietf.org>
Cc: David= Bird <dbird@google.com>
Subject: Re: [Captive-portals] = Use Case: "Carrier Grade Captive Portal"
 
[resend with fewer = recipients to avoid mailing list problems]
 
To echo David=E2=80=99s = request,
> If the authors of = the PvD concept (re-)present their I-D to the mailing list, and stick = around for discussion, that would be helpful.
 
 
From: David Bird [mailto:dbird@google.com] 
Sent: Wednesday, June 14, 2017 = 9:36 AM
To: Erik Kline
Cc: Gunther Nitzsche; Mark = Townsley; Heiko Folkerts; Martin Thomson; captive-portals@ietf.org; Livingood, Jason; Herzig, = Willi; Warren Kumari; Dave Dolson
Subject: Re: [Captive-portals] Use = Case: "Carrier Grade Captive Portal"
 
On Sun, Jun 11, 2017 at 11:17 PM, Erik Kline <ek@google.com> wrote:
I'm not sure we have enough input on whether 511 is useful or = not.  There seemed to be some suggestion it would help, and some = that it wouldn't.  Perhaps one question we could ask is whether = it's harmful?  And if we agree it's not harmful, is it worth = developing some recommendations for its use?
 
 
In of itself, I don't believe it is harmful. However, = if vendors use it as a reason to continue to terminate TLS connection in = order to deliver the 511, then perhaps it is a bit harmful - or at least = misleading. As the world moves to TLS (and QUIC), I think the time for = the 511 code has already passed, to some degree. That, combined with the = fact you may still have browsers not handling that return code properly, = I don't see the value for any vendor or venue to implement this.
 
 
As for the = ICMP unreachable option, I certainly don't think it would be harmful = (with the extra URL bits removed for now).  Is that something we = wish to progress?
 
 
I will work on a new draft that is only the basics. = The additional fields could always be add in their own draft as = extensions. 
 
 
Given that we're probably looking at a portal detection = method based on entirely new work, it seems to me we're free to look at = new things like utilizing the PVD detection scheme (DNS queries for = "provisioning domain names", followed by other interaction still = TBD).  Have the portal implementors reviewed this and given = consideration as to whether its useful?  (I think of the discovery = of the portal and subsequent interaction with it as 2 separate processes = conducted, obviously, in serial.)
 
 
I believe there are several talking points here, as = the PvD method seems to have several possible implementations. 
 
I think = requiring Ipv6 to configure Ipv4 is weird (I believe that was one = proposed method to convey configuration)
 
Several = points I made in the thread "Arguments against any Capport API" = regarding a web service - detached from the NAS - controlling the = UE/station I think are relevant.
 
If the authors of the PvD concept (re-)present their = I-D to the mailing list, and stick around for discussion, that would be = helpful. 
 
 
Thoughts?

_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

 
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

= --Boundary_(ID_y9zhcJ7zkYggclu4gjLNKQ)-- From nobody Mon Jul 10 06:38:52 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B685A126C22 for ; Mon, 10 Jul 2017 06:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DH3x8O62pDwa for ; Mon, 10 Jul 2017 06:38:48 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 DD00A12ECB0 for ; Mon, 10 Jul 2017 06:38:47 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id v202so33226273itb.0 for ; Mon, 10 Jul 2017 06:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bI9cqJ3nYkBhflfOxdIgDS7o7ujSujaclr9u4UrdIoM=; b=XJt/y0k4SuHsQ8B50aeqsHR4b9kvnaHPJzqLBu5YRLOJ61dF1uMOZkXUS2W3nsrSK9 I9lgS8dcjv72Fe0ggshU+PlbPmLqa3z3W8Kmp6eauoJMqs1EXbkev2L/EGr35CbGVN9I qp8m3zYgUW3PHdyZyYfk5l2jB0PV7xyRWiTYH8cOLDNRuEld0VwvAWGlAPUZ5hA6V/uL GtjRrfpANZ2PEjQLafdnoFWcfvujtBT+CmOkCuiseVlddQ/AbxyqLHn5FuwesjiJtJqW fLbUe2VM9DLi68yaG5xr1zIfzQtwIEByasfjTZkP7q4ynd9GkgI/ReXHDhp1VoMYMiag M1GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bI9cqJ3nYkBhflfOxdIgDS7o7ujSujaclr9u4UrdIoM=; b=QOF2xwDF87E/GjPFYFH/8dGiedPudt95jPvxCVy/qtkD8q2GQPuM5fa+yXrV3/hqe3 sPdAamAiXT1yL6KUrqsOAOnDLWR1ou2WBbVZVFdVfkGaoDgbgi1I3OikZbP3J2Nrct1p BRXzv0LVAroJ2kZO13t+h0L8kFV8O5fvJmJvcJSQkLHkrNHtF1g6wzvAElrqntjUgC0P rZ+ZzSGh8OPB3VL/coantEEu2GfG9nQCnQ5qz96YlBDy7Fpfj+V9/TFn6o780fEyc9DT 9Cr0nYE6thJI1H7pvxuXx1OtcXmt/qD39yiiqTieIJYaG7KL+EUCFBz1eHo0ZUp5aPX4 wVsg== X-Gm-Message-State: AIVw113MdG7aMIcneR0noM56dByq5/lQejnkl8S7nPn6f+k+tkiSRdQ8 +WiC9Ej1C1QrRLe7Fhq19QvdRAYib88D X-Received: by 10.107.21.196 with SMTP id 187mr3238242iov.86.1499693925527; Mon, 10 Jul 2017 06:38:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.14.144 with HTTP; Mon, 10 Jul 2017 06:38:44 -0700 (PDT) In-Reply-To: References: <201705031442.50683.heiko.folkerts@bsi.bund.de> <1BB90528-B35F-43F0-AF18-0215DC735FF0@cable.comcast.com> <754719c5-c74c-fbdc-405e-b8c91478c0a5@netcologne.de> From: David Bird Date: Mon, 10 Jul 2017 06:38:44 -0700 Message-ID: To: Tommy Pauly Cc: Dave Dolson , "Eric Vyncke (evyncke)" , "captive-portals@ietf.org" Content-Type: multipart/alternative; boundary="001a1148d54ab4991b0553f6b358" Archived-At: Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal" X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 13:38:51 -0000 --001a1148d54ab4991b0553f6b358 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 8, 2017 at 6:14 PM, Tommy Pauly wrote: > [snip] > The idea with explicit PvD discovery is that it would, as a step, replace a > separate captive portal detection strategy. > > My overall concern with discovery mechanisms that are specific to only > captive portals is that this is an extra step that is performed potential= ly > on every network association, that may have limited extensibility for > non-captive use cases. Since the explicit PvD design promises a way to > discover many properties beyond captivity, and is bootstrapped very early > on in the network association, it should hopefully allow clients to avoid > the extra probe. > > I have concerns with the PvD approach, as described. If a network was misconfigured to advertise a PvD that does have a (Internet based) HTTPS server with a JSON file on it describing a captive portal network, then devices utilizing the PvD information will *never* get on this network while devices not using the PvD information do. That could be very confusing to users and network administrators alike. If you have seen walled garden configurations for large networks, you will notice a lot about the network operator's marketing partners. Indeed, many walled gardens are much larger than the network really wants... sometimes they just need to make things work in the garden. My point here is that operators may not *want* to list out their walled garden configuration on a public JSON file... At the end of the day, I'd argue that the client *will always probe* -- wether it means to or not... A networking using PvD could just advertise all networks routes are available so that the device connects only to get caught up in a captive portal redirect anyway... back to step 1 and captive portal detection.. I'm also unclear how PvD would deal with scenarios where you might start out with internet connectivity (e.g. "MAC Authentication") then to have a captive portal return after a session timeout has occurred... > > > > Note: the same =E2=80=9CcaptivePortal=E2=80=9D key is also defined in sec= tion 5.3 as a > Boolean. Should I consider this to be a defect in the draft, or am I > missing something? > > > The updated version of the draft (https://tools.ietf.org/html/ > draft-bruneau-intarea-provisioning-domains-01) leaves out the specific > keys for captive portals, and discusses it more abstractly. That would be= a > good thing to nail down at the Prague meeting. If PvD detection is done > generically on network association, then a boolean or some way to indicat= e > that this is *not* a captive portal will allow the device to not perform > extra probing. If there is a captive network, we should be able to get th= e > page or instructions on how to get beyond captivity. > > Thanks, > Tommy > > > > -Dave > > > > *From:* Eric Vyncke (evyncke) [mailto:evyncke@cisco.com > ] > *Sent:* Sunday, June 25, 2017 8:27 PM > *To:* Dave Dolson; captive-portals@ietf.org > *Cc:* David Bird > *Subject:* Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal" > > At least Erik Kline and myself are following the captive-portal list :-) > > And the more we think about it, PvD could really be useful and we, the Pv= D > I-D authors, would be pleased to present at your WG > > -=C3=A9ric > > > *From: *Captive-portals on behalf of > Dave Dolson > *Date: *Friday 23 June 2017 at 11:57 > *To: *"captive-portals@ietf.org" > *Cc: *David Bird > *Subject: *Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal" > > [resend with fewer recipients to avoid mailing list problems] > > To echo David=E2=80=99s request, > > If the authors of the PvD concept (re-)present their I-D to the mailing > list, and stick around for discussion, that would be helpful. > > > *From:* David Bird [mailto:dbird@google.com ] > *Sent:* Wednesday, June 14, 2017 9:36 AM > *To:* Erik Kline > *Cc:* Gunther Nitzsche; Mark Townsley; Heiko Folkerts; Martin Thomson; > captive-portals@ietf.org; Livingood, Jason; Herzig, Willi; Warren Kumari; > Dave Dolson > *Subject:* Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal" > > On Sun, Jun 11, 2017 at 11:17 PM, Erik Kline wrote: > I'm not sure we have enough input on whether 511 is useful or not. There > seemed to be some suggestion it would help, and some that it wouldn't. > Perhaps one question we could ask is whether it's harmful? And if we agr= ee > it's not harmful, is it worth developing some recommendations for its use= ? > > > In of itself, I don't believe it is harmful. However, if vendors use it a= s > a reason to continue to terminate TLS connection in order to deliver the > 511, then perhaps it is a bit harmful - or at least misleading. As the > world moves to TLS (and QUIC), I think the time for the 511 code has > already passed, to some degree. That, combined with the fact you may stil= l > have browsers not handling that return code properly, I don't see the val= ue > for any vendor or venue to implement this. > > > > As for the ICMP unreachable option, I certainly don't think it would be > harmful (with the extra URL bits removed for now). Is that something we > wish to progress? > > > > I will work on a new draft that is only the basics. The additional fields > could always be add in their own draft as extensions. > > > > Given that we're probably looking at a portal detection method based on > entirely new work, it seems to me we're free to look at new things like > utilizing the PVD detection scheme (DNS queries for "provisioning domain > names", followed by other interaction still TBD). Have the portal > implementors reviewed this and given consideration as to whether its > useful? (I think of the discovery of the portal and subsequent interacti= on > with it as 2 separate processes conducted, obviously, in serial.) > > > > I believe there are several talking points here, as the PvD method seems > to have several possible implementations. > > I think requiring Ipv6 to configure Ipv4 is weird (I believe that was one > proposed method to convey configuration) > > Several points I made in the thread "Arguments against any Capport API" > regarding a web service - detached from the NAS - controlling the > UE/station I think are relevant. > > If the authors of the PvD concept (re-)present their I-D to the mailing > list, and stick around for discussion, that would be helpful. > > > > Thoughts? > > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > > > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > > > --001a1148d54ab4991b0553f6b358 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jul 8, 2017 at 6:14 PM, Tommy Pauly <tpauly@apple.com> wr= ote:
[snip= ]=C2=A0
The idea with explicit PvD discovery = is that it would, as a step, replace a separate captive portal detection st= rategy.

My overall concern with discovery mechanis= ms that are specific to only captive portals is that this is an extra step = that is performed potentially on every network association, that may have l= imited extensibility for non-captive use cases. Since the explicit PvD desi= gn promises a way to discover many properties beyond captivity, and is boot= strapped very early on in the network association, it should hopefully allo= w clients to avoid the extra probe.

<= /blockquote>

I have conc= erns with the PvD approach, as described.

If a net= work was misconfigured to advertise a PvD that does have a (Internet based)= HTTPS server with a JSON file on it describing a captive portal network, t= hen devices utilizing the PvD information will *never* get on this network = while devices not using the PvD information do. That could be very confusin= g to users and network administrators alike.=C2=A0

If you have seen walled garden configurations for large networks, you will= notice a lot about the network operator's marketing partners. Indeed, = many walled gardens are much larger than the network really wants... someti= mes they just need to make things work in the garden. My point here is that= operators may not *want* to list out their walled garden configuration on = a public JSON file...

At the end of the day, I'= ;d argue that the client *will always probe* -- wether it means to or not..= . A networking using PvD could just advertise all networks routes are avail= able so that the device connects only to get caught up in a captive portal = redirect anyway... back to step 1 and captive portal detection..
=
I'm also unclear how PvD would deal with scenarios where= you might start out with internet connectivity (e.g. "MAC Authenticat= ion") then to have a captive portal return after a session timeout has= occurred...

=C2=A0
=C2=A0
=C2=A0
=C2=A0
= Note: the same =E2=80=9CcaptivePortal=E2=80=9D key is also defined in secti= on 5.3 as a Boolean. Should I consider this to be a defect in the draft, or= am I missing something?

The updated version of the draft (htt= ps://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domai= ns-01) leaves out the specific keys for captive portals, and discusses = it more abstractly. That would be a good thing to nail down at the Prague m= eeting. If PvD detection is done generically on network association, then a= boolean or some way to indicate that this is *not* a captive portal will a= llow the device to not perform extra probing. If there is a captive network= , we should be able to get the page or instructions on how to get beyond ca= ptivity.

Thanks,
Tommy


= =C2=A0
-Dave<= /u>
=C2=A0
=C2=A0
=C2=A0
From:=C2=A0Eric Vyncke (evyncke) [= mailto:evyncke@cisco= .com]=C2=A0=
Sent:=C2=A0Sunday, June 25, 2017 8:27 PM
To:=C2=A0Dave Dolson; = captive-porta= ls@ietf.org
Cc:=C2=A0David Bird
Subject:=C2=A0Re: [Captive-portals]= Use Case: "Carrier Grade Captive Portal"
=C2=A0
At least Erik Kline and myself are following the captive-portal list :-)=
=C2=A0
And the more we think about it, PvD could really be useful and we,= the PvD I-D authors, would be pleased to present at your WG<= /span>
=C2=A0
-=C3= =A9ric
=C2=A0
From:=C2=A0Captive-portals <captive-port= als-bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com><= br>Date:=C2= =A0Friday 23 June 2017 at 11:57
To:=C2=A0"captive-portals@ietf.org= " <ca= ptive-portals@ietf.org>
Cc:=C2=A0David Bird <dbird@google.com>
Subject:= =C2=A0Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"<= u>
=C2=A0=
[resend with fewer reci= pients to avoid mailing list problems]
=C2=A0
To echo David=E2=80=99s request,
> If the authors of the PvD concept (re-)= present their I-D to the mailing list, and stick around for discussion, tha= t would be helpful.
=C2=A0
=C2= =A0
From:=C2=A0David Bird [mailto:dbird@google.com]=C2=A0
Sent:<= /b>=C2=A0Wednesday, June 14, 2017 9:36 AM
To:=C2=A0Erik Kline
Cc:=C2=A0Gunther = Nitzsche; Mark Townsley; Heiko Folkerts; Martin Thomson; captive-portals@ietf.org; L= ivingood, Jason; Herzig, Willi; Warren Kumari; Dave Dolson
Subject:=C2=A0= Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
=C2=A0
=
On Sun, Jun 11, 2017 at 11:17 PM, E= rik Kline <ek@google.com> wrote:<= u>
I'm not sure w= e have enough input on whether 511 is useful or not.=C2=A0 There seemed to = be some suggestion it would help, and some that it wouldn't.=C2=A0 Perh= aps one question we could ask is whether it's harmful?=C2=A0 And if we = agree it's not harmful, is it worth developing some recommendations for= its use?
=C2=A0<= /u>
=C2= =A0
In of itself, I = don't believe it is harmful. However, if vendors use it as a reason to = continue to terminate TLS connection in order to deliver the 511, then perh= aps it is a bit harmful - or at least misleading. As the world moves to TLS= (and QUIC), I think the time for the 511 code has already passed, to some = degree. That, combined with the fact you may still have browsers not handli= ng that return code properly, I don't see the value for any vendor or v= enue to implement this.
=C2=A0
=C2=A0=
As for the ICMP unreachable option, I certainly don't think it wou= ld be harmful (with the extra URL bits removed for now).=C2=A0 Is that some= thing we wish to progress?
=C2=A0
=
=C2=A0
I will work on a new draft that is only the basics. The additio= nal fields could always be add in their own draft as extensions.=C2=A0
=C2=A0
=C2=A0
Given that we're pr= obably looking at a portal detection method based on entirely new work, it = seems to me we're free to look at new things like utilizing the PVD det= ection scheme (DNS queries for "provisioning domain names", follo= wed by other interaction still TBD).=C2=A0 Have the portal implementors rev= iewed this and given consideration as to whether its useful? =C2=A0(I think= of the discovery of the portal and subsequent interaction with it as 2 sep= arate processes conducted, obviously, in serial.)
=
=C2=A0
<= /div>
=C2=A0
<= /div>
I believe there are several talking poin= ts here, as the PvD method seems to have several possible implementations.= =C2=A0
=C2=A0=
I think requiring Ipv6 to = configure Ipv4 is weird (I believe that was one proposed method to convey c= onfiguration)
=C2=A0=
Several points I ma= de in the thread "Arguments against any Capport API" regarding a = web service - detached from the NAS - controlling the UE/station I think ar= e relevant.
=C2=A0
If the authors of the= PvD concept (re-)present their I-D to the mailing list, and stick around f= or discussion, that would be helpful.=C2=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times= New Roman",serif">=C2=A0
=C2=A0
=
Thoughts?


_____________________________= __________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listin= fo/captive-portals

=C2=A0
_____________= __________________________________
= Captive-portals mailing list
Captive-portals@ietf.org=
https://www.ietf.org/mailm= an/listinfo/captive-portals


--001a1148d54ab4991b0553f6b358-- From nobody Mon Jul 10 08:54:19 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C125129ADD for ; Mon, 10 Jul 2017 08:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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 f6plQifMR3Pt for ; Mon, 10 Jul 2017 08:54:14 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EE0129AD1 for ; Mon, 10 Jul 2017 08:54:14 -0700 (PDT) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Mon, 10 Jul 2017 11:54:12 -0400 From: Dave Dolson To: "tpauly@apple.com" CC: "Eric Vyncke (evyncke)" , "captive-portals@ietf.org" , David Bird Thread-Topic: [Captive-portals] Use Case: "Carrier Grade Captive Portal" Thread-Index: AQHSxAspm2jwFnBWgkqjQKiot+mYpKHim5WQgAHxpYCAKua1AIAALgAAgAJV74CABl/BAIAI6m4AgAOfPACADjOEMIADVqkAgAMFLHCAEevbAIACPagQ Date: Mon, 10 Jul 2017 15:54:11 +0000 Message-ID: References: <201705031442.50683.heiko.folkerts@bsi.bund.de> <1BB90528-B35F-43F0-AF18-0215DC735FF0@cable.comcast.com> <754719c5-c74c-fbdc-405e-b8c91478c0a5@netcologne.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.114] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9870638DF6wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal" X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 15:54:17 -0000 --_000_E8355113905631478EFF04F5AA706E9870638DF6wtlexchp1sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXQgdGhlIGxhc3QgbWVldGluZywgSSB0aGluayB3ZSBoZWFyZCwg4oCcUHZEcyBjYW4gaGVscCBz b2x2ZSB0aGlzIHByb2JsZW0u4oCdDQooVGhpcyBzZWVtcyB0byBtZSB0byBiZSB0cnVlLikNCkFy ZSB0aGUgUHZEIGF1dGhvcnMgYmFja2luZyBhd2F5IGZyb20gdGhpcyBhc3NlcnRpb24/DQoNCkkg dGhpbmsgdGhlcmUgYXJlIHR3byBhc3BlY3RzOg0KDQoxLiAgICAgICBUaGUgUHZEIGRhdGEgc3Ry dWN0dXJlcyBvbiB0aGUgZW5kLXVzZXIgZGV2aWNlLCB3aGljaCB0cmFjayBjYXB0aXZpdHkgc3Rh dGUgcGVyIFB2RC4gKFJGQyA3NTU2IGRpc2N1c3NlcyBjb25uZWN0aXZpdHkgdGVzdHMgcGVyIFB2 RC4pDQoNCjIuICAgICAgIFdoZXRoZXIgdGhlIFB2RCBwcm90b2NvbCBleHBsaWNpdGx5IGNvbnZl eXMgdGhlIGNhcHRpdmUtcG9ydGFsIGNvbmNlcHQuDQoNCklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0 bHksICgxKSBjb3VsZCBiZSBhY2hpZXZlZCBldmVuIGlmIGNhcHBvcnQgaW5mb3JtYXRpb24gaXMg Y29udmV5ZWQgaW4gREhDUCBvciBSQXMgKHZzLiBpbiB0aGUgUHZEIHByb3RvY29sKS4NCkhvd2V2 ZXIsIHRoYXQgcG9pbnRzIHRvIHlldCBhbm90aGVyIEFQSSB0byBxdWVyeS4NCg0KSSB0aGluayB0 aGF0IGRyYWZ0LWJydW5lYXUtaW50YXJlYS1wcm92aXNpb25pbmctZG9tYWlucyBoYXMgYWRkcmVz c2VkIGEgcHJvYmxlbSBtb3JlIGdlbmVyaWMgdGhhbiB0aGUgQ0FQUE9SVCBBUEkgcHJvYmxlbS4N CkFuZCB0aGVyZWZvcmUgSeKAmW0gZmVlbGluZyBpdCBpcyBzdGlsbCB3b3J0aCBwdXJzdWluZy4N Cg0KDQpJIHRoaW5rIFRvbW15IG1ha2VzIGEgZ3JlYXQgcG9pbnQgdGhhdCB0aGVyZSBpcyB2YWx1 ZSBpbiBleHBsaWNpdGx5IGluZGljYXRpbmcsIOKAnHRoaXMgaXMgbm90IGEgY2FwdGl2ZSBwb3J0 YWzigJ0uIFRoaXMgb3VnaHQgdG8gc3BlZWQgdXAgbmV0d29yayBhc3NvY2lhdGlvbi4NCg0KDQot RGF2ZQ0KDQoNCg0KRnJvbTogdHBhdWx5QGFwcGxlLmNvbSBbbWFpbHRvOnRwYXVseUBhcHBsZS5j b21dDQpTZW50OiBTYXR1cmRheSwgSnVseSA4LCAyMDE3IDk6MTUgUE0NClRvOiBEYXZlIERvbHNv bg0KQ2M6IEVyaWMgVnluY2tlIChldnluY2tlKTsgY2FwdGl2ZS1wb3J0YWxzQGlldGYub3JnOyBE YXZpZCBCaXJkDQpTdWJqZWN0OiBSZTogW0NhcHRpdmUtcG9ydGFsc10gVXNlIENhc2U6ICJDYXJy aWVyIEdyYWRlIENhcHRpdmUgUG9ydGFsIg0KDQoNCg0KDQpPbiBKdW4gMjcsIDIwMTcsIGF0IDEy OjQ2IFBNLCBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb208bWFpbHRvOmRkb2xzb25A c2FuZHZpbmUuY29tPj4gd3JvdGU6DQoNCkVyaWMsDQpEbyBJIHVuZGVyc3RhbmQgY29ycmVjdGx5 IGZyb20gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJydW5lYXUtaW50YXJlYS1w cm92aXNpb25pbmctZG9tYWlucy0wMCNzZWN0aW9uLTUuNQ0KdGhhdCB0aGUgaW50ZW50aW9uIGlz IGZvciB0aGUgSlNPTiBrZXkg4oCcY2FwdGl2ZVBvcnRhbOKAnSB0byBpbmRpY2F0ZSB0aGF0IHRo ZSBzcGVjaWZpZWQgVVJMIGlzIHRvIGJlIHZpc2l0ZWQgYnkgdGhlIGJyb3dzZXIgdG8gbmF2aWdh dGUgdGhlIHJlcXVpcmVtZW50cyBmb3IgZXhpdGluZyBjYXB0aXZpdHk/DQoNCklmIHNvLCB3b3Vs ZCB5b3Ugc2F5IHRoaXMgVVJMIHNob3VsZCBiZSB1c2VkIGluIHBsYWNlIG9mIHBlcmZvcm1pbmcg YSBjYXBwb3J0IGRldGVjdGlvbiBzdHJhdGVneSAoZS5nLiwgY2FuYXJ5IEhUVFAgcmVxdWVzdCk/ DQoNClRoZSBpZGVhIHdpdGggZXhwbGljaXQgUHZEIGRpc2NvdmVyeSBpcyB0aGF0IGl0IHdvdWxk LCBhcyBhIHN0ZXAsIHJlcGxhY2UgYSBzZXBhcmF0ZSBjYXB0aXZlIHBvcnRhbCBkZXRlY3Rpb24g c3RyYXRlZ3kuDQoNCk15IG92ZXJhbGwgY29uY2VybiB3aXRoIGRpc2NvdmVyeSBtZWNoYW5pc21z IHRoYXQgYXJlIHNwZWNpZmljIHRvIG9ubHkgY2FwdGl2ZSBwb3J0YWxzIGlzIHRoYXQgdGhpcyBp cyBhbiBleHRyYSBzdGVwIHRoYXQgaXMgcGVyZm9ybWVkIHBvdGVudGlhbGx5IG9uIGV2ZXJ5IG5l dHdvcmsgYXNzb2NpYXRpb24sIHRoYXQgbWF5IGhhdmUgbGltaXRlZCBleHRlbnNpYmlsaXR5IGZv ciBub24tY2FwdGl2ZSB1c2UgY2FzZXMuIFNpbmNlIHRoZSBleHBsaWNpdCBQdkQgZGVzaWduIHBy b21pc2VzIGEgd2F5IHRvIGRpc2NvdmVyIG1hbnkgcHJvcGVydGllcyBiZXlvbmQgY2FwdGl2aXR5 LCBhbmQgaXMgYm9vdHN0cmFwcGVkIHZlcnkgZWFybHkgb24gaW4gdGhlIG5ldHdvcmsgYXNzb2Np YXRpb24sIGl0IHNob3VsZCBob3BlZnVsbHkgYWxsb3cgY2xpZW50cyB0byBhdm9pZCB0aGUgZXh0 cmEgcHJvYmUuDQoNCg0KDQoNCg0KTm90ZTogdGhlIHNhbWUg4oCcY2FwdGl2ZVBvcnRhbOKAnSBr ZXkgaXMgYWxzbyBkZWZpbmVkIGluIHNlY3Rpb24gNS4zIGFzIGEgQm9vbGVhbi4gU2hvdWxkIEkg Y29uc2lkZXIgdGhpcyB0byBiZSBhIGRlZmVjdCBpbiB0aGUgZHJhZnQsIG9yIGFtIEkgbWlzc2lu ZyBzb21ldGhpbmc/DQoNClRoZSB1cGRhdGVkIHZlcnNpb24gb2YgdGhlIGRyYWZ0IChodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJ1bmVhdS1pbnRhcmVhLXByb3Zpc2lvbmluZy1k b21haW5zLTAxKSBsZWF2ZXMgb3V0IHRoZSBzcGVjaWZpYyBrZXlzIGZvciBjYXB0aXZlIHBvcnRh bHMsIGFuZCBkaXNjdXNzZXMgaXQgbW9yZSBhYnN0cmFjdGx5LiBUaGF0IHdvdWxkIGJlIGEgZ29v ZCB0aGluZyB0byBuYWlsIGRvd24gYXQgdGhlIFByYWd1ZSBtZWV0aW5nLiBJZiBQdkQgZGV0ZWN0 aW9uIGlzIGRvbmUgZ2VuZXJpY2FsbHkgb24gbmV0d29yayBhc3NvY2lhdGlvbiwgdGhlbiBhIGJv b2xlYW4gb3Igc29tZSB3YXkgdG8gaW5kaWNhdGUgdGhhdCB0aGlzIGlzICpub3QqIGEgY2FwdGl2 ZSBwb3J0YWwgd2lsbCBhbGxvdyB0aGUgZGV2aWNlIHRvIG5vdCBwZXJmb3JtIGV4dHJhIHByb2Jp bmcuIElmIHRoZXJlIGlzIGEgY2FwdGl2ZSBuZXR3b3JrLCB3ZSBzaG91bGQgYmUgYWJsZSB0byBn ZXQgdGhlIHBhZ2Ugb3IgaW5zdHJ1Y3Rpb25zIG9uIGhvdyB0byBnZXQgYmV5b25kIGNhcHRpdml0 eS4NCg0KVGhhbmtzLA0KVG9tbXkNCg0KDQoNCi1EYXZlDQoNCg0KDQpGcm9tOiBFcmljIFZ5bmNr ZSAoZXZ5bmNrZSkgW21haWx0bzpldnluY2tlQGNpc2NvLmNvbV0NClNlbnQ6IFN1bmRheSwgSnVu ZSAyNSwgMjAxNyA4OjI3IFBNDQpUbzogRGF2ZSBEb2xzb247IGNhcHRpdmUtcG9ydGFsc0BpZXRm Lm9yZzxtYWlsdG86Y2FwdGl2ZS1wb3J0YWxzQGlldGYub3JnPg0KQ2M6IERhdmlkIEJpcmQNClN1 YmplY3Q6IFJlOiBbQ2FwdGl2ZS1wb3J0YWxzXSBVc2UgQ2FzZTogIkNhcnJpZXIgR3JhZGUgQ2Fw dGl2ZSBQb3J0YWwiDQoNCkF0IGxlYXN0IEVyaWsgS2xpbmUgYW5kIG15c2VsZiBhcmUgZm9sbG93 aW5nIHRoZSBjYXB0aXZlLXBvcnRhbCBsaXN0IDotKQ0KDQpBbmQgdGhlIG1vcmUgd2UgdGhpbmsg YWJvdXQgaXQsIFB2RCBjb3VsZCByZWFsbHkgYmUgdXNlZnVsIGFuZCB3ZSwgdGhlIFB2RCBJLUQg YXV0aG9ycywgd291bGQgYmUgcGxlYXNlZCB0byBwcmVzZW50IGF0IHlvdXIgV0cNCg0KLcOpcmlj DQoNCkZyb206IENhcHRpdmUtcG9ydGFscyA8Y2FwdGl2ZS1wb3J0YWxzLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOmNhcHRpdmUtcG9ydGFscy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9m IERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbTxtYWlsdG86ZGRvbHNvbkBzYW5kdmlu ZS5jb20+Pg0KRGF0ZTogRnJpZGF5IDIzIEp1bmUgMjAxNyBhdCAxMTo1Nw0KVG86ICJjYXB0aXZl LXBvcnRhbHNAaWV0Zi5vcmc8bWFpbHRvOmNhcHRpdmUtcG9ydGFsc0BpZXRmLm9yZz4iIDxjYXB0 aXZlLXBvcnRhbHNAaWV0Zi5vcmc8bWFpbHRvOmNhcHRpdmUtcG9ydGFsc0BpZXRmLm9yZz4+DQpD YzogRGF2aWQgQmlyZCA8ZGJpcmRAZ29vZ2xlLmNvbTxtYWlsdG86ZGJpcmRAZ29vZ2xlLmNvbT4+ DQpTdWJqZWN0OiBSZTogW0NhcHRpdmUtcG9ydGFsc10gVXNlIENhc2U6ICJDYXJyaWVyIEdyYWRl IENhcHRpdmUgUG9ydGFsIg0KDQpbcmVzZW5kIHdpdGggZmV3ZXIgcmVjaXBpZW50cyB0byBhdm9p ZCBtYWlsaW5nIGxpc3QgcHJvYmxlbXNdDQoNClRvIGVjaG8gRGF2aWTigJlzIHJlcXVlc3QsDQo+ IElmIHRoZSBhdXRob3JzIG9mIHRoZSBQdkQgY29uY2VwdCAocmUtKXByZXNlbnQgdGhlaXIgSS1E IHRvIHRoZSBtYWlsaW5nIGxpc3QsIGFuZCBzdGljayBhcm91bmQgZm9yIGRpc2N1c3Npb24sIHRo YXQgd291bGQgYmUgaGVscGZ1bC4NCg0KDQpGcm9tOiBEYXZpZCBCaXJkIFttYWlsdG86ZGJpcmRA Z29vZ2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAxNCwgMjAxNyA5OjM2IEFNDQpUbzog RXJpayBLbGluZQ0KQ2M6IEd1bnRoZXIgTml0enNjaGU7IE1hcmsgVG93bnNsZXk7IEhlaWtvIEZv bGtlcnRzOyBNYXJ0aW4gVGhvbXNvbjsgY2FwdGl2ZS1wb3J0YWxzQGlldGYub3JnPG1haWx0bzpj YXB0aXZlLXBvcnRhbHNAaWV0Zi5vcmc+OyBMaXZpbmdvb2QsIEphc29uOyBIZXJ6aWcsIFdpbGxp OyBXYXJyZW4gS3VtYXJpOyBEYXZlIERvbHNvbg0KU3ViamVjdDogUmU6IFtDYXB0aXZlLXBvcnRh bHNdIFVzZSBDYXNlOiAiQ2FycmllciBHcmFkZSBDYXB0aXZlIFBvcnRhbCINCg0KT24gU3VuLCBK dW4gMTEsIDIwMTcgYXQgMTE6MTcgUE0sIEVyaWsgS2xpbmUgPGVrQGdvb2dsZS5jb208bWFpbHRv OmVrQGdvb2dsZS5jb20+PiB3cm90ZToNCkknbSBub3Qgc3VyZSB3ZSBoYXZlIGVub3VnaCBpbnB1 dCBvbiB3aGV0aGVyIDUxMSBpcyB1c2VmdWwgb3Igbm90LiAgVGhlcmUgc2VlbWVkIHRvIGJlIHNv bWUgc3VnZ2VzdGlvbiBpdCB3b3VsZCBoZWxwLCBhbmQgc29tZSB0aGF0IGl0IHdvdWxkbid0LiAg UGVyaGFwcyBvbmUgcXVlc3Rpb24gd2UgY291bGQgYXNrIGlzIHdoZXRoZXIgaXQncyBoYXJtZnVs PyAgQW5kIGlmIHdlIGFncmVlIGl0J3Mgbm90IGhhcm1mdWwsIGlzIGl0IHdvcnRoIGRldmVsb3Bp bmcgc29tZSByZWNvbW1lbmRhdGlvbnMgZm9yIGl0cyB1c2U/DQoNCg0KSW4gb2YgaXRzZWxmLCBJ IGRvbid0IGJlbGlldmUgaXQgaXMgaGFybWZ1bC4gSG93ZXZlciwgaWYgdmVuZG9ycyB1c2UgaXQg YXMgYSByZWFzb24gdG8gY29udGludWUgdG8gdGVybWluYXRlIFRMUyBjb25uZWN0aW9uIGluIG9y ZGVyIHRvIGRlbGl2ZXIgdGhlIDUxMSwgdGhlbiBwZXJoYXBzIGl0IGlzIGEgYml0IGhhcm1mdWwg LSBvciBhdCBsZWFzdCBtaXNsZWFkaW5nLiBBcyB0aGUgd29ybGQgbW92ZXMgdG8gVExTIChhbmQg UVVJQyksIEkgdGhpbmsgdGhlIHRpbWUgZm9yIHRoZSA1MTEgY29kZSBoYXMgYWxyZWFkeSBwYXNz ZWQsIHRvIHNvbWUgZGVncmVlLiBUaGF0LCBjb21iaW5lZCB3aXRoIHRoZSBmYWN0IHlvdSBtYXkg c3RpbGwgaGF2ZSBicm93c2VycyBub3QgaGFuZGxpbmcgdGhhdCByZXR1cm4gY29kZSBwcm9wZXJs eSwgSSBkb24ndCBzZWUgdGhlIHZhbHVlIGZvciBhbnkgdmVuZG9yIG9yIHZlbnVlIHRvIGltcGxl bWVudCB0aGlzLg0KDQoNCkFzIGZvciB0aGUgSUNNUCB1bnJlYWNoYWJsZSBvcHRpb24sIEkgY2Vy dGFpbmx5IGRvbid0IHRoaW5rIGl0IHdvdWxkIGJlIGhhcm1mdWwgKHdpdGggdGhlIGV4dHJhIFVS TCBiaXRzIHJlbW92ZWQgZm9yIG5vdykuICBJcyB0aGF0IHNvbWV0aGluZyB3ZSB3aXNoIHRvIHBy b2dyZXNzPw0KDQoNCkkgd2lsbCB3b3JrIG9uIGEgbmV3IGRyYWZ0IHRoYXQgaXMgb25seSB0aGUg YmFzaWNzLiBUaGUgYWRkaXRpb25hbCBmaWVsZHMgY291bGQgYWx3YXlzIGJlIGFkZCBpbiB0aGVp ciBvd24gZHJhZnQgYXMgZXh0ZW5zaW9ucy4NCg0KDQpHaXZlbiB0aGF0IHdlJ3JlIHByb2JhYmx5 IGxvb2tpbmcgYXQgYSBwb3J0YWwgZGV0ZWN0aW9uIG1ldGhvZCBiYXNlZCBvbiBlbnRpcmVseSBu ZXcgd29yaywgaXQgc2VlbXMgdG8gbWUgd2UncmUgZnJlZSB0byBsb29rIGF0IG5ldyB0aGluZ3Mg bGlrZSB1dGlsaXppbmcgdGhlIFBWRCBkZXRlY3Rpb24gc2NoZW1lIChETlMgcXVlcmllcyBmb3Ig InByb3Zpc2lvbmluZyBkb21haW4gbmFtZXMiLCBmb2xsb3dlZCBieSBvdGhlciBpbnRlcmFjdGlv biBzdGlsbCBUQkQpLiAgSGF2ZSB0aGUgcG9ydGFsIGltcGxlbWVudG9ycyByZXZpZXdlZCB0aGlz IGFuZCBnaXZlbiBjb25zaWRlcmF0aW9uIGFzIHRvIHdoZXRoZXIgaXRzIHVzZWZ1bD8gIChJIHRo aW5rIG9mIHRoZSBkaXNjb3Zlcnkgb2YgdGhlIHBvcnRhbCBhbmQgc3Vic2VxdWVudCBpbnRlcmFj dGlvbiB3aXRoIGl0IGFzIDIgc2VwYXJhdGUgcHJvY2Vzc2VzIGNvbmR1Y3RlZCwgb2J2aW91c2x5 LCBpbiBzZXJpYWwuKQ0KDQoNCkkgYmVsaWV2ZSB0aGVyZSBhcmUgc2V2ZXJhbCB0YWxraW5nIHBv aW50cyBoZXJlLCBhcyB0aGUgUHZEIG1ldGhvZCBzZWVtcyB0byBoYXZlIHNldmVyYWwgcG9zc2li bGUgaW1wbGVtZW50YXRpb25zLg0KDQpJIHRoaW5rIHJlcXVpcmluZyBJcHY2IHRvIGNvbmZpZ3Vy ZSBJcHY0IGlzIHdlaXJkIChJIGJlbGlldmUgdGhhdCB3YXMgb25lIHByb3Bvc2VkIG1ldGhvZCB0 byBjb252ZXkgY29uZmlndXJhdGlvbikNCg0KU2V2ZXJhbCBwb2ludHMgSSBtYWRlIGluIHRoZSB0 aHJlYWQgIkFyZ3VtZW50cyBhZ2FpbnN0IGFueSBDYXBwb3J0IEFQSSIgcmVnYXJkaW5nIGEgd2Vi IHNlcnZpY2UgLSBkZXRhY2hlZCBmcm9tIHRoZSBOQVMgLSBjb250cm9sbGluZyB0aGUgVUUvc3Rh dGlvbiBJIHRoaW5rIGFyZSByZWxldmFudC4NCg0KSWYgdGhlIGF1dGhvcnMgb2YgdGhlIFB2RCBj b25jZXB0IChyZS0pcHJlc2VudCB0aGVpciBJLUQgdG8gdGhlIG1haWxpbmcgbGlzdCwgYW5kIHN0 aWNrIGFyb3VuZCBmb3IgZGlzY3Vzc2lvbiwgdGhhdCB3b3VsZCBiZSBoZWxwZnVsLg0KDQoNClRo b3VnaHRzPw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KQ2FwdGl2ZS1wb3J0YWxzIG1haWxpbmcgbGlzdA0KQ2FwdGl2ZS1wb3J0YWxzQGlldGYub3Jn PG1haWx0bzpDYXB0aXZlLXBvcnRhbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NhcHRpdmUtcG9ydGFscw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KQ2FwdGl2ZS1wb3J0YWxzIG1haWxpbmcgbGlzdA0K Q2FwdGl2ZS1wb3J0YWxzQGlldGYub3JnPG1haWx0bzpDYXB0aXZlLXBvcnRhbHNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NhcHRpdmUtcG9ydGFscw0K DQo= --_000_E8355113905631478EFF04F5AA706E9870638DF6wtlexchp1sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0Fj ZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28t c3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDoyNjMwMDE0NTc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04MDM5ODIyMDAgOTAzNjQzNDIgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEw ODU4MDA4ODg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi05MTkwNjc2ODAgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BdCB0aGUgbGFzdCBtZWV0aW5nLCBJIHRo aW5rIHdlIGhlYXJkLCDigJxQdkRzIGNhbiBoZWxwIHNvbHZlIHRoaXMgcHJvYmxlbS7igJ08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KFRoaXMgc2VlbXMgdG8gbWUgdG8gYmUgdHJ1ZS4p PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFyZSB0aGUgUHZEIGF1dGhvcnMgYmFja2lu ZyBhd2F5IGZyb20gdGhpcyBhc3NlcnRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoZXJlIGFyZSB0 d28gYXNwZWN0czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIFB2RCBkYXRhIHN0cnVjdHVyZXMg b24gdGhlIGVuZC11c2VyIGRldmljZSwgd2hpY2ggdHJhY2sgY2FwdGl2aXR5IHN0YXRlIHBlciBQ dkQuIChSRkMgNzU1NiBkaXNjdXNzZXMgY29ubmVjdGl2aXR5IHRlc3RzIHBlciBQdkQuKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5XaGV0aGVyIHRoZSBQdkQgcHJvdG9jb2wgZXhwbGljaXRseSBjb252 ZXlzIHRoZSBjYXB0aXZlLXBvcnRhbCBjb25jZXB0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgSSB1bmRlcnN0YW5k IGNvcnJlY3RseSwgKDEpIGNvdWxkIGJlIGFjaGlldmVkIGV2ZW4gaWYgY2FwcG9ydCBpbmZvcm1h dGlvbiBpcyBjb252ZXllZCBpbiBESENQIG9yIFJBcyAodnMuIGluIHRoZSBQdkQgcHJvdG9jb2wp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3dldmVyLCB0aGF0IHBvaW50cyB0byB5 ZXQgYW5vdGhlciBBUEkgdG8gcXVlcnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoYXQgZHJhZnQtYnJ1 bmVhdS1pbnRhcmVhLXByb3Zpc2lvbmluZy1kb21haW5zIGhhcyBhZGRyZXNzZWQgYSBwcm9ibGVt IG1vcmUgZ2VuZXJpYyB0aGFuIHRoZSBDQVBQT1JUIEFQSSBwcm9ibGVtLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5BbmQgdGhlcmVmb3JlIEnigJltIGZlZWxpbmcgaXQgaXMgc3RpbGwg d29ydGggcHVyc3VpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSB0aGluayBUb21teSBtYWtlcyBhIGdyZWF0IHBvaW50IHRoYXQgdGhlcmUgaXMgdmFs dWUgaW4gZXhwbGljaXRseSBpbmRpY2F0aW5nLCDigJx0aGlzIGlzIG5vdCBhIGNhcHRpdmUgcG9y dGFs4oCdLiBUaGlzIG91Z2h0IHRvIHNwZWVkIHVwIG5ldHdvcmsgYXNzb2NpYXRpb24uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LURhdmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRwYXVseUBhcHBsZS5jb20gW21haWx0bzp0cGF1 bHlAYXBwbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKdWx5IDgsIDIwMTcg OToxNSBQTTxicj4NCjxiPlRvOjwvYj4gRGF2ZSBEb2xzb248YnI+DQo8Yj5DYzo8L2I+IEVyaWMg VnluY2tlIChldnluY2tlKTsgY2FwdGl2ZS1wb3J0YWxzQGlldGYub3JnOyBEYXZpZCBCaXJkPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ2FwdGl2ZS1wb3J0YWxzXSBVc2UgQ2FzZTogJnF1b3Q7 Q2FycmllciBHcmFkZSBDYXB0aXZlIFBvcnRhbCZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1biAyNywgMjAxNywgYXQgMTI6NDYgUE0sIERhdmUgRG9s c29uICZsdDs8YSBocmVmPSJtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20iPmRkb2xzb25Ac2Fu ZHZpbmUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVyaWMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EbyBJIHVuZGVyc3Rh bmQgY29ycmVjdGx5IGZyb208c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJydW5l YXUtaW50YXJlYS1wcm92aXNpb25pbmctZG9tYWlucy0wMCNzZWN0aW9uLTUuNSI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJydW5l YXUtaW50YXJlYS1wcm92aXNpb25pbmctZG9tYWlucy0wMCNzZWN0aW9uLTUuNTwvc3Bhbj48L2E+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj50aGF0IHRoZSBpbnRlbnRpb24gaXMgZm9yIHRoZSBKU09OIGtleSDigJxj YXB0aXZlUG9ydGFs4oCdIHRvIGluZGljYXRlIHRoYXQgdGhlIHNwZWNpZmllZCBVUkwgaXMgdG8g YmUgdmlzaXRlZCBieSB0aGUgYnJvd3NlciB0byBuYXZpZ2F0ZQ0KIHRoZSByZXF1aXJlbWVudHMg Zm9yIGV4aXRpbmcgY2FwdGl2aXR5Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J ZiBzbywgd291bGQgeW91IHNheSB0aGlzIFVSTCBzaG91bGQgYmUgdXNlZCBpbiBwbGFjZSBvZiBw ZXJmb3JtaW5nIGEgY2FwcG9ydCBkZXRlY3Rpb24gc3RyYXRlZ3kgKGUuZy4sIGNhbmFyeSBIVFRQ IHJlcXVlc3QpPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaWRlYSB3aXRoIGV4cGxpY2l0IFB2RCBkaXNjb3Zl cnkgaXMgdGhhdCBpdCB3b3VsZCwgYXMgYSBzdGVwLCByZXBsYWNlIGEgc2VwYXJhdGUgY2FwdGl2 ZSBwb3J0YWwgZGV0ZWN0aW9uIHN0cmF0ZWd5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBvdmVyYWxsIGNvbmNlcm4gd2l0aCBkaXNjb3Zl cnkgbWVjaGFuaXNtcyB0aGF0IGFyZSBzcGVjaWZpYyB0byBvbmx5IGNhcHRpdmUgcG9ydGFscyBp cyB0aGF0IHRoaXMgaXMgYW4gZXh0cmEgc3RlcCB0aGF0IGlzIHBlcmZvcm1lZCBwb3RlbnRpYWxs eSBvbiBldmVyeSBuZXR3b3JrIGFzc29jaWF0aW9uLCB0aGF0IG1heSBoYXZlIGxpbWl0ZWQgZXh0 ZW5zaWJpbGl0eSBmb3Igbm9uLWNhcHRpdmUgdXNlIGNhc2VzLg0KIFNpbmNlIHRoZSBleHBsaWNp dCBQdkQgZGVzaWduIHByb21pc2VzIGEgd2F5IHRvIGRpc2NvdmVyIG1hbnkgcHJvcGVydGllcyBi ZXlvbmQgY2FwdGl2aXR5LCBhbmQgaXMgYm9vdHN0cmFwcGVkIHZlcnkgZWFybHkgb24gaW4gdGhl IG5ldHdvcmsgYXNzb2NpYXRpb24sIGl0IHNob3VsZCBob3BlZnVsbHkgYWxsb3cgY2xpZW50cyB0 byBhdm9pZCB0aGUgZXh0cmEgcHJvYmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vdGU6IHRoZSBzYW1lIOKAnGNhcHRp dmVQb3J0YWzigJ0ga2V5IGlzIGFsc28gZGVmaW5lZCBpbiBzZWN0aW9uIDUuMyBhcyBhIEJvb2xl YW4uIFNob3VsZCBJIGNvbnNpZGVyIHRoaXMgdG8gYmUgYSBkZWZlY3QgaW4gdGhlIGRyYWZ0LA0K IG9yIGFtIEkgbWlzc2luZyBzb21ldGhpbmc/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHVwZGF0ZWQgdmVyc2lvbiBvZiB0 aGUgZHJhZnQgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icnVu ZWF1LWludGFyZWEtcHJvdmlzaW9uaW5nLWRvbWFpbnMtMDEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1icnVuZWF1LWludGFyZWEtcHJvdmlzaW9uaW5nLWRvbWFpbnMtMDE8L2E+ KSBsZWF2ZXMgb3V0IHRoZSBzcGVjaWZpYyBrZXlzIGZvciBjYXB0aXZlDQogcG9ydGFscywgYW5k IGRpc2N1c3NlcyBpdCBtb3JlIGFic3RyYWN0bHkuIFRoYXQgd291bGQgYmUgYSBnb29kIHRoaW5n IHRvIG5haWwgZG93biBhdCB0aGUgUHJhZ3VlIG1lZXRpbmcuIElmIFB2RCBkZXRlY3Rpb24gaXMg ZG9uZSBnZW5lcmljYWxseSBvbiBuZXR3b3JrIGFzc29jaWF0aW9uLCB0aGVuIGEgYm9vbGVhbiBv ciBzb21lIHdheSB0byBpbmRpY2F0ZSB0aGF0IHRoaXMgaXMgKm5vdCogYSBjYXB0aXZlIHBvcnRh bCB3aWxsIGFsbG93IHRoZQ0KIGRldmljZSB0byBub3QgcGVyZm9ybSBleHRyYSBwcm9iaW5nLiBJ ZiB0aGVyZSBpcyBhIGNhcHRpdmUgbmV0d29yaywgd2Ugc2hvdWxkIGJlIGFibGUgdG8gZ2V0IHRo ZSBwYWdlIG9yIGluc3RydWN0aW9ucyBvbiBob3cgdG8gZ2V0IGJleW9uZCBjYXB0aXZpdHkuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRv bW15PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tRGF2ZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RXJpYw0KIFZ5 bmNrZSAoZXZ5bmNrZSkgWzxhIGhyZWY9Im1haWx0bzpldnluY2tlQGNpc2NvLmNvbSI+bWFpbHRv OmV2eW5ja2VAY2lzY28uY29tPC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlN1bmRheSwgSnVuZSAyNSwgMjAxNyA4OjI3IFBNPGJy Pg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5EYXZlIERvbHNvbjsgPGEgaHJlZj0ibWFpbHRvOmNhcHRpdmUtcG9ydGFsc0BpZXRmLm9y ZyI+DQpjYXB0aXZlLXBvcnRhbHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5EYXZpZCBCaXJkPGJyPg0K PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPlJlOiBbQ2FwdGl2ZS1wb3J0YWxzXSBVc2UgQ2FzZTogJnF1b3Q7Q2FycmllciBHcmFk ZSBDYXB0aXZlIFBvcnRhbCZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5BdCBsZWFzdCBFcmlrIEtsaW5lIGFuZCBteXNlbGYgYXJlIGZvbGxvd2luZyB0aGUg Y2FwdGl2ZS1wb3J0YWwgbGlzdCA6LSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BbmQgdGhlIG1vcmUgd2UgdGhpbmsgYWJvdXQg aXQsIFB2RCBjb3VsZCByZWFsbHkgYmUgdXNlZnVsIGFuZCB3ZSwgdGhlIFB2RCBJLUQgYXV0aG9y cywgd291bGQgYmUgcGxlYXNlZCB0byBwcmVzZW50IGF0IHlvdXIgV0c8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tw6lyaWM8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DYXB0aXZlLXBvcnRhbHMgJmx0OzxhIGhyZWY9 Im1haWx0bzpjYXB0aXZlLXBvcnRhbHMtYm91bmNlc0BpZXRmLm9yZyI+Y2FwdGl2ZS1wb3J0YWxz LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KIG9uIGJlaGFsZiBvZiBEYXZlIERvbHNvbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tIj5kZG9sc29uQHNhbmR2aW5lLmNv bTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9iPkZyaWRheSAyMyBKdW5lIDIwMTcgYXQgMTE6NTc8YnI+DQo8Yj5U bzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPiZx dW90OzxhIGhyZWY9Im1haWx0bzpjYXB0aXZlLXBvcnRhbHNAaWV0Zi5vcmciPmNhcHRpdmUtcG9y dGFsc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjYXB0aXZlLXBvcnRh bHNAaWV0Zi5vcmciPmNhcHRpdmUtcG9ydGFsc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5EYXZp ZCBCaXJkICZsdDs8YSBocmVmPSJtYWlsdG86ZGJpcmRAZ29vZ2xlLmNvbSI+ZGJpcmRAZ29vZ2xl LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJlOiBbQ2FwdGl2ZS1wb3J0YWxzXSBVc2UgQ2FzZTog JnF1b3Q7Q2FycmllciBHcmFkZSBDYXB0aXZlIFBvcnRhbCZxdW90Ozwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bcmVzZW5kIHdp dGggZmV3ZXIgcmVjaXBpZW50cyB0byBhdm9pZCBtYWlsaW5nIGxpc3QgcHJvYmxlbXNdPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRvIGVjaG8gRGF2aWTigJlzIHJlcXVlc3QsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mZ3Q7IElmIHRoZSBhdXRob3JzIG9mIHRoZSBQdkQgY29uY2VwdCAocmUtKXBy ZXNlbnQgdGhlaXIgSS1EIHRvIHRoZSBtYWlsaW5nIGxpc3QsIGFuZCBzdGljayBhcm91bmQgZm9y IGRpc2N1c3Npb24sIHRoYXQgd291bGQgYmUgaGVscGZ1bC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRhdmlkDQogQmlyZCBbPGEgaHJlZj0i bWFpbHRvOmRiaXJkQGdvb2dsZS5jb20iPm1haWx0bzpkYmlyZEBnb29nbGUuY29tPC9hPl08c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2Vu dDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldl ZG5lc2RheSwgSnVuZSAxNCwgMjAxNyA5OjM2IEFNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5FcmlrIEtsaW5lPGJyPg0KPGI+ Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5H dW50aGVyIE5pdHpzY2hlOyBNYXJrIFRvd25zbGV5OyBIZWlrbyBGb2xrZXJ0czsgTWFydGluIFRo b21zb247DQo8YSBocmVmPSJtYWlsdG86Y2FwdGl2ZS1wb3J0YWxzQGlldGYub3JnIj5jYXB0aXZl LXBvcnRhbHNAaWV0Zi5vcmc8L2E+OyBMaXZpbmdvb2QsIEphc29uOyBIZXJ6aWcsIFdpbGxpOyBX YXJyZW4gS3VtYXJpOyBEYXZlIERvbHNvbjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW0NhcHRpdmUtcG9ydGFs c10gVXNlIENhc2U6ICZxdW90O0NhcnJpZXIgR3JhZGUgQ2FwdGl2ZSBQb3J0YWwmcXVvdDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+T24gU3VuLCBKdW4gMTEsIDIwMTcgYXQgMTE6MTcgUE0sIEVyaWsgS2xp bmUgJmx0OzxhIGhyZWY9Im1haWx0bzpla0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZWtAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SSdtIG5v dCBzdXJlIHdlIGhhdmUgZW5vdWdoIGlucHV0IG9uIHdoZXRoZXIgNTExIGlzIHVzZWZ1bCBvciBu b3QuJm5ic3A7IFRoZXJlIHNlZW1lZCB0byBiZSBzb21lIHN1Z2dlc3Rpb24gaXQgd291bGQgaGVs cCwgYW5kIHNvbWUgdGhhdCBpdCB3b3VsZG4ndC4mbmJzcDsgUGVyaGFwcyBvbmUgcXVlc3Rpb24g d2UgY291bGQgYXNrIGlzIHdoZXRoZXIgaXQncyBoYXJtZnVsPyZuYnNwOyBBbmQgaWYNCiB3ZSBh Z3JlZSBpdCdzIG5vdCBoYXJtZnVsLCBpcyBpdCB3b3J0aCBkZXZlbG9waW5nIHNvbWUgcmVjb21t ZW5kYXRpb25zIGZvciBpdHMgdXNlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkluIG9m IGl0c2VsZiwgSSBkb24ndCBiZWxpZXZlIGl0IGlzIGhhcm1mdWwuIEhvd2V2ZXIsIGlmIHZlbmRv cnMgdXNlIGl0IGFzIGEgcmVhc29uIHRvIGNvbnRpbnVlIHRvIHRlcm1pbmF0ZSBUTFMgY29ubmVj dGlvbiBpbiBvcmRlciB0byBkZWxpdmVyIHRoZSA1MTEsIHRoZW4gcGVyaGFwcyBpdCBpcyBhIGJp dCBoYXJtZnVsIC0gb3IgYXQgbGVhc3QgbWlzbGVhZGluZy4NCiBBcyB0aGUgd29ybGQgbW92ZXMg dG8gVExTIChhbmQgUVVJQyksIEkgdGhpbmsgdGhlIHRpbWUgZm9yIHRoZSA1MTEgY29kZSBoYXMg YWxyZWFkeSBwYXNzZWQsIHRvIHNvbWUgZGVncmVlLiBUaGF0LCBjb21iaW5lZCB3aXRoIHRoZSBm YWN0IHlvdSBtYXkgc3RpbGwgaGF2ZSBicm93c2VycyBub3QgaGFuZGxpbmcgdGhhdCByZXR1cm4g Y29kZSBwcm9wZXJseSwgSSBkb24ndCBzZWUgdGhlIHZhbHVlIGZvciBhbnkgdmVuZG9yIG9yIHZl bnVlIHRvIGltcGxlbWVudA0KIHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5BcyBmb3IgdGhlIElD TVAgdW5yZWFjaGFibGUgb3B0aW9uLCBJIGNlcnRhaW5seSBkb24ndCB0aGluayBpdCB3b3VsZCBi ZSBoYXJtZnVsICh3aXRoIHRoZSBleHRyYSBVUkwgYml0cyByZW1vdmVkIGZvciBub3cpLiZuYnNw OyBJcyB0aGF0IHNvbWV0aGluZyB3ZSB3aXNoIHRvIHByb2dyZXNzPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkkgd2lsbCB3b3JrIG9uIGEgbmV3IGRyYWZ0IHRo YXQgaXMgb25seSB0aGUgYmFzaWNzLiBUaGUgYWRkaXRpb25hbCBmaWVsZHMgY291bGQgYWx3YXlz IGJlIGFkZCBpbiB0aGVpciBvd24gZHJhZnQgYXMgZXh0ZW5zaW9ucy4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPkdpdmVuIHRoYXQgd2UncmUgcHJvYmFibHkgbG9va2luZyBhdCBhIHBvcnRhbCBk ZXRlY3Rpb24gbWV0aG9kIGJhc2VkIG9uIGVudGlyZWx5IG5ldyB3b3JrLCBpdCBzZWVtcyB0byBt ZSB3ZSdyZSBmcmVlIHRvIGxvb2sgYXQgbmV3IHRoaW5ncyBsaWtlIHV0aWxpemluZyB0aGUgUFZE IGRldGVjdGlvbiBzY2hlbWUgKEROUyBxdWVyaWVzIGZvciAmcXVvdDtwcm92aXNpb25pbmcgZG9t YWluDQogbmFtZXMmcXVvdDssIGZvbGxvd2VkIGJ5IG90aGVyIGludGVyYWN0aW9uIHN0aWxsIFRC RCkuJm5ic3A7IEhhdmUgdGhlIHBvcnRhbCBpbXBsZW1lbnRvcnMgcmV2aWV3ZWQgdGhpcyBhbmQg Z2l2ZW4gY29uc2lkZXJhdGlvbiBhcyB0byB3aGV0aGVyIGl0cyB1c2VmdWw/ICZuYnNwOyhJIHRo aW5rIG9mIHRoZSBkaXNjb3Zlcnkgb2YgdGhlIHBvcnRhbCBhbmQgc3Vic2VxdWVudCBpbnRlcmFj dGlvbiB3aXRoIGl0IGFzIDIgc2VwYXJhdGUgcHJvY2Vzc2VzIGNvbmR1Y3RlZCwgb2J2aW91c2x5 LA0KIGluIHNlcmlhbC4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+SSBiZWxpZXZlIHRoZXJlIGFyZSBzZXZlcmFsIHRhbGtpbmcgcG9pbnRzIGhlcmUsIGFzIHRo ZSBQdkQgbWV0aG9kIHNlZW1zIHRvIGhhdmUgc2V2ZXJhbCBwb3NzaWJsZSBpbXBsZW1lbnRhdGlv bnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SSB0aGluayByZXF1aXJpbmcgSXB2NiB0byBj b25maWd1cmUgSXB2NCBpcyB3ZWlyZCAoSSBiZWxpZXZlIHRoYXQgd2FzIG9uZSBwcm9wb3NlZCBt ZXRob2QgdG8gY29udmV5IGNvbmZpZ3VyYXRpb24pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+U2V2ZXJh bCBwb2ludHMgSSBtYWRlIGluIHRoZSB0aHJlYWQgJnF1b3Q7QXJndW1lbnRzIGFnYWluc3QgYW55 IENhcHBvcnQgQVBJJnF1b3Q7IHJlZ2FyZGluZyBhIHdlYiBzZXJ2aWNlIC0gZGV0YWNoZWQgZnJv bSB0aGUgTkFTIC0gY29udHJvbGxpbmcgdGhlIFVFL3N0YXRpb24gSSB0aGluayBhcmUgcmVsZXZh bnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SWYgdGhlIGF1dGhvcnMgb2YgdGhlIFB2RCBjb25jZXB0 IChyZS0pcHJlc2VudCB0aGVpciBJLUQgdG8gdGhlIG1haWxpbmcgbGlzdCwgYW5kIHN0aWNrIGFy b3VuZCBmb3IgZGlzY3Vzc2lvbiwgdGhhdCB3b3VsZCBiZSBoZWxwZnVsLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+VGhvdWdodHM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ2FwdGl2ZS1wb3J0YWxzIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpDYXB0aXZlLXBvcnRhbHNAaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPkNhcHRpdmUtcG9ydGFsc0BpZXRmLm9yZzwvc3Bhbj48L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYXB0 aXZlLXBvcnRhbHMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NhcHRpdmUtcG9ydGFsczwvc3Bh bj48L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6d2hpdGUi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj5DYXB0aXZlLXBvcnRhbHMgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBocmVmPSJtYWlsdG86Q2FwdGl2ZS1wb3J0YWxzQGll dGYub3JnIj5DYXB0aXZlLXBvcnRhbHNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NhcHRpdmUtcG9ydGFscyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jYXB0aXZlLXBvcnRhbHM8L2E+PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E8355113905631478EFF04F5AA706E9870638DF6wtlexchp1sandvi_-- From nobody Mon Jul 10 08:54:37 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CAF1317BD for ; Mon, 10 Jul 2017 08:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 QpCkhMRu6SLe for ; Mon, 10 Jul 2017 08:54:25 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17141317C4 for ; Mon, 10 Jul 2017 08:54:24 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 10 Jul 2017 11:54:22 -0400 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Mon, 10 Jul 2017 11:54:22 -0400 From: Dave Dolson To: David Bird , Tommy Pauly CC: "Eric Vyncke (evyncke)" , "captive-portals@ietf.org" Thread-Topic: [Captive-portals] Use Case: "Carrier Grade Captive Portal" Thread-Index: AQHSxAspm2jwFnBWgkqjQKiot+mYpKHim5WQgAHxpYCAKua1AIAALgAAgAJV74CABl/BAIAI6m4AgAOfPACADjOEMIADVqkAgAMFLHCAEevbAIACYi0A///YbYA= Date: Mon, 10 Jul 2017 15:54:21 +0000 Message-ID: References: <201705031442.50683.heiko.folkerts@bsi.bund.de> <1BB90528-B35F-43F0-AF18-0215DC735FF0@cable.comcast.com> <754719c5-c74c-fbdc-405e-b8c91478c0a5@netcologne.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.114] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9870638DFDwtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal" X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 15:54:35 -0000 --_000_E8355113905631478EFF04F5AA706E9870638DFDwtlexchp1sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGF2aWQsDQpJcyBpdCBmYWlyIHRvIHNheSB5b3VyIGNvbmNlcm5zIGFyZSBtYWlubHkgYWJvdXQg bWlzY29uZmlndXJlZCBuZXR3b3Jrcz8NCkFuZCB0aGlzIGlzIHRoZSByZWFzb24gdGhhdCBkZXZp Y2VzIHdpbGwgYWx3YXlzIGJlIGluY2VudGVkIHRvIHByb2JlIHJlZ2FyZGxlc3Mgb2YgYW55IG1l dGhvZCBvZiBwcm92aXNpb25pbmc/DQoNCi1EYXZlDQoNCg0KRnJvbTogRGF2aWQgQmlyZCBbbWFp bHRvOmRiaXJkQGdvb2dsZS5jb21dDQpTZW50OiBNb25kYXksIEp1bHkgMTAsIDIwMTcgOTozOSBB TQ0KVG86IFRvbW15IFBhdWx5DQpDYzogRGF2ZSBEb2xzb247IEVyaWMgVnluY2tlIChldnluY2tl KTsgY2FwdGl2ZS1wb3J0YWxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0NhcHRpdmUtcG9ydGFs c10gVXNlIENhc2U6ICJDYXJyaWVyIEdyYWRlIENhcHRpdmUgUG9ydGFsIg0KDQpPbiBTYXQsIEp1 bCA4LCAyMDE3IGF0IDY6MTQgUE0sIFRvbW15IFBhdWx5IDx0cGF1bHlAYXBwbGUuY29tPG1haWx0 bzp0cGF1bHlAYXBwbGUuY29tPj4gd3JvdGU6DQpbc25pcF0NClRoZSBpZGVhIHdpdGggZXhwbGlj aXQgUHZEIGRpc2NvdmVyeSBpcyB0aGF0IGl0IHdvdWxkLCBhcyBhIHN0ZXAsIHJlcGxhY2UgYSBz ZXBhcmF0ZSBjYXB0aXZlIHBvcnRhbCBkZXRlY3Rpb24gc3RyYXRlZ3kuDQoNCk15IG92ZXJhbGwg Y29uY2VybiB3aXRoIGRpc2NvdmVyeSBtZWNoYW5pc21zIHRoYXQgYXJlIHNwZWNpZmljIHRvIG9u bHkgY2FwdGl2ZSBwb3J0YWxzIGlzIHRoYXQgdGhpcyBpcyBhbiBleHRyYSBzdGVwIHRoYXQgaXMg cGVyZm9ybWVkIHBvdGVudGlhbGx5IG9uIGV2ZXJ5IG5ldHdvcmsgYXNzb2NpYXRpb24sIHRoYXQg bWF5IGhhdmUgbGltaXRlZCBleHRlbnNpYmlsaXR5IGZvciBub24tY2FwdGl2ZSB1c2UgY2FzZXMu IFNpbmNlIHRoZSBleHBsaWNpdCBQdkQgZGVzaWduIHByb21pc2VzIGEgd2F5IHRvIGRpc2NvdmVy IG1hbnkgcHJvcGVydGllcyBiZXlvbmQgY2FwdGl2aXR5LCBhbmQgaXMgYm9vdHN0cmFwcGVkIHZl cnkgZWFybHkgb24gaW4gdGhlIG5ldHdvcmsgYXNzb2NpYXRpb24sIGl0IHNob3VsZCBob3BlZnVs bHkgYWxsb3cgY2xpZW50cyB0byBhdm9pZCB0aGUgZXh0cmEgcHJvYmUuDQoNCg0KDQpJIGhhdmUg Y29uY2VybnMgd2l0aCB0aGUgUHZEIGFwcHJvYWNoLCBhcyBkZXNjcmliZWQuDQoNCklmIGEgbmV0 d29yayB3YXMgbWlzY29uZmlndXJlZCB0byBhZHZlcnRpc2UgYSBQdkQgdGhhdCBkb2VzIGhhdmUg YSAoSW50ZXJuZXQgYmFzZWQpIEhUVFBTIHNlcnZlciB3aXRoIGEgSlNPTiBmaWxlIG9uIGl0IGRl c2NyaWJpbmcgYSBjYXB0aXZlIHBvcnRhbCBuZXR3b3JrLCB0aGVuIGRldmljZXMgdXRpbGl6aW5n IHRoZSBQdkQgaW5mb3JtYXRpb24gd2lsbCAqbmV2ZXIqIGdldCBvbiB0aGlzIG5ldHdvcmsgd2hp bGUgZGV2aWNlcyBub3QgdXNpbmcgdGhlIFB2RCBpbmZvcm1hdGlvbiBkby4gVGhhdCBjb3VsZCBi ZSB2ZXJ5IGNvbmZ1c2luZyB0byB1c2VycyBhbmQgbmV0d29yayBhZG1pbmlzdHJhdG9ycyBhbGlr ZS4NCg0KSWYgeW91IGhhdmUgc2VlbiB3YWxsZWQgZ2FyZGVuIGNvbmZpZ3VyYXRpb25zIGZvciBs YXJnZSBuZXR3b3JrcywgeW91IHdpbGwgbm90aWNlIGEgbG90IGFib3V0IHRoZSBuZXR3b3JrIG9w ZXJhdG9yJ3MgbWFya2V0aW5nIHBhcnRuZXJzLiBJbmRlZWQsIG1hbnkgd2FsbGVkIGdhcmRlbnMg YXJlIG11Y2ggbGFyZ2VyIHRoYW4gdGhlIG5ldHdvcmsgcmVhbGx5IHdhbnRzLi4uIHNvbWV0aW1l cyB0aGV5IGp1c3QgbmVlZCB0byBtYWtlIHRoaW5ncyB3b3JrIGluIHRoZSBnYXJkZW4uIE15IHBv aW50IGhlcmUgaXMgdGhhdCBvcGVyYXRvcnMgbWF5IG5vdCAqd2FudCogdG8gbGlzdCBvdXQgdGhl aXIgd2FsbGVkIGdhcmRlbiBjb25maWd1cmF0aW9uIG9uIGEgcHVibGljIEpTT04gZmlsZS4uLg0K DQpBdCB0aGUgZW5kIG9mIHRoZSBkYXksIEknZCBhcmd1ZSB0aGF0IHRoZSBjbGllbnQgKndpbGwg YWx3YXlzIHByb2JlKiAtLSB3ZXRoZXIgaXQgbWVhbnMgdG8gb3Igbm90Li4uIEEgbmV0d29ya2lu ZyB1c2luZyBQdkQgY291bGQganVzdCBhZHZlcnRpc2UgYWxsIG5ldHdvcmtzIHJvdXRlcyBhcmUg YXZhaWxhYmxlIHNvIHRoYXQgdGhlIGRldmljZSBjb25uZWN0cyBvbmx5IHRvIGdldCBjYXVnaHQg dXAgaW4gYSBjYXB0aXZlIHBvcnRhbCByZWRpcmVjdCBhbnl3YXkuLi4gYmFjayB0byBzdGVwIDEg YW5kIGNhcHRpdmUgcG9ydGFsIGRldGVjdGlvbi4uDQoNCkknbSBhbHNvIHVuY2xlYXIgaG93IFB2 RCB3b3VsZCBkZWFsIHdpdGggc2NlbmFyaW9zIHdoZXJlIHlvdSBtaWdodCBzdGFydCBvdXQgd2l0 aCBpbnRlcm5ldCBjb25uZWN0aXZpdHkgKGUuZy4gIk1BQyBBdXRoZW50aWNhdGlvbiIpIHRoZW4g dG8gaGF2ZSBhIGNhcHRpdmUgcG9ydGFsIHJldHVybiBhZnRlciBhIHNlc3Npb24gdGltZW91dCBo YXMgb2NjdXJyZWQuLi4NCg0KDQoNCg0KDQpOb3RlOiB0aGUgc2FtZSDigJxjYXB0aXZlUG9ydGFs 4oCdIGtleSBpcyBhbHNvIGRlZmluZWQgaW4gc2VjdGlvbiA1LjMgYXMgYSBCb29sZWFuLiBTaG91 bGQgSSBjb25zaWRlciB0aGlzIHRvIGJlIGEgZGVmZWN0IGluIHRoZSBkcmFmdCwgb3IgYW0gSSBt aXNzaW5nIHNvbWV0aGluZz8NCg0KVGhlIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgKGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icnVuZWF1LWludGFyZWEtcHJvdmlzaW9u aW5nLWRvbWFpbnMtMDEpIGxlYXZlcyBvdXQgdGhlIHNwZWNpZmljIGtleXMgZm9yIGNhcHRpdmUg cG9ydGFscywgYW5kIGRpc2N1c3NlcyBpdCBtb3JlIGFic3RyYWN0bHkuIFRoYXQgd291bGQgYmUg YSBnb29kIHRoaW5nIHRvIG5haWwgZG93biBhdCB0aGUgUHJhZ3VlIG1lZXRpbmcuIElmIFB2RCBk ZXRlY3Rpb24gaXMgZG9uZSBnZW5lcmljYWxseSBvbiBuZXR3b3JrIGFzc29jaWF0aW9uLCB0aGVu IGEgYm9vbGVhbiBvciBzb21lIHdheSB0byBpbmRpY2F0ZSB0aGF0IHRoaXMgaXMgKm5vdCogYSBj YXB0aXZlIHBvcnRhbCB3aWxsIGFsbG93IHRoZSBkZXZpY2UgdG8gbm90IHBlcmZvcm0gZXh0cmEg cHJvYmluZy4gSWYgdGhlcmUgaXMgYSBjYXB0aXZlIG5ldHdvcmssIHdlIHNob3VsZCBiZSBhYmxl IHRvIGdldCB0aGUgcGFnZSBvciBpbnN0cnVjdGlvbnMgb24gaG93IHRvIGdldCBiZXlvbmQgY2Fw dGl2aXR5Lg0KDQpUaGFua3MsDQpUb21teQ0KDQoNCg0KDQotRGF2ZQ0KDQoNCg0KRnJvbTogRXJp YyBWeW5ja2UgKGV2eW5ja2UpIFttYWlsdG86ZXZ5bmNrZUBjaXNjby5jb21dDQpTZW50OiBTdW5k YXksIEp1bmUgMjUsIDIwMTcgODoyNyBQTQ0KVG86IERhdmUgRG9sc29uOyBjYXB0aXZlLXBvcnRh bHNAaWV0Zi5vcmc8bWFpbHRvOmNhcHRpdmUtcG9ydGFsc0BpZXRmLm9yZz4NCkNjOiBEYXZpZCBC aXJkDQpTdWJqZWN0OiBSZTogW0NhcHRpdmUtcG9ydGFsc10gVXNlIENhc2U6ICJDYXJyaWVyIEdy YWRlIENhcHRpdmUgUG9ydGFsIg0KDQpBdCBsZWFzdCBFcmlrIEtsaW5lIGFuZCBteXNlbGYgYXJl IGZvbGxvd2luZyB0aGUgY2FwdGl2ZS1wb3J0YWwgbGlzdCA6LSkNCg0KQW5kIHRoZSBtb3JlIHdl IHRoaW5rIGFib3V0IGl0LCBQdkQgY291bGQgcmVhbGx5IGJlIHVzZWZ1bCBhbmQgd2UsIHRoZSBQ dkQgSS1EIGF1dGhvcnMsIHdvdWxkIGJlIHBsZWFzZWQgdG8gcHJlc2VudCBhdCB5b3VyIFdHDQoN Ci3DqXJpYw0KDQpGcm9tOiBDYXB0aXZlLXBvcnRhbHMgPGNhcHRpdmUtcG9ydGFscy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpjYXB0aXZlLXBvcnRhbHMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJl aGFsZiBvZiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb208bWFpbHRvOmRkb2xzb25A c2FuZHZpbmUuY29tPj4NCkRhdGU6IEZyaWRheSAyMyBKdW5lIDIwMTcgYXQgMTE6NTcNClRvOiAi Y2FwdGl2ZS1wb3J0YWxzQGlldGYub3JnPG1haWx0bzpjYXB0aXZlLXBvcnRhbHNAaWV0Zi5vcmc+ IiA8Y2FwdGl2ZS1wb3J0YWxzQGlldGYub3JnPG1haWx0bzpjYXB0aXZlLXBvcnRhbHNAaWV0Zi5v cmc+Pg0KQ2M6IERhdmlkIEJpcmQgPGRiaXJkQGdvb2dsZS5jb208bWFpbHRvOmRiaXJkQGdvb2ds ZS5jb20+Pg0KU3ViamVjdDogUmU6IFtDYXB0aXZlLXBvcnRhbHNdIFVzZSBDYXNlOiAiQ2Fycmll ciBHcmFkZSBDYXB0aXZlIFBvcnRhbCINCg0KW3Jlc2VuZCB3aXRoIGZld2VyIHJlY2lwaWVudHMg dG8gYXZvaWQgbWFpbGluZyBsaXN0IHByb2JsZW1zXQ0KDQpUbyBlY2hvIERhdmlk4oCZcyByZXF1 ZXN0LA0KPiBJZiB0aGUgYXV0aG9ycyBvZiB0aGUgUHZEIGNvbmNlcHQgKHJlLSlwcmVzZW50IHRo ZWlyIEktRCB0byB0aGUgbWFpbGluZyBsaXN0LCBhbmQgc3RpY2sgYXJvdW5kIGZvciBkaXNjdXNz aW9uLCB0aGF0IHdvdWxkIGJlIGhlbHBmdWwuDQoNCg0KRnJvbTogRGF2aWQgQmlyZCBbbWFpbHRv OmRiaXJkQGdvb2dsZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMTQsIDIwMTcgOTozNiBB TQ0KVG86IEVyaWsgS2xpbmUNCkNjOiBHdW50aGVyIE5pdHpzY2hlOyBNYXJrIFRvd25zbGV5OyBI ZWlrbyBGb2xrZXJ0czsgTWFydGluIFRob21zb247IGNhcHRpdmUtcG9ydGFsc0BpZXRmLm9yZzxt YWlsdG86Y2FwdGl2ZS1wb3J0YWxzQGlldGYub3JnPjsgTGl2aW5nb29kLCBKYXNvbjsgSGVyemln LCBXaWxsaTsgV2FycmVuIEt1bWFyaTsgRGF2ZSBEb2xzb24NClN1YmplY3Q6IFJlOiBbQ2FwdGl2 ZS1wb3J0YWxzXSBVc2UgQ2FzZTogIkNhcnJpZXIgR3JhZGUgQ2FwdGl2ZSBQb3J0YWwiDQoNCk9u IFN1biwgSnVuIDExLCAyMDE3IGF0IDExOjE3IFBNLCBFcmlrIEtsaW5lIDxla0Bnb29nbGUuY29t PG1haWx0bzpla0Bnb29nbGUuY29tPj4gd3JvdGU6DQpJJ20gbm90IHN1cmUgd2UgaGF2ZSBlbm91 Z2ggaW5wdXQgb24gd2hldGhlciA1MTEgaXMgdXNlZnVsIG9yIG5vdC4gIFRoZXJlIHNlZW1lZCB0 byBiZSBzb21lIHN1Z2dlc3Rpb24gaXQgd291bGQgaGVscCwgYW5kIHNvbWUgdGhhdCBpdCB3b3Vs ZG4ndC4gIFBlcmhhcHMgb25lIHF1ZXN0aW9uIHdlIGNvdWxkIGFzayBpcyB3aGV0aGVyIGl0J3Mg aGFybWZ1bD8gIEFuZCBpZiB3ZSBhZ3JlZSBpdCdzIG5vdCBoYXJtZnVsLCBpcyBpdCB3b3J0aCBk ZXZlbG9waW5nIHNvbWUgcmVjb21tZW5kYXRpb25zIGZvciBpdHMgdXNlPw0KDQoNCkluIG9mIGl0 c2VsZiwgSSBkb24ndCBiZWxpZXZlIGl0IGlzIGhhcm1mdWwuIEhvd2V2ZXIsIGlmIHZlbmRvcnMg dXNlIGl0IGFzIGEgcmVhc29uIHRvIGNvbnRpbnVlIHRvIHRlcm1pbmF0ZSBUTFMgY29ubmVjdGlv biBpbiBvcmRlciB0byBkZWxpdmVyIHRoZSA1MTEsIHRoZW4gcGVyaGFwcyBpdCBpcyBhIGJpdCBo YXJtZnVsIC0gb3IgYXQgbGVhc3QgbWlzbGVhZGluZy4gQXMgdGhlIHdvcmxkIG1vdmVzIHRvIFRM UyAoYW5kIFFVSUMpLCBJIHRoaW5rIHRoZSB0aW1lIGZvciB0aGUgNTExIGNvZGUgaGFzIGFscmVh ZHkgcGFzc2VkLCB0byBzb21lIGRlZ3JlZS4gVGhhdCwgY29tYmluZWQgd2l0aCB0aGUgZmFjdCB5 b3UgbWF5IHN0aWxsIGhhdmUgYnJvd3NlcnMgbm90IGhhbmRsaW5nIHRoYXQgcmV0dXJuIGNvZGUg cHJvcGVybHksIEkgZG9uJ3Qgc2VlIHRoZSB2YWx1ZSBmb3IgYW55IHZlbmRvciBvciB2ZW51ZSB0 byBpbXBsZW1lbnQgdGhpcy4NCg0KDQpBcyBmb3IgdGhlIElDTVAgdW5yZWFjaGFibGUgb3B0aW9u LCBJIGNlcnRhaW5seSBkb24ndCB0aGluayBpdCB3b3VsZCBiZSBoYXJtZnVsICh3aXRoIHRoZSBl eHRyYSBVUkwgYml0cyByZW1vdmVkIGZvciBub3cpLiAgSXMgdGhhdCBzb21ldGhpbmcgd2Ugd2lz aCB0byBwcm9ncmVzcz8NCg0KDQpJIHdpbGwgd29yayBvbiBhIG5ldyBkcmFmdCB0aGF0IGlzIG9u bHkgdGhlIGJhc2ljcy4gVGhlIGFkZGl0aW9uYWwgZmllbGRzIGNvdWxkIGFsd2F5cyBiZSBhZGQg aW4gdGhlaXIgb3duIGRyYWZ0IGFzIGV4dGVuc2lvbnMuDQoNCg0KR2l2ZW4gdGhhdCB3ZSdyZSBw cm9iYWJseSBsb29raW5nIGF0IGEgcG9ydGFsIGRldGVjdGlvbiBtZXRob2QgYmFzZWQgb24gZW50 aXJlbHkgbmV3IHdvcmssIGl0IHNlZW1zIHRvIG1lIHdlJ3JlIGZyZWUgdG8gbG9vayBhdCBuZXcg dGhpbmdzIGxpa2UgdXRpbGl6aW5nIHRoZSBQVkQgZGV0ZWN0aW9uIHNjaGVtZSAoRE5TIHF1ZXJp ZXMgZm9yICJwcm92aXNpb25pbmcgZG9tYWluIG5hbWVzIiwgZm9sbG93ZWQgYnkgb3RoZXIgaW50 ZXJhY3Rpb24gc3RpbGwgVEJEKS4gIEhhdmUgdGhlIHBvcnRhbCBpbXBsZW1lbnRvcnMgcmV2aWV3 ZWQgdGhpcyBhbmQgZ2l2ZW4gY29uc2lkZXJhdGlvbiBhcyB0byB3aGV0aGVyIGl0cyB1c2VmdWw/ ICAoSSB0aGluayBvZiB0aGUgZGlzY292ZXJ5IG9mIHRoZSBwb3J0YWwgYW5kIHN1YnNlcXVlbnQg aW50ZXJhY3Rpb24gd2l0aCBpdCBhcyAyIHNlcGFyYXRlIHByb2Nlc3NlcyBjb25kdWN0ZWQsIG9i dmlvdXNseSwgaW4gc2VyaWFsLikNCg0KDQpJIGJlbGlldmUgdGhlcmUgYXJlIHNldmVyYWwgdGFs a2luZyBwb2ludHMgaGVyZSwgYXMgdGhlIFB2RCBtZXRob2Qgc2VlbXMgdG8gaGF2ZSBzZXZlcmFs IHBvc3NpYmxlIGltcGxlbWVudGF0aW9ucy4NCg0KSSB0aGluayByZXF1aXJpbmcgSXB2NiB0byBj b25maWd1cmUgSXB2NCBpcyB3ZWlyZCAoSSBiZWxpZXZlIHRoYXQgd2FzIG9uZSBwcm9wb3NlZCBt ZXRob2QgdG8gY29udmV5IGNvbmZpZ3VyYXRpb24pDQoNClNldmVyYWwgcG9pbnRzIEkgbWFkZSBp biB0aGUgdGhyZWFkICJBcmd1bWVudHMgYWdhaW5zdCBhbnkgQ2FwcG9ydCBBUEkiIHJlZ2FyZGlu ZyBhIHdlYiBzZXJ2aWNlIC0gZGV0YWNoZWQgZnJvbSB0aGUgTkFTIC0gY29udHJvbGxpbmcgdGhl IFVFL3N0YXRpb24gSSB0aGluayBhcmUgcmVsZXZhbnQuDQoNCklmIHRoZSBhdXRob3JzIG9mIHRo ZSBQdkQgY29uY2VwdCAocmUtKXByZXNlbnQgdGhlaXIgSS1EIHRvIHRoZSBtYWlsaW5nIGxpc3Qs IGFuZCBzdGljayBhcm91bmQgZm9yIGRpc2N1c3Npb24sIHRoYXQgd291bGQgYmUgaGVscGZ1bC4N Cg0KDQpUaG91Z2h0cz8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkNhcHRpdmUtcG9ydGFscyBtYWlsaW5nIGxpc3QNCkNhcHRpdmUtcG9ydGFsc0Bp ZXRmLm9yZzxtYWlsdG86Q2FwdGl2ZS1wb3J0YWxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYXB0aXZlLXBvcnRhbHMNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNhcHRpdmUtcG9ydGFscyBtYWlsaW5n IGxpc3QNCkNhcHRpdmUtcG9ydGFsc0BpZXRmLm9yZzxtYWlsdG86Q2FwdGl2ZS1wb3J0YWxzQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYXB0aXZlLXBv cnRhbHMNCg0KDQo= --_000_E8355113905631478EFF04F5AA706E9870638DFDwtlexchp1sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4ubS0zNjUzNTY5MzQ3 NTUzODMyNjQwYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOm1fLTM2NTM1 NjkzNDc1NTM4MzI2NDBhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRhdmlkLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JcyBpdCBmYWlyIHRvIHNheSB5b3VyIGNvbmNlcm5zIGFyZSBtYWlubHkg YWJvdXQgbWlzY29uZmlndXJlZCBuZXR3b3Jrcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QW5kIHRoaXMgaXMgdGhlIHJlYXNvbiB0aGF0IGRldmljZXMgd2lsbCBhbHdheXMgYmUgaW5j ZW50ZWQgdG8gcHJvYmUgcmVnYXJkbGVzcyBvZiBhbnkgbWV0aG9kIG9mIHByb3Zpc2lvbmluZz88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPi1EYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRGF2aWQgQmlyZCBbbWFpbHRv OmRiaXJkQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdWx5IDEwLCAy MDE3IDk6MzkgQU08YnI+DQo8Yj5Ubzo8L2I+IFRvbW15IFBhdWx5PGJyPg0KPGI+Q2M6PC9iPiBE YXZlIERvbHNvbjsgRXJpYyBWeW5ja2UgKGV2eW5ja2UpOyBjYXB0aXZlLXBvcnRhbHNAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDYXB0aXZlLXBvcnRhbHNdIFVzZSBDYXNlOiAm cXVvdDtDYXJyaWVyIEdyYWRlIENhcHRpdmUgUG9ydGFsJnF1b3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIEp1bCA4LCAyMDE3IGF0 IDY6MTQgUE0sIFRvbW15IFBhdWx5ICZsdDs8YSBocmVmPSJtYWlsdG86dHBhdWx5QGFwcGxlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnRwYXVseUBhcHBsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W3NuaXBdJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpZGVhIHdpdGggZXhwbGljaXQgUHZE IGRpc2NvdmVyeSBpcyB0aGF0IGl0IHdvdWxkLCBhcyBhIHN0ZXAsIHJlcGxhY2UgYSBzZXBhcmF0 ZSBjYXB0aXZlIHBvcnRhbCBkZXRlY3Rpb24gc3RyYXRlZ3kuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IG92ZXJhbGwgY29uY2VybiB3aXRo IGRpc2NvdmVyeSBtZWNoYW5pc21zIHRoYXQgYXJlIHNwZWNpZmljIHRvIG9ubHkgY2FwdGl2ZSBw b3J0YWxzIGlzIHRoYXQgdGhpcyBpcyBhbiBleHRyYSBzdGVwIHRoYXQgaXMgcGVyZm9ybWVkIHBv dGVudGlhbGx5IG9uIGV2ZXJ5IG5ldHdvcmsgYXNzb2NpYXRpb24sIHRoYXQgbWF5IGhhdmUgbGlt aXRlZCBleHRlbnNpYmlsaXR5IGZvciBub24tY2FwdGl2ZSB1c2UgY2FzZXMuDQogU2luY2UgdGhl IGV4cGxpY2l0IFB2RCBkZXNpZ24gcHJvbWlzZXMgYSB3YXkgdG8gZGlzY292ZXIgbWFueSBwcm9w ZXJ0aWVzIGJleW9uZCBjYXB0aXZpdHksIGFuZCBpcyBib290c3RyYXBwZWQgdmVyeSBlYXJseSBv biBpbiB0aGUgbmV0d29yayBhc3NvY2lhdGlvbiwgaXQgc2hvdWxkIGhvcGVmdWxseSBhbGxvdyBj bGllbnRzIHRvIGF2b2lkIHRoZSBleHRyYSBwcm9iZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBo YXZlIGNvbmNlcm5zIHdpdGggdGhlIFB2RCBhcHByb2FjaCwgYXMgZGVzY3JpYmVkLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBhIG5ldHdv cmsgd2FzIG1pc2NvbmZpZ3VyZWQgdG8gYWR2ZXJ0aXNlIGEgUHZEIHRoYXQgZG9lcyBoYXZlIGEg KEludGVybmV0IGJhc2VkKSBIVFRQUyBzZXJ2ZXIgd2l0aCBhIEpTT04gZmlsZSBvbiBpdCBkZXNj cmliaW5nIGEgY2FwdGl2ZSBwb3J0YWwgbmV0d29yaywgdGhlbiBkZXZpY2VzIHV0aWxpemluZyB0 aGUgUHZEIGluZm9ybWF0aW9uIHdpbGwgKm5ldmVyKiBnZXQgb24gdGhpcyBuZXR3b3JrIHdoaWxl DQogZGV2aWNlcyBub3QgdXNpbmcgdGhlIFB2RCBpbmZvcm1hdGlvbiBkby4gVGhhdCBjb3VsZCBi ZSB2ZXJ5IGNvbmZ1c2luZyB0byB1c2VycyBhbmQgbmV0d29yayBhZG1pbmlzdHJhdG9ycyBhbGlr ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SWYgeW91IGhhdmUgc2VlbiB3YWxsZWQgZ2FyZGVuIGNvbmZpZ3VyYXRpb25zIGZvciBs YXJnZSBuZXR3b3JrcywgeW91IHdpbGwgbm90aWNlIGEgbG90IGFib3V0IHRoZSBuZXR3b3JrIG9w ZXJhdG9yJ3MgbWFya2V0aW5nIHBhcnRuZXJzLiBJbmRlZWQsIG1hbnkgd2FsbGVkIGdhcmRlbnMg YXJlIG11Y2ggbGFyZ2VyIHRoYW4gdGhlIG5ldHdvcmsgcmVhbGx5IHdhbnRzLi4uIHNvbWV0aW1l cyB0aGV5IGp1c3QgbmVlZA0KIHRvIG1ha2UgdGhpbmdzIHdvcmsgaW4gdGhlIGdhcmRlbi4gTXkg cG9pbnQgaGVyZSBpcyB0aGF0IG9wZXJhdG9ycyBtYXkgbm90ICp3YW50KiB0byBsaXN0IG91dCB0 aGVpciB3YWxsZWQgZ2FyZGVuIGNvbmZpZ3VyYXRpb24gb24gYSBwdWJsaWMgSlNPTiBmaWxlLi4u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0 IHRoZSBlbmQgb2YgdGhlIGRheSwgSSdkIGFyZ3VlIHRoYXQgdGhlIGNsaWVudCAqd2lsbCBhbHdh eXMgcHJvYmUqIC0tIHdldGhlciBpdCBtZWFucyB0byBvciBub3QuLi4gQSBuZXR3b3JraW5nIHVz aW5nIFB2RCBjb3VsZCBqdXN0IGFkdmVydGlzZSBhbGwgbmV0d29ya3Mgcm91dGVzIGFyZSBhdmFp bGFibGUgc28gdGhhdCB0aGUgZGV2aWNlIGNvbm5lY3RzIG9ubHkgdG8gZ2V0IGNhdWdodCB1cCBp biBhIGNhcHRpdmUNCiBwb3J0YWwgcmVkaXJlY3QgYW55d2F5Li4uIGJhY2sgdG8gc3RlcCAxIGFu ZCBjYXB0aXZlIHBvcnRhbCBkZXRlY3Rpb24uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gYWxzbyB1bmNsZWFyIGhvdyBQdkQgd291bGQg ZGVhbCB3aXRoIHNjZW5hcmlvcyB3aGVyZSB5b3UgbWlnaHQgc3RhcnQgb3V0IHdpdGggaW50ZXJu ZXQgY29ubmVjdGl2aXR5IChlLmcuICZxdW90O01BQyBBdXRoZW50aWNhdGlvbiZxdW90OykgdGhl biB0byBoYXZlIGEgY2FwdGl2ZSBwb3J0YWwgcmV0dXJuIGFmdGVyIGEgc2Vzc2lvbiB0aW1lb3V0 IGhhcyBvY2N1cnJlZC4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPk5vdGU6IHRoZSBzYW1lIOKAnGNhcHRpdmVQb3J0YWzigJ0ga2V5IGlz IGFsc28gZGVmaW5lZCBpbiBzZWN0aW9uIDUuMyBhcyBhIEJvb2xlYW4uIFNob3VsZCBJIGNvbnNp ZGVyIHRoaXMgdG8gYmUgYSBkZWZlY3QgaW4gdGhlIGRyYWZ0LA0KIG9yIGFtIEkgbWlzc2luZyBz b21ldGhpbmc/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdXBkYXRlZCB2ZXJzaW9u IG9mIHRoZSBkcmFmdCAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWJydW5lYXUtaW50YXJlYS1wcm92aXNpb25pbmctZG9tYWlucy0wMSIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icnVuZWF1LWludGFyZWEtcHJvdmlz aW9uaW5nLWRvbWFpbnMtMDE8L2E+KSBsZWF2ZXMgb3V0IHRoZSBzcGVjaWZpYw0KIGtleXMgZm9y IGNhcHRpdmUgcG9ydGFscywgYW5kIGRpc2N1c3NlcyBpdCBtb3JlIGFic3RyYWN0bHkuIFRoYXQg d291bGQgYmUgYSBnb29kIHRoaW5nIHRvIG5haWwgZG93biBhdCB0aGUgUHJhZ3VlIG1lZXRpbmcu IElmIFB2RCBkZXRlY3Rpb24gaXMgZG9uZSBnZW5lcmljYWxseSBvbiBuZXR3b3JrIGFzc29jaWF0 aW9uLCB0aGVuIGEgYm9vbGVhbiBvciBzb21lIHdheSB0byBpbmRpY2F0ZSB0aGF0IHRoaXMgaXMg Km5vdCogYSBjYXB0aXZlIHBvcnRhbA0KIHdpbGwgYWxsb3cgdGhlIGRldmljZSB0byBub3QgcGVy Zm9ybSBleHRyYSBwcm9iaW5nLiBJZiB0aGVyZSBpcyBhIGNhcHRpdmUgbmV0d29yaywgd2Ugc2hv dWxkIGJlIGFibGUgdG8gZ2V0IHRoZSBwYWdlIG9yIGluc3RydWN0aW9ucyBvbiBob3cgdG8gZ2V0 IGJleW9uZCBjYXB0aXZpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRvbW15PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPi1EYXZlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJtLTM2NTM1NjkzNDc1NTM4MzI2NDBhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5FcmljDQogVnluY2tlIChldnluY2tl KSBbPGEgaHJlZj0ibWFpbHRvOmV2eW5ja2VAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFp bHRvOmV2eW5ja2VAY2lzY28uY29tPC9hPl08c3BhbiBjbGFzcz0ibS0zNjUzNTY5MzQ3NTUzODMy NjQwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+ PHNwYW4gY2xhc3M9Im0tMzY1MzU2OTM0NzU1MzgzMjY0MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlN1bmRheSwgSnVuZSAyNSwgMjAxNyA4OjI3IFBNPGJyPg0KPGI+VG86PC9i PjxzcGFuIGNsYXNzPSJtLTM2NTM1NjkzNDc1NTM4MzI2NDBhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5EYXZlIERvbHNvbjsNCjxhIGhyZWY9Im1haWx0bzpjYXB0aXZlLXBvcnRh bHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jYXB0aXZlLXBvcnRhbHNAaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJtLTM2NTM1NjkzNDc1NTM4MzI2NDBhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5EYXZpZCBCaXJkPGJyPg0KPGI+U3ViamVjdDo8 L2I+PHNwYW4gY2xhc3M9Im0tMzY1MzU2OTM0NzU1MzgzMjY0MGFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPlJlOiBbQ2FwdGl2ZS1wb3J0YWxzXSBVc2UgQ2FzZTogJnF1b3Q7Q2Fy cmllciBHcmFkZSBDYXB0aXZlIFBvcnRhbCZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5BdCBsZWFzdCBFcmlrIEtsaW5lIGFuZCBteXNlbGYgYXJlIGZvbGxv d2luZyB0aGUgY2FwdGl2ZS1wb3J0YWwgbGlzdCA6LSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BbmQgdGhlIG1vcmUgd2UgdGhp bmsgYWJvdXQgaXQsIFB2RCBjb3VsZCByZWFsbHkgYmUgdXNlZnVsIGFuZCB3ZSwgdGhlIFB2RCBJ LUQgYXV0aG9ycywgd291bGQgYmUgcGxlYXNlZCB0byBwcmVzZW50IGF0IHlvdXIgV0c8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4t w6lyaWM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8c3BhbiBjbGFzcz0ibS0zNjUzNTY5MzQ3NTUzODMyNjQw YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5DYXB0aXZlLXBvcnRhbHMgJmx0OzxhIGhyZWY9Im1haWx0bzpjYXB0aXZlLXBvcnRhbHMtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNhcHRpdmUtcG9ydGFscy1ib3VuY2VzQGll dGYub3JnPC9hPiZndDsNCiBvbiBiZWhhbGYgb2YgRGF2ZSBEb2xzb24gJmx0OzxhIGhyZWY9Im1h aWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRkb2xzb25Ac2FuZHZp bmUuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJtLTM2NTM1NjkzNDc1NTM4 MzI2NDBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+RnJpZGF5IDIzIEp1 bmUgMjAxNyBhdCAxMTo1Nzxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJtLTM2NTM1NjkzNDc1NTM4 MzI2NDBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOmNhcHRpdmUtcG9ydGFsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNhcHRp dmUtcG9ydGFsc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjYXB0aXZl LXBvcnRhbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jYXB0aXZlLXBvcnRhbHNAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNzPSJtLTM2NTM1NjkzNDc1NTM4MzI2NDBh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+RGF2aWQgQmlyZCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRiaXJkQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5kYmlyZEBnb29n bGUuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJtLTM2NTM1NjkzNDc1 NTM4MzI2NDBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UmU6IFtDYXB0 aXZlLXBvcnRhbHNdIFVzZSBDYXNlOiAmcXVvdDtDYXJyaWVyIEdyYWRlIENhcHRpdmUgUG9ydGFs JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPltyZXNlbmQgd2l0aCBmZXdlciByZWNpcGllbnRzIHRvIGF2b2lkIG1haWxp bmcgbGlzdCBwcm9ibGVtc108L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG8gZWNo byBEYXZpZOKAmXMgcmVxdWVzdCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgSWYgdGhlIGF1dGhvcnMgb2Yg dGhlIFB2RCBjb25jZXB0IChyZS0pcHJlc2VudCB0aGVpciBJLUQgdG8gdGhlIG1haWxpbmcgbGlz dCwgYW5kIHN0aWNrIGFyb3VuZCBmb3IgZGlzY3Vzc2lvbiwgdGhhdCB3b3VsZCBiZSBoZWxwZnVs Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBjbGFzcz0ibS0zNjUzNTY5MzQ3NTUzODMyNjQwYXBwbGUtY29udmVydGVkLXNwYWNl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGF2aWQNCiBCaXJkIFs8YSBocmVmPSJtYWlsdG86ZGJpcmRA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpkYmlyZEBnb29nbGUuY29tPC9hPl08 c3BhbiBjbGFzcz0ibS0zNjUzNTY5MzQ3NTUzODMyNjQwYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9Im0tMzY1MzU2OTM0NzU1 MzgzMjY0MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlZG5lc2RheSwgSnVu ZSAxNCwgMjAxNyA5OjM2IEFNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJtLTM2NTM1Njkz NDc1NTM4MzI2NDBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5FcmlrIEtsaW5l PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJtLTM2NTM1NjkzNDc1NTM4MzI2NDBhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5HdW50aGVyIE5pdHpzY2hlOyBNYXJrIFRvd25z bGV5OyBIZWlrbyBGb2xrZXJ0czsgTWFydGluIFRob21zb247DQo8YSBocmVmPSJtYWlsdG86Y2Fw dGl2ZS1wb3J0YWxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2FwdGl2ZS1wb3J0YWxzQGll dGYub3JnPC9hPjsgTGl2aW5nb29kLCBKYXNvbjsgSGVyemlnLCBXaWxsaTsgV2FycmVuIEt1bWFy aTsgRGF2ZSBEb2xzb248YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0ibS0zNjUzNTY5 MzQ3NTUzODMyNjQwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtDYXB0 aXZlLXBvcnRhbHNdIFVzZSBDYXNlOiAmcXVvdDtDYXJyaWVyIEdyYWRlIENhcHRpdmUgUG9ydGFs JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9uIFN1biwgSnVuIDExLCAyMDE3IGF0IDExOjE3IFBN LCBFcmlrIEtsaW5lICZsdDs8YSBocmVmPSJtYWlsdG86ZWtAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmVrQGdvb2dsZS5jb208L3NwYW4+PC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPkknbSBub3Qgc3VyZSB3ZSBoYXZlIGVub3VnaCBpbnB1dCBvbiB3aGV0aGVyIDUxMSBpcyB1 c2VmdWwgb3Igbm90LiZuYnNwOyBUaGVyZSBzZWVtZWQgdG8gYmUgc29tZSBzdWdnZXN0aW9uIGl0 IHdvdWxkIGhlbHAsIGFuZCBzb21lIHRoYXQgaXQgd291bGRuJ3QuJm5ic3A7IFBlcmhhcHMgb25l IHF1ZXN0aW9uIHdlIGNvdWxkIGFzayBpcyB3aGV0aGVyIGl0J3MgaGFybWZ1bD8mbmJzcDsgQW5k IGlmDQogd2UgYWdyZWUgaXQncyBub3QgaGFybWZ1bCwgaXMgaXQgd29ydGggZGV2ZWxvcGluZyBz b21lIHJlY29tbWVuZGF0aW9ucyBmb3IgaXRzIHVzZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj5JbiBvZiBpdHNlbGYsIEkgZG9uJ3QgYmVsaWV2ZSBpdCBpcyBoYXJtZnVsLiBIb3dldmVy LCBpZiB2ZW5kb3JzIHVzZSBpdCBhcyBhIHJlYXNvbiB0byBjb250aW51ZSB0byB0ZXJtaW5hdGUg VExTIGNvbm5lY3Rpb24gaW4gb3JkZXIgdG8gZGVsaXZlciB0aGUgNTExLCB0aGVuIHBlcmhhcHMg aXQgaXMgYSBiaXQgaGFybWZ1bCAtIG9yIGF0IGxlYXN0IG1pc2xlYWRpbmcuDQogQXMgdGhlIHdv cmxkIG1vdmVzIHRvIFRMUyAoYW5kIFFVSUMpLCBJIHRoaW5rIHRoZSB0aW1lIGZvciB0aGUgNTEx IGNvZGUgaGFzIGFscmVhZHkgcGFzc2VkLCB0byBzb21lIGRlZ3JlZS4gVGhhdCwgY29tYmluZWQg d2l0aCB0aGUgZmFjdCB5b3UgbWF5IHN0aWxsIGhhdmUgYnJvd3NlcnMgbm90IGhhbmRsaW5nIHRo YXQgcmV0dXJuIGNvZGUgcHJvcGVybHksIEkgZG9uJ3Qgc2VlIHRoZSB2YWx1ZSBmb3IgYW55IHZl bmRvciBvciB2ZW51ZSB0byBpbXBsZW1lbnQNCiB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+QXMg Zm9yIHRoZSBJQ01QIHVucmVhY2hhYmxlIG9wdGlvbiwgSSBjZXJ0YWlubHkgZG9uJ3QgdGhpbmsg aXQgd291bGQgYmUgaGFybWZ1bCAod2l0aCB0aGUgZXh0cmEgVVJMIGJpdHMgcmVtb3ZlZCBmb3Ig bm93KS4mbmJzcDsgSXMgdGhhdCBzb21ldGhpbmcgd2Ugd2lzaCB0byBwcm9ncmVzcz88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JIHdpbGwgd29yayBvbiBhIG5l dyBkcmFmdCB0aGF0IGlzIG9ubHkgdGhlIGJhc2ljcy4gVGhlIGFkZGl0aW9uYWwgZmllbGRzIGNv dWxkIGFsd2F5cyBiZSBhZGQgaW4gdGhlaXIgb3duIGRyYWZ0IGFzIGV4dGVuc2lvbnMuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj5HaXZlbiB0aGF0IHdlJ3JlIHByb2JhYmx5IGxvb2tpbmcgYXQg YSBwb3J0YWwgZGV0ZWN0aW9uIG1ldGhvZCBiYXNlZCBvbiBlbnRpcmVseSBuZXcgd29yaywgaXQg c2VlbXMgdG8gbWUgd2UncmUgZnJlZSB0byBsb29rIGF0IG5ldyB0aGluZ3MgbGlrZSB1dGlsaXpp bmcgdGhlIFBWRCBkZXRlY3Rpb24gc2NoZW1lIChETlMgcXVlcmllcyBmb3IgJnF1b3Q7cHJvdmlz aW9uaW5nIGRvbWFpbg0KIG5hbWVzJnF1b3Q7LCBmb2xsb3dlZCBieSBvdGhlciBpbnRlcmFjdGlv biBzdGlsbCBUQkQpLiZuYnNwOyBIYXZlIHRoZSBwb3J0YWwgaW1wbGVtZW50b3JzIHJldmlld2Vk IHRoaXMgYW5kIGdpdmVuIGNvbnNpZGVyYXRpb24gYXMgdG8gd2hldGhlciBpdHMgdXNlZnVsPyAm bmJzcDsoSSB0aGluayBvZiB0aGUgZGlzY292ZXJ5IG9mIHRoZSBwb3J0YWwgYW5kIHN1YnNlcXVl bnQgaW50ZXJhY3Rpb24gd2l0aCBpdCBhcyAyIHNlcGFyYXRlIHByb2Nlc3NlcyBjb25kdWN0ZWQs IG9idmlvdXNseSwNCiBpbiBzZXJpYWwuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPkkgYmVsaWV2ZSB0aGVyZSBhcmUgc2V2ZXJhbCB0YWxraW5nIHBvaW50cyBo ZXJlLCBhcyB0aGUgUHZEIG1ldGhvZCBzZWVtcyB0byBoYXZlIHNldmVyYWwgcG9zc2libGUgaW1w bGVtZW50YXRpb25zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkkgdGhpbmsgcmVxdWlyaW5n IElwdjYgdG8gY29uZmlndXJlIElwdjQgaXMgd2VpcmQgKEkgYmVsaWV2ZSB0aGF0IHdhcyBvbmUg cHJvcG9zZWQgbWV0aG9kIHRvIGNvbnZleSBjb25maWd1cmF0aW9uKTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPlNldmVyYWwgcG9pbnRzIEkgbWFkZSBpbiB0aGUgdGhyZWFkICZxdW90O0FyZ3VtZW50cyBh Z2FpbnN0IGFueSBDYXBwb3J0IEFQSSZxdW90OyByZWdhcmRpbmcgYSB3ZWIgc2VydmljZSAtIGRl dGFjaGVkIGZyb20gdGhlIE5BUyAtIGNvbnRyb2xsaW5nIHRoZSBVRS9zdGF0aW9uIEkgdGhpbmsg YXJlIHJlbGV2YW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPklmIHRoZSBhdXRob3JzIG9mIHRoZSBQ dkQgY29uY2VwdCAocmUtKXByZXNlbnQgdGhlaXIgSS1EIHRvIHRoZSBtYWlsaW5nIGxpc3QsIGFu ZCBzdGljayBhcm91bmQgZm9yIGRpc2N1c3Npb24sIHRoYXQgd291bGQgYmUgaGVscGZ1bC4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRob3VnaHRzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkNhcHRpdmUtcG9ydGFs cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q2FwdGl2ZS1wb3J0YWxzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Q2FwdGl2ZS1w b3J0YWxzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NhcHRpdmUtcG9ydGFscyIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2FwdGl2ZS1wb3J0YWxzPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OztiYWNrZ3JvdW5kOndoaXRlIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Q2FwdGl2ZS1wb3J0YWxz IG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PGEgaHJlZj0ibWFpbHRvOkNhcHRpdmUtcG9ydGFsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PkNhcHRpdmUtcG9ydGFsc0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2FwdGl2ZS1wb3J0YWxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jYXB0aXZlLXBvcnRhbHM8L2E+PC9zcGFuPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E8355113905631478EFF04F5AA706E9870638DFDwtlexchp1sandvi_-- From nobody Mon Jul 10 20:13:38 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8236E129B33 for ; Mon, 10 Jul 2017 20:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 2p-MHl3StXy0 for ; Mon, 10 Jul 2017 20:13:34 -0700 (PDT) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (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 D921512EC13 for ; Mon, 10 Jul 2017 20:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1499742813; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PcEDG7A10ovXrp+EwUDMcrU1uzX8cLOo9ryCTfshuUk=; b=txhNG6rKxjDPrO72X1G/bkGI+UR6NydcwVMnMXvA/vMLnZRJtd1zHmlRc11CGZRN nh9ppS/Fj7MWJLKssdmoThw76TmmmimCKLKwzg+O0OhcE0somNB4tUW6iG13PGqT cef/Neoqabwm+G1i6M9ygUtwb0Dqknt/OOfOm8kVIfC+gq+6qQ679nQgra4r/VS7 lXNzmuPBlTuALeIZ2tV314TmH+Gnesi1UOYSWTD+j4momsr09PkQJSrODOyB4tYp 4thju6sSEIjHQFh0nkPo+1RiLq1mIEirGLNQIcmwEMsNa1Ge5SwpYu+n24if8X9s WHXEj3ilidPxQtBF7OIxIA==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id AD.E3.08001.C5244695; Mon, 10 Jul 2017 20:13:33 -0700 (PDT) X-AuditID: 11ab0217-c21ff70000001f41-41-5964425b310d Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay4.apple.com (Apple SCV relay) with SMTP id FE.F0.06992.B5244695; Mon, 10 Jul 2017 20:13:31 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_PNKqFKT2gSv4mN4sBuaSxw)" Received: from [17.234.24.3] (unknown [17.234.24.3]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSW00D2HOYJ9P50@nwk-mmpp-sz12.apple.com>; Mon, 10 Jul 2017 20:13:31 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Mon, 10 Jul 2017 20:13:30 -0700 In-reply-to: Cc: "Eric Vyncke (evyncke)" , "captive-portals@ietf.org" , David Bird To: Dave Dolson References: <201705031442.50683.heiko.folkerts@bsi.bund.de> <1BB90528-B35F-43F0-AF18-0215DC735FF0@cable.comcast.com> <754719c5-c74c-fbdc-405e-b8c91478c0a5@netcologne.de> X-Mailer: Apple Mail (2.3439) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUi2FAYrhvrlBJpcKyXzWLurAZWi08/tjNa bF32kN3iy/4FjA4sHlN+b2T1WLCp1GPJkp9MHl83b2cNYInisklJzcksSy3St0vgylj79yN7 wdKTzBWXHh5nbmA8NoG5i5GTQ0LARKJ5aj9bFyMXh5DAGiaJnv4nTDCJ1dteM0MkDjFKNO68 yAiS4BUQlPgx+R4LiM0sECbxuPUUI0RRN5PEnJ5JQA4Hh7CAhMTmPYkgNWwCKhLHv21ghui1 kTj2eBUriC0s4C5x7MUbsJksAqoSK5/3gs3kFAiQmNl8lwlkJrNAJ6PEhA07wJpFBNQklt74 xAqxrIld4sur06wgyyQEZCWW/gkBiUsILGOXaJyyg2UCo9AsJMfOQnLsLKAWZgF1iSlTciHC 2hJP3l1ghbDVJBb+XsSELL6AkW0Vo3BuYmaObmaekbFeYkFBTqpecn7uJkZQ5KxmEt/B+Pm1 4SFGAQ5GJR5ejbfJkUKsiWXFlbmHGKU5WJTEeU8oAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUwdgp3zmp89sG+v948Jl7cTIpFRjj1xWwmdYao3fcnzRfeJhYb/EUla+YD04qflxttM3VX vNgQ0rqy5Jg2U+WfvzZMCid5DB1CU7rYr9XayWlPU13z/OiFCvF6uSXLTqt3W78/avc2/Fz1 4rtip67c8phqlP/C9+/WyNK2d6LzVOR/7mToNb6lxFKckWioxVxUnAgAEPyoeH0CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsUi2FB8RjfaKSXSYOolbYu5sxpYLT792M5o sXXZQ3aLL/sXMDqweEz5vZHVY8GmUo8lS34yeXzdvJ01gCXK2iYtv6g8sShFoSi5oMRWqTgj MSW/PN7S2MjUIbGgICdVLzk/V0nfziYlNSezLLUImZVgnbH270f2gqUnmSsuPTzO3MB4bAJz FyMnh4SAicTqba+BbC4OIYFDjBKNOy8ygiR4BQQlfky+xwJiMwuESTxuPcUIUdTNJDGnZxKQ w8EhLCAhsXlPIkgNm4CKxPFvG5ghem0kjj1exQpiCwu4Sxx78QZsJouAqsTK571gMzkFAiRm Nt9lApnJLNDJKDFhww6wZhEBNYmlNz6xQixrYpf48uo0K8gyCQFZiaV/QiYw8s9Cct8sJPfN AqpiFlCXmDIlFyKsLfHk3QVWCFtNYuHvRUzI4gsY2VYxChSl5iRWmujBQ3ATIziSCsN3MP5b ZnWIUYCDUYmHV6A3OVKINbGsuDIXGEgczEoivDniKZFCvCmJlVWpRfnxRaU5qcWHGPczAn05 kVlKNDkfGOd5JfGGxhbGliYWBgYmlmYmhIVNTAxMjI3NjI3NTcxpKawkzmvCFxspJJCeWJKa nZpakFoE8wITB6dUA2OapISREzPvZkGeu/q7J71PdheI9v8ZdHRn7foeA98KpStxP0RXufx5 9NnY8ePJvqdRU/r4frne/fp6p7GzWsTtf/ZHZN6VvO3l3FW+6c1dVf1jLj2dq0XertSbmVjL cinpxPT5bUovDr29Wyn17OK8rztDP4r3SZyWnO/RWvHvC4ffTJlH61iUWIDp21CLuag4EQDo 2F4hRQMAAA== Archived-At: Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal" X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 03:13:37 -0000 --Boundary_(ID_PNKqFKT2gSv4mN4sBuaSxw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Dave, > On Jul 10, 2017, at 8:54 AM, Dave Dolson wrote: >=20 > At the last meeting, I think we heard, =E2=80=9CPvDs can help solve = this problem.=E2=80=9D > (This seems to me to be true.) > Are the PvD authors backing away from this assertion? No, we=E2=80=99re definitely still saying that PvDs can help solve the = Captive Portal problem. The details of the JSON aren=E2=80=99t in latest = revision of the main PvD document just to focus the scope of the draft, = but the idea would be that the PvD provisioning information would be how = you bootstrap captive portal discovery. > =20 > I think there are two aspects: > 1. The PvD data structures on the end-user device, which track = captivity state per PvD. (RFC 7556 discusses connectivity tests per = PvD.) > 2. Whether the PvD protocol explicitly conveys the = captive-portal concept. > =20 > If I understand correctly, (1) could be achieved even if capport = information is conveyed in DHCP or RAs (vs. in the PvD protocol). > However, that points to yet another API to query. You=E2=80=99re correct. A client device can keep track of PvD = information and already should associate captivity when discovered with = the implicit PvD. Part (2) is saying that if we are doing external PvD = discovery anyway, it should include captivity information. This is how = we avoid the extra API to call. > =20 > I think that draft-bruneau-intarea-provisioning-domains has addressed = a problem more generic than the CAPPORT API problem. > And therefore I=E2=80=99m feeling it is still worth pursuing. Right, the draft is more generic than the captive portal right now. I = could imagine that we make sure that the CAPPORT solution references and = works well with PvDs. Thanks, Tommy > =20 > =20 > I think Tommy makes a great point that there is value in explicitly = indicating, =E2=80=9Cthis is not a captive portal=E2=80=9D. This ought = to speed up network association. > =20 > =20 > -Dave > =20 > =20 > =20 > From: tpauly@apple.com = [mailto:tpauly@apple.com ]=20 > Sent: Saturday, July 8, 2017 9:15 PM > To: Dave Dolson > Cc: Eric Vyncke (evyncke); captive-portals@ietf.org = ; David Bird > Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive = Portal" > =20 > =20 >=20 >=20 > On Jun 27, 2017, at 12:46 PM, Dave Dolson > wrote: > =20 > Eric, > Do I understand correctly from = https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-00#= section-5.5 = > that the intention is for the JSON key =E2=80=9CcaptivePortal=E2=80=9D = to indicate that the specified URL is to be visited by the browser to = navigate the requirements for exiting captivity? > =20 > If so, would you say this URL should be used in place of performing a = capport detection strategy (e.g., canary HTTP request)? > =20 > The idea with explicit PvD discovery is that it would, as a step, = replace a separate captive portal detection strategy. > =20 > My overall concern with discovery mechanisms that are specific to only = captive portals is that this is an extra step that is performed = potentially on every network association, that may have limited = extensibility for non-captive use cases. Since the explicit PvD design = promises a way to discover many properties beyond captivity, and is = bootstrapped very early on in the network association, it should = hopefully allow clients to avoid the extra probe. >=20 >=20 > =20 > =20 > =20 > Note: the same =E2=80=9CcaptivePortal=E2=80=9D key is also defined in = section 5.3 as a Boolean. Should I consider this to be a defect in the = draft, or am I missing something? > =20 > The updated version of the draft = (https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-01= = ) leaves out the specific keys for captive portals, and discusses it = more abstractly. That would be a good thing to nail down at the Prague = meeting. If PvD detection is done generically on network association, = then a boolean or some way to indicate that this is *not* a captive = portal will allow the device to not perform extra probing. If there is a = captive network, we should be able to get the page or instructions on = how to get beyond captivity. > =20 > Thanks, > Tommy >=20 >=20 > =20 > -Dave > =20 > =20 > =20 > From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com = ]=20 > Sent: Sunday, June 25, 2017 8:27 PM > To: Dave Dolson; captive-portals@ietf.org = > Cc: David Bird > Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive = Portal" > =20 > At least Erik Kline and myself are following the captive-portal list = :-) > =20 > And the more we think about it, PvD could really be useful and we, the = PvD I-D authors, would be pleased to present at your WG > =20 > -=C3=A9ric > =20 > From: Captive-portals > on behalf of Dave Dolson = > > Date: Friday 23 June 2017 at 11:57 > To: "captive-portals@ietf.org " = > > Cc: David Bird > > Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive = Portal" > =20 > [resend with fewer recipients to avoid mailing list problems] > =20 > To echo David=E2=80=99s request, > > If the authors of the PvD concept (re-)present their I-D to the = mailing list, and stick around for discussion, that would be helpful. > =20 > =20 > From: David Bird [mailto:dbird@google.com ]=20= > Sent: Wednesday, June 14, 2017 9:36 AM > To: Erik Kline > Cc: Gunther Nitzsche; Mark Townsley; Heiko Folkerts; Martin Thomson; = captive-portals@ietf.org ; Livingood, = Jason; Herzig, Willi; Warren Kumari; Dave Dolson > Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive = Portal" > =20 > On Sun, Jun 11, 2017 at 11:17 PM, Erik Kline > wrote: > I'm not sure we have enough input on whether 511 is useful or not. = There seemed to be some suggestion it would help, and some that it = wouldn't. Perhaps one question we could ask is whether it's harmful? = And if we agree it's not harmful, is it worth developing some = recommendations for its use? > =20 > =20 > In of itself, I don't believe it is harmful. However, if vendors use = it as a reason to continue to terminate TLS connection in order to = deliver the 511, then perhaps it is a bit harmful - or at least = misleading. As the world moves to TLS (and QUIC), I think the time for = the 511 code has already passed, to some degree. That, combined with the = fact you may still have browsers not handling that return code properly, = I don't see the value for any vendor or venue to implement this. > =20 > =20 > As for the ICMP unreachable option, I certainly don't think it would = be harmful (with the extra URL bits removed for now). Is that something = we wish to progress? > =20 > =20 > I will work on a new draft that is only the basics. The additional = fields could always be add in their own draft as extensions.=20 > =20 > =20 > Given that we're probably looking at a portal detection method based = on entirely new work, it seems to me we're free to look at new things = like utilizing the PVD detection scheme (DNS queries for "provisioning = domain names", followed by other interaction still TBD). Have the = portal implementors reviewed this and given consideration as to whether = its useful? (I think of the discovery of the portal and subsequent = interaction with it as 2 separate processes conducted, obviously, in = serial.) > =20 > =20 > I believe there are several talking points here, as the PvD method = seems to have several possible implementations.=20 > =20 > I think requiring Ipv6 to configure Ipv4 is weird (I believe that was = one proposed method to convey configuration) > =20 > Several points I made in the thread "Arguments against any Capport = API" regarding a web service - detached from the NAS - controlling the = UE/station I think are relevant. > =20 > If the authors of the PvD concept (re-)present their I-D to the = mailing list, and stick around for discussion, that would be helpful.=20 > =20 > =20 > Thoughts? >=20 > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals = > =20 > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals = > =20 > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals = --Boundary_(ID_PNKqFKT2gSv4mN4sBuaSxw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = Dave,

On Jul 10, 2017, at 8:54 AM, Dave Dolson = <ddolson@sandvine.com> wrote:

At = the last meeting, I think we heard, =E2=80=9CPvDs can help solve this = problem.=E2=80=9D
(This seems to me to be true.)
Are the PvD authors = backing away from this = assertion?

No, we=E2=80=99re definitely still saying that = PvDs can help solve the Captive Portal problem. The details of the JSON = aren=E2=80=99t in latest revision of the main PvD document just to focus = the scope of the draft, but the idea would be that the PvD provisioning = information would be how you bootstrap captive portal = discovery.

 
I think there are two = aspects:
1.       The PvD data structures on the end-user = device, which track captivity state per PvD. (RFC 7556 discusses = connectivity tests per = PvD.)
2.       Whether the PvD protocol explicitly = conveys the captive-portal concept.
 
If = I understand correctly, (1) could be achieved even if capport = information is conveyed in DHCP or RAs (vs. in the PvD protocol).
However, that points to = yet another API to query.

You=E2=80=99re correct. A client device can keep track = of PvD information and already should associate = captivity when discovered with the implicit PvD. Part (2) is saying that = if we are doing external PvD discovery anyway, it should include = captivity information. This is how we avoid the extra API to call.
 
I think that = draft-bruneau-intarea-provisioning-domains has addressed a problem more = generic than the CAPPORT API problem.
And therefore I=E2=80=99m= feeling it is still worth = pursuing.

Right, the draft is more generic than the captive = portal right now. I could imagine that we make sure that the CAPPORT = solution references and works well with PvDs.

Thanks,
Tommy
 
 
I think Tommy makes a = great point that there is value in explicitly indicating, =E2=80=9Cthis = is not a captive portal=E2=80=9D. This ought to speed up network = association.
 
 
-Dave
 
 
 
From: tpauly@apple.com [mailto:tpauly@apple.com] 
Sent: Saturday, July 8, 2017 9:15 = PM
To: Dave Dolson
Cc: Eric = Vyncke (evyncke); captive-portals@ietf.org; = David Bird
Subject: Re: [Captive-portals] Use = Case: "Carrier Grade Captive Portal"
 
 


On Jun 27, 2017, at = 12:46 PM, Dave Dolson <ddolson@sandvine.com> wrote:
 
Eric,
Do I understand correctly from https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-= domains-00#section-5.5
that the intention is for the JSON key =E2=80=9CcaptivePortal=E2= =80=9D to indicate that the specified URL is to be visited by the = browser to navigate the requirements for exiting captivity?
 
If so, would you say = this URL should be used in place of performing a capport detection = strategy (e.g., canary HTTP request)?
 
The idea with explicit PvD discovery is = that it would, as a step, replace a separate captive portal detection = strategy.
 
My overall concern with discovery = mechanisms that are specific to only captive portals is that this is an = extra step that is performed potentially on every network association, = that may have limited extensibility for non-captive use cases. Since the = explicit PvD design promises a way to discover many properties beyond = captivity, and is bootstrapped very early on in the network association, = it should hopefully allow clients to avoid the extra probe.


 
 
 
Note: the same = =E2=80=9CcaptivePortal=E2=80=9D key is also defined in section 5.3 as a = Boolean. Should I consider this to be a defect in the draft, or am I = missing something?
 
The updated version of the draft (https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-= domains-01) leaves out the specific keys for captive portals, and = discusses it more abstractly. That would be a good thing to nail down at = the Prague meeting. If PvD detection is done generically on network = association, then a boolean or some way to indicate that this is *not* a = captive portal will allow the device to not perform extra probing. If = there is a captive network, we should be able to get the page or = instructions on how to get beyond captivity.
 
Thanks,
Tommy


 
-Dave
 
 
 
From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com] 
Sent: Sunday, June 25, 2017 8:27 = PM
To: Dave Dolson; captive-portals@ietf.org
Cc: David Bird
Subject: Re: [Captive-portals] Use = Case: "Carrier Grade Captive Portal"
 
At least Erik Kline and myself are following the = captive-portal list :-)
 
And the more we = think about it, PvD could really be useful and we, the PvD I-D authors, = would be pleased to present at your WG
 
-=C3=A9ric
 
From: Captive-portals = <captive-portals-bounces@ietf.org> on behalf of Dave = Dolson <ddolson@sandvine.com>
Date: Friday 23 June 2017 at = 11:57
To: "captive-portals@ietf.org" = <captive-portals@ietf.org>
Cc: David= Bird <dbird@google.com>
Subject: Re: [Captive-portals] = Use Case: "Carrier Grade Captive Portal"
 
[resend with fewer = recipients to avoid mailing list problems]
 
To echo David=E2=80=99s = request,
> If the authors of = the PvD concept (re-)present their I-D to the mailing list, and stick = around for discussion, that would be helpful.
 
 
From: David Bird [mailto:dbird@google.com] 
Sent: Wednesday, June 14, 2017 = 9:36 AM
To: Erik Kline
Cc: Gunther Nitzsche; Mark = Townsley; Heiko Folkerts; Martin Thomson; captive-portals@ietf.org; = Livingood, Jason; Herzig, Willi; Warren Kumari; Dave Dolson
Subject: Re: [Captive-portals] Use = Case: "Carrier Grade Captive Portal"
 
On Sun, Jun 11, 2017 at 11:17 PM, = Erik Kline <ek@google.com> = wrote:
I'm not sure we have enough input on whether 511 is useful or = not.  There seemed to be some suggestion it would help, and some = that it wouldn't.  Perhaps one question we could ask is whether = it's harmful?  And if we agree it's not harmful, is it worth = developing some recommendations for its use?
 
 
In of itself, I don't believe it is = harmful. However, if vendors use it as a reason to continue to terminate = TLS connection in order to deliver the 511, then perhaps it is a bit = harmful - or at least misleading. As the world moves to TLS (and QUIC), = I think the time for the 511 code has already passed, to some degree. = That, combined with the fact you may still have browsers not handling = that return code properly, I don't see the value for any vendor or venue = to implement this.
 
 
As for the ICMP unreachable = option, I certainly don't think it would be harmful (with the extra URL = bits removed for now).  Is that something we wish to progress?
 
 
I= will work on a new draft that is only the basics. The additional fields = could always be add in their own draft as extensions. 
 
 
Given that we're probably looking = at a portal detection method based on entirely new work, it seems to me = we're free to look at new things like utilizing the PVD detection scheme = (DNS queries for "provisioning domain names", followed by other = interaction still TBD).  Have the portal implementors reviewed this = and given consideration as to whether its useful?  (I think of the = discovery of the portal and subsequent interaction with it as 2 separate = processes conducted, obviously, in serial.)
 
 
I= believe there are several talking points here, as the PvD method seems = to have several possible implementations. 
 
I think requiring Ipv6 to configure = Ipv4 is weird (I believe that was one proposed method to convey = configuration)
 
Several points I made in the thread = "Arguments against any Capport API" regarding a web service - detached = from the NAS - controlling the UE/station I think are relevant.
 
If the authors of the PvD concept = (re-)present their I-D to the mailing list, and stick around for = discussion, that would be helpful. 
 
 
Thoughts?


_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
 
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals=
= --Boundary_(ID_PNKqFKT2gSv4mN4sBuaSxw)-- From nobody Mon Jul 10 20:26:07 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DBB12EC13 for ; Mon, 10 Jul 2017 20:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 jjKcnq0TIF1p for ; Mon, 10 Jul 2017 20:26:02 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 D2B36129B29 for ; Mon, 10 Jul 2017 20:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1499743562; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qQdT8HJTMPffX2h+NnUcfp9scIyihdKpH6ZlLFs0sPE=; b=OIEC/LFFjDN5RFwpSzrved1epZ6Awx8QW9aVQ4ThnSMUakkyH/p4Rm9n1EsYxjU9 2JlR0I8Unbs8D2YnQCUBJnwTWISSoEfQjI9ro/OwjbYl+n0/M+RWB11Lg5s8x0o0 DOH/i146OqRLLaGtiV8Gd4aGAQ36sX/KdpFFQx46/KWAwEvrSzodL9tESmXv5Kax qaVRXvOlGwk010R5J6fBNovwUu5jQ3PNZROkK2jtp8RbASJ8sTKj9M885L9EtmNT qWdMeIStX0vtQRwWV3Eu+VWMz8pcOXXZz6pNRYH7UUay6F8F0jKYXHCSim4G9GmY LrIgT57hg+GePOa4jRw4xg==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 88.E9.07214.A4544695; Mon, 10 Jul 2017 20:26:02 -0700 (PDT) X-AuditID: 11973e11-30dff70000001c2e-85-5964454a5f5e Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay7.apple.com (Apple SCV relay) with SMTP id 33.A1.07283.A4544695; Mon, 10 Jul 2017 20:26:02 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_fMBk8mYj/Z+rx/9c2fh94w)" Received: from [17.234.24.3] (unknown [17.234.24.3]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSW00DVNPJDOX80@nwk-mmpp-sz09.apple.com>; Mon, 10 Jul 2017 20:26:02 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Mon, 10 Jul 2017 20:26:01 -0700 In-reply-to: Cc: David Bird , "Eric Vyncke (evyncke)" , "captive-portals@ietf.org" To: Dave Dolson References: <201705031442.50683.heiko.folkerts@bsi.bund.de> <1BB90528-B35F-43F0-AF18-0215DC735FF0@cable.comcast.com> <754719c5-c74c-fbdc-405e-b8c91478c0a5@netcologne.de> X-Mailer: Apple Mail (2.3439) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUi2FCYquvlmhJpcLFR0WLurAZWi08/tjNa bF32kN3iy/4FjA4sHlN+b2T1WLCp1GPJkp9MHl83b2cNYInisklJzcksSy3St0vgyvh44Q5b wY21zBXzJu1kamDs+cbUxcjJISFgInH08C3WLkYuDiGBNUwSizrfMsIkVvXfY4ZIHGSUmNhy ixkkwSsgKPFj8j0WEJtZIEzi14s9UN3dTBJTHkxh72Lk4BAWkJDYvCcRpIZNQEXi+LcNUL02 ErPnzAKzhQXcJY69eAO2jEVAVeLN3B6wmZwCARKP13WzgcxkFmhnlHhy6SVYg4iAmsTSG5+g lp1kl2iZs5gJZJmEgKzE0j8hIHEJgWXsEpu+zmOewCg0C8mxs5AcOwuohVlAXWLKlFyIsLbE k3cXWCFsNYmFvxcxIYsvYGRbxSiUm5iZo5uZZ6SXWFCQk6qXnJ+7iREUN9PtBHcwHl9ldYhR gINRiYdXoDc5Uog1say4MvcQozQHi5I4704FoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG RVPmMlYyVYpa5d7mUt1hJ/VBZs8yzrrpfBt2MinPnOy0oWJLkPPGsvDgrttPnyvfPm51bJt8 3OeD2aonJXdlpKo+/37+gjtbYtEv+xlHPpws8EtrU//XE1f5YdEL7WOak061m547yfXCcr2q o6j5nu3L5+4xDtpq8fnrzKAn3xi8JiummkQHKbEUZyQaajEXFScCAL/qgfF8AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsUi2FAcoOvlmhJp8GyFhMXcWQ2sFp9+bGe0 2LrsIbvFl/0LGB1YPKb83sjqsWBTqceSJT+ZPL5u3s4awBJlbZOWX1SeWJSiUJRcUGKrVJyR mJJfHm9pbGTqkFhQkJOql5yfq6RvZ5OSmpNZllqEzEqwzvh44Q5bwY21zBXzJu1kamDs+cbU xcjJISFgIrGq/x5zFyMXh5DAQUaJiS23mEESvAKCEj8m32MBsZkFwiR+vdjDClHUzSQx5cEU 9i5GDg5hAQmJzXsSQWrYBFQkjn/bANVrIzF7ziwwW1jAXeLYizeMIDaLgKrEm7k9YDM5BQIk Hq/rZgOZySzQzijx5NJLsAYRATWJpTc+QS07yS7RMmcxE8gyCQFZiaV/QiYw8s9Cct8sJPfN AqpiFlCXmDIlFyKsLfHk3QVWCFtNYuHvRUzI4gsY2VYxChSl5iRWmuvBQ3ATIziSClN3MDYu tzrEKMDBqMTDK9CbHCnEmlhWXJl7iFGCg1lJhDdHPCVSiDclsbIqtSg/vqg0J7X4EON+RqAv JzJLiSbnA+M8ryTe0NjC2NLEwsDAxNLMhLCwiYmBibGxmbGxuYk5LYWVxHlN+GIjhQTSE0tS s1NTC1KLYF5g4uCUamAskpYTuttwolJTcUnnusYHH3j0D60sXH5d/ury2irWR7JHWX9wq26W Md93YOOZtPn9Xl8evpZvZ+KeOnmD7I1ArmwN41cf+IM2pJzIco/RrnjCVlZYfmFHaqbu+YJp 01pe7JyVUtzyaQmLzJLPlbxyt3L9JF+8knp5fv3qGNfWhWtT8jcyTnuoxAJM34ZazEXFiQDA YHJgRQMAAA== Archived-At: Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal" X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 03:26:05 -0000 --Boundary_(ID_fMBk8mYj/Z+rx/9c2fh94w) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable To chime in on the problem of misconfigured networks, I can picture = three variations of issues: 1. If the PvD captivity information is unavailable due to = misconfiguration, I would argue that an implementation MUST fall back to = any legacy mechanisms like today=E2=80=99s HTTP probes. This means that = on misconfigured networks that advertised a PvD server, we would have a = delay after failing to fetch the information. 2. If the PvD information is wrong and lies saying that there is no = captivity, when in fact there is, that could be detected by clients by = the redirects that happen with future connections. This is essentially = the situation we=E2=80=99re in today in which a captive network = whitelists hosts such as captive.apple.com , = and the user is forced to manually browse to a site and get redirected. = This case is unfortunate, and exists today (and likely with any = solution). 3. If the PvD information is wrong and lies that that there is captivity = when there isn=E2=80=99t any, I would assume that the portal site would = fail to connect or load, and would be ignored or dismissed by the = system. The system could also run explicit probes in this case. Between all three of these, there shouldn=E2=80=99t be any fundamental = reason a device that is PvD-aware would fail to join a network that a = legacy device was able to join. These cases may still involve probing, = or waiting for connections to fail, but if we can hope that = misconfiguration is not the norm (which must always be our hope), then = we=E2=80=99re still benefiting most cases. As for cases in which you join a network and then captivity starts = partway through after expiration, I think the PvD solution is very = elegant: we would still do explicit PvD discovery, and be altered that = there is an expiration time on the access from the moment the network is = joined. Also, the configuration that=E2=80=99s accessed for the PvD captivity = doesn=E2=80=99t need to be public=E2=80=94the information can be = specific to a local network, and only needs to tell as much information = as the network is willing to share for the device=E2=80=99s benefit. Thanks, Tommy > On Jul 10, 2017, at 8:54 AM, Dave Dolson wrote: >=20 > David, > Is it fair to say your concerns are mainly about misconfigured = networks? > And this is the reason that devices will always be incented to probe = regardless of any method of provisioning? > =20 > -Dave > =20 > =20 > From: David Bird [mailto:dbird@google.com ]=20= > Sent: Monday, July 10, 2017 9:39 AM > To: Tommy Pauly > Cc: Dave Dolson; Eric Vyncke (evyncke); captive-portals@ietf.org = > Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive = Portal" > =20 > On Sat, Jul 8, 2017 at 6:14 PM, Tommy Pauly > wrote: > [snip]=20 > The idea with explicit PvD discovery is that it would, as a step, = replace a separate captive portal detection strategy. > =20 > My overall concern with discovery mechanisms that are specific to only = captive portals is that this is an extra step that is performed = potentially on every network association, that may have limited = extensibility for non-captive use cases. Since the explicit PvD design = promises a way to discover many properties beyond captivity, and is = bootstrapped very early on in the network association, it should = hopefully allow clients to avoid the extra probe. >=20 >=20 > =20 > I have concerns with the PvD approach, as described. > =20 > If a network was misconfigured to advertise a PvD that does have a = (Internet based) HTTPS server with a JSON file on it describing a = captive portal network, then devices utilizing the PvD information will = *never* get on this network while devices not using the PvD information = do. That could be very confusing to users and network administrators = alike.=20 > =20 > If you have seen walled garden configurations for large networks, you = will notice a lot about the network operator's marketing partners. = Indeed, many walled gardens are much larger than the network really = wants... sometimes they just need to make things work in the garden. My = point here is that operators may not *want* to list out their walled = garden configuration on a public JSON file... > =20 > At the end of the day, I'd argue that the client *will always probe* = -- wether it means to or not... A networking using PvD could just = advertise all networks routes are available so that the device connects = only to get caught up in a captive portal redirect anyway... back to = step 1 and captive portal detection.. > =20 > I'm also unclear how PvD would deal with scenarios where you might = start out with internet connectivity (e.g. "MAC Authentication") then to = have a captive portal return after a session timeout has occurred... > =20 > =20 > =20 > =20 > =20 > Note: the same =E2=80=9CcaptivePortal=E2=80=9D key is also defined in = section 5.3 as a Boolean. Should I consider this to be a defect in the = draft, or am I missing something? > =20 > The updated version of the draft = (https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-01= = ) leaves out the specific keys for captive portals, and discusses it = more abstractly. That would be a good thing to nail down at the Prague = meeting. If PvD detection is done generically on network association, = then a boolean or some way to indicate that this is *not* a captive = portal will allow the device to not perform extra probing. If there is a = captive network, we should be able to get the page or instructions on = how to get beyond captivity. > =20 > Thanks, > Tommy >=20 >=20 >=20 > =20 > -Dave > =20 > =20 > =20 > From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com = ]=20 > Sent: Sunday, June 25, 2017 8:27 PM > To: Dave Dolson; captive-portals@ietf.org = > Cc: David Bird > Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive = Portal" > =20 > At least Erik Kline and myself are following the captive-portal list = :-) > =20 > And the more we think about it, PvD could really be useful and we, the = PvD I-D authors, would be pleased to present at your WG > =20 > -=C3=A9ric > =20 > From: Captive-portals > on behalf of Dave Dolson = > > Date: Friday 23 June 2017 at 11:57 > To: "captive-portals@ietf.org " = > > Cc: David Bird > > Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive = Portal" > =20 > [resend with fewer recipients to avoid mailing list problems] > =20 > To echo David=E2=80=99s request, > > If the authors of the PvD concept (re-)present their I-D to the = mailing list, and stick around for discussion, that would be helpful. > =20 > =20 > From: David Bird [mailto:dbird@google.com ]=20= > Sent: Wednesday, June 14, 2017 9:36 AM > To: Erik Kline > Cc: Gunther Nitzsche; Mark Townsley; Heiko Folkerts; Martin Thomson; = captive-portals@ietf.org ; Livingood, = Jason; Herzig, Willi; Warren Kumari; Dave Dolson > Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive = Portal" > =20 > On Sun, Jun 11, 2017 at 11:17 PM, Erik Kline > wrote: > I'm not sure we have enough input on whether 511 is useful or not. = There seemed to be some suggestion it would help, and some that it = wouldn't. Perhaps one question we could ask is whether it's harmful? = And if we agree it's not harmful, is it worth developing some = recommendations for its use? > =20 > =20 > In of itself, I don't believe it is harmful. However, if vendors use = it as a reason to continue to terminate TLS connection in order to = deliver the 511, then perhaps it is a bit harmful - or at least = misleading. As the world moves to TLS (and QUIC), I think the time for = the 511 code has already passed, to some degree. That, combined with the = fact you may still have browsers not handling that return code properly, = I don't see the value for any vendor or venue to implement this. > =20 > =20 > As for the ICMP unreachable option, I certainly don't think it would = be harmful (with the extra URL bits removed for now). Is that something = we wish to progress? > =20 > =20 > I will work on a new draft that is only the basics. The additional = fields could always be add in their own draft as extensions.=20 > =20 > =20 > Given that we're probably looking at a portal detection method based = on entirely new work, it seems to me we're free to look at new things = like utilizing the PVD detection scheme (DNS queries for "provisioning = domain names", followed by other interaction still TBD). Have the = portal implementors reviewed this and given consideration as to whether = its useful? (I think of the discovery of the portal and subsequent = interaction with it as 2 separate processes conducted, obviously, in = serial.) > =20 > =20 > I believe there are several talking points here, as the PvD method = seems to have several possible implementations.=20 > =20 > I think requiring Ipv6 to configure Ipv4 is weird (I believe that was = one proposed method to convey configuration) > =20 > Several points I made in the thread "Arguments against any Capport = API" regarding a web service - detached from the NAS - controlling the = UE/station I think are relevant. > =20 > If the authors of the PvD concept (re-)present their I-D to the = mailing list, and stick around for discussion, that would be helpful.=20 > =20 > =20 > Thoughts? >=20 > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals = > =20 > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals = > =20 > =20 > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals = --Boundary_(ID_fMBk8mYj/Z+rx/9c2fh94w) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable To = chime in on the problem of misconfigured networks, I can picture three = variations of issues:

1. If the PvD captivity information is unavailable due to = misconfiguration, I would argue that an implementation MUST fall back to = any legacy mechanisms like today=E2=80=99s HTTP probes. This means that = on misconfigured networks that advertised a PvD server, we would have a = delay after failing to fetch the information.
2. If = the PvD information is wrong and lies saying that there is no captivity, = when in fact there is, that could be detected by clients by the = redirects that happen with future connections. This is essentially the = situation we=E2=80=99re in today in which a captive network whitelists = hosts such as captive.apple.com, and the user is forced to manually = browse to a site and get redirected. This case is unfortunate, and = exists today (and likely with any solution).
3. If = the PvD information is wrong and lies that that there is captivity when = there isn=E2=80=99t any, I would assume that the portal site would fail = to connect or load, and would be ignored or dismissed by the system. The = system could also run explicit probes in this case.

Between all three of = these, there shouldn=E2=80=99t be any fundamental reason a device that = is PvD-aware would fail to join a network that a legacy device was able = to join. These cases may still involve probing, or waiting for = connections to fail, but if we can hope that misconfiguration is not the = norm (which must always be our hope), then we=E2=80=99re still = benefiting most cases.

As for cases in which you join a network and then captivity = starts partway through after expiration, I think the PvD solution is = very elegant: we would still do explicit PvD discovery, and be altered = that there is an expiration time on the access from the moment the = network is joined.

Also, the configuration that=E2=80=99s accessed for the PvD = captivity doesn=E2=80=99t need to be public=E2=80=94the information can = be specific to a local network, and only needs to tell as much = information as the network is willing to share for the device=E2=80=99s = benefit.

Thanks,
Tommy

On Jul = 10, 2017, at 8:54 AM, Dave Dolson <ddolson@sandvine.com> wrote:

David,
Is = it fair to say your concerns are mainly about misconfigured = networks?
And this is the reason = that devices will always be incented to probe regardless of any method = of provisioning?
 
-Dave
 
 
From: David Bird = [mailto:dbird@google.com] 
Sent: Monday, July 10, 2017 9:39 = AM
To: Tommy Pauly
Cc: Dave = Dolson; Eric Vyncke (evyncke); captive-portals@ietf.org
Subject: Re: [Captive-portals] Use = Case: "Carrier Grade Captive Portal"
 
On Sat, Jul 8, 2017 at 6:14 PM, Tommy Pauly <tpauly@apple.com> = wrote:
[snip] 
The idea = with explicit PvD discovery is that it would, as a step, replace a = separate captive portal detection strategy.
 
My overall = concern with discovery mechanisms that are specific to only captive = portals is that this is an extra step that is performed potentially on = every network association, that may have limited extensibility for = non-captive use cases. Since the explicit PvD design promises a way to = discover many properties beyond captivity, and is bootstrapped very = early on in the network association, it should hopefully allow clients = to avoid the extra probe.


 
I have concerns with the PvD approach, = as described.
 
If a network was misconfigured to = advertise a PvD that does have a (Internet based) HTTPS server with a = JSON file on it describing a captive portal network, then devices = utilizing the PvD information will *never* get on this network while = devices not using the PvD information do. That could be very confusing = to users and network administrators alike. 
 
If you have = seen walled garden configurations for large networks, you will notice a = lot about the network operator's marketing partners. Indeed, many walled = gardens are much larger than the network really wants... sometimes they = just need to make things work in the garden. My point here is that = operators may not *want* to list out their walled garden configuration = on a public JSON file...
 
At the end of the day, I'd argue that = the client *will always probe* -- wether it means to or not... A = networking using PvD could just advertise all networks routes are = available so that the device connects only to get caught up in a captive = portal redirect anyway... back to step 1 and captive portal = detection..
 
I'm also unclear how PvD would deal with = scenarios where you might start out with internet connectivity (e.g. = "MAC Authentication") then to have a captive portal return after a = session timeout has occurred...
 
 
 
 
 
Note: the same = =E2=80=9CcaptivePortal=E2=80=9D key is also defined in section 5.3 as a = Boolean. Should I consider this to be a defect in the draft, or am I = missing something?
 
The updated version of the draft (https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-= domains-01) leaves out the specific keys for captive portals, and = discusses it more abstractly. That would be a good thing to nail down at = the Prague meeting. If PvD detection is done generically on network = association, then a boolean or some way to indicate that this is *not* a = captive portal will allow the device to not perform extra probing. If = there is a captive network, we should be able to get the page or = instructions on how to get beyond captivity.
 
Thanks,
Tommy



 
-Dave
 
 
 
From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com] 
Sent: Sunday, = June 25, 2017 8:27 PM
To: Dave = Dolson; captive-portals@ietf.org
Cc: David = Bird
Subject: Re: = [Captive-portals] Use Case: "Carrier Grade Captive Portal"
 
At least Erik Kline and myself are following the = captive-portal list :-)
 
And the more we = think about it, PvD could really be useful and we, the PvD I-D authors, = would be pleased to present at your WG
 
-=C3=A9ric
 
From: <= /b>Captive-portals <captive-portals-bounces@ietf.org> on behalf of Dave = Dolson <ddolson@sandvine.com>
Date: Frid= ay 23 June 2017 at 11:57
To: "captive-portals@ietf.org" <captive-portals@ietf.org>
Cc: Davi= d Bird <dbird@google.com>
Subject: Re: = [Captive-portals] Use Case: "Carrier Grade Captive Portal"
 
[resend with fewer = recipients to avoid mailing list problems]
 
To echo David=E2=80=99s = request,
> If the authors of = the PvD concept (re-)present their I-D to the mailing list, and stick = around for discussion, that would be helpful.
 
 
From: David Bird [mailto:dbird@google.com] 
Sent: Wednesda= y, June 14, 2017 9:36 AM
To: Erik = Kline
Cc: Gunther = Nitzsche; Mark Townsley; Heiko Folkerts; Martin Thomson; captive-portals@ietf.org; Livingood, Jason; Herzig, = Willi; Warren Kumari; Dave Dolson
Subject: Re: = [Captive-portals] Use Case: "Carrier Grade Captive Portal"
 
On Sun, Jun 11, 2017 at 11:17 PM, = Erik Kline <ek@google.com> = wrote:
I'm not sure we have enough input on whether 511 is useful or = not.  There seemed to be some suggestion it would help, and some = that it wouldn't.  Perhaps one question we could ask is whether = it's harmful?  And if we agree it's not harmful, is it worth = developing some recommendations for its use?
 
 
In of itself, I don't believe it is = harmful. However, if vendors use it as a reason to continue to terminate = TLS connection in order to deliver the 511, then perhaps it is a bit = harmful - or at least misleading. As the world moves to TLS (and QUIC), = I think the time for the 511 code has already passed, to some degree. = That, combined with the fact you may still have browsers not handling = that return code properly, I don't see the value for any vendor or venue = to implement this.
 
 
As for the ICMP unreachable = option, I certainly don't think it would be harmful (with the extra URL = bits removed for now).  Is that something we wish to progress?
 
 
I= will work on a new draft that is only the basics. The additional fields = could always be add in their own draft as extensions. 
 
 
Given that we're probably looking = at a portal detection method based on entirely new work, it seems to me = we're free to look at new things like utilizing the PVD detection scheme = (DNS queries for "provisioning domain names", followed by other = interaction still TBD).  Have the portal implementors reviewed this = and given consideration as to whether its useful?  (I think of the = discovery of the portal and subsequent interaction with it as 2 separate = processes conducted, obviously, in serial.)
 
 
I= believe there are several talking points here, as the PvD method seems = to have several possible implementations. 
 
I think requiring Ipv6 to configure = Ipv4 is weird (I believe that was one proposed method to convey = configuration)
 
Several points I made in the thread = "Arguments against any Capport API" regarding a web service - detached = from the NAS - controlling the UE/station I think are relevant.
 
If the authors of the PvD concept = (re-)present their I-D to the mailing list, and stick around for = discussion, that would be helpful. 
 
 
Thoughts?


_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
 
 
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals=
= --Boundary_(ID_fMBk8mYj/Z+rx/9c2fh94w)-- From nobody Tue Jul 11 07:18:50 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D1D1316EC for ; Tue, 11 Jul 2017 07:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMKSZ1oO96lP for ; Tue, 11 Jul 2017 07:18:44 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7694E1316ED for ; Tue, 11 Jul 2017 07:18:43 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id m84so21927790ita.0 for ; Tue, 11 Jul 2017 07:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8X5qJoTbCfg9VzzeyzyhQx98OUx4a41LqZe0yIFo1II=; b=nVs1FVoppTjp7+abQgkic4kkS8leWegxeztxiFyBh8Ly+De2IcG/OlGbyjPy0Nf7xp Y/iwL01qZEfXEgiJDtvj8jFSAsWr0nOl5nayQF23ZY7oP7SykWv+qYQnSgajZQuRcNq5 0UQF0gkXALWWVpPO/Sa5EaW7xEe1QZC6s0x/Yp7DtXwdclfgIyU2AeYFkaYy0oNtiQ2T K01ilV7e0BCK+cfM/cYvUFB1dIi6bN82V2jwTOPe1i9SW7OduMvjdN9cXUZg6keEF4AI 1QiyFfEsZ+OuxEsYN1r4XImYB199hNh9Ia0V0zbargXaVUv2D0B+NCI3mkGbSmD6UiB7 bpJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8X5qJoTbCfg9VzzeyzyhQx98OUx4a41LqZe0yIFo1II=; b=CHlHcPjJGtKBrYc0tOlbma72ydmZUmUvLvaGIIM3RAijKMma3pcOsFNVxASW6rke/G MJ07lxsoJCkMxUJ6B8m9ex1af+gbsv4kV2UkQIsdFapcfND7h+sb0vvNagFW44+SVJbs M29Kw+ivSv9M07jv4Jed4+fPuoCpoLbxqm37SYzTXX3q3R8JHFJSGZ7/Ygrr1JFiqQet 1HZHRx2cpB9TR8bGWfQac+XaO+wfLbfkvVQ7/9ojal9olukaQhdFGkU39dDEbim+ILG8 hzEVE6wlHDT9B5AuRAC1JPIBFC6nM0VUoSzJ8RClwWkmEO/TcoqHyq4BFjr+Ln98SvA8 aT6A== X-Gm-Message-State: AIVw1131GAYu4IQQvtD49wPcE6UzQ7UwQGeZU6N4O3oD5E3JTxe7/NeT wixqhc03KwV1P38ICLAMCkIcN07DjO4u X-Received: by 10.36.120.67 with SMTP id p64mr3417449itc.23.1499782722143; Tue, 11 Jul 2017 07:18:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.6.140 with HTTP; Tue, 11 Jul 2017 07:18:40 -0700 (PDT) In-Reply-To: References: <201705031442.50683.heiko.folkerts@bsi.bund.de> <1BB90528-B35F-43F0-AF18-0215DC735FF0@cable.comcast.com> <754719c5-c74c-fbdc-405e-b8c91478c0a5@netcologne.de> From: David Bird Date: Tue, 11 Jul 2017 07:18:40 -0700 Message-ID: To: Tommy Pauly Cc: Dave Dolson , "Eric Vyncke (evyncke)" , "captive-portals@ietf.org" Content-Type: multipart/alternative; boundary="001a114a9ebe665ab205540b607e" Archived-At: Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal" X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 14:18:48 -0000 --001a114a9ebe665ab205540b607e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the explanation... Concerning the variations, 1. Agreed 2. Indeed, this is the situation we are in today when networks take measures to avoid captive portal detection. PvD just made that easier for them to do. Also, it has been argued that in Android the "captive portal check" is really a surrogate for "connectivity check".... So, would client really *not* to any probing when told there is no portal? 3. It is a big assumption to think portals will not load when redirected to by unknown networks... assuming it does load, and seemingly "works", the PvD device will be captive when non-PvD devices notice *nothing* (no portal or problems accessing). I will add another, 4. The network has a captive portal, but it is broken (for whatever reason, RADIUS server is down, for example). In this case the PvD device discovered the portal, the user interacted with the portal, the user should be on-line, but isn't. What happens here? The 'problem' could have been temporary, so ideally we want the user to return to the portal... my guess is that the client is still probing like today in *all* cases... I will reiterate a concern I have generally with PvD controlling the device from a web service which may or may not be within the NAS itself (probably not, in fact, since that would require many TLS certificates). Which is, there will be many 'broken' networks. PvD is saying one thing, but the NAS thinks differently (maybe because it received a RADIUS CoA, or a local NAS timeout or issue, or any number of implementation 'glitches'). On Mon, Jul 10, 2017 at 8:26 PM, Tommy Pauly wrote: > To chime in on the problem of misconfigured networks, I can picture three > variations of issues: > > 1. If the PvD captivity information is unavailable due to > misconfiguration, I would argue that an implementation MUST fall back to > any legacy mechanisms like today=E2=80=99s HTTP probes. This means that o= n > misconfigured networks that advertised a PvD server, we would have a dela= y > after failing to fetch the information. > 2. If the PvD information is wrong and lies saying that there is no > captivity, when in fact there is, that could be detected by clients by th= e > redirects that happen with future connections. This is essentially the > situation we=E2=80=99re in today in which a captive network whitelists ho= sts such > as captive.apple.com, and the user is forced to manually browse to a site > and get redirected. This case is unfortunate, and exists today (and likel= y > with any solution). > 3. If the PvD information is wrong and lies that that there is captivity > when there isn=E2=80=99t any, I would assume that the portal site would f= ail to > connect or load, and would be ignored or dismissed by the system. The > system could also run explicit probes in this case. > > Between all three of these, there shouldn=E2=80=99t be any fundamental re= ason a > device that is PvD-aware would fail to join a network that a legacy devic= e > was able to join. These cases may still involve probing, or waiting for > connections to fail, but if we can hope that misconfiguration is not the > norm (which must always be our hope), then we=E2=80=99re still benefiting= most > cases. > > As for cases in which you join a network and then captivity starts partwa= y > through after expiration, I think the PvD solution is very elegant: we > would still do explicit PvD discovery, and be altered that there is an > expiration time on the access from the moment the network is joined. > > Also, the configuration that=E2=80=99s accessed for the PvD captivity doe= sn=E2=80=99t need > to be public=E2=80=94the information can be specific to a local network, = and only > needs to tell as much information as the network is willing to share for > the device=E2=80=99s benefit. > > Thanks, > Tommy > > > On Jul 10, 2017, at 8:54 AM, Dave Dolson wrote: > > David, > Is it fair to say your concerns are mainly about misconfigured networks? > And this is the reason that devices will always be incented to probe > regardless of any method of provisioning? > > -Dave > > > *From:* David Bird [mailto:dbird@google.com ] > *Sent:* Monday, July 10, 2017 9:39 AM > *To:* Tommy Pauly > *Cc:* Dave Dolson; Eric Vyncke (evyncke); captive-portals@ietf.org > *Subject:* Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal" > > On Sat, Jul 8, 2017 at 6:14 PM, Tommy Pauly wrote: > [snip] > > The idea with explicit PvD discovery is that it would, as a step, replace > a separate captive portal detection strategy. > > My overall concern with discovery mechanisms that are specific to only > captive portals is that this is an extra step that is performed potential= ly > on every network association, that may have limited extensibility for > non-captive use cases. Since the explicit PvD design promises a way to > discover many properties beyond captivity, and is bootstrapped very early > on in the network association, it should hopefully allow clients to avoid > the extra probe. > > > > I have concerns with the PvD approach, as described. > > If a network was misconfigured to advertise a PvD that does have a > (Internet based) HTTPS server with a JSON file on it describing a captive > portal network, then devices utilizing the PvD information will *never* g= et > on this network while devices not using the PvD information do. That coul= d > be very confusing to users and network administrators alike. > > If you have seen walled garden configurations for large networks, you wil= l > notice a lot about the network operator's marketing partners. Indeed, man= y > walled gardens are much larger than the network really wants... sometimes > they just need to make things work in the garden. My point here is that > operators may not *want* to list out their walled garden configuration on= a > public JSON file... > > At the end of the day, I'd argue that the client *will always probe* -- > wether it means to or not... A networking using PvD could just advertise > all networks routes are available so that the device connects only to get > caught up in a captive portal redirect anyway... back to step 1 and capti= ve > portal detection.. > > I'm also unclear how PvD would deal with scenarios where you might start > out with internet connectivity (e.g. "MAC Authentication") then to have a > captive portal return after a session timeout has occurred... > > > > > > > Note: the same =E2=80=9CcaptivePortal=E2=80=9D key is also defined in sec= tion 5.3 as a > Boolean. Should I consider this to be a defect in the draft, or am I > missing something? > > > The updated version of the draft (https://tools.ietf.org/html/ > draft-bruneau-intarea-provisioning-domains-01) leaves out the specific > keys for captive portals, and discusses it more abstractly. That would be= a > good thing to nail down at the Prague meeting. If PvD detection is done > generically on network association, then a boolean or some way to indicat= e > that this is *not* a captive portal will allow the device to not perform > extra probing. If there is a captive network, we should be able to get th= e > page or instructions on how to get beyond captivity. > > Thanks, > Tommy > > > > > -Dave > > > > *From:* Eric Vyncke (evyncke) [mailto:evyncke@cisco.com > ] > *Sent:* Sunday, June 25, 2017 8:27 PM > *To:* Dave Dolson; captive-portals@ietf.org > *Cc:* David Bird > *Subject:* Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal" > > At least Erik Kline and myself are following the captive-portal list :-) > > And the more we think about it, PvD could really be useful and we, the Pv= D > I-D authors, would be pleased to present at your WG > > -=C3=A9ric > > > *From: *Captive-portals on behalf of > Dave Dolson > *Date: *Friday 23 June 2017 at 11:57 > *To: *"captive-portals@ietf.org" > *Cc: *David Bird > *Subject: *Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal" > > [resend with fewer recipients to avoid mailing list problems] > > To echo David=E2=80=99s request, > > If the authors of the PvD concept (re-)present their I-D to the mailing > list, and stick around for discussion, that would be helpful. > > > *From:* David Bird [mailto:dbird@google.com ] > *Sent:* Wednesday, June 14, 2017 9:36 AM > *To:* Erik Kline > *Cc:* Gunther Nitzsche; Mark Townsley; Heiko Folkerts; Martin Thomson; > captive-portals@ietf.org; Livingood, Jason; Herzig, Willi; Warren Kumari; > Dave Dolson > *Subject:* Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal" > > On Sun, Jun 11, 2017 at 11:17 PM, Erik Kline wrote: > I'm not sure we have enough input on whether 511 is useful or not. There > seemed to be some suggestion it would help, and some that it wouldn't. > Perhaps one question we could ask is whether it's harmful? And if we agr= ee > it's not harmful, is it worth developing some recommendations for its use= ? > > > In of itself, I don't believe it is harmful. However, if vendors use it a= s > a reason to continue to terminate TLS connection in order to deliver the > 511, then perhaps it is a bit harmful - or at least misleading. As the > world moves to TLS (and QUIC), I think the time for the 511 code has > already passed, to some degree. That, combined with the fact you may stil= l > have browsers not handling that return code properly, I don't see the val= ue > for any vendor or venue to implement this. > > > > As for the ICMP unreachable option, I certainly don't think it would be > harmful (with the extra URL bits removed for now). Is that something we > wish to progress? > > > > I will work on a new draft that is only the basics. The additional fields > could always be add in their own draft as extensions. > > > > Given that we're probably looking at a portal detection method based on > entirely new work, it seems to me we're free to look at new things like > utilizing the PVD detection scheme (DNS queries for "provisioning domain > names", followed by other interaction still TBD). Have the portal > implementors reviewed this and given consideration as to whether its > useful? (I think of the discovery of the portal and subsequent interacti= on > with it as 2 separate processes conducted, obviously, in serial.) > > > > I believe there are several talking points here, as the PvD method seems > to have several possible implementations. > > I think requiring Ipv6 to configure Ipv4 is weird (I believe that was one > proposed method to convey configuration) > > Several points I made in the thread "Arguments against any Capport API" > regarding a web service - detached from the NAS - controlling the > UE/station I think are relevant. > > If the authors of the PvD concept (re-)present their I-D to the mailing > list, and stick around for discussion, that would be helpful. > > > > Thoughts? > > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > > > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > > > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > > > --001a114a9ebe665ab205540b607e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
--001a114a9ebe665ab205540b607e-- From nobody Sun Jul 30 18:00:46 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060D612ECBD for ; Sun, 30 Jul 2017 18:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD01EPagY4OM for ; Sun, 30 Jul 2017 18:00:43 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 84D5C127601 for ; Sun, 30 Jul 2017 18:00:43 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id u207so87053193ywc.3 for ; Sun, 30 Jul 2017 18:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=SITNO8ZM/FOJHBCNVpw7xQiktYlxt4cnUFRg+fehRoc=; b=CC4FqOE5ly7dQDYz/XsVdW9+A7RKY404myxwYMA2EWMbR7/97LFQYZhQmkxqxFCE5D X6YH12s7VosshuN1CdzcXpxU1eS3ztRLj3qM5qcJusVbg2csOzYaDmTvZBtgXrRuYn1Z mVhL0Rm44dWGPwKygu8O58YKOPMCyPQKphwrI4HqG4rWvnKp5tnE3XNLJvnnJQkzqNsS nlVzk6eTh9whYzCnQWOf259F+KkiQTjwt8BW84i/ewm8wBUm8mZoZMW9l5uZl2omw10J MGb3MtuPJpXR0dEp/fHUlimzy5LnK25RDtXg867AqfCJCKfzoArcXVs1ublTkjraYZlF hqQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=SITNO8ZM/FOJHBCNVpw7xQiktYlxt4cnUFRg+fehRoc=; b=HvVunf5AC0r2qZ8rUZWePE0w76p8IzphMQ0aE70HXXETaOikII2RsPk2RUQoGDXUGc oFaLHn+iHC6PAy8GvsF/LFj7i10UfGrgUN4go4AtbEAYpmOUiZhzDuq/2rcF1Bu1ZiaM gkO9puKYcv87uWSsS+/h9OB8rDEN0L0J1KaoP2NmwCYNEHW8D5p4C3f76xyvrPLZgCyf CV5VfWkKjVzohyrmdCcrfXoN44qr2ouIpB4/nWu6uXhWYc+Tpo6coBKUjqApvkYPuVbe dOkK0uVgJXeDyfsYc3AV3uzP44gcdhqGHEDBjTo/Wg0FVmYmv3EcHS9EBrk08i1kwv0Y ZrPQ== X-Gm-Message-State: AIVw1103HCNb62GKxC3s2BIqOt62gX15SqIIWapeBbK6Ba2i1nk3iW3V fmisvum4XV/6mcv0Vhq/K0k6PzdaJGmRV0qtuQ== X-Received: by 10.129.172.21 with SMTP id k21mr4722451ywh.321.1501462842084; Sun, 30 Jul 2017 18:00:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.38.74 with HTTP; Sun, 30 Jul 2017 18:00:21 -0700 (PDT) From: Erik Kline Date: Mon, 31 Jul 2017 10:00:21 +0900 Message-ID: To: captive-portals@ietf.org Cc: "martin.thomson@gmail.com" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f4030436885e5ece3d0555928fb5" Archived-At: Subject: [Captive-portals] IETF 99 minutes X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 01:00:45 -0000 --f4030436885e5ece3d0555928fb5 Content-Type: text/plain; charset="UTF-8" FYI: I have uploaded the meeting minutes as captured in Etherpad. Many thanks to David Dolson (and any others) for taking notes. You can find the minutes on the wg meetings page: https://datatracker.ietf.org/group/capport/meetings/ https://datatracker.ietf.org/meeting/99/minutes/capport and in the wg-materials repo on github: https://github.com/capport-wg/wg-materials I have not edited this initial upload of the minutes in any way. Please review if/when you get a chance; we can post corrections/clarifications. --f4030436885e5ece3d0555928fb5 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgSr4u3zkjW57qpNwdavHFA/ijTAeJGUlm cC9DS9W8Rh0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzMx MDEwMDQyWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBANaCmsIiyUmWImWY0JnFYKaUoNrviyWCKIbdVoVnrwuzfJVkKNTU va5NYu6+pDRC80W3laFKEr4OrODZZJuJ2Hm7PBKR8viOEnPAcH4sSXea8Xl1yyGw49MajRzmgtdh YvAdFvKwodQOomtDipqGAsIVItKo0hJEVewXuLWgKpV/5qwC1F1aLxCeVehEk19YFPkfmmz7v3Qt gzTzGdqRuxexUlYNMYeNL0OM0vmEBj5HpUcW0MB4CZZjKc/oN8v5kn12XU1MG0UAZ6jnisOYGJ1P CEhwqrR1kpwhATHDhjttBMBdDL+K9y84kfX5u7nNUKzgqtYQCAe7nD6z3zd0LXI= --f4030436885e5ece3d0555928fb5--
Than= ks for the explanation...=C2=A0

<= div class=3D"gmail_quote">Concerning the variations,
1. Agreed
2. Indeed, this is the = situation we are in today when networks take measures to avoid captive port= al detection. PvD just made that easier for them to do. Also, it has been a= rgued that in Android the "captive portal check" is really a surr= ogate for "connectivity check".... So, would client really *not* = to any probing when told there is no portal?
3. It is a big assumption to think portals will not load when redirected = to by unknown networks... assuming it does load, and seemingly "works&= quot;, the PvD device will be captive when non-PvD devices notice *nothing*= (no portal or problems accessing).

I will add another,
4. The network has a captive portal, but it is broken (for whatever = reason, RADIUS server is down, for example). In this case the PvD device di= scovered the portal, the user interacted with the portal, the user should b= e on-line, but isn't. What happens here? The 'problem' could ha= ve been temporary, so ideally we want the user to return to the portal... m= y guess is that the client is still probing like today in *all* cases...

I will r= eiterate a concern I have generally with PvD controlling the device from a = web service which may or may not be within the NAS itself (probably not, in= fact, since that would require many TLS certificates). Which is, there wil= l be many 'broken' networks. PvD is saying one thing, but the NAS t= hinks differently (maybe because it received a RADIUS CoA, or a local NAS t= imeout or issue, or any number of implementation 'glitches').=C2=A0=


<= /div>
On Mon, Jul 10, 2017 at 8:26 PM, Tommy Paul= y <tpauly@apple.com> wrote:
To chime in on the = problem of misconfigured networks, I can picture three variations of issues= :

1. If the PvD captivity information is unavailable due= to misconfiguration, I would argue that an implementation MUST fall back t= o any legacy mechanisms like today=E2=80=99s HTTP probes. This means that o= n misconfigured networks that advertised a PvD server, we would have a dela= y after failing to fetch the information.
2. If the PvD informati= on is wrong and lies saying that there is no captivity, when in fact there = is, that could be detected by clients by the redirects that happen with fut= ure connections. This is essentially the situation we=E2=80=99re in today i= n which a captive network whitelists hosts such as captive.apple.com, and the user is force= d to manually browse to a site and get redirected. This case is unfortunate= , and exists today (and likely with any solution).
3. If the PvD = information is wrong and lies that that there is captivity when there isn= =E2=80=99t any, I would assume that the portal site would fail to connect o= r load, and would be ignored or dismissed by the system. The system could a= lso run explicit probes in this case.

Between all = three of these, there shouldn=E2=80=99t be any fundamental reason a device = that is PvD-aware would fail to join a network that a legacy device was abl= e to join. These cases may still involve probing, or waiting for connection= s to fail, but if we can hope that misconfiguration is not the norm (which = must always be our hope), then we=E2=80=99re still benefiting most cases.

As for cases in which you join a network and then c= aptivity starts partway through after expiration, I think the PvD solution = is very elegant: we would still do explicit PvD discovery, and be altered t= hat there is an expiration time on the access from the moment the network i= s joined.

Also, the configuration that=E2=80=99s a= ccessed for the PvD captivity doesn=E2=80=99t need to be public=E2=80=94the= information can be specific to a local network, and only needs to tell as = much information as the network is willing to share for the device=E2=80=99= s benefit.

Thanks,
Tommy


On Jul 10, 2017, = at 8:54 AM, Dave Dolson <ddolson@sandvine.com> wrote:

David,<= /u>
Is it fair to say your con= cerns are mainly about misconfigured networks?
And this is the reason that devices will alw= ays be incented to probe regardless of any method of provisioning?
=C2=A0
-Dave
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times= New Roman",serif">=C2=A0
=C2=A0
From:= =C2=A0= David Bird [mailto:dbird@google.com]=C2=A0
= Sent:=C2=A0Monday, July 10, 2017 9:39 AM
To:=C2=A0Tommy PaulyCc:=C2=A0Dave Dolson; Eric Vyncke (evyncke);=C2=A0captive-portals@ietf.org
Subject:=C2=A0Re: [Ca= ptive-portals] Use Case: "Carrier Grade Captive Portal"=
=C2=A0
On Sat, Jul 8, 2017 at 6:14 PM, Tommy Paul= y <tpauly@apple.com> wrote:=
[snip]=C2=A0
The idea with explicit PvD discovery is that it would, as a step, replace = a separate captive portal detection strategy.
=C2=A0
My overall concern with discovery mechanisms that are specif= ic to only captive portals is that this is an extra step that is performed = potentially on every network association, that may have limited extensibili= ty for non-captive use cases. Since the explicit PvD design promises a way = to discover many properties beyond captivity, and is bootstrapped very earl= y on in the network association, it should hopefully allow clients to avoid= the extra probe.

=C2=A0
I have conce= rns with the PvD approach, as described.
=C2=A0
If a network was misconfigured to advertise a PvD that does have a = (Internet based) HTTPS server with a JSON file on it describing a captive p= ortal network, then devices utilizing the PvD information will *never* get = on this network while devices not using the PvD information do. That could = be very confusing to users and network administrators alike.=C2=A0
=C2=A0
If you have seen walled garden configurat= ions for large networks, you will notice a lot about the network operator&#= 39;s marketing partners. Indeed, many walled gardens are much larger than t= he network really wants... sometimes they just need to make things work in = the garden. My point here is that operators may not *want* to list out thei= r walled garden configuration on a public JSON file...
<= /div>
=C2=A0
At the end of the day, I'd argue that the client = *will always probe* -- wether it means to or not... A networking using PvD = could just advertise all networks routes are available so that the device c= onnects only to get caught up in a captive portal redirect anyway... back t= o step 1 and captive portal detection..
=C2=A0
I'm also unclear how PvD would deal with scenarios where you mig= ht start out with internet connectivity (e.g. "MAC Authentication"= ;) then to have a captive portal return after a session timeout has occurre= d...
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0=
Note: the same =E2=80=9CcaptivePortal=E2=80=9D key is also defi= ned in section 5.3 as a Boolean. Should I consider this to be a defect in t= he draft, or am I missing something?
=
=C2=A0
=
The updated version of the draft (https:/= /tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-0= 1) leaves out the specific keys for captive portals, and discusses it m= ore abstractly. That would be a good thing to nail down at the Prague meeti= ng. If PvD detection is done generically on network association, then a boo= lean or some way to indicate that this is *not* a captive portal will allow= the device to not perform extra probing. If there is a captive network, we= should be able to get the page or instructions on how to get beyond captiv= ity.
=C2=A0
Thanks,
<= /div>
Tommy



=C2=A0=
-D= ave
=C2=A0
=C2=A0<= /div>
=C2= =A0
From:=C2=A0Eric= Vyncke (evyncke) [mailto:evyncke@cisco.com]=C2=A0
Sent:=C2=A0Sunday, J= une 25, 2017 8:27 PM
To:=C2=A0Dave Dolson;=C2=A0captive-portals@ietf.org
C= c:=C2=A0David Bird
Subject:=C2= =A0Re: [Captive-portals] Use Case: "Carrier Grade Captive Porta= l"
=C2=A0
At least Erik Kline and myself are following the= captive-portal list :-)
=C2=A0
And the more we think about it, PvD could really = be useful and we, the PvD I-D authors, would be pleased to present at your = WG
= =C2=A0
-=C3=A9ric
=C2=A0
From:=C2=A0= Captive-portals <captive-por= tals-bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date:=C2= =A0Friday 23 June 2017 at 11:57
To:=C2=A0"captive-portals@ietf.org= " <captive-portals@ietf.org= >
Cc:=C2=A0David Bird <dbird@google.com>
Subject:=C2=A0= Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"= ;
=C2=A0
[resend with fewer recipient= s to avoid mailing list problems]
=C2=A0=
To echo David=E2=80=99s request,
> If the authors of= the PvD concept (re-)present their I-D to the mailing list, and stick arou= nd for discussion, that would be helpful.
<= div>
=C2=A0
=C2=A0
From:=C2=A0David Bird [= mailto:dbird@google.com]=C2=A0
Sent:=C2=A0Wednesday, June 14, 2017 9:36 AM
To:= =C2=A0Erik Kline
Cc:=C2=A0Gunther Nitzsc= he; Mark Townsley; Heiko Folkerts; Martin Thomson;=C2=A0captive-portals@ietf.org; Livingood, Jason; Herzig, = Willi; Warren Kumari; Dave Dolson
Subject:=C2=A0Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
=C2=A0
On Sun, Jun 11, 2017 at 11:17 PM, Erik Kl= ine <ek@google.com= > wrote:
I'm not sure we have enou= gh input on whether 511 is useful or not.=C2=A0 There seemed to be some sug= gestion it would help, and some that it wouldn't.=C2=A0 Perhaps one que= stion we could ask is whether it's harmful?=C2=A0 And if we agree it= 9;s not harmful, is it worth developing some recommendations for its use?
=C2=A0
<= div>
=C2=A0
In= of itself, I don't believe it is harmful. However, if vendors use it a= s a reason to continue to terminate TLS connection in order to deliver the = 511, then perhaps it is a bit harmful - or at least misleading. As the worl= d moves to TLS (and QUIC), I think the time for the 511 code has already pa= ssed, to some degree. That, combined with the fact you may still have brows= ers not handling that return code properly, I don't see the value for a= ny vendor or venue to implement this.
<= div>
=C2=A0
= =C2=A0
=
As for the ICMP unreachable= option, I certainly don't think it would be harmful (with the extra UR= L bits removed for now).=C2=A0 Is that something we wish to progress?
=C2=A0
=C2=A0<= u>
I will work on a new draft that is only the basics. The additional f= ields could always be add in their own draft as extensions.=C2=A0=
=C2=A0
=C2=A0
G= iven that we're probably looking at a portal detection method based on = entirely new work, it seems to me we're free to look at new things like= utilizing the PVD detection scheme (DNS queries for "provisioning dom= ain names", followed by other interaction still TBD).=C2=A0 Have the p= ortal implementors reviewed this and given consideration as to whether its = useful? =C2=A0(I think of the discovery of the portal and subsequent intera= ction with it as 2 separate processes conducted, obviously, in serial.)<= /u>
=C2=A0
=C2=A0
I believe there are several talking points here, as the PvD method= seems to have several possible implementations.=C2=A0
<= /div>
=C2=A0=
I think requiring Ipv6 to configure Ipv4 is weird (I believe= that was one proposed method to convey configuration)
<= /div>
=C2=A0=
Several points I made in the thread "Arguments against = any Capport API" regarding a web service - detached from the NAS - con= trolling the UE/station I think are relevant.
=C2=A0
If the authors of the PvD concept (re-)present their I-D to the maili= ng list, and stick around for discussion, that would be helpful.=C2=A0
=C2=A0
=C2=A0
Thoughts?


_____________________= __________________________
Captive-portals mailing list
Captive-portals@i= etf.org
https://www.ietf.org/mailman/listinf= o/captive-portals

=C2=A0
=
________= _______________________________________
Captive-portals mailing list
Captive-portals@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/= captive-portals
=C2=A0
=C2=A0
______________________________________________= _
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals