From nobody Wed Nov 1 09:39:31 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D9413B408 for ; Wed, 1 Nov 2017 09:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQp9RMamM8uf for ; Wed, 1 Nov 2017 09:39:22 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B438013F732 for ; Wed, 1 Nov 2017 09:39:22 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id j3so2571287pga.1 for ; Wed, 01 Nov 2017 09:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gsePcWOisrixSdltDsoadqjvKmhwLlLbs/ZWwrwvXrw=; b=QCbCxnhkvvL49HfPDZ1H4E4DuEKjNeIhoWLOxQrD7X7Jmh8ALZ/ThcrtXheSnTSfOe qFjQb41YvnD8d6Gk6WuwWj0N0vSNYuUo+rGaX7e5V2bz7nVqvOgePFJfYWVaI+3ZFeTL /X9vZbWwmHtZH2Mw0LfTGxTv0E8JU3dQQUEhYgpd0q8QLp3tvID5QvWSzNF5oDnA2BSM 8m8IRYr7n+gInBTgiU4SDBhTh+KhNLXY6NZWK+qJD4ZDqQqM0EnnJDTZuPUX+xA9DjgV miaY80Z27VFoJqF8krKDSA3pXYbrBLQKAAXLljMiImRF7FMhWpoGQKbxYqck/GZtU2Ro dxGQ== 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=gsePcWOisrixSdltDsoadqjvKmhwLlLbs/ZWwrwvXrw=; b=r06eMqOa3c+vLM59U7CbgOY9vpuHy+1aTrFvMXElgxwLyEic4oUbtoSb5sHat17ICd PT/whan4hDqfopmLnUkIeP9yG1ObKBDXmc/ajsWxcnYfuQ8P+8ZMx8nHgKMSfjpdT3tO tUiDhEIecuvlkWc02DPFe+oFDcxevkAnYpz0lx8eCb/rtJ/xglPEWjEB1RDNIHuU4xbk P1uf2su3TBiyzVfkN1L69yfIjoZBAeWS1OcDxH27RZnZm7HAQQbN7LhBbY5xdL/Lual5 e5s43zakhjqNfnoI26mjFAy/QQ6oQQXtT6D8LJ6wtlMJLTtnM/lgfysYwvSgQNi5xayq waKA== X-Gm-Message-State: AMCzsaXOpS+o2Dj+oSlxwxnDGWHFeaK9dgdyOaNSFxrO+luTpv27Ug2J X4J+644/QmQbql5AUsBPr2sWabbGW6rNoAyIlcE= X-Google-Smtp-Source: ABhQp+Ql9wOQ1IXJ20h8blSyOw3cucTcx7scht1wK7G6psIYmUvhOWe2eobDtiXeuq7szZhZPzuJGOR3OGBOJZ3Dr+I= X-Received: by 10.84.132.66 with SMTP id 60mr187183ple.225.1509554361963; Wed, 01 Nov 2017 09:39:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.78 with HTTP; Wed, 1 Nov 2017 09:39:01 -0700 (PDT) In-Reply-To: References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> From: Dick Hardt Date: Wed, 1 Nov 2017 09:39:01 -0700 Message-ID: To: Mike Jones Cc: Yaron Sheffer , "Richard Backman, Annabelle" , ID Events Mailing List , "Phil Hunt (IDM)" Content-Type: multipart/alternative; boundary="94eb2c12553e839b08055cee8325" Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 16:39:29 -0000 --94eb2c12553e839b08055cee8325 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Your comments highlight a couple of points: 1) The example is how to have a predefined extension point for extensions of a specific event, it is not how to add another event. Myself, I think this is overly complicated. Events should be comparatively static, and as with many other JSON formats, the receiver should ignore properties it does not understand, which let's new properties be introduced as extensions. There should not be any conflict as extensions should only be done by the profile that created the event format to start off with. 2) Having an lvalue be a URI is much harder to code against. I'm not sure why Marius had that in his example. Per the event, the type of the event is well defined with "event_type": "https://example.com/scim/event/passwordResetExt", 3) This thread is about reasons for multiple events to be contained in one set. Your mention of an issuer not wanting to sign separate events as a reason to allow multiple events. I think we have decided that given a preference, we will push effort to the transmitter over the receiver as in many use cases there are many more receivers. Given that, it is more complex for a receiver to have different ways of managing the receipt of multiple events as not all issuers will bundle the events, so it is simpler to have only one event per SET. Including the separate events with a URI as an lvalue is challenging to implement, speaking from experience. On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones wrote: > Marius=E2=80=99 proposed syntax, pasted in below, has exactly this > characteristic. The way I see it, his proposal essentially has a primary > passwordReset event and a secondary passwordResetExt data structure, whic= h > could have been simply another event value in the current draft. > > > > This breaking change makes the data structures more complicated - not > less. And it makes things that used to be possible impossible, reducing > flexibility to those who would use the spec. > > > > These seem like bad tradeoffs to me. > > > > { > > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "iat": 1458496025, > > "iss": "https://scim.example.com", > > "aud": [ > > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "event_type": "https://example.com/scim/event/passwordResetExt", > > "event": { > > "id":"44f6142df96bd6ab61e7521d9", > > "extensions": { > > "https://example.com/scim/event/passwordResetExt=E2=80=9D: { > > "resetAttempts":5, > > } > > } > > } > > } > > > > In particular, it makes it impossible to sign multiple related events > sharing a common claims schema with a single signature by the issuer. It > forces the issuer to do the extra work of signing each of the related > events (or facets of the same logical event) individually and forces the > recipients to do the extra work of checking all those unnecessary > signatures. > > > > Not every profile will ever have multiple keys in the =E2=80=9Cevents=E2= =80=9D set but > there=E2=80=99s absolutely no reason to preclude it. > > > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org] * On Behalf Of *Dick > Hardt > *Sent:* Tuesday, October 31, 2017 9:52 PM > *To:* Mike Jones > *Cc:* Yaron Sheffer ; Richard Backman, Annabelle < > richanna@amazon.com>; ID Events Mailing List ; Phil > Hunt (IDM) > > *Subject:* Re: [Id-event] Use cases for multiple events per SET? > > > > Please direct me to a proposal that has a "primary" and "secondary" > events. I agree that is undesirable. I would also encourage to engage in > the discussions so that we can drive clarity and simplicity. > > > > I think the proposal is that there is one event per SET. > > > > I think having more than one event per SET adds complexity as a receiver > must deal with receiving correlated events in one SET as well as correlat= ed > events in the same SET. > > > > /Dick > > > > On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones > wrote: > > I hear you on the fact that different people have joined the effort at > different times. That=E2=80=99s a normal process as an effort builds mom= entum. I > get that not everyone was there when previous consensus calls were taken. > > > > I should note that I have specific technical objections to the specific > proposed changes being discussed as well. Currently all events in the se= t > have the same syntax. The proposals, as I understand them, revert us to = a > state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and =E2=80=9Cseco= ndary=E2=80=9D events, with different > syntax for the two classes. That=E2=80=99s needlessly more complicated, = adding no > actual value. > > > > -- Mike > > > > *From:* Dick Hardt [mailto:dick.hardt@gmail.com] > *Sent:* Tuesday, October 31, 2017 9:37 PM > *To:* Mike Jones > *Cc:* Phil Hunt (IDM) ; Yaron Sheffer < > yaronf.ietf@gmail.com>; Richard Backman, Annabelle ; > ID Events Mailing List > > > *Subject:* Re: [Id-event] Use cases for multiple events per SET? > > > > Mike > > > > As you well know, many people in a WG don't look closely at a > specification until last call is made. Additionally, we are coming up on > only the 3rd WG meeting. The WG has not existed for very long. While some > of the participants have been working on this for a while, many have not, > and we are looking for consensus across the WG. > > > > Since SecEvent is a framework that we expect to be profiled, I feel it is > important to ensure that SecEvent specifications are easy for a variety o= f > profiles to adopt, and that the semantics make sense. I also think that > properties that are specific to a profile should be left to that profile > and not be included in SecEvent. > > > > Since this is a framework, it is expected that as different groups profil= e > it, there will be additional feedback. > > > > Specifically, as a participant in the RISC profile of SET, a number of > issues in SET have surfaced as the RISC WG has looked at how to use the S= ET. > > > > As for SET being stable for over a year, there have been a number of > changes to SET since then. I also don't think there was consensus. Before > the WG was formed, I and several others had expressed concern on the desi= gn > of SET when Phil presented it at an IIW session. > > > > As to taking another year, I am hopeful we can resolve the remaining > issues in SET and publish a new draft for last call. I do not think we wi= ll > need to wait for another WG meeting to ask for last call. > > > > We also have a number of other documents that are not in last call, and w= e > don't have a WG adopted draft yet for management. So there are still a > number of documents to work through before we have all the bits for someo= ne > to work with. > > > > I do think we have been making good progress since the last IETF meeting, > and I am hopeful we can keep up this momentum and finalize all the > documents in a timely manner. > > > > /Dick > > > > > > On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones > wrote: > > It=E2=80=99s hard for me to even express my level of frustration with the= recent > attempts to once again redesign the SecEvent Token spec. We=E2=80=99ve b= een at > this for multiple years because people keep trying to revisit decisions > that were long ago made by consensus. It=E2=80=99s been stable for over = a year and > the majority of WGLC respondents said some variant of =E2=80=9CWorks for = me =E2=80=93 ship > it!=E2=80=9D > > > > There=E2=80=99s not sufficient justification to try to undo consensus pos= itions > that have been debated and affirmed over and over. Countenancing wholesa= le > changes at this late date is counterproductive in the extreme! > > > > It=E2=80=99s far better than good enough as-is. In my experience, if we = start > redesigning it, it will result in another year=E2=80=99s delay. It does = something > simple and useful. Please, let=E2=80=99s just ship it, so people can rel= y on it. > > > > -- Mike > > > > *From:* Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] > *Sent:* Monday, October 30, 2017 2:42 PM > *To:* Dick Hardt > *Cc:* Yaron Sheffer ; Richard Backman, Annabelle < > richanna@amazon.com>; Mike Jones ; ID Events > Mailing List > > > *Subject:* Re: [Id-event] Use cases for multiple events per SET? > > > > Inline... > > Phil > > > On Oct 30, 2017, at 2:22 PM, Dick Hardt wrote: > > Hi Phil > > > > Correct me if I am misunderstanding, but there is a RISC profile event > > > > "http://schemas.openid.net/secevent/risc/event-type/ accou= nt-credential-change-required=E2=80=9D > > > > and an SCIM profile event > > > > "https://example.com/scim/event/passwordResetExt=E2=80=9D > > > > I'm suggesting that two different events would be sent. Embedding one in > the other does not make sense. > > It is a hypothetical example. Just because you disagree on this does > not mean others are not valid. > > > > I just picked overlapping proposals that have different meaning (but not > the same) to illustrate the difference from issuing a single set with > different events. > > > > As I have stated this is very different from asserting multiple distinct > events in one SET. > > > > Also, I think it is simpler to have event_type be at the same level as > event > > > > may be. I was working from Annabelle's proposed format. > > > > { > > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "iat": 1458496025, > > "iss": "https://scim.example.com", > > "aud": [ > > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "event_type": "https://example.com/scim/event/passwordResetExt", > > "event": { > > "id":"44f6142df96bd6ab61e7521d9", > > "resetAttempts":5 > > } > > } > > > > { > > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "iat": 1458496025, > > "iss": "https://scim.example.com", > > "aud": [ > > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "event_type": "http://schemas.openid.net/secevent/risc/event-type/ > account-credential-change-required > > ", > > "event": { > > =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, > > =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" > > } > > } > > > > > > > > > > > > On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt wrote: > > Annabelle/Dick, > > > > Thanks for the comments. I think we need to examine the consequences of > the proposal in JSON. > > > > As I stated, what causes most of the issue is the proposed extension > mechanism in the payload (possibly using events in a recursive way). Does > it follow the old format or the new? > > > > Let=E2=80=99s consider a use case where we have an identity management s= ystem > that uses SCIM, but the SCIM system is also the underlying data store for > Connect. A Password reset might generate the following event which has a= n > extension (conveying reset count) AND overlapping statement from RISC. > BOTH of which might be important to a similar receiver using SCIM and OID= C. > > > > > *The 03 spec currently would allow:* > > > > { > > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "iat": 1458496025, > > "iss": "https://scim.example.com", > > "aud": [ > > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "events": { > > "urn:ietf:params:scim:event:passwordReset": > > { "id":"44f6142df96bd6ab61e7521d9"}, > > "https://example.com/scim/event/passwordResetExt": > > { "resetAttempts":5}, > > "http://schemas.openid.net/secevent/risc/event-type/\ > account-credential-change-required": { > > =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, > > =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" > > } > > } > > } > > > > In the above - each payload is a =E2=80=98peer' and issued without prefer= ence by the transmitter. The receiver can assign priority in its own contex= t if that matters. > > > > *The new proposal:* > > > > { > > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "iat": 1458496025, > > "iss": "https://scim.example.com", > > "aud": [ > > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "event": { > > =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passwordRes= et=E2=80=9D, > > "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, > > =E2=80=9Cevents=E2=80=9D:{ > > ->note =E2=80=A6is this the old or new structure? <- > > "https://example.com/scim/event/passwordResetExt": > > { "resetAttempts":5}, > > "http://schemas.openid.net/secevent/risc/event-type/\ > account-credential-change-required": { > > =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, > > =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" > > } > > } > > } > > } > > > > In the above, sub-events or extensions have a different format. The same = complaint about the original stands. > > > > **OR* (if the receiver cares about RISC more). Note that this leads to a= triple nested structure.* > > > > { > > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "iat": 1458496025, > > "iss": "https://scim.example.com", > > "aud": [ > > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "event": { > > =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/ris= c/event-type/\ > > account-credential-change-required=E2=80=9D, > > =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, > > =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, > > =E2=80=9Cevents=E2=80=9D:{ > > "urn:ietf:params:scim:event:passwordReset": > > { > > "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, > > =E2=80=9Cevents=E2=80=9D:{ > > "https://example.com/scim/event/passwordResetExt": > > { "resetAttempts":5}, > > } > > } > > } > > } > > } > > > > In the above, the extension is placed inside the event it extends. It fol= lows the old format (or should it follow the new?) > > **OR* Following the top layer pattern of singular event Note that this l= eads to a triple nested structure.* > > > > { > > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "iat": 1458496025, > > "iss": "https://scim.example.com", > > "aud": [ > > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "event": { > > =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/ris= c/event-type/\ > > account-credential-change-required=E2=80=9D, > > =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, > > =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, > > =E2=80=9Cevent=E2=80=9D:{ > > =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:password= Reset=E2=80=9D, > > "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, > > =E2=80=9Cevent=E2=80=9D:{ > > =E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/event/pa= sswordResetExt=E2=80=9D, > > "resetAttempts":5 > > } > > } > > } > > } > > > > This format follows the proposed singular event format recursively and is= 3 layers deep. Note that the parser has to continue to search the document= for things that aren=E2=80=99t there as it has to stop when no =E2=80=9Cev= ent=E2=80=9D attribute is found rather than iterate over an array. > > > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > > phil.hunt@oracle.com > > > > On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > > > Replies inline. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Phil Hunt > *Date: *Sunday, October 29, 2017 at 5:25 PM > *To: *Dick Hardt > *Cc: *Yaron Sheffer , Mike Jones < > Michael.Jones@microsoft.com>, "Richard Backman, Annabelle" < > richanna@amazon.com>, ID Events Mailing List > *Subject: *Re: [Id-event] Use cases for multiple events per SET? > > > > I hope this answers your question. > > > > My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reason why not= . The question should be, > what is the justification to make =E2=80=9Cevents=E2=80=9D singular? > > [richanna]The singular =E2=80=9Cevent=E2=80=9D claim has clearer semantic= s and is easier > to process. We should opt for easier solutions unless there are use cases > that require more complexity.[/richanna] > > > > There are many reasons for multiple events in a SET. Some are good, some > not so good. Some of the reasons... > > > > 1. Multiple event payloads expressing statements about largely the > *same*thing. For example, SCIM password reset AND RISC password reset. A > RISC Event and an OpenBanking Event. Is one a complement to the other? D= o > they overlap or are they distinct? > > [richanna]Copy/pasted from my earlier email: > > Why is it necessary or appropriate to include these events in the same > SET? They are likely being generated by different systems at different > times on the transmitter=E2=80=99s side, consumed by different systems on= the > receiver=E2=80=99s side, and possibly being transmitted over different ev= ent > streams. I know the latter would be the case for us, as a receiver. Even = if > it=E2=80=99s not, is it burdensome to send these events separately? What = value is > gained in combining them? > > > > Additionally, since the signature is over the SET and not the event > objects, Receivers independently route separate events from a single toke= n > without either losing the ability to verify the authenticity of the event > or sharing all information in the SET with every system handling any even= t > in the token.[/richanna] > > > > 2. Multiple events payloads expressing different statements about the > same transaction - RISC Password Reset and RISC Session Cancel > [richanna]Same as above[/richanna] > > 3. A new profile defines new event attributes to be added on to an > existing event type (a pure extension) > [richanna]I have suggested a way to support extensions within an event > body, multiple times now. If you see problems with it, please point them > out.[/richanna] > > > > I think it is quite valid to allow 1 and 3. 2 could be limited by > specific profiles like RISC if they want. > > > > I am not in agreement that making event singular simplifies anything. For > one is makes extensions complex (another nested JSON structure) and > potentially conflicting. > [richanna] > > Ways that multiple-event SETs are more complicated: > > 1. It results in a more complex structure for the single event use > case, which I think we all agree is the majority use case. > 2. Multiple-event SETs have ambiguous semantics. The presence of two > events A and B in the same SET could mean any of: > > > 1. They are related to the same logical event (i.e. the same thing as > if they were from different SETs that have a common txn). > 2. A is an extension of B. > 3. B is an extension of A. > 4. They are aliases for one another. > 5. They are not actually related to one another in any way. > > > 1. Claim semantics become harder to define, as different profiles may > want to use the same claims in different ways. > > > > If the WG wants to block 1 and 2 above, then I believe we have to > establish an event registry to ensure new Event profiles do not overlap t= o > eliminate the need to express multiple events. > > [richanna]I=E2=80=99m not sure what you mean by this. Are you referring t= o event > names? Those are already defined by the spec to be URIs.[/richanna] > > Phil > > > > Oracle Corporation, Identity Cloud Services Architect > > @independentid > > www.independentid.com > > > phil.hunt@oracle.com > > > > On Oct 29, 2017, at 4:12 PM, Dick Hardt wrote: > > > > Phil: > > > > In your examples for having a plurality of events, you use the word "may"= , > which leads me to question if a plurality of events is really required in > SET. > > > > You posit that it will be difficult for a distributed system to correlate > multiple SETs with the same "txn", but the distributed system will > certainly need to correlate events on the same subject -- correlating > events on the same "txn" on the same subject seems fairly simple. > > > > I think that a receiver will need to correlate multiple SEts on the same > subject, so having multiple events in a SET is redundant, and adds > complexity with no clear benefit that I can see. > > > > An implementor may choose to send multiple SETs, or send a single SET wit= h > multiple events, so a receiver will need to support both. I prefer we pic= k > one way and minimize the code paths, and we will need to support > correlating across multiple SETs, so that seems the best mechanism. > > > > Let me know if there is something I missed in my logic. > > > > /Dick > > > > > > On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer > wrote: > > In that case, let's add text to that effect, e.g. we could add to the > definition of the "events" claim: > > Profiling specifications SHOULD define the allowed event statements, and > MAY restrict their number. For example, some profiles may require this > claim to contain only a single event statement. > > Thanks, > Yaron > > On 24/10/17 22:10, Mike Jones wrote: > > I agree with much of Phil=E2=80=99s rationale here. > > It=E2=80=99s fine for some profiles to say that the =E2=80=9Cevents=E2=80= =9D set must be a > singleton. That doesn=E2=80=99t have to be true for all events. I think= things > are fine as-is. > > -- Mike > > *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Phil > Hunt > *Sent:* Monday, October 23, 2017 8:47 PM > *To:* Richard Backman, Annabelle > *Cc:* ID Events Mailing List > *Subject:* Re: [Id-event] Use cases for multiple events per SET? > > Annabelle, > > I have a number of concerns with this proposal. > > Profiling Independence / Keeping Event Payloads Independent > > Indicating that extensions should be handled by profiles leads to more > inter-operability issues and more importantly intrudes on the Event paylo= ad > space by suggesting a sub-schema creates potential limitations and > conflicts that may add to complexity later on. The current format allows = a > parser to discover and unload one or more JSON payloads which can each ha= ve > independent structure. > > General extensions > > The proposal also rules out general purpose extensions not related to any > specific event. Given the emergence of items like GPRD, I would not want = to > block the ability to add meta-data or other general purpose items. We can > also anticipate some delivery scenarios where additional data might be > required. Even though there is no current planned use, I see no good reas= on > to rule this out. > > Multiple Events From Different Families (vs. Multiple Events from a singl= e > family like RISC) > > In our RISC session we discussed expressing multiple distinct RISC events > in one SET. The discussion was that only one RISC event at a time. We did > not discuss other event profiles. I don=E2=80=99t see a reason to rule ou= t > multi-events from different families at the SET level. Each profile is > expressing slightly different things about the same event. > > I can forsee some cases where it is not clear which is the primary and > which is the extension. There may not be a clear winner. > > A couple of examples (these are necessarily real=E2=80=A6just possibiliti= es): > > * It is probably useful to be able to express simlar/overlapping events > from different SET profiles in one SET. For example a Backchannel Logout= & > a RISC session cancel event. > > * SCIM may want to represent a single transaction as causing multiple > state changes in an event (e.g. a password change causes multiple effects= ). > Having to chase down multiple events and correlate by =E2=80=9Ctxn=E2=80= =9D would be > challenging in a multi-threaded/multi-node delivery system. The SCIM li= st > has not discussed this, but I would not want to block this capability. I= OW > - Just because RISC does not want to express multiple events does not mak= e > this true for other profiles. > > * We may wish to indicate a SCIM Password Reset was performed and a > Logout/session cancellation is expressed at the same time. The events ar= e > related but express different data. > > Avoiding Confusion From Similar Events Originating from the Same > Transaction > > If events are sent separately, then more tracking of state (e.g. by txn) > would be required to ensure similar events are not mistaken or handled as > repeats. While txn provides useful audit analysis capability, I=E2=80=99m= not sure > it can be used in live or near-real time systems given distributed > multi-node, multi-threading architectures. > > Previous Discussion > > I note that I originally raised having an attribute to designate primary > event attribute to alleviate your concern, but this was not accepted. See= : > > * https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html > > > * https://www.ietf.org/mail-archive/web/id-event/current/msg00140.html > > > The consensus, at least as I interpreted it is up to the receiver to > figure this out based on the definitions it has for each event URI and th= e > profiles they represent. IOW - RISC is free to limit that only one RISC > event be expressed at a time. > > Phil > > Oracle Corporation, Identity Cloud Services Architect > > @independentid > > www.independentid.com > > > > > > phil.hunt@oracle.com > > On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle > > wrote: > > The current draft of the SET spec allows for expressing multiple > events within the same token, which introduces additional complexity > and room for ambiguous semantics. We=E2=80=99ve discussed this in the= OIDF > RISC working group and the current consensus there is that RISC will > require that RISC events must be the only event in the SET, having > identified ways to clearly and easily support the handful of use > cases for multiple events per token that people have raised. With > that context in mind, I propose striking the definition of the > =E2=80=9Cevents=E2=80=9D claim from the Security Event Token spec, an= d replacing it > with the following definition for an =E2=80=9Cevent=E2=80=9D claim (s= ingular): > > event > > A JSON object containing an "event_type" member whose value is a URI > representing a type of event defined in a Profiling Specification. > The object MAY otherwise be empty, or MAY contain additional members > as described by the Profiling Specification. > > Here is the example SET from section 2.3, rewritten with this change > mind: > > { > > "jti": "4d3559ec67504aaba65d40b0363faad8", > > "iat": 1458496404, > > "iss": "https://scim.example.com ", > > "aud": [ > > "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "event": { > > "event_type": "urn:ietf:params:scim:event:create", > > "ref": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 > ", > > "attributes": ["id", "name", "userName", "password", "emails"] > > } > > } > > Does anyone in the working group have use cases for SETs that cannot > be met by this proposed text? Within RISC, we identified three use > cases, with solutions outlined below: > > ** > > *Extensions* > > Event extension mechanisms can be defined internal to the event > object. A simple approach would be to define an =E2=80=9Cextensions= =E2=80=9D member > that is a list of event objects (or set resembling the =E2=80=9Cevent= s=E2=80=9D > claim as defined in the current spec). This has the advantage of > making it clear in the data structure that there is a single primary > event, with zero or more extensions. There is no room for confusion > over which event is primary, or if there is a primary event at all. > I would be fine with adding something like this to my proposed text, > if there is consensus that it is broadly useful. > > *Aliases* > > This use case was brought up in the context of migrating clients > from draft event names to standardized event names. In this case, > the event transmitter can transmit two tokens for the logical event, > one using the old name and another using the new name. > > *Related Events* > > The SET spec defines the txn claim as a means of correlating > independent tokens that relate to the same logical event. > > -- > Annabelle Richard Backman > > Amazon =E2=80=93 Identity Services > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > s5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=3D > X8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > -- > > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DYBCGlK9mjjhcFsj- > 2tDkn31Auxuruib9KATkRlQG1iw&s=3DWrMuQRwLV802iMQ4wYB1f2rFUGu4zb > hcW001fK02EXs&e=3D > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DU- > a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=3DrvdrtI7rYNRAnqZDltCwBAZVHKp= - > MJ20ui2nm46QSz0&e=3D > > > > > > > > -- > > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DiyVnrZmr9_ > uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=3DOe0qfLEX83vtXM7Wl2cYBe- > Gg1DVPjhXjVJkfhVRzwc&e=3D > > > > > > -- > > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > > > > > > -- > > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --94eb2c12553e839b08055cee8325 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your comments highlight a couple of points:

1) The example is how to have a predefined extension point = for extensions of a specific event, it is not how to add another event. Mys= elf, I think this is overly complicated. Events should be comparatively sta= tic, and as with many other JSON formats, the receiver should ignore proper= ties it does not understand, which let's new properties be introduced a= s extensions. There should not be any conflict as extensions should only be= done by the profile that created the event format to start off with.
=

2) Having an lvalue be a URI is much harder to code aga= inst. I'm not sure why Marius had that in his example. Per the event, t= he type of the event is well defined with=C2=A0


3) This thread is about reasons for = multiple events to be contained in one set. Your mention of an issuer not w= anting to sign separate events as a reason to allow multiple events. I thin= k we have decided that given a preference, we will push effort to the trans= mitter over the receiver as in many use cases there are many more receivers= . Given that, it is more complex for a receiver to have different ways of m= anaging the receipt of multiple events as not all issuers will bundle the e= vents, so it is simpler to have only one event per SET. Including the separ= ate events with a URI as an lvalue is challenging to implement, speaking fr= om experience.



=C2= =A0







<= /div>

On Tue= , Oct 31, 2017 at 11:05 PM, Mike Jones <Michael.Jones@microsoft.= com> wrote:

Marius=E2=80=99 propos= ed syntax, pasted in below, has exactly this characteristic.=C2=A0 The way = I see it, his proposal essentially has a primary passwordReset event and a = secondary passwordResetExt data structure, which could have been simply another event value in the current draft.=

=C2=A0

This breaking change m= akes the data structures more complicated - not less.=C2=A0 And it makes th= ings that used to be possible impossible, reducing flexibility to those who= would use the spec.

=C2=A0

These seem like bad tr= adeoffs to me.

=C2=A0

{

=C2=A0 "jti": "3d0c3cf797584bd193bd0fb1= bd4e7d30",

=C2=A0 "iat": 1458496025,

=C2=A0 "iss": "https://scim.example.com",

=C2=A0 "aud": [

=C2=A0 =C2=A0 "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",

=C2=A0 =C2=A0 "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"

=C2=A0 =C2=A0],

=C2=A0 =C2=A0"event_type": "https://examp= le.com/scim/event/passwordResetExt",

=C2=A0 =C2=A0"event": {=C2=A0=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"id":"44f6142df96bd6ab61e7521d9",=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"extensions&q= uot;: {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"https://e= xample.com/scim/event/passwordResetExt=E2=80=9D: {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"reset= Attempts":5,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0 =C2=A0}

}

=C2=A0

In particular, it make= s it impossible to sign multiple related events sharing a common claims sch= ema with a single signature by the issuer.=C2=A0 It forces the issuer to do= the extra work of signing each of the related events (or facets of the same logical event) individually and forces the r= ecipients to do the extra work of checking all those unnecessary signatures= .

=C2=A0

Not every profile will= ever have multiple keys in the =E2=80=9Cevents=E2=80=9D set but there=E2= =80=99s absolutely no reason to preclude it.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike

<= span style=3D"color:#002060">=C2=A0

From: Id-event [mailto:id-event-bounces@ietf.org= ] On Behalf Of Dick Hardt
Sent: Tuesday, October 31, 2017 9:52 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle <= richanna@amazon.co= m>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt (IDM) <phil.hunt@oracle.com>= ;


Subject: Re: [Id-event] Use cases for multiple events per SET?

=C2=A0

Please direct me to a proposal that has a "prim= ary" and "secondary" events. I agree that is undesirable. I = would also encourage to engage in the discussions so that we can drive clar= ity and simplicity.

=C2=A0

I think the proposal is that there is one event per = SET.

=C2=A0

I think having more than one event per SET adds comp= lexity as a receiver must deal with receiving correlated events in one SET = as well as correlated events in the same SET.

=C2=A0

/Dick

=C2=A0

On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

I hear you on the fact= that different people have joined the effort at different times.=C2=A0 Tha= t=E2=80=99s a normal process as an effort builds momentum.=C2=A0 I get that not everyone was there when previous consensus calls were taken.

=C2=A0

I should note that I h= ave specific technical objections to the specific proposed changes being di= scussed as well.=C2=A0 Currently all events in the set have the same syntax.=C2=A0 The proposals, as I understand them, revert us to a= state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and =E2=80=9Csecon= dary=E2=80=9D events, with different syntax for the two classes.=C2=A0 That= =E2=80=99s needlessly more complicated, adding no actual value.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mik= e

=C2=A0

From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Tuesday, October 31, 2017 9:37 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Phil Hunt (IDM) <phil.hunt@oracle.com>; Yaron Sheffer <yaronf.ietf@gmail.com>= ; Richard Backman, Annabelle <richanna@amazon.com>; ID Events Mailing List <id-event@ietf.org>


Subject: Re: [Id-event] Use cases for multiple events per SET?

=C2=A0

Mike

=C2=A0

As you well know, many people in a WG don't look= closely at a specification until last call is made. Additionally, we are c= oming up on only the 3rd WG meeting. The WG has not existed for very long. While some of the participants have been working on this fo= r a while, many have not, and we are looking for consensus across the WG.

=C2=A0

Since SecEvent is a framework that we expect to be p= rofiled, I feel it is important to ensure that SecEvent specifications are = easy for a variety of profiles to adopt, and that the semantics make sense. I also think that properties that are specific t= o a profile should be left to that profile and not be included in SecEvent.=

=C2=A0

Since this is a framework, it is expected that as di= fferent groups profile it, there will be additional feedback.=

=C2=A0

Specifically, as a participant in the RISC profile o= f SET, a number of issues in SET have surfaced as the RISC WG has looked at= how to use the SET.

=C2=A0

As for SET being stable for over a year, there have = been a number of changes to SET since then. I also don't think there wa= s consensus. Before the WG was formed, I and several others had expressed concern on the design of SET when Phil presented it at an II= W session.

=C2=A0

As to taking another year, I am hopeful we can resol= ve the remaining issues in SET and publish a new draft for last call. I do = not think we will need to wait for another WG meeting to ask for last call.=C2=A0

=C2=A0

We also have a number of other documents that are no= t in last call, and we don't have a WG adopted draft yet for management= . So there are still a number of documents to work through before we have all the bits for someone to work with.

=C2=A0

I do think we have been making good progress since t= he last IETF meeting, and I am hopeful we can keep up this momentum and fin= alize all the documents in a timely manner.

=C2=A0

/Dick

=C2=A0

=C2=A0

On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

It=E2=80=99s hard for = me to even express my level of frustration with the recent attempts to once= again redesign the SecEvent Token spec.=C2=A0 We=E2=80=99ve been at this for multiple years because people keep trying to revisit decisions that we= re long ago made by consensus.=C2=A0 It=E2=80=99s been stable for over a ye= ar and the majority of WGLC respondents said some variant of =E2=80=9CWorks= for me =E2=80=93 ship it!=E2=80=9D

=C2=A0

There=E2=80=99s not su= fficient justification to try to undo consensus positions that have been de= bated and affirmed over and over.=C2=A0 Countenancing wholesale changes at this late date is counterproductive in the extreme!

=C2=A0

It=E2=80=99s far bette= r than good enough as-is.=C2=A0 In my experience, if we start redesigning i= t, it will result in another year=E2=80=99s delay.=C2=A0 It does something = simple and useful.=C2=A0 Please, let=E2=80=99s just ship it, so people can rely o= n it.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike

=C2=A0<= /u>

From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]
Sent: Monday, October 30, 2017 2:42 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle <= richanna@amazon.co= m>; Mike Jones <Michael.Jones@microsoft.com>; ID Events Mailing List <id-event@ietf.org>


Subject: Re: [Id-event] Use cases for multiple events per SET?

=C2=A0

Inline...

Phil


On Oct 30, 2017, at 2:22 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hi Phil

=C2=A0

Correct me if I am misunderstanding, but there is a = RISC profile event=C2=A0

=C2=A0
"=
http://=
schemas.openid.net/secevent/risc/event-type/account-cred=
ential-change-required=E2=80=9D
=C2=A0

and an SCIM profile event

=C2=A0

I'm suggesting that two different events would b= e sent. Embedding one in the other does not make sense.

<ph>It is a hypothetical example. Just because= you disagree on this does not mean others are not valid.=C2=A0

=C2=A0

I just picked overlapping proposals that have differ= ent meaning (but not the same) to illustrate the difference from issuing a = single set with different events.=C2=A0

=C2=A0

As I have stated this= is very different from asserting multiple distinct events in one SET.=C2= =A0

=C2=A0

Also, I think it is simpler to have event_type be at= the same level as event

=C2=A0

<ph>may be. I w= as working from Annabelle's proposed format.=C2=A0

=C2=A0

= {

= =C2=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30&qu= ot;,

= =C2=A0 "iat": 1458496025,

= =C2=A0 "iss": "https://scim.example.com",

= =C2=A0 "aud": [

= =C2=A0 =C2=A0],

= =C2=A0 =C2=A0"event_type": "https://example.com/scim/event/passwordResetExt",

= =C2=A0 =C2=A0"event": {=C2=A0=C2=A0

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"id":"44f6142df96bd6a= b61e7521d9",

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"resetAttempts":5=

= =C2=A0 =C2=A0 =C2=A0 =C2=A0}

= }

=C2=A0

= {

= =C2=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30&qu= ot;,

= =C2=A0 "iat": 1458496025,

= =C2=A0 "iss": "https://scim.example.com",

= =C2=A0 "aud": [

= =C2=A0 =C2=A0],

= =C2=A0 =C2=A0"event": {

= =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2= =80=9D,

= =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=9Ciss=E2=80=9D:"https://idp.example.com/"= =C2=A0 =C2=A0 =C2=A0 =C2=A0

= =C2=A0 =C2=A0 =C2=A0 =C2=A0}

= }

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:

Annabelle/Dick,

=C2=A0

Thanks for the comments. I think we need to examine = the consequences of the proposal in JSON.

=C2=A0

As I stated, what causes most of the issue is the pr= oposed extension mechanism in the payload (possibly using events in a recur= sive way). Does it follow the old format or the new?

=C2=A0

Let=E2=80=99s =C2=A0consider a use case where we hav= e an identity management system that uses SCIM, but the SCIM system is also= the underlying data store for Connect.=C2=A0 A Password reset might generate the following event which has an extension (conveying reset count= ) AND overlapping statement from RISC.=C2=A0 BOTH of which might be importa= nt to a similar receiver using SCIM and OIDC. =C2=A0

=C2=A0

The 03 spec currently would allow:<= /u>

=C2=A0

{
=C2=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d=
30",
=C2=A0 "iat": 1458496025,
=C2=A0 "iss": "https://scim.example.com",
=C2=A0 "aud": [
=C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Fee=
ds/98d52461fa5bbc879593b7754",
=C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Fee=
ds/5d7604516b1d08641d7676ee7"
=C2=A0=C2=A0 ],
=C2=A0=C2=A0 "events": {
=C2=A0=C2=A0=C2=A0=C2=A0 "urn:ietf:params:scim:event:passwor=
dReset":
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "id":"44f61=
42df96bd6ab61e7521d9"},
=C2=A0=C2=A0=C2=A0=C2=A0 "https://example.com/scim/event/=
passwordResetExt":
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAttempts":5},
=C2=A0=C2=A0=C2=A0=C2=A0 "http://schema=
s.openid.net/secevent/risc/event-type/\
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0account-credential-change-required": {=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =E2=80=9Ciss=E2=80=9D:"https://idp.ex=
ample.com/"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
}
=C2=A0 }
}
=C2=A0
In the ab=
ove - each payload is a =E2=80=98peer' and issued without preference by=
 the transmitter. The receiver can assign priority in its own context if th=
at matters.
=C2=A0
The ne=
w proposal:
=C2=A0
{
=C2=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d=
30",
=C2=A0 "iat": 1458496025,
=C2=A0 "iss": "https://scim.example.com",
=C2=A0 "aud": [
=C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Fee=
ds/98d52461fa5bbc879593b7754",
=C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Fee=
ds/5d7604516b1d08641d7676ee7"
=C2=A0=C2=A0 ],
=C2=A0=C2=A0 "event": {
=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:p=
arams:scim:event:passwordReset=E2=80=9D,
=C2=A0=C2=A0=C2=A0=C2=A0 "id":=E2=80=9D44f6142df96bd6ab=
61e7521d9=E2=80=9D,
=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevents=E2=80=9D:{

=C2=A0=C2=A0=C2=A0=C2=A0 ->note =E2=80=A6is this the old or new str=
ucture? <-


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://example.com/scim=
/event/passwordResetExt":


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAttempts=
":5},


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
"=
http://schemas.openid.net/secevent/risc/event-type/\
=C2=A0 =C2=
=A0 =C2=A0=C2=A0=C2=A0 =C2=A0account-credential-change-required":=
 {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =E2=80=9Ciss=E2=80=9D:"https://idp.ex=
ample.com/"


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
}


=C2=A0=C2=A0=C2=A0=C2=A0 }<=
/u>


=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=
=A0 


}


=C2=A0


In the ab=
ove, sub-events or extensions have a different format. The same complaint a=
bout the original stands.


=C2=A0


*OR* (=
if the receiver cares about RISC more).=C2=A0 Note that this leads to a tri=
ple nested structure.


=C2=A0


{


=C2=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d=
30",


=C2=A0 "iat": 1458496025,


=C2=A0 "iss": "https://scim.example.com",


=C2=A0 "aud": [


=C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Fee=
ds/98d52461fa5bbc879593b7754",


=C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Fee=
ds/5d7604516b1d08641d7676ee7"


=C2=A0=C2=A0 ],


=C2=A0=C2=A0 "event": {


=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/risc/event-typ=
e/\


=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 =C2=A0account-credential-change-required=E2=80=9D,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,

=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=E2=80=
=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=9Cevents=E2=80=9D:{


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 "urn:ietf:params:scim:event:passwordReset":=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 {=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "id":=
=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevents=
=E2=80=9D:{


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 "https://example.com/scim/event/passwordResetExt"=
:


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 { "resetAttempts":5},=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0}=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 




=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}




=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0}<=
/u>


}




=C2=A0






In the ab=
ove, the extension is placed inside the event it extends. It follows the ol=
d format (or should it follow the new?)






*OR* F=
ollowing the top layer pattern of singular event=C2=A0 Note that this leads=
 to a triple nested structure.


=C2=A0


{


=C2=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d=
30",


=C2=A0 "iat": 1458496025,


=C2=A0 "iss": "https://scim.example.com",


=C2=A0 "aud": [


=C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Fee=
ds/98d52461fa5bbc879593b7754",


=C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Fee=
ds/5d7604516b1d08641d7676ee7"


=C2=A0=C2=A0 ],


=C2=A0=C2=A0 "event": {


=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/risc/event-typ=
e/\


=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0account=
-credential-change-required=E2=80=9D,=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=9Cevent=E2=80=9D:{


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:p=
asswordReset=E2=80=9D,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=
=9D,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent=E2=80=9D:{


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_=
type=E2=80=9D:"https://example.com/scim/event/passwordRes=
etExt=E2=80=9D,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "resetAtte=
mpts":5 




=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}




=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0}<=
/u>


}


=C2=A0


This form=
at follows the proposed singular event format recursively and is 3 layers d=
eep. Note that the parser has to continue to search the document for things=
 that aren=E2=80=99t there as it has to stop when no =E2=80=9Cevent=E2=80=
=9D attribute is found rather than iterate over an array.<=
/u>




=C2=A0

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.= com

=C2=A0

On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabe= lle <richanna@a= mazon.com> wrote:

=C2=A0

Replies inline.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identity Services

=C2=A0

=C2=A0

From:=C2=A0Phil H= unt <phil.hunt@oracle.com>
Date:=C2=A0Sund= ay, October 29, 2017 at 5:25 PM
To:=C2=A0Dick H= ardt <dick.hardt@gmail.com>
Cc:=C2=A0Yaron = Sheffer <yaronf.ietf@gmail.com>, Mike Jones <Michael.Jones@microsoft.com>, "R= ichard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>
Subject:=C2=A0R= e: [Id-event] Use cases for multiple events per SET?

=C2=A0

I hope this answers your question.

=C2=A0

My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reason why not. = The question should be, what is the justification to make =E2=80=9Cevents= =E2=80=9D singular?

[richanna]The singular =E2=80=9Cevent=E2=80= =9D claim has clearer semantics and is easier to process. We should opt for= easier solutions unless there are use cases that require more complexity.[= /richanna]

=C2=A0

There are many reasons for multiple events in a SET.=C2=A0 Some are good, s= ome not so good. Some of the reasons...

=C2=A0

1.=C2=A0 Multiple event payloads expressing statements about largely the *s= ame*thing. For example, SCIM password reset AND RISC password reset.=C2=A0 = A RISC Event and an OpenBanking Event. Is one a complement to the other?=C2= =A0 Do they overlap or are they distinct? =C2=A0

[richanna]Copy/pasted from my earlier email:<= /span>

Why is it necessary or appropriate to include= these events in the same SET? They are likely being generated by different= systems at different times on the transmitter=E2=80=99s side, consumed by = different systems on the receiver=E2=80=99s side, and possibly being transmitted over different event streams. I know the la= tter would be the case for us, as a receiver. Even if it=E2=80=99s not, is = it burdensome to send these events separately? What value is gained in comb= ining them?

=C2=A0

Additionally, since the signature is over the= SET and not the event objects, Receivers independently route separate even= ts from a single token without either losing the ability to verify the auth= enticity of the event or sharing all information in the SET with every system handling any event in the token.[= /richanna]

=C2=A0

2.=C2=A0 Multiple events payloads expressing different statements about the= same transaction - RISC Password Reset and RISC Session Cancel
[richanna]Same as above[/richanna]<= /u>

3.=C2=A0 A new profile defines new event attributes to be added on to an ex= isting event type (a pure extension)=C2=A0
[richanna]I have suggested a way to support e= xtensions within an event body, multiple times now. If you see problems wit= h it, please point them out.[/richanna]

=C2=A0

I think it is quite valid to allow 1 and 3. =C2=A02 could be limited by spe= cific profiles like RISC if they want.

=C2=A0

I am not in agreement that making event singular simplifies anything. For o= ne is makes extensions complex (another nested JSON structure) and potentia= lly conflicting.=C2=A0
[richanna]

Ways that multiple-event SETs are more compli= cated:

  1. It results in a more complex structure for the single event use case, which= I think we all agree is the majority use case.
  2. Multiple-event SETs have ambiguous semantics. The presence of two events A = and B in the same SET could mean any of:
    1. They are related to the same logical event (i.e. the same thing as if they = were from different SETs that have a common txn).
    2. A is an extension of B.
    3. B is an extension of A.
    4. They are aliases for one another.
    5. They are not actually related to one another in any way.
      6. =
  1. Claim semantics become harder to define, as different profiles may want to = use the same claims in different ways.

=C2=A0

If the WG wants to block 1 and 2 above, then I believe we have to establish= an event registry to ensure new Event profiles do not overlap to eliminate= the need to express multiple events.

[richanna]I=E2=80=99m not sure what you mean = by this. Are you referring to event names? Those are already defined by the= spec to be URIs.[/richanna]

Phil

=C2=A0

Oracle Corporation, Identity Cloud Services Architect

@independentid

=C2=A0

On Oct 29, 2017, at 4:12 PM, Dick Hardt <dick.hardt@gmail.co= m> wrote:

=C2=A0

Phil:

=C2=A0

In your examples for having a plurality of events, you use the word "= ;may", which leads me to question if a plurality of events is really r= equired in SET.

=C2=A0

You posit that it will be difficult for a distributed system to correlate= multiple SETs with the same "txn", but the distributed system wi= ll certainly need to correlate events on the same subject -- correlating events on the same "txn" on the same subject seem= s fairly simple.

=C2=A0

I think that a receiver will need to correlate multiple SEts on the same = subject, so having multiple events in a SET is redundant, and adds complexi= ty with no clear benefit that I can see.

=C2=A0

An implementor may choose to send multiple SETs, or send a single SET wit= h multiple events, so a receiver will need to support both. I prefer we pic= k one way and minimize the code paths, and we will need to support correlating across multiple SETs, so that seems the b= est mechanism.

=C2=A0

Let me know if there is something I missed in my logic.<= /u>

=C2=A0

/Dick

=C2=A0

=C2=A0

On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer=C2=A0<yaronf.ietf@gmail.com>=C2=A0= wrote:

In that case, let's add text to that effect, e.g. we could add to the= definition of the "events" claim:

Profiling specifications SHOULD define the allowed event statements, and MA= Y restrict their number. For example, some profiles may require this claim = to contain only a single event statement.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Yaron

On 24/10/17 22:10, Mike Jones wrote:

I agree with much of Phil=E2=80=99s rationale here.

It=E2=80=99s fine for some profiles to say that the =E2=80=9Cevents=E2=80= =9D set must be a singleton.=C2=A0 That doesn=E2=80=99t have to be true for= all events.=C2=A0 I think things are fine as-is.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0-- Mike

*From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Phil Hunt
*Sent:* Monday, October 23, 2017 8:47 PM
*To:* Richard Backman, Annabelle <richanna@amazon.com<= /a>>
*Cc:* ID Events Mailing List <id-event@ietf.org><= br> *Subject:* Re: [Id-event] Use cases for multiple events per SET?

Annabelle,

I have a number of concerns with this proposal.

Profiling Independence / Keeping Event Payloads Independent

Indicating that extensions should be handled by profiles leads to more inte= r-operability issues and more importantly intrudes on the Event payload spa= ce by suggesting a sub-schema creates potential limitations and conflicts t= hat may add to complexity later on. The current format allows a parser to discover and unload one or more = JSON payloads which can each have independent structure.

General extensions

The proposal also rules out general purpose extensions not related to any s= pecific event. Given the emergence of items like GPRD, I would not want to = block the ability to add meta-data or other general purpose items. We can a= lso anticipate some delivery scenarios where additional data might be required. Even though there is no current p= lanned use, I see no good reason to rule this out.

Multiple Events From Different Families (vs. Multiple Events from a single = family like RISC)

In our RISC session we discussed expressing multiple distinct RISC events i= n one SET. The discussion was that only one RISC event at a time. We did no= t discuss other event profiles. I don=E2=80=99t see a reason to rule out mu= lti-events from different families at the SET level. Each profile is expressing slightly different things about the = same event.

I can forsee some cases where it is not clear which is the primary and whic= h is the extension.=C2=A0 There may not be a clear winner.

A couple of examples (these are necessarily real=E2=80=A6just possibilities= ):

* It is probably useful to be able to express simlar/overlapping events fro= m different SET profiles in one SET.=C2=A0 For example a Backchannel Logout= & a RISC session cancel event.

* SCIM may want to represent a single transaction as causing multiple state= changes in an event (e.g. a password change causes multiple effects). Havi= ng to chase down multiple events and correlate by =E2=80=9Ctxn=E2=80=9D wou= ld be challenging in a multi-threaded/multi-node delivery system.=C2=A0 =C2=A0The SCIM list has not discussed this, but I w= ould not want to block this capability.=C2=A0 IOW - Just because RISC does = not want to express multiple events does not make this true for other profi= les.

* We may wish to indicate a SCIM Password Reset was performed and a Logout/= session cancellation is expressed at the same time.=C2=A0 The events are re= lated but express different data.

Avoiding Confusion From Similar Events Originating from the Same Transactio= n

If events are sent separately, then more tracking of state (e.g. by txn) wo= uld be required to ensure similar events are not mistaken or handled as rep= eats. While txn provides useful audit analysis capability, I=E2=80=99m not = sure it can be used in live or near-real time systems given distributed multi-node, multi-threading architectures.<= br>
Previous Discussion

I note that I originally raised having an attribute to designate primary ev= ent attribute to alleviate your concern, but this was not accepted. See:
*=C2=A0https://www.ietf.org/mail-archive/web/id-event/cu= rrent/msg00406.html

*=C2=A0https://www.ietf.org/mail-archive/web/id-event/cu= rrent/msg00140.html

The consensus, at least as I interpreted it is up to the receiver to figure= this out based on the definitions it has for each event URI and the profil= es they represent. IOW - RISC is free to limit that only one RISC event be = expressed at a time.

Phil

Oracle Corporation, Identity Cloud Services Architect

@independentid

www.inde= pendentid.com=C2= =A0<http://www.independentid.com>

phil.hunt@oracle.com=C2=A0<mailto:phil.hunt@oracle.com= >

=C2=A0 =C2=A0 On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle
=C2=A0 =C2=A0 <= richanna@amazon.com=C2=A0<mailto:richa= nna@amazon.com>> wrote:

=C2=A0 =C2=A0 The current draft of the SET spec allows for expressing multi= ple
=C2=A0 =C2=A0 events within the same token, which introduces additional com= plexity
=C2=A0 =C2=A0 and room for ambiguous semantics. We=E2=80=99ve discussed thi= s in the OIDF
=C2=A0 =C2=A0 RISC working group and the current consensus there is that RI= SC will
=C2=A0 =C2=A0 require that RISC events must be the only event in the SET, h= aving
=C2=A0 =C2=A0 identified ways to clearly and easily support the handful of = use
=C2=A0 =C2=A0 cases for multiple events per token that people have raised. = With
=C2=A0 =C2=A0 that context in mind, I propose striking the definition of th= e
=C2=A0 =C2=A0 =E2=80=9Cevents=E2=80=9D claim from the Security Event Token = spec, and replacing it
=C2=A0 =C2=A0 with the following definition for an =E2=80=9Cevent=E2=80=9D = claim (singular):

=C2=A0 =C2=A0 event

=C2=A0 =C2=A0 A JSON object containing an "event_type" member who= se value is a URI
=C2=A0 =C2=A0 representing a type of event defined in a Profiling Specifica= tion.
=C2=A0 =C2=A0 The object MAY otherwise be empty, or MAY contain additional = members
=C2=A0 =C2=A0 as described by the Profiling Specification.

=C2=A0 =C2=A0 Here is the example SET from section 2.3, rewritten with this= change
=C2=A0 =C2=A0 mind:

=C2=A0 =C2=A0=C2=A0{
=C2=A0 =C2=A0 =C2=A0=C2=A0 "jti": "4d3559ec67504aaba65d= 40b0363faad8",

=C2=A0 =C2=A0 =C2=A0=C2=A0 "iat": 1458496404,

=C2=A0 =C2=A0 =C2=A0=C2=A0"iss": "https://scim.exa= mple.com=C2=A0<https://scim.example.com/>",

=C2=A0 =C2=A0 =C2=A0=C2=A0 "aud": [

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0"https://scim.example.com/Feeds/98d52461fa5bbc879593b77= 54",

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0"https://scim.example.com/Feeds/5d7604516b1d08641d7676e= e7"

=C2=A0 =C2=A0 =C2=A0=C2=A0 ],

=C2=A0 =C2=A0 =C2=A0=C2=A0 "event": {

=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 "event_type": "urn:ie= tf:params:scim:event:create",

=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 "ref": "<= span style=3D"color:purple">https://scim.example.com/Users/44f614= 2df96bd6ab61e7521d9",

=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 "attributes": ["id&qu= ot;, "name", "userName", "password", "em= ails"]

=C2=A0 =C2=A0 =C2=A0=C2=A0 }

=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 Does anyone in the working group have use cases for SETs that= cannot
=C2=A0 =C2=A0 be met by this proposed text? Within RISC, we identified thre= e use
=C2=A0 =C2=A0 cases, with solutions outlined below:

=C2=A0 =C2=A0 **

=C2=A0 =C2=A0 *Extensions*

=C2=A0 =C2=A0 Event extension mechanisms can be defined internal to the eve= nt
=C2=A0 =C2=A0 object. A simple approach would be to =C2=A0define an =E2=80= =9Cextensions=E2=80=9D member
=C2=A0 =C2=A0 that is a list of event objects (or set resembling the =E2=80= =9Cevents=E2=80=9D
=C2=A0 =C2=A0 claim as defined in the current spec). This has the advantage= of
=C2=A0 =C2=A0 making it clear in the data structure that there is a single = primary
=C2=A0 =C2=A0 event, with zero or more extensions. There is no room for con= fusion
=C2=A0 =C2=A0 over which event is primary, or if there is a primary event a= t all.
=C2=A0 =C2=A0 I would be fine with adding something like this to my propose= d text,
=C2=A0 =C2=A0 if there is consensus that it is broadly useful.

=C2=A0 =C2=A0 *Aliases*

=C2=A0 =C2=A0 This use case was brought up in the context of migrating clie= nts
=C2=A0 =C2=A0 from draft event names to standardized event names. In this c= ase,
=C2=A0 =C2=A0 the event transmitter can transmit two tokens for the logical= event,
=C2=A0 =C2=A0 one using the old name and another using the new name.

=C2=A0 =C2=A0 *Related Events*

=C2=A0 =C2=A0 The SET spec defines the txn claim as a means of correlating<= br> =C2=A0 =C2=A0 independent tokens that relate to the same logical event.

=C2=A0 =C2=A0 --=C2=A0=
=C2=A0 =C2=A0 Annabelle Richard Backman

=C2=A0 =C2=A0 Amazon =E2=80=93 Identity Services

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0=C2=A0Id-event@ietf.org=C2=A0<mailto:Id-event@ietf.org>=
=C2=A0 =C2=A0=C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__w= ww.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKu= gCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Ds5byBe5KANnGVuAb1mAupEG= oJn8XG5JIUUwWGFSibEc&s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58Z= Fd4eEZfgyoIY&e=3D



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event<= /span>


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event<= /span>



=C2=A0

--=C2=A0

Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I am working on!

=C2=A0

_______________________________________________
Id-event mailing list
Id-event@ietf.org

https://urldefense.proofpoint.co= m/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&a= mp;d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE= &r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DU-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=3DrvdrtI7rYNRA= nqZDltCwBAZVHKp-MJ20ui2nm46QSz0&e=3D

=C2=A0



=C2=A0

--

Subscribe to the HARDTWARE mail list to learn about projects I am working on!<= /u>



=C2=A0

--

Subscribe to the HARDTWARE mail list= to learn about projects I am working on!



=C2=A0

--

Subscribe to the HARDTWARE mail list to learn about projects I am working on!<= /u>




--
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
--94eb2c12553e839b08055cee8325-- From nobody Wed Nov 1 11:20:51 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88A513FA08 for ; Wed, 1 Nov 2017 11:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 t8NgF6dHGVfC for ; Wed, 1 Nov 2017 11:20:43 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0102.outbound.protection.outlook.com [104.47.34.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34DC813F5B1 for ; Wed, 1 Nov 2017 11:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6R5ZCSd3LLrAGS9DVmlg75JL502M60ISZl709+29DRE=; b=DyjSMvewpxWFEwMZirQMBrfcY2sSkv2DDO5ujOTx9oaAG/Du09Mi8FQ5ZWeq0bWcsIZSjrHtnziI6en/SzvfBX3rOKbma5bZOx8bAtH6MKdwBuzvj+QQidecgBr26hOJOdJ7dSjSjJT4JCRxHu2y4+VFduxTj2Ccal7aHAb6N3k= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.218.1; Wed, 1 Nov 2017 18:20:41 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0218.005; Wed, 1 Nov 2017 18:20:40 +0000 From: Mike Jones To: Dick Hardt CC: Yaron Sheffer , "Richard Backman, Annabelle" , ID Events Mailing List , "Phil Hunt (IDM)" Thread-Topic: [Id-event] Use cases for multiple events per SET? Thread-Index: AQHTTGwev6cV0D/tE06azbqzz7my9aLyXLkAgAEBjXCAB9BnAIAAT1IAgAAUagCAAQQ9AIAANauAgAAlNACAAAV2gIABcZJQgACUvYCAAADCcIAAA1kAgAASxcCAALLVgIAAG18A Date: Wed, 1 Nov 2017 18:20:40 +0000 Message-ID: References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.85.199] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0630; 6:9btwshHTTWaMj0pAkG2A0aAo/9deDPv0hydZlihrMNbHgu+b6QZxVdb3u/ZmgLsCHtjvqsGKr6X2NncXa0GYcvZ46CNMoghsdx+9SRIML0JtLWVr2AgrTVUomh3eI8BPLKCwk7UkO6fWpLsv0cWCSrXA1hX0CO0zvM+JWn+6Tczq8vuLGGoJv7Ay95LWL8Crf2Z19K+WV+JzNUdkhnZIDuIQX3/t2HxHRJfJCMObscyoY0B9YUUEAHJWOBedKCZdQlzyzrk1EBZliGWH81k8xcQPQ7Fd/l3zpBtolwMSWK9bfdrWWhPtPYOhAzRqPoqAJvhY6o9XGzDCBFAeR3taPomGSH74DP6aUnOfQnuVY0g=; 5:6J+6LcZdwvDzEzOqR+fMVYqf1BbdxaGirRPDE5Khssj0wMJ3WiS7NOn2rG5FEfKUlIJTtRlkgVHK57pGVw48PtZmW4oL3h+f7yCCelE5/p6wgpWyan5hMy6DhoIVwtTFei1AlIewt8aCCVKXnbDq0R1sGtvXgOLGSvCJj9OQZ+I=; 24:ahc3lQPBe8z8CGOXm3SESriHB0ezEgS+6DD1JbcXOsuv+4yUL1FhoRWiQTDhdfmNbZHa0WTo/PyDzC3Sg8cihEuHfaCEbOIqFkPILcGKSWE=; 7:x/4wiw2Nq8T5Ia4YiO+YuqR40S341UXAn5xD7e2n7NwG4AVyQDzvcuX84k1UIDRQndrF60WKIah7HwI2Xlg0+6uofCCrBVkAltZVyyTfGTxOMUdV/yxnEdLfDioQFaOIRoHvOtNyvdlaunxmOgnxjLJ3pM7JkZA0r7DhS8HB6wPiJjUyWXJMZPxTSJVbScQdRiLe9t1qLYH2iIbIIqmQEhpZwnX32aHnu0YqlP2alHxUD/a5x96/ncKn/HkAbUxr x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5587ac4b-b1ab-4d4c-837a-08d52155423a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:CY4PR21MB0630; x-ms-traffictypediagnostic: CY4PR21MB0630: x-exchange-antispam-report-test: UriScan:(10436049006162)(89211679590171)(192374486261705)(33061846794335)(100405760836317)(21748063052155)(5213294742642)(146099531331640)(47284530071512)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231020)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0630; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0630; x-forefront-prvs: 0478C23FE0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(47760400005)(51444003)(51914003)(199003)(189002)(24454002)(50986999)(551544002)(4326008)(6306002)(236005)(9686003)(54896002)(6246003)(53376002)(39060400002)(72206003)(53386004)(10290500003)(7736002)(55016002)(66066001)(74316002)(25786009)(966005)(97736004)(478600001)(575784001)(86612001)(86362001)(3846002)(10090500001)(99286004)(102836003)(790700001)(68736007)(16200700003)(8936002)(19609705001)(81166006)(53936002)(8990500004)(6116002)(53946003)(8676002)(6436002)(6916009)(229853002)(5660300001)(6506006)(2906002)(7696004)(3280700002)(2950100002)(81156014)(7066003)(316002)(54906003)(22452003)(77096006)(606006)(189998001)(54356999)(76176999)(2900100001)(561944003)(53546010)(93886005)(33656002)(101416001)(105586002)(14454004)(3660700001)(551934003)(106356001)(579004)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0630; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504123CF86035352776D8DCF55F0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5587ac4b-b1ab-4d4c-837a-08d52155423a X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2017 18:20:40.7985 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0630 Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 18:20:49 -0000 --_000_CY4PR21MB0504123CF86035352776D8DCF55F0CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjb21wbGV0ZWx5IGFncmVlIG9uIG1vdmluZyBjb21wbGV4aXR5IHRvIHRoZSBpc3N1ZXIgb3Zl ciB0aGUgcmVjaXBpZW50LiAgSW4gbXkgdmlldywgaXTigJlzIG1vcmUgY29tcGxleCBmb3IgcmVj aXBpZW50cyB0byBoYXZlIHRvIGNvcnJlbGF0ZSBhbmQgcHJvY2VzcyBhIHNlcXVlbmNlIG9mIG11 bHRpcGxlIFNFVHMgcHJvdmlkaW5nIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzYW1lIGxvZ2ljYWwg ZXZlbnQsIGFuZCB2YWxpZGF0ZSBOIHNpZ25hdHVyZXMsIHRoYW4gdG8gcmVjZWl2ZSBvbmUgU0VU IHdpdGggYWxsIHRoZSBhc3BlY3RzIG9mIHRoZSBsb2dpY2FsIGV2ZW50IGFzIOKAnGV2ZW50c+KA nSBmaWVsZHMsIHdpdGggbm8gY29ycmVsYXRpb24gb3ZlciB0aW1lIHRoZW4gcmVxdWlyZWQuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LSBNaWtlDQoNCkZyb206IERpY2sgSGFyZHQgW21haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbV0N ClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMSwgMjAxNyA5OjM5IEFNDQpUbzogTWlrZSBKb25l cyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9u Zi5pZXRmQGdtYWlsLmNvbT47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBh bWF6b24uY29tPjsgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc+OyBQ aGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0KU3ViamVjdDogUmU6IFtJZC1l dmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD8NCg0KWW91ciBjb21t ZW50cyBoaWdobGlnaHQgYSBjb3VwbGUgb2YgcG9pbnRzOg0KDQoxKSBUaGUgZXhhbXBsZSBpcyBo b3cgdG8gaGF2ZSBhIHByZWRlZmluZWQgZXh0ZW5zaW9uIHBvaW50IGZvciBleHRlbnNpb25zIG9m IGEgc3BlY2lmaWMgZXZlbnQsIGl0IGlzIG5vdCBob3cgdG8gYWRkIGFub3RoZXIgZXZlbnQuIE15 c2VsZiwgSSB0aGluayB0aGlzIGlzIG92ZXJseSBjb21wbGljYXRlZC4gRXZlbnRzIHNob3VsZCBi ZSBjb21wYXJhdGl2ZWx5IHN0YXRpYywgYW5kIGFzIHdpdGggbWFueSBvdGhlciBKU09OIGZvcm1h dHMsIHRoZSByZWNlaXZlciBzaG91bGQgaWdub3JlIHByb3BlcnRpZXMgaXQgZG9lcyBub3QgdW5k ZXJzdGFuZCwgd2hpY2ggbGV0J3MgbmV3IHByb3BlcnRpZXMgYmUgaW50cm9kdWNlZCBhcyBleHRl bnNpb25zLiBUaGVyZSBzaG91bGQgbm90IGJlIGFueSBjb25mbGljdCBhcyBleHRlbnNpb25zIHNo b3VsZCBvbmx5IGJlIGRvbmUgYnkgdGhlIHByb2ZpbGUgdGhhdCBjcmVhdGVkIHRoZSBldmVudCBm b3JtYXQgdG8gc3RhcnQgb2ZmIHdpdGguDQoNCjIpIEhhdmluZyBhbiBsdmFsdWUgYmUgYSBVUkkg aXMgbXVjaCBoYXJkZXIgdG8gY29kZSBhZ2FpbnN0LiBJJ20gbm90IHN1cmUgd2h5IE1hcml1cyBo YWQgdGhhdCBpbiBoaXMgZXhhbXBsZS4gUGVyIHRoZSBldmVudCwgdGhlIHR5cGUgb2YgdGhlIGV2 ZW50IGlzIHdlbGwgZGVmaW5lZCB3aXRoDQoNCiJldmVudF90eXBlIjogImh0dHBzOi8vZXhhbXBs ZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0IiwNCg0KMykgVGhpcyB0aHJlYWQgaXMg YWJvdXQgcmVhc29ucyBmb3IgbXVsdGlwbGUgZXZlbnRzIHRvIGJlIGNvbnRhaW5lZCBpbiBvbmUg c2V0LiBZb3VyIG1lbnRpb24gb2YgYW4gaXNzdWVyIG5vdCB3YW50aW5nIHRvIHNpZ24gc2VwYXJh dGUgZXZlbnRzIGFzIGEgcmVhc29uIHRvIGFsbG93IG11bHRpcGxlIGV2ZW50cy4gSSB0aGluayB3 ZSBoYXZlIGRlY2lkZWQgdGhhdCBnaXZlbiBhIHByZWZlcmVuY2UsIHdlIHdpbGwgcHVzaCBlZmZv cnQgdG8gdGhlIHRyYW5zbWl0dGVyIG92ZXIgdGhlIHJlY2VpdmVyIGFzIGluIG1hbnkgdXNlIGNh c2VzIHRoZXJlIGFyZSBtYW55IG1vcmUgcmVjZWl2ZXJzLiBHaXZlbiB0aGF0LCBpdCBpcyBtb3Jl IGNvbXBsZXggZm9yIGEgcmVjZWl2ZXIgdG8gaGF2ZSBkaWZmZXJlbnQgd2F5cyBvZiBtYW5hZ2lu ZyB0aGUgcmVjZWlwdCBvZiBtdWx0aXBsZSBldmVudHMgYXMgbm90IGFsbCBpc3N1ZXJzIHdpbGwg YnVuZGxlIHRoZSBldmVudHMsIHNvIGl0IGlzIHNpbXBsZXIgdG8gaGF2ZSBvbmx5IG9uZSBldmVu dCBwZXIgU0VULiBJbmNsdWRpbmcgdGhlIHNlcGFyYXRlIGV2ZW50cyB3aXRoIGEgVVJJIGFzIGFu IGx2YWx1ZSBpcyBjaGFsbGVuZ2luZyB0byBpbXBsZW1lbnQsIHNwZWFraW5nIGZyb20gZXhwZXJp ZW5jZS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCk9uIFR1ZSwgT2N0IDMxLCAyMDE3IGF0IDEx OjA1IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KTWFyaXVz4oCZIHByb3Bvc2VkIHN5 bnRheCwgcGFzdGVkIGluIGJlbG93LCBoYXMgZXhhY3RseSB0aGlzIGNoYXJhY3RlcmlzdGljLiAg VGhlIHdheSBJIHNlZSBpdCwgaGlzIHByb3Bvc2FsIGVzc2VudGlhbGx5IGhhcyBhIHByaW1hcnkg cGFzc3dvcmRSZXNldCBldmVudCBhbmQgYSBzZWNvbmRhcnkgcGFzc3dvcmRSZXNldEV4dCBkYXRh IHN0cnVjdHVyZSwgd2hpY2ggY291bGQgaGF2ZSBiZWVuIHNpbXBseSBhbm90aGVyIGV2ZW50IHZh bHVlIGluIHRoZSBjdXJyZW50IGRyYWZ0Lg0KDQpUaGlzIGJyZWFraW5nIGNoYW5nZSBtYWtlcyB0 aGUgZGF0YSBzdHJ1Y3R1cmVzIG1vcmUgY29tcGxpY2F0ZWQgLSBub3QgbGVzcy4gIEFuZCBpdCBt YWtlcyB0aGluZ3MgdGhhdCB1c2VkIHRvIGJlIHBvc3NpYmxlIGltcG9zc2libGUsIHJlZHVjaW5n IGZsZXhpYmlsaXR5IHRvIHRob3NlIHdobyB3b3VsZCB1c2UgdGhlIHNwZWMuDQoNClRoZXNlIHNl ZW0gbGlrZSBiYWQgdHJhZGVvZmZzIHRvIG1lLg0KDQp7DQogICJqdGkiOiAiM2QwYzNjZjc5NzU4 NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KICAiaWF0IjogMTQ1ODQ5NjAyNSwNCiAgImlzcyI6ICJo dHRwczovL3NjaW0uZXhhbXBsZS5jb208aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLz4iLA0KICAi YXVkIjogWw0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTVi YmM4Nzk1OTNiNzc1NCIsDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2 MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Ig0KICAgXSwNCiAgICJldmVudF90eXBlIjogImh0dHBzOi8v ZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0IiwNCiAgICJldmVudCI6IHsN CiAgICAgICAgICJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLA0KICAgICAgICAgImV4 dGVuc2lvbnMiOiB7DQogICAgICAgICAgICJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQv cGFzc3dvcmRSZXNldEV4dOKAnTogew0KICAgICAgICAgICAgICJyZXNldEF0dGVtcHRzIjo1LA0K ICAgICAgICAgICB9DQogICAgICAgICB9DQogICAgICAgfQ0KfQ0KDQpJbiBwYXJ0aWN1bGFyLCBp dCBtYWtlcyBpdCBpbXBvc3NpYmxlIHRvIHNpZ24gbXVsdGlwbGUgcmVsYXRlZCBldmVudHMgc2hh cmluZyBhIGNvbW1vbiBjbGFpbXMgc2NoZW1hIHdpdGggYSBzaW5nbGUgc2lnbmF0dXJlIGJ5IHRo ZSBpc3N1ZXIuICBJdCBmb3JjZXMgdGhlIGlzc3VlciB0byBkbyB0aGUgZXh0cmEgd29yayBvZiBz aWduaW5nIGVhY2ggb2YgdGhlIHJlbGF0ZWQgZXZlbnRzIChvciBmYWNldHMgb2YgdGhlIHNhbWUg bG9naWNhbCBldmVudCkgaW5kaXZpZHVhbGx5IGFuZCBmb3JjZXMgdGhlIHJlY2lwaWVudHMgdG8g ZG8gdGhlIGV4dHJhIHdvcmsgb2YgY2hlY2tpbmcgYWxsIHRob3NlIHVubmVjZXNzYXJ5IHNpZ25h dHVyZXMuDQoNCk5vdCBldmVyeSBwcm9maWxlIHdpbGwgZXZlciBoYXZlIG11bHRpcGxlIGtleXMg aW4gdGhlIOKAnGV2ZW50c+KAnSBzZXQgYnV0IHRoZXJl4oCZcyBhYnNvbHV0ZWx5IG5vIHJlYXNv biB0byBwcmVjbHVkZSBpdC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSWQtZXZlbnQgW21haWx0bzppZC1l dmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPl0g T24gQmVoYWxmIE9mIERpY2sgSGFyZHQNClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMzEsIDIwMTcg OTo1MiBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCkNjOiBZYXJvbiBTaGVmZmVyIDx5YXJv bmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+OyBSaWNoYXJk IEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFA YW1hem9uLmNvbT4+OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxt YWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+PjsgUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3Jh Y2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pg0KDQpTdWJqZWN0OiBSZTogW0lk LWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPw0KDQpQbGVhc2Ug ZGlyZWN0IG1lIHRvIGEgcHJvcG9zYWwgdGhhdCBoYXMgYSAicHJpbWFyeSIgYW5kICJzZWNvbmRh cnkiIGV2ZW50cy4gSSBhZ3JlZSB0aGF0IGlzIHVuZGVzaXJhYmxlLiBJIHdvdWxkIGFsc28gZW5j b3VyYWdlIHRvIGVuZ2FnZSBpbiB0aGUgZGlzY3Vzc2lvbnMgc28gdGhhdCB3ZSBjYW4gZHJpdmUg Y2xhcml0eSBhbmQgc2ltcGxpY2l0eS4NCg0KSSB0aGluayB0aGUgcHJvcG9zYWwgaXMgdGhhdCB0 aGVyZSBpcyBvbmUgZXZlbnQgcGVyIFNFVC4NCg0KSSB0aGluayBoYXZpbmcgbW9yZSB0aGFuIG9u ZSBldmVudCBwZXIgU0VUIGFkZHMgY29tcGxleGl0eSBhcyBhIHJlY2VpdmVyIG11c3QgZGVhbCB3 aXRoIHJlY2VpdmluZyBjb3JyZWxhdGVkIGV2ZW50cyBpbiBvbmUgU0VUIGFzIHdlbGwgYXMgY29y cmVsYXRlZCBldmVudHMgaW4gdGhlIHNhbWUgU0VULg0KDQovRGljaw0KDQpPbiBUdWUsIE9jdCAz MSwgMjAxNyBhdCA5OjQyIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSSBoZWFyIHlv dSBvbiB0aGUgZmFjdCB0aGF0IGRpZmZlcmVudCBwZW9wbGUgaGF2ZSBqb2luZWQgdGhlIGVmZm9y dCBhdCBkaWZmZXJlbnQgdGltZXMuICBUaGF04oCZcyBhIG5vcm1hbCBwcm9jZXNzIGFzIGFuIGVm Zm9ydCBidWlsZHMgbW9tZW50dW0uICBJIGdldCB0aGF0IG5vdCBldmVyeW9uZSB3YXMgdGhlcmUg d2hlbiBwcmV2aW91cyBjb25zZW5zdXMgY2FsbHMgd2VyZSB0YWtlbi4NCg0KSSBzaG91bGQgbm90 ZSB0aGF0IEkgaGF2ZSBzcGVjaWZpYyB0ZWNobmljYWwgb2JqZWN0aW9ucyB0byB0aGUgc3BlY2lm aWMgcHJvcG9zZWQgY2hhbmdlcyBiZWluZyBkaXNjdXNzZWQgYXMgd2VsbC4gIEN1cnJlbnRseSBh bGwgZXZlbnRzIGluIHRoZSBzZXQgaGF2ZSB0aGUgc2FtZSBzeW50YXguICBUaGUgcHJvcG9zYWxz LCBhcyBJIHVuZGVyc3RhbmQgdGhlbSwgcmV2ZXJ0IHVzIHRvIGEgc3RhdGUgd2hlcmUgdGhlcmXi gJlzIGEg4oCccHJpbWFyeeKAnSBhbmQg4oCcc2Vjb25kYXJ54oCdIGV2ZW50cywgd2l0aCBkaWZm ZXJlbnQgc3ludGF4IGZvciB0aGUgdHdvIGNsYXNzZXMuICBUaGF04oCZcyBuZWVkbGVzc2x5IG1v cmUgY29tcGxpY2F0ZWQsIGFkZGluZyBubyBhY3R1YWwgdmFsdWUuDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQoNCkZyb206IERpY2sgSGFyZHQgW21haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86 ZGljay5oYXJkdEBnbWFpbC5jb20+XQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAzMSwgMjAxNyA5 OjM3IFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0 bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFBoaWwgSHVudCAoSURNKSA8cGhp bC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj47IFlhcm9uIFNo ZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29t Pj47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0 bzpyaWNoYW5uYUBhbWF6b24uY29tPj47IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50 QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+DQoNClN1YmplY3Q6IFJlOiBbSWQt ZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQ/DQoNCk1pa2UNCg0K QXMgeW91IHdlbGwga25vdywgbWFueSBwZW9wbGUgaW4gYSBXRyBkb24ndCBsb29rIGNsb3NlbHkg YXQgYSBzcGVjaWZpY2F0aW9uIHVudGlsIGxhc3QgY2FsbCBpcyBtYWRlLiBBZGRpdGlvbmFsbHks IHdlIGFyZSBjb21pbmcgdXAgb24gb25seSB0aGUgM3JkIFdHIG1lZXRpbmcuIFRoZSBXRyBoYXMg bm90IGV4aXN0ZWQgZm9yIHZlcnkgbG9uZy4gV2hpbGUgc29tZSBvZiB0aGUgcGFydGljaXBhbnRz IGhhdmUgYmVlbiB3b3JraW5nIG9uIHRoaXMgZm9yIGEgd2hpbGUsIG1hbnkgaGF2ZSBub3QsIGFu ZCB3ZSBhcmUgbG9va2luZyBmb3IgY29uc2Vuc3VzIGFjcm9zcyB0aGUgV0cuDQoNClNpbmNlIFNl Y0V2ZW50IGlzIGEgZnJhbWV3b3JrIHRoYXQgd2UgZXhwZWN0IHRvIGJlIHByb2ZpbGVkLCBJIGZl ZWwgaXQgaXMgaW1wb3J0YW50IHRvIGVuc3VyZSB0aGF0IFNlY0V2ZW50IHNwZWNpZmljYXRpb25z IGFyZSBlYXN5IGZvciBhIHZhcmlldHkgb2YgcHJvZmlsZXMgdG8gYWRvcHQsIGFuZCB0aGF0IHRo ZSBzZW1hbnRpY3MgbWFrZSBzZW5zZS4gSSBhbHNvIHRoaW5rIHRoYXQgcHJvcGVydGllcyB0aGF0 IGFyZSBzcGVjaWZpYyB0byBhIHByb2ZpbGUgc2hvdWxkIGJlIGxlZnQgdG8gdGhhdCBwcm9maWxl IGFuZCBub3QgYmUgaW5jbHVkZWQgaW4gU2VjRXZlbnQuDQoNClNpbmNlIHRoaXMgaXMgYSBmcmFt ZXdvcmssIGl0IGlzIGV4cGVjdGVkIHRoYXQgYXMgZGlmZmVyZW50IGdyb3VwcyBwcm9maWxlIGl0 LCB0aGVyZSB3aWxsIGJlIGFkZGl0aW9uYWwgZmVlZGJhY2suDQoNClNwZWNpZmljYWxseSwgYXMg YSBwYXJ0aWNpcGFudCBpbiB0aGUgUklTQyBwcm9maWxlIG9mIFNFVCwgYSBudW1iZXIgb2YgaXNz dWVzIGluIFNFVCBoYXZlIHN1cmZhY2VkIGFzIHRoZSBSSVNDIFdHIGhhcyBsb29rZWQgYXQgaG93 IHRvIHVzZSB0aGUgU0VULg0KDQpBcyBmb3IgU0VUIGJlaW5nIHN0YWJsZSBmb3Igb3ZlciBhIHll YXIsIHRoZXJlIGhhdmUgYmVlbiBhIG51bWJlciBvZiBjaGFuZ2VzIHRvIFNFVCBzaW5jZSB0aGVu LiBJIGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgd2FzIGNvbnNlbnN1cy4gQmVmb3JlIHRoZSBXRyB3 YXMgZm9ybWVkLCBJIGFuZCBzZXZlcmFsIG90aGVycyBoYWQgZXhwcmVzc2VkIGNvbmNlcm4gb24g dGhlIGRlc2lnbiBvZiBTRVQgd2hlbiBQaGlsIHByZXNlbnRlZCBpdCBhdCBhbiBJSVcgc2Vzc2lv bi4NCg0KQXMgdG8gdGFraW5nIGFub3RoZXIgeWVhciwgSSBhbSBob3BlZnVsIHdlIGNhbiByZXNv bHZlIHRoZSByZW1haW5pbmcgaXNzdWVzIGluIFNFVCBhbmQgcHVibGlzaCBhIG5ldyBkcmFmdCBm b3IgbGFzdCBjYWxsLiBJIGRvIG5vdCB0aGluayB3ZSB3aWxsIG5lZWQgdG8gd2FpdCBmb3IgYW5v dGhlciBXRyBtZWV0aW5nIHRvIGFzayBmb3IgbGFzdCBjYWxsLg0KDQpXZSBhbHNvIGhhdmUgYSBu dW1iZXIgb2Ygb3RoZXIgZG9jdW1lbnRzIHRoYXQgYXJlIG5vdCBpbiBsYXN0IGNhbGwsIGFuZCB3 ZSBkb24ndCBoYXZlIGEgV0cgYWRvcHRlZCBkcmFmdCB5ZXQgZm9yIG1hbmFnZW1lbnQuIFNvIHRo ZXJlIGFyZSBzdGlsbCBhIG51bWJlciBvZiBkb2N1bWVudHMgdG8gd29yayB0aHJvdWdoIGJlZm9y ZSB3ZSBoYXZlIGFsbCB0aGUgYml0cyBmb3Igc29tZW9uZSB0byB3b3JrIHdpdGguDQoNCkkgZG8g dGhpbmsgd2UgaGF2ZSBiZWVuIG1ha2luZyBnb29kIHByb2dyZXNzIHNpbmNlIHRoZSBsYXN0IElF VEYgbWVldGluZywgYW5kIEkgYW0gaG9wZWZ1bCB3ZSBjYW4ga2VlcCB1cCB0aGlzIG1vbWVudHVt IGFuZCBmaW5hbGl6ZSBhbGwgdGhlIGRvY3VtZW50cyBpbiBhIHRpbWVseSBtYW5uZXIuDQoNCi9E aWNrDQoNCg0KT24gVHVlLCBPY3QgMzEsIDIwMTcgYXQgMTI6NDggUE0sIE1pa2UgSm9uZXMgPE1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPj4gd3JvdGU6DQpJdOKAmXMgaGFyZCBmb3IgbWUgdG8gZXZlbiBleHByZXNzIG15IGxldmVs IG9mIGZydXN0cmF0aW9uIHdpdGggdGhlIHJlY2VudCBhdHRlbXB0cyB0byBvbmNlIGFnYWluIHJl ZGVzaWduIHRoZSBTZWNFdmVudCBUb2tlbiBzcGVjLiAgV2XigJl2ZSBiZWVuIGF0IHRoaXMgZm9y IG11bHRpcGxlIHllYXJzIGJlY2F1c2UgcGVvcGxlIGtlZXAgdHJ5aW5nIHRvIHJldmlzaXQgZGVj aXNpb25zIHRoYXQgd2VyZSBsb25nIGFnbyBtYWRlIGJ5IGNvbnNlbnN1cy4gIEl04oCZcyBiZWVu IHN0YWJsZSBmb3Igb3ZlciBhIHllYXIgYW5kIHRoZSBtYWpvcml0eSBvZiBXR0xDIHJlc3BvbmRl bnRzIHNhaWQgc29tZSB2YXJpYW50IG9mIOKAnFdvcmtzIGZvciBtZSDigJMgc2hpcCBpdCHigJ0N Cg0KVGhlcmXigJlzIG5vdCBzdWZmaWNpZW50IGp1c3RpZmljYXRpb24gdG8gdHJ5IHRvIHVuZG8g Y29uc2Vuc3VzIHBvc2l0aW9ucyB0aGF0IGhhdmUgYmVlbiBkZWJhdGVkIGFuZCBhZmZpcm1lZCBv dmVyIGFuZCBvdmVyLiAgQ291bnRlbmFuY2luZyB3aG9sZXNhbGUgY2hhbmdlcyBhdCB0aGlzIGxh dGUgZGF0ZSBpcyBjb3VudGVycHJvZHVjdGl2ZSBpbiB0aGUgZXh0cmVtZSENCg0KSXTigJlzIGZh ciBiZXR0ZXIgdGhhbiBnb29kIGVub3VnaCBhcy1pcy4gIEluIG15IGV4cGVyaWVuY2UsIGlmIHdl IHN0YXJ0IHJlZGVzaWduaW5nIGl0LCBpdCB3aWxsIHJlc3VsdCBpbiBhbm90aGVyIHllYXLigJlz IGRlbGF5LiAgSXQgZG9lcyBzb21ldGhpbmcgc2ltcGxlIGFuZCB1c2VmdWwuICBQbGVhc2UsIGxl dOKAmXMganVzdCBzaGlwIGl0LCBzbyBwZW9wbGUgY2FuIHJlbHkgb24gaXQuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN CkZyb206IFBoaWwgSHVudCAoSURNKSBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT5dDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMzAsIDIwMTcg Mjo0MiBQTQ0KVG86IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbT4+DQpDYzogWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwu Y29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PjsgUmljaGFyZCBCYWNrbWFuLCBBbm5h YmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+Pjsg TWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20+PjsgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0 Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj4NCg0KU3ViamVjdDogUmU6IFtJZC1ldmVu dF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD8NCg0KSW5saW5lLi4uDQoN ClBoaWwNCg0KT24gT2N0IDMwLCAyMDE3LCBhdCAyOjIyIFBNLCBEaWNrIEhhcmR0IDxkaWNrLmhh cmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCkhpIFBo aWwNCg0KQ29ycmVjdCBtZSBpZiBJIGFtIG1pc3VuZGVyc3RhbmRpbmcsIGJ1dCB0aGVyZSBpcyBh IFJJU0MgcHJvZmlsZSBldmVudA0KDQoNCg0KImh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2Vj ZXZlbnQvcmlzYy9ldmVudC10eXBlLzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVuaWQubmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQt MkR0eXBlXy0yNTVDJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVC NjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEm bT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JnM9MjVsMDlzSDhZ VjQyeHpnVS1DWFNnOHhIOXR2eURKejQwdENSakZhbGhrdyZlPT5hY2NvdW50LWNyZWRlbnRpYWwt Y2hhbmdlLXJlcXVpcmVk4oCdDQoNCg0KYW5kIGFuIFNDSU0gcHJvZmlsZSBldmVudA0KDQoNCiJo dHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dOKAnQ0KDQoNCkkn bSBzdWdnZXN0aW5nIHRoYXQgdHdvIGRpZmZlcmVudCBldmVudHMgd291bGQgYmUgc2VudC4gRW1i ZWRkaW5nIG9uZSBpbiB0aGUgb3RoZXIgZG9lcyBub3QgbWFrZSBzZW5zZS4NCjxwaD5JdCBpcyBh IGh5cG90aGV0aWNhbCBleGFtcGxlLiBKdXN0IGJlY2F1c2UgeW91IGRpc2FncmVlIG9uIHRoaXMg ZG9lcyBub3QgbWVhbiBvdGhlcnMgYXJlIG5vdCB2YWxpZC4NCg0KSSBqdXN0IHBpY2tlZCBvdmVy bGFwcGluZyBwcm9wb3NhbHMgdGhhdCBoYXZlIGRpZmZlcmVudCBtZWFuaW5nIChidXQgbm90IHRo ZSBzYW1lKSB0byBpbGx1c3RyYXRlIHRoZSBkaWZmZXJlbmNlIGZyb20gaXNzdWluZyBhIHNpbmds ZSBzZXQgd2l0aCBkaWZmZXJlbnQgZXZlbnRzLg0KDQpBcyBJIGhhdmUgc3RhdGVkIHRoaXMgaXMg dmVyeSBkaWZmZXJlbnQgZnJvbSBhc3NlcnRpbmcgbXVsdGlwbGUgZGlzdGluY3QgZXZlbnRzIGlu IG9uZSBTRVQuDQoNCkFsc28sIEkgdGhpbmsgaXQgaXMgc2ltcGxlciB0byBoYXZlIGV2ZW50X3R5 cGUgYmUgYXQgdGhlIHNhbWUgbGV2ZWwgYXMgZXZlbnQNCg0KPHBoPm1heSBiZS4gSSB3YXMgd29y a2luZyBmcm9tIEFubmFiZWxsZSdzIHByb3Bvc2VkIGZvcm1hdC4NCg0Kew0KICAianRpIjogIjNk MGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwIiwNCiAgImlhdCI6IDE0NTg0OTYwMjUsDQog ICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwNCiAgImF1ZCI6IFsNCiAgICAiaHR0 cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLA0K ICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3 NmVlNyINCiAgIF0sDQogICAiZXZlbnRfdHlwZSI6ICJodHRwczovL2V4YW1wbGUuY29tL3NjaW0v ZXZlbnQvcGFzc3dvcmRSZXNldEV4dCIsDQogICAiZXZlbnQiOiB7DQogICAgICAgICAiaWQiOiI0 NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5IiwNCiAgICAgICAgICJyZXNldEF0dGVtcHRzIjo1DQog ICAgICAgfQ0KfQ0KDQp7DQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdk MzAiLA0KICAiaWF0IjogMTQ1ODQ5NjAyNSwNCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBs ZS5jb20iLA0KICAiYXVkIjogWw0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMv OThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNv bS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Ig0KICAgXSwNCiAgICJldmVudF90eXBl IjogImh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL2Fj Y291bnQtY3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9y aXNjX2V2ZW50LTJEdHlwZV9hY2NvdW50LTJEY3JlZGVudGlhbC0yRGNoYW5nZS0yRHJlcXVpcmVk JmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZy PW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1peVZuclptcjlf dUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JnM9blF5OWV6UFJqREdkdlJUQ2FpRHRp NE9IZWxIM0RLZ1VDVEtqRjJHUS1zbyZlPT4iLA0KICAgImV2ZW50Ijogew0KICAgICAgIOKAnHN1 YuKAnTrigJ03Mzc1NjI2QTY1NjM3NOKAnSwNCiAgICAgICDigJxpc3PigJ06Imh0dHBzOi8vaWRw LmV4YW1wbGUuY29tLyINCiAgICAgICB9DQp9DQoNCg0KDQoNCg0KT24gTW9uLCBPY3QgMzAsIDIw MTcgYXQgMTI6MDkgUE0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQpBbm5hYmVsbGUvRGljaywNCg0KVGhhbmtzIGZv ciB0aGUgY29tbWVudHMuIEkgdGhpbmsgd2UgbmVlZCB0byBleGFtaW5lIHRoZSBjb25zZXF1ZW5j ZXMgb2YgdGhlIHByb3Bvc2FsIGluIEpTT04uDQoNCkFzIEkgc3RhdGVkLCB3aGF0IGNhdXNlcyBt b3N0IG9mIHRoZSBpc3N1ZSBpcyB0aGUgcHJvcG9zZWQgZXh0ZW5zaW9uIG1lY2hhbmlzbSBpbiB0 aGUgcGF5bG9hZCAocG9zc2libHkgdXNpbmcgZXZlbnRzIGluIGEgcmVjdXJzaXZlIHdheSkuIERv ZXMgaXQgZm9sbG93IHRoZSBvbGQgZm9ybWF0IG9yIHRoZSBuZXc/DQoNCkxldOKAmXMgIGNvbnNp ZGVyIGEgdXNlIGNhc2Ugd2hlcmUgd2UgaGF2ZSBhbiBpZGVudGl0eSBtYW5hZ2VtZW50IHN5c3Rl bSB0aGF0IHVzZXMgU0NJTSwgYnV0IHRoZSBTQ0lNIHN5c3RlbSBpcyBhbHNvIHRoZSB1bmRlcmx5 aW5nIGRhdGEgc3RvcmUgZm9yIENvbm5lY3QuICBBIFBhc3N3b3JkIHJlc2V0IG1pZ2h0IGdlbmVy YXRlIHRoZSBmb2xsb3dpbmcgZXZlbnQgd2hpY2ggaGFzIGFuIGV4dGVuc2lvbiAoY29udmV5aW5n IHJlc2V0IGNvdW50KSBBTkQgb3ZlcmxhcHBpbmcgc3RhdGVtZW50IGZyb20gUklTQy4gIEJPVEgg b2Ygd2hpY2ggbWlnaHQgYmUgaW1wb3J0YW50IHRvIGEgc2ltaWxhciByZWNlaXZlciB1c2luZyBT Q0lNIGFuZCBPSURDLg0KDQpUaGUgMDMgc3BlYyBjdXJyZW50bHkgd291bGQgYWxsb3c6DQoNCg0K ew0KDQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KDQogICJp YXQiOiAxNDU4NDk2MDI1LA0KDQogICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwN Cg0KICAiYXVkIjogWw0KDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1 MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiwNCg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20v RmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyINCg0KICAgXSwNCg0KICAgImV2ZW50cyI6 IHsNCg0KICAgICAidXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldCI6DQoN CiAgICAgICB7ICJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkifSwNCg0KICAgICAiaHR0 cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiOg0KDQogICAgICAg eyAicmVzZXRBdHRlbXB0cyI6NX0sDQoNCiAgICAgImh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQv c2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL1w8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2 ZW50LTJEdHlwZV8tMjU1QyZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJ ck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRL Wk5BJm09aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZzPTI1bDA5 c0g4WVY0Mnh6Z1UtQ1hTZzh4SDl0dnlESno0MHRDUmpGYWxoa3cmZT0+DQogICAgICAgYWNjb3Vu dC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZCI6IHsNCg0KICAgICAgICAg4oCcc3Vi4oCdOuKA nTczNzU2MjZBNjU2Mzc04oCdLA0KDQogICAgICAgICDigJxpc3PigJ06Imh0dHBzOi8vaWRwLmV4 YW1wbGUuY29tLyINCg0KICAgICAgIH0NCg0KICB9DQoNCn0NCg0KDQoNCkluIHRoZSBhYm92ZSAt IGVhY2ggcGF5bG9hZCBpcyBhIOKAmHBlZXInIGFuZCBpc3N1ZWQgd2l0aG91dCBwcmVmZXJlbmNl IGJ5IHRoZSB0cmFuc21pdHRlci4gVGhlIHJlY2VpdmVyIGNhbiBhc3NpZ24gcHJpb3JpdHkgaW4g aXRzIG93biBjb250ZXh0IGlmIHRoYXQgbWF0dGVycy4NCg0KDQoNClRoZSBuZXcgcHJvcG9zYWw6 DQoNCg0KDQp7DQoNCiAgImp0aSI6ICIzZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCIs DQoNCiAgImlhdCI6IDE0NTg0OTYwMjUsDQoNCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBs ZS5jb20iLA0KDQogICJhdWQiOiBbDQoNCiAgICAiaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0Zl ZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLA0KDQogICAgImh0dHBzOi8vamh1Yi5leGFt cGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Ig0KDQogICBdLA0KDQogICAi ZXZlbnQiOiB7DQoNCiAgICAg4oCcZXZlbnRfdHlwZeKAnToidXJuOmlldGY6cGFyYW1zOnNjaW06 ZXZlbnQ6cGFzc3dvcmRSZXNldOKAnSwNCg0KICAgICAiaWQiOuKAnTQ0ZjYxNDJkZjk2YmQ2YWI2 MWU3NTIxZDnigJ0sDQoNCiAgICAg4oCcZXZlbnRz4oCdOnsNCg0KICAgICAtPm5vdGUg4oCmaXMg dGhpcyB0aGUgb2xkIG9yIG5ldyBzdHJ1Y3R1cmU/IDwtDQoNCiAgICAgICAiaHR0cHM6Ly9leGFt cGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiOg0KDQogICAgICAgICB7ICJyZXNl dEF0dGVtcHRzIjo1fSwNCg0KICAgICAgICJodHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0L3NlY2V2 ZW50L3Jpc2MvZXZlbnQtdHlwZS9cPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZlbnRfcmlzY19ldmVudC0y RHR5cGVfLTI1NUMmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2 NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZt PWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmcz0yNWwwOXNIOFlW NDJ4emdVLUNYU2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmU9Pg0KICAgICAgICAgYWNjb3VudC1j cmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZCI6IHsNCg0KICAgICAgICAg4oCcc3Vi4oCdOuKAnTcz NzU2MjZBNjU2Mzc04oCdLA0KDQogICAgICAgICDigJxpc3PigJ06Imh0dHBzOi8vaWRwLmV4YW1w bGUuY29tLyINCg0KICAgICAgIH0NCg0KICAgICB9DQoNCiAgIH0NCg0KfQ0KDQoNCg0KSW4gdGhl IGFib3ZlLCBzdWItZXZlbnRzIG9yIGV4dGVuc2lvbnMgaGF2ZSBhIGRpZmZlcmVudCBmb3JtYXQu IFRoZSBzYW1lIGNvbXBsYWludCBhYm91dCB0aGUgb3JpZ2luYWwgc3RhbmRzLg0KDQoNCg0KKk9S KiAoaWYgdGhlIHJlY2VpdmVyIGNhcmVzIGFib3V0IFJJU0MgbW9yZSkuICBOb3RlIHRoYXQgdGhp cyBsZWFkcyB0byBhIHRyaXBsZSBuZXN0ZWQgc3RydWN0dXJlLg0KDQoNCg0Kew0KDQogICJqdGki OiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KDQogICJpYXQiOiAxNDU4NDk2 MDI1LA0KDQogICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwNCg0KICAiYXVkIjog Ww0KDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3 OTU5M2I3NzU0IiwNCg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0 NTE2YjFkMDg2NDFkNzY3NmVlNyINCg0KICAgXSwNCg0KICAgImV2ZW50Ijogew0KDQogICAgIOKA nGV2ZW50X3R5cGXigJ06Imh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9l dmVudC10eXBlL1w8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV8tMjU1 QyZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUm cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09aXlWbnJabXI5 X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZzPTI1bDA5c0g4WVY0Mnh6Z1UtQ1hT Zzh4SDl0dnlESno0MHRDUmpGYWxoa3cmZT0+DQoNCiAgICAgICAgICAgICBhY2NvdW50LWNyZWRl bnRpYWwtY2hhbmdlLXJlcXVpcmVk4oCdLA0KDQogICAgICDigJxzdWLigJ064oCdNzM3NTYyNkE2 NTYzNzTigJ0sDQoNCiAgICAgIOKAnGlzc+KAnToiaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20v4oCc LA0KDQogICAgICDigJxldmVudHPigJ06ew0KDQogICAgICAgICJ1cm46aWV0ZjpwYXJhbXM6c2Np bTpldmVudDpwYXNzd29yZFJlc2V0IjoNCg0KICAgICAgICB7DQoNCiAgICAgICAgICAiaWQiOuKA nTQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDnigJ0sDQoNCiAgICAgICAgICDigJxldmVudHPigJ06 ew0KDQogICAgICAgICAgICAgImh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29y ZFJlc2V0RXh0IjoNCg0KICAgICAgICAgICAgICAgeyAicmVzZXRBdHRlbXB0cyI6NX0sDQoNCiAg ICAgICAgICB9DQoNCiAgICAgICAgfQ0KDQogICAgICB9DQoNCiAgIH0NCg0KfQ0KDQoNCg0KSW4g dGhlIGFib3ZlLCB0aGUgZXh0ZW5zaW9uIGlzIHBsYWNlZCBpbnNpZGUgdGhlIGV2ZW50IGl0IGV4 dGVuZHMuIEl0IGZvbGxvd3MgdGhlIG9sZCBmb3JtYXQgKG9yIHNob3VsZCBpdCBmb2xsb3cgdGhl IG5ldz8pDQoNCipPUiogRm9sbG93aW5nIHRoZSB0b3AgbGF5ZXIgcGF0dGVybiBvZiBzaW5ndWxh ciBldmVudCAgTm90ZSB0aGF0IHRoaXMgbGVhZHMgdG8gYSB0cmlwbGUgbmVzdGVkIHN0cnVjdHVy ZS4NCg0KDQoNCnsNCg0KICAianRpIjogIjNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMw IiwNCg0KICAiaWF0IjogMTQ1ODQ5NjAyNSwNCg0KICAiaXNzIjogImh0dHBzOi8vc2NpbS5leGFt cGxlLmNvbSIsDQoNCiAgImF1ZCI6IFsNCg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20v RmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsDQoNCiAgICAiaHR0cHM6Ly9qaHViLmV4 YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciDQoNCiAgIF0sDQoNCiAg ICJldmVudCI6IHsNCg0KICAgICDigJxldmVudF90eXBl4oCdOiJodHRwOi8vc2NoZW1hcy5vcGVu aWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS9cPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZlbnRf cmlzY19ldmVudC0yRHR5cGVfLTI1NUMmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBa aDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkx YUxjTE40S1pOQSZtPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cm cz0yNWwwOXNIOFlWNDJ4emdVLUNYU2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmU9Pg0KDQogICAg ICAgICAgICAgYWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZOKAnSwNCg0KICAgICAg 4oCcc3Vi4oCdOuKAnTczNzU2MjZBNjU2Mzc04oCdLA0KDQogICAgICDigJxpc3PigJ06Imh0dHBz Oi8vaWRwLmV4YW1wbGUuY29tL+KAnCwNCg0KICAgICAg4oCcZXZlbnTigJ06ew0KDQogICAgICAg IOKAnGV2ZW50X3R5cGXigJ06InVybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3JkUmVz ZXTigJ0sDQoNCiAgICAgICAgImlkIjrigJ00NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ54oCdLA0K DQogICAgICAgIOKAnGV2ZW504oCdOnsNCg0KICAgICAgICAgIOKAnGV2ZW50X3R5cGXigJ06Imh0 dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh04oCdLA0KDQogICAg ICAgICAgInJlc2V0QXR0ZW1wdHMiOjUNCg0KICAgICAgICB9DQoNCiAgICAgIH0NCg0KICAgfQ0K DQp9DQoNCg0KDQpUaGlzIGZvcm1hdCBmb2xsb3dzIHRoZSBwcm9wb3NlZCBzaW5ndWxhciBldmVu dCBmb3JtYXQgcmVjdXJzaXZlbHkgYW5kIGlzIDMgbGF5ZXJzIGRlZXAuIE5vdGUgdGhhdCB0aGUg cGFyc2VyIGhhcyB0byBjb250aW51ZSB0byBzZWFyY2ggdGhlIGRvY3VtZW50IGZvciB0aGluZ3Mg dGhhdCBhcmVu4oCZdCB0aGVyZSBhcyBpdCBoYXMgdG8gc3RvcCB3aGVuIG5vIOKAnGV2ZW504oCd IGF0dHJpYnV0ZSBpcyBmb3VuZCByYXRoZXIgdGhhbiBpdGVyYXRlIG92ZXIgYW4gYXJyYXkuDQoN Cg0KUGhpbA0KDQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFy Y2hpdGVjdA0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fd3d3LmluZGVwZW5kZW50 aWQuY29tJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJ X0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1peVZu clptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JnM9OXNZaGdwRXpiN3hQbFFG bUNDWE5tSG82ZlFOOUlCdS1TSEphbWdfQjRIcyZlPT4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KT24gT2N0IDMwLCAyMDE3LCBhdCA4OjU3IEFN LCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86 cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KDQpSZXBsaWVzIGlubGluZS4NCg0KLS0NCkFu bmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCklkZW50aXR5IFNlcnZpY2VzDQoNCg0KRnJvbTogUGhp bCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+ Pg0KRGF0ZTogU3VuZGF5LCBPY3RvYmVyIDI5LCAyMDE3IGF0IDU6MjUgUE0NClRvOiBEaWNrIEhh cmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0K Q2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmll dGZAZ21haWwuY29tPj4sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxt YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4sICJSaWNoYXJkIEJhY2ttYW4sIEFu bmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+ PiwgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2 ZW50QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVs dGlwbGUgZXZlbnRzIHBlciBTRVQ/DQoNCkkgaG9wZSB0aGlzIGFuc3dlcnMgeW91ciBxdWVzdGlv bi4NCg0KTXkg4oCcbWF54oCdIHdhcyBiZWNhdXNlIEkgY2Fu4oCZdCBzZWUgYSByZWFzb24gd2h5 IG5vdC4gVGhlIHF1ZXN0aW9uIHNob3VsZCBiZSwgd2hhdCBpcyB0aGUganVzdGlmaWNhdGlvbiB0 byBtYWtlIOKAnGV2ZW50c+KAnSBzaW5ndWxhcj8NCltyaWNoYW5uYV1UaGUgc2luZ3VsYXIg4oCc ZXZlbnTigJ0gY2xhaW0gaGFzIGNsZWFyZXIgc2VtYW50aWNzIGFuZCBpcyBlYXNpZXIgdG8gcHJv Y2Vzcy4gV2Ugc2hvdWxkIG9wdCBmb3IgZWFzaWVyIHNvbHV0aW9ucyB1bmxlc3MgdGhlcmUgYXJl IHVzZSBjYXNlcyB0aGF0IHJlcXVpcmUgbW9yZSBjb21wbGV4aXR5LlsvcmljaGFubmFdDQoNClRo ZXJlIGFyZSBtYW55IHJlYXNvbnMgZm9yIG11bHRpcGxlIGV2ZW50cyBpbiBhIFNFVC4gIFNvbWUg YXJlIGdvb2QsIHNvbWUgbm90IHNvIGdvb2QuIFNvbWUgb2YgdGhlIHJlYXNvbnMuLi4NCg0KMS4g IE11bHRpcGxlIGV2ZW50IHBheWxvYWRzIGV4cHJlc3Npbmcgc3RhdGVtZW50cyBhYm91dCBsYXJn ZWx5IHRoZSAqc2FtZSp0aGluZy4gRm9yIGV4YW1wbGUsIFNDSU0gcGFzc3dvcmQgcmVzZXQgQU5E IFJJU0MgcGFzc3dvcmQgcmVzZXQuICBBIFJJU0MgRXZlbnQgYW5kIGFuIE9wZW5CYW5raW5nIEV2 ZW50LiBJcyBvbmUgYSBjb21wbGVtZW50IHRvIHRoZSBvdGhlcj8gIERvIHRoZXkgb3ZlcmxhcCBv ciBhcmUgdGhleSBkaXN0aW5jdD8NCltyaWNoYW5uYV1Db3B5L3Bhc3RlZCBmcm9tIG15IGVhcmxp ZXIgZW1haWw6DQpXaHkgaXMgaXQgbmVjZXNzYXJ5IG9yIGFwcHJvcHJpYXRlIHRvIGluY2x1ZGUg dGhlc2UgZXZlbnRzIGluIHRoZSBzYW1lIFNFVD8gVGhleSBhcmUgbGlrZWx5IGJlaW5nIGdlbmVy YXRlZCBieSBkaWZmZXJlbnQgc3lzdGVtcyBhdCBkaWZmZXJlbnQgdGltZXMgb24gdGhlIHRyYW5z bWl0dGVy4oCZcyBzaWRlLCBjb25zdW1lZCBieSBkaWZmZXJlbnQgc3lzdGVtcyBvbiB0aGUgcmVj ZWl2ZXLigJlzIHNpZGUsIGFuZCBwb3NzaWJseSBiZWluZyB0cmFuc21pdHRlZCBvdmVyIGRpZmZl cmVudCBldmVudCBzdHJlYW1zLiBJIGtub3cgdGhlIGxhdHRlciB3b3VsZCBiZSB0aGUgY2FzZSBm b3IgdXMsIGFzIGEgcmVjZWl2ZXIuIEV2ZW4gaWYgaXTigJlzIG5vdCwgaXMgaXQgYnVyZGVuc29t ZSB0byBzZW5kIHRoZXNlIGV2ZW50cyBzZXBhcmF0ZWx5PyBXaGF0IHZhbHVlIGlzIGdhaW5lZCBp biBjb21iaW5pbmcgdGhlbT8NCg0KQWRkaXRpb25hbGx5LCBzaW5jZSB0aGUgc2lnbmF0dXJlIGlz IG92ZXIgdGhlIFNFVCBhbmQgbm90IHRoZSBldmVudCBvYmplY3RzLCBSZWNlaXZlcnMgaW5kZXBl bmRlbnRseSByb3V0ZSBzZXBhcmF0ZSBldmVudHMgZnJvbSBhIHNpbmdsZSB0b2tlbiB3aXRob3V0 IGVpdGhlciBsb3NpbmcgdGhlIGFiaWxpdHkgdG8gdmVyaWZ5IHRoZSBhdXRoZW50aWNpdHkgb2Yg dGhlIGV2ZW50IG9yIHNoYXJpbmcgYWxsIGluZm9ybWF0aW9uIGluIHRoZSBTRVQgd2l0aCBldmVy eSBzeXN0ZW0gaGFuZGxpbmcgYW55IGV2ZW50IGluIHRoZSB0b2tlbi5bL3JpY2hhbm5hXQ0KDQoy LiAgTXVsdGlwbGUgZXZlbnRzIHBheWxvYWRzIGV4cHJlc3NpbmcgZGlmZmVyZW50IHN0YXRlbWVu dHMgYWJvdXQgdGhlIHNhbWUgdHJhbnNhY3Rpb24gLSBSSVNDIFBhc3N3b3JkIFJlc2V0IGFuZCBS SVNDIFNlc3Npb24gQ2FuY2VsDQpbcmljaGFubmFdU2FtZSBhcyBhYm92ZVsvcmljaGFubmFdDQoz LiAgQSBuZXcgcHJvZmlsZSBkZWZpbmVzIG5ldyBldmVudCBhdHRyaWJ1dGVzIHRvIGJlIGFkZGVk IG9uIHRvIGFuIGV4aXN0aW5nIGV2ZW50IHR5cGUgKGEgcHVyZSBleHRlbnNpb24pDQpbcmljaGFu bmFdSSBoYXZlIHN1Z2dlc3RlZCBhIHdheSB0byBzdXBwb3J0IGV4dGVuc2lvbnMgd2l0aGluIGFu IGV2ZW50IGJvZHksIG11bHRpcGxlIHRpbWVzIG5vdy4gSWYgeW91IHNlZSBwcm9ibGVtcyB3aXRo IGl0LCBwbGVhc2UgcG9pbnQgdGhlbSBvdXQuWy9yaWNoYW5uYV0NCg0KSSB0aGluayBpdCBpcyBx dWl0ZSB2YWxpZCB0byBhbGxvdyAxIGFuZCAzLiAgMiBjb3VsZCBiZSBsaW1pdGVkIGJ5IHNwZWNp ZmljIHByb2ZpbGVzIGxpa2UgUklTQyBpZiB0aGV5IHdhbnQuDQoNCkkgYW0gbm90IGluIGFncmVl bWVudCB0aGF0IG1ha2luZyBldmVudCBzaW5ndWxhciBzaW1wbGlmaWVzIGFueXRoaW5nLiBGb3Ig b25lIGlzIG1ha2VzIGV4dGVuc2lvbnMgY29tcGxleCAoYW5vdGhlciBuZXN0ZWQgSlNPTiBzdHJ1 Y3R1cmUpIGFuZCBwb3RlbnRpYWxseSBjb25mbGljdGluZy4NCltyaWNoYW5uYV0NCldheXMgdGhh dCBtdWx0aXBsZS1ldmVudCBTRVRzIGFyZSBtb3JlIGNvbXBsaWNhdGVkOg0KDQogIDEuICBJdCBy ZXN1bHRzIGluIGEgbW9yZSBjb21wbGV4IHN0cnVjdHVyZSBmb3IgdGhlIHNpbmdsZSBldmVudCB1 c2UgY2FzZSwgd2hpY2ggSSB0aGluayB3ZSBhbGwgYWdyZWUgaXMgdGhlIG1ham9yaXR5IHVzZSBj YXNlLg0KICAyLiAgTXVsdGlwbGUtZXZlbnQgU0VUcyBoYXZlIGFtYmlndW91cyBzZW1hbnRpY3Mu IFRoZSBwcmVzZW5jZSBvZiB0d28gZXZlbnRzIEEgYW5kIEIgaW4gdGhlIHNhbWUgU0VUIGNvdWxk IG1lYW4gYW55IG9mOg0KDQogICAgICogICBUaGV5IGFyZSByZWxhdGVkIHRvIHRoZSBzYW1lIGxv Z2ljYWwgZXZlbnQgKGkuZS4gdGhlIHNhbWUgdGhpbmcgYXMgaWYgdGhleSB3ZXJlIGZyb20gZGlm ZmVyZW50IFNFVHMgdGhhdCBoYXZlIGEgY29tbW9uIHR4bikuDQogICAgICogICBBIGlzIGFuIGV4 dGVuc2lvbiBvZiBCLg0KICAgICAqICAgQiBpcyBhbiBleHRlbnNpb24gb2YgQS4NCiAgICAgKiAg IFRoZXkgYXJlIGFsaWFzZXMgZm9yIG9uZSBhbm90aGVyLg0KICAgICAqICAgVGhleSBhcmUgbm90 IGFjdHVhbGx5IHJlbGF0ZWQgdG8gb25lIGFub3RoZXIgaW4gYW55IHdheS4NCg0KICAxLiAgQ2xh aW0gc2VtYW50aWNzIGJlY29tZSBoYXJkZXIgdG8gZGVmaW5lLCBhcyBkaWZmZXJlbnQgcHJvZmls ZXMgbWF5IHdhbnQgdG8gdXNlIHRoZSBzYW1lIGNsYWltcyBpbiBkaWZmZXJlbnQgd2F5cy4NCg0K SWYgdGhlIFdHIHdhbnRzIHRvIGJsb2NrIDEgYW5kIDIgYWJvdmUsIHRoZW4gSSBiZWxpZXZlIHdl IGhhdmUgdG8gZXN0YWJsaXNoIGFuIGV2ZW50IHJlZ2lzdHJ5IHRvIGVuc3VyZSBuZXcgRXZlbnQg cHJvZmlsZXMgZG8gbm90IG92ZXJsYXAgdG8gZWxpbWluYXRlIHRoZSBuZWVkIHRvIGV4cHJlc3Mg bXVsdGlwbGUgZXZlbnRzLg0KW3JpY2hhbm5hXUnigJltIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4g YnkgdGhpcy4gQXJlIHlvdSByZWZlcnJpbmcgdG8gZXZlbnQgbmFtZXM/IFRob3NlIGFyZSBhbHJl YWR5IGRlZmluZWQgYnkgdGhlIHNwZWMgdG8gYmUgVVJJcy5bL3JpY2hhbm5hXQ0KUGhpbA0KDQpP cmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdA0KQGlu ZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fd3d3LmluZGVwZW5kZW50aWQuY29tJmQ9RHdN R2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZW ekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1VLWE1SEJORDBIYVRYNGFu Tlpmelg3cERzZks1ZjBoOW1aOUNaa2tHaWVjJnM9S0J3S1BGbnFZX1E5NUNUQV9fV0dDWUdUeHJE N0FHQ3h1ZW9QWG5LRVVUMCZlPT4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbT4NCg0KT24gT2N0IDI5LCAyMDE3LCBhdCA0OjEyIFBNLCBEaWNrIEhhcmR0 IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90 ZToNCg0KUGhpbDoNCg0KSW4geW91ciBleGFtcGxlcyBmb3IgaGF2aW5nIGEgcGx1cmFsaXR5IG9m IGV2ZW50cywgeW91IHVzZSB0aGUgd29yZCAibWF5Iiwgd2hpY2ggbGVhZHMgbWUgdG8gcXVlc3Rp b24gaWYgYSBwbHVyYWxpdHkgb2YgZXZlbnRzIGlzIHJlYWxseSByZXF1aXJlZCBpbiBTRVQuDQoN CllvdSBwb3NpdCB0aGF0IGl0IHdpbGwgYmUgZGlmZmljdWx0IGZvciBhIGRpc3RyaWJ1dGVkIHN5 c3RlbSB0byBjb3JyZWxhdGUgbXVsdGlwbGUgU0VUcyB3aXRoIHRoZSBzYW1lICJ0eG4iLCBidXQg dGhlIGRpc3RyaWJ1dGVkIHN5c3RlbSB3aWxsIGNlcnRhaW5seSBuZWVkIHRvIGNvcnJlbGF0ZSBl dmVudHMgb24gdGhlIHNhbWUgc3ViamVjdCAtLSBjb3JyZWxhdGluZyBldmVudHMgb24gdGhlIHNh bWUgInR4biIgb24gdGhlIHNhbWUgc3ViamVjdCBzZWVtcyBmYWlybHkgc2ltcGxlLg0KDQpJIHRo aW5rIHRoYXQgYSByZWNlaXZlciB3aWxsIG5lZWQgdG8gY29ycmVsYXRlIG11bHRpcGxlIFNFdHMg b24gdGhlIHNhbWUgc3ViamVjdCwgc28gaGF2aW5nIG11bHRpcGxlIGV2ZW50cyBpbiBhIFNFVCBp cyByZWR1bmRhbnQsIGFuZCBhZGRzIGNvbXBsZXhpdHkgd2l0aCBubyBjbGVhciBiZW5lZml0IHRo YXQgSSBjYW4gc2VlLg0KDQpBbiBpbXBsZW1lbnRvciBtYXkgY2hvb3NlIHRvIHNlbmQgbXVsdGlw bGUgU0VUcywgb3Igc2VuZCBhIHNpbmdsZSBTRVQgd2l0aCBtdWx0aXBsZSBldmVudHMsIHNvIGEg cmVjZWl2ZXIgd2lsbCBuZWVkIHRvIHN1cHBvcnQgYm90aC4gSSBwcmVmZXIgd2UgcGljayBvbmUg d2F5IGFuZCBtaW5pbWl6ZSB0aGUgY29kZSBwYXRocywgYW5kIHdlIHdpbGwgbmVlZCB0byBzdXBw b3J0IGNvcnJlbGF0aW5nIGFjcm9zcyBtdWx0aXBsZSBTRVRzLCBzbyB0aGF0IHNlZW1zIHRoZSBi ZXN0IG1lY2hhbmlzbS4NCg0KTGV0IG1lIGtub3cgaWYgdGhlcmUgaXMgc29tZXRoaW5nIEkgbWlz c2VkIGluIG15IGxvZ2ljLg0KDQovRGljaw0KDQoNCk9uIFN1biwgT2N0IDI5LCAyMDE3IGF0IDEx OjI4IEFNLCBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9u Zi5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KSW4gdGhhdCBjYXNlLCBsZXQncyBhZGQgdGV4dCB0 byB0aGF0IGVmZmVjdCwgZS5nLiB3ZSBjb3VsZCBhZGQgdG8gdGhlIGRlZmluaXRpb24gb2YgdGhl ICJldmVudHMiIGNsYWltOg0KDQpQcm9maWxpbmcgc3BlY2lmaWNhdGlvbnMgU0hPVUxEIGRlZmlu ZSB0aGUgYWxsb3dlZCBldmVudCBzdGF0ZW1lbnRzLCBhbmQgTUFZIHJlc3RyaWN0IHRoZWlyIG51 bWJlci4gRm9yIGV4YW1wbGUsIHNvbWUgcHJvZmlsZXMgbWF5IHJlcXVpcmUgdGhpcyBjbGFpbSB0 byBjb250YWluIG9ubHkgYSBzaW5nbGUgZXZlbnQgc3RhdGVtZW50Lg0KDQpUaGFua3MsDQogICAg ICAgIFlhcm9uDQoNCk9uIDI0LzEwLzE3IDIyOjEwLCBNaWtlIEpvbmVzIHdyb3RlOg0KSSBhZ3Jl ZSB3aXRoIG11Y2ggb2YgUGhpbOKAmXMgcmF0aW9uYWxlIGhlcmUuDQoNCkl04oCZcyBmaW5lIGZv ciBzb21lIHByb2ZpbGVzIHRvIHNheSB0aGF0IHRoZSDigJxldmVudHPigJ0gc2V0IG11c3QgYmUg YSBzaW5nbGV0b24uICBUaGF0IGRvZXNu4oCZdCBoYXZlIHRvIGJlIHRydWUgZm9yIGFsbCBldmVu dHMuICBJIHRoaW5rIHRoaW5ncyBhcmUgZmluZSBhcy1pcy4NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN CipGcm9tOiogSWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPl0gKk9uIEJlaGFsZiBPZiAqUGhpbCBIdW50DQoq U2VudDoqIE1vbmRheSwgT2N0b2JlciAyMywgMjAxNyA4OjQ3IFBNDQoqVG86KiBSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1h em9uLmNvbT4+DQoqQ2M6KiBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9y ZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KKlN1YmplY3Q6KiBSZTogW0lkLWV2ZW50XSBV c2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPw0KDQpBbm5hYmVsbGUsDQoNCkkg aGF2ZSBhIG51bWJlciBvZiBjb25jZXJucyB3aXRoIHRoaXMgcHJvcG9zYWwuDQoNClByb2ZpbGlu ZyBJbmRlcGVuZGVuY2UgLyBLZWVwaW5nIEV2ZW50IFBheWxvYWRzIEluZGVwZW5kZW50DQoNCklu ZGljYXRpbmcgdGhhdCBleHRlbnNpb25zIHNob3VsZCBiZSBoYW5kbGVkIGJ5IHByb2ZpbGVzIGxl YWRzIHRvIG1vcmUgaW50ZXItb3BlcmFiaWxpdHkgaXNzdWVzIGFuZCBtb3JlIGltcG9ydGFudGx5 IGludHJ1ZGVzIG9uIHRoZSBFdmVudCBwYXlsb2FkIHNwYWNlIGJ5IHN1Z2dlc3RpbmcgYSBzdWIt c2NoZW1hIGNyZWF0ZXMgcG90ZW50aWFsIGxpbWl0YXRpb25zIGFuZCBjb25mbGljdHMgdGhhdCBt YXkgYWRkIHRvIGNvbXBsZXhpdHkgbGF0ZXIgb24uIFRoZSBjdXJyZW50IGZvcm1hdCBhbGxvd3Mg YSBwYXJzZXIgdG8gZGlzY292ZXIgYW5kIHVubG9hZCBvbmUgb3IgbW9yZSBKU09OIHBheWxvYWRz IHdoaWNoIGNhbiBlYWNoIGhhdmUgaW5kZXBlbmRlbnQgc3RydWN0dXJlLg0KDQpHZW5lcmFsIGV4 dGVuc2lvbnMNCg0KVGhlIHByb3Bvc2FsIGFsc28gcnVsZXMgb3V0IGdlbmVyYWwgcHVycG9zZSBl eHRlbnNpb25zIG5vdCByZWxhdGVkIHRvIGFueSBzcGVjaWZpYyBldmVudC4gR2l2ZW4gdGhlIGVt ZXJnZW5jZSBvZiBpdGVtcyBsaWtlIEdQUkQsIEkgd291bGQgbm90IHdhbnQgdG8gYmxvY2sgdGhl IGFiaWxpdHkgdG8gYWRkIG1ldGEtZGF0YSBvciBvdGhlciBnZW5lcmFsIHB1cnBvc2UgaXRlbXMu IFdlIGNhbiBhbHNvIGFudGljaXBhdGUgc29tZSBkZWxpdmVyeSBzY2VuYXJpb3Mgd2hlcmUgYWRk aXRpb25hbCBkYXRhIG1pZ2h0IGJlIHJlcXVpcmVkLiBFdmVuIHRob3VnaCB0aGVyZSBpcyBubyBj dXJyZW50IHBsYW5uZWQgdXNlLCBJIHNlZSBubyBnb29kIHJlYXNvbiB0byBydWxlIHRoaXMgb3V0 Lg0KDQpNdWx0aXBsZSBFdmVudHMgRnJvbSBEaWZmZXJlbnQgRmFtaWxpZXMgKHZzLiBNdWx0aXBs ZSBFdmVudHMgZnJvbSBhIHNpbmdsZSBmYW1pbHkgbGlrZSBSSVNDKQ0KDQpJbiBvdXIgUklTQyBz ZXNzaW9uIHdlIGRpc2N1c3NlZCBleHByZXNzaW5nIG11bHRpcGxlIGRpc3RpbmN0IFJJU0MgZXZl bnRzIGluIG9uZSBTRVQuIFRoZSBkaXNjdXNzaW9uIHdhcyB0aGF0IG9ubHkgb25lIFJJU0MgZXZl bnQgYXQgYSB0aW1lLiBXZSBkaWQgbm90IGRpc2N1c3Mgb3RoZXIgZXZlbnQgcHJvZmlsZXMuIEkg ZG9u4oCZdCBzZWUgYSByZWFzb24gdG8gcnVsZSBvdXQgbXVsdGktZXZlbnRzIGZyb20gZGlmZmVy ZW50IGZhbWlsaWVzIGF0IHRoZSBTRVQgbGV2ZWwuIEVhY2ggcHJvZmlsZSBpcyBleHByZXNzaW5n IHNsaWdodGx5IGRpZmZlcmVudCB0aGluZ3MgYWJvdXQgdGhlIHNhbWUgZXZlbnQuDQoNCkkgY2Fu IGZvcnNlZSBzb21lIGNhc2VzIHdoZXJlIGl0IGlzIG5vdCBjbGVhciB3aGljaCBpcyB0aGUgcHJp bWFyeSBhbmQgd2hpY2ggaXMgdGhlIGV4dGVuc2lvbi4gIFRoZXJlIG1heSBub3QgYmUgYSBjbGVh ciB3aW5uZXIuDQoNCkEgY291cGxlIG9mIGV4YW1wbGVzICh0aGVzZSBhcmUgbmVjZXNzYXJpbHkg cmVhbOKApmp1c3QgcG9zc2liaWxpdGllcyk6DQoNCiogSXQgaXMgcHJvYmFibHkgdXNlZnVsIHRv IGJlIGFibGUgdG8gZXhwcmVzcyBzaW1sYXIvb3ZlcmxhcHBpbmcgZXZlbnRzIGZyb20gZGlmZmVy ZW50IFNFVCBwcm9maWxlcyBpbiBvbmUgU0VULiAgRm9yIGV4YW1wbGUgYSBCYWNrY2hhbm5lbCBM b2dvdXQgJiBhIFJJU0Mgc2Vzc2lvbiBjYW5jZWwgZXZlbnQuDQoNCiogU0NJTSBtYXkgd2FudCB0 byByZXByZXNlbnQgYSBzaW5nbGUgdHJhbnNhY3Rpb24gYXMgY2F1c2luZyBtdWx0aXBsZSBzdGF0 ZSBjaGFuZ2VzIGluIGFuIGV2ZW50IChlLmcuIGEgcGFzc3dvcmQgY2hhbmdlIGNhdXNlcyBtdWx0 aXBsZSBlZmZlY3RzKS4gSGF2aW5nIHRvIGNoYXNlIGRvd24gbXVsdGlwbGUgZXZlbnRzIGFuZCBj b3JyZWxhdGUgYnkg4oCcdHhu4oCdIHdvdWxkIGJlIGNoYWxsZW5naW5nIGluIGEgbXVsdGktdGhy ZWFkZWQvbXVsdGktbm9kZSBkZWxpdmVyeSBzeXN0ZW0uICAgVGhlIFNDSU0gbGlzdCBoYXMgbm90 IGRpc2N1c3NlZCB0aGlzLCBidXQgSSB3b3VsZCBub3Qgd2FudCB0byBibG9jayB0aGlzIGNhcGFi aWxpdHkuICBJT1cgLSBKdXN0IGJlY2F1c2UgUklTQyBkb2VzIG5vdCB3YW50IHRvIGV4cHJlc3Mg bXVsdGlwbGUgZXZlbnRzIGRvZXMgbm90IG1ha2UgdGhpcyB0cnVlIGZvciBvdGhlciBwcm9maWxl cy4NCg0KKiBXZSBtYXkgd2lzaCB0byBpbmRpY2F0ZSBhIFNDSU0gUGFzc3dvcmQgUmVzZXQgd2Fz IHBlcmZvcm1lZCBhbmQgYSBMb2dvdXQvc2Vzc2lvbiBjYW5jZWxsYXRpb24gaXMgZXhwcmVzc2Vk IGF0IHRoZSBzYW1lIHRpbWUuICBUaGUgZXZlbnRzIGFyZSByZWxhdGVkIGJ1dCBleHByZXNzIGRp ZmZlcmVudCBkYXRhLg0KDQpBdm9pZGluZyBDb25mdXNpb24gRnJvbSBTaW1pbGFyIEV2ZW50cyBP cmlnaW5hdGluZyBmcm9tIHRoZSBTYW1lIFRyYW5zYWN0aW9uDQoNCklmIGV2ZW50cyBhcmUgc2Vu dCBzZXBhcmF0ZWx5LCB0aGVuIG1vcmUgdHJhY2tpbmcgb2Ygc3RhdGUgKGUuZy4gYnkgdHhuKSB3 b3VsZCBiZSByZXF1aXJlZCB0byBlbnN1cmUgc2ltaWxhciBldmVudHMgYXJlIG5vdCBtaXN0YWtl biBvciBoYW5kbGVkIGFzIHJlcGVhdHMuIFdoaWxlIHR4biBwcm92aWRlcyB1c2VmdWwgYXVkaXQg YW5hbHlzaXMgY2FwYWJpbGl0eSwgSeKAmW0gbm90IHN1cmUgaXQgY2FuIGJlIHVzZWQgaW4gbGl2 ZSBvciBuZWFyLXJlYWwgdGltZSBzeXN0ZW1zIGdpdmVuIGRpc3RyaWJ1dGVkIG11bHRpLW5vZGUs IG11bHRpLXRocmVhZGluZyBhcmNoaXRlY3R1cmVzLg0KDQpQcmV2aW91cyBEaXNjdXNzaW9uDQoN Ckkgbm90ZSB0aGF0IEkgb3JpZ2luYWxseSByYWlzZWQgaGF2aW5nIGFuIGF0dHJpYnV0ZSB0byBk ZXNpZ25hdGUgcHJpbWFyeSBldmVudCBhdHRyaWJ1dGUgdG8gYWxsZXZpYXRlIHlvdXIgY29uY2Vy biwgYnV0IHRoaXMgd2FzIG5vdCBhY2NlcHRlZC4gU2VlOg0KDQoqIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3VycmVudC9tc2cwMDQwNi5odG1sPGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRfbXNnMDA0MDYuaHRtbCZk PUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1u YTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09WUJDR2xLOW1qamhj RnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZzPVMzc01WaXFNdkVnbndHYkp3T1FOeWNy T3lyN1NlZnBxX01vRk9LY0VlQ0UmZT0+DQoNCiogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9pZC1ldmVudC9jdXJyZW50L21zZzAwMTQwLmh0bWw8aHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbC0y RGFyY2hpdmVfd2ViX2lkLTJEZXZlbnRfY3VycmVudF9tc2cwMDE0MC5odG1sJmQ9RHdNRmFRJmM9 Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21h bnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1ZQkNHbEs5bWpqaGNGc2otMnREa24z MUF1eHVydWliOUtBVGtSbFFHMWl3JnM9R3k5Z3lSb0lJdGEtY1NoVjdiTjE2MWF5NHlFNnI5RzFf QWFfTmVCbnlsZyZlPT4NCg0KVGhlIGNvbnNlbnN1cywgYXQgbGVhc3QgYXMgSSBpbnRlcnByZXRl ZCBpdCBpcyB1cCB0byB0aGUgcmVjZWl2ZXIgdG8gZmlndXJlIHRoaXMgb3V0IGJhc2VkIG9uIHRo ZSBkZWZpbml0aW9ucyBpdCBoYXMgZm9yIGVhY2ggZXZlbnQgVVJJIGFuZCB0aGUgcHJvZmlsZXMg dGhleSByZXByZXNlbnQuIElPVyAtIFJJU0MgaXMgZnJlZSB0byBsaW1pdCB0aGF0IG9ubHkgb25l IFJJU0MgZXZlbnQgYmUgZXhwcmVzc2VkIGF0IGEgdGltZS4NCg0KUGhpbA0KDQpPcmFjbGUgQ29y cG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdA0KDQpAaW5kZXBlbmRl bnRpZA0KDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNvbSZkPUR3TUZhUSZj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdt YW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09WUJDR2xLOW1qamhjRnNqLTJ0RGtu MzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZzPTlOUDVuYW1nNnJJVnp3dW45Yy0xcTB3aHN5WHdTdnRI QjBmMmRLa2ZDWDgmZT0+IDxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRp ZC5jb20mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElf Sm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPVlCQ0ds SzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmcz05TlA1bmFtZzZySVZ6d3Vu OWMtMXEwd2hzeVh3U3Z0SEIwZjJkS2tmQ1g4JmU9Pj4NCg0KcGhpbC5odW50QG9yYWNsZS5jb208 bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPiA8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQoNCiAgICBPbiBPY3QgMjMsIDIwMTcsIGF0 IDc6MDIgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlDQogICAgPHJpY2hhbm5hQGFtYXpv bi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+IDxtYWlsdG86cmljaGFubmFAYW1hem9u LmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+PiB3cm90ZToNCg0KICAgIFRoZSBjdXJy ZW50IGRyYWZ0IG9mIHRoZSBTRVQgc3BlYyBhbGxvd3MgZm9yIGV4cHJlc3NpbmcgbXVsdGlwbGUN CiAgICBldmVudHMgd2l0aGluIHRoZSBzYW1lIHRva2VuLCB3aGljaCBpbnRyb2R1Y2VzIGFkZGl0 aW9uYWwgY29tcGxleGl0eQ0KICAgIGFuZCByb29tIGZvciBhbWJpZ3VvdXMgc2VtYW50aWNzLiBX ZeKAmXZlIGRpc2N1c3NlZCB0aGlzIGluIHRoZSBPSURGDQogICAgUklTQyB3b3JraW5nIGdyb3Vw IGFuZCB0aGUgY3VycmVudCBjb25zZW5zdXMgdGhlcmUgaXMgdGhhdCBSSVNDIHdpbGwNCiAgICBy ZXF1aXJlIHRoYXQgUklTQyBldmVudHMgbXVzdCBiZSB0aGUgb25seSBldmVudCBpbiB0aGUgU0VU LCBoYXZpbmcNCiAgICBpZGVudGlmaWVkIHdheXMgdG8gY2xlYXJseSBhbmQgZWFzaWx5IHN1cHBv cnQgdGhlIGhhbmRmdWwgb2YgdXNlDQogICAgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIg dG9rZW4gdGhhdCBwZW9wbGUgaGF2ZSByYWlzZWQuIFdpdGgNCiAgICB0aGF0IGNvbnRleHQgaW4g bWluZCwgSSBwcm9wb3NlIHN0cmlraW5nIHRoZSBkZWZpbml0aW9uIG9mIHRoZQ0KICAgIOKAnGV2 ZW50c+KAnSBjbGFpbSBmcm9tIHRoZSBTZWN1cml0eSBFdmVudCBUb2tlbiBzcGVjLCBhbmQgcmVw bGFjaW5nIGl0DQogICAgd2l0aCB0aGUgZm9sbG93aW5nIGRlZmluaXRpb24gZm9yIGFuIOKAnGV2 ZW504oCdIGNsYWltIChzaW5ndWxhcik6DQoNCiAgICBldmVudA0KDQogICAgQSBKU09OIG9iamVj dCBjb250YWluaW5nIGFuICJldmVudF90eXBlIiBtZW1iZXIgd2hvc2UgdmFsdWUgaXMgYSBVUkkN CiAgICByZXByZXNlbnRpbmcgYSB0eXBlIG9mIGV2ZW50IGRlZmluZWQgaW4gYSBQcm9maWxpbmcg U3BlY2lmaWNhdGlvbi4NCiAgICBUaGUgb2JqZWN0IE1BWSBvdGhlcndpc2UgYmUgZW1wdHksIG9y IE1BWSBjb250YWluIGFkZGl0aW9uYWwgbWVtYmVycw0KICAgIGFzIGRlc2NyaWJlZCBieSB0aGUg UHJvZmlsaW5nIFNwZWNpZmljYXRpb24uDQoNCiAgICBIZXJlIGlzIHRoZSBleGFtcGxlIFNFVCBm cm9tIHNlY3Rpb24gMi4zLCByZXdyaXR0ZW4gd2l0aCB0aGlzIGNoYW5nZQ0KICAgIG1pbmQ6DQoN CiAgICB7DQoNCiAgICAgICAianRpIjogIjRkMzU1OWVjNjc1MDRhYWJhNjVkNDBiMDM2M2ZhYWQ4 IiwNCg0KICAgICAgICJpYXQiOiAxNDU4NDk2NDA0LA0KDQogICAgICAiaXNzIjogImh0dHBzOi8v c2NpbS5leGFtcGxlLmNvbTxodHRwczovL3NjaW0uZXhhbXBsZS5jb20vPiA8aHR0cHM6Ly9zY2lt LmV4YW1wbGUuY29tLz4iLA0KDQogICAgICAgImF1ZCI6IFsNCg0KICAgICAgICAgImh0dHBzOi8v c2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiwNCg0KICAg ICAgICAgImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3 Njc2ZWU3Ig0KDQogICAgICAgXSwNCg0KICAgICAgICJldmVudCI6IHsNCg0KICAgICAgICAgImV2 ZW50X3R5cGUiOiAidXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6Y3JlYXRlIiwNCg0KICAgICAg ICAgInJlZiI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZh YjYxZTc1MjFkOSIsDQoNCiAgICAgICAgICJhdHRyaWJ1dGVzIjogWyJpZCIsICJuYW1lIiwgInVz ZXJOYW1lIiwgInBhc3N3b3JkIiwgImVtYWlscyJdDQoNCiAgICAgICB9DQoNCiAgICB9DQoNCiAg ICBEb2VzIGFueW9uZSBpbiB0aGUgd29ya2luZyBncm91cCBoYXZlIHVzZSBjYXNlcyBmb3IgU0VU cyB0aGF0IGNhbm5vdA0KICAgIGJlIG1ldCBieSB0aGlzIHByb3Bvc2VkIHRleHQ/IFdpdGhpbiBS SVNDLCB3ZSBpZGVudGlmaWVkIHRocmVlIHVzZQ0KICAgIGNhc2VzLCB3aXRoIHNvbHV0aW9ucyBv dXRsaW5lZCBiZWxvdzoNCg0KICAgICoqDQoNCiAgICAqRXh0ZW5zaW9ucyoNCg0KICAgIEV2ZW50 IGV4dGVuc2lvbiBtZWNoYW5pc21zIGNhbiBiZSBkZWZpbmVkIGludGVybmFsIHRvIHRoZSBldmVu dA0KICAgIG9iamVjdC4gQSBzaW1wbGUgYXBwcm9hY2ggd291bGQgYmUgdG8gIGRlZmluZSBhbiDi gJxleHRlbnNpb25z4oCdIG1lbWJlcg0KICAgIHRoYXQgaXMgYSBsaXN0IG9mIGV2ZW50IG9iamVj dHMgKG9yIHNldCByZXNlbWJsaW5nIHRoZSDigJxldmVudHPigJ0NCiAgICBjbGFpbSBhcyBkZWZp bmVkIGluIHRoZSBjdXJyZW50IHNwZWMpLiBUaGlzIGhhcyB0aGUgYWR2YW50YWdlIG9mDQogICAg bWFraW5nIGl0IGNsZWFyIGluIHRoZSBkYXRhIHN0cnVjdHVyZSB0aGF0IHRoZXJlIGlzIGEgc2lu Z2xlIHByaW1hcnkNCiAgICBldmVudCwgd2l0aCB6ZXJvIG9yIG1vcmUgZXh0ZW5zaW9ucy4gVGhl cmUgaXMgbm8gcm9vbSBmb3IgY29uZnVzaW9uDQogICAgb3ZlciB3aGljaCBldmVudCBpcyBwcmlt YXJ5LCBvciBpZiB0aGVyZSBpcyBhIHByaW1hcnkgZXZlbnQgYXQgYWxsLg0KICAgIEkgd291bGQg YmUgZmluZSB3aXRoIGFkZGluZyBzb21ldGhpbmcgbGlrZSB0aGlzIHRvIG15IHByb3Bvc2VkIHRl eHQsDQogICAgaWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRoYXQgaXQgaXMgYnJvYWRseSB1c2VmdWwu DQoNCiAgICAqQWxpYXNlcyoNCg0KICAgIFRoaXMgdXNlIGNhc2Ugd2FzIGJyb3VnaHQgdXAgaW4g dGhlIGNvbnRleHQgb2YgbWlncmF0aW5nIGNsaWVudHMNCiAgICBmcm9tIGRyYWZ0IGV2ZW50IG5h bWVzIHRvIHN0YW5kYXJkaXplZCBldmVudCBuYW1lcy4gSW4gdGhpcyBjYXNlLA0KICAgIHRoZSBl dmVudCB0cmFuc21pdHRlciBjYW4gdHJhbnNtaXQgdHdvIHRva2VucyBmb3IgdGhlIGxvZ2ljYWwg ZXZlbnQsDQogICAgb25lIHVzaW5nIHRoZSBvbGQgbmFtZSBhbmQgYW5vdGhlciB1c2luZyB0aGUg bmV3IG5hbWUuDQoNCiAgICAqUmVsYXRlZCBFdmVudHMqDQoNCiAgICBUaGUgU0VUIHNwZWMgZGVm aW5lcyB0aGUgdHhuIGNsYWltIGFzIGEgbWVhbnMgb2YgY29ycmVsYXRpbmcNCiAgICBpbmRlcGVu ZGVudCB0b2tlbnMgdGhhdCByZWxhdGUgdG8gdGhlIHNhbWUgbG9naWNhbCBldmVudC4NCg0KICAg IC0tDQogICAgQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KDQogICAgQW1hem9uIOKAkyBJZGVu dGl0eSBTZXJ2aWNlcw0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgICBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICBJZC1ldmVudEBpZXRm Lm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8 bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPj4NCiAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv X2lkLTJEZXZlbnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtL WTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZt PXM1YnlCZTVLQU5uR1Z1QWIxbUF1cEVHb0puOFhHNUpJVVV3V0dGU2liRWMmcz1YOG9SU3EzSXps RjdqaVJBZVpoWHBSM2VWSTBJNThaRmQ0ZUVaZmd5b0lZJmU9DQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0 DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9faWQtMkRldmVudCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJ ck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRL Wk5BJm09WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZzPVdyTXVR UndMVjgwMmlNUTR3WUIxZjJyRlVHdTR6YmhjVzAwMWZLMDJFWHMmZT0+DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxp c3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3 cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xO NEtaTkEmbT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JnM9V3JN dVFSd0xWODAyaU1RNHdZQjFmMnJGVUd1NHpiaGNXMDAxZkswMkVYcyZlPT4NCg0KDQoNCi0tDQpT dWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hD Z2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0 eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5 S0FUa1JsUUcxaXcmcz1MWU43MkdnS1ZoSHNUNnRBcUJlLWVNb1dNdnlfN2RmRm4xdVowSEs2WXVR JmU9PiBtYWlsIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50 IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3Jn Pg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193 d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1 bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0 RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVy dWliOUtBVGtSbFFHMWl3JnM9V3JNdVFSd0xWODAyaU1RNHdZQjFmMnJGVUd1NHpiaGNXMDAxZksw MkVYcyZlPQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZl bnRAaWV0Zi5vcmc+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lD QWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6 QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPVUtYTVIQk5EMEhhVFg0YW5O WmZ6WDdwRHNmSzVmMGg5bVo5Q1pra0dpZWMmcz1ydmRydEk3cllOUkFucVpEbHRDd0JBWlZIS3At TUoyMHVpMm5tNDZRU3owJmU9DQoNCg0KDQoNCi0tDQpTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FS RTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFy ZHR3YXJlLmNvbV8mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2 NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZt PWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmcz13dGdEM05wMHZ5 aExkcEV3VWlxc2Y0SXRpd0EzT203R3JvYjcwTHgwcjNrJmU9PiBtYWlsIGxpc3QgdG8gbGVhcm4g YWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRA aWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUly TVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEta TkEmbT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JnM9T2UwcWZM RVg4M3Z0WE03V2wyY1lCZS1HZzFEVlBqaFhqVkprZmhWUnp3YyZlPQ0KDQoNCg0KLS0NClN1YnNj cmliZSB0byB0aGUgSEFSRFRXQVJFPGh0dHA6Ly9oYXJkdHdhcmUuY29tLz4gbWFpbCBsaXN0IHRv IGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCg0KDQoNCi0tDQpTdWJzY3Jp YmUgdG8gdGhlIEhBUkRUV0FSRTxodHRwOi8vaGFyZHR3YXJlLmNvbS8+IG1haWwgbGlzdCB0byBs ZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hDQoNCg0KDQotLQ0KU3Vic2NyaWJl IHRvIHRoZSBIQVJEVFdBUkU8aHR0cDovL2hhcmR0d2FyZS5jb20vPiBtYWlsIGxpc3QgdG8gbGVh cm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0K --_000_CY4PR21MB0504123CF86035352776D8DCF55F0CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4ubS00Mzc3Nzg3 NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAy NjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTpt Xy00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2 NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVt YWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDo0NjUwMDY0NjE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDMzNzkyNDMyO30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEyNzI4NTg0MTk7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjE1ODMyNTk2NTA7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTc4 ODIzOTI1MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTMzNzg5ODczMjt9DQpAbGlzdCBsMjps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGNvbXBs ZXRlbHkgYWdyZWUgb24gbW92aW5nIGNvbXBsZXhpdHkgdG8gdGhlIGlzc3VlciBvdmVyIHRoZSBy ZWNpcGllbnQuJm5ic3A7IEluIG15IHZpZXcsIGl04oCZcyBtb3JlIGNvbXBsZXggZm9yIHJlY2lw aWVudHMgdG8gaGF2ZSB0byBjb3JyZWxhdGUgYW5kIHByb2Nlc3MgYSBzZXF1ZW5jZSBvZiBtdWx0 aXBsZSBTRVRzIHByb3ZpZGluZyBpbmZvcm1hdGlvbiBhYm91dA0KIHRoZSBzYW1lIGxvZ2ljYWwg ZXZlbnQsIGFuZCB2YWxpZGF0ZSBOIHNpZ25hdHVyZXMsIHRoYW4gdG8gcmVjZWl2ZSBvbmUgU0VU IHdpdGggYWxsIHRoZSBhc3BlY3RzIG9mIHRoZSBsb2dpY2FsIGV2ZW50IGFzIOKAnGV2ZW50c+KA nSBmaWVsZHMsIHdpdGggbm8gY29ycmVsYXRpb24gb3ZlciB0aW1lIHRoZW4gcmVxdWlyZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IERpY2sgSGFyZHQgW21haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbV0g PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMSwgMjAxNyA5OjM5IEFNPGJy Pg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBZYXJvbiBTaGVmZmVyICZsdDt5YXJvbmYuaWV0ZkBnbWFpbC5j b20mZ3Q7OyBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmFAYW1hem9uLmNv bSZndDs7IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0O2lkLWV2ZW50QGlldGYub3JnJmd0Ozsg UGhpbCBIdW50IChJRE0pICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVy IFNFVD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3VyIGNvbW1lbnRz IGhpZ2hsaWdodCBhIGNvdXBsZSBvZiBwb2ludHM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIFRoZSBleGFtcGxlIGlzIGhvdyB0byBoYXZl IGEgcHJlZGVmaW5lZCBleHRlbnNpb24gcG9pbnQgZm9yIGV4dGVuc2lvbnMgb2YgYSBzcGVjaWZp YyBldmVudCwgaXQgaXMgbm90IGhvdyB0byBhZGQgYW5vdGhlciBldmVudC4gTXlzZWxmLCBJIHRo aW5rIHRoaXMgaXMgb3Zlcmx5IGNvbXBsaWNhdGVkLiBFdmVudHMgc2hvdWxkIGJlIGNvbXBhcmF0 aXZlbHkgc3RhdGljLCBhbmQgYXMgd2l0aCBtYW55IG90aGVyDQogSlNPTiBmb3JtYXRzLCB0aGUg cmVjZWl2ZXIgc2hvdWxkIGlnbm9yZSBwcm9wZXJ0aWVzIGl0IGRvZXMgbm90IHVuZGVyc3RhbmQs IHdoaWNoIGxldCdzIG5ldyBwcm9wZXJ0aWVzIGJlIGludHJvZHVjZWQgYXMgZXh0ZW5zaW9ucy4g VGhlcmUgc2hvdWxkIG5vdCBiZSBhbnkgY29uZmxpY3QgYXMgZXh0ZW5zaW9ucyBzaG91bGQgb25s eSBiZSBkb25lIGJ5IHRoZSBwcm9maWxlIHRoYXQgY3JlYXRlZCB0aGUgZXZlbnQgZm9ybWF0IHRv IHN0YXJ0IG9mZg0KIHdpdGguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjIpIEhhdmluZyBhbiBsdmFsdWUgYmUgYSBVUkkgaXMgbXVjaCBoYXJk ZXIgdG8gY29kZSBhZ2FpbnN0LiBJJ20gbm90IHN1cmUgd2h5IE1hcml1cyBoYWQgdGhhdCBpbiBo aXMgZXhhbXBsZS4gUGVyIHRoZSBldmVudCwgdGhlIHR5cGUgb2YgdGhlIGV2ZW50IGlzIHdlbGwg ZGVmaW5lZCB3aXRoJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+JnF1b3Q7ZXZlbnRfdHlwZSZx dW90OzogJnF1b3Q7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVu dC9wYXNzd29yZFJlc2V0RXh0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+aHR0cHM6Ly9leGFt cGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQ8L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzUwMDA1MCI+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMpIFRoaXMgdGhyZWFkIGlzIGFib3V0IHJl YXNvbnMgZm9yIG11bHRpcGxlIGV2ZW50cyB0byBiZSBjb250YWluZWQgaW4gb25lIHNldC4gWW91 ciBtZW50aW9uIG9mIGFuIGlzc3VlciBub3Qgd2FudGluZyB0byBzaWduIHNlcGFyYXRlIGV2ZW50 cyBhcyBhIHJlYXNvbiB0byBhbGxvdyBtdWx0aXBsZSBldmVudHMuIEkgdGhpbmsgd2UgaGF2ZSBk ZWNpZGVkIHRoYXQgZ2l2ZW4gYSBwcmVmZXJlbmNlLCB3ZSB3aWxsDQogcHVzaCBlZmZvcnQgdG8g dGhlIHRyYW5zbWl0dGVyIG92ZXIgdGhlIHJlY2VpdmVyIGFzIGluIG1hbnkgdXNlIGNhc2VzIHRo ZXJlIGFyZSBtYW55IG1vcmUgcmVjZWl2ZXJzLiBHaXZlbiB0aGF0LCBpdCBpcyBtb3JlIGNvbXBs ZXggZm9yIGEgcmVjZWl2ZXIgdG8gaGF2ZSBkaWZmZXJlbnQgd2F5cyBvZiBtYW5hZ2luZyB0aGUg cmVjZWlwdCBvZiBtdWx0aXBsZSBldmVudHMgYXMgbm90IGFsbCBpc3N1ZXJzIHdpbGwgYnVuZGxl IHRoZSBldmVudHMsDQogc28gaXQgaXMgc2ltcGxlciB0byBoYXZlIG9ubHkgb25lIGV2ZW50IHBl ciBTRVQuIEluY2x1ZGluZyB0aGUgc2VwYXJhdGUgZXZlbnRzIHdpdGggYSBVUkkgYXMgYW4gbHZh bHVlIGlzIGNoYWxsZW5naW5nIHRvIGltcGxlbWVudCwgc3BlYWtpbmcgZnJvbSBleHBlcmllbmNl LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUdWUsIE9jdCAzMSwgMjAxNyBhdCAxMTowNSBQTSwgTWlrZSBKb25l cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+TWFyaXVz4oCZIHByb3Bvc2VkIHN5bnRh eCwgcGFzdGVkIGluIGJlbG93LCBoYXMgZXhhY3RseSB0aGlzIGNoYXJhY3RlcmlzdGljLiZuYnNw OyBUaGUgd2F5IEkgc2VlIGl0LCBoaXMgcHJvcG9zYWwgZXNzZW50aWFsbHkgaGFzIGEgcHJpbWFy eSBwYXNzd29yZFJlc2V0IGV2ZW50DQogYW5kIGEgc2Vjb25kYXJ5IHBhc3N3b3JkUmVzZXRFeHQg ZGF0YSBzdHJ1Y3R1cmUsIHdoaWNoIGNvdWxkIGhhdmUgYmVlbiBzaW1wbHkgYW5vdGhlciBldmVu dCB2YWx1ZSBpbiB0aGUgY3VycmVudCBkcmFmdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj5UaGlzIGJyZWFraW5nIGNoYW5nZSBtYWtlcyB0aGUgZGF0YSBzdHJ1Y3R1 cmVzIG1vcmUgY29tcGxpY2F0ZWQgLSBub3QgbGVzcy4mbmJzcDsgQW5kIGl0IG1ha2VzIHRoaW5n cyB0aGF0IHVzZWQgdG8gYmUgcG9zc2libGUgaW1wb3NzaWJsZSwgcmVkdWNpbmcgZmxleGliaWxp dHkNCiB0byB0aG9zZSB3aG8gd291bGQgdXNlIHRoZSBzcGVjLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoZXNlIHNlZW0gbGlrZSBiYWQgdHJhZGVvZmZzIHRvIG1l Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZxdW90O2p0aSZxdW90OzogJnF1b3Q7M2Qw YzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7 OiAxNDU4NDk2MDI1LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7ICZxdW90O2lzcyZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6 Ly9zY2ltLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vc2NpbS5leGFtcGxl LmNvbTwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiBbPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZxdW90 OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3 OTU5M2I3NzU0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRz Lzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQ8L2E+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmcXVvdDs8 YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFk NzY3NmVlNyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81 ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3PC9hPiZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwO10sPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5i c3A7JnF1b3Q7ZXZlbnRfdHlwZSZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxl LmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwvYT4mcXVvdDssPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsg Jm5ic3A7JnF1b3Q7ZXZlbnQmcXVvdDs6IHsmbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmcXVvdDtpZCZxdW90OzomcXVvdDs0NGY2MTQyZGY5NmJkNmFiNjFlNzUy MWQ5JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O2V4dGVuc2lv bnMmcXVvdDs6IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7 PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRS ZXNldEV4dDwvYT7igJ06DQogezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7JnF1b3Q7cmVzZXRBdHRlbXB0cyZxdW90Ozo1LDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPkluIHBhcnRpY3VsYXIsIGl0IG1ha2VzIGl0IGltcG9zc2libGUgdG8gc2lnbiBt dWx0aXBsZSByZWxhdGVkIGV2ZW50cyBzaGFyaW5nIGEgY29tbW9uIGNsYWltcyBzY2hlbWEgd2l0 aCBhIHNpbmdsZSBzaWduYXR1cmUgYnkgdGhlIGlzc3Vlci4mbmJzcDsgSXQgZm9yY2VzDQogdGhl IGlzc3VlciB0byBkbyB0aGUgZXh0cmEgd29yayBvZiBzaWduaW5nIGVhY2ggb2YgdGhlIHJlbGF0 ZWQgZXZlbnRzIChvciBmYWNldHMgb2YgdGhlIHNhbWUgbG9naWNhbCBldmVudCkgaW5kaXZpZHVh bGx5IGFuZCBmb3JjZXMgdGhlIHJlY2lwaWVudHMgdG8gZG8gdGhlIGV4dHJhIHdvcmsgb2YgY2hl Y2tpbmcgYWxsIHRob3NlIHVubmVjZXNzYXJ5IHNpZ25hdHVyZXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Tm90IGV2ZXJ5IHByb2ZpbGUgd2lsbCBldmVyIGhhdmUg bXVsdGlwbGUga2V5cyBpbiB0aGUg4oCcZXZlbnRz4oCdIHNldCBidXQgdGhlcmXigJlzIGFic29s dXRlbHkgbm8gcmVhc29uIHRvIHByZWNsdWRlIGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt LSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBu YW1lPSJtXy00Mzc3Nzg3NzU1ODczMjA4OTM1X19NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBJZC1ldmVudCBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZlbnQt Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRpY2sgSGFyZHQ8YnI+ DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAzMSwgMjAxNyA5OjUyIFBNPGJyPg0KPGI+ VG86PC9iPiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9h PiZndDs8YnI+DQo8Yj5DYzo8L2I+IFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5 YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj55YXJvbmYuaWV0ZkBnbWFpbC5j b208L2E+Jmd0OzsgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0 bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNv bTwvYT4mZ3Q7OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQt ZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7 Ow0KIFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVy IFNFVD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5QbGVhc2UgZGlyZWN0IG1lIHRvIGEgcHJvcG9zYWwgdGhhdCBoYXMgYSAm cXVvdDtwcmltYXJ5JnF1b3Q7IGFuZCAmcXVvdDtzZWNvbmRhcnkmcXVvdDsgZXZlbnRzLiBJIGFn cmVlIHRoYXQgaXMgdW5kZXNpcmFibGUuIEkgd291bGQgYWxzbyBlbmNvdXJhZ2UgdG8gZW5nYWdl IGluIHRoZSBkaXNjdXNzaW9ucyBzbyB0aGF0IHdlIGNhbiBkcml2ZQ0KIGNsYXJpdHkgYW5kIHNp bXBsaWNpdHkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SSB0aGluayB0aGUgcHJvcG9zYWwgaXMgdGhhdCB0aGVyZSBpcyBvbmUgZXZlbnQgcGVyIFNF VC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkkgdGhpbmsgaGF2aW5nIG1vcmUgdGhhbiBvbmUgZXZlbnQgcGVyIFNFVCBhZGRzIGNvbXBs ZXhpdHkgYXMgYSByZWNlaXZlciBtdXN0IGRlYWwgd2l0aCByZWNlaXZpbmcgY29ycmVsYXRlZCBl dmVudHMgaW4gb25lIFNFVCBhcyB3ZWxsIGFzIGNvcnJlbGF0ZWQgZXZlbnRzIGluIHRoZSBzYW1l IFNFVC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPi9EaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiBUdWUsIE9jdCAzMSwgMjAxNyBhdCA5OjQyIFBNLCBNaWtlIEpvbmVz ICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+SSBoZWFyIHlvdSBvbiB0aGUgZmFjdCB0aGF0IGRpZmZlcmVudCBwZW9wbGUg aGF2ZSBqb2luZWQgdGhlIGVmZm9ydCBhdCBkaWZmZXJlbnQgdGltZXMuJm5ic3A7IFRoYXTigJlz IGEgbm9ybWFsIHByb2Nlc3MgYXMgYW4gZWZmb3J0IGJ1aWxkcyBtb21lbnR1bS4mbmJzcDsgSSBn ZXQNCiB0aGF0IG5vdCBldmVyeW9uZSB3YXMgdGhlcmUgd2hlbiBwcmV2aW91cyBjb25zZW5zdXMg Y2FsbHMgd2VyZSB0YWtlbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij5JIHNob3VsZCBub3RlIHRoYXQgSSBoYXZlIHNwZWNpZmljIHRlY2huaWNhbCBvYmplY3Rpb25z IHRvIHRoZSBzcGVjaWZpYyBwcm9wb3NlZCBjaGFuZ2VzIGJlaW5nIGRpc2N1c3NlZCBhcyB3ZWxs LiZuYnNwOyBDdXJyZW50bHkgYWxsIGV2ZW50cyBpbiB0aGUgc2V0IGhhdmUNCiB0aGUgc2FtZSBz eW50YXguJm5ic3A7IFRoZSBwcm9wb3NhbHMsIGFzIEkgdW5kZXJzdGFuZCB0aGVtLCByZXZlcnQg dXMgdG8gYSBzdGF0ZSB3aGVyZSB0aGVyZeKAmXMgYSDigJxwcmltYXJ54oCdIGFuZCDigJxzZWNv bmRhcnnigJ0gZXZlbnRzLCB3aXRoIGRpZmZlcmVudCBzeW50YXggZm9yIHRoZSB0d28gY2xhc3Nl cy4mbmJzcDsgVGhhdOKAmXMgbmVlZGxlc3NseSBtb3JlIGNvbXBsaWNhdGVkLCBhZGRpbmcgbm8g YWN0dWFsIHZhbHVlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj5Gcm9tOjwvYj4gRGljayBIYXJkdCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0 QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPl0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDMxLCAyMDE3IDk6MzcgUE08YnI+DQo8 Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWls dG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xl LmNvbTwvYT4mZ3Q7OyBZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmll dGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+eWFyb25mLmlldGZAZ21haWwuY29tPC9hPiZn dDs7IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFu bmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0 OzsNCiBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRz IHBlciBTRVQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+TWlrZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkFzIHlvdSB3ZWxsIGtub3csIG1hbnkgcGVvcGxlIGluIGEgV0cgZG9u J3QgbG9vayBjbG9zZWx5IGF0IGEgc3BlY2lmaWNhdGlvbiB1bnRpbCBsYXN0IGNhbGwgaXMgbWFk ZS4gQWRkaXRpb25hbGx5LCB3ZSBhcmUgY29taW5nIHVwIG9uIG9ubHkgdGhlIDNyZCBXRyBtZWV0 aW5nLiBUaGUgV0cgaGFzIG5vdCBleGlzdGVkDQogZm9yIHZlcnkgbG9uZy4gV2hpbGUgc29tZSBv ZiB0aGUgcGFydGljaXBhbnRzIGhhdmUgYmVlbiB3b3JraW5nIG9uIHRoaXMgZm9yIGEgd2hpbGUs IG1hbnkgaGF2ZSBub3QsIGFuZCB3ZSBhcmUgbG9va2luZyBmb3IgY29uc2Vuc3VzIGFjcm9zcyB0 aGUgV0cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5TaW5jZSBTZWNFdmVudCBpcyBhIGZyYW1ld29yayB0aGF0IHdlIGV4cGVjdCB0byBi ZSBwcm9maWxlZCwgSSBmZWVsIGl0IGlzIGltcG9ydGFudCB0byBlbnN1cmUgdGhhdCBTZWNFdmVu dCBzcGVjaWZpY2F0aW9ucyBhcmUgZWFzeSBmb3IgYSB2YXJpZXR5IG9mIHByb2ZpbGVzIHRvIGFk b3B0LCBhbmQgdGhhdA0KIHRoZSBzZW1hbnRpY3MgbWFrZSBzZW5zZS4gSSBhbHNvIHRoaW5rIHRo YXQgcHJvcGVydGllcyB0aGF0IGFyZSBzcGVjaWZpYyB0byBhIHByb2ZpbGUgc2hvdWxkIGJlIGxl ZnQgdG8gdGhhdCBwcm9maWxlIGFuZCBub3QgYmUgaW5jbHVkZWQgaW4gU2VjRXZlbnQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TaW5j ZSB0aGlzIGlzIGEgZnJhbWV3b3JrLCBpdCBpcyBleHBlY3RlZCB0aGF0IGFzIGRpZmZlcmVudCBn cm91cHMgcHJvZmlsZSBpdCwgdGhlcmUgd2lsbCBiZSBhZGRpdGlvbmFsIGZlZWRiYWNrLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U3Bl Y2lmaWNhbGx5LCBhcyBhIHBhcnRpY2lwYW50IGluIHRoZSBSSVNDIHByb2ZpbGUgb2YgU0VULCBh IG51bWJlciBvZiBpc3N1ZXMgaW4gU0VUIGhhdmUgc3VyZmFjZWQgYXMgdGhlIFJJU0MgV0cgaGFz IGxvb2tlZCBhdCBob3cgdG8gdXNlIHRoZSBTRVQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBmb3IgU0VUIGJlaW5nIHN0YWJsZSBm b3Igb3ZlciBhIHllYXIsIHRoZXJlIGhhdmUgYmVlbiBhIG51bWJlciBvZiBjaGFuZ2VzIHRvIFNF VCBzaW5jZSB0aGVuLiBJIGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgd2FzIGNvbnNlbnN1cy4gQmVm b3JlIHRoZSBXRyB3YXMgZm9ybWVkLCBJIGFuZCBzZXZlcmFsIG90aGVycw0KIGhhZCBleHByZXNz ZWQgY29uY2VybiBvbiB0aGUgZGVzaWduIG9mIFNFVCB3aGVuIFBoaWwgcHJlc2VudGVkIGl0IGF0 IGFuIElJVyBzZXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+QXMgdG8gdGFraW5nIGFub3RoZXIgeWVhciwgSSBhbSBob3BlZnVs IHdlIGNhbiByZXNvbHZlIHRoZSByZW1haW5pbmcgaXNzdWVzIGluIFNFVCBhbmQgcHVibGlzaCBh IG5ldyBkcmFmdCBmb3IgbGFzdCBjYWxsLiBJIGRvIG5vdCB0aGluayB3ZSB3aWxsIG5lZWQgdG8g d2FpdCBmb3IgYW5vdGhlciBXRyBtZWV0aW5nDQogdG8gYXNrIGZvciBsYXN0IGNhbGwuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5XZSBhbHNvIGhhdmUgYSBudW1iZXIgb2Ygb3RoZXIgZG9jdW1lbnRzIHRoYXQgYXJlIG5vdCBp biBsYXN0IGNhbGwsIGFuZCB3ZSBkb24ndCBoYXZlIGEgV0cgYWRvcHRlZCBkcmFmdCB5ZXQgZm9y IG1hbmFnZW1lbnQuIFNvIHRoZXJlIGFyZSBzdGlsbCBhIG51bWJlciBvZiBkb2N1bWVudHMgdG8g d29yayB0aHJvdWdoDQogYmVmb3JlIHdlIGhhdmUgYWxsIHRoZSBiaXRzIGZvciBzb21lb25lIHRv IHdvcmsgd2l0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkkgZG8gdGhpbmsgd2UgaGF2ZSBiZWVuIG1ha2luZyBnb29kIHByb2dyZXNz IHNpbmNlIHRoZSBsYXN0IElFVEYgbWVldGluZywgYW5kIEkgYW0gaG9wZWZ1bCB3ZSBjYW4ga2Vl cCB1cCB0aGlzIG1vbWVudHVtIGFuZCBmaW5hbGl6ZSBhbGwgdGhlIGRvY3VtZW50cyBpbiBhIHRp bWVseSBtYW5uZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4vRGljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgT2N0IDMxLCAyMDE3IGF0IDEyOjQ4IFBN LCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SXTigJlzIGhhcmQgZm9yIG1lIHRvIGV2ZW4gZXhwcmVz cyBteSBsZXZlbCBvZiBmcnVzdHJhdGlvbiB3aXRoIHRoZSByZWNlbnQgYXR0ZW1wdHMgdG8gb25j ZSBhZ2FpbiByZWRlc2lnbiB0aGUgU2VjRXZlbnQgVG9rZW4gc3BlYy4mbmJzcDsgV2XigJl2ZSBi ZWVuIGF0IHRoaXMNCiBmb3IgbXVsdGlwbGUgeWVhcnMgYmVjYXVzZSBwZW9wbGUga2VlcCB0cnlp bmcgdG8gcmV2aXNpdCBkZWNpc2lvbnMgdGhhdCB3ZXJlIGxvbmcgYWdvIG1hZGUgYnkgY29uc2Vu c3VzLiZuYnNwOyBJdOKAmXMgYmVlbiBzdGFibGUgZm9yIG92ZXIgYSB5ZWFyIGFuZCB0aGUgbWFq b3JpdHkgb2YgV0dMQyByZXNwb25kZW50cyBzYWlkIHNvbWUgdmFyaWFudCBvZiDigJxXb3JrcyBm b3IgbWUg4oCTIHNoaXAgaXQh4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+VGhlcmXigJlzIG5vdCBzdWZmaWNpZW50IGp1c3RpZmljYXRpb24gdG8gdHJ5IHRvIHVu ZG8gY29uc2Vuc3VzIHBvc2l0aW9ucyB0aGF0IGhhdmUgYmVlbiBkZWJhdGVkIGFuZCBhZmZpcm1l ZCBvdmVyIGFuZCBvdmVyLiZuYnNwOyBDb3VudGVuYW5jaW5nIHdob2xlc2FsZSBjaGFuZ2VzDQog YXQgdGhpcyBsYXRlIGRhdGUgaXMgY291bnRlcnByb2R1Y3RpdmUgaW4gdGhlIGV4dHJlbWUhPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SXTigJlzIGZhciBiZXR0ZXIg dGhhbiBnb29kIGVub3VnaCBhcy1pcy4mbmJzcDsgSW4gbXkgZXhwZXJpZW5jZSwgaWYgd2Ugc3Rh cnQgcmVkZXNpZ25pbmcgaXQsIGl0IHdpbGwgcmVzdWx0IGluIGFub3RoZXIgeWVhcuKAmXMgZGVs YXkuJm5ic3A7IEl0IGRvZXMgc29tZXRoaW5nIHNpbXBsZQ0KIGFuZCB1c2VmdWwuJm5ic3A7IFBs ZWFzZSwgbGV04oCZcyBqdXN0IHNoaXAgaXQsIHNvIHBlb3BsZSBjYW4gcmVseSBvbiBpdC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8tNDM3Nzc4Nzc1NTg3MzIwODkzNV9tXy01MDEz ODU0ODYxNDEwMiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUGhpbCBIdW50IChJRE0pIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5o dW50QG9yYWNsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAz MCwgMjAxNyAyOjQyIFBNPGJyPg0KPGI+VG86PC9iPiBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJt YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdt YWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVm PSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+eWFyb25mLmll dGZAZ21haWwuY29tPC9hPiZndDs7IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBo cmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5h QGFtYXpvbi5jb208L2E+Jmd0OzsgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbTwvYT4mZ3Q7Ow0KIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9 Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYu b3JnPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZv ciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW5saW5l Li4uPGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpPbiBPY3QgMzAsIDIwMTcsIGF0IDI6MjIgUE0sIERpY2sgSGFyZHQg Jmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIFBoaWw8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Db3JyZWN0IG1lIGlm IEkgYW0gbWlzdW5kZXJzdGFuZGluZywgYnV0IHRoZXJlIGlzIGEgUklTQyBwcm9maWxlIGV2ZW50 Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1z cGFjZTpwcmUtd3JhcCI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRl LXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+JnF1b3Q7PGEg aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0Ff X3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV8tMjU1QyZhbXA7 ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0pu RSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDtt PWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmYW1wO3M9MjVsMDlz SDhZVjQyeHpnVS1DWFNnOHhIOXR2eURKejQwdENSakZhbGhrdyZhbXA7ZT0iIHRhcmdldD0iX2Js YW5rIj5odHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS88 L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+YWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJl ZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj7igJ08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5hbmQgYW4gU0NJTSBwcm9maWxlIGV2 ZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id2hpdGUt c3BhY2U6cHJlLXdyYXAiPiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9l dmVudC9wYXNzd29yZFJlc2V0RXh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9leGFtcGxlLmNv bS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQ8L2E+4oCdPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ20gc3VnZ2VzdGluZyB0aGF0 IHR3byBkaWZmZXJlbnQgZXZlbnRzIHdvdWxkIGJlIHNlbnQuIEVtYmVkZGluZyBvbmUgaW4gdGhl IG90aGVyIGRvZXMgbm90IG1ha2Ugc2Vuc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZsdDtwaCZn dDtJdCBpcyBhIGh5cG90aGV0aWNhbCBleGFtcGxlLiBKdXN0IGJlY2F1c2UgeW91IGRpc2FncmVl IG9uIHRoaXMgZG9lcyBub3QgbWVhbiBvdGhlcnMgYXJlIG5vdCB2YWxpZC4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGp1c3QgcGlja2Vk IG92ZXJsYXBwaW5nIHByb3Bvc2FscyB0aGF0IGhhdmUgZGlmZmVyZW50IG1lYW5pbmcgKGJ1dCBu b3QgdGhlIHNhbWUpIHRvIGlsbHVzdHJhdGUgdGhlIGRpZmZlcmVuY2UgZnJvbSBpc3N1aW5nIGEg c2luZ2xlIHNldCB3aXRoIGRpZmZlcmVudCBldmVudHMuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5BcyBJIGhhdmUgc3RhdGVkIHRoaXMg aXMgdmVyeSBkaWZmZXJlbnQgZnJvbSBhc3NlcnRpbmcgbXVsdGlwbGUgZGlzdGluY3QgZXZlbnRz IGluIG9uZSBTRVQuJm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsc28sIEkgdGhpbmsgaXQgaXMgc2ltcGxlciB0 byBoYXZlIGV2ZW50X3R5cGUgYmUgYXQgdGhlIHNhbWUgbGV2ZWwgYXMgZXZlbnQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPiZsdDtwaCZndDttYXkgYmUuIEkgd2FzIHdvcmtpbmcgZnJvbSBBbm5hYmVsbGUn cyBwcm9wb3NlZCBmb3JtYXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPns8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZxdW90O2p0aSZxdW90Ozog JnF1b3Q7M2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAmcXVvdDssPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmcXVvdDtp YXQmcXVvdDs6IDE0NTg0OTYwMjUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmcXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9 Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vc2NpbS5l eGFtcGxlLmNvbTwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmcXVvdDthdWQmcXVvdDs6IFs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAm cXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTVi YmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9G ZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmcXVv dDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2 NDFkNzY3NmVlNyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVk cy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3PC9hPiZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7XSw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZu YnNwOyZxdW90O2V2ZW50X3R5cGUmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vZXhhbXBs ZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQ8L2E+JnF1b3Q7LDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsg Jm5ic3A7JnF1b3Q7ZXZlbnQmcXVvdDs6IHsmbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZxdW90O2lkJnF1b3Q7OiZxdW90OzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIx ZDkmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtyZXNldEF0dGVt cHRzJnF1b3Q7OjU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij59PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij57PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmcXVvdDtqdGkmcXVv dDs6ICZxdW90OzNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwJnF1b3Q7LDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJnF1 b3Q7aWF0JnF1b3Q7OiAxNDU4NDk2MDI1LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBo cmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Nj aW0uZXhhbXBsZS5jb208L2E+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiBbPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJz cDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYx ZmE1YmJjODc5NTkzYjc3NTQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2podWIuZXhhbXBsZS5j b20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NDwvYT4mcXVvdDssPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsg JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIx ZDA4NjQxZDc2NzZlZTciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2podWIuZXhhbXBsZS5jb20v RmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNzwvYT4mcXVvdDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwO10sPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyAmbmJzcDsmcXVvdDtldmVudF90eXBlJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVuaWQu bmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlX2FjY291bnQtMkRjcmVkZW50aWFsLTJEY2hh bmdlLTJEcmVxdWlyZWQmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpo OEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBr QUkxYUxjTE40S1pOQSZhbXA7bT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4 X3FTQ193JmFtcDtzPW5ReTllelBSakRHZHZSVENhaUR0aTRPSGVsSDNES2dVQ1RLakYyR1Etc28m YW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NjaGVtYXMub3BlbmlkLm5ldC9zZWNldmVu dC9yaXNjL2V2ZW50LXR5cGUvYWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZDwvYT4m cXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyAmbmJzcDsmcXVvdDtldmVudCZxdW90Ozogezwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDvigJxzdWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO+KAnGlzc+KAnTomcXVvdDs8YSBocmVmPSJodHRwczovL2lkcC5leGFtcGxlLmNvbS8iIHRh cmdldD0iX2JsYW5rIj5odHRwczovL2lkcC5leGFtcGxlLmNvbS88L2E+JnF1b3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgT2N0IDMwLCAyMDE3IGF0IDEyOjA5IFBNLCBQaGls IEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Bbm5hYmVsbGUvRGljayw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBm b3IgdGhlIGNvbW1lbnRzLiBJIHRoaW5rIHdlIG5lZWQgdG8gZXhhbWluZSB0aGUgY29uc2VxdWVu Y2VzIG9mIHRoZSBwcm9wb3NhbCBpbiBKU09OLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBJIHN0YXRlZCwgd2hhdCBjYXVzZXMgbW9zdCBvZiB0 aGUgaXNzdWUgaXMgdGhlIHByb3Bvc2VkIGV4dGVuc2lvbiBtZWNoYW5pc20gaW4gdGhlIHBheWxv YWQgKHBvc3NpYmx5IHVzaW5nIGV2ZW50cyBpbiBhIHJlY3Vyc2l2ZSB3YXkpLiBEb2VzIGl0IGZv bGxvdyB0aGUgb2xkIGZvcm1hdCBvciB0aGUgbmV3PzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkxldOKAmXMgJm5ic3A7Y29uc2lkZXIgYSB1c2UgY2Fz ZSB3aGVyZSB3ZSBoYXZlIGFuIGlkZW50aXR5IG1hbmFnZW1lbnQgc3lzdGVtIHRoYXQgdXNlcyBT Q0lNLCBidXQgdGhlIFNDSU0gc3lzdGVtIGlzIGFsc28gdGhlIHVuZGVybHlpbmcgZGF0YSBzdG9y ZSBmb3IgQ29ubmVjdC4mbmJzcDsgQSBQYXNzd29yZCByZXNldCBtaWdodA0KIGdlbmVyYXRlIHRo ZSBmb2xsb3dpbmcgZXZlbnQgd2hpY2ggaGFzIGFuIGV4dGVuc2lvbiAoY29udmV5aW5nIHJlc2V0 IGNvdW50KSBBTkQgb3ZlcmxhcHBpbmcgc3RhdGVtZW50IGZyb20gUklTQy4mbmJzcDsgQk9USCBv ZiB3aGljaCBtaWdodCBiZSBpbXBvcnRhbnQgdG8gYSBzaW1pbGFyIHJlY2VpdmVyIHVzaW5nIFND SU0gYW5kIE9JREMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+VGhlIDAzIHNwZWMgY3VycmVudGx5IHdvdWxkIGFsbG93 OjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPns8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsgJnF1b3Q7anRpJnF1b3Q7OiAmcXVvdDszZDBjM2NmNzk3NTg0 YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsg JnF1b3Q7aWF0JnF1b3Q7OiAxNDU4NDk2MDI1LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyAmcXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbTwvYT4mcXVvdDssPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZxdW90O2F1ZCZxdW90OzogWzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2po dWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5 M2I3NzU0PC9hPiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUx NmIxZDA4NjQxZDc2NzZlZTciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2podWIuZXhhbXBsZS5j b20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNzwvYT4mcXVvdDs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgXSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsgJnF1b3Q7ZXZlbnRzJnF1b3Q7OiB7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3VybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3 b3JkUmVzZXQmcXVvdDs6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHsgJnF1b3Q7aWQmcXVvdDs6JnF1b3Q7NDRmNjE0MmRmOTZiZDZh YjYxZTc1MjFkOSZxdW90O30sPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9w YXNzd29yZFJlc2V0RXh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9leGFtcGxlLmNvbS9zY2lt L2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQ8L2E+JnF1b3Q7OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB7ICZxdW90O3Jlc2V0QXR0ZW1w dHMmcXVvdDs6NX0sPG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVu aWQubmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlXy0yNTVDJmFtcDtkPUR3TUZhUSZhbXA7 Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZW ekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209aXlWbnJabXI5X3VH Q1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZhbXA7cz0yNWwwOXNIOFlWNDJ4emdVLUNY U2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9z Y2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL1w8L2E+PGJyPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FjY291bnQtY3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWQm cXVvdDs6IHs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyDigJxzdWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcaXNz4oCdOiZxdW90Ozwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+PGEgaHJlZj0iaHR0cHM6Ly9pZHAuZXhhbXBs ZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vPC9hPiZxdW90 Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyB9 PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij59PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+SW4gdGhlIGFib3ZlIC0gZWFjaCBwYXlsb2FkIGlzIGEg4oCYcGVlcicgYW5k IGlzc3VlZCB3aXRob3V0IHByZWZlcmVuY2UgYnkgdGhlIHRyYW5zbWl0dGVyLiBUaGUgcmVjZWl2 ZXIgY2FuIGFzc2lnbiBwcmlvcml0eSBpbiBpdHMgb3duIGNvbnRleHQgaWYgdGhhdCBtYXR0ZXJz Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgbmV3IHByb3Bvc2FsOjwvc3Bhbj48 L2I+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7PG86cD48L286 cD48L3ByZT4NCjxwcmU+ezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmcXVvdDtqdGkm cXVvdDs6ICZxdW90OzNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwJnF1b3Q7LDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmcXVvdDtpYXQmcXVvdDs6IDE0NTg0OTYwMjUsPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZxdW90O2lzcyZxdW90OzogJnF1b3Q7PGEgaHJl Zj0iaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zY2lt LmV4YW1wbGUuY29tPC9hPiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgJnF1 b3Q7YXVkJnF1b3Q7OiBbPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZh NWJiYzg3OTU5M2I3NzU0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29t L0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQ8L2E+JnF1b3Q7LDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIu ZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2 ZWU3PC9hPiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBdLDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAmcXVvdDtldmVudCZxdW90OzogezxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxldmVudF90eXBl 4oCdOiZxdW90O3VybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3JkUmVzZXTigJ0sPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2lkJnF1 b3Q7OuKAnTQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDnigJ0sPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGV2ZW50c+KAnTp7PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0mZ3Q7bm90ZSDigKZpcyB0aGlzIHRo ZSBvbGQgb3IgbmV3IHN0cnVjdHVyZT8gJmx0Oy08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9l eGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwvYT4mcXVvdDs6 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHsgJnF1b3Q7cmVzZXRBdHRlbXB0cyZxdW90Ozo1fSw8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2Vj ZXZlbnRfcmlzY19ldmVudC0yRHR5cGVfLTI1NUMmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdO eTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1peVZuclptcjlfdUdDUTZNRDB6RjJ5 bVJRUzZsSzY3eUZfOHU4X3FTQ193JmFtcDtzPTI1bDA5c0g4WVY0Mnh6Z1UtQ1hTZzh4SDl0dnlE Sno0MHRDUmpGYWxoa3cmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NjaGVtYXMub3Bl bmlkLm5ldC9zZWNldmVudC9yaXNjL2V2ZW50LXR5cGUvXDwvYT48YnI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7YWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJl ZCZxdW90Ozogezwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IOKAnHN1YuKAnTrigJ03Mzc1NjI2QTY1NjM3NOKAnSw8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxpc3PigJ06JnF1b3Q7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij48YSBocmVmPSJodHRwczovL2lkcC5leGFt cGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2lkcC5leGFtcGxlLmNvbS88L2E+JnF1 b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyB9PC9zcGFuPiZuYnNwOyZuYnNw OyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPkluIHRoZSBhYm92ZSwgc3ViLWV2ZW50cyBvciBleHRlbnNpb25zIGhhdmUg YSBkaWZmZXJlbnQgZm9ybWF0LiBUaGUgc2FtZSBjb21wbGFpbnQgYWJvdXQgdGhlIG9yaWdpbmFs IHN0YW5kcy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj4qT1IqIChpZiB0aGUgcmVjZWl2ZXIgY2FyZXMgYWJvdXQgUklTQyBt b3JlKS4mbmJzcDsgTm90ZSB0aGF0IHRoaXMgbGVhZHMgdG8gYSB0cmlwbGUgbmVzdGVkIHN0cnVj dHVyZS48L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPns8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgJnF1b3Q7anRpJnF1 b3Q7OiAmcXVvdDszZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90Oyw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OiAxNDU4NDk2MDI1LDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmcXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9 Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vc2NpbS5l eGFtcGxlLmNvbTwvYT4mcXVvdDssPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZxdW90 O2F1ZCZxdW90OzogWzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyAm cXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTVi YmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9G ZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0PC9hPiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4 YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVl NzwvYT4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgXSw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgJnF1b3Q7ZXZlbnQmcXVvdDs6IHs8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXZlbnRfdHlwZeKA nTo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3Blbmlk Lm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV8tMjU1QyZhbXA7ZD1Ed01GYVEmYW1wO2M9 Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpC VFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NR Nk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmYW1wO3M9MjVsMDlzSDhZVjQyeHpnVS1DWFNn OHhIOXR2eURKejQwdENSakZhbGhrdyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc2No ZW1hcy5vcGVuaWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS9cPC9hPjwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDsg Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDth Y2NvdW50LWNyZWRlbnRpYWwtY2hhbmdlLXJlcXVpcmVkPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij7igJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTMuNXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCc c3Vi4oCdOuKAnTczNzU2MjZBNjU2Mzc04oCdLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A74oCcaXNz4oCdOiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PGEgaHJlZj0iaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20v4oCcIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20v4oCcPC9hPiw8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyDigJxldmVudHPigJ06ezwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3VybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3Jk UmVzZXQmcXVvdDs6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgeyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7aWQmcXVvdDs64oCd NDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOeKAnSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXZl bnRz4oCdOns8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEg aHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNl dEV4dDwvYT4mcXVvdDs6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHsgJnF1b3Q7cmVzZXRBdHRlbXB0cyZxdW90Ozo1fSw8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdCI+Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTwvc3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308bzpwPjwvbzpwPjwvcHJlPg0KPC9k aXY+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDt9PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij59PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8ZGl2Pg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPkluIHRoZSBhYm92ZSwgdGhlIGV4dGVuc2lvbiBpcyBwbGFjZWQgaW5zaWRlIHRoZSBldmVu dCBpdCBleHRlbmRzLiBJdCBmb2xsb3dzIHRoZSBvbGQgZm9ybWF0IChvciBzaG91bGQgaXQgZm9s bG93IHRoZSBuZXc/KTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHBy ZT48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPipPUiogRm9sbG93aW5nIHRoZSB0b3AgbGF5ZXIgcGF0dGVybiBvZiBzaW5ndWxhciBl dmVudCZuYnNwOyBOb3RlIHRoYXQgdGhpcyBsZWFkcyB0byBhIHRyaXBsZSBuZXN0ZWQgc3RydWN0 dXJlLjwvc3Bhbj48L2I+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+ezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmcXVvdDtqdGkmcXVv dDs6ICZxdW90OzNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwJnF1b3Q7LDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmcXVvdDtpYXQmcXVvdDs6IDE0NTg0OTYwMjUsPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZxdW90O2lzcyZxdW90OzogJnF1b3Q7PGEgaHJlZj0i aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zY2ltLmV4 YW1wbGUuY29tPC9hPiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgJnF1b3Q7 YXVkJnF1b3Q7OiBbPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJi Yzg3OTU5M2I3NzU0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0Zl ZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQ8L2E+JnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhh bXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3 PC9hPiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBdLDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAmcXVvdDtldmVudCZxdW90OzogezxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxldmVudF90eXBl4oCd OjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij4mcXVvdDs8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVuaWQu bmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlXy0yNTVDJmFtcDtkPUR3TUZhUSZhbXA7Yz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJU V21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209aXlWbnJabXI5X3VHQ1E2 TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZhbXA7cz0yNWwwOXNIOFlWNDJ4emdVLUNYU2c4 eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zY2hl bWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL1w8L2E+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO2FjY291bnQtY3JlZGVudGlhbC1jaGFuZ2UtcmVxdWly ZWQ8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+4oCdLDwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IOKAnHN1YuKAnTrigJ03Mzc1NjI2QTY1NjM3NOKAnSw8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGlz c+KAnTomcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJlZj0iaHR0cHM6 Ly9pZHAuZXhhbXBsZS5jb20v4oCcIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9pZHAuZXhhbXBs ZS5jb20v4oCcPC9hPiw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxldmVu dOKAnTp7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCc ZXZlbnRfdHlwZeKAnTomcXVvdDt1cm46aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpwYXNzd29yZFJl c2V04oCdLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj4mcXVvdDtpZCZxdW90OzrigJ00NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ54oCdLDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyDigJxldmVudOKAnTp7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGV2ZW50X3R5cGXigJ06 JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVz ZXRFeHQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFz c3dvcmRSZXNldEV4dDwvYT7igJ0sPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3Jlc2V0QXR0 ZW1wdHMmcXVvdDs6NTxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij4gPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDt9PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgZm9ybWF0IGZvbGxvd3MgdGhlIHByb3Bvc2VkIHNp bmd1bGFyIGV2ZW50IGZvcm1hdCByZWN1cnNpdmVseSBhbmQgaXMgMyBsYXllcnMgZGVlcC4gTm90 ZSB0aGF0IHRoZSBwYXJzZXIgaGFzIHRvIGNvbnRpbnVlIHRvIHNlYXJjaCB0aGUgZG9jdW1lbnQg Zm9yIHRoaW5ncyB0aGF0IGFyZW7igJl0IHRoZXJlIGFzIGl0IGhhcyB0byBzdG9wIHdoZW4gbm8g 4oCcZXZlbnTigJ0gYXR0cmlidXRlIGlzIGZvdW5kIHJhdGhlciB0aGFuIGl0ZXJhdGUgb3ZlciBh biBhcnJheS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPHByZT4mbmJzcDs8bzpw PjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QaGls PGJyPg0KPGJyPg0KT3JhY2xlIENvcnBvcmF0aW9uLCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNlcyBB cmNoaXRlY3Q8YnI+DQpAaW5kZXBlbmRlbnRpZDxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5j b20mYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1 ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pO QSZhbXA7bT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JmFtcDtz PTlzWWhncEV6Yjd4UGxRRm1DQ1hObUhvNmZRTjlJQnUtU0hKYW1nX0I0SHMmYW1wO2U9IiB0YXJn ZXQ9Il9ibGFuayI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxicj4NCjxhIGhyZWY9Im1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUu Y29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbiBPY3QgMzAsIDIwMTcsIGF0IDg6NTcgQU0sIFJpY2hhcmQgQmFj a21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJj b2xvcjojQzM0NkUwIj5SZXBsaWVzIGlubGluZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFy ZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5JZGVu dGl0eSBTZXJ2aWNlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3Vu ZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Gcm9tOjxzcGFuIGNsYXNzPSJt LTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2 MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UGhpbCBIdW50ICZs dDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+ Jmd0Ozxicj4NCjxiPkRhdGU6PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAx Mzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+U3VuZGF5LCBPY3RvYmVyIDI5 LCAyMDE3IGF0IDU6MjUgUE08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODcz MjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1 NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5EaWNrIEhh cmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvc3Bh bj48L2E+Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVt LTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5 NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPllhcm9uIFNoZWZmZXIg Jmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L3NwYW4+ PC9hPiZndDssDQogTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0OywgJnF1b3Q7UmljaGFy ZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBh bWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cmlj aGFubmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+Jmd0OywNCiBJRCBFdmVudHMgTWFpbGluZyBMaXN0 ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAx Mzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UmU6IFtJZC1ldmVudF0gVXNl IGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD88L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCkkg aG9wZSB0aGlzIGFuc3dlcnMgeW91ciBxdWVzdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndo aXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KTXkg4oCcbWF54oCd IHdhcyBiZWNhdXNlIEkgY2Fu4oCZdCBzZWUgYSByZWFzb24gd2h5IG5vdC4gVGhlIHF1ZXN0aW9u IHNob3VsZCBiZSwgd2hhdCBpcyB0aGUganVzdGlmaWNhdGlvbiB0byBtYWtlIOKAnGV2ZW50c+KA nSBzaW5ndWxhcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojQzM0NkUwIj5b cmljaGFubmFdVGhlIHNpbmd1bGFyIOKAnGV2ZW504oCdIGNsYWltIGhhcyBjbGVhcmVyIHNlbWFu dGljcyBhbmQgaXMgZWFzaWVyIHRvIHByb2Nlc3MuIFdlIHNob3VsZCBvcHQgZm9yIGVhc2llciBz b2x1dGlvbnMgdW5sZXNzIHRoZXJlIGFyZSB1c2UgY2FzZXMgdGhhdCByZXF1aXJlIG1vcmUgY29t cGxleGl0eS5bL3JpY2hhbm5hXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4N CiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KVGhlcmUgYXJlIG1hbnkgcmVh c29ucyBmb3IgbXVsdGlwbGUgZXZlbnRzIGluIGEgU0VULiZuYnNwOyBTb21lIGFyZSBnb29kLCBz b21lIG5vdCBzbyBnb29kLiBTb21lIG9mIHRoZSByZWFzb25zLi4uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjEuJm5i c3A7IE11bHRpcGxlIGV2ZW50IHBheWxvYWRzIGV4cHJlc3Npbmcgc3RhdGVtZW50cyBhYm91dCBs YXJnZWx5IHRoZSAqc2FtZSp0aGluZy4gRm9yIGV4YW1wbGUsIFNDSU0gcGFzc3dvcmQgcmVzZXQg QU5EIFJJU0MgcGFzc3dvcmQgcmVzZXQuJm5ic3A7IEEgUklTQyBFdmVudCBhbmQgYW4gT3BlbkJh bmtpbmcgRXZlbnQuIElzIG9uZSBhIGNvbXBsZW1lbnQgdG8gdGhlIG90aGVyPyZuYnNwOyBEbyB0 aGV5IG92ZXJsYXAgb3IgYXJlIHRoZXkgZGlzdGluY3Q/ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPltyaWNoYW5uYV1Db3B5L3Bhc3RlZCBmcm9tIG15 IGVhcmxpZXIgZW1haWw6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OiNDMzQ2RTAiPldoeSBpcyBpdCBuZWNlc3Nhcnkgb3IgYXBwcm9wcmlhdGUgdG8gaW5jbHVkZSB0 aGVzZSBldmVudHMgaW4gdGhlIHNhbWUgU0VUPyBUaGV5IGFyZSBsaWtlbHkgYmVpbmcgZ2VuZXJh dGVkIGJ5IGRpZmZlcmVudCBzeXN0ZW1zIGF0IGRpZmZlcmVudCB0aW1lcyBvbiB0aGUgdHJhbnNt aXR0ZXLigJlzIHNpZGUsIGNvbnN1bWVkIGJ5IGRpZmZlcmVudCBzeXN0ZW1zIG9uIHRoZSByZWNl aXZlcuKAmXMgc2lkZSwNCiBhbmQgcG9zc2libHkgYmVpbmcgdHJhbnNtaXR0ZWQgb3ZlciBkaWZm ZXJlbnQgZXZlbnQgc3RyZWFtcy4gSSBrbm93IHRoZSBsYXR0ZXIgd291bGQgYmUgdGhlIGNhc2Ug Zm9yIHVzLCBhcyBhIHJlY2VpdmVyLiBFdmVuIGlmIGl04oCZcyBub3QsIGlzIGl0IGJ1cmRlbnNv bWUgdG8gc2VuZCB0aGVzZSBldmVudHMgc2VwYXJhdGVseT8gV2hhdCB2YWx1ZSBpcyBnYWluZWQg aW4gY29tYmluaW5nIHRoZW0/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNv bG9yOiNDMzQ2RTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJj b2xvcjojQzM0NkUwIj5BZGRpdGlvbmFsbHksIHNpbmNlIHRoZSBzaWduYXR1cmUgaXMgb3ZlciB0 aGUgU0VUIGFuZCBub3QgdGhlIGV2ZW50IG9iamVjdHMsIFJlY2VpdmVycyBpbmRlcGVuZGVudGx5 IHJvdXRlIHNlcGFyYXRlIGV2ZW50cyBmcm9tIGEgc2luZ2xlIHRva2VuIHdpdGhvdXQgZWl0aGVy IGxvc2luZyB0aGUgYWJpbGl0eSB0byB2ZXJpZnkgdGhlIGF1dGhlbnRpY2l0eSBvZiB0aGUgZXZl bnQgb3Igc2hhcmluZyBhbGwNCiBpbmZvcm1hdGlvbiBpbiB0aGUgU0VUIHdpdGggZXZlcnkgc3lz dGVtIGhhbmRsaW5nIGFueSBldmVudCBpbiB0aGUgdG9rZW4uWy9yaWNoYW5uYV08L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6I0MzNDZFMCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0O2JhY2tncm91bmQ6d2hpdGUiPg0KMi4mbmJzcDsgTXVsdGlwbGUgZXZlbnRzIHBheWxvYWRz IGV4cHJlc3NpbmcgZGlmZmVyZW50IHN0YXRlbWVudHMgYWJvdXQgdGhlIHNhbWUgdHJhbnNhY3Rp b24gLSBSSVNDIFBhc3N3b3JkIFJlc2V0IGFuZCBSSVNDIFNlc3Npb24gQ2FuY2VsPGJyPg0KPHNw YW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPltyaWNoYW5uYV1TYW1lIGFzIGFib3ZlWy9yaWNoYW5u YV08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQozLiZuYnNwOyBBIG5ldyBw cm9maWxlIGRlZmluZXMgbmV3IGV2ZW50IGF0dHJpYnV0ZXMgdG8gYmUgYWRkZWQgb24gdG8gYW4g ZXhpc3RpbmcgZXZlbnQgdHlwZSAoYSBwdXJlIGV4dGVuc2lvbikmbmJzcDs8YnI+DQo8c3BhbiBz dHlsZT0iY29sb3I6I0MzNDZFMCI+W3JpY2hhbm5hXUkgaGF2ZSBzdWdnZXN0ZWQgYSB3YXkgdG8g c3VwcG9ydCBleHRlbnNpb25zIHdpdGhpbiBhbiBldmVudCBib2R5LCBtdWx0aXBsZSB0aW1lcyBu b3cuIElmIHlvdSBzZWUgcHJvYmxlbXMgd2l0aCBpdCwgcGxlYXNlIHBvaW50IHRoZW0gb3V0Llsv cmljaGFubmFdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQpJIHRoaW5rIGl0IGlzIHF1aXRlIHZhbGlkIHRv IGFsbG93IDEgYW5kIDMuICZuYnNwOzIgY291bGQgYmUgbGltaXRlZCBieSBzcGVjaWZpYyBwcm9m aWxlcyBsaWtlIFJJU0MgaWYgdGhleSB3YW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQpJIGFtIG5vdCBpbiBhZ3Jl ZW1lbnQgdGhhdCBtYWtpbmcgZXZlbnQgc2luZ3VsYXIgc2ltcGxpZmllcyBhbnl0aGluZy4gRm9y IG9uZSBpcyBtYWtlcyBleHRlbnNpb25zIGNvbXBsZXggKGFub3RoZXIgbmVzdGVkIEpTT04gc3Ry dWN0dXJlKSBhbmQgcG90ZW50aWFsbHkgY29uZmxpY3RpbmcuJm5ic3A7PGJyPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiNDMzQ2RTAiPltyaWNoYW5uYV08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3Bh biBzdHlsZT0iY29sb3I6I0MzNDZFMCI+V2F5cyB0aGF0IG11bHRpcGxlLWV2ZW50IFNFVHMgYXJl IG1vcmUgY29tcGxpY2F0ZWQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8b2wgc3Rh cnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojQzM0 NkUwO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwxIGxldmVsMSBsZm8xO2JhY2tncm91bmQ6d2hpdGUiPg0KSXQgcmVzdWx0cyBpbiBh IG1vcmUgY29tcGxleCBzdHJ1Y3R1cmUgZm9yIHRoZSBzaW5nbGUgZXZlbnQgdXNlIGNhc2UsIHdo aWNoIEkgdGhpbmsgd2UgYWxsIGFncmVlIGlzIHRoZSBtYWpvcml0eSB1c2UgY2FzZS48bzpwPjwv bzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojQzM0NkUwO21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omwx IGxldmVsMSBsZm8xO2JhY2tncm91bmQ6d2hpdGUiPg0KTXVsdGlwbGUtZXZlbnQgU0VUcyBoYXZl IGFtYmlndW91cyBzZW1hbnRpY3MuIFRoZSBwcmVzZW5jZSBvZiB0d28gZXZlbnRzIEEgYW5kIEIg aW4gdGhlIHNhbWUgU0VUIGNvdWxkIG1lYW4gYW55IG9mOjxvOnA+PC9vOnA+PC9saT48L29sPg0K PG9sIHN0YXJ0PSIyIiB0eXBlPSIxIj4NCjxvbCBzdGFydD0iMSIgdHlwZT0iYSI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiNDMzQ2RTA7bXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzI7YmFj a2dyb3VuZDp3aGl0ZSI+DQpUaGV5IGFyZSByZWxhdGVkIHRvIHRoZSBzYW1lIGxvZ2ljYWwgZXZl bnQgKGkuZS4gdGhlIHNhbWUgdGhpbmcgYXMgaWYgdGhleSB3ZXJlIGZyb20gZGlmZmVyZW50IFNF VHMgdGhhdCBoYXZlIGEgY29tbW9uIHR4bikuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY29sb3I6I0MzNDZFMDttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDIgbGZvMjtiYWNrZ3JvdW5k OndoaXRlIj4NCkEgaXMgYW4gZXh0ZW5zaW9uIG9mIEIuPG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6I0MzNDZFMDttc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDIgbGZvMjtiYWNr Z3JvdW5kOndoaXRlIj4NCkIgaXMgYW4gZXh0ZW5zaW9uIG9mIEEuPG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6I0MzNDZFMDttc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDIgbGZv MjtiYWNrZ3JvdW5kOndoaXRlIj4NClRoZXkgYXJlIGFsaWFzZXMgZm9yIG9uZSBhbm90aGVyLjxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiNDMzQ2RTA7 bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDIgbGV2ZWwyIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSI+DQpUaGV5IGFyZSBub3QgYWN0dWFs bHkgcmVsYXRlZCB0byBvbmUgYW5vdGhlciBpbiBhbnkgd2F5LjxvOnA+PC9vOnA+PC9saT48L29s Pg0KPC9vbD4NCjxvbCBzdGFydD0iMyIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImNvbG9yOiNDMzQ2RTA7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzM7YmFja2dyb3VuZDp3aGl0ZSI+ DQpDbGFpbSBzZW1hbnRpY3MgYmVjb21lIGhhcmRlciB0byBkZWZpbmUsIGFzIGRpZmZlcmVudCBw cm9maWxlcyBtYXkgd2FudCB0byB1c2UgdGhlIHNhbWUgY2xhaW1zIGluIGRpZmZlcmVudCB3YXlz LjxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91 bmQ6d2hpdGUiPg0KSWYgdGhlIFdHIHdhbnRzIHRvIGJsb2NrIDEgYW5kIDIgYWJvdmUsIHRoZW4g SSBiZWxpZXZlIHdlIGhhdmUgdG8gZXN0YWJsaXNoIGFuIGV2ZW50IHJlZ2lzdHJ5IHRvIGVuc3Vy ZSBuZXcgRXZlbnQgcHJvZmlsZXMgZG8gbm90IG92ZXJsYXAgdG8gZWxpbWluYXRlIHRoZSBuZWVk IHRvIGV4cHJlc3MgbXVsdGlwbGUgZXZlbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPltyaWNoYW5uYV1J4oCZbSBub3Qgc3VyZSB3 aGF0IHlvdSBtZWFuIGJ5IHRoaXMuIEFyZSB5b3UgcmVmZXJyaW5nIHRvIGV2ZW50IG5hbWVzPyBU aG9zZSBhcmUgYWxyZWFkeSBkZWZpbmVkIGJ5IHRoZSBzcGVjIHRvIGJlIFVSSXMuWy9yaWNoYW5u YV08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQpQaGls PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkgQ2xvdWQgU2VydmljZXMg QXJjaGl0ZWN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQpAaW5kZXBlbmRlbnRpZDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNvbSZh bXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJ X0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFt cDttPVUtYTVIQk5EMEhhVFg0YW5OWmZ6WDdwRHNmSzVmMGg5bVo5Q1pra0dpZWMmYW1wO3M9S0J3 S1BGbnFZX1E5NUNUQV9fV0dDWUdUeHJEN0FHQ3h1ZW9QWG5LRVVUMCZhbXA7ZT0iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53d3cuaW5kZXBlbmRlbnRpZC5jb208 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+ DQo8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tn cm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KT24g T2N0IDI5LCAyMDE3LCBhdCA0OjEyIFBNLCBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86 ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Jh Y2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPlBoaWw6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPkluIHlvdXIgZXhhbXBsZXMgZm9yIGhhdmluZyBhIHBsdXJhbGl0 eSBvZiBldmVudHMsIHlvdSB1c2UgdGhlIHdvcmQgJnF1b3Q7bWF5JnF1b3Q7LCB3aGljaCBsZWFk cyBtZSB0byBxdWVzdGlvbiBpZiBhIHBsdXJhbGl0eSBvZiBldmVudHMgaXMgcmVhbGx5IHJlcXVp cmVkIGluIFNFVC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5Zb3UgcG9zaXQgdGhhdCBpdCB3aWxsIGJlIGRpZmZpY3VsdCBmb3Ig YSBkaXN0cmlidXRlZCBzeXN0ZW0gdG8gY29ycmVsYXRlIG11bHRpcGxlIFNFVHMgd2l0aCB0aGUg c2FtZSAmcXVvdDt0eG4mcXVvdDssIGJ1dCB0aGUgZGlzdHJpYnV0ZWQgc3lzdGVtIHdpbGwgY2Vy dGFpbmx5IG5lZWQgdG8gY29ycmVsYXRlIGV2ZW50cyBvbiB0aGUgc2FtZSBzdWJqZWN0DQogLS0g Y29ycmVsYXRpbmcgZXZlbnRzIG9uIHRoZSBzYW1lICZxdW90O3R4biZxdW90OyBvbiB0aGUgc2Ft ZSBzdWJqZWN0IHNlZW1zIGZhaXJseSBzaW1wbGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91 bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Jh Y2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSB0aGluayB0aGF0IGEgcmVjZWl2 ZXIgd2lsbCBuZWVkIHRvIGNvcnJlbGF0ZSBtdWx0aXBsZSBTRXRzIG9uIHRoZSBzYW1lIHN1Ympl Y3QsIHNvIGhhdmluZyBtdWx0aXBsZSBldmVudHMgaW4gYSBTRVQgaXMgcmVkdW5kYW50LCBhbmQg YWRkcyBjb21wbGV4aXR5IHdpdGggbm8gY2xlYXIgYmVuZWZpdCB0aGF0IEkgY2FuIHNlZS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5BbiBpbXBsZW1lbnRvciBtYXkgY2hvb3NlIHRvIHNlbmQgbXVsdGlwbGUgU0VUcywgb3Igc2Vu ZCBhIHNpbmdsZSBTRVQgd2l0aCBtdWx0aXBsZSBldmVudHMsIHNvIGEgcmVjZWl2ZXIgd2lsbCBu ZWVkIHRvIHN1cHBvcnQgYm90aC4gSSBwcmVmZXIgd2UgcGljayBvbmUgd2F5IGFuZCBtaW5pbWl6 ZSB0aGUgY29kZSBwYXRocywgYW5kIHdlDQogd2lsbCBuZWVkIHRvIHN1cHBvcnQgY29ycmVsYXRp bmcgYWNyb3NzIG11bHRpcGxlIFNFVHMsIHNvIHRoYXQgc2VlbXMgdGhlIGJlc3QgbWVjaGFuaXNt Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPkxldCBtZSBrbm93IGlmIHRoZXJlIGlzIHNvbWV0aGluZyBJIG1pc3NlZCBpbiBteSBs b2dpYy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj4vRGljazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91 bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5k OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIFN1biwgT2N0IDI5LCAyMDE3IGF0IDExOjI4 IEFNLCBZYXJvbiBTaGVmZmVyPHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAx Mzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnlh cm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0OzxzcGFuIGNsYXNzPSJt LTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2 MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+d3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JbiB0aGF0IGNhc2Us IGxldCdzIGFkZCB0ZXh0IHRvIHRoYXQgZWZmZWN0LCBlLmcuIHdlIGNvdWxkIGFkZCB0byB0aGUg ZGVmaW5pdGlvbiBvZiB0aGUgJnF1b3Q7ZXZlbnRzJnF1b3Q7IGNsYWltOjxicj4NCjxicj4NClBy b2ZpbGluZyBzcGVjaWZpY2F0aW9ucyBTSE9VTEQgZGVmaW5lIHRoZSBhbGxvd2VkIGV2ZW50IHN0 YXRlbWVudHMsIGFuZCBNQVkgcmVzdHJpY3QgdGhlaXIgbnVtYmVyLiBGb3IgZXhhbXBsZSwgc29t ZSBwcm9maWxlcyBtYXkgcmVxdWlyZSB0aGlzIGNsYWltIHRvIGNvbnRhaW4gb25seSBhIHNpbmds ZSBldmVudCBzdGF0ZW1lbnQuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4 NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+WWFyb248YnI+DQo8YnI+DQpPbiAyNC8xMC8x NyAyMjoxMCwgTWlrZSBKb25lcyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBhZ3JlZSB3 aXRoIG11Y2ggb2YgUGhpbOKAmXMgcmF0aW9uYWxlIGhlcmUuPGJyPg0KPGJyPg0KSXTigJlzIGZp bmUgZm9yIHNvbWUgcHJvZmlsZXMgdG8gc2F5IHRoYXQgdGhlIOKAnGV2ZW50c+KAnSBzZXQgbXVz dCBiZSBhIHNpbmdsZXRvbi4mbmJzcDsgVGhhdCBkb2VzbuKAmXQgaGF2ZSB0byBiZSB0cnVlIGZv ciBhbGwgZXZlbnRzLiZuYnNwOyBJIHRoaW5rIHRoaW5ncyBhcmUgZmluZSBhcy1pcy48YnI+DQo8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFz cz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAy NDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPi0tIE1pa2U8YnI+DQo8YnI+DQoqRnJvbToqIElkLWV2ZW50IFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwv YT5dICpPbiBCZWhhbGYgT2YgKlBoaWwgSHVudDxicj4NCipTZW50OiogTW9uZGF5LCBPY3RvYmVy IDIzLCAyMDE3IDg6NDcgUE08YnI+DQoqVG86KiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yaWNoYW5uYUBhbWF6b24uY29tPC9zcGFuPjwvYT4m Z3Q7PGJyPg0KKkNjOiogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQoqU3ViamVjdDoqIFJl OiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQ/PGJyPg0K PGJyPg0KQW5uYWJlbGxlLDxicj4NCjxicj4NCkkgaGF2ZSBhIG51bWJlciBvZiBjb25jZXJucyB3 aXRoIHRoaXMgcHJvcG9zYWwuPGJyPg0KPGJyPg0KUHJvZmlsaW5nIEluZGVwZW5kZW5jZSAvIEtl ZXBpbmcgRXZlbnQgUGF5bG9hZHMgSW5kZXBlbmRlbnQ8YnI+DQo8YnI+DQpJbmRpY2F0aW5nIHRo YXQgZXh0ZW5zaW9ucyBzaG91bGQgYmUgaGFuZGxlZCBieSBwcm9maWxlcyBsZWFkcyB0byBtb3Jl IGludGVyLW9wZXJhYmlsaXR5IGlzc3VlcyBhbmQgbW9yZSBpbXBvcnRhbnRseSBpbnRydWRlcyBv biB0aGUgRXZlbnQgcGF5bG9hZCBzcGFjZSBieSBzdWdnZXN0aW5nIGEgc3ViLXNjaGVtYSBjcmVh dGVzIHBvdGVudGlhbCBsaW1pdGF0aW9ucyBhbmQgY29uZmxpY3RzIHRoYXQgbWF5IGFkZCB0byBj b21wbGV4aXR5IGxhdGVyDQogb24uIFRoZSBjdXJyZW50IGZvcm1hdCBhbGxvd3MgYSBwYXJzZXIg dG8gZGlzY292ZXIgYW5kIHVubG9hZCBvbmUgb3IgbW9yZSBKU09OIHBheWxvYWRzIHdoaWNoIGNh biBlYWNoIGhhdmUgaW5kZXBlbmRlbnQgc3RydWN0dXJlLjxicj4NCjxicj4NCkdlbmVyYWwgZXh0 ZW5zaW9uczxicj4NCjxicj4NClRoZSBwcm9wb3NhbCBhbHNvIHJ1bGVzIG91dCBnZW5lcmFsIHB1 cnBvc2UgZXh0ZW5zaW9ucyBub3QgcmVsYXRlZCB0byBhbnkgc3BlY2lmaWMgZXZlbnQuIEdpdmVu IHRoZSBlbWVyZ2VuY2Ugb2YgaXRlbXMgbGlrZSBHUFJELCBJIHdvdWxkIG5vdCB3YW50IHRvIGJs b2NrIHRoZSBhYmlsaXR5IHRvIGFkZCBtZXRhLWRhdGEgb3Igb3RoZXIgZ2VuZXJhbCBwdXJwb3Nl IGl0ZW1zLiBXZSBjYW4gYWxzbyBhbnRpY2lwYXRlIHNvbWUgZGVsaXZlcnkgc2NlbmFyaW9zDQog d2hlcmUgYWRkaXRpb25hbCBkYXRhIG1pZ2h0IGJlIHJlcXVpcmVkLiBFdmVuIHRob3VnaCB0aGVy ZSBpcyBubyBjdXJyZW50IHBsYW5uZWQgdXNlLCBJIHNlZSBubyBnb29kIHJlYXNvbiB0byBydWxl IHRoaXMgb3V0Ljxicj4NCjxicj4NCk11bHRpcGxlIEV2ZW50cyBGcm9tIERpZmZlcmVudCBGYW1p bGllcyAodnMuIE11bHRpcGxlIEV2ZW50cyBmcm9tIGEgc2luZ2xlIGZhbWlseSBsaWtlIFJJU0Mp PGJyPg0KPGJyPg0KSW4gb3VyIFJJU0Mgc2Vzc2lvbiB3ZSBkaXNjdXNzZWQgZXhwcmVzc2luZyBt dWx0aXBsZSBkaXN0aW5jdCBSSVNDIGV2ZW50cyBpbiBvbmUgU0VULiBUaGUgZGlzY3Vzc2lvbiB3 YXMgdGhhdCBvbmx5IG9uZSBSSVNDIGV2ZW50IGF0IGEgdGltZS4gV2UgZGlkIG5vdCBkaXNjdXNz IG90aGVyIGV2ZW50IHByb2ZpbGVzLiBJIGRvbuKAmXQgc2VlIGEgcmVhc29uIHRvIHJ1bGUgb3V0 IG11bHRpLWV2ZW50cyBmcm9tIGRpZmZlcmVudCBmYW1pbGllcyBhdCB0aGUNCiBTRVQgbGV2ZWwu IEVhY2ggcHJvZmlsZSBpcyBleHByZXNzaW5nIHNsaWdodGx5IGRpZmZlcmVudCB0aGluZ3MgYWJv dXQgdGhlIHNhbWUgZXZlbnQuPGJyPg0KPGJyPg0KSSBjYW4gZm9yc2VlIHNvbWUgY2FzZXMgd2hl cmUgaXQgaXMgbm90IGNsZWFyIHdoaWNoIGlzIHRoZSBwcmltYXJ5IGFuZCB3aGljaCBpcyB0aGUg ZXh0ZW5zaW9uLiZuYnNwOyBUaGVyZSBtYXkgbm90IGJlIGEgY2xlYXIgd2lubmVyLjxicj4NCjxi cj4NCkEgY291cGxlIG9mIGV4YW1wbGVzICh0aGVzZSBhcmUgbmVjZXNzYXJpbHkgcmVhbOKApmp1 c3QgcG9zc2liaWxpdGllcyk6PGJyPg0KPGJyPg0KKiBJdCBpcyBwcm9iYWJseSB1c2VmdWwgdG8g YmUgYWJsZSB0byBleHByZXNzIHNpbWxhci9vdmVybGFwcGluZyBldmVudHMgZnJvbSBkaWZmZXJl bnQgU0VUIHByb2ZpbGVzIGluIG9uZSBTRVQuJm5ic3A7IEZvciBleGFtcGxlIGEgQmFja2NoYW5u ZWwgTG9nb3V0ICZhbXA7IGEgUklTQyBzZXNzaW9uIGNhbmNlbCBldmVudC48YnI+DQo8YnI+DQoq IFNDSU0gbWF5IHdhbnQgdG8gcmVwcmVzZW50IGEgc2luZ2xlIHRyYW5zYWN0aW9uIGFzIGNhdXNp bmcgbXVsdGlwbGUgc3RhdGUgY2hhbmdlcyBpbiBhbiBldmVudCAoZS5nLiBhIHBhc3N3b3JkIGNo YW5nZSBjYXVzZXMgbXVsdGlwbGUgZWZmZWN0cykuIEhhdmluZyB0byBjaGFzZSBkb3duIG11bHRp cGxlIGV2ZW50cyBhbmQgY29ycmVsYXRlIGJ5IOKAnHR4buKAnSB3b3VsZCBiZSBjaGFsbGVuZ2lu ZyBpbiBhIG11bHRpLXRocmVhZGVkL211bHRpLW5vZGUNCiBkZWxpdmVyeSBzeXN0ZW0uJm5ic3A7 ICZuYnNwO1RoZSBTQ0lNIGxpc3QgaGFzIG5vdCBkaXNjdXNzZWQgdGhpcywgYnV0IEkgd291bGQg bm90IHdhbnQgdG8gYmxvY2sgdGhpcyBjYXBhYmlsaXR5LiZuYnNwOyBJT1cgLSBKdXN0IGJlY2F1 c2UgUklTQyBkb2VzIG5vdCB3YW50IHRvIGV4cHJlc3MgbXVsdGlwbGUgZXZlbnRzIGRvZXMgbm90 IG1ha2UgdGhpcyB0cnVlIGZvciBvdGhlciBwcm9maWxlcy48YnI+DQo8YnI+DQoqIFdlIG1heSB3 aXNoIHRvIGluZGljYXRlIGEgU0NJTSBQYXNzd29yZCBSZXNldCB3YXMgcGVyZm9ybWVkIGFuZCBh IExvZ291dC9zZXNzaW9uIGNhbmNlbGxhdGlvbiBpcyBleHByZXNzZWQgYXQgdGhlIHNhbWUgdGlt ZS4mbmJzcDsgVGhlIGV2ZW50cyBhcmUgcmVsYXRlZCBidXQgZXhwcmVzcyBkaWZmZXJlbnQgZGF0 YS48YnI+DQo8YnI+DQpBdm9pZGluZyBDb25mdXNpb24gRnJvbSBTaW1pbGFyIEV2ZW50cyBPcmln aW5hdGluZyBmcm9tIHRoZSBTYW1lIFRyYW5zYWN0aW9uPGJyPg0KPGJyPg0KSWYgZXZlbnRzIGFy ZSBzZW50IHNlcGFyYXRlbHksIHRoZW4gbW9yZSB0cmFja2luZyBvZiBzdGF0ZSAoZS5nLiBieSB0 eG4pIHdvdWxkIGJlIHJlcXVpcmVkIHRvIGVuc3VyZSBzaW1pbGFyIGV2ZW50cyBhcmUgbm90IG1p c3Rha2VuIG9yIGhhbmRsZWQgYXMgcmVwZWF0cy4gV2hpbGUgdHhuIHByb3ZpZGVzIHVzZWZ1bCBh dWRpdCBhbmFseXNpcyBjYXBhYmlsaXR5LCBJ4oCZbSBub3Qgc3VyZSBpdCBjYW4gYmUgdXNlZCBp biBsaXZlIG9yIG5lYXItcmVhbA0KIHRpbWUgc3lzdGVtcyBnaXZlbiBkaXN0cmlidXRlZCBtdWx0 aS1ub2RlLCBtdWx0aS10aHJlYWRpbmcgYXJjaGl0ZWN0dXJlcy48YnI+DQo8YnI+DQpQcmV2aW91 cyBEaXNjdXNzaW9uPGJyPg0KPGJyPg0KSSBub3RlIHRoYXQgSSBvcmlnaW5hbGx5IHJhaXNlZCBo YXZpbmcgYW4gYXR0cmlidXRlIHRvIGRlc2lnbmF0ZSBwcmltYXJ5IGV2ZW50IGF0dHJpYnV0ZSB0 byBhbGxldmlhdGUgeW91ciBjb25jZXJuLCBidXQgdGhpcyB3YXMgbm90IGFjY2VwdGVkLiBTZWU6 PGJyPg0KPGJyPg0KKjxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4 NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbC0yRGFy Y2hpdmVfd2ViX2lkLTJEZXZlbnRfY3VycmVudF9tc2cwMDQwNi5odG1sJmFtcDtkPUR3TUZhUSZh bXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5h NUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209WUJDR2xLOW1q amhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZhbXA7cz1TM3NNVmlxTXZFZ253R2JK d09RTnljck95cjdTZWZwcV9Nb0ZPS2NFZUNFJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvaWQtZXZlbnQvY3VycmVudC9tc2cwMDQwNi5odG1sPC9zcGFuPjwvYT48YnI+DQo8YnI+DQoq PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02 OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfaWQt MkRldmVudF9jdXJyZW50X21zZzAwMTQwLmh0bWwmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdO eTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1ZQkNHbEs5bWpqaGNGc2otMnREa24z MUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtzPUd5OWd5Um9JSXRhLWNTaFY3Yk4xNjFheTR5RTZy OUcxX0FhX05lQm55bGcmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pZC1ldmVudC9j dXJyZW50L21zZzAwMTQwLmh0bWw8L3NwYW4+PC9hPjxicj4NCjxicj4NClRoZSBjb25zZW5zdXMs IGF0IGxlYXN0IGFzIEkgaW50ZXJwcmV0ZWQgaXQgaXMgdXAgdG8gdGhlIHJlY2VpdmVyIHRvIGZp Z3VyZSB0aGlzIG91dCBiYXNlZCBvbiB0aGUgZGVmaW5pdGlvbnMgaXQgaGFzIGZvciBlYWNoIGV2 ZW50IFVSSSBhbmQgdGhlIHByb2ZpbGVzIHRoZXkgcmVwcmVzZW50LiBJT1cgLSBSSVNDIGlzIGZy ZWUgdG8gbGltaXQgdGhhdCBvbmx5IG9uZSBSSVNDIGV2ZW50IGJlIGV4cHJlc3NlZCBhdCBhIHRp bWUuPGJyPg0KPGJyPg0KUGhpbDxicj4NCjxicj4NCk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRp dHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0PGJyPg0KPGJyPg0KQGluZGVwZW5kZW50aWQ8YnI+ DQo8YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cC0zQV9fd3d3LmluZGVwZW5kZW50aWQuY29tJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1Ax WXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21h bnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209WUJDR2xLOW1qamhjRnNqLTJ0 RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZhbXA7cz05TlA1bmFtZzZySVZ6d3VuOWMtMXEwd2hz eVh3U3Z0SEIwZjJkS2tmQ1g4JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9 Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2 NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj4mbHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNvbSZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdt YW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPVlCQ0dsSzltampoY0Zzai0y dERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmYW1wO3M9OU5QNW5hbWc2cklWend1bjljLTFxMHdo c3lYd1N2dEhCMGYyZEtrZkNYOCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5odHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPC9zcGFuPjwvYT4mZ3Q7 PGJyPg0KPGJyPg0KPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208 L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0 MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgT24gT2N0IDIzLCAyMDE3LCBhdCA3OjAyIFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFu bmFiZWxsZTxicj4NCiZuYnNwOyAmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBh bWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cmlj aGFubmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIw ODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYw ODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+cmljaGFubmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+Jmd0OyZn dDsNCiB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoZSBjdXJyZW50IGRyYWZ0IG9m IHRoZSBTRVQgc3BlYyBhbGxvd3MgZm9yIGV4cHJlc3NpbmcgbXVsdGlwbGU8YnI+DQombmJzcDsg Jm5ic3A7IGV2ZW50cyB3aXRoaW4gdGhlIHNhbWUgdG9rZW4sIHdoaWNoIGludHJvZHVjZXMgYWRk aXRpb25hbCBjb21wbGV4aXR5PGJyPg0KJm5ic3A7ICZuYnNwOyBhbmQgcm9vbSBmb3IgYW1iaWd1 b3VzIHNlbWFudGljcy4gV2XigJl2ZSBkaXNjdXNzZWQgdGhpcyBpbiB0aGUgT0lERjxicj4NCiZu YnNwOyAmbmJzcDsgUklTQyB3b3JraW5nIGdyb3VwIGFuZCB0aGUgY3VycmVudCBjb25zZW5zdXMg dGhlcmUgaXMgdGhhdCBSSVNDIHdpbGw8YnI+DQombmJzcDsgJm5ic3A7IHJlcXVpcmUgdGhhdCBS SVNDIGV2ZW50cyBtdXN0IGJlIHRoZSBvbmx5IGV2ZW50IGluIHRoZSBTRVQsIGhhdmluZzxicj4N CiZuYnNwOyAmbmJzcDsgaWRlbnRpZmllZCB3YXlzIHRvIGNsZWFybHkgYW5kIGVhc2lseSBzdXBw b3J0IHRoZSBoYW5kZnVsIG9mIHVzZTxicj4NCiZuYnNwOyAmbmJzcDsgY2FzZXMgZm9yIG11bHRp cGxlIGV2ZW50cyBwZXIgdG9rZW4gdGhhdCBwZW9wbGUgaGF2ZSByYWlzZWQuIFdpdGg8YnI+DQom bmJzcDsgJm5ic3A7IHRoYXQgY29udGV4dCBpbiBtaW5kLCBJIHByb3Bvc2Ugc3RyaWtpbmcgdGhl IGRlZmluaXRpb24gb2YgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyDigJxldmVudHPigJ0gY2xhaW0g ZnJvbSB0aGUgU2VjdXJpdHkgRXZlbnQgVG9rZW4gc3BlYywgYW5kIHJlcGxhY2luZyBpdDxicj4N CiZuYnNwOyAmbmJzcDsgd2l0aCB0aGUgZm9sbG93aW5nIGRlZmluaXRpb24gZm9yIGFuIOKAnGV2 ZW504oCdIGNsYWltIChzaW5ndWxhcik6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBldmVudDxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgQSBKU09OIG9iamVjdCBjb250YWluaW5nIGFuICZxdW90 O2V2ZW50X3R5cGUmcXVvdDsgbWVtYmVyIHdob3NlIHZhbHVlIGlzIGEgVVJJPGJyPg0KJm5ic3A7 ICZuYnNwOyByZXByZXNlbnRpbmcgYSB0eXBlIG9mIGV2ZW50IGRlZmluZWQgaW4gYSBQcm9maWxp bmcgU3BlY2lmaWNhdGlvbi48YnI+DQombmJzcDsgJm5ic3A7IFRoZSBvYmplY3QgTUFZIG90aGVy d2lzZSBiZSBlbXB0eSwgb3IgTUFZIGNvbnRhaW4gYWRkaXRpb25hbCBtZW1iZXJzPGJyPg0KJm5i c3A7ICZuYnNwOyBhcyBkZXNjcmliZWQgYnkgdGhlIFByb2ZpbGluZyBTcGVjaWZpY2F0aW9uLjxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSGVyZSBpcyB0aGUgZXhhbXBsZSBTRVQgZnJvbSBzZWN0 aW9uIDIuMywgcmV3cml0dGVuIHdpdGggdGhpcyBjaGFuZ2U8YnI+DQombmJzcDsgJm5ic3A7IG1p bmQ6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMy MDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2 MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ezxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZxdW90O2p0aSZxdW90OzogJnF1b3Q7NGQzNTU5 ZWM2NzUwNGFhYmE2NWQ0MGIwMzYzZmFhZDgmcXVvdDssPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsmbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OiAxNDU4NDk2NDA0LDxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7JnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJo dHRwczovL3NjaW0uZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPC9zcGFuPjwvYT48c3BhbiBjbGFz cz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAy NDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPiZsdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29t Lzwvc3Bhbj48L2E+Jmd0OyZxdW90Oyw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZu YnNwOyAmcXVvdDthdWQmcXVvdDs6IFs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20v RmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2 MWZhNWJiYzg3OTU5M2I3NzU0PC9zcGFuPjwvYT4mcXVvdDssPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zY2lt LmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NjaW0uZXhhbXBsZS5jb20v RmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNzwvc3Bhbj48L2E+JnF1b3Q7PGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgXSw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyZuYnNwOyAmcXVvdDtldmVudCZxdW90Ozogezxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2V2ZW50X3R5cGUmcXVvdDs6ICZxdW90 O3VybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OmNyZWF0ZSZxdW90Oyw8YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtyZWYmcXVvdDs6ICZxdW90 OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9Vc2Vycy80NGY2MTQyZGY5NmJkNmFi NjFlNzUyMWQ5IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0 cHM6Ly9zY2ltLmV4YW1wbGUuY29tL1VzZXJzLzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDk8L3Nw YW4+PC9hPiZxdW90Oyw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmcXVvdDthdHRyaWJ1dGVzJnF1b3Q7OiBbJnF1b3Q7aWQmcXVvdDssICZxdW90O25h bWUmcXVvdDssICZxdW90O3VzZXJOYW1lJnF1b3Q7LCAmcXVvdDtwYXNzd29yZCZxdW90OywgJnF1 b3Q7ZW1haWxzJnF1b3Q7XTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IH08 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IH08YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IERvZXMg YW55b25lIGluIHRoZSB3b3JraW5nIGdyb3VwIGhhdmUgdXNlIGNhc2VzIGZvciBTRVRzIHRoYXQg Y2Fubm90PGJyPg0KJm5ic3A7ICZuYnNwOyBiZSBtZXQgYnkgdGhpcyBwcm9wb3NlZCB0ZXh0PyBX aXRoaW4gUklTQywgd2UgaWRlbnRpZmllZCB0aHJlZSB1c2U8YnI+DQombmJzcDsgJm5ic3A7IGNh c2VzLCB3aXRoIHNvbHV0aW9ucyBvdXRsaW5lZCBiZWxvdzo8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7ICoqPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAqRXh0ZW5zaW9ucyo8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7IEV2ZW50IGV4dGVuc2lvbiBtZWNoYW5pc21zIGNhbiBiZSBkZWZpbmVkIGlu dGVybmFsIHRvIHRoZSBldmVudDxicj4NCiZuYnNwOyAmbmJzcDsgb2JqZWN0LiBBIHNpbXBsZSBh cHByb2FjaCB3b3VsZCBiZSB0byAmbmJzcDtkZWZpbmUgYW4g4oCcZXh0ZW5zaW9uc+KAnSBtZW1i ZXI8YnI+DQombmJzcDsgJm5ic3A7IHRoYXQgaXMgYSBsaXN0IG9mIGV2ZW50IG9iamVjdHMgKG9y IHNldCByZXNlbWJsaW5nIHRoZSDigJxldmVudHPigJ08YnI+DQombmJzcDsgJm5ic3A7IGNsYWlt IGFzIGRlZmluZWQgaW4gdGhlIGN1cnJlbnQgc3BlYykuIFRoaXMgaGFzIHRoZSBhZHZhbnRhZ2Ug b2Y8YnI+DQombmJzcDsgJm5ic3A7IG1ha2luZyBpdCBjbGVhciBpbiB0aGUgZGF0YSBzdHJ1Y3R1 cmUgdGhhdCB0aGVyZSBpcyBhIHNpbmdsZSBwcmltYXJ5PGJyPg0KJm5ic3A7ICZuYnNwOyBldmVu dCwgd2l0aCB6ZXJvIG9yIG1vcmUgZXh0ZW5zaW9ucy4gVGhlcmUgaXMgbm8gcm9vbSBmb3IgY29u ZnVzaW9uPGJyPg0KJm5ic3A7ICZuYnNwOyBvdmVyIHdoaWNoIGV2ZW50IGlzIHByaW1hcnksIG9y IGlmIHRoZXJlIGlzIGEgcHJpbWFyeSBldmVudCBhdCBhbGwuPGJyPg0KJm5ic3A7ICZuYnNwOyBJ IHdvdWxkIGJlIGZpbmUgd2l0aCBhZGRpbmcgc29tZXRoaW5nIGxpa2UgdGhpcyB0byBteSBwcm9w b3NlZCB0ZXh0LDxicj4NCiZuYnNwOyAmbmJzcDsgaWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRoYXQg aXQgaXMgYnJvYWRseSB1c2VmdWwuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAqQWxpYXNlcyo8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoaXMgdXNlIGNhc2Ugd2FzIGJyb3VnaHQgdXAgaW4g dGhlIGNvbnRleHQgb2YgbWlncmF0aW5nIGNsaWVudHM8YnI+DQombmJzcDsgJm5ic3A7IGZyb20g ZHJhZnQgZXZlbnQgbmFtZXMgdG8gc3RhbmRhcmRpemVkIGV2ZW50IG5hbWVzLiBJbiB0aGlzIGNh c2UsPGJyPg0KJm5ic3A7ICZuYnNwOyB0aGUgZXZlbnQgdHJhbnNtaXR0ZXIgY2FuIHRyYW5zbWl0 IHR3byB0b2tlbnMgZm9yIHRoZSBsb2dpY2FsIGV2ZW50LDxicj4NCiZuYnNwOyAmbmJzcDsgb25l IHVzaW5nIHRoZSBvbGQgbmFtZSBhbmQgYW5vdGhlciB1c2luZyB0aGUgbmV3IG5hbWUuPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyAqUmVsYXRlZCBFdmVudHMqPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyBUaGUgU0VUIHNwZWMgZGVmaW5lcyB0aGUgdHhuIGNsYWltIGFzIGEgbWVhbnMgb2YgY29y cmVsYXRpbmc8YnI+DQombmJzcDsgJm5ic3A7IGluZGVwZW5kZW50IHRva2VucyB0aGF0IHJlbGF0 ZSB0byB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgLS08 c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5 NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZuYnNwOyAmbmJzcDsgQW5uYWJlbGxlIFJpY2hhcmQgQmFj a21hbjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgQW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNl czxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7IElkLWV2ZW50IG1haWxpbmcgbGlz dDxicj4NCiZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01 MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0 NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJZC1l dmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODcz MjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1 NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+ DQombmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1 NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu X2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQ RWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1zNWJ5QmU1S0FObkdWdUFiMW1BdXBFR29KbjhYRzVK SVVVd1dHRlNpYkVjJmFtcDtzPVg4b1JTcTNJemxGN2ppUkFlWmhYcFIzZVZJMEk1OFpGZDRlRVpm Z3lvSVkmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJy S3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209czVieUJlNUtBTm5HVnVB YjFtQXVwRUdvSm44WEc1SklVVXdXR0ZTaWJFYyZhbXA7cz1YOG9SU3EzSXpsRjdqaVJBZVpoWHBS M2VWSTBJNThaRmQ0ZUVaZmd5b0lZJmFtcDtlPTwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVu dEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBa aDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQ a0FJMWFMY0xONEtaTkEmYW1wO209WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRr UmxRRzFpdyZhbXA7cz1Xck11UVJ3TFY4MDJpTVE0d1lCMWYyckZVR3U0emJoY1cwMDFmSzAyRVhz JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9z cGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZl bnQmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1 ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pO QSZhbXA7bT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtz PVdyTXVRUndMVjgwMmlNUTR3WUIxZjJyRlVHdTR6YmhjVzAwMWZLMDJFWHMmYW1wO2U9IiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8YnIg Y2xlYXI9ImFsbCI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4tLTxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAy NjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U3Vic2Ny aWJlIHRvIHRoZTxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0 MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmFtcDtkPUR3TUZh USZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDty PW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209WUJDR2xL OW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZhbXA7cz1MWU43MkdnS1ZoSHNU NnRBcUJlLWVNb1dNdnlfN2RmRm4xdVowSEs2WXVRJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkhBUkRUV0FSRTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9 Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2 NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5tYWlsDQogbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24h PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlz dDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdO eTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1ZQkNHbEs5bWpqaGNGc2otMnREa24z MUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtzPVdyTXVRUndMVjgwMmlNUTR3WUIxZjJyRlVHdTR6 YmhjVzAwMWZLMDJFWHMmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpwdXJwbGUiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1E d0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZh bXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPVlC Q0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmYW1wO3M9V3JNdVFSd0xW ODAyaU1RNHdZQjFmMnJGVUd1NHpiaGNXMDAxZkswMkVYcyZhbXA7ZT08L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6d2hpdGUiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxz cGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JZC1ldmVudCBtYWlsaW5nIGxpc3Q8L3NwYW4+ PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlO2JhY2tncm91bmQ6d2hpdGUiPklk LWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4 QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtB STFhTGNMTjRLWk5BJmFtcDttPVUtYTVIQk5EMEhhVFg0YW5OWmZ6WDdwRHNmSzVmMGg5bVo5Q1pr a0dpZWMmYW1wO3M9cnZkcnRJN3JZTlJBbnFaRGx0Q3dCQVpWSEtwLU1KMjB1aTJubTQ2UVN6MCZh bXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZTtiYWNr Z3JvdW5kOndoaXRlIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9 RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUm YW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1V LWE1SEJORDBIYVRYNGFuTlpmelg3cERzZks1ZjBoOW1aOUNaa2tHaWVjJmFtcDtzPXJ2ZHJ0STdy WU5SQW5xWkRsdEN3QkFaVkhLcC1NSjIwdWkybm00NlFTejAmYW1wO2U9PC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9ImFs bCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+U3Vic2NyaWJlIHRvIHRoZQ0KPGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21f JmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVh cElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEm YW1wO209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZhbXA7cz13 dGdEM05wMHZ5aExkcEV3VWlxc2Y0SXRpd0EzT203R3JvYjcwTHgwcjNrJmFtcDtlPSIgdGFyZ2V0 PSJfYmxhbmsiPg0KSEFSRFRXQVJFPC9hPiBtYWlsIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVj dHMgSSBhbSB3b3JraW5nIG9uITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVu dEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lk LTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJ ck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxj TE40S1pOQSZhbXA7bT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193 JmFtcDtzPU9lMHFmTEVYODN2dFhNN1dsMmNZQmUtR2cxRFZQamhYalZKa2ZoVlJ6d2MmYW1wO2U9 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFt cDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElf Sm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1w O209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZhbXA7cz1PZTBx ZkxFWDgzdnRYTTdXbDJjWUJlLUdnMURWUGpoWGpWSmtmaFZSendjJmFtcDtlPTwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U3Vic2NyaWJlIHRv IHRoZQ0KPGEgaHJlZj0iaHR0cDovL2hhcmR0d2FyZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+SEFS RFRXQVJFPC9hPiBtYWlsIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5n IG9uITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9 ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U3Vic2NyaWJlIHRvIHRoZQ0KPGEgaHJlZj0iaHR0cDov L2hhcmR0d2FyZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+SEFSRFRXQVJFPC9hPiBtYWlsIGxpc3Qg dG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uITxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3Vic2Ny aWJlIHRvIHRoZSA8YSBocmVmPSJodHRwOi8vaGFyZHR3YXJlLmNvbS8iIHRhcmdldD0iX2JsYW5r Ij4NCkhBUkRUV0FSRTwvYT4gbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0g d29ya2luZyBvbiE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB0504123CF86035352776D8DCF55F0CY4PR21MB0504namp_-- From nobody Wed Nov 1 12:18:37 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BE9139A2F for ; Wed, 1 Nov 2017 12:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.818 X-Spam-Level: X-Spam-Status: No, score=-11.818 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 exAfdmiqgRI6 for ; Wed, 1 Nov 2017 12:18:29 -0700 (PDT) Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDD313A1F4 for ; Wed, 1 Nov 2017 12:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1509563908; x=1541099908; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nKbVnNeFnRTefoFfbt3FABXoZ1RqDakupJ9cpHPcfgQ=; b=Ir2FDPqtzHJcC3BaJAAGdTm1huQ3SUyXPq5bjI+wauu6asn+VM28SXgi o2B7cKrJugWOg2zkR80XYL3ZPMiNNx4NrFE9cqeZxp+nj/qVxnLoxTYJc EzTaWMynndqfrt/V6BGn9+IxDqYN9JW0tVdrxD5IJYiKZVjUEazuKL+po 4=; X-IronPort-AV: E=Sophos;i="5.44,330,1505779200"; d="scan'208,217";a="314492065" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2b-2eab95aa.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2017 19:18:17 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-2b-2eab95aa.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id vA1JIGG3027284 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2017 19:18:16 GMT Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 1 Nov 2017 19:18:16 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 1 Nov 2017 19:18:15 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Wed, 1 Nov 2017 19:18:15 +0000 From: "Richard Backman, Annabelle" To: Mike Jones , Dick Hardt CC: Yaron Sheffer , ID Events Mailing List , "Phil Hunt (IDM)" Thread-Topic: [Id-event] Use cases for multiple events per SET? Thread-Index: AQHTTGwev6cV0D/tE06azbqzz7my9aLyXLkAgAEBjXCAB9BnAIAAT1IAgAAUagCAAQQ9AIAANauAgAAlNACAAAV2gIABcZJQgACUvYCAAADCcIAAA1kAgAASxcCAALLVgIAAG18AgAARHoA= Date: Wed, 1 Nov 2017 19:18:15 +0000 Message-ID: <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.131] Content-Type: multipart/alternative; boundary="_000_6DF29D13F11E4140BB39A88A4FD0B335amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 19:18:35 -0000 --_000_6DF29D13F11E4140BB39A88A4FD0B335amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VW5sZXNzIHRoZSBwcm9maWxlIGd1YXJhbnRlZXMgdGhhdCBzdWNoIHJlbGF0ZWQgZXZlbnRzIHdp bGwgYWx3YXlzIGJlIGluY2x1ZGVkIGluIHRoZSBzYW1lIFNFVCwgdGhlbiB0aGUgcmVjZWl2ZXIg aGFzIHRvIGNvcnJlbGF0ZSBhY3Jvc3MgU0VUcyBhbnl3YXksIGFuZCBtdWx0aXBsZSBldmVudHMg cGVyIFNFVCBpcyBqdXN0IGdpdmluZyB0aGUgcmVjZWl2ZXIgYW5vdGhlciBzY2VuYXJpbyB0aGF0 IHRoZXkgaGF2ZSB0byBzdXBwb3J0Lg0KDQpJ4oCZdmUgYWxyZWFkeSBwcm92aWRlZCBzZXZlcmFs IG90aGVyIHJlYXNvbnMgd2h5IHdlIHNob3VsZCBub3Qgc3VwcG9ydCBtdWx0aXBsZSB0b2tlbnMg cGVyIFNFVCB0aGF0IG5vIG9uZSBoYXMgYWRkcmVzc2VkLiBIZXJlIHRoZXkgYXJlIGFnYWluOg0K DQogIDEuICBNdWx0aXBsZSBldmVudCBzdXBwb3J0IHJlc3VsdHMgaW4gYSBtb3JlIGNvbXBsZXgg c3RydWN0dXJlIGZvciB0aGUgc2luZ2xlIGV2ZW50IHVzZSBjYXNlLCB3aGljaCBJIHRoaW5rIHdl IGFsbCBhZ3JlZSBpcyB0aGUgbWFqb3JpdHkgdXNlIGNhc2UuDQogIDIuICBNdWx0aXBsZS1ldmVu dCBTRVRzIGhhdmUgYW1iaWd1b3VzIHNlbWFudGljcy4gVGhlIHByZXNlbmNlIG9mIHR3byBldmVu dHMgQSBhbmQgQiBpbiB0aGUgc2FtZSBTRVQgY291bGQgbWVhbiBhbnkgb2Y6DQogICAgICogICBB IGFuZCBCIGFyZSByZWxhdGVkIHRvIHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQgKGkuZS4gdGhlIHNh bWUgdGhpbmcgYXMgaWYgdGhleSB3ZXJlIGZyb20gZGlmZmVyZW50IFNFVHMgdGhhdCBoYXZlIGEg Y29tbW9uIHR4bikuDQogICAgICogICBBIGlzIGFuIGV4dGVuc2lvbiBvZiBCLg0KICAgICAqICAg QiBpcyBhbiBleHRlbnNpb24gb2YgQS4NCiAgICAgKiAgIEEgaXMgYW4gYWxpYXMgZm9yIEIsIG9y IHZpY2UtdmVyc2EuDQogICAgICogICBBIGFuZCBCIGFyZSBub3QgYWN0dWFsbHkgcmVsYXRlZCB0 byBvbmUgYW5vdGhlciBpbiBhbnkgd2F5LCBhbmQgdGhlIHRyYW5zbWl0dGVyIGJ1bmRsZWQgdGhl bSB0b2dldGhlciBiZWNhdXNlIHRoZXkgd2VyZSBnb2luZyB0byB0aGUgc2FtZSByZWNlaXZlci4N CiAgMy4gIFRvcC1sZXZlbCBjbGFpbSBzZW1hbnRpY3MgYmVjb21lIGhhcmRlciB0byBkZWZpbmUs IGFzIGRpZmZlcmVudCBwcm9maWxlcyBtYXkgd2FudCB0byB1c2UgdGhlIHNhbWUgY2xhaW1zIGlu IGRpZmZlcmVudCB3YXlzLg0KICA0LiAgRXZlbnQgYXV0aGVudGljaXR5IGNhbm5vdCBiZSB2ZXJp ZmllZCB3aXRob3V0IGhhdmluZyB0aGUgZW50aXJlIFNFVC4gVGhpcyBmb3JjZXMgcmVjZWl2ZXJz IHRvIGV4cG9zZSBkb3duc3RyZWFtIHN5c3RlbXMgdG8gbW9yZSBpbmZvcm1hdGlvbiBuZWNlc3Nh cnksIGlmIHRob3NlIHN5c3RlbXMgbmVlZCB0byBiZSBhYmxlIHRvIHZlcmlmeSBhdXRoZW50aWNp dHkuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBbWF6b24g4oCTIElkZW50aXR5 IFNlcnZpY2VzDQoNCg0KRnJvbTogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPg0KRGF0ZTogV2VkbmVzZGF5LCBOb3ZlbWJlciAxLCAyMDE3IGF0IDExOjIxIEFNDQpUbzog RGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpDYzogWWFyb24gU2hlZmZlciA8eWFy b25mLmlldGZAZ21haWwuY29tPiwgIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFu bmFAYW1hem9uLmNvbT4sIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3Jn PiwgIlBoaWwgSHVudCAoSURNKSIgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0KU3ViamVjdDogUkU6 IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD8NCg0KSSBj b21wbGV0ZWx5IGFncmVlIG9uIG1vdmluZyBjb21wbGV4aXR5IHRvIHRoZSBpc3N1ZXIgb3ZlciB0 aGUgcmVjaXBpZW50LiAgSW4gbXkgdmlldywgaXTigJlzIG1vcmUgY29tcGxleCBmb3IgcmVjaXBp ZW50cyB0byBoYXZlIHRvIGNvcnJlbGF0ZSBhbmQgcHJvY2VzcyBhIHNlcXVlbmNlIG9mIG11bHRp cGxlIFNFVHMgcHJvdmlkaW5nIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzYW1lIGxvZ2ljYWwgZXZl bnQsIGFuZCB2YWxpZGF0ZSBOIHNpZ25hdHVyZXMsIHRoYW4gdG8gcmVjZWl2ZSBvbmUgU0VUIHdp dGggYWxsIHRoZSBhc3BlY3RzIG9mIHRoZSBsb2dpY2FsIGV2ZW50IGFzIOKAnGV2ZW50c+KAnSBm aWVsZHMsIHdpdGggbm8gY29ycmVsYXRpb24gb3ZlciB0aW1lIHRoZW4gcmVxdWlyZWQuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCkZyb206IERpY2sgSGFyZHQgW21haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbV0NClNl bnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMSwgMjAxNyA5OjM5IEFNDQpUbzogTWlrZSBKb25lcyA8 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5p ZXRmQGdtYWlsLmNvbT47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6 b24uY29tPjsgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc+OyBQaGls IEh1bnQgKElETSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0KU3ViamVjdDogUmU6IFtJZC1ldmVu dF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD8NCg0KWW91ciBjb21tZW50 cyBoaWdobGlnaHQgYSBjb3VwbGUgb2YgcG9pbnRzOg0KDQoxKSBUaGUgZXhhbXBsZSBpcyBob3cg dG8gaGF2ZSBhIHByZWRlZmluZWQgZXh0ZW5zaW9uIHBvaW50IGZvciBleHRlbnNpb25zIG9mIGEg c3BlY2lmaWMgZXZlbnQsIGl0IGlzIG5vdCBob3cgdG8gYWRkIGFub3RoZXIgZXZlbnQuIE15c2Vs ZiwgSSB0aGluayB0aGlzIGlzIG92ZXJseSBjb21wbGljYXRlZC4gRXZlbnRzIHNob3VsZCBiZSBj b21wYXJhdGl2ZWx5IHN0YXRpYywgYW5kIGFzIHdpdGggbWFueSBvdGhlciBKU09OIGZvcm1hdHMs IHRoZSByZWNlaXZlciBzaG91bGQgaWdub3JlIHByb3BlcnRpZXMgaXQgZG9lcyBub3QgdW5kZXJz dGFuZCwgd2hpY2ggbGV0J3MgbmV3IHByb3BlcnRpZXMgYmUgaW50cm9kdWNlZCBhcyBleHRlbnNp b25zLiBUaGVyZSBzaG91bGQgbm90IGJlIGFueSBjb25mbGljdCBhcyBleHRlbnNpb25zIHNob3Vs ZCBvbmx5IGJlIGRvbmUgYnkgdGhlIHByb2ZpbGUgdGhhdCBjcmVhdGVkIHRoZSBldmVudCBmb3Jt YXQgdG8gc3RhcnQgb2ZmIHdpdGguDQoNCjIpIEhhdmluZyBhbiBsdmFsdWUgYmUgYSBVUkkgaXMg bXVjaCBoYXJkZXIgdG8gY29kZSBhZ2FpbnN0LiBJJ20gbm90IHN1cmUgd2h5IE1hcml1cyBoYWQg dGhhdCBpbiBoaXMgZXhhbXBsZS4gUGVyIHRoZSBldmVudCwgdGhlIHR5cGUgb2YgdGhlIGV2ZW50 IGlzIHdlbGwgZGVmaW5lZCB3aXRoDQoNCiJldmVudF90eXBlIjogImh0dHBzOi8vZXhhbXBsZS5j b20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0IiwNCg0KMykgVGhpcyB0aHJlYWQgaXMgYWJv dXQgcmVhc29ucyBmb3IgbXVsdGlwbGUgZXZlbnRzIHRvIGJlIGNvbnRhaW5lZCBpbiBvbmUgc2V0 LiBZb3VyIG1lbnRpb24gb2YgYW4gaXNzdWVyIG5vdCB3YW50aW5nIHRvIHNpZ24gc2VwYXJhdGUg ZXZlbnRzIGFzIGEgcmVhc29uIHRvIGFsbG93IG11bHRpcGxlIGV2ZW50cy4gSSB0aGluayB3ZSBo YXZlIGRlY2lkZWQgdGhhdCBnaXZlbiBhIHByZWZlcmVuY2UsIHdlIHdpbGwgcHVzaCBlZmZvcnQg dG8gdGhlIHRyYW5zbWl0dGVyIG92ZXIgdGhlIHJlY2VpdmVyIGFzIGluIG1hbnkgdXNlIGNhc2Vz IHRoZXJlIGFyZSBtYW55IG1vcmUgcmVjZWl2ZXJzLiBHaXZlbiB0aGF0LCBpdCBpcyBtb3JlIGNv bXBsZXggZm9yIGEgcmVjZWl2ZXIgdG8gaGF2ZSBkaWZmZXJlbnQgd2F5cyBvZiBtYW5hZ2luZyB0 aGUgcmVjZWlwdCBvZiBtdWx0aXBsZSBldmVudHMgYXMgbm90IGFsbCBpc3N1ZXJzIHdpbGwgYnVu ZGxlIHRoZSBldmVudHMsIHNvIGl0IGlzIHNpbXBsZXIgdG8gaGF2ZSBvbmx5IG9uZSBldmVudCBw ZXIgU0VULiBJbmNsdWRpbmcgdGhlIHNlcGFyYXRlIGV2ZW50cyB3aXRoIGEgVVJJIGFzIGFuIGx2 YWx1ZSBpcyBjaGFsbGVuZ2luZyB0byBpbXBsZW1lbnQsIHNwZWFraW5nIGZyb20gZXhwZXJpZW5j ZS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCk9uIFR1ZSwgT2N0IDMxLCAyMDE3IGF0IDExOjA1 IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KTWFyaXVz4oCZIHByb3Bvc2VkIHN5bnRh eCwgcGFzdGVkIGluIGJlbG93LCBoYXMgZXhhY3RseSB0aGlzIGNoYXJhY3RlcmlzdGljLiAgVGhl IHdheSBJIHNlZSBpdCwgaGlzIHByb3Bvc2FsIGVzc2VudGlhbGx5IGhhcyBhIHByaW1hcnkgcGFz c3dvcmRSZXNldCBldmVudCBhbmQgYSBzZWNvbmRhcnkgcGFzc3dvcmRSZXNldEV4dCBkYXRhIHN0 cnVjdHVyZSwgd2hpY2ggY291bGQgaGF2ZSBiZWVuIHNpbXBseSBhbm90aGVyIGV2ZW50IHZhbHVl IGluIHRoZSBjdXJyZW50IGRyYWZ0Lg0KDQpUaGlzIGJyZWFraW5nIGNoYW5nZSBtYWtlcyB0aGUg ZGF0YSBzdHJ1Y3R1cmVzIG1vcmUgY29tcGxpY2F0ZWQgLSBub3QgbGVzcy4gIEFuZCBpdCBtYWtl cyB0aGluZ3MgdGhhdCB1c2VkIHRvIGJlIHBvc3NpYmxlIGltcG9zc2libGUsIHJlZHVjaW5nIGZs ZXhpYmlsaXR5IHRvIHRob3NlIHdobyB3b3VsZCB1c2UgdGhlIHNwZWMuDQoNClRoZXNlIHNlZW0g bGlrZSBiYWQgdHJhZGVvZmZzIHRvIG1lLg0KDQp7DQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJk MTkzYmQwZmIxYmQ0ZTdkMzAiLA0KICAiaWF0IjogMTQ1ODQ5NjAyNSwNCiAgImlzcyI6ICJodHRw czovL3NjaW0uZXhhbXBsZS5jb208aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLz4iLA0KICAiYXVk IjogWw0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4 Nzk1OTNiNzc1NCIsDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1 MTZiMWQwODY0MWQ3Njc2ZWU3Ig0KICAgXSwNCiAgICJldmVudF90eXBlIjogImh0dHBzOi8vZXhh bXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0IiwNCiAgICJldmVudCI6IHsNCiAg ICAgICAgICJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLA0KICAgICAgICAgImV4dGVu c2lvbnMiOiB7DQogICAgICAgICAgICJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFz c3dvcmRSZXNldEV4dOKAnTogew0KICAgICAgICAgICAgICJyZXNldEF0dGVtcHRzIjo1LA0KICAg ICAgICAgICB9DQogICAgICAgICB9DQogICAgICAgfQ0KfQ0KDQpJbiBwYXJ0aWN1bGFyLCBpdCBt YWtlcyBpdCBpbXBvc3NpYmxlIHRvIHNpZ24gbXVsdGlwbGUgcmVsYXRlZCBldmVudHMgc2hhcmlu ZyBhIGNvbW1vbiBjbGFpbXMgc2NoZW1hIHdpdGggYSBzaW5nbGUgc2lnbmF0dXJlIGJ5IHRoZSBp c3N1ZXIuICBJdCBmb3JjZXMgdGhlIGlzc3VlciB0byBkbyB0aGUgZXh0cmEgd29yayBvZiBzaWdu aW5nIGVhY2ggb2YgdGhlIHJlbGF0ZWQgZXZlbnRzIChvciBmYWNldHMgb2YgdGhlIHNhbWUgbG9n aWNhbCBldmVudCkgaW5kaXZpZHVhbGx5IGFuZCBmb3JjZXMgdGhlIHJlY2lwaWVudHMgdG8gZG8g dGhlIGV4dHJhIHdvcmsgb2YgY2hlY2tpbmcgYWxsIHRob3NlIHVubmVjZXNzYXJ5IHNpZ25hdHVy ZXMuDQoNCk5vdCBldmVyeSBwcm9maWxlIHdpbGwgZXZlciBoYXZlIG11bHRpcGxlIGtleXMgaW4g dGhlIOKAnGV2ZW50c+KAnSBzZXQgYnV0IHRoZXJl4oCZcyBhYnNvbHV0ZWx5IG5vIHJlYXNvbiB0 byBwcmVjbHVkZSBpdC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSWQtZXZlbnQgW21haWx0bzppZC1ldmVu dC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPl0gT24g QmVoYWxmIE9mIERpY2sgSGFyZHQNClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMzEsIDIwMTcgOTo1 MiBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCkNjOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYu aWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+OyBSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1h em9uLmNvbT4+OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWls dG86aWQtZXZlbnRAaWV0Zi5vcmc+PjsgUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xl LmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pg0KDQpTdWJqZWN0OiBSZTogW0lkLWV2 ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPw0KDQpQbGVhc2UgZGly ZWN0IG1lIHRvIGEgcHJvcG9zYWwgdGhhdCBoYXMgYSAicHJpbWFyeSIgYW5kICJzZWNvbmRhcnki IGV2ZW50cy4gSSBhZ3JlZSB0aGF0IGlzIHVuZGVzaXJhYmxlLiBJIHdvdWxkIGFsc28gZW5jb3Vy YWdlIHRvIGVuZ2FnZSBpbiB0aGUgZGlzY3Vzc2lvbnMgc28gdGhhdCB3ZSBjYW4gZHJpdmUgY2xh cml0eSBhbmQgc2ltcGxpY2l0eS4NCg0KSSB0aGluayB0aGUgcHJvcG9zYWwgaXMgdGhhdCB0aGVy ZSBpcyBvbmUgZXZlbnQgcGVyIFNFVC4NCg0KSSB0aGluayBoYXZpbmcgbW9yZSB0aGFuIG9uZSBl dmVudCBwZXIgU0VUIGFkZHMgY29tcGxleGl0eSBhcyBhIHJlY2VpdmVyIG11c3QgZGVhbCB3aXRo IHJlY2VpdmluZyBjb3JyZWxhdGVkIGV2ZW50cyBpbiBvbmUgU0VUIGFzIHdlbGwgYXMgY29ycmVs YXRlZCBldmVudHMgaW4gdGhlIHNhbWUgU0VULg0KDQovRGljaw0KDQpPbiBUdWUsIE9jdCAzMSwg MjAxNyBhdCA5OjQyIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSSBoZWFyIHlvdSBv biB0aGUgZmFjdCB0aGF0IGRpZmZlcmVudCBwZW9wbGUgaGF2ZSBqb2luZWQgdGhlIGVmZm9ydCBh dCBkaWZmZXJlbnQgdGltZXMuICBUaGF04oCZcyBhIG5vcm1hbCBwcm9jZXNzIGFzIGFuIGVmZm9y dCBidWlsZHMgbW9tZW50dW0uICBJIGdldCB0aGF0IG5vdCBldmVyeW9uZSB3YXMgdGhlcmUgd2hl biBwcmV2aW91cyBjb25zZW5zdXMgY2FsbHMgd2VyZSB0YWtlbi4NCg0KSSBzaG91bGQgbm90ZSB0 aGF0IEkgaGF2ZSBzcGVjaWZpYyB0ZWNobmljYWwgb2JqZWN0aW9ucyB0byB0aGUgc3BlY2lmaWMg cHJvcG9zZWQgY2hhbmdlcyBiZWluZyBkaXNjdXNzZWQgYXMgd2VsbC4gIEN1cnJlbnRseSBhbGwg ZXZlbnRzIGluIHRoZSBzZXQgaGF2ZSB0aGUgc2FtZSBzeW50YXguICBUaGUgcHJvcG9zYWxzLCBh cyBJIHVuZGVyc3RhbmQgdGhlbSwgcmV2ZXJ0IHVzIHRvIGEgc3RhdGUgd2hlcmUgdGhlcmXigJlz IGEg4oCccHJpbWFyeeKAnSBhbmQg4oCcc2Vjb25kYXJ54oCdIGV2ZW50cywgd2l0aCBkaWZmZXJl bnQgc3ludGF4IGZvciB0aGUgdHdvIGNsYXNzZXMuICBUaGF04oCZcyBuZWVkbGVzc2x5IG1vcmUg Y29tcGxpY2F0ZWQsIGFkZGluZyBubyBhY3R1YWwgdmFsdWUuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN CkZyb206IERpY2sgSGFyZHQgW21haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGlj ay5oYXJkdEBnbWFpbC5jb20+XQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAzMSwgMjAxNyA5OjM3 IFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFBoaWwgSHVudCAoSURNKSA8cGhpbC5o dW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj47IFlhcm9uIFNoZWZm ZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj47 IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpy aWNoYW5uYUBhbWF6b24uY29tPj47IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGll dGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+DQoNClN1YmplY3Q6IFJlOiBbSWQtZXZl bnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQ/DQoNCk1pa2UNCg0KQXMg eW91IHdlbGwga25vdywgbWFueSBwZW9wbGUgaW4gYSBXRyBkb24ndCBsb29rIGNsb3NlbHkgYXQg YSBzcGVjaWZpY2F0aW9uIHVudGlsIGxhc3QgY2FsbCBpcyBtYWRlLiBBZGRpdGlvbmFsbHksIHdl IGFyZSBjb21pbmcgdXAgb24gb25seSB0aGUgM3JkIFdHIG1lZXRpbmcuIFRoZSBXRyBoYXMgbm90 IGV4aXN0ZWQgZm9yIHZlcnkgbG9uZy4gV2hpbGUgc29tZSBvZiB0aGUgcGFydGljaXBhbnRzIGhh dmUgYmVlbiB3b3JraW5nIG9uIHRoaXMgZm9yIGEgd2hpbGUsIG1hbnkgaGF2ZSBub3QsIGFuZCB3 ZSBhcmUgbG9va2luZyBmb3IgY29uc2Vuc3VzIGFjcm9zcyB0aGUgV0cuDQoNClNpbmNlIFNlY0V2 ZW50IGlzIGEgZnJhbWV3b3JrIHRoYXQgd2UgZXhwZWN0IHRvIGJlIHByb2ZpbGVkLCBJIGZlZWwg aXQgaXMgaW1wb3J0YW50IHRvIGVuc3VyZSB0aGF0IFNlY0V2ZW50IHNwZWNpZmljYXRpb25zIGFy ZSBlYXN5IGZvciBhIHZhcmlldHkgb2YgcHJvZmlsZXMgdG8gYWRvcHQsIGFuZCB0aGF0IHRoZSBz ZW1hbnRpY3MgbWFrZSBzZW5zZS4gSSBhbHNvIHRoaW5rIHRoYXQgcHJvcGVydGllcyB0aGF0IGFy ZSBzcGVjaWZpYyB0byBhIHByb2ZpbGUgc2hvdWxkIGJlIGxlZnQgdG8gdGhhdCBwcm9maWxlIGFu ZCBub3QgYmUgaW5jbHVkZWQgaW4gU2VjRXZlbnQuDQoNClNpbmNlIHRoaXMgaXMgYSBmcmFtZXdv cmssIGl0IGlzIGV4cGVjdGVkIHRoYXQgYXMgZGlmZmVyZW50IGdyb3VwcyBwcm9maWxlIGl0LCB0 aGVyZSB3aWxsIGJlIGFkZGl0aW9uYWwgZmVlZGJhY2suDQoNClNwZWNpZmljYWxseSwgYXMgYSBw YXJ0aWNpcGFudCBpbiB0aGUgUklTQyBwcm9maWxlIG9mIFNFVCwgYSBudW1iZXIgb2YgaXNzdWVz IGluIFNFVCBoYXZlIHN1cmZhY2VkIGFzIHRoZSBSSVNDIFdHIGhhcyBsb29rZWQgYXQgaG93IHRv IHVzZSB0aGUgU0VULg0KDQpBcyBmb3IgU0VUIGJlaW5nIHN0YWJsZSBmb3Igb3ZlciBhIHllYXIs IHRoZXJlIGhhdmUgYmVlbiBhIG51bWJlciBvZiBjaGFuZ2VzIHRvIFNFVCBzaW5jZSB0aGVuLiBJ IGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgd2FzIGNvbnNlbnN1cy4gQmVmb3JlIHRoZSBXRyB3YXMg Zm9ybWVkLCBJIGFuZCBzZXZlcmFsIG90aGVycyBoYWQgZXhwcmVzc2VkIGNvbmNlcm4gb24gdGhl IGRlc2lnbiBvZiBTRVQgd2hlbiBQaGlsIHByZXNlbnRlZCBpdCBhdCBhbiBJSVcgc2Vzc2lvbi4N Cg0KQXMgdG8gdGFraW5nIGFub3RoZXIgeWVhciwgSSBhbSBob3BlZnVsIHdlIGNhbiByZXNvbHZl IHRoZSByZW1haW5pbmcgaXNzdWVzIGluIFNFVCBhbmQgcHVibGlzaCBhIG5ldyBkcmFmdCBmb3Ig bGFzdCBjYWxsLiBJIGRvIG5vdCB0aGluayB3ZSB3aWxsIG5lZWQgdG8gd2FpdCBmb3IgYW5vdGhl ciBXRyBtZWV0aW5nIHRvIGFzayBmb3IgbGFzdCBjYWxsLg0KDQpXZSBhbHNvIGhhdmUgYSBudW1i ZXIgb2Ygb3RoZXIgZG9jdW1lbnRzIHRoYXQgYXJlIG5vdCBpbiBsYXN0IGNhbGwsIGFuZCB3ZSBk b24ndCBoYXZlIGEgV0cgYWRvcHRlZCBkcmFmdCB5ZXQgZm9yIG1hbmFnZW1lbnQuIFNvIHRoZXJl IGFyZSBzdGlsbCBhIG51bWJlciBvZiBkb2N1bWVudHMgdG8gd29yayB0aHJvdWdoIGJlZm9yZSB3 ZSBoYXZlIGFsbCB0aGUgYml0cyBmb3Igc29tZW9uZSB0byB3b3JrIHdpdGguDQoNCkkgZG8gdGhp bmsgd2UgaGF2ZSBiZWVuIG1ha2luZyBnb29kIHByb2dyZXNzIHNpbmNlIHRoZSBsYXN0IElFVEYg bWVldGluZywgYW5kIEkgYW0gaG9wZWZ1bCB3ZSBjYW4ga2VlcCB1cCB0aGlzIG1vbWVudHVtIGFu ZCBmaW5hbGl6ZSBhbGwgdGhlIGRvY3VtZW50cyBpbiBhIHRpbWVseSBtYW5uZXIuDQoNCi9EaWNr DQoNCg0KT24gVHVlLCBPY3QgMzEsIDIwMTcgYXQgMTI6NDggUE0sIE1pa2UgSm9uZXMgPE1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t Pj4gd3JvdGU6DQpJdOKAmXMgaGFyZCBmb3IgbWUgdG8gZXZlbiBleHByZXNzIG15IGxldmVsIG9m IGZydXN0cmF0aW9uIHdpdGggdGhlIHJlY2VudCBhdHRlbXB0cyB0byBvbmNlIGFnYWluIHJlZGVz aWduIHRoZSBTZWNFdmVudCBUb2tlbiBzcGVjLiAgV2XigJl2ZSBiZWVuIGF0IHRoaXMgZm9yIG11 bHRpcGxlIHllYXJzIGJlY2F1c2UgcGVvcGxlIGtlZXAgdHJ5aW5nIHRvIHJldmlzaXQgZGVjaXNp b25zIHRoYXQgd2VyZSBsb25nIGFnbyBtYWRlIGJ5IGNvbnNlbnN1cy4gIEl04oCZcyBiZWVuIHN0 YWJsZSBmb3Igb3ZlciBhIHllYXIgYW5kIHRoZSBtYWpvcml0eSBvZiBXR0xDIHJlc3BvbmRlbnRz IHNhaWQgc29tZSB2YXJpYW50IG9mIOKAnFdvcmtzIGZvciBtZSDigJMgc2hpcCBpdCHigJ0NCg0K VGhlcmXigJlzIG5vdCBzdWZmaWNpZW50IGp1c3RpZmljYXRpb24gdG8gdHJ5IHRvIHVuZG8gY29u c2Vuc3VzIHBvc2l0aW9ucyB0aGF0IGhhdmUgYmVlbiBkZWJhdGVkIGFuZCBhZmZpcm1lZCBvdmVy IGFuZCBvdmVyLiAgQ291bnRlbmFuY2luZyB3aG9sZXNhbGUgY2hhbmdlcyBhdCB0aGlzIGxhdGUg ZGF0ZSBpcyBjb3VudGVycHJvZHVjdGl2ZSBpbiB0aGUgZXh0cmVtZSENCg0KSXTigJlzIGZhciBi ZXR0ZXIgdGhhbiBnb29kIGVub3VnaCBhcy1pcy4gIEluIG15IGV4cGVyaWVuY2UsIGlmIHdlIHN0 YXJ0IHJlZGVzaWduaW5nIGl0LCBpdCB3aWxsIHJlc3VsdCBpbiBhbm90aGVyIHllYXLigJlzIGRl bGF5LiAgSXQgZG9lcyBzb21ldGhpbmcgc2ltcGxlIGFuZCB1c2VmdWwuICBQbGVhc2UsIGxldOKA mXMganVzdCBzaGlwIGl0LCBzbyBwZW9wbGUgY2FuIHJlbHkgb24gaXQuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZy b206IFBoaWwgSHVudCAoSURNKSBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbT5dDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMzAsIDIwMTcgMjo0 MiBQTQ0KVG86IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhh cmR0QGdtYWlsLmNvbT4+DQpDYzogWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29t PG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PjsgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PjsgTWlr ZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20+PjsgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5v cmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj4NCg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0g VXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD8NCg0KSW5saW5lLi4uDQoNClBo aWwNCg0KT24gT2N0IDMwLCAyMDE3LCBhdCAyOjIyIFBNLCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0 QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCkhpIFBoaWwN Cg0KQ29ycmVjdCBtZSBpZiBJIGFtIG1pc3VuZGVyc3RhbmRpbmcsIGJ1dCB0aGVyZSBpcyBhIFJJ U0MgcHJvZmlsZSBldmVudA0KDQoNCg0KImh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZl bnQvcmlzYy9ldmVudC10eXBlLzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVuaWQubmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0 eXBlXy0yNTVDJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVl YXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1p eVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JnM9MjVsMDlzSDhZVjQy eHpnVS1DWFNnOHhIOXR2eURKejQwdENSakZhbGhrdyZlPT5hY2NvdW50LWNyZWRlbnRpYWwtY2hh bmdlLXJlcXVpcmVk4oCdDQoNCg0KYW5kIGFuIFNDSU0gcHJvZmlsZSBldmVudA0KDQoNCiJodHRw czovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dOKAnQ0KDQoNCkknbSBz dWdnZXN0aW5nIHRoYXQgdHdvIGRpZmZlcmVudCBldmVudHMgd291bGQgYmUgc2VudC4gRW1iZWRk aW5nIG9uZSBpbiB0aGUgb3RoZXIgZG9lcyBub3QgbWFrZSBzZW5zZS4NCjxwaD5JdCBpcyBhIGh5 cG90aGV0aWNhbCBleGFtcGxlLiBKdXN0IGJlY2F1c2UgeW91IGRpc2FncmVlIG9uIHRoaXMgZG9l cyBub3QgbWVhbiBvdGhlcnMgYXJlIG5vdCB2YWxpZC4NCg0KSSBqdXN0IHBpY2tlZCBvdmVybGFw cGluZyBwcm9wb3NhbHMgdGhhdCBoYXZlIGRpZmZlcmVudCBtZWFuaW5nIChidXQgbm90IHRoZSBz YW1lKSB0byBpbGx1c3RyYXRlIHRoZSBkaWZmZXJlbmNlIGZyb20gaXNzdWluZyBhIHNpbmdsZSBz ZXQgd2l0aCBkaWZmZXJlbnQgZXZlbnRzLg0KDQpBcyBJIGhhdmUgc3RhdGVkIHRoaXMgaXMgdmVy eSBkaWZmZXJlbnQgZnJvbSBhc3NlcnRpbmcgbXVsdGlwbGUgZGlzdGluY3QgZXZlbnRzIGluIG9u ZSBTRVQuDQoNCkFsc28sIEkgdGhpbmsgaXQgaXMgc2ltcGxlciB0byBoYXZlIGV2ZW50X3R5cGUg YmUgYXQgdGhlIHNhbWUgbGV2ZWwgYXMgZXZlbnQNCg0KPHBoPm1heSBiZS4gSSB3YXMgd29ya2lu ZyBmcm9tIEFubmFiZWxsZSdzIHByb3Bvc2VkIGZvcm1hdC4NCg0Kew0KICAianRpIjogIjNkMGMz Y2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwIiwNCiAgImlhdCI6IDE0NTg0OTYwMjUsDQogICJp c3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwNCiAgImF1ZCI6IFsNCiAgICAiaHR0cHM6 Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLA0KICAg ICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVl NyINCiAgIF0sDQogICAiZXZlbnRfdHlwZSI6ICJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZl bnQvcGFzc3dvcmRSZXNldEV4dCIsDQogICAiZXZlbnQiOiB7DQogICAgICAgICAiaWQiOiI0NGY2 MTQyZGY5NmJkNmFiNjFlNzUyMWQ5IiwNCiAgICAgICAgICJyZXNldEF0dGVtcHRzIjo1DQogICAg ICAgfQ0KfQ0KDQp7DQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAi LA0KICAiaWF0IjogMTQ1ODQ5NjAyNSwNCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5j b20iLA0KICAiYXVkIjogWw0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThk NTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9G ZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Ig0KICAgXSwNCiAgICJldmVudF90eXBlIjog Imh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL2FjY291 bnQtY3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNj X2V2ZW50LTJEdHlwZV9hY2NvdW50LTJEY3JlZGVudGlhbC0yRGNoYW5nZS0yRHJlcXVpcmVkJmQ9 RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5h NUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1peVZuclptcjlfdUdD UTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JnM9blF5OWV6UFJqREdkdlJUQ2FpRHRpNE9I ZWxIM0RLZ1VDVEtqRjJHUS1zbyZlPT4iLA0KICAgImV2ZW50Ijogew0KICAgICAgIOKAnHN1YuKA nTrigJ03Mzc1NjI2QTY1NjM3NOKAnSwNCiAgICAgICDigJxpc3PigJ06Imh0dHBzOi8vaWRwLmV4 YW1wbGUuY29tLyINCiAgICAgICB9DQp9DQoNCg0KDQoNCg0KT24gTW9uLCBPY3QgMzAsIDIwMTcg YXQgMTI6MDkgUE0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQpBbm5hYmVsbGUvRGljaywNCg0KVGhhbmtzIGZvciB0 aGUgY29tbWVudHMuIEkgdGhpbmsgd2UgbmVlZCB0byBleGFtaW5lIHRoZSBjb25zZXF1ZW5jZXMg b2YgdGhlIHByb3Bvc2FsIGluIEpTT04uDQoNCkFzIEkgc3RhdGVkLCB3aGF0IGNhdXNlcyBtb3N0 IG9mIHRoZSBpc3N1ZSBpcyB0aGUgcHJvcG9zZWQgZXh0ZW5zaW9uIG1lY2hhbmlzbSBpbiB0aGUg cGF5bG9hZCAocG9zc2libHkgdXNpbmcgZXZlbnRzIGluIGEgcmVjdXJzaXZlIHdheSkuIERvZXMg aXQgZm9sbG93IHRoZSBvbGQgZm9ybWF0IG9yIHRoZSBuZXc/DQoNCkxldOKAmXMgIGNvbnNpZGVy IGEgdXNlIGNhc2Ugd2hlcmUgd2UgaGF2ZSBhbiBpZGVudGl0eSBtYW5hZ2VtZW50IHN5c3RlbSB0 aGF0IHVzZXMgU0NJTSwgYnV0IHRoZSBTQ0lNIHN5c3RlbSBpcyBhbHNvIHRoZSB1bmRlcmx5aW5n IGRhdGEgc3RvcmUgZm9yIENvbm5lY3QuICBBIFBhc3N3b3JkIHJlc2V0IG1pZ2h0IGdlbmVyYXRl IHRoZSBmb2xsb3dpbmcgZXZlbnQgd2hpY2ggaGFzIGFuIGV4dGVuc2lvbiAoY29udmV5aW5nIHJl c2V0IGNvdW50KSBBTkQgb3ZlcmxhcHBpbmcgc3RhdGVtZW50IGZyb20gUklTQy4gIEJPVEggb2Yg d2hpY2ggbWlnaHQgYmUgaW1wb3J0YW50IHRvIGEgc2ltaWxhciByZWNlaXZlciB1c2luZyBTQ0lN IGFuZCBPSURDLg0KDQpUaGUgMDMgc3BlYyBjdXJyZW50bHkgd291bGQgYWxsb3c6DQoNCg0Kew0K DQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KDQogICJpYXQi OiAxNDU4NDk2MDI1LA0KDQogICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwNCg0K ICAiYXVkIjogWw0KDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2 MWZhNWJiYzg3OTU5M2I3NzU0IiwNCg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVl ZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyINCg0KICAgXSwNCg0KICAgImV2ZW50cyI6IHsN Cg0KICAgICAidXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldCI6DQoNCiAg ICAgICB7ICJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkifSwNCg0KICAgICAiaHR0cHM6 Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiOg0KDQogICAgICAgeyAi cmVzZXRBdHRlbXB0cyI6NX0sDQoNCiAgICAgImh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2Vj ZXZlbnQvcmlzYy9ldmVudC10eXBlL1w8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50 LTJEdHlwZV8tMjU1QyZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1V QjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5B Jm09aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZzPTI1bDA5c0g4 WVY0Mnh6Z1UtQ1hTZzh4SDl0dnlESno0MHRDUmpGYWxoa3cmZT0+DQogICAgICAgYWNjb3VudC1j cmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZCI6IHsNCg0KICAgICAgICAg4oCcc3Vi4oCdOuKAnTcz NzU2MjZBNjU2Mzc04oCdLA0KDQogICAgICAgICDigJxpc3PigJ06Imh0dHBzOi8vaWRwLmV4YW1w bGUuY29tLyINCg0KICAgICAgIH0NCg0KICB9DQoNCn0NCg0KDQoNCkluIHRoZSBhYm92ZSAtIGVh Y2ggcGF5bG9hZCBpcyBhIOKAmHBlZXInIGFuZCBpc3N1ZWQgd2l0aG91dCBwcmVmZXJlbmNlIGJ5 IHRoZSB0cmFuc21pdHRlci4gVGhlIHJlY2VpdmVyIGNhbiBhc3NpZ24gcHJpb3JpdHkgaW4gaXRz IG93biBjb250ZXh0IGlmIHRoYXQgbWF0dGVycy4NCg0KDQoNClRoZSBuZXcgcHJvcG9zYWw6DQoN Cg0KDQp7DQoNCiAgImp0aSI6ICIzZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCIsDQoN CiAgImlhdCI6IDE0NTg0OTYwMjUsDQoNCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5j b20iLA0KDQogICJhdWQiOiBbDQoNCiAgICAiaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRz Lzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLA0KDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxl LmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Ig0KDQogICBdLA0KDQogICAiZXZl bnQiOiB7DQoNCiAgICAg4oCcZXZlbnRfdHlwZeKAnToidXJuOmlldGY6cGFyYW1zOnNjaW06ZXZl bnQ6cGFzc3dvcmRSZXNldOKAnSwNCg0KICAgICAiaWQiOuKAnTQ0ZjYxNDJkZjk2YmQ2YWI2MWU3 NTIxZDnigJ0sDQoNCiAgICAg4oCcZXZlbnRz4oCdOnsNCg0KICAgICAtPm5vdGUg4oCmaXMgdGhp cyB0aGUgb2xkIG9yIG5ldyBzdHJ1Y3R1cmU/IDwtDQoNCiAgICAgICAiaHR0cHM6Ly9leGFtcGxl LmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiOg0KDQogICAgICAgICB7ICJyZXNldEF0 dGVtcHRzIjo1fSwNCg0KICAgICAgICJodHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0L3NlY2V2ZW50 L3Jpc2MvZXZlbnQtdHlwZS9cPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZlbnRfcmlzY19ldmVudC0yRHR5 cGVfLTI1NUMmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVh cElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPWl5 Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmcz0yNWwwOXNIOFlWNDJ4 emdVLUNYU2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmU9Pg0KICAgICAgICAgYWNjb3VudC1jcmVk ZW50aWFsLWNoYW5nZS1yZXF1aXJlZCI6IHsNCg0KICAgICAgICAg4oCcc3Vi4oCdOuKAnTczNzU2 MjZBNjU2Mzc04oCdLA0KDQogICAgICAgICDigJxpc3PigJ06Imh0dHBzOi8vaWRwLmV4YW1wbGUu Y29tLyINCg0KICAgICAgIH0NCg0KICAgICB9DQoNCiAgIH0NCg0KfQ0KDQoNCg0KSW4gdGhlIGFi b3ZlLCBzdWItZXZlbnRzIG9yIGV4dGVuc2lvbnMgaGF2ZSBhIGRpZmZlcmVudCBmb3JtYXQuIFRo ZSBzYW1lIGNvbXBsYWludCBhYm91dCB0aGUgb3JpZ2luYWwgc3RhbmRzLg0KDQoNCg0KKk9SKiAo aWYgdGhlIHJlY2VpdmVyIGNhcmVzIGFib3V0IFJJU0MgbW9yZSkuICBOb3RlIHRoYXQgdGhpcyBs ZWFkcyB0byBhIHRyaXBsZSBuZXN0ZWQgc3RydWN0dXJlLg0KDQoNCg0Kew0KDQogICJqdGkiOiAi M2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KDQogICJpYXQiOiAxNDU4NDk2MDI1 LA0KDQogICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwNCg0KICAiYXVkIjogWw0K DQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5 M2I3NzU0IiwNCg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2 YjFkMDg2NDFkNzY3NmVlNyINCg0KICAgXSwNCg0KICAgImV2ZW50Ijogew0KDQogICAgIOKAnGV2 ZW50X3R5cGXigJ06Imh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVu dC10eXBlL1w8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAt M0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV8tMjU1QyZk PUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1u YTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09aXlWbnJabXI5X3VH Q1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZzPTI1bDA5c0g4WVY0Mnh6Z1UtQ1hTZzh4 SDl0dnlESno0MHRDUmpGYWxoa3cmZT0+DQoNCiAgICAgICAgICAgICBhY2NvdW50LWNyZWRlbnRp YWwtY2hhbmdlLXJlcXVpcmVk4oCdLA0KDQogICAgICDigJxzdWLigJ064oCdNzM3NTYyNkE2NTYz NzTigJ0sDQoNCiAgICAgIOKAnGlzc+KAnToiaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20v4oCcLA0K DQogICAgICDigJxldmVudHPigJ06ew0KDQogICAgICAgICJ1cm46aWV0ZjpwYXJhbXM6c2NpbTpl dmVudDpwYXNzd29yZFJlc2V0IjoNCg0KICAgICAgICB7DQoNCiAgICAgICAgICAiaWQiOuKAnTQ0 ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDnigJ0sDQoNCiAgICAgICAgICDigJxldmVudHPigJ06ew0K DQogICAgICAgICAgICAgImh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJl c2V0RXh0IjoNCg0KICAgICAgICAgICAgICAgeyAicmVzZXRBdHRlbXB0cyI6NX0sDQoNCiAgICAg ICAgICB9DQoNCiAgICAgICAgfQ0KDQogICAgICB9DQoNCiAgIH0NCg0KfQ0KDQoNCg0KSW4gdGhl IGFib3ZlLCB0aGUgZXh0ZW5zaW9uIGlzIHBsYWNlZCBpbnNpZGUgdGhlIGV2ZW50IGl0IGV4dGVu ZHMuIEl0IGZvbGxvd3MgdGhlIG9sZCBmb3JtYXQgKG9yIHNob3VsZCBpdCBmb2xsb3cgdGhlIG5l dz8pDQoNCipPUiogRm9sbG93aW5nIHRoZSB0b3AgbGF5ZXIgcGF0dGVybiBvZiBzaW5ndWxhciBl dmVudCAgTm90ZSB0aGF0IHRoaXMgbGVhZHMgdG8gYSB0cmlwbGUgbmVzdGVkIHN0cnVjdHVyZS4N Cg0KDQoNCnsNCg0KICAianRpIjogIjNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwIiwN Cg0KICAiaWF0IjogMTQ1ODQ5NjAyNSwNCg0KICAiaXNzIjogImh0dHBzOi8vc2NpbS5leGFtcGxl LmNvbSIsDQoNCiAgImF1ZCI6IFsNCg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVl ZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsDQoNCiAgICAiaHR0cHM6Ly9qaHViLmV4YW1w bGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciDQoNCiAgIF0sDQoNCiAgICJl dmVudCI6IHsNCg0KICAgICDigJxldmVudF90eXBl4oCdOiJodHRwOi8vc2NoZW1hcy5vcGVuaWQu bmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS9cPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZlbnRfcmlz Y19ldmVudC0yRHR5cGVfLTI1NUMmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhC djdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxj TE40S1pOQSZtPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmcz0y NWwwOXNIOFlWNDJ4emdVLUNYU2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmU9Pg0KDQogICAgICAg ICAgICAgYWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZOKAnSwNCg0KICAgICAg4oCc c3Vi4oCdOuKAnTczNzU2MjZBNjU2Mzc04oCdLA0KDQogICAgICDigJxpc3PigJ06Imh0dHBzOi8v aWRwLmV4YW1wbGUuY29tL+KAnCwNCg0KICAgICAg4oCcZXZlbnTigJ06ew0KDQogICAgICAgIOKA nGV2ZW50X3R5cGXigJ06InVybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3JkUmVzZXTi gJ0sDQoNCiAgICAgICAgImlkIjrigJ00NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ54oCdLA0KDQog ICAgICAgIOKAnGV2ZW504oCdOnsNCg0KICAgICAgICAgIOKAnGV2ZW50X3R5cGXigJ06Imh0dHBz Oi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh04oCdLA0KDQogICAgICAg ICAgInJlc2V0QXR0ZW1wdHMiOjUNCg0KICAgICAgICB9DQoNCiAgICAgIH0NCg0KICAgfQ0KDQp9 DQoNCg0KDQpUaGlzIGZvcm1hdCBmb2xsb3dzIHRoZSBwcm9wb3NlZCBzaW5ndWxhciBldmVudCBm b3JtYXQgcmVjdXJzaXZlbHkgYW5kIGlzIDMgbGF5ZXJzIGRlZXAuIE5vdGUgdGhhdCB0aGUgcGFy c2VyIGhhcyB0byBjb250aW51ZSB0byBzZWFyY2ggdGhlIGRvY3VtZW50IGZvciB0aGluZ3MgdGhh dCBhcmVu4oCZdCB0aGVyZSBhcyBpdCBoYXMgdG8gc3RvcCB3aGVuIG5vIOKAnGV2ZW504oCdIGF0 dHJpYnV0ZSBpcyBmb3VuZCByYXRoZXIgdGhhbiBpdGVyYXRlIG92ZXIgYW4gYXJyYXkuDQoNCg0K UGhpbA0KDQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hp dGVjdA0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fd3d3LmluZGVwZW5kZW50aWQu Y29tJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0pu RSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1peVZuclpt cjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JnM9OXNZaGdwRXpiN3hQbFFGbUND WE5tSG82ZlFOOUlCdS1TSEphbWdfQjRIcyZlPT4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KT24gT2N0IDMwLCAyMDE3LCBhdCA4OjU3IEFNLCBS aWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmlj aGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KDQpSZXBsaWVzIGlubGluZS4NCg0KLS0NCkFubmFi ZWxsZSBSaWNoYXJkIEJhY2ttYW4NCklkZW50aXR5IFNlcnZpY2VzDQoNCg0KRnJvbTogUGhpbCBI dW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pg0K RGF0ZTogU3VuZGF5LCBPY3RvYmVyIDI5LCAyMDE3IGF0IDU6MjUgUE0NClRvOiBEaWNrIEhhcmR0 IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0KQ2M6 IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZA Z21haWwuY29tPj4sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4sICJSaWNoYXJkIEJhY2ttYW4sIEFubmFi ZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+Piwg SUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50 QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlw bGUgZXZlbnRzIHBlciBTRVQ/DQoNCkkgaG9wZSB0aGlzIGFuc3dlcnMgeW91ciBxdWVzdGlvbi4N Cg0KTXkg4oCcbWF54oCdIHdhcyBiZWNhdXNlIEkgY2Fu4oCZdCBzZWUgYSByZWFzb24gd2h5IG5v dC4gVGhlIHF1ZXN0aW9uIHNob3VsZCBiZSwgd2hhdCBpcyB0aGUganVzdGlmaWNhdGlvbiB0byBt YWtlIOKAnGV2ZW50c+KAnSBzaW5ndWxhcj8NCltyaWNoYW5uYV1UaGUgc2luZ3VsYXIg4oCcZXZl bnTigJ0gY2xhaW0gaGFzIGNsZWFyZXIgc2VtYW50aWNzIGFuZCBpcyBlYXNpZXIgdG8gcHJvY2Vz cy4gV2Ugc2hvdWxkIG9wdCBmb3IgZWFzaWVyIHNvbHV0aW9ucyB1bmxlc3MgdGhlcmUgYXJlIHVz ZSBjYXNlcyB0aGF0IHJlcXVpcmUgbW9yZSBjb21wbGV4aXR5LlsvcmljaGFubmFdDQoNClRoZXJl IGFyZSBtYW55IHJlYXNvbnMgZm9yIG11bHRpcGxlIGV2ZW50cyBpbiBhIFNFVC4gIFNvbWUgYXJl IGdvb2QsIHNvbWUgbm90IHNvIGdvb2QuIFNvbWUgb2YgdGhlIHJlYXNvbnMuLi4NCg0KMS4gIE11 bHRpcGxlIGV2ZW50IHBheWxvYWRzIGV4cHJlc3Npbmcgc3RhdGVtZW50cyBhYm91dCBsYXJnZWx5 IHRoZSAqc2FtZSp0aGluZy4gRm9yIGV4YW1wbGUsIFNDSU0gcGFzc3dvcmQgcmVzZXQgQU5EIFJJ U0MgcGFzc3dvcmQgcmVzZXQuICBBIFJJU0MgRXZlbnQgYW5kIGFuIE9wZW5CYW5raW5nIEV2ZW50 LiBJcyBvbmUgYSBjb21wbGVtZW50IHRvIHRoZSBvdGhlcj8gIERvIHRoZXkgb3ZlcmxhcCBvciBh cmUgdGhleSBkaXN0aW5jdD8NCltyaWNoYW5uYV1Db3B5L3Bhc3RlZCBmcm9tIG15IGVhcmxpZXIg ZW1haWw6DQpXaHkgaXMgaXQgbmVjZXNzYXJ5IG9yIGFwcHJvcHJpYXRlIHRvIGluY2x1ZGUgdGhl c2UgZXZlbnRzIGluIHRoZSBzYW1lIFNFVD8gVGhleSBhcmUgbGlrZWx5IGJlaW5nIGdlbmVyYXRl ZCBieSBkaWZmZXJlbnQgc3lzdGVtcyBhdCBkaWZmZXJlbnQgdGltZXMgb24gdGhlIHRyYW5zbWl0 dGVy4oCZcyBzaWRlLCBjb25zdW1lZCBieSBkaWZmZXJlbnQgc3lzdGVtcyBvbiB0aGUgcmVjZWl2 ZXLigJlzIHNpZGUsIGFuZCBwb3NzaWJseSBiZWluZyB0cmFuc21pdHRlZCBvdmVyIGRpZmZlcmVu dCBldmVudCBzdHJlYW1zLiBJIGtub3cgdGhlIGxhdHRlciB3b3VsZCBiZSB0aGUgY2FzZSBmb3Ig dXMsIGFzIGEgcmVjZWl2ZXIuIEV2ZW4gaWYgaXTigJlzIG5vdCwgaXMgaXQgYnVyZGVuc29tZSB0 byBzZW5kIHRoZXNlIGV2ZW50cyBzZXBhcmF0ZWx5PyBXaGF0IHZhbHVlIGlzIGdhaW5lZCBpbiBj b21iaW5pbmcgdGhlbT8NCg0KQWRkaXRpb25hbGx5LCBzaW5jZSB0aGUgc2lnbmF0dXJlIGlzIG92 ZXIgdGhlIFNFVCBhbmQgbm90IHRoZSBldmVudCBvYmplY3RzLCBSZWNlaXZlcnMgaW5kZXBlbmRl bnRseSByb3V0ZSBzZXBhcmF0ZSBldmVudHMgZnJvbSBhIHNpbmdsZSB0b2tlbiB3aXRob3V0IGVp dGhlciBsb3NpbmcgdGhlIGFiaWxpdHkgdG8gdmVyaWZ5IHRoZSBhdXRoZW50aWNpdHkgb2YgdGhl IGV2ZW50IG9yIHNoYXJpbmcgYWxsIGluZm9ybWF0aW9uIGluIHRoZSBTRVQgd2l0aCBldmVyeSBz eXN0ZW0gaGFuZGxpbmcgYW55IGV2ZW50IGluIHRoZSB0b2tlbi5bL3JpY2hhbm5hXQ0KDQoyLiAg TXVsdGlwbGUgZXZlbnRzIHBheWxvYWRzIGV4cHJlc3NpbmcgZGlmZmVyZW50IHN0YXRlbWVudHMg YWJvdXQgdGhlIHNhbWUgdHJhbnNhY3Rpb24gLSBSSVNDIFBhc3N3b3JkIFJlc2V0IGFuZCBSSVND IFNlc3Npb24gQ2FuY2VsDQpbcmljaGFubmFdU2FtZSBhcyBhYm92ZVsvcmljaGFubmFdDQozLiAg QSBuZXcgcHJvZmlsZSBkZWZpbmVzIG5ldyBldmVudCBhdHRyaWJ1dGVzIHRvIGJlIGFkZGVkIG9u IHRvIGFuIGV4aXN0aW5nIGV2ZW50IHR5cGUgKGEgcHVyZSBleHRlbnNpb24pDQpbcmljaGFubmFd SSBoYXZlIHN1Z2dlc3RlZCBhIHdheSB0byBzdXBwb3J0IGV4dGVuc2lvbnMgd2l0aGluIGFuIGV2 ZW50IGJvZHksIG11bHRpcGxlIHRpbWVzIG5vdy4gSWYgeW91IHNlZSBwcm9ibGVtcyB3aXRoIGl0 LCBwbGVhc2UgcG9pbnQgdGhlbSBvdXQuWy9yaWNoYW5uYV0NCg0KSSB0aGluayBpdCBpcyBxdWl0 ZSB2YWxpZCB0byBhbGxvdyAxIGFuZCAzLiAgMiBjb3VsZCBiZSBsaW1pdGVkIGJ5IHNwZWNpZmlj IHByb2ZpbGVzIGxpa2UgUklTQyBpZiB0aGV5IHdhbnQuDQoNCkkgYW0gbm90IGluIGFncmVlbWVu dCB0aGF0IG1ha2luZyBldmVudCBzaW5ndWxhciBzaW1wbGlmaWVzIGFueXRoaW5nLiBGb3Igb25l IGlzIG1ha2VzIGV4dGVuc2lvbnMgY29tcGxleCAoYW5vdGhlciBuZXN0ZWQgSlNPTiBzdHJ1Y3R1 cmUpIGFuZCBwb3RlbnRpYWxseSBjb25mbGljdGluZy4NCltyaWNoYW5uYV0NCldheXMgdGhhdCBt dWx0aXBsZS1ldmVudCBTRVRzIGFyZSBtb3JlIGNvbXBsaWNhdGVkOg0KDQogIDEuICBJdCByZXN1 bHRzIGluIGEgbW9yZSBjb21wbGV4IHN0cnVjdHVyZSBmb3IgdGhlIHNpbmdsZSBldmVudCB1c2Ug Y2FzZSwgd2hpY2ggSSB0aGluayB3ZSBhbGwgYWdyZWUgaXMgdGhlIG1ham9yaXR5IHVzZSBjYXNl Lg0KICAyLiAgTXVsdGlwbGUtZXZlbnQgU0VUcyBoYXZlIGFtYmlndW91cyBzZW1hbnRpY3MuIFRo ZSBwcmVzZW5jZSBvZiB0d28gZXZlbnRzIEEgYW5kIEIgaW4gdGhlIHNhbWUgU0VUIGNvdWxkIG1l YW4gYW55IG9mOg0KDQogICAgICogICBUaGV5IGFyZSByZWxhdGVkIHRvIHRoZSBzYW1lIGxvZ2lj YWwgZXZlbnQgKGkuZS4gdGhlIHNhbWUgdGhpbmcgYXMgaWYgdGhleSB3ZXJlIGZyb20gZGlmZmVy ZW50IFNFVHMgdGhhdCBoYXZlIGEgY29tbW9uIHR4bikuDQogICAgICogICBBIGlzIGFuIGV4dGVu c2lvbiBvZiBCLg0KICAgICAqICAgQiBpcyBhbiBleHRlbnNpb24gb2YgQS4NCiAgICAgKiAgIFRo ZXkgYXJlIGFsaWFzZXMgZm9yIG9uZSBhbm90aGVyLg0KICAgICAqICAgVGhleSBhcmUgbm90IGFj dHVhbGx5IHJlbGF0ZWQgdG8gb25lIGFub3RoZXIgaW4gYW55IHdheS4NCg0KICAxLiAgQ2xhaW0g c2VtYW50aWNzIGJlY29tZSBoYXJkZXIgdG8gZGVmaW5lLCBhcyBkaWZmZXJlbnQgcHJvZmlsZXMg bWF5IHdhbnQgdG8gdXNlIHRoZSBzYW1lIGNsYWltcyBpbiBkaWZmZXJlbnQgd2F5cy4NCg0KSWYg dGhlIFdHIHdhbnRzIHRvIGJsb2NrIDEgYW5kIDIgYWJvdmUsIHRoZW4gSSBiZWxpZXZlIHdlIGhh dmUgdG8gZXN0YWJsaXNoIGFuIGV2ZW50IHJlZ2lzdHJ5IHRvIGVuc3VyZSBuZXcgRXZlbnQgcHJv ZmlsZXMgZG8gbm90IG92ZXJsYXAgdG8gZWxpbWluYXRlIHRoZSBuZWVkIHRvIGV4cHJlc3MgbXVs dGlwbGUgZXZlbnRzLg0KW3JpY2hhbm5hXUnigJltIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkg dGhpcy4gQXJlIHlvdSByZWZlcnJpbmcgdG8gZXZlbnQgbmFtZXM/IFRob3NlIGFyZSBhbHJlYWR5 IGRlZmluZWQgYnkgdGhlIHNwZWMgdG8gYmUgVVJJcy5bL3JpY2hhbm5hXQ0KUGhpbA0KDQpPcmFj bGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdA0KQGluZGVw ZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fd3d3LmluZGVwZW5kZW50aWQuY29tJmQ9RHdNR2FR JmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJU V21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1VLWE1SEJORDBIYVRYNGFuTlpm elg3cERzZks1ZjBoOW1aOUNaa2tHaWVjJnM9S0J3S1BGbnFZX1E5NUNUQV9fV0dDWUdUeHJEN0FH Q3h1ZW9QWG5LRVVUMCZlPT4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbT4NCg0KT24gT2N0IDI5LCAyMDE3LCBhdCA0OjEyIFBNLCBEaWNrIEhhcmR0IDxk aWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToN Cg0KUGhpbDoNCg0KSW4geW91ciBleGFtcGxlcyBmb3IgaGF2aW5nIGEgcGx1cmFsaXR5IG9mIGV2 ZW50cywgeW91IHVzZSB0aGUgd29yZCAibWF5Iiwgd2hpY2ggbGVhZHMgbWUgdG8gcXVlc3Rpb24g aWYgYSBwbHVyYWxpdHkgb2YgZXZlbnRzIGlzIHJlYWxseSByZXF1aXJlZCBpbiBTRVQuDQoNCllv dSBwb3NpdCB0aGF0IGl0IHdpbGwgYmUgZGlmZmljdWx0IGZvciBhIGRpc3RyaWJ1dGVkIHN5c3Rl bSB0byBjb3JyZWxhdGUgbXVsdGlwbGUgU0VUcyB3aXRoIHRoZSBzYW1lICJ0eG4iLCBidXQgdGhl IGRpc3RyaWJ1dGVkIHN5c3RlbSB3aWxsIGNlcnRhaW5seSBuZWVkIHRvIGNvcnJlbGF0ZSBldmVu dHMgb24gdGhlIHNhbWUgc3ViamVjdCAtLSBjb3JyZWxhdGluZyBldmVudHMgb24gdGhlIHNhbWUg InR4biIgb24gdGhlIHNhbWUgc3ViamVjdCBzZWVtcyBmYWlybHkgc2ltcGxlLg0KDQpJIHRoaW5r IHRoYXQgYSByZWNlaXZlciB3aWxsIG5lZWQgdG8gY29ycmVsYXRlIG11bHRpcGxlIFNFdHMgb24g dGhlIHNhbWUgc3ViamVjdCwgc28gaGF2aW5nIG11bHRpcGxlIGV2ZW50cyBpbiBhIFNFVCBpcyBy ZWR1bmRhbnQsIGFuZCBhZGRzIGNvbXBsZXhpdHkgd2l0aCBubyBjbGVhciBiZW5lZml0IHRoYXQg SSBjYW4gc2VlLg0KDQpBbiBpbXBsZW1lbnRvciBtYXkgY2hvb3NlIHRvIHNlbmQgbXVsdGlwbGUg U0VUcywgb3Igc2VuZCBhIHNpbmdsZSBTRVQgd2l0aCBtdWx0aXBsZSBldmVudHMsIHNvIGEgcmVj ZWl2ZXIgd2lsbCBuZWVkIHRvIHN1cHBvcnQgYm90aC4gSSBwcmVmZXIgd2UgcGljayBvbmUgd2F5 IGFuZCBtaW5pbWl6ZSB0aGUgY29kZSBwYXRocywgYW5kIHdlIHdpbGwgbmVlZCB0byBzdXBwb3J0 IGNvcnJlbGF0aW5nIGFjcm9zcyBtdWx0aXBsZSBTRVRzLCBzbyB0aGF0IHNlZW1zIHRoZSBiZXN0 IG1lY2hhbmlzbS4NCg0KTGV0IG1lIGtub3cgaWYgdGhlcmUgaXMgc29tZXRoaW5nIEkgbWlzc2Vk IGluIG15IGxvZ2ljLg0KDQovRGljaw0KDQoNCk9uIFN1biwgT2N0IDI5LCAyMDE3IGF0IDExOjI4 IEFNLCBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5p ZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KSW4gdGhhdCBjYXNlLCBsZXQncyBhZGQgdGV4dCB0byB0 aGF0IGVmZmVjdCwgZS5nLiB3ZSBjb3VsZCBhZGQgdG8gdGhlIGRlZmluaXRpb24gb2YgdGhlICJl dmVudHMiIGNsYWltOg0KDQpQcm9maWxpbmcgc3BlY2lmaWNhdGlvbnMgU0hPVUxEIGRlZmluZSB0 aGUgYWxsb3dlZCBldmVudCBzdGF0ZW1lbnRzLCBhbmQgTUFZIHJlc3RyaWN0IHRoZWlyIG51bWJl ci4gRm9yIGV4YW1wbGUsIHNvbWUgcHJvZmlsZXMgbWF5IHJlcXVpcmUgdGhpcyBjbGFpbSB0byBj b250YWluIG9ubHkgYSBzaW5nbGUgZXZlbnQgc3RhdGVtZW50Lg0KDQpUaGFua3MsDQogICAgICAg IFlhcm9uDQoNCk9uIDI0LzEwLzE3IDIyOjEwLCBNaWtlIEpvbmVzIHdyb3RlOg0KSSBhZ3JlZSB3 aXRoIG11Y2ggb2YgUGhpbOKAmXMgcmF0aW9uYWxlIGhlcmUuDQoNCkl04oCZcyBmaW5lIGZvciBz b21lIHByb2ZpbGVzIHRvIHNheSB0aGF0IHRoZSDigJxldmVudHPigJ0gc2V0IG11c3QgYmUgYSBz aW5nbGV0b24uICBUaGF0IGRvZXNu4oCZdCBoYXZlIHRvIGJlIHRydWUgZm9yIGFsbCBldmVudHMu ICBJIHRoaW5rIHRoaW5ncyBhcmUgZmluZSBhcy1pcy4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCipG cm9tOiogSWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpp ZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPl0gKk9uIEJlaGFsZiBPZiAqUGhpbCBIdW50DQoqU2Vu dDoqIE1vbmRheSwgT2N0b2JlciAyMywgMjAxNyA4OjQ3IFBNDQoqVG86KiBSaWNoYXJkIEJhY2tt YW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9u LmNvbT4+DQoqQ2M6KiBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxt YWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KKlN1YmplY3Q6KiBSZTogW0lkLWV2ZW50XSBVc2Ug Y2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPw0KDQpBbm5hYmVsbGUsDQoNCkkgaGF2 ZSBhIG51bWJlciBvZiBjb25jZXJucyB3aXRoIHRoaXMgcHJvcG9zYWwuDQoNClByb2ZpbGluZyBJ bmRlcGVuZGVuY2UgLyBLZWVwaW5nIEV2ZW50IFBheWxvYWRzIEluZGVwZW5kZW50DQoNCkluZGlj YXRpbmcgdGhhdCBleHRlbnNpb25zIHNob3VsZCBiZSBoYW5kbGVkIGJ5IHByb2ZpbGVzIGxlYWRz IHRvIG1vcmUgaW50ZXItb3BlcmFiaWxpdHkgaXNzdWVzIGFuZCBtb3JlIGltcG9ydGFudGx5IGlu dHJ1ZGVzIG9uIHRoZSBFdmVudCBwYXlsb2FkIHNwYWNlIGJ5IHN1Z2dlc3RpbmcgYSBzdWItc2No ZW1hIGNyZWF0ZXMgcG90ZW50aWFsIGxpbWl0YXRpb25zIGFuZCBjb25mbGljdHMgdGhhdCBtYXkg YWRkIHRvIGNvbXBsZXhpdHkgbGF0ZXIgb24uIFRoZSBjdXJyZW50IGZvcm1hdCBhbGxvd3MgYSBw YXJzZXIgdG8gZGlzY292ZXIgYW5kIHVubG9hZCBvbmUgb3IgbW9yZSBKU09OIHBheWxvYWRzIHdo aWNoIGNhbiBlYWNoIGhhdmUgaW5kZXBlbmRlbnQgc3RydWN0dXJlLg0KDQpHZW5lcmFsIGV4dGVu c2lvbnMNCg0KVGhlIHByb3Bvc2FsIGFsc28gcnVsZXMgb3V0IGdlbmVyYWwgcHVycG9zZSBleHRl bnNpb25zIG5vdCByZWxhdGVkIHRvIGFueSBzcGVjaWZpYyBldmVudC4gR2l2ZW4gdGhlIGVtZXJn ZW5jZSBvZiBpdGVtcyBsaWtlIEdQUkQsIEkgd291bGQgbm90IHdhbnQgdG8gYmxvY2sgdGhlIGFi aWxpdHkgdG8gYWRkIG1ldGEtZGF0YSBvciBvdGhlciBnZW5lcmFsIHB1cnBvc2UgaXRlbXMuIFdl IGNhbiBhbHNvIGFudGljaXBhdGUgc29tZSBkZWxpdmVyeSBzY2VuYXJpb3Mgd2hlcmUgYWRkaXRp b25hbCBkYXRhIG1pZ2h0IGJlIHJlcXVpcmVkLiBFdmVuIHRob3VnaCB0aGVyZSBpcyBubyBjdXJy ZW50IHBsYW5uZWQgdXNlLCBJIHNlZSBubyBnb29kIHJlYXNvbiB0byBydWxlIHRoaXMgb3V0Lg0K DQpNdWx0aXBsZSBFdmVudHMgRnJvbSBEaWZmZXJlbnQgRmFtaWxpZXMgKHZzLiBNdWx0aXBsZSBF dmVudHMgZnJvbSBhIHNpbmdsZSBmYW1pbHkgbGlrZSBSSVNDKQ0KDQpJbiBvdXIgUklTQyBzZXNz aW9uIHdlIGRpc2N1c3NlZCBleHByZXNzaW5nIG11bHRpcGxlIGRpc3RpbmN0IFJJU0MgZXZlbnRz IGluIG9uZSBTRVQuIFRoZSBkaXNjdXNzaW9uIHdhcyB0aGF0IG9ubHkgb25lIFJJU0MgZXZlbnQg YXQgYSB0aW1lLiBXZSBkaWQgbm90IGRpc2N1c3Mgb3RoZXIgZXZlbnQgcHJvZmlsZXMuIEkgZG9u 4oCZdCBzZWUgYSByZWFzb24gdG8gcnVsZSBvdXQgbXVsdGktZXZlbnRzIGZyb20gZGlmZmVyZW50 IGZhbWlsaWVzIGF0IHRoZSBTRVQgbGV2ZWwuIEVhY2ggcHJvZmlsZSBpcyBleHByZXNzaW5nIHNs aWdodGx5IGRpZmZlcmVudCB0aGluZ3MgYWJvdXQgdGhlIHNhbWUgZXZlbnQuDQoNCkkgY2FuIGZv cnNlZSBzb21lIGNhc2VzIHdoZXJlIGl0IGlzIG5vdCBjbGVhciB3aGljaCBpcyB0aGUgcHJpbWFy eSBhbmQgd2hpY2ggaXMgdGhlIGV4dGVuc2lvbi4gIFRoZXJlIG1heSBub3QgYmUgYSBjbGVhciB3 aW5uZXIuDQoNCkEgY291cGxlIG9mIGV4YW1wbGVzICh0aGVzZSBhcmUgbmVjZXNzYXJpbHkgcmVh bOKApmp1c3QgcG9zc2liaWxpdGllcyk6DQoNCiogSXQgaXMgcHJvYmFibHkgdXNlZnVsIHRvIGJl IGFibGUgdG8gZXhwcmVzcyBzaW1sYXIvb3ZlcmxhcHBpbmcgZXZlbnRzIGZyb20gZGlmZmVyZW50 IFNFVCBwcm9maWxlcyBpbiBvbmUgU0VULiAgRm9yIGV4YW1wbGUgYSBCYWNrY2hhbm5lbCBMb2dv dXQgJiBhIFJJU0Mgc2Vzc2lvbiBjYW5jZWwgZXZlbnQuDQoNCiogU0NJTSBtYXkgd2FudCB0byBy ZXByZXNlbnQgYSBzaW5nbGUgdHJhbnNhY3Rpb24gYXMgY2F1c2luZyBtdWx0aXBsZSBzdGF0ZSBj aGFuZ2VzIGluIGFuIGV2ZW50IChlLmcuIGEgcGFzc3dvcmQgY2hhbmdlIGNhdXNlcyBtdWx0aXBs ZSBlZmZlY3RzKS4gSGF2aW5nIHRvIGNoYXNlIGRvd24gbXVsdGlwbGUgZXZlbnRzIGFuZCBjb3Jy ZWxhdGUgYnkg4oCcdHhu4oCdIHdvdWxkIGJlIGNoYWxsZW5naW5nIGluIGEgbXVsdGktdGhyZWFk ZWQvbXVsdGktbm9kZSBkZWxpdmVyeSBzeXN0ZW0uICAgVGhlIFNDSU0gbGlzdCBoYXMgbm90IGRp c2N1c3NlZCB0aGlzLCBidXQgSSB3b3VsZCBub3Qgd2FudCB0byBibG9jayB0aGlzIGNhcGFiaWxp dHkuICBJT1cgLSBKdXN0IGJlY2F1c2UgUklTQyBkb2VzIG5vdCB3YW50IHRvIGV4cHJlc3MgbXVs dGlwbGUgZXZlbnRzIGRvZXMgbm90IG1ha2UgdGhpcyB0cnVlIGZvciBvdGhlciBwcm9maWxlcy4N Cg0KKiBXZSBtYXkgd2lzaCB0byBpbmRpY2F0ZSBhIFNDSU0gUGFzc3dvcmQgUmVzZXQgd2FzIHBl cmZvcm1lZCBhbmQgYSBMb2dvdXQvc2Vzc2lvbiBjYW5jZWxsYXRpb24gaXMgZXhwcmVzc2VkIGF0 IHRoZSBzYW1lIHRpbWUuICBUaGUgZXZlbnRzIGFyZSByZWxhdGVkIGJ1dCBleHByZXNzIGRpZmZl cmVudCBkYXRhLg0KDQpBdm9pZGluZyBDb25mdXNpb24gRnJvbSBTaW1pbGFyIEV2ZW50cyBPcmln aW5hdGluZyBmcm9tIHRoZSBTYW1lIFRyYW5zYWN0aW9uDQoNCklmIGV2ZW50cyBhcmUgc2VudCBz ZXBhcmF0ZWx5LCB0aGVuIG1vcmUgdHJhY2tpbmcgb2Ygc3RhdGUgKGUuZy4gYnkgdHhuKSB3b3Vs ZCBiZSByZXF1aXJlZCB0byBlbnN1cmUgc2ltaWxhciBldmVudHMgYXJlIG5vdCBtaXN0YWtlbiBv ciBoYW5kbGVkIGFzIHJlcGVhdHMuIFdoaWxlIHR4biBwcm92aWRlcyB1c2VmdWwgYXVkaXQgYW5h bHlzaXMgY2FwYWJpbGl0eSwgSeKAmW0gbm90IHN1cmUgaXQgY2FuIGJlIHVzZWQgaW4gbGl2ZSBv ciBuZWFyLXJlYWwgdGltZSBzeXN0ZW1zIGdpdmVuIGRpc3RyaWJ1dGVkIG11bHRpLW5vZGUsIG11 bHRpLXRocmVhZGluZyBhcmNoaXRlY3R1cmVzLg0KDQpQcmV2aW91cyBEaXNjdXNzaW9uDQoNCkkg bm90ZSB0aGF0IEkgb3JpZ2luYWxseSByYWlzZWQgaGF2aW5nIGFuIGF0dHJpYnV0ZSB0byBkZXNp Z25hdGUgcHJpbWFyeSBldmVudCBhdHRyaWJ1dGUgdG8gYWxsZXZpYXRlIHlvdXIgY29uY2Vybiwg YnV0IHRoaXMgd2FzIG5vdCBhY2NlcHRlZC4gU2VlOg0KDQoqIGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3VycmVudC9tc2cwMDQwNi5odG1sPGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRfbXNnMDA0MDYuaHRtbCZkPUR3 TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVG VnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09WUJDR2xLOW1qamhjRnNq LTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZzPVMzc01WaXFNdkVnbndHYkp3T1FOeWNyT3ly N1NlZnBxX01vRk9LY0VlQ0UmZT0+DQoNCiogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9pZC1ldmVudC9jdXJyZW50L21zZzAwMTQwLmh0bWw8aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbC0yRGFy Y2hpdmVfd2ViX2lkLTJEZXZlbnRfY3VycmVudF9tc2cwMDE0MC5odG1sJmQ9RHdNRmFRJmM9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFX Tnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1 eHVydWliOUtBVGtSbFFHMWl3JnM9R3k5Z3lSb0lJdGEtY1NoVjdiTjE2MWF5NHlFNnI5RzFfQWFf TmVCbnlsZyZlPT4NCg0KVGhlIGNvbnNlbnN1cywgYXQgbGVhc3QgYXMgSSBpbnRlcnByZXRlZCBp dCBpcyB1cCB0byB0aGUgcmVjZWl2ZXIgdG8gZmlndXJlIHRoaXMgb3V0IGJhc2VkIG9uIHRoZSBk ZWZpbml0aW9ucyBpdCBoYXMgZm9yIGVhY2ggZXZlbnQgVVJJIGFuZCB0aGUgcHJvZmlsZXMgdGhl eSByZXByZXNlbnQuIElPVyAtIFJJU0MgaXMgZnJlZSB0byBsaW1pdCB0aGF0IG9ubHkgb25lIFJJ U0MgZXZlbnQgYmUgZXhwcmVzc2VkIGF0IGEgdGltZS4NCg0KUGhpbA0KDQpPcmFjbGUgQ29ycG9y YXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdA0KDQpAaW5kZXBlbmRlbnRp ZA0KDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNvbSZkPUR3TUZhUSZjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5x V055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFB dXh1cnVpYjlLQVRrUmxRRzFpdyZzPTlOUDVuYW1nNnJJVnp3dW45Yy0xcTB3aHN5WHdTdnRIQjBm MmRLa2ZDWDgmZT0+IDxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5j b20mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5F JnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPVlCQ0dsSzlt ampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmcz05TlA1bmFtZzZySVZ6d3VuOWMt MXEwd2hzeVh3U3Z0SEIwZjJkS2tmQ1g4JmU9Pj4NCg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPiA8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPG1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQoNCiAgICBPbiBPY3QgMjMsIDIwMTcsIGF0IDc6 MDIgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlDQogICAgPHJpY2hhbm5hQGFtYXpvbi5j b208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+IDxtYWlsdG86cmljaGFubmFAYW1hem9uLmNv bTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+PiB3cm90ZToNCg0KICAgIFRoZSBjdXJyZW50 IGRyYWZ0IG9mIHRoZSBTRVQgc3BlYyBhbGxvd3MgZm9yIGV4cHJlc3NpbmcgbXVsdGlwbGUNCiAg ICBldmVudHMgd2l0aGluIHRoZSBzYW1lIHRva2VuLCB3aGljaCBpbnRyb2R1Y2VzIGFkZGl0aW9u YWwgY29tcGxleGl0eQ0KICAgIGFuZCByb29tIGZvciBhbWJpZ3VvdXMgc2VtYW50aWNzLiBXZeKA mXZlIGRpc2N1c3NlZCB0aGlzIGluIHRoZSBPSURGDQogICAgUklTQyB3b3JraW5nIGdyb3VwIGFu ZCB0aGUgY3VycmVudCBjb25zZW5zdXMgdGhlcmUgaXMgdGhhdCBSSVNDIHdpbGwNCiAgICByZXF1 aXJlIHRoYXQgUklTQyBldmVudHMgbXVzdCBiZSB0aGUgb25seSBldmVudCBpbiB0aGUgU0VULCBo YXZpbmcNCiAgICBpZGVudGlmaWVkIHdheXMgdG8gY2xlYXJseSBhbmQgZWFzaWx5IHN1cHBvcnQg dGhlIGhhbmRmdWwgb2YgdXNlDQogICAgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgdG9r ZW4gdGhhdCBwZW9wbGUgaGF2ZSByYWlzZWQuIFdpdGgNCiAgICB0aGF0IGNvbnRleHQgaW4gbWlu ZCwgSSBwcm9wb3NlIHN0cmlraW5nIHRoZSBkZWZpbml0aW9uIG9mIHRoZQ0KICAgIOKAnGV2ZW50 c+KAnSBjbGFpbSBmcm9tIHRoZSBTZWN1cml0eSBFdmVudCBUb2tlbiBzcGVjLCBhbmQgcmVwbGFj aW5nIGl0DQogICAgd2l0aCB0aGUgZm9sbG93aW5nIGRlZmluaXRpb24gZm9yIGFuIOKAnGV2ZW50 4oCdIGNsYWltIChzaW5ndWxhcik6DQoNCiAgICBldmVudA0KDQogICAgQSBKU09OIG9iamVjdCBj b250YWluaW5nIGFuICJldmVudF90eXBlIiBtZW1iZXIgd2hvc2UgdmFsdWUgaXMgYSBVUkkNCiAg ICByZXByZXNlbnRpbmcgYSB0eXBlIG9mIGV2ZW50IGRlZmluZWQgaW4gYSBQcm9maWxpbmcgU3Bl Y2lmaWNhdGlvbi4NCiAgICBUaGUgb2JqZWN0IE1BWSBvdGhlcndpc2UgYmUgZW1wdHksIG9yIE1B WSBjb250YWluIGFkZGl0aW9uYWwgbWVtYmVycw0KICAgIGFzIGRlc2NyaWJlZCBieSB0aGUgUHJv ZmlsaW5nIFNwZWNpZmljYXRpb24uDQoNCiAgICBIZXJlIGlzIHRoZSBleGFtcGxlIFNFVCBmcm9t IHNlY3Rpb24gMi4zLCByZXdyaXR0ZW4gd2l0aCB0aGlzIGNoYW5nZQ0KICAgIG1pbmQ6DQoNCiAg ICB7DQoNCiAgICAgICAianRpIjogIjRkMzU1OWVjNjc1MDRhYWJhNjVkNDBiMDM2M2ZhYWQ4IiwN Cg0KICAgICAgICJpYXQiOiAxNDU4NDk2NDA0LA0KDQogICAgICAiaXNzIjogImh0dHBzOi8vc2Np bS5leGFtcGxlLmNvbTxodHRwczovL3NjaW0uZXhhbXBsZS5jb20vPiA8aHR0cHM6Ly9zY2ltLmV4 YW1wbGUuY29tLz4iLA0KDQogICAgICAgImF1ZCI6IFsNCg0KICAgICAgICAgImh0dHBzOi8vc2Np bS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiwNCg0KICAgICAg ICAgImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2 ZWU3Ig0KDQogICAgICAgXSwNCg0KICAgICAgICJldmVudCI6IHsNCg0KICAgICAgICAgImV2ZW50 X3R5cGUiOiAidXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6Y3JlYXRlIiwNCg0KICAgICAgICAg InJlZiI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYx ZTc1MjFkOSIsDQoNCiAgICAgICAgICJhdHRyaWJ1dGVzIjogWyJpZCIsICJuYW1lIiwgInVzZXJO YW1lIiwgInBhc3N3b3JkIiwgImVtYWlscyJdDQoNCiAgICAgICB9DQoNCiAgICB9DQoNCiAgICBE b2VzIGFueW9uZSBpbiB0aGUgd29ya2luZyBncm91cCBoYXZlIHVzZSBjYXNlcyBmb3IgU0VUcyB0 aGF0IGNhbm5vdA0KICAgIGJlIG1ldCBieSB0aGlzIHByb3Bvc2VkIHRleHQ/IFdpdGhpbiBSSVND LCB3ZSBpZGVudGlmaWVkIHRocmVlIHVzZQ0KICAgIGNhc2VzLCB3aXRoIHNvbHV0aW9ucyBvdXRs aW5lZCBiZWxvdzoNCg0KICAgICoqDQoNCiAgICAqRXh0ZW5zaW9ucyoNCg0KICAgIEV2ZW50IGV4 dGVuc2lvbiBtZWNoYW5pc21zIGNhbiBiZSBkZWZpbmVkIGludGVybmFsIHRvIHRoZSBldmVudA0K ICAgIG9iamVjdC4gQSBzaW1wbGUgYXBwcm9hY2ggd291bGQgYmUgdG8gIGRlZmluZSBhbiDigJxl eHRlbnNpb25z4oCdIG1lbWJlcg0KICAgIHRoYXQgaXMgYSBsaXN0IG9mIGV2ZW50IG9iamVjdHMg KG9yIHNldCByZXNlbWJsaW5nIHRoZSDigJxldmVudHPigJ0NCiAgICBjbGFpbSBhcyBkZWZpbmVk IGluIHRoZSBjdXJyZW50IHNwZWMpLiBUaGlzIGhhcyB0aGUgYWR2YW50YWdlIG9mDQogICAgbWFr aW5nIGl0IGNsZWFyIGluIHRoZSBkYXRhIHN0cnVjdHVyZSB0aGF0IHRoZXJlIGlzIGEgc2luZ2xl IHByaW1hcnkNCiAgICBldmVudCwgd2l0aCB6ZXJvIG9yIG1vcmUgZXh0ZW5zaW9ucy4gVGhlcmUg aXMgbm8gcm9vbSBmb3IgY29uZnVzaW9uDQogICAgb3ZlciB3aGljaCBldmVudCBpcyBwcmltYXJ5 LCBvciBpZiB0aGVyZSBpcyBhIHByaW1hcnkgZXZlbnQgYXQgYWxsLg0KICAgIEkgd291bGQgYmUg ZmluZSB3aXRoIGFkZGluZyBzb21ldGhpbmcgbGlrZSB0aGlzIHRvIG15IHByb3Bvc2VkIHRleHQs DQogICAgaWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRoYXQgaXQgaXMgYnJvYWRseSB1c2VmdWwuDQoN CiAgICAqQWxpYXNlcyoNCg0KICAgIFRoaXMgdXNlIGNhc2Ugd2FzIGJyb3VnaHQgdXAgaW4gdGhl IGNvbnRleHQgb2YgbWlncmF0aW5nIGNsaWVudHMNCiAgICBmcm9tIGRyYWZ0IGV2ZW50IG5hbWVz IHRvIHN0YW5kYXJkaXplZCBldmVudCBuYW1lcy4gSW4gdGhpcyBjYXNlLA0KICAgIHRoZSBldmVu dCB0cmFuc21pdHRlciBjYW4gdHJhbnNtaXQgdHdvIHRva2VucyBmb3IgdGhlIGxvZ2ljYWwgZXZl bnQsDQogICAgb25lIHVzaW5nIHRoZSBvbGQgbmFtZSBhbmQgYW5vdGhlciB1c2luZyB0aGUgbmV3 IG5hbWUuDQoNCiAgICAqUmVsYXRlZCBFdmVudHMqDQoNCiAgICBUaGUgU0VUIHNwZWMgZGVmaW5l cyB0aGUgdHhuIGNsYWltIGFzIGEgbWVhbnMgb2YgY29ycmVsYXRpbmcNCiAgICBpbmRlcGVuZGVu dCB0b2tlbnMgdGhhdCByZWxhdGUgdG8gdGhlIHNhbWUgbG9naWNhbCBldmVudC4NCg0KICAgIC0t DQogICAgQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KDQogICAgQW1hem9uIOKAkyBJZGVudGl0 eSBTZXJ2aWNlcw0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCiAgICBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICBJZC1ldmVudEBpZXRmLm9y ZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8bWFp bHRvOklkLWV2ZW50QGlldGYub3JnPj4NCiAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lk LTJEZXZlbnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1 N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPXM1 YnlCZTVLQU5uR1Z1QWIxbUF1cEVHb0puOFhHNUpJVVV3V0dGU2liRWMmcz1YOG9SU3EzSXpsRjdq aVJBZVpoWHBSM2VWSTBJNThaRmQ0ZUVaZmd5b0lZJmU9DQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJ ZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9faWQtMkRldmVudCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1V QjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5B Jm09WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZzPVdyTXVRUndM VjgwMmlNUTR3WUIxZjJyRlVHdTR6YmhjVzAwMWZLMDJFWHMmZT0+DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QN CklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19pZC0yRGV2ZW50JmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUly TVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEta TkEmbT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JnM9V3JNdVFS d0xWODAyaU1RNHdZQjFmMnJGVUd1NHpiaGNXMDAxZkswMkVYcyZlPT4NCg0KDQoNCi0tDQpTdWJz Y3JpYmUgdG8gdGhlIEhBUkRUV0FSRTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQ cHVZcVBrQUkxYUxjTE40S1pOQSZtPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FU a1JsUUcxaXcmcz1MWU43MkdnS1ZoSHNUNnRBcUJlLWVNb1dNdnlfN2RmRm4xdVowSEs2WXVRJmU9 PiBtYWlsIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1h aWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0K aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBj dHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWli OUtBVGtSbFFHMWl3JnM9V3JNdVFSd0xWODAyaU1RNHdZQjFmMnJGVUd1NHpiaGNXMDAxZkswMkVY cyZlPQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K SWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRA aWV0Zi5vcmc+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lDQWcm Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRX bWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPVUtYTVIQk5EMEhhVFg0YW5OWmZ6 WDdwRHNmSzVmMGg5bVo5Q1pra0dpZWMmcz1ydmRydEk3cllOUkFucVpEbHRDd0JBWlZIS3AtTUoy MHVpMm5tNDZRU3owJmU9DQoNCg0KDQoNCi0tDQpTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRTxo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3 YXJlLmNvbV8mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVh cElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPWl5 Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmcz13dGdEM05wMHZ5aExk cEV3VWlxc2Y0SXRpd0EzT203R3JvYjcwTHgwcjNrJmU9PiBtYWlsIGxpc3QgdG8gbGVhcm4gYWJv dXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0 Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5m b19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVC NjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEm bT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JnM9T2UwcWZMRVg4 M3Z0WE03V2wyY1lCZS1HZzFEVlBqaFhqVkprZmhWUnp3YyZlPQ0KDQoNCg0KLS0NClN1YnNjcmli ZSB0byB0aGUgSEFSRFRXQVJFPGh0dHA6Ly9oYXJkdHdhcmUuY29tLz4gbWFpbCBsaXN0IHRvIGxl YXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCg0KDQoNCi0tDQpTdWJzY3JpYmUg dG8gdGhlIEhBUkRUV0FSRTxodHRwOi8vaGFyZHR3YXJlLmNvbS8+IG1haWwgbGlzdCB0byBsZWFy biBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hDQoNCg0KDQotLQ0KU3Vic2NyaWJlIHRv IHRoZSBIQVJEVFdBUkU8aHR0cDovL2hhcmR0d2FyZS5jb20vPiBtYWlsIGxpc3QgdG8gbGVhcm4g YWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0K --_000_6DF29D13F11E4140BB39A88A4FD0B335amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCXBh bm9zZS0xOjIgNyAzIDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi Q2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEg NiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNh bnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLm0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMw MW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQt c3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6bV8tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2 MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1j b252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2 MDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1p ZDo0NjUwMDY0NjE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDMzNzkyNDMyO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6 ODY0MTc3NTIzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczozOTg2Mzc5NTI7fQ0KQGxpc3QgbDE6 bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDozOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTAyNDA5NjQ2MzsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTU0MzExNTgzNjt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxMTgyODE3NzU5Ow0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyNTM5Mzk1NTQg Njc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2 OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDQNCgl7bXNv LWxpc3QtaWQ6MTI3Mjg1ODQxOTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTU4MzI1OTY1MDt9 DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNDps ZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21z by1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0OmxldmVsNA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsNDpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0 OmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC10 YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGw1DQoJe21zby1saXN0LWlkOjE3ODgyMzkyNTA7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi0zMzc4OTg3MzI7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJe21zby1s ZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDU6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDU6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw1OmxldmVsNg0K CXttc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDU6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDo0 LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsNg0KCXttc28tbGlzdC1pZDoyMDEwMjgxMDg3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoz MDU0NDU2MjI7fQ0KQGxpc3QgbDY6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1z by1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDY6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlVubGVzcyB0aGUgcHJvZmlsZSBndWFyYW50ZWVzIHRoYXQgc3VjaCByZWxh dGVkIGV2ZW50cyB3aWxsIGFsd2F5cyBiZSBpbmNsdWRlZCBpbiB0aGUgc2FtZSBTRVQsIHRoZW4g dGhlIHJlY2VpdmVyIGhhcyB0byBjb3JyZWxhdGUgYWNyb3NzIFNFVHMgYW55d2F5LCBhbmQgbXVs dGlwbGUgZXZlbnRzIHBlciBTRVQgaXMganVzdCBnaXZpbmcgdGhlIHJlY2VpdmVyIGFub3RoZXIg c2NlbmFyaW8gdGhhdCB0aGV5IGhhdmUNCiB0byBzdXBwb3J0LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5J4oCZdmUgYWxyZWFkeSBwcm92aWRlZCBzZXZlcmFsIG90aGVyIHJlYXNvbnMgd2h5IHdl IHNob3VsZCBub3Qgc3VwcG9ydCBtdWx0aXBsZSB0b2tlbnMgcGVyIFNFVCB0aGF0IG5vIG9uZSBo YXMgYWRkcmVzc2VkLiBIZXJlIHRoZXkgYXJlIGFnYWluOjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwzIGxldmVsMSBs Zm8xMCI+TXVsdGlwbGUgZXZlbnQgc3VwcG9ydCByZXN1bHRzIGluIGEgbW9yZSBjb21wbGV4IHN0 cnVjdHVyZSBmb3IgdGhlIHNpbmdsZSBldmVudCB1c2UgY2FzZSwgd2hpY2ggSSB0aGluayB3ZSBh bGwgYWdyZWUgaXMgdGhlIG1ham9yaXR5IHVzZSBjYXNlLjxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDMg bGV2ZWwxIGxmbzEwIj5NdWx0aXBsZS1ldmVudCBTRVRzIGhhdmUgYW1iaWd1b3VzIHNlbWFudGlj cy4gVGhlIHByZXNlbmNlIG9mIHR3byBldmVudHMgQSBhbmQgQiBpbiB0aGUgc2FtZSBTRVQgY291 bGQgbWVhbiBhbnkgb2Y6PG86cD48L286cD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0 YXJ0PSIxIiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMyBsZXZlbDIgbGZvMTAiPkEgYW5kIEIgYXJlIHJlbGF0 ZWQgdG8gdGhlIHNhbWUgbG9naWNhbCBldmVudCAoaS5lLiB0aGUgc2FtZSB0aGluZyBhcyBpZiB0 aGV5IHdlcmUgZnJvbSBkaWZmZXJlbnQgU0VUcyB0aGF0IGhhdmUgYSBjb21tb24gdHhuKS48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGluO21zby1saXN0OmwzIGxldmVsMiBsZm8xMCI+QSBpcyBhbiBleHRlbnNpb24gb2YgQi48 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MGluO21zby1saXN0OmwzIGxldmVsMiBsZm8xMCI+QiBpcyBhbiBleHRlbnNpb24gb2Yg QS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwzIGxldmVsMiBsZm8xMCI+QSBpcyBhbiBhbGlhcyBmb3Ig Qiwgb3IgdmljZS12ZXJzYS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwzIGxldmVsMiBsZm8xMCI+QSBh bmQgQiBhcmUgbm90IGFjdHVhbGx5IHJlbGF0ZWQgdG8gb25lIGFub3RoZXIgaW4gYW55IHdheSwg YW5kIHRoZSB0cmFuc21pdHRlciBidW5kbGVkIHRoZW0gdG9nZXRoZXIgYmVjYXVzZSB0aGV5IHdl cmUgZ29pbmcgdG8gdGhlIHNhbWUgcmVjZWl2ZXIuPG86cD48L286cD48L2xpPjwvb2w+DQo8L2xp PjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28t bGlzdDpsMyBsZXZlbDEgbGZvMTAiPlRvcC1sZXZlbCBjbGFpbSBzZW1hbnRpY3MgYmVjb21lIGhh cmRlciB0byBkZWZpbmUsIGFzIGRpZmZlcmVudCBwcm9maWxlcyBtYXkgd2FudCB0byB1c2UgdGhl IHNhbWUgY2xhaW1zIGluIGRpZmZlcmVudCB3YXlzLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDMgbGV2 ZWwxIGxmbzEwIj5FdmVudCBhdXRoZW50aWNpdHkgY2Fubm90IGJlIHZlcmlmaWVkIHdpdGhvdXQg aGF2aW5nIHRoZSBlbnRpcmUgU0VULiBUaGlzIGZvcmNlcyByZWNlaXZlcnMgdG8gZXhwb3NlIGRv d25zdHJlYW0gc3lzdGVtcyB0byBtb3JlIGluZm9ybWF0aW9uIG5lY2Vzc2FyeSwgaWYgdGhvc2Ug c3lzdGVtcyBuZWVkIHRvIGJlDQogYWJsZSB0byB2ZXJpZnkgYXV0aGVudGljaXR5LjxvOnA+PC9v OnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW1hem9uIOKAkyBJZGVu dGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5G cm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5NaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+ RGF0ZTogPC9iPldlZG5lc2RheSwgTm92ZW1iZXIgMSwgMjAxNyBhdCAxMToyMSBBTTxicj4NCjxi PlRvOiA8L2I+RGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+ Q2M6IDwvYj5ZYXJvbiBTaGVmZmVyICZsdDt5YXJvbmYuaWV0ZkBnbWFpbC5jb20mZ3Q7LCAmcXVv dDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmFAYW1hem9uLmNv bSZndDssIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0O2lkLWV2ZW50QGlldGYub3JnJmd0Oywg JnF1b3Q7UGhpbCBIdW50IChJRE0pJnF1b3Q7ICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8 YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBs ZSBldmVudHMgcGVyIFNFVD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgY29tcGxldGVseSBh Z3JlZSBvbiBtb3ZpbmcgY29tcGxleGl0eSB0byB0aGUgaXNzdWVyIG92ZXIgdGhlIHJlY2lwaWVu dC4mbmJzcDsgSW4gbXkgdmlldywgaXTigJlzIG1vcmUgY29tcGxleCBmb3IgcmVjaXBpZW50cyB0 byBoYXZlIHRvIGNvcnJlbGF0ZSBhbmQgcHJvY2VzcyBhIHNlcXVlbmNlIG9mIG11bHRpcGxlIFNF VHMgcHJvdmlkaW5nIGluZm9ybWF0aW9uIGFib3V0DQogdGhlIHNhbWUgbG9naWNhbCBldmVudCwg YW5kIHZhbGlkYXRlIE4gc2lnbmF0dXJlcywgdGhhbiB0byByZWNlaXZlIG9uZSBTRVQgd2l0aCBh bGwgdGhlIGFzcGVjdHMgb2YgdGhlIGxvZ2ljYWwgZXZlbnQgYXMg4oCcZXZlbnRz4oCdIGZpZWxk cywgd2l0aCBubyBjb3JyZWxhdGlvbiBvdmVyIHRpbWUgdGhlbiByZXF1aXJlZC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkZyb206PC9iPiBEaWNrIEhhcmR0IFttYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb21dIDxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDEsIDIwMTcgOTozOSBBTTxicj4N CjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0 Ozxicj4NCjxiPkNjOjwvYj4gWWFyb24gU2hlZmZlciAmbHQ7eWFyb25mLmlldGZAZ21haWwuY29t Jmd0OzsgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20m Z3Q7OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDtpZC1ldmVudEBpZXRmLm9yZyZndDs7IFBo aWwgSHVudCAoSURNKSAmbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBT RVQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91ciBjb21tZW50cyBo aWdobGlnaHQgYSBjb3VwbGUgb2YgcG9pbnRzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xKSBUaGUgZXhhbXBsZSBpcyBob3cgdG8gaGF2ZSBh IHByZWRlZmluZWQgZXh0ZW5zaW9uIHBvaW50IGZvciBleHRlbnNpb25zIG9mIGEgc3BlY2lmaWMg ZXZlbnQsIGl0IGlzIG5vdCBob3cgdG8gYWRkIGFub3RoZXIgZXZlbnQuIE15c2VsZiwgSSB0aGlu ayB0aGlzIGlzIG92ZXJseSBjb21wbGljYXRlZC4gRXZlbnRzIHNob3VsZCBiZSBjb21wYXJhdGl2 ZWx5IHN0YXRpYywgYW5kIGFzIHdpdGggbWFueSBvdGhlcg0KIEpTT04gZm9ybWF0cywgdGhlIHJl Y2VpdmVyIHNob3VsZCBpZ25vcmUgcHJvcGVydGllcyBpdCBkb2VzIG5vdCB1bmRlcnN0YW5kLCB3 aGljaCBsZXQncyBuZXcgcHJvcGVydGllcyBiZSBpbnRyb2R1Y2VkIGFzIGV4dGVuc2lvbnMuIFRo ZXJlIHNob3VsZCBub3QgYmUgYW55IGNvbmZsaWN0IGFzIGV4dGVuc2lvbnMgc2hvdWxkIG9ubHkg YmUgZG9uZSBieSB0aGUgcHJvZmlsZSB0aGF0IGNyZWF0ZWQgdGhlIGV2ZW50IGZvcm1hdCB0byBz dGFydCBvZmYNCiB3aXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4yKSBIYXZpbmcgYW4gbHZhbHVlIGJlIGEgVVJJIGlzIG11Y2ggaGFyZGVy IHRvIGNvZGUgYWdhaW5zdC4gSSdtIG5vdCBzdXJlIHdoeSBNYXJpdXMgaGFkIHRoYXQgaW4gaGlz IGV4YW1wbGUuIFBlciB0aGUgZXZlbnQsIHRoZSB0eXBlIG9mIHRoZSBldmVudCBpcyB3ZWxsIGRl ZmluZWQgd2l0aCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM1MDAwNTAiPiZxdW90O2V2ZW50X3R5 cGUmcXVvdDs6ICZxdW90Ozwvc3Bhbj48YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL3NjaW0v ZXZlbnQvcGFzc3dvcmRSZXNldEV4dCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPmh0 dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0PC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LHNlcmlmO2NvbG9yOiM1MDAwNTAiPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zKSBUaGlzIHRo cmVhZCBpcyBhYm91dCByZWFzb25zIGZvciBtdWx0aXBsZSBldmVudHMgdG8gYmUgY29udGFpbmVk IGluIG9uZSBzZXQuIFlvdXIgbWVudGlvbiBvZiBhbiBpc3N1ZXIgbm90IHdhbnRpbmcgdG8gc2ln biBzZXBhcmF0ZSBldmVudHMgYXMgYSByZWFzb24gdG8gYWxsb3cgbXVsdGlwbGUgZXZlbnRzLiBJ IHRoaW5rIHdlIGhhdmUgZGVjaWRlZCB0aGF0IGdpdmVuIGEgcHJlZmVyZW5jZSwgd2Ugd2lsbA0K IHB1c2ggZWZmb3J0IHRvIHRoZSB0cmFuc21pdHRlciBvdmVyIHRoZSByZWNlaXZlciBhcyBpbiBt YW55IHVzZSBjYXNlcyB0aGVyZSBhcmUgbWFueSBtb3JlIHJlY2VpdmVycy4gR2l2ZW4gdGhhdCwg aXQgaXMgbW9yZSBjb21wbGV4IGZvciBhIHJlY2VpdmVyIHRvIGhhdmUgZGlmZmVyZW50IHdheXMg b2YgbWFuYWdpbmcgdGhlIHJlY2VpcHQgb2YgbXVsdGlwbGUgZXZlbnRzIGFzIG5vdCBhbGwgaXNz dWVycyB3aWxsIGJ1bmRsZSB0aGUgZXZlbnRzLA0KIHNvIGl0IGlzIHNpbXBsZXIgdG8gaGF2ZSBv bmx5IG9uZSBldmVudCBwZXIgU0VULiBJbmNsdWRpbmcgdGhlIHNlcGFyYXRlIGV2ZW50cyB3aXRo IGEgVVJJIGFzIGFuIGx2YWx1ZSBpcyBjaGFsbGVuZ2luZyB0byBpbXBsZW1lbnQsIHNwZWFraW5n IGZyb20gZXhwZXJpZW5jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBPY3QgMzEsIDIwMTcgYXQgMTE6 MDUgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5NYXJpdXPigJkgcHJvcG9zZWQgc3ludGF4LCBw YXN0ZWQgaW4gYmVsb3csIGhhcyBleGFjdGx5IHRoaXMgY2hhcmFjdGVyaXN0aWMuJm5ic3A7IFRo ZSB3YXkgSSBzZWUgaXQsIGhpcyBwcm9wb3NhbCBlc3NlbnRpYWxseSBoYXMgYSBwcmltYXJ5IHBh c3N3b3JkUmVzZXQgZXZlbnQNCiBhbmQgYSBzZWNvbmRhcnkgcGFzc3dvcmRSZXNldEV4dCBkYXRh IHN0cnVjdHVyZSwgd2hpY2ggY291bGQgaGF2ZSBiZWVuIHNpbXBseSBhbm90aGVyIGV2ZW50IHZh bHVlIGluIHRoZSBjdXJyZW50IGRyYWZ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPlRoaXMgYnJlYWtpbmcgY2hhbmdlIG1ha2VzIHRoZSBkYXRhIHN0cnVjdHVyZXMg bW9yZSBjb21wbGljYXRlZCAtIG5vdCBsZXNzLiZuYnNwOyBBbmQgaXQgbWFrZXMgdGhpbmdzIHRo YXQgdXNlZCB0byBiZSBwb3NzaWJsZSBpbXBvc3NpYmxlLCByZWR1Y2luZyBmbGV4aWJpbGl0eQ0K IHRvIHRob3NlIHdobyB3b3VsZCB1c2UgdGhlIHNwZWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+VGhlc2Ugc2VlbSBsaWtlIGJhZCB0cmFkZW9mZnMgdG8gbWUuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj57PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7anRpJnF1b3Q7OiAm cXVvdDszZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90Oyw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAm cXVvdDtpYXQmcXVvdDs6IDE0NTg0OTYwMjUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7OiAm cXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmcXVvdDthdWQm cXVvdDs6IFs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4 YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1 NDwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1 Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2 NzZlZTc8L2E+JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7XSw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsmcXVv dDtldmVudF90eXBlJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL3Nj aW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZXhhbXBs ZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAm bmJzcDsmcXVvdDtldmVudCZxdW90OzogeyZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O2lkJnF1b3Q7OiZxdW90OzQ0ZjYxNDJkZjk2YmQ2YWI2 MWU3NTIxZDkmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1 b3Q7ZXh0ZW5zaW9ucyZxdW90Ozogezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmcXVvdDs8YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQv cGFzc3dvcmRSZXNldEV4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZXhhbXBsZS5jb20vc2Np bS9ldmVudC9wYXNzd29yZFJlc2V0RXh0PC9hPuKAnToNCiB7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtyZXNldEF0dGVtcHRzJnF1b3Q7 OjUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LHNlcmlmIj59PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ SW4gcGFydGljdWxhciwgaXQgbWFrZXMgaXQgaW1wb3NzaWJsZSB0byBzaWduIG11bHRpcGxlIHJl bGF0ZWQgZXZlbnRzIHNoYXJpbmcgYSBjb21tb24gY2xhaW1zIHNjaGVtYSB3aXRoIGEgc2luZ2xl IHNpZ25hdHVyZSBieSB0aGUgaXNzdWVyLiZuYnNwOyBJdCBmb3JjZXMNCiB0aGUgaXNzdWVyIHRv IGRvIHRoZSBleHRyYSB3b3JrIG9mIHNpZ25pbmcgZWFjaCBvZiB0aGUgcmVsYXRlZCBldmVudHMg KG9yIGZhY2V0cyBvZiB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50KSBpbmRpdmlkdWFsbHkgYW5kIGZv cmNlcyB0aGUgcmVjaXBpZW50cyB0byBkbyB0aGUgZXh0cmEgd29yayBvZiBjaGVja2luZyBhbGwg dGhvc2UgdW5uZWNlc3Nhcnkgc2lnbmF0dXJlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj5Ob3QgZXZlcnkgcHJvZmlsZSB3aWxsIGV2ZXIgaGF2ZSBtdWx0aXBsZSBr ZXlzIGluIHRoZSDigJxldmVudHPigJ0gc2V0IGJ1dCB0aGVyZeKAmXMgYWJzb2x1dGVseSBubyBy ZWFzb24gdG8gcHJlY2x1ZGUgaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fLTQz Nzc3ODc3NTU4NzMyMDg5MzVfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+RnJvbTo8L2I+IElkLWV2ZW50IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmlkLWV2 ZW50LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudC1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGljayBIYXJkdDxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDMxLCAyMDE3IDk6NTIgUE08YnI+DQo8Yj5Ubzo8L2I+IE1p a2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20i IHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4N CjxiPkNjOjwvYj4gWWFyb24gU2hlZmZlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRm QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7 OyBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5h QGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDs7 IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDs7DQogUGhpbCBI dW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlBsZWFzZSBkaXJlY3QgbWUgdG8gYSBwcm9wb3NhbCB0aGF0IGhhcyBhICZxdW90O3ByaW1h cnkmcXVvdDsgYW5kICZxdW90O3NlY29uZGFyeSZxdW90OyBldmVudHMuIEkgYWdyZWUgdGhhdCBp cyB1bmRlc2lyYWJsZS4gSSB3b3VsZCBhbHNvIGVuY291cmFnZSB0byBlbmdhZ2UgaW4gdGhlIGRp c2N1c3Npb25zIHNvIHRoYXQgd2UgY2FuIGRyaXZlDQogY2xhcml0eSBhbmQgc2ltcGxpY2l0eS48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRoaW5r IHRoZSBwcm9wb3NhbCBpcyB0aGF0IHRoZXJlIGlzIG9uZSBldmVudCBwZXIgU0VULjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGlu ayBoYXZpbmcgbW9yZSB0aGFuIG9uZSBldmVudCBwZXIgU0VUIGFkZHMgY29tcGxleGl0eSBhcyBh IHJlY2VpdmVyIG11c3QgZGVhbCB3aXRoIHJlY2VpdmluZyBjb3JyZWxhdGVkIGV2ZW50cyBpbiBv bmUgU0VUIGFzIHdlbGwgYXMgY29ycmVsYXRlZCBldmVudHMgaW4gdGhlIHNhbWUgU0VULjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+L0Rp Y2s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIFR1ZSwgT2N0IDMxLCAyMDE3IGF0IDk6NDIgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhy ZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5N aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij5JIGhlYXIgeW91IG9uIHRoZSBmYWN0IHRoYXQgZGlmZmVyZW50IHBlb3BsZSBoYXZlIGpvaW5l ZCB0aGUgZWZmb3J0IGF0IGRpZmZlcmVudCB0aW1lcy4mbmJzcDsgVGhhdOKAmXMgYSBub3JtYWwg cHJvY2VzcyBhcyBhbiBlZmZvcnQgYnVpbGRzIG1vbWVudHVtLiZuYnNwOyBJIGdldA0KIHRoYXQg bm90IGV2ZXJ5b25lIHdhcyB0aGVyZSB3aGVuIHByZXZpb3VzIGNvbnNlbnN1cyBjYWxscyB3ZXJl IHRha2VuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgc2hvdWxk IG5vdGUgdGhhdCBJIGhhdmUgc3BlY2lmaWMgdGVjaG5pY2FsIG9iamVjdGlvbnMgdG8gdGhlIHNw ZWNpZmljIHByb3Bvc2VkIGNoYW5nZXMgYmVpbmcgZGlzY3Vzc2VkIGFzIHdlbGwuJm5ic3A7IEN1 cnJlbnRseSBhbGwgZXZlbnRzIGluIHRoZSBzZXQgaGF2ZQ0KIHRoZSBzYW1lIHN5bnRheC4mbmJz cDsgVGhlIHByb3Bvc2FscywgYXMgSSB1bmRlcnN0YW5kIHRoZW0sIHJldmVydCB1cyB0byBhIHN0 YXRlIHdoZXJlIHRoZXJl4oCZcyBhIOKAnHByaW1hcnnigJ0gYW5kIOKAnHNlY29uZGFyeeKAnSBl dmVudHMsIHdpdGggZGlmZmVyZW50IHN5bnRheCBmb3IgdGhlIHR3byBjbGFzc2VzLiZuYnNwOyBU aGF04oCZcyBuZWVkbGVzc2x5IG1vcmUgY29tcGxpY2F0ZWQsIGFkZGluZyBubyBhY3R1YWwgdmFs dWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9i PiBEaWNrIEhhcmR0IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMzEsIDIwMTcgOTozNyBQTTxicj4NCjxiPlRvOjwvYj4g TWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZn dDs7IFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OzsgUmljaGFy ZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24u Y29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7Ow0KIElEIEV2 ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5NaWtlPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+QXMgeW91IHdlbGwga25vdywgbWFueSBwZW9wbGUgaW4gYSBXRyBkb24ndCBsb29rIGNs b3NlbHkgYXQgYSBzcGVjaWZpY2F0aW9uIHVudGlsIGxhc3QgY2FsbCBpcyBtYWRlLiBBZGRpdGlv bmFsbHksIHdlIGFyZSBjb21pbmcgdXAgb24gb25seSB0aGUgM3JkIFdHIG1lZXRpbmcuIFRoZSBX RyBoYXMgbm90IGV4aXN0ZWQNCiBmb3IgdmVyeSBsb25nLiBXaGlsZSBzb21lIG9mIHRoZSBwYXJ0 aWNpcGFudHMgaGF2ZSBiZWVuIHdvcmtpbmcgb24gdGhpcyBmb3IgYSB3aGlsZSwgbWFueSBoYXZl IG5vdCwgYW5kIHdlIGFyZSBsb29raW5nIGZvciBjb25zZW5zdXMgYWNyb3NzIHRoZSBXRy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNp bmNlIFNlY0V2ZW50IGlzIGEgZnJhbWV3b3JrIHRoYXQgd2UgZXhwZWN0IHRvIGJlIHByb2ZpbGVk LCBJIGZlZWwgaXQgaXMgaW1wb3J0YW50IHRvIGVuc3VyZSB0aGF0IFNlY0V2ZW50IHNwZWNpZmlj YXRpb25zIGFyZSBlYXN5IGZvciBhIHZhcmlldHkgb2YgcHJvZmlsZXMgdG8gYWRvcHQsIGFuZCB0 aGF0DQogdGhlIHNlbWFudGljcyBtYWtlIHNlbnNlLiBJIGFsc28gdGhpbmsgdGhhdCBwcm9wZXJ0 aWVzIHRoYXQgYXJlIHNwZWNpZmljIHRvIGEgcHJvZmlsZSBzaG91bGQgYmUgbGVmdCB0byB0aGF0 IHByb2ZpbGUgYW5kIG5vdCBiZSBpbmNsdWRlZCBpbiBTZWNFdmVudC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNpbmNlIHRoaXMgaXMg YSBmcmFtZXdvcmssIGl0IGlzIGV4cGVjdGVkIHRoYXQgYXMgZGlmZmVyZW50IGdyb3VwcyBwcm9m aWxlIGl0LCB0aGVyZSB3aWxsIGJlIGFkZGl0aW9uYWwgZmVlZGJhY2suPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TcGVjaWZpY2FsbHks IGFzIGEgcGFydGljaXBhbnQgaW4gdGhlIFJJU0MgcHJvZmlsZSBvZiBTRVQsIGEgbnVtYmVyIG9m IGlzc3VlcyBpbiBTRVQgaGF2ZSBzdXJmYWNlZCBhcyB0aGUgUklTQyBXRyBoYXMgbG9va2VkIGF0 IGhvdyB0byB1c2UgdGhlIFNFVC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIGZvciBTRVQgYmVpbmcgc3RhYmxlIGZvciBvdmVyIGEg eWVhciwgdGhlcmUgaGF2ZSBiZWVuIGEgbnVtYmVyIG9mIGNoYW5nZXMgdG8gU0VUIHNpbmNlIHRo ZW4uIEkgYWxzbyBkb24ndCB0aGluayB0aGVyZSB3YXMgY29uc2Vuc3VzLiBCZWZvcmUgdGhlIFdH IHdhcyBmb3JtZWQsIEkgYW5kIHNldmVyYWwgb3RoZXJzDQogaGFkIGV4cHJlc3NlZCBjb25jZXJu IG9uIHRoZSBkZXNpZ24gb2YgU0VUIHdoZW4gUGhpbCBwcmVzZW50ZWQgaXQgYXQgYW4gSUlXIHNl c3Npb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5BcyB0byB0YWtpbmcgYW5vdGhlciB5ZWFyLCBJIGFtIGhvcGVmdWwgd2UgY2FuIHJl c29sdmUgdGhlIHJlbWFpbmluZyBpc3N1ZXMgaW4gU0VUIGFuZCBwdWJsaXNoIGEgbmV3IGRyYWZ0 IGZvciBsYXN0IGNhbGwuIEkgZG8gbm90IHRoaW5rIHdlIHdpbGwgbmVlZCB0byB3YWl0IGZvciBh bm90aGVyIFdHIG1lZXRpbmcNCiB0byBhc2sgZm9yIGxhc3QgY2FsbC4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIGFsc28g aGF2ZSBhIG51bWJlciBvZiBvdGhlciBkb2N1bWVudHMgdGhhdCBhcmUgbm90IGluIGxhc3QgY2Fs bCwgYW5kIHdlIGRvbid0IGhhdmUgYSBXRyBhZG9wdGVkIGRyYWZ0IHlldCBmb3IgbWFuYWdlbWVu dC4gU28gdGhlcmUgYXJlIHN0aWxsIGEgbnVtYmVyIG9mIGRvY3VtZW50cyB0byB3b3JrIHRocm91 Z2gNCiBiZWZvcmUgd2UgaGF2ZSBhbGwgdGhlIGJpdHMgZm9yIHNvbWVvbmUgdG8gd29yayB3aXRo LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SSBkbyB0aGluayB3ZSBoYXZlIGJlZW4gbWFraW5nIGdvb2QgcHJvZ3Jlc3Mgc2luY2UgdGhl IGxhc3QgSUVURiBtZWV0aW5nLCBhbmQgSSBhbSBob3BlZnVsIHdlIGNhbiBrZWVwIHVwIHRoaXMg bW9tZW50dW0gYW5kIGZpbmFsaXplIGFsbCB0aGUgZG9jdW1lbnRzIGluIGEgdGltZWx5IG1hbm5l ci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPi9EaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+T24gVHVlLCBPY3QgMzEsIDIwMTcgYXQgMTI6NDggUE0sIE1pa2UgSm9u ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdl dD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj5JdOKAmXMgaGFyZCBmb3IgbWUgdG8gZXZlbiBleHByZXNzIG15IGxldmVs IG9mIGZydXN0cmF0aW9uIHdpdGggdGhlIHJlY2VudCBhdHRlbXB0cyB0byBvbmNlIGFnYWluIHJl ZGVzaWduIHRoZSBTZWNFdmVudCBUb2tlbiBzcGVjLiZuYnNwOyBXZeKAmXZlIGJlZW4gYXQgdGhp cw0KIGZvciBtdWx0aXBsZSB5ZWFycyBiZWNhdXNlIHBlb3BsZSBrZWVwIHRyeWluZyB0byByZXZp c2l0IGRlY2lzaW9ucyB0aGF0IHdlcmUgbG9uZyBhZ28gbWFkZSBieSBjb25zZW5zdXMuJm5ic3A7 IEl04oCZcyBiZWVuIHN0YWJsZSBmb3Igb3ZlciBhIHllYXIgYW5kIHRoZSBtYWpvcml0eSBvZiBX R0xDIHJlc3BvbmRlbnRzIHNhaWQgc29tZSB2YXJpYW50IG9mIOKAnFdvcmtzIGZvciBtZSDigJMg c2hpcCBpdCHigJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGVy ZeKAmXMgbm90IHN1ZmZpY2llbnQganVzdGlmaWNhdGlvbiB0byB0cnkgdG8gdW5kbyBjb25zZW5z dXMgcG9zaXRpb25zIHRoYXQgaGF2ZSBiZWVuIGRlYmF0ZWQgYW5kIGFmZmlybWVkIG92ZXIgYW5k IG92ZXIuJm5ic3A7IENvdW50ZW5hbmNpbmcgd2hvbGVzYWxlIGNoYW5nZXMNCiBhdCB0aGlzIGxh dGUgZGF0ZSBpcyBjb3VudGVycHJvZHVjdGl2ZSBpbiB0aGUgZXh0cmVtZSE8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JdOKAmXMgZmFyIGJldHRlciB0aGFuIGdvb2Qg ZW5vdWdoIGFzLWlzLiZuYnNwOyBJbiBteSBleHBlcmllbmNlLCBpZiB3ZSBzdGFydCByZWRlc2ln bmluZyBpdCwgaXQgd2lsbCByZXN1bHQgaW4gYW5vdGhlciB5ZWFy4oCZcyBkZWxheS4mbmJzcDsg SXQgZG9lcyBzb21ldGhpbmcgc2ltcGxlDQogYW5kIHVzZWZ1bC4mbmJzcDsgUGxlYXNlLCBsZXTi gJlzIGp1c3Qgc2hpcCBpdCwgc28gcGVvcGxlIGNhbiByZWx5IG9uIGl0Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48YSBuYW1lPSJtXy00Mzc3Nzg3NzU1ODczMjA4OTM1X21fLTUwMTM4NTQ4NjE0MTAy Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPkZyb206PC9iPiBQaGlsIEh1bnQgKElETSkgW21haWx0bzo8YSBocmVmPSJtYWls dG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xl LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDMwLCAyMDE3IDI6 NDIgUE08YnI+DQo8Yj5Ubzo8L2I+IERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9h PiZndDs8YnI+DQo8Yj5DYzo8L2I+IFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5 YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj55YXJvbmYuaWV0ZkBnbWFpbC5j b208L2E+Jmd0OzsgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0 bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNv bTwvYT4mZ3Q7OyBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PC9hPiZndDs7DQogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlk LWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0 OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxl IGV2ZW50cyBwZXIgU0VUPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbmxpbmUuLi48YnI+DQo8 YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCk9uIE9jdCAzMCwgMjAxNywgYXQgMjoyMiBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJk dEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgUGhpbDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvcnJlY3QgbWUgaWYgSSBhbSBtaXN1 bmRlcnN0YW5kaW5nLCBidXQgdGhlcmUgaXMgYSBSSVNDIHByb2ZpbGUgZXZlbnQmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13 cmFwIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJl LXdyYXAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij4mcXVvdDs8YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5v cGVuaWQubmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlXy0yNTVDJmFtcDtkPUR3TUZhUSZh bXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5h NUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209aXlWbnJabXI5 X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZhbXA7cz0yNWwwOXNIOFlWNDJ4emdV LUNYU2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlLzwvYT48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5hY2NvdW50LWNyZWRlbnRpYWwtY2hhbmdlLXJlcXVpcmVkPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0id2hp dGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmFuZCBhbiBTQ0lNIHByb2ZpbGUgZXZlbnQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUt d3JhcCI+JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3 b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZl bnQvcGFzc3dvcmRSZXNldEV4dDwvYT7igJ08bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i d2hpdGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkknbSBzdWdnZXN0aW5nIHRoYXQgdHdvIGRpZmZl cmVudCBldmVudHMgd291bGQgYmUgc2VudC4gRW1iZWRkaW5nIG9uZSBpbiB0aGUgb3RoZXIgZG9l cyBub3QgbWFrZSBzZW5zZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmx0O3BoJmd0O0l0IGlzIGEg aHlwb3RoZXRpY2FsIGV4YW1wbGUuIEp1c3QgYmVjYXVzZSB5b3UgZGlzYWdyZWUgb24gdGhpcyBk b2VzIG5vdCBtZWFuIG90aGVycyBhcmUgbm90IHZhbGlkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkganVzdCBwaWNrZWQgb3ZlcmxhcHBp bmcgcHJvcG9zYWxzIHRoYXQgaGF2ZSBkaWZmZXJlbnQgbWVhbmluZyAoYnV0IG5vdCB0aGUgc2Ft ZSkgdG8gaWxsdXN0cmF0ZSB0aGUgZGlmZmVyZW5jZSBmcm9tIGlzc3VpbmcgYSBzaW5nbGUgc2V0 IHdpdGggZGlmZmVyZW50IGV2ZW50cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkFzIEkgaGF2ZSBzdGF0ZWQgdGhpcyBpcyB2ZXJ5IGRp ZmZlcmVudCBmcm9tIGFzc2VydGluZyBtdWx0aXBsZSBkaXN0aW5jdCBldmVudHMgaW4gb25lIFNF VC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+QWxzbywgSSB0aGluayBpdCBpcyBzaW1wbGVyIHRvIGhhdmUgZXZl bnRfdHlwZSBiZSBhdCB0aGUgc2FtZSBsZXZlbCBhcyBldmVudDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ Jmx0O3BoJmd0O21heSBiZS4gSSB3YXMgd29ya2luZyBmcm9tIEFubmFiZWxsZSdzIHByb3Bvc2Vk IGZvcm1hdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+ezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7anRpJnF1b3Q7 OiAmcXVvdDszZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90Oyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7 ICZxdW90O2lhdCZxdW90OzogMTQ1ODQ5NjAyNSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZxdW90O2lzcyZxdW90Ozog JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZxdW90O2F1ZCZx dW90OzogWzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFt cGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQ8 L2E+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5l eGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3IiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZl ZTc8L2E+JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDtdLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7JnF1b3Q7ZXZl bnRfdHlwZSZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2 ZW50L3Bhc3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2V4YW1wbGUuY29t L3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsm cXVvdDtldmVudCZxdW90OzogeyZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7JnF1b3Q7aWQmcXVvdDs6JnF1b3Q7NDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFk OSZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O3Jlc2V0 QXR0ZW1wdHMmcXVvdDs6NTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPn08L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWYiPns8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyxzZXJpZiI+Jm5ic3A7ICZxdW90O2p0aSZxdW90OzogJnF1b3Q7M2QwYzNjZjc5NzU4NGJkMTkz YmQwZmIxYmQ0ZTdkMzAmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmcXVvdDtpYXQmcXVvdDs6IDE0NTg0OTYw MjUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss c2VyaWYiPiZuYnNwOyAmcXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2Np bS5leGFtcGxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbTwv YT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssc2VyaWYiPiZuYnNwOyAmcXVvdDthdWQmcXVvdDs6IFs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAm cXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTVi YmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9G ZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNw OyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2 YjFkMDg2NDFkNzY3NmVlNyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNv bS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3PC9hPiZxdW90Ozwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5i c3A7XSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyZxdW90O2V2ZW50X3R5cGUmcXVvdDs6ICZxdW90OzxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19z Y2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZlbnRfcmlzY19ldmVudC0yRHR5cGVfYWNjb3VudC0yRGNy ZWRlbnRpYWwtMkRjaGFuZ2UtMkRyZXF1aXJlZCZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055 NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnlt UlFTNmxLNjd5Rl84dThfcVNDX3cmYW1wO3M9blF5OWV6UFJqREdkdlJUQ2FpRHRpNE9IZWxIM0RL Z1VDVEtqRjJHUS1zbyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc2NoZW1hcy5vcGVu aWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS9hY2NvdW50LWNyZWRlbnRpYWwtY2hhbmdl LXJlcXVpcmVkPC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyZxdW90O2V2ZW50JnF1b3Q7OiB7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO+KAnHN1YuKAnTrigJ03Mzc1NjI2QTY1NjM3 NOKAnSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A74oCcaXNz4oCdOiZxdW90OzxhIGhy ZWY9Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vaWRw LmV4YW1wbGUuY29tLzwvYT4mcXVvdDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj59PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gTW9uLCBPY3QgMzAsIDIwMTcgYXQgMTI6MDkgUE0sIFBoaWwgSHVudCAmbHQ7PGEg aHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5o dW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkFubmFiZWxsZS9EaWNrLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciB0aGUgY29tbWVu dHMuIEkgdGhpbmsgd2UgbmVlZCB0byBleGFtaW5lIHRoZSBjb25zZXF1ZW5jZXMgb2YgdGhlIHBy b3Bvc2FsIGluIEpTT04uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkFzIEkgc3RhdGVkLCB3aGF0IGNhdXNlcyBtb3N0IG9mIHRoZSBpc3N1ZSBpcyB0 aGUgcHJvcG9zZWQgZXh0ZW5zaW9uIG1lY2hhbmlzbSBpbiB0aGUgcGF5bG9hZCAocG9zc2libHkg dXNpbmcgZXZlbnRzIGluIGEgcmVjdXJzaXZlIHdheSkuIERvZXMgaXQgZm9sbG93IHRoZSBvbGQg Zm9ybWF0IG9yIHRoZSBuZXc/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+TGV04oCZcyAmbmJzcDtjb25zaWRlciBhIHVzZSBjYXNlIHdoZXJlIHdlIGhh dmUgYW4gaWRlbnRpdHkgbWFuYWdlbWVudCBzeXN0ZW0gdGhhdCB1c2VzIFNDSU0sIGJ1dCB0aGUg U0NJTSBzeXN0ZW0gaXMgYWxzbyB0aGUgdW5kZXJseWluZyBkYXRhIHN0b3JlIGZvciBDb25uZWN0 LiZuYnNwOyBBIFBhc3N3b3JkIHJlc2V0IG1pZ2h0DQogZ2VuZXJhdGUgdGhlIGZvbGxvd2luZyBl dmVudCB3aGljaCBoYXMgYW4gZXh0ZW5zaW9uIChjb252ZXlpbmcgcmVzZXQgY291bnQpIEFORCBv dmVybGFwcGluZyBzdGF0ZW1lbnQgZnJvbSBSSVNDLiZuYnNwOyBCT1RIIG9mIHdoaWNoIG1pZ2h0 IGJlIGltcG9ydGFudCB0byBhIHNpbWlsYXIgcmVjZWl2ZXIgdXNpbmcgU0NJTSBhbmQgT0lEQy4g Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj5UaGUgMDMgc3BlYyBjdXJyZW50bHkgd291bGQgYWxsb3c6PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+ezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyAmcXVvdDtqdGkmcXVvdDs6ICZxdW90OzNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJk NGU3ZDMwJnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmcXVvdDtpYXQmcXVv dDs6IDE0NTg0OTYwMjUsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZxdW90O2lzcyZx dW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPC9hPiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiBbPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNv bS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQ8L2E+JnF1 b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBo cmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3 NmVlNyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2 MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3PC9hPiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyBdLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAmcXVvdDtl dmVudHMmcXVvdDs6IHs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJnF1b3Q7dXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldCZxdW90 Ozo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgeyAmcXVvdDtpZCZxdW90OzomcXVvdDs0NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5JnF1 b3Q7fSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1 b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRF eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dv cmRSZXNldEV4dDwvYT4mcXVvdDs6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHsgJnF1b3Q7cmVzZXRBdHRlbXB0cyZxdW90Ozo1fSw8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZl bnRfcmlzY19ldmVudC0yRHR5cGVfLTI1NUMmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENn YVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTRE cGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJR UzZsSzY3eUZfOHU4X3FTQ193JmFtcDtzPTI1bDA5c0g4WVY0Mnh6Z1UtQ1hTZzh4SDl0dnlESno0 MHRDUmpGYWxoa3cmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NjaGVtYXMub3Blbmlk Lm5ldC9zZWNldmVudC9yaXNjL2V2ZW50LXR5cGUvXDwvYT48YnI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7YWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZCZxdW90Ozogezwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnHN1YuKA nTrigJ03Mzc1NjI2QTY1NjM3NOKAnSw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyDigJxpc3PigJ06JnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTMuNXB0Ij48YSBocmVmPSJodHRwczovL2lkcC5leGFtcGxlLmNvbS8iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2lkcC5leGFtcGxlLmNvbS88L2E+JnF1b3Q7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7IH08L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPn08L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5J biB0aGUgYWJvdmUgLSBlYWNoIHBheWxvYWQgaXMgYSDigJhwZWVyJyBhbmQgaXNzdWVkIHdpdGhv dXQgcHJlZmVyZW5jZSBieSB0aGUgdHJhbnNtaXR0ZXIuIFRoZSByZWNlaXZlciBjYW4gYXNzaWdu IHByaW9yaXR5IGluIGl0cyBvd24gY29udGV4dCBpZiB0aGF0IG1hdHRlcnMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+ DQo8ZGl2Pg0KPHByZT48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBuZXcgcHJvcG9zYWw6PC9zcGFuPjwvYj48bzpwPjwvbzpw PjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT57PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZxdW90O2p0aSZxdW90OzogJnF1b3Q7 M2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAmcXVvdDssPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7ICZxdW90O2lhdCZxdW90OzogMTQ1ODQ5NjAyNSw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3Nj aW0uZXhhbXBsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3NjaW0uZXhhbXBsZS5jb208 L2E+JnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmcXVvdDthdWQmcXVvdDs6 IFs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJl Zj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3 NTQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0 NjFmYTViYmM4Nzk1OTNiNzc1NDwvYT4mcXVvdDssPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9G ZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9q aHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTc8L2E+JnF1b3Q7 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IF0sPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7ICZxdW90O2V2ZW50JnF1b3Q7OiB7PG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGV2ZW50X3R5cGXigJ06JnF1b3Q7dXJu OmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldOKAnSw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7aWQmcXVvdDs64oCdNDRmNjE0 MmRmOTZiZDZhYjYxZTc1MjFkOeKAnSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsg4oCcZXZlbnRz4oCdOns8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLSZndDtub3RlIOKApmlzIHRoaXMgdGhlIG9sZCBvciBuZXcg c3RydWN0dXJlPyAmbHQ7LTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL3Nj aW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZXhhbXBs ZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0PC9hPiZxdW90Ozo8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgeyAmcXVvdDtyZXNldEF0dGVtcHRzJnF1b3Q7OjV9LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2 ZW50LTJEdHlwZV8tMjU1QyZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQ Wmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlx UGtBSTFhTGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84 dThfcVNDX3cmYW1wO3M9MjVsMDlzSDhZVjQyeHpnVS1DWFNnOHhIOXR2eURKejQwdENSakZhbGhr dyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0L3NlY2V2 ZW50L3Jpc2MvZXZlbnQtdHlwZS9cPC9hPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDthY2NvdW50LWNyZWRlbnRpYWwtY2hhbmdlLXJlcXVpcmVkJnF1b3Q7OiB7PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcc3Vi 4oCdOuKAnTczNzU2MjZBNjU2Mzc04oCdLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGlzc+KAnTomcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQiPjxhIGhyZWY9Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLzwvYT4mcXVvdDs8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IH08L3NwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij59PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ SW4gdGhlIGFib3ZlLCBzdWItZXZlbnRzIG9yIGV4dGVuc2lvbnMgaGF2ZSBhIGRpZmZlcmVudCBm b3JtYXQuIFRoZSBzYW1lIGNvbXBsYWludCBhYm91dCB0aGUgb3JpZ2luYWwgc3RhbmRzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPipPUiogKGlmIHRoZSByZWNlaXZlciBjYXJlcyBhYm91dCBSSVNDIG1vcmUpLiZuYnNwOyBO b3RlIHRoYXQgdGhpcyBsZWFkcyB0byBhIHRyaXBsZSBuZXN0ZWQgc3RydWN0dXJlLjwvc3Bhbj48 L2I+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+ ezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmcXVvdDtqdGkmcXVvdDs6ICZxdW90OzNk MGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwJnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyAmcXVvdDtpYXQmcXVvdDs6IDE0NTg0OTYwMjUsPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7ICZxdW90O2lzcyZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zY2lt LmV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPC9h PiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiBb PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9 Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYx ZmE1YmJjODc5NTkzYjc3NTQ8L2E+JnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVl ZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vamh1 Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3PC9hPiZxdW90Ozxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBdLDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyAmcXVvdDtldmVudCZxdW90OzogezxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxldmVudF90eXBl4oCdOjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTMuNXB0Ij4mcXVvdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVuaWQubmV0X3NlY2V2ZW50 X3Jpc2NfZXZlbnQtMkR0eXBlXy0yNTVDJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBj dHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2 bEs2N3lGXzh1OF9xU0NfdyZhbXA7cz0yNWwwOXNIOFlWNDJ4emdVLUNYU2c4eEg5dHZ5REp6NDB0 Q1JqRmFsaGt3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5u ZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL1w8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO2FjY291bnQtY3JlZGVu dGlhbC1jaGFuZ2UtcmVxdWlyZWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PuKAnSw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxzdWLigJ064oCdNzM3 NTYyNkE2NTYzNzTigJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDvigJxpc3Pi gJ06JnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJo dHRwczovL2lkcC5leGFtcGxlLmNvbS/igJwiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2lkcC5l eGFtcGxlLmNvbS/igJw8L2E+LDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKA nGV2ZW50c+KAnTp7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJnF1b3Q7dXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldCZxdW90Ozo8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB7Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtpZCZxdW90OzrigJ00NGY2MTQyZGY5NmJk NmFiNjFlNzUyMWQ54oCdLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxldmVudHPigJ06ezxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczov L2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0PC9hPiZxdW90 Ozo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeyAm cXVvdDtyZXNldEF0dGVtcHRzJnF1b3Q7OjV9LDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0 Ij4mbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDt9PC9zcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86 cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwO308L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPn08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cHJl PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gdGhlIGFi b3ZlLCB0aGUgZXh0ZW5zaW9uIGlzIHBsYWNlZCBpbnNpZGUgdGhlIGV2ZW50IGl0IGV4dGVuZHMu IEl0IGZvbGxvd3MgdGhlIG9sZCBmb3JtYXQgKG9yIHNob3VsZCBpdCBmb2xsb3cgdGhlIG5ldz8p PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Kk9SKiBG b2xsb3dpbmcgdGhlIHRvcCBsYXllciBwYXR0ZXJuIG9mIHNpbmd1bGFyIGV2ZW50Jm5ic3A7IE5v dGUgdGhhdCB0aGlzIGxlYWRzIHRvIGEgdHJpcGxlIG5lc3RlZCBzdHJ1Y3R1cmUuPC9zcGFuPjwv Yj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT57 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZxdW90O2p0aSZxdW90OzogJnF1b3Q7M2Qw YzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAmcXVvdDssPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7ICZxdW90O2lhdCZxdW90OzogMTQ1ODQ5NjAyNSw8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0u ZXhhbXBsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3NjaW0uZXhhbXBsZS5jb208L2E+ JnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmcXVvdDthdWQmcXVvdDs6IFs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0i aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFm YTViYmM4Nzk1OTNiNzc1NDwvYT4mcXVvdDssPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVk cy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9qaHVi LmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTc8L2E+JnF1b3Q7PG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IF0sPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7ICZxdW90O2V2ZW50JnF1b3Q7OiB7PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGV2ZW50X3R5cGXigJ06PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQiPiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZlbnRf cmlzY19ldmVudC0yRHR5cGVfLTI1NUMmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0 eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZs SzY3eUZfOHU4X3FTQ193JmFtcDtzPTI1bDA5c0g4WVY0Mnh6Z1UtQ1hTZzh4SDl0dnlESno0MHRD UmpGYWxoa3cmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NjaGVtYXMub3BlbmlkLm5l dC9zZWNldmVudC9yaXNjL2V2ZW50LXR5cGUvXDwvYT48L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7YWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZDxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij7igJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsg4oCcc3Vi4oCdOuKAnTczNzU2MjZBNjU2Mzc04oCdLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcaXNz4oCdOiZxdW90Ozxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2lkcC5leGFtcGxl LmNvbS/igJwiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2lkcC5leGFtcGxlLmNvbS/igJw8L2E+ LDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGV2ZW504oCdOns8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxldmVudF90eXBl4oCd OiZxdW90O3VybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3JkUmVzZXTigJ0sPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPiZxdW90O2lk JnF1b3Q7OuKAnTQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDnigJ0sPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGV2ZW50 4oCdOns8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXZlbnRfdHlwZeKAnTomcXVvdDs8YSBocmVm PSJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0 PC9hPuKAnSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7cmVzZXRBdHRlbXB0cyZxdW90Ozo1 PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPiA8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxkaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO308bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB9Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDt9PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij59PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+VGhpcyBmb3JtYXQgZm9sbG93cyB0aGUgcHJvcG9zZWQgc2luZ3VsYXIgZXZlbnQg Zm9ybWF0IHJlY3Vyc2l2ZWx5IGFuZCBpcyAzIGxheWVycyBkZWVwLiBOb3RlIHRoYXQgdGhlIHBh cnNlciBoYXMgdG8gY29udGludWUgdG8gc2VhcmNoIHRoZSBkb2N1bWVudCBmb3IgdGhpbmdzIHRo YXQgYXJlbuKAmXQgdGhlcmUgYXMgaXQgaGFzIHRvIHN0b3Agd2hlbiBubyDigJxldmVudOKAnSBh dHRyaWJ1dGUgaXMgZm91bmQgcmF0aGVyIHRoYW4gaXRlcmF0ZSBvdmVyIGFuIGFycmF5Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBoaWw8YnI+DQo8YnI+DQpP cmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdDxicj4N CkBpbmRlcGVuZGVudGlkPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNvbSZhbXA7ZD1Ed01G YVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7 cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPWl5Vm5y Wm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmYW1wO3M9OXNZaGdwRXpiN3hQ bFFGbUNDWE5tSG82ZlFOOUlCdS1TSEphbWdfQjRIcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj53 d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIE9jdCAzMCwgMjAxNywgYXQgODo1NyBBTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFu ayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAi PlJlcGxpZXMgaW5saW5lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3 aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPklkZW50aXR5IFNlcnZpY2Vz PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkZyb206PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3 MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0 NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5QaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+ RGF0ZTo8c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1 MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5TdW5kYXksIE9jdG9iZXIgMjksIDIwMTcgYXQgNToy NSBQTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4 NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkRpY2sgSGFyZHQgJmx0OzxhIGhy ZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmRpY2suaGFyZHRAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQx MDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+WWFyb24gU2hlZmZlciAmbHQ7PGEgaHJlZj0i bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0OywNCiBN aWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT4mZ3Q7LCAmcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFu bmFiZWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yaWNoYW5uYUBhbWF6b24u Y29tPC9zcGFuPjwvYT4mZ3Q7LA0KIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9 Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1 MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11 bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KSSBob3BlIHRoaXMgYW5z d2VycyB5b3VyIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQpNeSDigJxtYXnigJ0gd2FzIGJlY2F1c2Ug SSBjYW7igJl0IHNlZSBhIHJlYXNvbiB3aHkgbm90LiBUaGUgcXVlc3Rpb24gc2hvdWxkIGJlLCB3 aGF0IGlzIHRoZSBqdXN0aWZpY2F0aW9uIHRvIG1ha2Ug4oCcZXZlbnRz4oCdIHNpbmd1bGFyPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPltyaWNoYW5uYV1UaGUg c2luZ3VsYXIg4oCcZXZlbnTigJ0gY2xhaW0gaGFzIGNsZWFyZXIgc2VtYW50aWNzIGFuZCBpcyBl YXNpZXIgdG8gcHJvY2Vzcy4gV2Ugc2hvdWxkIG9wdCBmb3IgZWFzaWVyIHNvbHV0aW9ucyB1bmxl c3MgdGhlcmUgYXJlIHVzZSBjYXNlcyB0aGF0IHJlcXVpcmUgbW9yZSBjb21wbGV4aXR5Llsvcmlj aGFubmFdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQpUaGVyZSBhcmUgbWFueSByZWFzb25zIGZvciBtdWx0 aXBsZSBldmVudHMgaW4gYSBTRVQuJm5ic3A7IFNvbWUgYXJlIGdvb2QsIHNvbWUgbm90IHNvIGdv b2QuIFNvbWUgb2YgdGhlIHJlYXNvbnMuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4N CiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KMS4mbmJzcDsgTXVsdGlwbGUg ZXZlbnQgcGF5bG9hZHMgZXhwcmVzc2luZyBzdGF0ZW1lbnRzIGFib3V0IGxhcmdlbHkgdGhlICpz YW1lKnRoaW5nLiBGb3IgZXhhbXBsZSwgU0NJTSBwYXNzd29yZCByZXNldCBBTkQgUklTQyBwYXNz d29yZCByZXNldC4mbmJzcDsgQSBSSVNDIEV2ZW50IGFuZCBhbiBPcGVuQmFua2luZyBFdmVudC4g SXMgb25lIGEgY29tcGxlbWVudCB0byB0aGUgb3RoZXI/Jm5ic3A7IERvIHRoZXkgb3ZlcmxhcCBv ciBhcmUgdGhleSBkaXN0aW5jdD8gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6I0MzNDZFMCI+W3JpY2hhbm5hXUNvcHkvcGFzdGVkIGZyb20gbXkgZWFybGllciBlbWFp bDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6I0MzNDZFMCI+V2h5 IGlzIGl0IG5lY2Vzc2FyeSBvciBhcHByb3ByaWF0ZSB0byBpbmNsdWRlIHRoZXNlIGV2ZW50cyBp biB0aGUgc2FtZSBTRVQ/IFRoZXkgYXJlIGxpa2VseSBiZWluZyBnZW5lcmF0ZWQgYnkgZGlmZmVy ZW50IHN5c3RlbXMgYXQgZGlmZmVyZW50IHRpbWVzIG9uIHRoZSB0cmFuc21pdHRlcuKAmXMgc2lk ZSwgY29uc3VtZWQgYnkgZGlmZmVyZW50IHN5c3RlbXMgb24gdGhlIHJlY2VpdmVy4oCZcyBzaWRl LA0KIGFuZCBwb3NzaWJseSBiZWluZyB0cmFuc21pdHRlZCBvdmVyIGRpZmZlcmVudCBldmVudCBz dHJlYW1zLiBJIGtub3cgdGhlIGxhdHRlciB3b3VsZCBiZSB0aGUgY2FzZSBmb3IgdXMsIGFzIGEg cmVjZWl2ZXIuIEV2ZW4gaWYgaXTigJlzIG5vdCwgaXMgaXQgYnVyZGVuc29tZSB0byBzZW5kIHRo ZXNlIGV2ZW50cyBzZXBhcmF0ZWx5PyBXaGF0IHZhbHVlIGlzIGdhaW5lZCBpbiBjb21iaW5pbmcg dGhlbT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6I0MzNDZFMCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAi PkFkZGl0aW9uYWxseSwgc2luY2UgdGhlIHNpZ25hdHVyZSBpcyBvdmVyIHRoZSBTRVQgYW5kIG5v dCB0aGUgZXZlbnQgb2JqZWN0cywgUmVjZWl2ZXJzIGluZGVwZW5kZW50bHkgcm91dGUgc2VwYXJh dGUgZXZlbnRzIGZyb20gYSBzaW5nbGUgdG9rZW4gd2l0aG91dCBlaXRoZXIgbG9zaW5nIHRoZSBh YmlsaXR5IHRvIHZlcmlmeSB0aGUgYXV0aGVudGljaXR5IG9mIHRoZSBldmVudCBvciBzaGFyaW5n IGFsbA0KIGluZm9ybWF0aW9uIGluIHRoZSBTRVQgd2l0aCBldmVyeSBzeXN0ZW0gaGFuZGxpbmcg YW55IGV2ZW50IGluIHRoZSB0b2tlbi5bL3JpY2hhbm5hXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjojQzM0NkUwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3Vu ZDp3aGl0ZSI+DQoyLiZuYnNwOyBNdWx0aXBsZSBldmVudHMgcGF5bG9hZHMgZXhwcmVzc2luZyBk aWZmZXJlbnQgc3RhdGVtZW50cyBhYm91dCB0aGUgc2FtZSB0cmFuc2FjdGlvbiAtIFJJU0MgUGFz c3dvcmQgUmVzZXQgYW5kIFJJU0MgU2Vzc2lvbiBDYW5jZWw8YnI+DQo8c3BhbiBzdHlsZT0iY29s b3I6I0MzNDZFMCI+W3JpY2hhbm5hXVNhbWUgYXMgYWJvdmVbL3JpY2hhbm5hXTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjMuJm5ic3A7IEEgbmV3IHByb2ZpbGUgZGVmaW5l cyBuZXcgZXZlbnQgYXR0cmlidXRlcyB0byBiZSBhZGRlZCBvbiB0byBhbiBleGlzdGluZyBldmVu dCB0eXBlIChhIHB1cmUgZXh0ZW5zaW9uKSZuYnNwOzxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjoj QzM0NkUwIj5bcmljaGFubmFdSSBoYXZlIHN1Z2dlc3RlZCBhIHdheSB0byBzdXBwb3J0IGV4dGVu c2lvbnMgd2l0aGluIGFuIGV2ZW50IGJvZHksIG11bHRpcGxlIHRpbWVzIG5vdy4gSWYgeW91IHNl ZSBwcm9ibGVtcyB3aXRoIGl0LCBwbGVhc2UgcG9pbnQgdGhlbSBvdXQuWy9yaWNoYW5uYV08L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOndoaXRlIj4NCkkgdGhpbmsgaXQgaXMgcXVpdGUgdmFsaWQgdG8gYWxsb3cgMSBhbmQg My4gJm5ic3A7MiBjb3VsZCBiZSBsaW1pdGVkIGJ5IHNwZWNpZmljIHByb2ZpbGVzIGxpa2UgUklT QyBpZiB0aGV5IHdhbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCkkgYW0gbm90IGluIGFncmVlbWVudCB0aGF0IG1h a2luZyBldmVudCBzaW5ndWxhciBzaW1wbGlmaWVzIGFueXRoaW5nLiBGb3Igb25lIGlzIG1ha2Vz IGV4dGVuc2lvbnMgY29tcGxleCAoYW5vdGhlciBuZXN0ZWQgSlNPTiBzdHJ1Y3R1cmUpIGFuZCBw b3RlbnRpYWxseSBjb25mbGljdGluZy4mbmJzcDs8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6I0Mz NDZFMCI+W3JpY2hhbm5hXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjojQzM0NkUwIj5XYXlzIHRoYXQgbXVsdGlwbGUtZXZlbnQgU0VUcyBhcmUgbW9yZSBjb21wbGlj YXRlZDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxvbCBzdGFydD0iMSIgdHlwZT0i MSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiNDMzQ2RTA7bXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGlu O21zby1saXN0Omw0IGxldmVsMSBsZm8zO2JhY2tncm91bmQ6d2hpdGUiPg0KSXQgcmVzdWx0cyBp biBhIG1vcmUgY29tcGxleCBzdHJ1Y3R1cmUgZm9yIHRoZSBzaW5nbGUgZXZlbnQgdXNlIGNhc2Us IHdoaWNoIEkgdGhpbmsgd2UgYWxsIGFncmVlIGlzIHRoZSBtYWpvcml0eSB1c2UgY2FzZS48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojQzM0NkUwO21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvMztiYWNrZ3JvdW5kOndoaXRlIj4NCk11bHRp cGxlLWV2ZW50IFNFVHMgaGF2ZSBhbWJpZ3VvdXMgc2VtYW50aWNzLiBUaGUgcHJlc2VuY2Ugb2Yg dHdvIGV2ZW50cyBBIGFuZCBCIGluIHRoZSBzYW1lIFNFVCBjb3VsZCBtZWFuIGFueSBvZjo8bzpw PjwvbzpwPjwvbGk+PC9vbD4NCjxvbCBzdGFydD0iMiIgdHlwZT0iMSI+DQo8b2wgc3RhcnQ9IjEi IHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojQzM0NkUwO21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsNSBsZXZlbDIgbGZvNjtiYWNrZ3JvdW5kOndoaXRlIj4NClRoZXkg YXJlIHJlbGF0ZWQgdG8gdGhlIHNhbWUgbG9naWNhbCBldmVudCAoaS5lLiB0aGUgc2FtZSB0aGlu ZyBhcyBpZiB0aGV5IHdlcmUgZnJvbSBkaWZmZXJlbnQgU0VUcyB0aGF0IGhhdmUgYSBjb21tb24g dHhuKS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjoj QzM0NkUwO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNSBsZXZlbDIgbGZvNjtiYWNrZ3JvdW5kOndoaXRl Ij4NCkEgaXMgYW4gZXh0ZW5zaW9uIG9mIEIuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY29sb3I6I0MzNDZFMDttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDUgbGV2ZWwy IGxmbzY7YmFja2dyb3VuZDp3aGl0ZSI+DQpCIGlzIGFuIGV4dGVuc2lvbiBvZiBBLjxvOnA+PC9v OnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiNDMzQ2RTA7bXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MGluO21zby1saXN0Omw1IGxldmVsMiBsZm82O2JhY2tncm91bmQ6d2hpdGUiPg0KVGhleSBhcmUg YWxpYXNlcyBmb3Igb25lIGFub3RoZXIuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iY29sb3I6I0MzNDZFMDttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDUgbGV2ZWwyIGxm bzY7YmFja2dyb3VuZDp3aGl0ZSI+DQpUaGV5IGFyZSBub3QgYWN0dWFsbHkgcmVsYXRlZCB0byBv bmUgYW5vdGhlciBpbiBhbnkgd2F5LjxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9vbD4NCjxvbCBz dGFydD0iMyIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiND MzQ2RTA7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm85O2JhY2tncm91bmQ6d2hpdGUi Pg0KQ2xhaW0gc2VtYW50aWNzIGJlY29tZSBoYXJkZXIgdG8gZGVmaW5lLCBhcyBkaWZmZXJlbnQg cHJvZmlsZXMgbWF5IHdhbnQgdG8gdXNlIHRoZSBzYW1lIGNsYWltcyBpbiBkaWZmZXJlbnQgd2F5 cy48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCklmIHRoZSBXRyB3YW50cyB0byBibG9jayAxIGFuZCAyIGFib3ZlLCB0aGVu IEkgYmVsaWV2ZSB3ZSBoYXZlIHRvIGVzdGFibGlzaCBhbiBldmVudCByZWdpc3RyeSB0byBlbnN1 cmUgbmV3IEV2ZW50IHByb2ZpbGVzIGRvIG5vdCBvdmVybGFwIHRvIGVsaW1pbmF0ZSB0aGUgbmVl ZCB0byBleHByZXNzIG11bHRpcGxlIGV2ZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojQzM0NkUwIj5bcmljaGFubmFdSeKAmW0gbm90IHN1cmUg d2hhdCB5b3UgbWVhbiBieSB0aGlzLiBBcmUgeW91IHJlZmVycmluZyB0byBldmVudCBuYW1lcz8g VGhvc2UgYXJlIGFscmVhZHkgZGVmaW5lZCBieSB0aGUgc3BlYyB0byBiZSBVUklzLlsvcmljaGFu bmFdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KUGhp bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2Vz IEFyY2hpdGVjdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KQGluZGVwZW5kZW50aWQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5jb20m YW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFw SV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZh bXA7bT1VLWE1SEJORDBIYVRYNGFuTlpmelg3cERzZks1ZjBoOW1aOUNaa2tHaWVjJmFtcDtzPUtC d0tQRm5xWV9ROTVDVEFfX1dHQ1lHVHhyRDdBR0N4dWVvUFhuS0VVVDAmYW1wO2U9IiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+d3d3LmluZGVwZW5kZW50aWQuY29t PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCk9u IE9jdCAyOSwgMjAxNywgYXQgNDoxMiBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+ZGljay5oYXJkdEBnbWFpbC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzti YWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5QaGlsOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5JbiB5b3VyIGV4YW1wbGVzIGZvciBoYXZpbmcgYSBwbHVyYWxp dHkgb2YgZXZlbnRzLCB5b3UgdXNlIHRoZSB3b3JkICZxdW90O21heSZxdW90Oywgd2hpY2ggbGVh ZHMgbWUgdG8gcXVlc3Rpb24gaWYgYSBwbHVyYWxpdHkgb2YgZXZlbnRzIGlzIHJlYWxseSByZXF1 aXJlZCBpbiBTRVQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+WW91IHBvc2l0IHRoYXQgaXQgd2lsbCBiZSBkaWZmaWN1bHQgZm9y IGEgZGlzdHJpYnV0ZWQgc3lzdGVtIHRvIGNvcnJlbGF0ZSBtdWx0aXBsZSBTRVRzIHdpdGggdGhl IHNhbWUgJnF1b3Q7dHhuJnF1b3Q7LCBidXQgdGhlIGRpc3RyaWJ1dGVkIHN5c3RlbSB3aWxsIGNl cnRhaW5seSBuZWVkIHRvIGNvcnJlbGF0ZSBldmVudHMgb24gdGhlIHNhbWUgc3ViamVjdA0KIC0t IGNvcnJlbGF0aW5nIGV2ZW50cyBvbiB0aGUgc2FtZSAmcXVvdDt0eG4mcXVvdDsgb24gdGhlIHNh bWUgc3ViamVjdCBzZWVtcyBmYWlybHkgc2ltcGxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzti YWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgdGhpbmsgdGhhdCBhIHJlY2Vp dmVyIHdpbGwgbmVlZCB0byBjb3JyZWxhdGUgbXVsdGlwbGUgU0V0cyBvbiB0aGUgc2FtZSBzdWJq ZWN0LCBzbyBoYXZpbmcgbXVsdGlwbGUgZXZlbnRzIGluIGEgU0VUIGlzIHJlZHVuZGFudCwgYW5k IGFkZHMgY29tcGxleGl0eSB3aXRoIG5vIGNsZWFyIGJlbmVmaXQgdGhhdCBJIGNhbiBzZWUuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+QW4gaW1wbGVtZW50b3IgbWF5IGNob29zZSB0byBzZW5kIG11bHRpcGxlIFNFVHMsIG9yIHNl bmQgYSBzaW5nbGUgU0VUIHdpdGggbXVsdGlwbGUgZXZlbnRzLCBzbyBhIHJlY2VpdmVyIHdpbGwg bmVlZCB0byBzdXBwb3J0IGJvdGguIEkgcHJlZmVyIHdlIHBpY2sgb25lIHdheSBhbmQgbWluaW1p emUgdGhlIGNvZGUgcGF0aHMsIGFuZCB3ZQ0KIHdpbGwgbmVlZCB0byBzdXBwb3J0IGNvcnJlbGF0 aW5nIGFjcm9zcyBtdWx0aXBsZSBTRVRzLCBzbyB0aGF0IHNlZW1zIHRoZSBiZXN0IG1lY2hhbmlz bS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5MZXQgbWUga25vdyBpZiB0aGVyZSBpcyBzb21ldGhpbmcgSSBtaXNzZWQgaW4gbXkg bG9naWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+L0RpY2s8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBTdW4sIE9jdCAyOSwgMjAxNyBhdCAxMToy OCBBTSwgWWFyb24gU2hlZmZlcjxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUw MTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0 YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0OzxhIGhyZWY9Im1haWx0bzp5 YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L3NwYW4+PC9hPiZndDs8c3BhbiBjbGFzcz0i bS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2 NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPndyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gdGhhdCBjYXNl LCBsZXQncyBhZGQgdGV4dCB0byB0aGF0IGVmZmVjdCwgZS5nLiB3ZSBjb3VsZCBhZGQgdG8gdGhl IGRlZmluaXRpb24gb2YgdGhlICZxdW90O2V2ZW50cyZxdW90OyBjbGFpbTo8YnI+DQo8YnI+DQpQ cm9maWxpbmcgc3BlY2lmaWNhdGlvbnMgU0hPVUxEIGRlZmluZSB0aGUgYWxsb3dlZCBldmVudCBz dGF0ZW1lbnRzLCBhbmQgTUFZIHJlc3RyaWN0IHRoZWlyIG51bWJlci4gRm9yIGV4YW1wbGUsIHNv bWUgcHJvZmlsZXMgbWF5IHJlcXVpcmUgdGhpcyBjbGFpbSB0byBjb250YWluIG9ubHkgYSBzaW5n bGUgZXZlbnQgc3RhdGVtZW50Ljxicj4NCjxicj4NClRoYW5rcyw8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0 ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPllhcm9uPGJyPg0KPGJyPg0KT24gMjQvMTAv MTcgMjI6MTAsIE1pa2UgSm9uZXMgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYWdyZWUg d2l0aCBtdWNoIG9mIFBoaWzigJlzIHJhdGlvbmFsZSBoZXJlLjxicj4NCjxicj4NCkl04oCZcyBm aW5lIGZvciBzb21lIHByb2ZpbGVzIHRvIHNheSB0aGF0IHRoZSDigJxldmVudHPigJ0gc2V0IG11 c3QgYmUgYSBzaW5nbGV0b24uJm5ic3A7IFRoYXQgZG9lc27igJl0IGhhdmUgdG8gYmUgdHJ1ZSBm b3IgYWxsIGV2ZW50cy4mbmJzcDsgSSB0aGluayB0aGluZ3MgYXJlIGZpbmUgYXMtaXMuPGJyPg0K PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgw MjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj4tLSBNaWtlPGJyPg0KPGJyPg0KKkZyb206KiBJZC1ldmVudCBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+XSAqT24gQmVoYWxmIE9mICpQaGlsIEh1bnQ8YnI+DQoqU2VudDoqIE1vbmRheSwgT2N0b2Jl ciAyMywgMjAxNyA4OjQ3IFBNPGJyPg0KKlRvOiogUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUg Jmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cmljaGFubmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+ Jmd0Ozxicj4NCipDYzoqIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0 bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KKlN1YmplY3Q6KiBS ZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzxicj4N Cjxicj4NCkFubmFiZWxsZSw8YnI+DQo8YnI+DQpJIGhhdmUgYSBudW1iZXIgb2YgY29uY2VybnMg d2l0aCB0aGlzIHByb3Bvc2FsLjxicj4NCjxicj4NClByb2ZpbGluZyBJbmRlcGVuZGVuY2UgLyBL ZWVwaW5nIEV2ZW50IFBheWxvYWRzIEluZGVwZW5kZW50PGJyPg0KPGJyPg0KSW5kaWNhdGluZyB0 aGF0IGV4dGVuc2lvbnMgc2hvdWxkIGJlIGhhbmRsZWQgYnkgcHJvZmlsZXMgbGVhZHMgdG8gbW9y ZSBpbnRlci1vcGVyYWJpbGl0eSBpc3N1ZXMgYW5kIG1vcmUgaW1wb3J0YW50bHkgaW50cnVkZXMg b24gdGhlIEV2ZW50IHBheWxvYWQgc3BhY2UgYnkgc3VnZ2VzdGluZyBhIHN1Yi1zY2hlbWEgY3Jl YXRlcyBwb3RlbnRpYWwgbGltaXRhdGlvbnMgYW5kIGNvbmZsaWN0cyB0aGF0IG1heSBhZGQgdG8g Y29tcGxleGl0eSBsYXRlcg0KIG9uLiBUaGUgY3VycmVudCBmb3JtYXQgYWxsb3dzIGEgcGFyc2Vy IHRvIGRpc2NvdmVyIGFuZCB1bmxvYWQgb25lIG9yIG1vcmUgSlNPTiBwYXlsb2FkcyB3aGljaCBj YW4gZWFjaCBoYXZlIGluZGVwZW5kZW50IHN0cnVjdHVyZS48YnI+DQo8YnI+DQpHZW5lcmFsIGV4 dGVuc2lvbnM8YnI+DQo8YnI+DQpUaGUgcHJvcG9zYWwgYWxzbyBydWxlcyBvdXQgZ2VuZXJhbCBw dXJwb3NlIGV4dGVuc2lvbnMgbm90IHJlbGF0ZWQgdG8gYW55IHNwZWNpZmljIGV2ZW50LiBHaXZl biB0aGUgZW1lcmdlbmNlIG9mIGl0ZW1zIGxpa2UgR1BSRCwgSSB3b3VsZCBub3Qgd2FudCB0byBi bG9jayB0aGUgYWJpbGl0eSB0byBhZGQgbWV0YS1kYXRhIG9yIG90aGVyIGdlbmVyYWwgcHVycG9z ZSBpdGVtcy4gV2UgY2FuIGFsc28gYW50aWNpcGF0ZSBzb21lIGRlbGl2ZXJ5IHNjZW5hcmlvcw0K IHdoZXJlIGFkZGl0aW9uYWwgZGF0YSBtaWdodCBiZSByZXF1aXJlZC4gRXZlbiB0aG91Z2ggdGhl cmUgaXMgbm8gY3VycmVudCBwbGFubmVkIHVzZSwgSSBzZWUgbm8gZ29vZCByZWFzb24gdG8gcnVs ZSB0aGlzIG91dC48YnI+DQo8YnI+DQpNdWx0aXBsZSBFdmVudHMgRnJvbSBEaWZmZXJlbnQgRmFt aWxpZXMgKHZzLiBNdWx0aXBsZSBFdmVudHMgZnJvbSBhIHNpbmdsZSBmYW1pbHkgbGlrZSBSSVND KTxicj4NCjxicj4NCkluIG91ciBSSVNDIHNlc3Npb24gd2UgZGlzY3Vzc2VkIGV4cHJlc3Npbmcg bXVsdGlwbGUgZGlzdGluY3QgUklTQyBldmVudHMgaW4gb25lIFNFVC4gVGhlIGRpc2N1c3Npb24g d2FzIHRoYXQgb25seSBvbmUgUklTQyBldmVudCBhdCBhIHRpbWUuIFdlIGRpZCBub3QgZGlzY3Vz cyBvdGhlciBldmVudCBwcm9maWxlcy4gSSBkb27igJl0IHNlZSBhIHJlYXNvbiB0byBydWxlIG91 dCBtdWx0aS1ldmVudHMgZnJvbSBkaWZmZXJlbnQgZmFtaWxpZXMgYXQgdGhlDQogU0VUIGxldmVs LiBFYWNoIHByb2ZpbGUgaXMgZXhwcmVzc2luZyBzbGlnaHRseSBkaWZmZXJlbnQgdGhpbmdzIGFi b3V0IHRoZSBzYW1lIGV2ZW50Ljxicj4NCjxicj4NCkkgY2FuIGZvcnNlZSBzb21lIGNhc2VzIHdo ZXJlIGl0IGlzIG5vdCBjbGVhciB3aGljaCBpcyB0aGUgcHJpbWFyeSBhbmQgd2hpY2ggaXMgdGhl IGV4dGVuc2lvbi4mbmJzcDsgVGhlcmUgbWF5IG5vdCBiZSBhIGNsZWFyIHdpbm5lci48YnI+DQo8 YnI+DQpBIGNvdXBsZSBvZiBleGFtcGxlcyAodGhlc2UgYXJlIG5lY2Vzc2FyaWx5IHJlYWzigKZq dXN0IHBvc3NpYmlsaXRpZXMpOjxicj4NCjxicj4NCiogSXQgaXMgcHJvYmFibHkgdXNlZnVsIHRv IGJlIGFibGUgdG8gZXhwcmVzcyBzaW1sYXIvb3ZlcmxhcHBpbmcgZXZlbnRzIGZyb20gZGlmZmVy ZW50IFNFVCBwcm9maWxlcyBpbiBvbmUgU0VULiZuYnNwOyBGb3IgZXhhbXBsZSBhIEJhY2tjaGFu bmVsIExvZ291dCAmYW1wOyBhIFJJU0Mgc2Vzc2lvbiBjYW5jZWwgZXZlbnQuPGJyPg0KPGJyPg0K KiBTQ0lNIG1heSB3YW50IHRvIHJlcHJlc2VudCBhIHNpbmdsZSB0cmFuc2FjdGlvbiBhcyBjYXVz aW5nIG11bHRpcGxlIHN0YXRlIGNoYW5nZXMgaW4gYW4gZXZlbnQgKGUuZy4gYSBwYXNzd29yZCBj aGFuZ2UgY2F1c2VzIG11bHRpcGxlIGVmZmVjdHMpLiBIYXZpbmcgdG8gY2hhc2UgZG93biBtdWx0 aXBsZSBldmVudHMgYW5kIGNvcnJlbGF0ZSBieSDigJx0eG7igJ0gd291bGQgYmUgY2hhbGxlbmdp bmcgaW4gYSBtdWx0aS10aHJlYWRlZC9tdWx0aS1ub2RlDQogZGVsaXZlcnkgc3lzdGVtLiZuYnNw OyAmbmJzcDtUaGUgU0NJTSBsaXN0IGhhcyBub3QgZGlzY3Vzc2VkIHRoaXMsIGJ1dCBJIHdvdWxk IG5vdCB3YW50IHRvIGJsb2NrIHRoaXMgY2FwYWJpbGl0eS4mbmJzcDsgSU9XIC0gSnVzdCBiZWNh dXNlIFJJU0MgZG9lcyBub3Qgd2FudCB0byBleHByZXNzIG11bHRpcGxlIGV2ZW50cyBkb2VzIG5v dCBtYWtlIHRoaXMgdHJ1ZSBmb3Igb3RoZXIgcHJvZmlsZXMuPGJyPg0KPGJyPg0KKiBXZSBtYXkg d2lzaCB0byBpbmRpY2F0ZSBhIFNDSU0gUGFzc3dvcmQgUmVzZXQgd2FzIHBlcmZvcm1lZCBhbmQg YSBMb2dvdXQvc2Vzc2lvbiBjYW5jZWxsYXRpb24gaXMgZXhwcmVzc2VkIGF0IHRoZSBzYW1lIHRp bWUuJm5ic3A7IFRoZSBldmVudHMgYXJlIHJlbGF0ZWQgYnV0IGV4cHJlc3MgZGlmZmVyZW50IGRh dGEuPGJyPg0KPGJyPg0KQXZvaWRpbmcgQ29uZnVzaW9uIEZyb20gU2ltaWxhciBFdmVudHMgT3Jp Z2luYXRpbmcgZnJvbSB0aGUgU2FtZSBUcmFuc2FjdGlvbjxicj4NCjxicj4NCklmIGV2ZW50cyBh cmUgc2VudCBzZXBhcmF0ZWx5LCB0aGVuIG1vcmUgdHJhY2tpbmcgb2Ygc3RhdGUgKGUuZy4gYnkg dHhuKSB3b3VsZCBiZSByZXF1aXJlZCB0byBlbnN1cmUgc2ltaWxhciBldmVudHMgYXJlIG5vdCBt aXN0YWtlbiBvciBoYW5kbGVkIGFzIHJlcGVhdHMuIFdoaWxlIHR4biBwcm92aWRlcyB1c2VmdWwg YXVkaXQgYW5hbHlzaXMgY2FwYWJpbGl0eSwgSeKAmW0gbm90IHN1cmUgaXQgY2FuIGJlIHVzZWQg aW4gbGl2ZSBvciBuZWFyLXJlYWwNCiB0aW1lIHN5c3RlbXMgZ2l2ZW4gZGlzdHJpYnV0ZWQgbXVs dGktbm9kZSwgbXVsdGktdGhyZWFkaW5nIGFyY2hpdGVjdHVyZXMuPGJyPg0KPGJyPg0KUHJldmlv dXMgRGlzY3Vzc2lvbjxicj4NCjxicj4NCkkgbm90ZSB0aGF0IEkgb3JpZ2luYWxseSByYWlzZWQg aGF2aW5nIGFuIGF0dHJpYnV0ZSB0byBkZXNpZ25hdGUgcHJpbWFyeSBldmVudCBhdHRyaWJ1dGUg dG8gYWxsZXZpYXRlIHlvdXIgY29uY2VybiwgYnV0IHRoaXMgd2FzIG5vdCBhY2NlcHRlZC4gU2Vl Ojxicj4NCjxicj4NCio8c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0 ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWwtMkRh cmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRfbXNnMDA0MDYuaHRtbCZhbXA7ZD1Ed01GYVEm YW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1u YTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPVlCQ0dsSzlt ampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmYW1wO3M9UzNzTVZpcU12RWdud0di SndPUU55Y3JPeXI3U2VmcHFfTW9GT0tjRWVDRSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2lkLWV2ZW50L2N1cnJlbnQvbXNnMDA0MDYuaHRtbDwvc3Bhbj48L2E+PGJyPg0KPGJyPg0K KjxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFt Njk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbC0yRGFyY2hpdmVfd2ViX2lk LTJEZXZlbnRfY3VycmVudF9tc2cwMDE0MC5odG1sJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVt Q1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFX Tnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209WUJDR2xLOW1qamhjRnNqLTJ0RGtu MzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZhbXA7cz1HeTlneVJvSUl0YS1jU2hWN2JOMTYxYXk0eUU2 cjlHMV9BYV9OZUJueWxnJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQv Y3VycmVudC9tc2cwMDE0MC5odG1sPC9zcGFuPjwvYT48YnI+DQo8YnI+DQpUaGUgY29uc2Vuc3Vz LCBhdCBsZWFzdCBhcyBJIGludGVycHJldGVkIGl0IGlzIHVwIHRvIHRoZSByZWNlaXZlciB0byBm aWd1cmUgdGhpcyBvdXQgYmFzZWQgb24gdGhlIGRlZmluaXRpb25zIGl0IGhhcyBmb3IgZWFjaCBl dmVudCBVUkkgYW5kIHRoZSBwcm9maWxlcyB0aGV5IHJlcHJlc2VudC4gSU9XIC0gUklTQyBpcyBm cmVlIHRvIGxpbWl0IHRoYXQgb25seSBvbmUgUklTQyBldmVudCBiZSBleHByZXNzZWQgYXQgYSB0 aW1lLjxicj4NCjxicj4NClBoaWw8YnI+DQo8YnI+DQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50 aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdDxicj4NCjxicj4NCkBpbmRlcGVuZGVudGlkPGJy Pg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNvbSZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdt YW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPVlCQ0dsSzltampoY0Zzai0y dERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmYW1wO3M9OU5QNW5hbWc2cklWend1bjljLTFxMHdo c3lYd1N2dEhCMGYyZEtrZkNYOCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L3NwYW4+PC9hPjxzcGFuIGNsYXNz PSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0 NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5jb20mYW1wO2Q9RHdNRmFRJmFtcDtjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRX bWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1ZQkNHbEs5bWpqaGNGc2ot MnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtzPTlOUDVuYW1nNnJJVnp3dW45Yy0xcTB3 aHN5WHdTdnRIQjBmMmRLa2ZDWDgmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbTwvc3Bhbj48L2E+Jmd0 Ozxicj4NCjxicj4NCjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29t PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYx NDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7IE9uIE9jdCAyMywgMjAxNywgYXQgNzowMiBQTSwgUmljaGFyZCBCYWNrbWFuLCBB bm5hYmVsbGU8YnI+DQombmJzcDsgJm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFA YW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJp Y2hhbm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMy MDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2 MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPiZndDsm Z3Q7DQogd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgY3VycmVudCBkcmFmdCBv ZiB0aGUgU0VUIHNwZWMgYWxsb3dzIGZvciBleHByZXNzaW5nIG11bHRpcGxlPGJyPg0KJm5ic3A7 ICZuYnNwOyBldmVudHMgd2l0aGluIHRoZSBzYW1lIHRva2VuLCB3aGljaCBpbnRyb2R1Y2VzIGFk ZGl0aW9uYWwgY29tcGxleGl0eTxicj4NCiZuYnNwOyAmbmJzcDsgYW5kIHJvb20gZm9yIGFtYmln dW91cyBzZW1hbnRpY3MuIFdl4oCZdmUgZGlzY3Vzc2VkIHRoaXMgaW4gdGhlIE9JREY8YnI+DQom bmJzcDsgJm5ic3A7IFJJU0Mgd29ya2luZyBncm91cCBhbmQgdGhlIGN1cnJlbnQgY29uc2Vuc3Vz IHRoZXJlIGlzIHRoYXQgUklTQyB3aWxsPGJyPg0KJm5ic3A7ICZuYnNwOyByZXF1aXJlIHRoYXQg UklTQyBldmVudHMgbXVzdCBiZSB0aGUgb25seSBldmVudCBpbiB0aGUgU0VULCBoYXZpbmc8YnI+ DQombmJzcDsgJm5ic3A7IGlkZW50aWZpZWQgd2F5cyB0byBjbGVhcmx5IGFuZCBlYXNpbHkgc3Vw cG9ydCB0aGUgaGFuZGZ1bCBvZiB1c2U8YnI+DQombmJzcDsgJm5ic3A7IGNhc2VzIGZvciBtdWx0 aXBsZSBldmVudHMgcGVyIHRva2VuIHRoYXQgcGVvcGxlIGhhdmUgcmFpc2VkLiBXaXRoPGJyPg0K Jm5ic3A7ICZuYnNwOyB0aGF0IGNvbnRleHQgaW4gbWluZCwgSSBwcm9wb3NlIHN0cmlraW5nIHRo ZSBkZWZpbml0aW9uIG9mIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsg4oCcZXZlbnRz4oCdIGNsYWlt IGZyb20gdGhlIFNlY3VyaXR5IEV2ZW50IFRva2VuIHNwZWMsIGFuZCByZXBsYWNpbmcgaXQ8YnI+ DQombmJzcDsgJm5ic3A7IHdpdGggdGhlIGZvbGxvd2luZyBkZWZpbml0aW9uIGZvciBhbiDigJxl dmVudOKAnSBjbGFpbSAoc2luZ3VsYXIpOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgZXZlbnQ8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEEgSlNPTiBvYmplY3QgY29udGFpbmluZyBhbiAmcXVv dDtldmVudF90eXBlJnF1b3Q7IG1lbWJlciB3aG9zZSB2YWx1ZSBpcyBhIFVSSTxicj4NCiZuYnNw OyAmbmJzcDsgcmVwcmVzZW50aW5nIGEgdHlwZSBvZiBldmVudCBkZWZpbmVkIGluIGEgUHJvZmls aW5nIFNwZWNpZmljYXRpb24uPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgb2JqZWN0IE1BWSBvdGhl cndpc2UgYmUgZW1wdHksIG9yIE1BWSBjb250YWluIGFkZGl0aW9uYWwgbWVtYmVyczxicj4NCiZu YnNwOyAmbmJzcDsgYXMgZGVzY3JpYmVkIGJ5IHRoZSBQcm9maWxpbmcgU3BlY2lmaWNhdGlvbi48 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEhlcmUgaXMgdGhlIGV4YW1wbGUgU0VUIGZyb20gc2Vj dGlvbiAyLjMsIHJld3JpdHRlbiB3aXRoIHRoaXMgY2hhbmdlPGJyPg0KJm5ic3A7ICZuYnNwOyBt aW5kOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODcz MjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1 NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPns8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmcXVvdDtqdGkmcXVvdDs6ICZxdW90OzRkMzU1 OWVjNjc1MDRhYWJhNjVkNDBiMDM2M2ZhYWQ4JnF1b3Q7LDxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7Jm5ic3A7ICZxdW90O2lhdCZxdW90OzogMTQ1ODQ5NjQwNCw8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZxdW90O2lzcyZxdW90OzogJnF1b3Q7PGEgaHJlZj0i aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbTwvc3Bhbj48L2E+PHNwYW4gY2xh c3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgw MjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj4mbHQ7PGEgaHJlZj0iaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vc2NpbS5leGFtcGxlLmNv bS88L3NwYW4+PC9hPiZndDsmcXVvdDssPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsm bmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiBbPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29t L0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NjaW0uZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0 NjFmYTViYmM4Nzk1OTNiNzc1NDwvc3Bhbj48L2E+JnF1b3Q7LDxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2Np bS5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3IiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29t L0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTc8L3NwYW4+PC9hPiZxdW90Ozxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IF0sPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsmbmJzcDsgJnF1b3Q7ZXZlbnQmcXVvdDs6IHs8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtldmVudF90eXBlJnF1b3Q7OiAmcXVv dDt1cm46aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpjcmVhdGUmcXVvdDssPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7cmVmJnF1b3Q7OiAmcXVv dDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZh YjYxZTc1MjFkOSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0 dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9Vc2Vycy80NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5PC9z cGFuPjwvYT4mcXVvdDssPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJnF1b3Q7YXR0cmlidXRlcyZxdW90OzogWyZxdW90O2lkJnF1b3Q7LCAmcXVvdDtu YW1lJnF1b3Q7LCAmcXVvdDt1c2VyTmFtZSZxdW90OywgJnF1b3Q7cGFzc3dvcmQmcXVvdDssICZx dW90O2VtYWlscyZxdW90O108YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyB9 PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyB9PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBEb2Vz IGFueW9uZSBpbiB0aGUgd29ya2luZyBncm91cCBoYXZlIHVzZSBjYXNlcyBmb3IgU0VUcyB0aGF0 IGNhbm5vdDxicj4NCiZuYnNwOyAmbmJzcDsgYmUgbWV0IGJ5IHRoaXMgcHJvcG9zZWQgdGV4dD8g V2l0aGluIFJJU0MsIHdlIGlkZW50aWZpZWQgdGhyZWUgdXNlPGJyPg0KJm5ic3A7ICZuYnNwOyBj YXNlcywgd2l0aCBzb2x1dGlvbnMgb3V0bGluZWQgYmVsb3c6PGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyAqKjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgKkV4dGVuc2lvbnMqPGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyBFdmVudCBleHRlbnNpb24gbWVjaGFuaXNtcyBjYW4gYmUgZGVmaW5lZCBp bnRlcm5hbCB0byB0aGUgZXZlbnQ8YnI+DQombmJzcDsgJm5ic3A7IG9iamVjdC4gQSBzaW1wbGUg YXBwcm9hY2ggd291bGQgYmUgdG8gJm5ic3A7ZGVmaW5lIGFuIOKAnGV4dGVuc2lvbnPigJ0gbWVt YmVyPGJyPg0KJm5ic3A7ICZuYnNwOyB0aGF0IGlzIGEgbGlzdCBvZiBldmVudCBvYmplY3RzIChv ciBzZXQgcmVzZW1ibGluZyB0aGUg4oCcZXZlbnRz4oCdPGJyPg0KJm5ic3A7ICZuYnNwOyBjbGFp bSBhcyBkZWZpbmVkIGluIHRoZSBjdXJyZW50IHNwZWMpLiBUaGlzIGhhcyB0aGUgYWR2YW50YWdl IG9mPGJyPg0KJm5ic3A7ICZuYnNwOyBtYWtpbmcgaXQgY2xlYXIgaW4gdGhlIGRhdGEgc3RydWN0 dXJlIHRoYXQgdGhlcmUgaXMgYSBzaW5nbGUgcHJpbWFyeTxicj4NCiZuYnNwOyAmbmJzcDsgZXZl bnQsIHdpdGggemVybyBvciBtb3JlIGV4dGVuc2lvbnMuIFRoZXJlIGlzIG5vIHJvb20gZm9yIGNv bmZ1c2lvbjxicj4NCiZuYnNwOyAmbmJzcDsgb3ZlciB3aGljaCBldmVudCBpcyBwcmltYXJ5LCBv ciBpZiB0aGVyZSBpcyBhIHByaW1hcnkgZXZlbnQgYXQgYWxsLjxicj4NCiZuYnNwOyAmbmJzcDsg SSB3b3VsZCBiZSBmaW5lIHdpdGggYWRkaW5nIHNvbWV0aGluZyBsaWtlIHRoaXMgdG8gbXkgcHJv cG9zZWQgdGV4dCw8YnI+DQombmJzcDsgJm5ic3A7IGlmIHRoZXJlIGlzIGNvbnNlbnN1cyB0aGF0 IGl0IGlzIGJyb2FkbHkgdXNlZnVsLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgKkFsaWFzZXMq PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGlzIHVzZSBjYXNlIHdhcyBicm91Z2h0IHVwIGlu IHRoZSBjb250ZXh0IG9mIG1pZ3JhdGluZyBjbGllbnRzPGJyPg0KJm5ic3A7ICZuYnNwOyBmcm9t IGRyYWZ0IGV2ZW50IG5hbWVzIHRvIHN0YW5kYXJkaXplZCBldmVudCBuYW1lcy4gSW4gdGhpcyBj YXNlLDxicj4NCiZuYnNwOyAmbmJzcDsgdGhlIGV2ZW50IHRyYW5zbWl0dGVyIGNhbiB0cmFuc21p dCB0d28gdG9rZW5zIGZvciB0aGUgbG9naWNhbCBldmVudCw8YnI+DQombmJzcDsgJm5ic3A7IG9u ZSB1c2luZyB0aGUgb2xkIG5hbWUgYW5kIGFub3RoZXIgdXNpbmcgdGhlIG5ldyBuYW1lLjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgKlJlbGF0ZWQgRXZlbnRzKjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgVGhlIFNFVCBzcGVjIGRlZmluZXMgdGhlIHR4biBjbGFpbSBhcyBhIG1lYW5zIG9mIGNv cnJlbGF0aW5nPGJyPg0KJm5ic3A7ICZuYnNwOyBpbmRlcGVuZGVudCB0b2tlbnMgdGhhdCByZWxh dGUgdG8gdGhlIHNhbWUgbG9naWNhbCBldmVudC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IC0t PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02 OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnI+DQombmJzcDsgJm5ic3A7IEFubmFiZWxsZSBSaWNoYXJkIEJh Y2ttYW48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEFtYXpvbiDigJMgSWRlbnRpdHkgU2Vydmlj ZXM8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyBJZC1ldmVudCBtYWlsaW5nIGxp c3Q8YnI+DQombmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0t NTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2 NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQt ZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3 MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0 NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJy Pg0KJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4 NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1h bl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4 UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209czVieUJlNUtBTm5HVnVBYjFtQXVwRUdvSm44WEc1 SklVVXdXR0ZTaWJFYyZhbXA7cz1YOG9SU3EzSXpsRjdqaVJBZVpoWHBSM2VWSTBJNThaRmQ0ZUVa Zmd5b0lZJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9 Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlS ckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPXM1YnlCZTVLQU5uR1Z1 QWIxbUF1cEVHb0puOFhHNUpJVVV3V0dGU2liRWMmYW1wO3M9WDhvUlNxM0l6bEY3amlSQWVaaFhw UjNlVkkwSTU4WkZkNGVFWmZneW9JWSZhbXA7ZT08L3NwYW4+PC9hPjxicj4NCjxicj4NCjxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZl bnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQ Wmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlx UGtBSTFhTGNMTjRLWk5BJmFtcDttPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FU a1JsUUcxaXcmYW1wO3M9V3JNdVFSd0xWODAyaU1RNHdZQjFmMnJGVUd1NHpiaGNXMDAxZkswMkVY cyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFuPjwvYT48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwv c3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2 ZW50JmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2 NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEta TkEmYW1wO209WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZhbXA7 cz1Xck11UVJ3TFY4MDJpTVE0d1lCMWYyckZVR3U0emJoY1cwMDFmSzAyRVhzJmFtcDtlPSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGJy IGNsZWFyPSJhbGwiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+LS08c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEw MjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlN1YnNj cmliZSB0byB0aGU8c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYx NDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZhbXA7ZD1Ed01G YVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7 cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPVlCQ0ds SzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmYW1wO3M9TFlONzJHZ0tWaEhz VDZ0QXFCZS1lTW9XTXZ5XzdkZkZuMXVaMEhLNll1USZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5IQVJEVFdBUkU8L3NwYW4+PC9hPjxzcGFuIGNsYXNz PSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0 NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+bWFpbA0KIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9u ITwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxp c3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3Jn PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVt Q1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFX Tnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209WUJDR2xLOW1qamhjRnNqLTJ0RGtu MzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZhbXA7cz1Xck11UVJ3TFY4MDJpTVE0d1lCMWYyckZVR3U0 emJoY1cwMDFmSzAyRVhzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6cHVycGxlIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9 RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUm YW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1Z QkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtzPVdyTXVRUndM VjgwMmlNUTR3WUIxZjJyRlVHdTR6YmhjVzAwMWZLMDJFWHMmYW1wO2U9PC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtiYWNrZ3JvdW5kOndoaXRlIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8 c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SWQtZXZlbnQgbWFpbGluZyBsaXN0PC9zcGFu Pjxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj5J ZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpo OEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBr QUkxYUxjTE40S1pOQSZhbXA7bT1VLWE1SEJORDBIYVRYNGFuTlpmelg3cERzZks1ZjBoOW1aOUNa a2tHaWVjJmFtcDtzPXJ2ZHJ0STdyWU5SQW5xWkRsdEN3QkFaVkhLcC1NSjIwdWkybm00NlFTejAm YW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGU7YmFj a2dyb3VuZDp3aGl0ZSI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtk PUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5F JmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209 VS1hNUhCTkQwSGFUWDRhbk5aZnpYN3BEc2ZLNWYwaDltWjlDWmtrR2llYyZhbXA7cz1ydmRydEk3 cllOUkFucVpEbHRDd0JBWlZIS3AtTUoyMHVpMm5tNDZRU3owJmFtcDtlPTwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyIGNsZWFyPSJh bGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLQ0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlN1YnNjcmliZSB0byB0aGUNCjxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29t XyZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVl YXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5B JmFtcDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmYW1wO3M9 d3RnRDNOcDB2eWhMZHBFd1VpcXNmNEl0aXdBM09tN0dyb2I3MEx4MHIzayZhbXA7ZT0iIHRhcmdl dD0iX2JsYW5rIj4NCkhBUkRUV0FSRTwvYT4gbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2pl Y3RzIEkgYW0gd29ya2luZyBvbiE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZl bnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19p ZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdx SXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFM Y0xONEtaTkEmYW1wO209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0Nf dyZhbXA7cz1PZTBxZkxFWDgzdnRYTTdXbDJjWUJlLUdnMURWUGpoWGpWSmtmaFZSendjJmFtcDtl PSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZh bXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJ X0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFt cDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmYW1wO3M9T2Uw cWZMRVg4M3Z0WE03V2wyY1lCZS1HZzFEVlBqaFhqVkprZmhWUnp3YyZhbXA7ZT08L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4tLQ0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlN1YnNjcmliZSB0 byB0aGUNCjxhIGhyZWY9Imh0dHA6Ly9oYXJkdHdhcmUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPkhB UkRUV0FSRTwvYT4gbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2lu ZyBvbiE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyIGNsZWFy PSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLQ0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlN1YnNjcmliZSB0byB0aGUNCjxhIGhyZWY9Imh0dHA6 Ly9oYXJkdHdhcmUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPkhBUkRUV0FSRTwvYT4gbWFpbCBsaXN0 IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiE8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1YnNj cmliZSB0byB0aGUgPGEgaHJlZj0iaHR0cDovL2hhcmR0d2FyZS5jb20vIiB0YXJnZXQ9Il9ibGFu ayI+DQpIQVJEVFdBUkU8L2E+IG1haWwgbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFt IHdvcmtpbmcgb24hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6DF29D13F11E4140BB39A88A4FD0B335amazoncom_-- From nobody Wed Nov 1 12:45:25 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB9513F595 for ; Wed, 1 Nov 2017 12:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOBFmKFD5LTl for ; Wed, 1 Nov 2017 12:45:19 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 AE47613FE91 for ; Wed, 1 Nov 2017 12:45:18 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA1JjEqd023259 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Nov 2017 19:45:14 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA1JjDsT014428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Nov 2017 19:45:13 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vA1JjCXC031759; Wed, 1 Nov 2017 19:45:12 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 12:45:10 -0700 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B8486D94-C6FA-41CE-AB10-3AE14293DB46" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 1 Nov 2017 12:45:08 -0700 In-Reply-To: <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> Cc: Mike Jones , Dick Hardt , Yaron Sheffer , ID Events Mailing List To: "Richard Backman, Annabelle" References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 19:45:24 -0000 --Apple-Mail=_B8486D94-C6FA-41CE-AB10-3AE14293DB46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You can=E2=80=99t really have multiple events (at least of the same = type). The current spec can only have one instance of a URI (afaik). =20= Note that the spec normatively does not support multiple event SETS. It = currently states: > events > The semantics of this claim is to define a set of event = statements > that each MAY add additional claims to fully describe a single > logical event that has occurred (e.g. a state change to a > subject). Multiple event statements of the same type SHALL NOT = be > accepted. The "events" claim SHOULD NOT be used to express > multiple logical events. The spec has *always* supported requirements (as stated in the spec) for = multiple separate profile statements (from one or more profile = familities) needing to be sent as a single message. It would be = INSECURE to force multiple SETs because the current delivery mechanism = only allows one SET to be delivered at a time. There is no way to assure = that a single receiver gets all of the SETs it needs in a = multi-threaded, multi-node environment at scale. Assembling multiple = SETs to track =E2=80=9Ctxn=E2=80=9D in a common state database is NOT = simple nor cost effective. =20 If we accommodate this in the proposed form, we end up with a complex, = deeply nested JSON structure with the possibility of namespace = conflicts. IMO The proposal does not simplify, it complicating and limiting. =20 The current spec has very clean JSON and avoids namespace conflicts = between profiles. I think we should stay on track with the current draft = and observe the normative text if not make it stronger in regards to = multi-events (understood that Mike may disagree). Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Nov 1, 2017, at 12:18 PM, Richard Backman, Annabelle = wrote: >=20 > Unless the profile guarantees that such related events will always be = included in the same SET, then the receiver has to correlate across SETs = anyway, and multiple events per SET is just giving the receiver another = scenario that they have to support. > =20 > I=E2=80=99ve already provided several other reasons why we should not = support multiple tokens per SET that no one has addressed. Here they are = again: > Multiple event support results in a more complex structure for the = single event use case, which I think we all agree is the majority use = case. > Multiple-event SETs have ambiguous semantics. The presence of two = events A and B in the same SET could mean any of: > A and B are related to the same logical event (i.e. the same thing as = if they were from different SETs that have a common txn). > A is an extension of B. > B is an extension of A. > A is an alias for B, or vice-versa. > A and B are not actually related to one another in any way, and the = transmitter bundled them together because they were going to the same = receiver. > Top-level claim semantics become harder to define, as different = profiles may want to use the same claims in different ways. > Event authenticity cannot be verified without having the entire SET. = This forces receivers to expose downstream systems to more information = necessary, if those systems need to be able to verify authenticity. > =20 > --=20 > Annabelle Richard Backman > Amazon =E2=80=93 Identity Services > =20 > =20 > From: Mike Jones > Date: Wednesday, November 1, 2017 at 11:21 AM > To: Dick Hardt > Cc: Yaron Sheffer , "Richard Backman, = Annabelle" , ID Events Mailing List = , "Phil Hunt (IDM)" > Subject: RE: [Id-event] Use cases for multiple events per SET? > =20 > I completely agree on moving complexity to the issuer over the = recipient. In my view, it=E2=80=99s more complex for recipients to have = to correlate and process a sequence of multiple SETs providing = information about the same logical event, and validate N signatures, = than to receive one SET with all the aspects of the logical event as = =E2=80=9Cevents=E2=80=9D fields, with no correlation over time then = required. > =20 > -- Mike > =C2=A0 <> > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Wednesday, November 1, 2017 9:39 AM > To: Mike Jones > Cc: Yaron Sheffer ; Richard Backman, Annabelle = ; ID Events Mailing List ; Phil = Hunt (IDM) > Subject: Re: [Id-event] Use cases for multiple events per SET? > =20 > Your comments highlight a couple of points: > =20 > 1) The example is how to have a predefined extension point for = extensions of a specific event, it is not how to add another event. = Myself, I think this is overly complicated. Events should be = comparatively static, and as with many other JSON formats, the receiver = should ignore properties it does not understand, which let's new = properties be introduced as extensions. There should not be any conflict = as extensions should only be done by the profile that created the event = format to start off with. > =20 > 2) Having an lvalue be a URI is much harder to code against. I'm not = sure why Marius had that in his example. Per the event, the type of the = event is well defined with=20 > =20 > "event_type": "https://example.com/scim/event/passwordResetExt = ", > =20 > 3) This thread is about reasons for multiple events to be contained in = one set. Your mention of an issuer not wanting to sign separate events = as a reason to allow multiple events. I think we have decided that given = a preference, we will push effort to the transmitter over the receiver = as in many use cases there are many more receivers. Given that, it is = more complex for a receiver to have different ways of managing the = receipt of multiple events as not all issuers will bundle the events, so = it is simpler to have only one event per SET. Including the separate = events with a URI as an lvalue is challenging to implement, speaking = from experience. > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones = > = wrote: >> Marius=E2=80=99 proposed syntax, pasted in below, has exactly this = characteristic. The way I see it, his proposal essentially has a = primary passwordReset event and a secondary passwordResetExt data = structure, which could have been simply another event value in the = current draft. >> =20 >> This breaking change makes the data structures more complicated - not = less. And it makes things that used to be possible impossible, reducing = flexibility to those who would use the spec. >> =20 >> These seem like bad tradeoffs to me. >> =20 >> { >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "iat": 1458496025, >> "iss": "https://scim.example.com ", >> "aud": [ >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 = ", >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 = " >> ], >> "event_type": "https://example.com/scim/event/passwordResetExt = ", >> "event": { =20 >> "id":"44f6142df96bd6ab61e7521d9", >> "extensions": { >> "https://example.com/scim/event/passwordResetExt = =E2=80=9D: { >> "resetAttempts":5, >> } >> } >> } >> } >> =20 >> In particular, it makes it impossible to sign multiple related events = sharing a common claims schema with a single signature by the issuer. = It forces the issuer to do the extra work of signing each of the related = events (or facets of the same logical event) individually and forces the = recipients to do the extra work of checking all those unnecessary = signatures. >> =20 >> Not every profile will ever have multiple keys in the =E2=80=9Cevents=E2= =80=9D set but there=E2=80=99s absolutely no reason to preclude it. >> =20 >> -- Mike >> =C2=A0 <> >> From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Dick Hardt >> Sent: Tuesday, October 31, 2017 9:52 PM >> To: Mike Jones > >> Cc: Yaron Sheffer >; Richard Backman, Annabelle = >; ID Events Mailing = List >; Phil Hunt (IDM) = > >>=20 >> Subject: Re: [Id-event] Use cases for multiple events per SET? >> =20 >> Please direct me to a proposal that has a "primary" and "secondary" = events. I agree that is undesirable. I would also encourage to engage in = the discussions so that we can drive clarity and simplicity. >> =20 >> I think the proposal is that there is one event per SET. >> =20 >> I think having more than one event per SET adds complexity as a = receiver must deal with receiving correlated events in one SET as well = as correlated events in the same SET. >> =20 >> /Dick >> =20 >> On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones = > = wrote: >>> I hear you on the fact that different people have joined the effort = at different times. That=E2=80=99s a normal process as an effort builds = momentum. I get that not everyone was there when previous consensus = calls were taken. >>> =20 >>> I should note that I have specific technical objections to the = specific proposed changes being discussed as well. Currently all events = in the set have the same syntax. The proposals, as I understand them, = revert us to a state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D = and =E2=80=9Csecondary=E2=80=9D events, with different syntax for the = two classes. That=E2=80=99s needlessly more complicated, adding no = actual value. >>> =20 >>> -- = Mike >>> =20 >>> From: Dick Hardt [mailto:dick.hardt@gmail.com = ]=20 >>> Sent: Tuesday, October 31, 2017 9:37 PM >>> To: Mike Jones > >>> Cc: Phil Hunt (IDM) >; Yaron Sheffer >; Richard Backman, Annabelle = >; ID Events Mailing = List > >>>=20 >>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>> =20 >>> Mike >>> =20 >>> As you well know, many people in a WG don't look closely at a = specification until last call is made. Additionally, we are coming up on = only the 3rd WG meeting. The WG has not existed for very long. While = some of the participants have been working on this for a while, many = have not, and we are looking for consensus across the WG. >>> =20 >>> Since SecEvent is a framework that we expect to be profiled, I feel = it is important to ensure that SecEvent specifications are easy for a = variety of profiles to adopt, and that the semantics make sense. I also = think that properties that are specific to a profile should be left to = that profile and not be included in SecEvent. >>> =20 >>> Since this is a framework, it is expected that as different groups = profile it, there will be additional feedback. >>> =20 >>> Specifically, as a participant in the RISC profile of SET, a number = of issues in SET have surfaced as the RISC WG has looked at how to use = the SET. >>> =20 >>> As for SET being stable for over a year, there have been a number of = changes to SET since then. I also don't think there was consensus. = Before the WG was formed, I and several others had expressed concern on = the design of SET when Phil presented it at an IIW session. >>> =20 >>> As to taking another year, I am hopeful we can resolve the remaining = issues in SET and publish a new draft for last call. I do not think we = will need to wait for another WG meeting to ask for last call.=20 >>> =20 >>> We also have a number of other documents that are not in last call, = and we don't have a WG adopted draft yet for management. So there are = still a number of documents to work through before we have all the bits = for someone to work with. >>> =20 >>> I do think we have been making good progress since the last IETF = meeting, and I am hopeful we can keep up this momentum and finalize all = the documents in a timely manner. >>> =20 >>> /Dick >>> =20 >>> =20 >>> On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones = > = wrote: >>>> It=E2=80=99s hard for me to even express my level of frustration = with the recent attempts to once again redesign the SecEvent Token spec. = We=E2=80=99ve been at this for multiple years because people keep = trying to revisit decisions that were long ago made by consensus. = It=E2=80=99s been stable for over a year and the majority of WGLC = respondents said some variant of =E2=80=9CWorks for me =E2=80=93 ship = it!=E2=80=9D >>>> =20 >>>> There=E2=80=99s not sufficient justification to try to undo = consensus positions that have been debated and affirmed over and over. = Countenancing wholesale changes at this late date is counterproductive = in the extreme! >>>> =20 >>>> It=E2=80=99s far better than good enough as-is. In my experience, = if we start redesigning it, it will result in another year=E2=80=99s = delay. It does something simple and useful. Please, let=E2=80=99s just = ship it, so people can rely on it. >>>> =20 >>>> -- Mike >>>> =C2=A0 <> >>>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com = ]=20 >>>> Sent: Monday, October 30, 2017 2:42 PM >>>> To: Dick Hardt > >>>> Cc: Yaron Sheffer >; Richard Backman, Annabelle = >; Mike Jones = >; ID = Events Mailing List > >>>>=20 >>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>> =20 >>>> Inline... >>>>=20 >>>> Phil >>>>=20 >>>> On Oct 30, 2017, at 2:22 PM, Dick Hardt > wrote: >>>>=20 >>>>> Hi Phil >>>>> =20 >>>>> Correct me if I am misunderstanding, but there is a RISC profile = event=20 >>>>> =20 >>>>> "http://schemas.openid.net/secevent/risc/event-type/ = account-credential-change-required=E2=80=9D >>>>> =20 >>>>> and an SCIM profile event >>>>> =20 >>>>> "https://example.com/scim/event/passwordResetExt = =E2=80=9D >>>>> =20 >>>>> I'm suggesting that two different events would be sent. Embedding = one in the other does not make sense. >>>> It is a hypothetical example. Just because you disagree on this = does not mean others are not valid.=20 >>>> =20 >>>> I just picked overlapping proposals that have different meaning = (but not the same) to illustrate the difference from issuing a single = set with different events.=20 >>>> =20 >>>> As I have stated this is very different from asserting multiple = distinct events in one SET.=20 >>>>=20 >>>>> =20 >>>>> Also, I think it is simpler to have event_type be at the same = level as event >>>> =20 >>>> may be. I was working from Annabelle's proposed format.=20 >>>>=20 >>>>> =20 >>>>> { >>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>> "iat": 1458496025, >>>>> "iss": "https://scim.example.com ", >>>>> "aud": [ >>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 = ", >>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 = " >>>>> ], >>>>> "event_type": "https://example.com/scim/event/passwordResetExt = ", >>>>> "event": { =20 >>>>> "id":"44f6142df96bd6ab61e7521d9", >>>>> "resetAttempts":5 >>>>> } >>>>> } >>>>> =20 >>>>> { >>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>> "iat": 1458496025, >>>>> "iss": "https://scim.example.com ", >>>>> "aud": [ >>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 = ", >>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 = " >>>>> ], >>>>> "event_type": = "http://schemas.openid.net/secevent/risc/event-type/account-credential-cha= nge-required = ", >>>>> "event": { >>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/ = " =20 >>>>> } >>>>> } >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt > wrote: >>>>>> Annabelle/Dick, >>>>>> =20 >>>>>> Thanks for the comments. I think we need to examine the = consequences of the proposal in JSON. >>>>>> =20 >>>>>> As I stated, what causes most of the issue is the proposed = extension mechanism in the payload (possibly using events in a recursive = way). Does it follow the old format or the new? >>>>>> =20 >>>>>> Let=E2=80=99s consider a use case where we have an identity = management system that uses SCIM, but the SCIM system is also the = underlying data store for Connect. A Password reset might generate the = following event which has an extension (conveying reset count) AND = overlapping statement from RISC. BOTH of which might be important to a = similar receiver using SCIM and OIDC. =20 >>>>>> =20 >>>>>> The 03 spec currently would allow: >>>>>> =20 >>>>>> { >>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>> "iat": 1458496025, >>>>>> "iss": "https://scim.example.com ", >>>>>> "aud": [ >>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 = ", >>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 = " >>>>>> ], >>>>>> "events": { >>>>>> "urn:ietf:params:scim:event:passwordReset": >>>>>> { "id":"44f6142df96bd6ab61e7521d9"}, >>>>>> "https://example.com/scim/event/passwordResetExt = ": >>>>>> { "resetAttempts":5}, >>>>>> "http://schemas.openid.net/secevent/risc/event-type/\ = >>>>>> account-credential-change-required": { >>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/ = " >>>>>> } >>>>>> } >>>>>> } >>>>>> =20 >>>>>> In the above - each payload is a =E2=80=98peer' and issued = without preference by the transmitter. The receiver can assign priority = in its own context if that matters. >>>>>> =20 >>>>>> The new proposal: >>>>>> =20 >>>>>> { >>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>> "iat": 1458496025, >>>>>> "iss": "https://scim.example.com ", >>>>>> "aud": [ >>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 = ", >>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 = " >>>>>> ], >>>>>> "event": { >>>>>> = =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passwordReset=E2=80= =9D, >>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>> ->note =E2=80=A6is this the old or new structure? <- >>>>>> "https://example.com/scim/event/passwordResetExt = ": >>>>>> { "resetAttempts":5}, >>>>>> "http://schemas.openid.net/secevent/risc/event-type/\ = >>>>>> account-credential-change-required": { >>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/ = " >>>>>> } >>>>>> } >>>>>> } =20 >>>>>> } >>>>>> =20 >>>>>> In the above, sub-events or extensions have a different format. = The same complaint about the original stands. >>>>>> =20 >>>>>> *OR* (if the receiver cares about RISC more). Note that this = leads to a triple nested structure. >>>>>> =20 >>>>>> { >>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>> "iat": 1458496025, >>>>>> "iss": "https://scim.example.com ", >>>>>> "aud": [ >>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 = ", >>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 = " >>>>>> ], >>>>>> "event": { >>>>>> = =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/risc/even= t-type/\ = >>>>>> account-credential-change-required=E2=80=9D, >>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C = , >>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>> "urn:ietf:params:scim:event:passwordReset": >>>>>> {=20 >>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>> "https://example.com/scim/event/passwordResetExt = ": >>>>>> { "resetAttempts":5}, =20 >>>>>> } =20 >>>>>> } >>>>>> } =20 >>>>>> } >>>>>> } >>>>>> =20 >>>>>> In the above, the extension is placed inside the event it = extends. It follows the old format (or should it follow the new?) >>>>>> *OR* Following the top layer pattern of singular event Note that = this leads to a triple nested structure. >>>>>> =20 >>>>>> { >>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>> "iat": 1458496025, >>>>>> "iss": "https://scim.example.com ", >>>>>> "aud": [ >>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 = ", >>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 = " >>>>>> ], >>>>>> "event": { >>>>>> = =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/risc/even= t-type/\ = >>>>>> account-credential-change-required=E2=80=9D, >>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C = , >>>>>> =E2=80=9Cevent=E2=80=9D:{ >>>>>> = =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passwordReset=E2=80= =9D, >>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>> =E2=80=9Cevent=E2=80=9D:{ >>>>>> = =E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/event/passwordReset= Ext =E2=80=9D, >>>>>> "resetAttempts":5=20 >>>>>> } >>>>>> } =20 >>>>>> } >>>>>> } >>>>>> =20 >>>>>> This format follows the proposed singular event format = recursively and is 3 layers deep. Note that the parser has to continue = to search the document for things that aren=E2=80=99t there as it has to = stop when no =E2=80=9Cevent=E2=80=9D attribute is found rather than = iterate over an array. >>>>>> =20 >>>>>> Phil >>>>>>=20 >>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>> @independentid >>>>>> www.independentid.com = >>>>>> phil.hunt@oracle.com >>>>>> =20 >>>>>>> On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle = > wrote: >>>>>>> =20 >>>>>>> Replies inline. >>>>>>> =20 >>>>>>> --=20 >>>>>>> Annabelle Richard Backman >>>>>>> Identity Services >>>>>>> =20 >>>>>>> =20 >>>>>>> From: Phil Hunt > >>>>>>> Date: Sunday, October 29, 2017 at 5:25 PM >>>>>>> To: Dick Hardt > >>>>>>> Cc: Yaron Sheffer >, Mike Jones >, "Richard Backman, Annabelle" = >, ID Events Mailing = List > >>>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>>> =20 >>>>>>> I hope this answers your question. >>>>>>> =20 >>>>>>> My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a = reason why not. The question should be, what is the justification to = make =E2=80=9Cevents=E2=80=9D singular? >>>>>>> [richanna]The singular =E2=80=9Cevent=E2=80=9D claim has clearer = semantics and is easier to process. We should opt for easier solutions = unless there are use cases that require more complexity.[/richanna] >>>>>>> =20 >>>>>>> There are many reasons for multiple events in a SET. Some are = good, some not so good. Some of the reasons... >>>>>>> =20 >>>>>>> 1. Multiple event payloads expressing statements about largely = the *same*thing. For example, SCIM password reset AND RISC password = reset. A RISC Event and an OpenBanking Event. Is one a complement to = the other? Do they overlap or are they distinct? =20 >>>>>>> [richanna]Copy/pasted from my earlier email: >>>>>>> Why is it necessary or appropriate to include these events in = the same SET? They are likely being generated by different systems at = different times on the transmitter=E2=80=99s side, consumed by different = systems on the receiver=E2=80=99s side, and possibly being transmitted = over different event streams. I know the latter would be the case for = us, as a receiver. Even if it=E2=80=99s not, is it burdensome to send = these events separately? What value is gained in combining them? >>>>>>> =20 >>>>>>> Additionally, since the signature is over the SET and not the = event objects, Receivers independently route separate events from a = single token without either losing the ability to verify the = authenticity of the event or sharing all information in the SET with = every system handling any event in the token.[/richanna] >>>>>>> =20 >>>>>>> 2. Multiple events payloads expressing different statements = about the same transaction - RISC Password Reset and RISC Session Cancel >>>>>>> [richanna]Same as above[/richanna] >>>>>>>=20 >>>>>>> 3. A new profile defines new event attributes to be added on to = an existing event type (a pure extension)=20 >>>>>>> [richanna]I have suggested a way to support extensions within an = event body, multiple times now. If you see problems with it, please = point them out.[/richanna] >>>>>>> =20 >>>>>>> I think it is quite valid to allow 1 and 3. 2 could be limited = by specific profiles like RISC if they want. >>>>>>> =20 >>>>>>> I am not in agreement that making event singular simplifies = anything. For one is makes extensions complex (another nested JSON = structure) and potentially conflicting.=20 >>>>>>> [richanna] >>>>>>> Ways that multiple-event SETs are more complicated: >>>>>>> It results in a more complex structure for the single event use = case, which I think we all agree is the majority use case. >>>>>>> Multiple-event SETs have ambiguous semantics. The presence of = two events A and B in the same SET could mean any of: >>>>>>> They are related to the same logical event (i.e. the same thing = as if they were from different SETs that have a common txn). >>>>>>> A is an extension of B. >>>>>>> B is an extension of A. >>>>>>> They are aliases for one another. >>>>>>> They are not actually related to one another in any way. >>>>>>> Claim semantics become harder to define, as different profiles = may want to use the same claims in different ways. >>>>>>> =20 >>>>>>> If the WG wants to block 1 and 2 above, then I believe we have = to establish an event registry to ensure new Event profiles do not = overlap to eliminate the need to express multiple events. >>>>>>> [richanna]I=E2=80=99m not sure what you mean by this. Are you = referring to event names? Those are already defined by the spec to be = URIs.[/richanna] >>>>>>> Phil >>>>>>> =20 >>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>> @independentid >>>>>>> www.independentid.com = >>>>>>> phil.hunt@oracle.com >>>>>>> =20 >>>>>>>> On Oct 29, 2017, at 4:12 PM, Dick Hardt > wrote: >>>>>>>> =20 >>>>>>>> Phil: >>>>>>>> =20 >>>>>>>> In your examples for having a plurality of events, you use the = word "may", which leads me to question if a plurality of events is = really required in SET. >>>>>>>> =20 >>>>>>>> You posit that it will be difficult for a distributed system to = correlate multiple SETs with the same "txn", but the distributed system = will certainly need to correlate events on the same subject -- = correlating events on the same "txn" on the same subject seems fairly = simple. >>>>>>>> =20 >>>>>>>> I think that a receiver will need to correlate multiple SEts on = the same subject, so having multiple events in a SET is redundant, and = adds complexity with no clear benefit that I can see. >>>>>>>> =20 >>>>>>>> An implementor may choose to send multiple SETs, or send a = single SET with multiple events, so a receiver will need to support = both. I prefer we pick one way and minimize the code paths, and we will = need to support correlating across multiple SETs, so that seems the best = mechanism. >>>>>>>> =20 >>>>>>>> Let me know if there is something I missed in my logic. >>>>>>>> =20 >>>>>>>> /Dick >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer = > wrote: >>>>>>>>> In that case, let's add text to that effect, e.g. we could add = to the definition of the "events" claim: >>>>>>>>>=20 >>>>>>>>> Profiling specifications SHOULD define the allowed event = statements, and MAY restrict their number. For example, some profiles = may require this claim to contain only a single event statement. >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Yaron >>>>>>>>>=20 >>>>>>>>> On 24/10/17 22:10, Mike Jones wrote: >>>>>>>>>> I agree with much of Phil=E2=80=99s rationale here. >>>>>>>>>>=20 >>>>>>>>>> It=E2=80=99s fine for some profiles to say that the = =E2=80=9Cevents=E2=80=9D set must be a singleton. That doesn=E2=80=99t = have to be true for all events. I think things are fine as-is. >>>>>>>>>>=20 >>>>>>>>>> = -- Mike >>>>>>>>>>=20 >>>>>>>>>> *From:* Id-event [mailto:id-event-bounces@ietf.org = ] *On Behalf Of *Phil Hunt >>>>>>>>>> *Sent:* Monday, October 23, 2017 8:47 PM >>>>>>>>>> *To:* Richard Backman, Annabelle > >>>>>>>>>> *Cc:* ID Events Mailing List > >>>>>>>>>> *Subject:* Re: [Id-event] Use cases for multiple events per = SET? >>>>>>>>>>=20 >>>>>>>>>> Annabelle, >>>>>>>>>>=20 >>>>>>>>>> I have a number of concerns with this proposal. >>>>>>>>>>=20 >>>>>>>>>> Profiling Independence / Keeping Event Payloads Independent >>>>>>>>>>=20 >>>>>>>>>> Indicating that extensions should be handled by profiles = leads to more inter-operability issues and more importantly intrudes on = the Event payload space by suggesting a sub-schema creates potential = limitations and conflicts that may add to complexity later on. The = current format allows a parser to discover and unload one or more JSON = payloads which can each have independent structure. >>>>>>>>>>=20 >>>>>>>>>> General extensions >>>>>>>>>>=20 >>>>>>>>>> The proposal also rules out general purpose extensions not = related to any specific event. Given the emergence of items like GPRD, I = would not want to block the ability to add meta-data or other general = purpose items. We can also anticipate some delivery scenarios where = additional data might be required. Even though there is no current = planned use, I see no good reason to rule this out. >>>>>>>>>>=20 >>>>>>>>>> Multiple Events =46rom Different Families (vs. Multiple = Events from a single family like RISC) >>>>>>>>>>=20 >>>>>>>>>> In our RISC session we discussed expressing multiple distinct = RISC events in one SET. The discussion was that only one RISC event at a = time. We did not discuss other event profiles. I don=E2=80=99t see a = reason to rule out multi-events from different families at the SET = level. Each profile is expressing slightly different things about the = same event. >>>>>>>>>>=20 >>>>>>>>>> I can forsee some cases where it is not clear which is the = primary and which is the extension. There may not be a clear winner. >>>>>>>>>>=20 >>>>>>>>>> A couple of examples (these are necessarily real=E2=80=A6just = possibilities): >>>>>>>>>>=20 >>>>>>>>>> * It is probably useful to be able to express = simlar/overlapping events from different SET profiles in one SET. For = example a Backchannel Logout & a RISC session cancel event. >>>>>>>>>>=20 >>>>>>>>>> * SCIM may want to represent a single transaction as causing = multiple state changes in an event (e.g. a password change causes = multiple effects). Having to chase down multiple events and correlate by = =E2=80=9Ctxn=E2=80=9D would be challenging in a = multi-threaded/multi-node delivery system. The SCIM list has not = discussed this, but I would not want to block this capability. IOW - = Just because RISC does not want to express multiple events does not make = this true for other profiles. >>>>>>>>>>=20 >>>>>>>>>> * We may wish to indicate a SCIM Password Reset was performed = and a Logout/session cancellation is expressed at the same time. The = events are related but express different data. >>>>>>>>>>=20 >>>>>>>>>> Avoiding Confusion =46rom Similar Events Originating from the = Same Transaction >>>>>>>>>>=20 >>>>>>>>>> If events are sent separately, then more tracking of state = (e.g. by txn) would be required to ensure similar events are not = mistaken or handled as repeats. While txn provides useful audit analysis = capability, I=E2=80=99m not sure it can be used in live or near-real = time systems given distributed multi-node, multi-threading = architectures. >>>>>>>>>>=20 >>>>>>>>>> Previous Discussion >>>>>>>>>>=20 >>>>>>>>>> I note that I originally raised having an attribute to = designate primary event attribute to alleviate your concern, but this = was not accepted. See: >>>>>>>>>>=20 >>>>>>>>>> * = https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html = >>>>>>>>>>=20 >>>>>>>>>> * = https://www.ietf.org/mail-archive/web/id-event/current/msg00140.html = >>>>>>>>>>=20 >>>>>>>>>> The consensus, at least as I interpreted it is up to the = receiver to figure this out based on the definitions it has for each = event URI and the profiles they represent. IOW - RISC is free to limit = that only one RISC event be expressed at a time. >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>>>>>=20 >>>>>>>>>> @independentid >>>>>>>>>>=20 >>>>>>>>>> www.independentid.com = = > >>>>>>>>>>=20 >>>>>>>>>> phil.hunt@oracle.com = > >>>>>>>>>>=20 >>>>>>>>>> On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle >>>>>>>>>> = >> wrote: >>>>>>>>>>=20 >>>>>>>>>> The current draft of the SET spec allows for expressing = multiple >>>>>>>>>> events within the same token, which introduces additional = complexity >>>>>>>>>> and room for ambiguous semantics. We=E2=80=99ve discussed = this in the OIDF >>>>>>>>>> RISC working group and the current consensus there is = that RISC will >>>>>>>>>> require that RISC events must be the only event in the = SET, having >>>>>>>>>> identified ways to clearly and easily support the handful = of use >>>>>>>>>> cases for multiple events per token that people have = raised. With >>>>>>>>>> that context in mind, I propose striking the definition = of the >>>>>>>>>> =E2=80=9Cevents=E2=80=9D claim from the Security Event = Token spec, and replacing it >>>>>>>>>> with the following definition for an =E2=80=9Cevent=E2=80=9D= claim (singular): >>>>>>>>>>=20 >>>>>>>>>> event >>>>>>>>>>=20 >>>>>>>>>> A JSON object containing an "event_type" member whose = value is a URI >>>>>>>>>> representing a type of event defined in a Profiling = Specification. >>>>>>>>>> The object MAY otherwise be empty, or MAY contain = additional members >>>>>>>>>> as described by the Profiling Specification. >>>>>>>>>>=20 >>>>>>>>>> Here is the example SET from section 2.3, rewritten with = this change >>>>>>>>>> mind: >>>>>>>>>>=20 >>>>>>>>>> { >>>>>>>>>>=20 >>>>>>>>>> "jti": "4d3559ec67504aaba65d40b0363faad8", >>>>>>>>>>=20 >>>>>>>>>> "iat": 1458496404, >>>>>>>>>>=20 >>>>>>>>>> "iss": "https://scim.example.com = >", >>>>>>>>>>=20 >>>>>>>>>> "aud": [ >>>>>>>>>>=20 >>>>>>>>>> = "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754 = ", >>>>>>>>>>=20 >>>>>>>>>> = "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7 = " >>>>>>>>>>=20 >>>>>>>>>> ], >>>>>>>>>>=20 >>>>>>>>>> "event": { >>>>>>>>>>=20 >>>>>>>>>> "event_type": "urn:ietf:params:scim:event:create", >>>>>>>>>>=20 >>>>>>>>>> "ref": = "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 = ", >>>>>>>>>>=20 >>>>>>>>>> "attributes": ["id", "name", "userName", "password", = "emails"] >>>>>>>>>>=20 >>>>>>>>>> } >>>>>>>>>>=20 >>>>>>>>>> } >>>>>>>>>>=20 >>>>>>>>>> Does anyone in the working group have use cases for SETs = that cannot >>>>>>>>>> be met by this proposed text? Within RISC, we identified = three use >>>>>>>>>> cases, with solutions outlined below: >>>>>>>>>>=20 >>>>>>>>>> ** >>>>>>>>>>=20 >>>>>>>>>> *Extensions* >>>>>>>>>>=20 >>>>>>>>>> Event extension mechanisms can be defined internal to the = event >>>>>>>>>> object. A simple approach would be to define an = =E2=80=9Cextensions=E2=80=9D member >>>>>>>>>> that is a list of event objects (or set resembling the = =E2=80=9Cevents=E2=80=9D >>>>>>>>>> claim as defined in the current spec). This has the = advantage of >>>>>>>>>> making it clear in the data structure that there is a = single primary >>>>>>>>>> event, with zero or more extensions. There is no room for = confusion >>>>>>>>>> over which event is primary, or if there is a primary = event at all. >>>>>>>>>> I would be fine with adding something like this to my = proposed text, >>>>>>>>>> if there is consensus that it is broadly useful. >>>>>>>>>>=20 >>>>>>>>>> *Aliases* >>>>>>>>>>=20 >>>>>>>>>> This use case was brought up in the context of migrating = clients >>>>>>>>>> from draft event names to standardized event names. In = this case, >>>>>>>>>> the event transmitter can transmit two tokens for the = logical event, >>>>>>>>>> one using the old name and another using the new name. >>>>>>>>>>=20 >>>>>>>>>> *Related Events* >>>>>>>>>>=20 >>>>>>>>>> The SET spec defines the txn claim as a means of = correlating >>>>>>>>>> independent tokens that relate to the same logical event. >>>>>>>>>>=20 >>>>>>>>>> --=20 >>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>=20 >>>>>>>>>> Amazon =E2=80=93 Identity Services >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> Id-event mailing list >>>>>>>>>> Id-event@ietf.org = > >>>>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Ds5byBe5KANnGVuA= b1mAupEGoJn8XG5JIUUwWGFSibEc&s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyo= IY&e=3D = >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> Id-event mailing list >>>>>>>>>> Id-event@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>> _______________________________________________ >>>>>>>>> Id-event mailing list >>>>>>>>> Id-event@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> --=20 >>>>>>>> Subscribe to the HARDTWARE = mail list to = learn about projects I am working on! >>>>>>>> _______________________________________________ >>>>>>>> Id-event mailing list >>>>>>>> Id-event@ietf.org >>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DYBCGlK9mjjhcFsj= -2tDkn31Auxuruib9KATkRlQG1iw&s=3DWrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02E= Xs&e=3D = >>>>>>> =20 >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DU-a5HBND0HaTX4a= nNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=3DrvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm46QS= z0&e=3D = >>>>>> =20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> -- >>>>> Subscribe to the HARDTWARE = mail list to = learn about projects I am working on! >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DiyVnrZmr9_uGCQ6= MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=3DOe0qfLEX83vtXM7Wl2cYBe-Gg1DVPjhXjVJkfhVRz= wc&e=3D = >>>=20 >>>=20 >>> =20 >>> -- >>> Subscribe to the HARDTWARE = mail list to = learn about projects I am working on! >>=20 >>=20 >>=20 >> =20 >> -- >> Subscribe to the HARDTWARE = mail list to = learn about projects I am working on! >=20 >=20 >=20 > =20 > --=20 > Subscribe to the HARDTWARE = mail list to = learn about projects I am working on! > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZkt= cmagv5Ea21QEip4HXpEVKRa0qhlo&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcOR= V0&e=3D = --Apple-Mail=_B8486D94-C6FA-41CE-AB10-3AE14293DB46 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You can=E2=80=99t really have multiple events (at least of = the same type).  The current spec can only have one instance of a = URI (afaik).  

Note that the spec normatively does not support multiple = event SETS.  It currently states:
events
      The semantics of this claim is to define a set of =
event statements
      that each MAY add additional claims to fully describe a single
      logical event that has occurred (e.g. a state change to a
      subject).  Multiple event statements of the same type SHALL NOT be
      accepted.  The "events" claim SHOULD NOT be used to express
      multiple logical events.

The spec has *always* supported = requirements (as stated in the spec) for multiple separate profile = statements (from one or more profile familities) needing to be sent as a = single message.  It would be INSECURE to force multiple SETs = because the current delivery mechanism only allows one SET to be = delivered at a time. There is no way to assure that a single receiver = gets all of the SETs it needs in a multi-threaded, multi-node = environment at scale.  Assembling multiple SETs to track =E2=80=9Ctxn= =E2=80=9D in a common state database is NOT simple nor cost effective. =  

If we = accommodate this in the proposed form, we end up with a complex, deeply = nested JSON structure with the possibility of namespace = conflicts.

IMO = The proposal does not simplify, it complicating and limiting. =  

The = current spec has very clean JSON and avoids namespace conflicts between = profiles. I think we should stay on track with the current draft and = observe the normative text if not make it stronger in regards to = multi-events (understood that Mike may disagree).
Phil

Oracle = Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Nov 1, 2017, at 12:18 PM, Richard Backman, Annabelle = <richanna@amazon.com> wrote:

Unless the profile = guarantees that such related events will always be included in the same = SET, then the receiver has to correlate across SETs anyway, and multiple = events per SET is just giving the receiver another scenario that they = have to support.
 
I=E2=80=99ve already provided several other reasons why we = should not support multiple tokens per SET that no one has addressed. = Here they are again:
  1. Multiple event support results = in a more complex structure for the single event use case, which I think = we all agree is the majority use case.
  2. Multiple-event SETs have = ambiguous semantics. The presence of two events A and B in the same SET = could mean any of:
    1. A and B are related to the same = logical event (i.e. the same thing as if they were from different SETs = that have a common txn).
    2. A is an extension of B.
    3. B = is an extension of A.
    4. A is an alias for B, or = vice-versa.
    5. A and B are not actually related to one another in = any way, and the transmitter bundled them together because they were = going to the same receiver.
  3. Top-level claim semantics = become harder to define, as different profiles may want to use the same = claims in different ways.
  4. Event authenticity cannot be = verified without having the entire SET. This forces receivers to expose = downstream systems to more information necessary, if those systems need = to be able to verify authenticity.
 
-- 
Annabelle Richard Backman
Amazon =E2=80=93 Identity Services
 
 
From: Mike Jones <Michael.Jones@microsoft.com>
Date: Wednesday, November 1, = 2017 at 11:21 AM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Yaron= Sheffer <yaronf.ietf@gmail.com>, "Richard Backman, Annabelle" = <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, = "Phil Hunt (IDM)" <phil.hunt@oracle.com>
Subject: RE: [Id-event] Use = cases for multiple events per SET?
 
I = completely agree on moving complexity to the issuer over the = recipient.  In my view, it=E2=80=99s more complex for recipients to = have to correlate and process a sequence of multiple SETs providing = information about the same logical event, and validate N signatures, = than to receive one SET with all the aspects of the logical event as = =E2=80=9Cevents=E2=80=9D fields, with no correlation over time then = required.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Dick Hardt [mailto:dick.hardt@gmail.com] 
Sent: Wednesday, November 1, 2017 = 9:39 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron= Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle = <richanna@amazon.com>; ID Events Mailing List <id-event@ietf.org>; = Phil Hunt (IDM) <phil.hunt@oracle.com>
Subject: Re: [Id-event] Use cases = for multiple events per SET?
 
Your = comments highlight a couple of points:
 
1) The example is how to have a = predefined extension point for extensions of a specific event, it is not = how to add another event. Myself, I think this is overly complicated. = Events should be comparatively static, and as with many other JSON = formats, the receiver should ignore properties it does not understand, = which let's new properties be introduced as extensions. There should not = be any conflict as extensions should only be done by the profile that = created the event format to start off with.
 
2) Having an lvalue be a URI is much = harder to code against. I'm not sure why Marius had that in his example. = Per the event, the type of the event is well defined with 
 
"event_type": "https://example.com/scim/event/passwordResetExt",
 
3) This thread is about = reasons for multiple events to be contained in one set. Your mention of = an issuer not wanting to sign separate events as a reason to allow = multiple events. I think we have decided that given a preference, we = will push effort to the transmitter over the receiver as in many use = cases there are many more receivers. Given that, it is more complex for = a receiver to have different ways of managing the receipt of multiple = events as not all issuers will bundle the events, so it is simpler to = have only one event per SET. Including the separate events with a URI as = an lvalue is challenging to implement, speaking from experience.
 
 
 
 
 
 
 
 
 
 
 
 
On Tue, Oct 31, 2017 at 11:05 PM, Mike = Jones <Michael.Jones@microsoft.com> wrote:
Marius=E2=80=99= proposed syntax, pasted in below, has exactly this = characteristic.  The way I see it, his proposal essentially has a = primary passwordReset event and a secondary passwordResetExt data = structure, which could have been simply another event value in the = current draft.
 
This = breaking change makes the data structures more complicated - not = less.  And it makes things that used to be possible impossible, = reducing flexibility to those who would use the spec.
 
These seem like bad = tradeoffs to me.
 
{
  "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": = 1458496025,
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",<= /span>
   ],
  =  "event_type": "https://example.com/scim/event/passwordResetExt",
   "event": {  
        =  "id":"44f6142df96bd6ab61e7521d9",
         "extensions": {
           "https://example.com/scim/event/passwordResetExt=E2=80=9D: = {
            =  "resetAttempts":5,
      =      }
      =    }
       }
}
 
In = particular, it makes it impossible to sign multiple related events = sharing a common claims schema with a single signature by the = issuer.  It forces the issuer to do the extra work of signing each = of the related events (or facets of the same logical event) individually = and forces the recipients to do the extra work of checking all those = unnecessary signatures.
 
Not every = profile will ever have multiple keys in the =E2=80=9Cevents=E2=80=9D set = but there=E2=80=99s absolutely no reason to preclude it.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf = Of Dick Hardt
Sent: Tuesday, October 31, 2017 = 9:52 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron= Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle = <richanna@amazon.com>; ID Events Mailing List <id-event@ietf.org>;= Phil Hunt (IDM) <phil.hunt@oracle.com>

Subject: Re: [Id-event] Use cases = for multiple events per SET?
 
Please direct me to a proposal that has a "primary" and = "secondary" events. I agree that is undesirable. I would also encourage = to engage in the discussions so that we can drive clarity and = simplicity.
 
I think the proposal is that there is one event per SET.
 
I think having more than one event per = SET adds complexity as a receiver must deal with receiving correlated = events in one SET as well as correlated events in the same SET.
 
/Dick
 
On Tue, Oct 31, 2017 at 9:42 PM, Mike = Jones <Michael.Jones@microsoft.com> wrote:
I hear you = on the fact that different people have joined the effort at different = times.  That=E2=80=99s a normal process as an effort builds = momentum.  I get that not everyone was there when previous = consensus calls were taken.
 
I should = note that I have specific technical objections to the specific proposed = changes being discussed as well.  Currently all events in the set = have the same syntax.  The proposals, as I understand them, revert = us to a state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and = =E2=80=9Csecondary=E2=80=9D events, with different syntax for the two = classes.  That=E2=80=99s needlessly more complicated, adding no = actual value.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: Dick Hardt [mailto:dick.hardt@gmail.com] 
Sent: Tuesday, October 31, 2017 = 9:37 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Phil = Hunt (IDM) <phil.hunt@oracle.com>; Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle = <richanna@amazon.com>; ID Events Mailing List <id-event@ietf.org>

Subject: Re: [Id-event] Use cases = for multiple events per SET?
 
Mike
 
As you well know, many people in a WG don't look closely at a = specification until last call is made. Additionally, we are coming up on = only the 3rd WG meeting. The WG has not existed for very long. While = some of the participants have been working on this for a while, many = have not, and we are looking for consensus across the WG.
 
Since SecEvent is a framework that we = expect to be profiled, I feel it is important to ensure that SecEvent = specifications are easy for a variety of profiles to adopt, and that the = semantics make sense. I also think that properties that are specific to = a profile should be left to that profile and not be included in = SecEvent.
 
Since this is a framework, it is expected that as different = groups profile it, there will be additional feedback.
 
Specifically, as a participant in the = RISC profile of SET, a number of issues in SET have surfaced as the RISC = WG has looked at how to use the SET.
 
As for SET being stable for over a year, there have been a = number of changes to SET since then. I also don't think there was = consensus. Before the WG was formed, I and several others had expressed = concern on the design of SET when Phil presented it at an IIW = session.
 
As to taking another year, I am hopeful we can resolve the = remaining issues in SET and publish a new draft for last call. I do not = think we will need to wait for another WG meeting to ask for last = call. 
 
We also have a number of other documents that are not in last = call, and we don't have a WG adopted draft yet for management. So there = are still a number of documents to work through before we have all the = bits for someone to work with.
 
I do think we have been making good progress since the last = IETF meeting, and I am hopeful we can keep up this momentum and finalize = all the documents in a timely manner.
 
/Dick
 
 
On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
It=E2=80=99s = hard for me to even express my level of frustration with the recent = attempts to once again redesign the SecEvent Token spec.  We=E2=80=99= ve been at this for multiple years because people keep trying to revisit = decisions that were long ago made by consensus.  It=E2=80=99s been = stable for over a year and the majority of WGLC respondents said some = variant of =E2=80=9CWorks for me =E2=80=93 ship it!=E2=80=9D
 
There=E2=80=99s not = sufficient justification to try to undo consensus positions that have = been debated and affirmed over and over.  Countenancing wholesale = changes at this late date is counterproductive in the = extreme!
 
It=E2=80=99s = far better than good enough as-is.  In my experience, if we start = redesigning it, it will result in another year=E2=80=99s delay.  It = does something simple and useful.  Please, let=E2=80=99s just ship = it, so people can rely on it.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 
Sent: Monday, October 30, 2017 = 2:42 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Yaron= Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle = <richanna@amazon.com>; Mike Jones <Michael.Jones@microsoft.com>; ID Events Mailing List = <id-event@ietf.org>

Subject: Re: [Id-event] Use cases = for multiple events per SET?
 
Inline...

Phil


On Oct 30, 2017, at 2:22 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:

Hi Phil
 
Correct me if I am misunderstanding, = but there is a RISC profile event 
 
"http://schemas.openid.net/secevent/risc/event-type/<=
span style=3D"font-size: 9pt; font-family: Arial, sans-serif;" =
class=3D"">account-credential-change-required=E2=80=9D
 
and an SCIM profile event
 
"https://example.com/scim/event/passwordResetExt=E2=80=9D
 
I'm suggesting that two = different events would be sent. Embedding one in the other does not make = sense.
<ph>It is a hypothetical example. = Just because you disagree on this does not mean others are not = valid. 
 
I just picked overlapping proposals that have different = meaning (but not the same) to illustrate the difference from issuing a = single set with different events. 
 

As I have stated this is very = different from asserting multiple distinct events in one SET. 

 
Also, I think it is simpler to have event_type be at the same = level as event
 

<ph>may be. I was working from Annabelle's proposed = format. 

 
{
  "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",<= /span>
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
   ],
   "event": {  
        =  "id":"44f6142df96bd6ab61e7521d9",
        =  "resetAttempts":5
      =  }
}
 
{
  "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",<= /span>
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
   ],
   "event": {
      =  =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
       =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/"      =  
       }
}
 
 
 
 
 
On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Annabelle/Dick,
 
Thanks for the comments. I think we need to examine the = consequences of the proposal in JSON.
 
As I stated, what causes most of the issue is the proposed = extension mechanism in the payload (possibly using events in a recursive = way). Does it follow the old format or the new?
 
Let=E2=80=99s  consider a use case = where we have an identity management system that uses SCIM, but the SCIM = system is also the underlying data store for Connect.  A Password = reset might generate the following event which has an extension = (conveying reset count) AND overlapping statement from RISC.  BOTH = of which might be important to a similar receiver using SCIM and OIDC. =  
 
The 03 spec currently would allow:
 
{
  "jti": =
"3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  =
"iss": "https://scim.example.com",
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",<=
o:p class=3D"">
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
   ],
   "events": {
     =
"urn:ietf:params:scim:event:passwordReset":
       { =
"id":"44f6142df96bd6ab61e7521d9"},
     "https://example.com/scim/event/passwordResetExt":
       { =
"resetAttempts":5},
     "http://schemas.openid.net/secevent/risc/event-type/\
      =
 account-credential-change-required": {
         =
=E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
         =
=E2=80=9Ciss=E2=80=9D:"https://idp.example.com/"
      =
 }
  =
}
}
 
In the above - =
each payload is a =E2=80=98peer' and issued without preference by the =
transmitter. The receiver can assign priority in its own context if that =
matters.
 
The new proposal:
 
{
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  =
"iat": 1458496025,
  "iss": "https://scim.example.com",
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",<=
o:p class=3D"">
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
   ],
   "event": {
     =
=E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passwordReset=E2=80=
=9D,
     =
"id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
     =E2=80=9Cevents=E2=80=9D:{
     ->note =E2=80=A6is this the old =
or new structure? <-
       "https://example.com/scim/event/passwordResetExt":
         { =
"resetAttempts":5},
       "http://schemas.openid.net/secevent/risc/event-type/\
        =
 account-credential-change-required": {
         =
=E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
         =
=E2=80=9Ciss=E2=80=9D:"https://idp.example.com/"
      =
 }
     }
   =
}    
}
 
In the above, sub-events or extensions have a different =
format. The same complaint about the original stands.
 
*OR* (if the receiver cares about RISC more).  Note that =
this leads to a triple nested structure.
 
{
  =
"jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  =
"iss": "https://scim.example.com",
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",<=
o:p class=3D"">
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
   ],
   "event": {
     =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/risc/event-type/\=

    =
        =
 account-credential-change-required=E2=80=9D,
      =
=E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
     =
 =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C,
      =
=E2=80=9Cevents=E2=80=9D:{
        =
"urn:ietf:params:scim:event:passwordReset":
        { 
          =
"id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
          =
=E2=80=9Cevents=E2=80=9D:{
          &nb=
sp;  "https://example.com/scim/event/passwordResetExt":
          &nb=
sp;    { "resetAttempts":5},  
          }      
        }
      }     
   }
}
 
In the above, the extension is placed inside the =
event it extends. It follows the old format (or should it follow the =
new?)
*OR* Following =
the top layer pattern of singular event  Note that this leads to a =
triple nested structure.
 
{
  "jti": =
"3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  =
"iss": "https://scim.example.com",
  "aud": [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",<=
o:p class=3D"">
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
   ],
   "event": {
     =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/risc/event-type/\=

  =
          =
 account-credential-change-required=E2=80=9D,
      =
=E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
      =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C,
      =
=E2=80=9Cevent=E2=80=9D:{
        =
=E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passwordReset=E2=80=
=9D,
        =
"id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
        =E2=80=9Cevent=E2=80=
=9D:{
          =
=E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/event/passwordResetExt=E2=80=9D,
          =
"resetAttempts":5 =

        }
      }     
   }
}
 
This format =
follows the proposed singular event format recursively and is 3 layers =
deep. Note that the parser has to continue to search the document for =
things that aren=E2=80=99t there as it has to stop when no =E2=80=9Cevent=E2=
=80=9D attribute is found rather than iterate over an array.
 
Phil

Oracle Corporation, = Identity Cloud Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com
 
On Oct 30, 2017, at 8:57 = AM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
 
Replies inline.
 
-- 
Annabelle Richard Backman
Identity = Services
 
 
From: Phil Hunt <phil.hunt@oracle.com>
Date: Sunday, October = 29, 2017 at 5:25 PM
To: Dick Hardt = <dick.hardt@gmail.com>Cc: Yaron Sheffer = <yaronf.ietf@gmail.com>, = Mike Jones <Michael.Jones@microsoft.com>, "Richard Backman, = Annabelle" <richanna@amazon.com>, = ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] = Use cases for multiple events per SET?
 
I hope this = answers your question.
 
My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t = see a reason why not. The question should be, what is the justification = to make =E2=80=9Cevents=E2=80=9D singular?
[richanna]The singular =E2=80=9Cevent=E2=80=9D claim = has clearer semantics and is easier to process. We should opt for easier = solutions unless there are use cases that require more = complexity.[/richanna]
 
There are many reasons for multiple events in a = SET.  Some are good, some not so good. Some of the reasons...
 
1.  = Multiple event payloads expressing statements about largely the = *same*thing. For example, SCIM password reset AND RISC password = reset.  A RISC Event and an OpenBanking Event. Is one a complement = to the other?  Do they overlap or are they distinct?  
[richanna]Copy/pasted from my earlier = email:
Why is it necessary or = appropriate to include these events in the same SET? They are likely = being generated by different systems at different times on the = transmitter=E2=80=99s side, consumed by different systems on the = receiver=E2=80=99s side, and possibly being transmitted over different = event streams. I know the latter would be the case for us, as a = receiver. Even if it=E2=80=99s not, is it burdensome to send these = events separately? What value is gained in combining them?
 
Additionally, since the signature is over the SET and not the = event objects, Receivers independently route separate events from a = single token without either losing the ability to verify the = authenticity of the event or sharing all information in the SET with = every system handling any event in the token.[/richanna]
 

2.  Multiple events payloads expressing different = statements about the same transaction - RISC Password Reset and RISC = Session Cancel
[richanna]Same as above[/richanna]

3.  A new = profile defines new event attributes to be added on to an existing event = type (a pure extension) 
[richanna]I have suggested a way to = support extensions within an event body, multiple times now. If you see = problems with it, please point them out.[/richanna]
 
I think it is = quite valid to allow 1 and 3.  2 could be limited by specific = profiles like RISC if they want.
 
I am not in = agreement that making event singular simplifies anything. For one is = makes extensions complex (another nested JSON structure) and potentially = conflicting. 
[richanna]
Ways = that multiple-event SETs are more complicated:
  1. It results in a more complex structure for the single event = use case, which I think we all agree is the majority use case.
  2. Multiple-event SETs have = ambiguous semantics. The presence of two events A and B in the same SET = could mean any of:
    1. They are related to the same = logical event (i.e. the same thing as if they were from different SETs = that have a common txn).
    2. A is an extension of B.
    3. B is an extension of A.
    4. They are aliases for one = another.
    5. They are not actually related to one another in any way.
  1. Claim semantics become harder to define, as different profiles = may want to use the same claims in different ways.
 
If the WG = wants to block 1 and 2 above, then I believe we have to establish an = event registry to ensure new Event profiles do not overlap to eliminate = the need to express multiple events.
[richanna]I=E2=80=99m not = sure what you mean by this. Are you referring to event names? Those are = already defined by the spec to be URIs.[/richanna]
Phil
 
Oracle Corporation, Identity Cloud Services = Architect
@independentid
www.independentid.com
phil.hunt@oracle.com
 
On Oct 29, 2017, at 4:12 PM, Dick = Hardt <dick.hardt@gmail.com> = wrote:
 
Phil:
 
In your examples for having a plurality of events, you use = the word "may", which leads me to question if a plurality of events is = really required in SET.
 
You posit that it will be difficult for a distributed system = to correlate multiple SETs with the same "txn", but the distributed = system will certainly need to correlate events on the same subject -- = correlating events on the same "txn" on the same subject seems fairly = simple.
 
I= think that a receiver will need to correlate multiple SEts on the same = subject, so having multiple events in a SET is redundant, and adds = complexity with no clear benefit that I can see.
 
An implementor may choose to send = multiple SETs, or send a single SET with multiple events, so a receiver = will need to support both. I prefer we pick one way and minimize the = code paths, and we will need to support correlating across multiple = SETs, so that seems the best mechanism.
 
Let me know if there is something I = missed in my logic.
 
/Dick
 
 
On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
In that case, let's add = text to that effect, e.g. we could add to the definition of the "events" = claim:

Profiling specifications SHOULD = define the allowed event statements, and MAY restrict their number. For = example, some profiles may require this claim to contain only a single = event statement.

Thanks,
 =       Yaron

On 24/10/17 22:10, Mike Jones = wrote:

I agree with much = of Phil=E2=80=99s rationale here.

It=E2=80=99= s fine for some profiles to say that the =E2=80=9Cevents=E2=80=9D set = must be a singleton.  That doesn=E2=80=99t have to be true for all = events.  I think things are fine as-is.

          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;     -- Mike

*From:* Id-event [mailto:id-event-bounces@ietf.org] = *On Behalf Of *Phil Hunt
*Sent:* Monday, October 23, 2017 = 8:47 PM
*To:* Richard Backman, Annabelle <richanna@amazon.com>
*Cc:*= ID Events Mailing List <id-event@ietf.org>
*Subject:* Re: = [Id-event] Use cases for multiple events per SET?

Annabelle,

I have a number of = concerns with this proposal.

Profiling = Independence / Keeping Event Payloads Independent

Indicating that extensions should be handled by profiles = leads to more inter-operability issues and more importantly intrudes on = the Event payload space by suggesting a sub-schema creates potential = limitations and conflicts that may add to complexity later on. The = current format allows a parser to discover and unload one or more JSON = payloads which can each have independent structure.

General extensions

The proposal = also rules out general purpose extensions not related to any specific = event. Given the emergence of items like GPRD, I would not want to block = the ability to add meta-data or other general purpose items. We can also = anticipate some delivery scenarios where additional data might be = required. Even though there is no current planned use, I see no good = reason to rule this out.

Multiple Events = =46rom Different Families (vs. Multiple Events from a single family like = RISC)

In our RISC session we discussed = expressing multiple distinct RISC events in one SET. The discussion was = that only one RISC event at a time. We did not discuss other event = profiles. I don=E2=80=99t see a reason to rule out multi-events from = different families at the SET level. Each profile is expressing slightly = different things about the same event.

I = can forsee some cases where it is not clear which is the primary and = which is the extension.  There may not be a clear winner.

A couple of examples (these are necessarily = real=E2=80=A6just possibilities):

* It is = probably useful to be able to express simlar/overlapping events from = different SET profiles in one SET.  For example a Backchannel = Logout & a RISC session cancel event.

* = SCIM may want to represent a single transaction as causing multiple = state changes in an event (e.g. a password change causes multiple = effects). Having to chase down multiple events and correlate by = =E2=80=9Ctxn=E2=80=9D would be challenging in a = multi-threaded/multi-node delivery system.   The SCIM list has = not discussed this, but I would not want to block this capability.  = IOW - Just because RISC does not want to express multiple events does = not make this true for other profiles.

* We = may wish to indicate a SCIM Password Reset was performed and a = Logout/session cancellation is expressed at the same time.  The = events are related but express different data.

Avoiding Confusion =46rom Similar Events Originating from the = Same Transaction

If events are sent = separately, then more tracking of state (e.g. by txn) would be required = to ensure similar events are not mistaken or handled as repeats. While = txn provides useful audit analysis capability, I=E2=80=99m not sure it = can be used in live or near-real time systems given distributed = multi-node, multi-threading architectures.

Previous Discussion

I note that = I originally raised having an attribute to designate primary event = attribute to alleviate your concern, but this was not accepted. See:

* https://www.ietf.org/mail-archive/web/id-event/current/msg00406= .html

* https://www.ietf.org/mail-archive/web/id-event/current/msg00140= .html

The consensus, at least as = I interpreted it is up to the receiver to figure this out based on the = definitions it has for each event URI and the profiles they represent. = IOW - RISC is free to limit that only one RISC event be expressed at a = time.

Phil

Oracle Corporation, Identity Cloud Services Architect

@independentid

www.independentid.com <http://www.independentid.com>

phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>

    On Oct 23, 2017, at 7:02 PM, Richard Backman, = Annabelle
    <richanna@amazon.com <mailto:richanna@amazon.com>> wrote:

    The current draft of the SET = spec allows for expressing multiple
    events = within the same token, which introduces additional complexity
    and room for ambiguous semantics. We=E2=80=99ve = discussed this in the OIDF
    RISC working = group and the current consensus there is that RISC will
    require that RISC events must be the only event = in the SET, having
    identified ways to = clearly and easily support the handful of use
  =   cases for multiple events per token that people have raised. = With
    that context in mind, I propose = striking the definition of the
    =E2=80=9Cevents= =E2=80=9D claim from the Security Event Token spec, and replacing it
    with the following definition for an = =E2=80=9Cevent=E2=80=9D claim (singular):

    event

  =   A JSON object containing an "event_type" member whose value is a = URI
    representing a type of event defined in = a Profiling Specification.
    The object MAY = otherwise be empty, or MAY contain additional members
 =   as described by the Profiling Specification.

    Here is the example SET from section 2.3, = rewritten with this change
    mind:

    {

       "jti": = "4d3559ec67504aaba65d40b0363faad8",

  =      "iat": 1458496404,

 =     "iss": "https://scim.example.com <https://scim.example.com/>",

       "aud": [

         "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754= ",

       =   "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7= "

       ],

       "event": {

         = "event_type": "urn:ietf:params:scim:event:create",

         "ref": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9= ",

    =      "attributes": ["id", "name", "userName", = "password", "emails"]

    =    }

    }

    Does anyone in the working group = have use cases for SETs that cannot
    be met = by this proposed text? Within RISC, we identified three use
    cases, with solutions outlined below:

    **

    *Extensions*

  =   Event extension mechanisms can be defined internal to the = event
    object. A simple approach would be to =  define an =E2=80=9Cextensions=E2=80=9D member
  =   that is a list of event objects (or set resembling the = =E2=80=9Cevents=E2=80=9D
    claim as defined in = the current spec). This has the advantage of
    = making it clear in the data structure that there is a single primary
    event, with zero or more extensions. There is = no room for confusion
    over which event is = primary, or if there is a primary event at all.
  =   I would be fine with adding something like this to my proposed = text,
    if there is consensus that it is = broadly useful.

    *Aliases*

    This use case was brought up in = the context of migrating clients
    from draft = event names to standardized event names. In this case,
    the event transmitter can transmit two tokens = for the logical event,
    one using the old = name and another using the new name.

  =   *Related Events*

    The = SET spec defines the txn claim as a means of correlating
    independent tokens that relate to the same = logical event.

    -- 
 =   Annabelle Richard Backman

  =   Amazon =E2=80=93 Identity Services

    = _______________________________________________
  =   Id-event mailing list
    Id-event@ietf.org <mailto:Id-event@ietf.org>
  =   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3Ds5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=3DX8oRSq3Izl= F7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


 
-- 
Subscribe to the HARDTWARE mail list to learn = about projects I am working on!
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
 


 
--
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!


 
--
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!


 
--
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!


 
-- 
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4K= ZNA&m=3DsIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=3DgdNrs7UDAt= tpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=3D

= --Apple-Mail=_B8486D94-C6FA-41CE-AB10-3AE14293DB46-- From nobody Wed Nov 1 12:57:20 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810FE13F622 for ; Wed, 1 Nov 2017 12:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 IFkg-qiKEsSw for ; Wed, 1 Nov 2017 12:57:12 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0134.outbound.protection.outlook.com [104.47.34.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC7D138FA0 for ; Wed, 1 Nov 2017 12:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XIJMabqmeZpc2uTvTO1QzQEfVXAkoX9WOMGL0CE9L+4=; b=jrbDmLdocqNZ/xmmmEqGxlbpLe6Ba5W3l829PjcKRIxPm7wYnU/wKPHsak/5j4/MUHqVJda5iJMphCSDYZsEi4CNYYegcXCFvu3h8InqRbp3qo1FwB/Z+qSnWffvNjuZnT4refknerMJcL5wCjqTraykBYcVj+SYhLzNIqEEoVY= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0757.namprd21.prod.outlook.com (10.173.192.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.197.0; Wed, 1 Nov 2017 19:57:09 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0218.005; Wed, 1 Nov 2017 19:57:09 +0000 From: Mike Jones To: Phil Hunt , "Richard Backman, Annabelle" CC: Dick Hardt , Yaron Sheffer , ID Events Mailing List Thread-Topic: [Id-event] Use cases for multiple events per SET? Thread-Index: AQHTTGwev6cV0D/tE06azbqzz7my9aLyXLkAgAEBjXCAB9BnAIAAT1IAgAAUagCAAQQ9AIAANauAgAAlNACAAAV2gIABcZJQgACUvYCAAADCcIAAA1kAgAASxcCAALLVgIAAG18AgAARHoCAAAeDAIAAAqEQ Date: Wed, 1 Nov 2017 19:57:09 +0000 Message-ID: References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-11-01T19:57:05.2998065Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:1::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0757; 6:jczKrvDdouRX8kVsPQ1vI+eOzuK9WcdkMTNoFZVhuYgzhaui8zBgC9hgEkQ780ji8yIY2uhEpO8PGkfY4t9fYFU99YH6AcWXGckXYYlz4MAO7/MS/UMK7J/EmZznsiqs2THNieYcOCbkmeRUcfvqyQThUe6Ii2QOt8lMJDH5Xk5ECB2D3siVqQv61VDsFR8qYfFhcSkVv+aZ4bctDz1wNwKSW4Z3Qn8QGGCQUGAX43Op8mn0fn2EgWjMiS5MrVQ1RfGWYR4DV4tpED/PoNohxoZczDEAv9ua6qhT6J+qMePSyZAfSMXpipOln8/8Rte1HCbd3B9pfSCd6QXtEgVLzQzlC1N0KVuueu1zaBKRBMI=; 5:HRVNByzhR8v/g0dhz4wkePeN9rfy0ajtGGPntSUvVLIKPZvFs+GOwp0mlVHfjlvZ+JjoNT5WV6fscQCyNRfO2zXgSHz1ijyLtXQo2cQNS8SdArZ77Nx9QsXpejD86cl0Ye1NQy72KD3sJwVt3fQbBifKwC+cNgyeEVdhGVaYrJA=; 24:2nMYto/irm3MxnCe8XCvCU40LjVHorLd2kLu6yCkbN2JzKFvhMy0joG081eiUfHnQF2cc3p2DizxoARvFy/8Ik29Zjvqlh2hON3PynCt1qE=; 7:iZC4lgjFMCALG4QXQhF01Ra/pzqHMKHIchFmyvZFs+2nHv23/0LzA9RtyGEIxl8HcfeCbHt/BGVZeSD9OK3f/2/W0OeBKkUTz7FYzFJzvuwYGgoiD1TbM6GwqkSsy7YW4qEZ+5MXObH26zIdLmmj8fgJ4hZHKks7dTp/rIM+Rj+fb1g8iIOIO4W6OVj40dYSzRExraF+ZmEbEWOWPTYjxnUIEZPUY4ipYShxdF2efZP2JSyVw35TcanuNC+R798r x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 90b07efb-f1cc-445a-33f9-08d52162bc6b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:CY4PR21MB0757; x-ms-traffictypediagnostic: CY4PR21MB0757: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-exchange-antispam-report-test: UriScan:(190756311086443)(10436049006162)(89211679590171)(192374486261705)(33061846794335)(100405760836317)(21748063052155)(5213294742642)(146099531331640)(47284530071512); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(3231020)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0757; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0757; x-forefront-prvs: 0478C23FE0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(47760400005)(51914003)(189002)(52314003)(199003)(24454002)(51444003)(19609705001)(3280700002)(966005)(10290500003)(22452003)(54906003)(1680700002)(72206003)(53546010)(606006)(478600001)(110136005)(6436002)(68736007)(33656002)(53386004)(2900100001)(76176999)(54356999)(229853002)(790700001)(50986999)(551544002)(74316002)(14454004)(39060400002)(8936002)(99286004)(86612001)(2950100002)(2906002)(575784001)(6116002)(3660700001)(102836003)(7696004)(86362001)(4326008)(6246003)(584604001)(8676002)(81166006)(81156014)(5660300001)(6306002)(54896002)(101416001)(9686003)(53936002)(93886005)(16200700003)(53946003)(561944003)(551934003)(236005)(97736004)(316002)(25786009)(7736002)(6506006)(77096006)(55016002)(189998001)(105586002)(8990500004)(106356001)(10090500001)(579004)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0757; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504111616783EB6E3E055E2F55F0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 90b07efb-f1cc-445a-33f9-08d52162bc6b X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2017 19:57:09.3353 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0757 Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 19:57:18 -0000 --_000_CY4PR21MB0504111616783EB6E3E055E2F55F0CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyB3ZWxsIHNhaWQsIFBoaWwuICBZb3UgZGlkIGEgZ3JlYXQgam9iIGV4cGxhaW5pbmcgaG93 IG1ha2luZyB0aGUg4oCcZXZlbnRz4oCdIGNsYWltIHNpbmdsZS12YWx1ZWQgYW5kIGZvcmNpbmcg bXVsdGlwbGUgU0VUcyB3aGVuIG9uZSB3aWxsIGRvIHNpZ25pZmljYW50bHkgY29tcGxpY2F0ZXMg bGlmZSBmb3IgYWxsIHBhcnRpZXMuDQoNCkkgYWdyZWUgdGhhdCB3ZSBwcm9iYWJseSB3YW50IHRv IGV4YW1pbmUgdGhlIGV4aXN0aW5nIGRlc2NyaXB0aXZlIHRleHQgYW5kIG1ha2UgaXQgY2xlYXIg dGhhdCB3aGF04oCZcyBpbiB0aGUg4oCcZXZlbnRz4oCdIHNldCBhcmUgbXVsdGlwbGUgYXNwZWN0 cyBvZiB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50IOKAkyBub3QgZGlzdGluY3QgZXZlbnRzLiAgSeKA mW0gZ3JlYXQgd2l0aCBzdHJlbmd0aGVuaW5nIHRob3NlIHN0YXRlbWVudHMgaWYgdGhleSBhcmVu 4oCZdCBhbHJlYWR5IGNsZWFyIGVub3VnaC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJlc3Qgd2lzaGVzLA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0tIE1pa2UNCg0KRnJvbTogUGhpbCBIdW50IFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21d DQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDEsIDIwMTcgMTI6NDUgUE0NClRvOiBSaWNoYXJk IEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbT4NCkNjOiBNaWtlIEpvbmVz IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdt YWlsLmNvbT47IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT47IElEIEV2ZW50 cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJZC1ldmVu dF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD8NCg0KWW91IGNhbuKAmXQg cmVhbGx5IGhhdmUgbXVsdGlwbGUgZXZlbnRzIChhdCBsZWFzdCBvZiB0aGUgc2FtZSB0eXBlKS4g IFRoZSBjdXJyZW50IHNwZWMgY2FuIG9ubHkgaGF2ZSBvbmUgaW5zdGFuY2Ugb2YgYSBVUkkgKGFm YWlrKS4NCg0KTm90ZSB0aGF0IHRoZSBzcGVjIG5vcm1hdGl2ZWx5IGRvZXMgbm90IHN1cHBvcnQg bXVsdGlwbGUgZXZlbnQgU0VUUy4gIEl0IGN1cnJlbnRseSBzdGF0ZXM6DQoNCmV2ZW50cw0KDQog ICAgICBUaGUgc2VtYW50aWNzIG9mIHRoaXMgY2xhaW0gaXMgdG8gZGVmaW5lIGEgc2V0IG9mIGV2 ZW50IHN0YXRlbWVudHMNCg0KICAgICAgdGhhdCBlYWNoIE1BWSBhZGQgYWRkaXRpb25hbCBjbGFp bXMgdG8gZnVsbHkgZGVzY3JpYmUgYSBzaW5nbGUNCg0KICAgICAgbG9naWNhbCBldmVudCB0aGF0 IGhhcyBvY2N1cnJlZCAoZS5nLiBhIHN0YXRlIGNoYW5nZSB0byBhDQoNCiAgICAgIHN1YmplY3Qp LiAgTXVsdGlwbGUgZXZlbnQgc3RhdGVtZW50cyBvZiB0aGUgc2FtZSB0eXBlIFNIQUxMIE5PVCBi ZQ0KDQogICAgICBhY2NlcHRlZC4gIFRoZSAiZXZlbnRzIiBjbGFpbSBTSE9VTEQgTk9UIGJlIHVz ZWQgdG8gZXhwcmVzcw0KDQogICAgICBtdWx0aXBsZSBsb2dpY2FsIGV2ZW50cy4NCg0KVGhlIHNw ZWMgaGFzICphbHdheXMqIHN1cHBvcnRlZCByZXF1aXJlbWVudHMgKGFzIHN0YXRlZCBpbiB0aGUg c3BlYykgZm9yIG11bHRpcGxlIHNlcGFyYXRlIHByb2ZpbGUgc3RhdGVtZW50cyAoZnJvbSBvbmUg b3IgbW9yZSBwcm9maWxlIGZhbWlsaXRpZXMpIG5lZWRpbmcgdG8gYmUgc2VudCBhcyBhIHNpbmds ZSBtZXNzYWdlLiAgSXQgd291bGQgYmUgSU5TRUNVUkUgdG8gZm9yY2UgbXVsdGlwbGUgU0VUcyBi ZWNhdXNlIHRoZSBjdXJyZW50IGRlbGl2ZXJ5IG1lY2hhbmlzbSBvbmx5IGFsbG93cyBvbmUgU0VU IHRvIGJlIGRlbGl2ZXJlZCBhdCBhIHRpbWUuIFRoZXJlIGlzIG5vIHdheSB0byBhc3N1cmUgdGhh dCBhIHNpbmdsZSByZWNlaXZlciBnZXRzIGFsbCBvZiB0aGUgU0VUcyBpdCBuZWVkcyBpbiBhIG11 bHRpLXRocmVhZGVkLCBtdWx0aS1ub2RlIGVudmlyb25tZW50IGF0IHNjYWxlLiAgQXNzZW1ibGlu ZyBtdWx0aXBsZSBTRVRzIHRvIHRyYWNrIOKAnHR4buKAnSBpbiBhIGNvbW1vbiBzdGF0ZSBkYXRh YmFzZSBpcyBOT1Qgc2ltcGxlIG5vciBjb3N0IGVmZmVjdGl2ZS4NCg0KSWYgd2UgYWNjb21tb2Rh dGUgdGhpcyBpbiB0aGUgcHJvcG9zZWQgZm9ybSwgd2UgZW5kIHVwIHdpdGggYSBjb21wbGV4LCBk ZWVwbHkgbmVzdGVkIEpTT04gc3RydWN0dXJlIHdpdGggdGhlIHBvc3NpYmlsaXR5IG9mIG5hbWVz cGFjZSBjb25mbGljdHMuDQoNCklNTyBUaGUgcHJvcG9zYWwgZG9lcyBub3Qgc2ltcGxpZnksIGl0 IGNvbXBsaWNhdGluZyBhbmQgbGltaXRpbmcuDQoNClRoZSBjdXJyZW50IHNwZWMgaGFzIHZlcnkg Y2xlYW4gSlNPTiBhbmQgYXZvaWRzIG5hbWVzcGFjZSBjb25mbGljdHMgYmV0d2VlbiBwcm9maWxl cy4gSSB0aGluayB3ZSBzaG91bGQgc3RheSBvbiB0cmFjayB3aXRoIHRoZSBjdXJyZW50IGRyYWZ0 IGFuZCBvYnNlcnZlIHRoZSBub3JtYXRpdmUgdGV4dCBpZiBub3QgbWFrZSBpdCBzdHJvbmdlciBp biByZWdhcmRzIHRvIG11bHRpLWV2ZW50cyAodW5kZXJzdG9vZCB0aGF0IE1pa2UgbWF5IGRpc2Fn cmVlKS4NCg0KUGhpbA0KDQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZp Y2VzIEFyY2hpdGVjdA0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRw Oi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tPg0KDQpPbiBOb3YgMSwgMjAxNywgYXQgMTI6MTggUE0sIFJpY2hh cmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5u YUBhbWF6b24uY29tPj4gd3JvdGU6DQoNClVubGVzcyB0aGUgcHJvZmlsZSBndWFyYW50ZWVzIHRo YXQgc3VjaCByZWxhdGVkIGV2ZW50cyB3aWxsIGFsd2F5cyBiZSBpbmNsdWRlZCBpbiB0aGUgc2Ft ZSBTRVQsIHRoZW4gdGhlIHJlY2VpdmVyIGhhcyB0byBjb3JyZWxhdGUgYWNyb3NzIFNFVHMgYW55 d2F5LCBhbmQgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQgaXMganVzdCBnaXZpbmcgdGhlIHJlY2Vp dmVyIGFub3RoZXIgc2NlbmFyaW8gdGhhdCB0aGV5IGhhdmUgdG8gc3VwcG9ydC4NCg0KSeKAmXZl IGFscmVhZHkgcHJvdmlkZWQgc2V2ZXJhbCBvdGhlciByZWFzb25zIHdoeSB3ZSBzaG91bGQgbm90 IHN1cHBvcnQgbXVsdGlwbGUgdG9rZW5zIHBlciBTRVQgdGhhdCBubyBvbmUgaGFzIGFkZHJlc3Nl ZC4gSGVyZSB0aGV5IGFyZSBhZ2FpbjoNCg0KICAxLiAgTXVsdGlwbGUgZXZlbnQgc3VwcG9ydCBy ZXN1bHRzIGluIGEgbW9yZSBjb21wbGV4IHN0cnVjdHVyZSBmb3IgdGhlIHNpbmdsZSBldmVudCB1 c2UgY2FzZSwgd2hpY2ggSSB0aGluayB3ZSBhbGwgYWdyZWUgaXMgdGhlIG1ham9yaXR5IHVzZSBj YXNlLg0KICAyLiAgTXVsdGlwbGUtZXZlbnQgU0VUcyBoYXZlIGFtYmlndW91cyBzZW1hbnRpY3Mu IFRoZSBwcmVzZW5jZSBvZiB0d28gZXZlbnRzIEEgYW5kIEIgaW4gdGhlIHNhbWUgU0VUIGNvdWxk IG1lYW4gYW55IG9mOg0KDQogICAgICogICBBIGFuZCBCIGFyZSByZWxhdGVkIHRvIHRoZSBzYW1l IGxvZ2ljYWwgZXZlbnQgKGkuZS4gdGhlIHNhbWUgdGhpbmcgYXMgaWYgdGhleSB3ZXJlIGZyb20g ZGlmZmVyZW50IFNFVHMgdGhhdCBoYXZlIGEgY29tbW9uIHR4bikuDQogICAgICogICBBIGlzIGFu IGV4dGVuc2lvbiBvZiBCLg0KICAgICAqICAgQiBpcyBhbiBleHRlbnNpb24gb2YgQS4NCiAgICAg KiAgIEEgaXMgYW4gYWxpYXMgZm9yIEIsIG9yIHZpY2UtdmVyc2EuDQogICAgICogICBBIGFuZCBC IGFyZSBub3QgYWN0dWFsbHkgcmVsYXRlZCB0byBvbmUgYW5vdGhlciBpbiBhbnkgd2F5LCBhbmQg dGhlIHRyYW5zbWl0dGVyIGJ1bmRsZWQgdGhlbSB0b2dldGhlciBiZWNhdXNlIHRoZXkgd2VyZSBn b2luZyB0byB0aGUgc2FtZSByZWNlaXZlci4NCg0KICAxLiAgVG9wLWxldmVsIGNsYWltIHNlbWFu dGljcyBiZWNvbWUgaGFyZGVyIHRvIGRlZmluZSwgYXMgZGlmZmVyZW50IHByb2ZpbGVzIG1heSB3 YW50IHRvIHVzZSB0aGUgc2FtZSBjbGFpbXMgaW4gZGlmZmVyZW50IHdheXMuDQogIDIuICBFdmVu dCBhdXRoZW50aWNpdHkgY2Fubm90IGJlIHZlcmlmaWVkIHdpdGhvdXQgaGF2aW5nIHRoZSBlbnRp cmUgU0VULiBUaGlzIGZvcmNlcyByZWNlaXZlcnMgdG8gZXhwb3NlIGRvd25zdHJlYW0gc3lzdGVt cyB0byBtb3JlIGluZm9ybWF0aW9uIG5lY2Vzc2FyeSwgaWYgdGhvc2Ugc3lzdGVtcyBuZWVkIHRv IGJlIGFibGUgdG8gdmVyaWZ5IGF1dGhlbnRpY2l0eS4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJk IEJhY2ttYW4NCkFtYXpvbiDigJMgSWRlbnRpdHkgU2VydmljZXMNCg0KDQpGcm9tOiBNaWtlIEpv bmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIE5vdmVtYmVyIDEsIDIwMTcgYXQgMTE6MjEg QU0NClRvOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJk dEBnbWFpbC5jb20+Pg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxt YWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4sICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxs ZSIgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiwgSUQg RXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGll dGYub3JnPj4sICJQaGlsIEh1bnQgKElETSkiIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20+Pg0KU3ViamVjdDogUkU6IFtJZC1ldmVudF0gVXNlIGNhc2Vz IGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD8NCg0KSSBjb21wbGV0ZWx5IGFncmVlIG9uIG1v dmluZyBjb21wbGV4aXR5IHRvIHRoZSBpc3N1ZXIgb3ZlciB0aGUgcmVjaXBpZW50LiAgSW4gbXkg dmlldywgaXTigJlzIG1vcmUgY29tcGxleCBmb3IgcmVjaXBpZW50cyB0byBoYXZlIHRvIGNvcnJl bGF0ZSBhbmQgcHJvY2VzcyBhIHNlcXVlbmNlIG9mIG11bHRpcGxlIFNFVHMgcHJvdmlkaW5nIGlu Zm9ybWF0aW9uIGFib3V0IHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQsIGFuZCB2YWxpZGF0ZSBOIHNp Z25hdHVyZXMsIHRoYW4gdG8gcmVjZWl2ZSBvbmUgU0VUIHdpdGggYWxsIHRoZSBhc3BlY3RzIG9m IHRoZSBsb2dpY2FsIGV2ZW50IGFzIOKAnGV2ZW50c+KAnSBmaWVsZHMsIHdpdGggbm8gY29ycmVs YXRpb24gb3ZlciB0aW1lIHRoZW4gcmVxdWlyZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IERpY2sgSGFy ZHQgW21haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1i ZXIgMSwgMjAxNyA5OjM5IEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFlhcm9uIFNo ZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29t Pj47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0 bzpyaWNoYW5uYUBhbWF6b24uY29tPj47IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50 QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+OyBQaGlsIEh1bnQgKElETSkgPHBo aWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpTdWJqZWN0 OiBSZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPw0K DQpZb3VyIGNvbW1lbnRzIGhpZ2hsaWdodCBhIGNvdXBsZSBvZiBwb2ludHM6DQoNCjEpIFRoZSBl eGFtcGxlIGlzIGhvdyB0byBoYXZlIGEgcHJlZGVmaW5lZCBleHRlbnNpb24gcG9pbnQgZm9yIGV4 dGVuc2lvbnMgb2YgYSBzcGVjaWZpYyBldmVudCwgaXQgaXMgbm90IGhvdyB0byBhZGQgYW5vdGhl ciBldmVudC4gTXlzZWxmLCBJIHRoaW5rIHRoaXMgaXMgb3Zlcmx5IGNvbXBsaWNhdGVkLiBFdmVu dHMgc2hvdWxkIGJlIGNvbXBhcmF0aXZlbHkgc3RhdGljLCBhbmQgYXMgd2l0aCBtYW55IG90aGVy IEpTT04gZm9ybWF0cywgdGhlIHJlY2VpdmVyIHNob3VsZCBpZ25vcmUgcHJvcGVydGllcyBpdCBk b2VzIG5vdCB1bmRlcnN0YW5kLCB3aGljaCBsZXQncyBuZXcgcHJvcGVydGllcyBiZSBpbnRyb2R1 Y2VkIGFzIGV4dGVuc2lvbnMuIFRoZXJlIHNob3VsZCBub3QgYmUgYW55IGNvbmZsaWN0IGFzIGV4 dGVuc2lvbnMgc2hvdWxkIG9ubHkgYmUgZG9uZSBieSB0aGUgcHJvZmlsZSB0aGF0IGNyZWF0ZWQg dGhlIGV2ZW50IGZvcm1hdCB0byBzdGFydCBvZmYgd2l0aC4NCg0KMikgSGF2aW5nIGFuIGx2YWx1 ZSBiZSBhIFVSSSBpcyBtdWNoIGhhcmRlciB0byBjb2RlIGFnYWluc3QuIEknbSBub3Qgc3VyZSB3 aHkgTWFyaXVzIGhhZCB0aGF0IGluIGhpcyBleGFtcGxlLiBQZXIgdGhlIGV2ZW50LCB0aGUgdHlw ZSBvZiB0aGUgZXZlbnQgaXMgd2VsbCBkZWZpbmVkIHdpdGgNCg0KImV2ZW50X3R5cGUiOiAiaHR0 cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiLA0KDQozKSBUaGlz IHRocmVhZCBpcyBhYm91dCByZWFzb25zIGZvciBtdWx0aXBsZSBldmVudHMgdG8gYmUgY29udGFp bmVkIGluIG9uZSBzZXQuIFlvdXIgbWVudGlvbiBvZiBhbiBpc3N1ZXIgbm90IHdhbnRpbmcgdG8g c2lnbiBzZXBhcmF0ZSBldmVudHMgYXMgYSByZWFzb24gdG8gYWxsb3cgbXVsdGlwbGUgZXZlbnRz LiBJIHRoaW5rIHdlIGhhdmUgZGVjaWRlZCB0aGF0IGdpdmVuIGEgcHJlZmVyZW5jZSwgd2Ugd2ls bCBwdXNoIGVmZm9ydCB0byB0aGUgdHJhbnNtaXR0ZXIgb3ZlciB0aGUgcmVjZWl2ZXIgYXMgaW4g bWFueSB1c2UgY2FzZXMgdGhlcmUgYXJlIG1hbnkgbW9yZSByZWNlaXZlcnMuIEdpdmVuIHRoYXQs IGl0IGlzIG1vcmUgY29tcGxleCBmb3IgYSByZWNlaXZlciB0byBoYXZlIGRpZmZlcmVudCB3YXlz IG9mIG1hbmFnaW5nIHRoZSByZWNlaXB0IG9mIG11bHRpcGxlIGV2ZW50cyBhcyBub3QgYWxsIGlz c3VlcnMgd2lsbCBidW5kbGUgdGhlIGV2ZW50cywgc28gaXQgaXMgc2ltcGxlciB0byBoYXZlIG9u bHkgb25lIGV2ZW50IHBlciBTRVQuIEluY2x1ZGluZyB0aGUgc2VwYXJhdGUgZXZlbnRzIHdpdGgg YSBVUkkgYXMgYW4gbHZhbHVlIGlzIGNoYWxsZW5naW5nIHRvIGltcGxlbWVudCwgc3BlYWtpbmcg ZnJvbSBleHBlcmllbmNlLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KT24gVHVlLCBPY3QgMzEs IDIwMTcgYXQgMTE6MDUgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpNYXJpdXPigJkg cHJvcG9zZWQgc3ludGF4LCBwYXN0ZWQgaW4gYmVsb3csIGhhcyBleGFjdGx5IHRoaXMgY2hhcmFj dGVyaXN0aWMuICBUaGUgd2F5IEkgc2VlIGl0LCBoaXMgcHJvcG9zYWwgZXNzZW50aWFsbHkgaGFz IGEgcHJpbWFyeSBwYXNzd29yZFJlc2V0IGV2ZW50IGFuZCBhIHNlY29uZGFyeSBwYXNzd29yZFJl c2V0RXh0IGRhdGEgc3RydWN0dXJlLCB3aGljaCBjb3VsZCBoYXZlIGJlZW4gc2ltcGx5IGFub3Ro ZXIgZXZlbnQgdmFsdWUgaW4gdGhlIGN1cnJlbnQgZHJhZnQuDQoNClRoaXMgYnJlYWtpbmcgY2hh bmdlIG1ha2VzIHRoZSBkYXRhIHN0cnVjdHVyZXMgbW9yZSBjb21wbGljYXRlZCAtIG5vdCBsZXNz LiAgQW5kIGl0IG1ha2VzIHRoaW5ncyB0aGF0IHVzZWQgdG8gYmUgcG9zc2libGUgaW1wb3NzaWJs ZSwgcmVkdWNpbmcgZmxleGliaWxpdHkgdG8gdGhvc2Ugd2hvIHdvdWxkIHVzZSB0aGUgc3BlYy4N Cg0KVGhlc2Ugc2VlbSBsaWtlIGJhZCB0cmFkZW9mZnMgdG8gbWUuDQoNCnsNCiAgImp0aSI6ICIz ZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCIsDQogICJpYXQiOiAxNDU4NDk2MDI1LA0K ICAiaXNzIjogImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbTxodHRwczovL3NjaW0uZXhhbXBsZS5j b20vPiIsDQogICJhdWQiOiBbDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85 OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiwNCiAgICAiaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29t L0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciDQogICBdLA0KICAgImV2ZW50X3R5cGUi OiAiaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiLA0KICAg ImV2ZW50Ijogew0KICAgICAgICAgImlkIjoiNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsDQog ICAgICAgICAiZXh0ZW5zaW9ucyI6IHsNCiAgICAgICAgICAgImh0dHBzOi8vZXhhbXBsZS5jb20v c2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh04oCdOiB7DQogICAgICAgICAgICAgInJlc2V0QXR0 ZW1wdHMiOjUsDQogICAgICAgICAgIH0NCiAgICAgICAgIH0NCiAgICAgICB9DQp9DQoNCkluIHBh cnRpY3VsYXIsIGl0IG1ha2VzIGl0IGltcG9zc2libGUgdG8gc2lnbiBtdWx0aXBsZSByZWxhdGVk IGV2ZW50cyBzaGFyaW5nIGEgY29tbW9uIGNsYWltcyBzY2hlbWEgd2l0aCBhIHNpbmdsZSBzaWdu YXR1cmUgYnkgdGhlIGlzc3Vlci4gIEl0IGZvcmNlcyB0aGUgaXNzdWVyIHRvIGRvIHRoZSBleHRy YSB3b3JrIG9mIHNpZ25pbmcgZWFjaCBvZiB0aGUgcmVsYXRlZCBldmVudHMgKG9yIGZhY2V0cyBv ZiB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50KSBpbmRpdmlkdWFsbHkgYW5kIGZvcmNlcyB0aGUgcmVj aXBpZW50cyB0byBkbyB0aGUgZXh0cmEgd29yayBvZiBjaGVja2luZyBhbGwgdGhvc2UgdW5uZWNl c3Nhcnkgc2lnbmF0dXJlcy4NCg0KTm90IGV2ZXJ5IHByb2ZpbGUgd2lsbCBldmVyIGhhdmUgbXVs dGlwbGUga2V5cyBpbiB0aGUg4oCcZXZlbnRz4oCdIHNldCBidXQgdGhlcmXigJlzIGFic29sdXRl bHkgbm8gcmVhc29uIHRvIHByZWNsdWRlIGl0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBJZC1ldmVudCBb bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNA aWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRGljayBIYXJkdA0KU2VudDogVHVlc2RheSwgT2N0b2Jl ciAzMSwgMjAxNyA5OjUyIFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFlhcm9uIFNo ZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29t Pj47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0 bzpyaWNoYW5uYUBhbWF6b24uY29tPj47IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50 QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+OyBQaGlsIEh1bnQgKElETSkgPHBo aWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQoNClN1Ympl Y3Q6IFJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQ/ DQoNClBsZWFzZSBkaXJlY3QgbWUgdG8gYSBwcm9wb3NhbCB0aGF0IGhhcyBhICJwcmltYXJ5IiBh bmQgInNlY29uZGFyeSIgZXZlbnRzLiBJIGFncmVlIHRoYXQgaXMgdW5kZXNpcmFibGUuIEkgd291 bGQgYWxzbyBlbmNvdXJhZ2UgdG8gZW5nYWdlIGluIHRoZSBkaXNjdXNzaW9ucyBzbyB0aGF0IHdl IGNhbiBkcml2ZSBjbGFyaXR5IGFuZCBzaW1wbGljaXR5Lg0KDQpJIHRoaW5rIHRoZSBwcm9wb3Nh bCBpcyB0aGF0IHRoZXJlIGlzIG9uZSBldmVudCBwZXIgU0VULg0KDQpJIHRoaW5rIGhhdmluZyBt b3JlIHRoYW4gb25lIGV2ZW50IHBlciBTRVQgYWRkcyBjb21wbGV4aXR5IGFzIGEgcmVjZWl2ZXIg bXVzdCBkZWFsIHdpdGggcmVjZWl2aW5nIGNvcnJlbGF0ZWQgZXZlbnRzIGluIG9uZSBTRVQgYXMg d2VsbCBhcyBjb3JyZWxhdGVkIGV2ZW50cyBpbiB0aGUgc2FtZSBTRVQuDQoNCi9EaWNrDQoNCk9u IFR1ZSwgT2N0IDMxLCAyMDE3IGF0IDk6NDIgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6 DQpJIGhlYXIgeW91IG9uIHRoZSBmYWN0IHRoYXQgZGlmZmVyZW50IHBlb3BsZSBoYXZlIGpvaW5l ZCB0aGUgZWZmb3J0IGF0IGRpZmZlcmVudCB0aW1lcy4gIFRoYXTigJlzIGEgbm9ybWFsIHByb2Nl c3MgYXMgYW4gZWZmb3J0IGJ1aWxkcyBtb21lbnR1bS4gIEkgZ2V0IHRoYXQgbm90IGV2ZXJ5b25l IHdhcyB0aGVyZSB3aGVuIHByZXZpb3VzIGNvbnNlbnN1cyBjYWxscyB3ZXJlIHRha2VuLg0KDQpJ IHNob3VsZCBub3RlIHRoYXQgSSBoYXZlIHNwZWNpZmljIHRlY2huaWNhbCBvYmplY3Rpb25zIHRv IHRoZSBzcGVjaWZpYyBwcm9wb3NlZCBjaGFuZ2VzIGJlaW5nIGRpc2N1c3NlZCBhcyB3ZWxsLiAg Q3VycmVudGx5IGFsbCBldmVudHMgaW4gdGhlIHNldCBoYXZlIHRoZSBzYW1lIHN5bnRheC4gIFRo ZSBwcm9wb3NhbHMsIGFzIEkgdW5kZXJzdGFuZCB0aGVtLCByZXZlcnQgdXMgdG8gYSBzdGF0ZSB3 aGVyZSB0aGVyZeKAmXMgYSDigJxwcmltYXJ54oCdIGFuZCDigJxzZWNvbmRhcnnigJ0gZXZlbnRz LCB3aXRoIGRpZmZlcmVudCBzeW50YXggZm9yIHRoZSB0d28gY2xhc3Nlcy4gIFRoYXTigJlzIG5l ZWRsZXNzbHkgbW9yZSBjb21wbGljYXRlZCwgYWRkaW5nIG5vIGFjdHVhbCB2YWx1ZS4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0tIE1pa2UNCg0KRnJvbTogRGljayBIYXJkdCBbbWFpbHRvOmRpY2suaGFyZHRAZ21haWwu Y29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT5dDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVy IDMxLCAyMDE3IDk6MzcgUE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQpDYzogUGhpbCBIdW50 IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+ PjsgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0 ZkBnbWFpbC5jb20+PjsgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpv bi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PjsgSUQgRXZlbnRzIE1haWxpbmcgTGlz dCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj4NCg0KU3ViamVj dDogUmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD8N Cg0KTWlrZQ0KDQpBcyB5b3Ugd2VsbCBrbm93LCBtYW55IHBlb3BsZSBpbiBhIFdHIGRvbid0IGxv b2sgY2xvc2VseSBhdCBhIHNwZWNpZmljYXRpb24gdW50aWwgbGFzdCBjYWxsIGlzIG1hZGUuIEFk ZGl0aW9uYWxseSwgd2UgYXJlIGNvbWluZyB1cCBvbiBvbmx5IHRoZSAzcmQgV0cgbWVldGluZy4g VGhlIFdHIGhhcyBub3QgZXhpc3RlZCBmb3IgdmVyeSBsb25nLiBXaGlsZSBzb21lIG9mIHRoZSBw YXJ0aWNpcGFudHMgaGF2ZSBiZWVuIHdvcmtpbmcgb24gdGhpcyBmb3IgYSB3aGlsZSwgbWFueSBo YXZlIG5vdCwgYW5kIHdlIGFyZSBsb29raW5nIGZvciBjb25zZW5zdXMgYWNyb3NzIHRoZSBXRy4N Cg0KU2luY2UgU2VjRXZlbnQgaXMgYSBmcmFtZXdvcmsgdGhhdCB3ZSBleHBlY3QgdG8gYmUgcHJv ZmlsZWQsIEkgZmVlbCBpdCBpcyBpbXBvcnRhbnQgdG8gZW5zdXJlIHRoYXQgU2VjRXZlbnQgc3Bl Y2lmaWNhdGlvbnMgYXJlIGVhc3kgZm9yIGEgdmFyaWV0eSBvZiBwcm9maWxlcyB0byBhZG9wdCwg YW5kIHRoYXQgdGhlIHNlbWFudGljcyBtYWtlIHNlbnNlLiBJIGFsc28gdGhpbmsgdGhhdCBwcm9w ZXJ0aWVzIHRoYXQgYXJlIHNwZWNpZmljIHRvIGEgcHJvZmlsZSBzaG91bGQgYmUgbGVmdCB0byB0 aGF0IHByb2ZpbGUgYW5kIG5vdCBiZSBpbmNsdWRlZCBpbiBTZWNFdmVudC4NCg0KU2luY2UgdGhp cyBpcyBhIGZyYW1ld29yaywgaXQgaXMgZXhwZWN0ZWQgdGhhdCBhcyBkaWZmZXJlbnQgZ3JvdXBz IHByb2ZpbGUgaXQsIHRoZXJlIHdpbGwgYmUgYWRkaXRpb25hbCBmZWVkYmFjay4NCg0KU3BlY2lm aWNhbGx5LCBhcyBhIHBhcnRpY2lwYW50IGluIHRoZSBSSVNDIHByb2ZpbGUgb2YgU0VULCBhIG51 bWJlciBvZiBpc3N1ZXMgaW4gU0VUIGhhdmUgc3VyZmFjZWQgYXMgdGhlIFJJU0MgV0cgaGFzIGxv b2tlZCBhdCBob3cgdG8gdXNlIHRoZSBTRVQuDQoNCkFzIGZvciBTRVQgYmVpbmcgc3RhYmxlIGZv ciBvdmVyIGEgeWVhciwgdGhlcmUgaGF2ZSBiZWVuIGEgbnVtYmVyIG9mIGNoYW5nZXMgdG8gU0VU IHNpbmNlIHRoZW4uIEkgYWxzbyBkb24ndCB0aGluayB0aGVyZSB3YXMgY29uc2Vuc3VzLiBCZWZv cmUgdGhlIFdHIHdhcyBmb3JtZWQsIEkgYW5kIHNldmVyYWwgb3RoZXJzIGhhZCBleHByZXNzZWQg Y29uY2VybiBvbiB0aGUgZGVzaWduIG9mIFNFVCB3aGVuIFBoaWwgcHJlc2VudGVkIGl0IGF0IGFu IElJVyBzZXNzaW9uLg0KDQpBcyB0byB0YWtpbmcgYW5vdGhlciB5ZWFyLCBJIGFtIGhvcGVmdWwg d2UgY2FuIHJlc29sdmUgdGhlIHJlbWFpbmluZyBpc3N1ZXMgaW4gU0VUIGFuZCBwdWJsaXNoIGEg bmV3IGRyYWZ0IGZvciBsYXN0IGNhbGwuIEkgZG8gbm90IHRoaW5rIHdlIHdpbGwgbmVlZCB0byB3 YWl0IGZvciBhbm90aGVyIFdHIG1lZXRpbmcgdG8gYXNrIGZvciBsYXN0IGNhbGwuDQoNCldlIGFs c28gaGF2ZSBhIG51bWJlciBvZiBvdGhlciBkb2N1bWVudHMgdGhhdCBhcmUgbm90IGluIGxhc3Qg Y2FsbCwgYW5kIHdlIGRvbid0IGhhdmUgYSBXRyBhZG9wdGVkIGRyYWZ0IHlldCBmb3IgbWFuYWdl bWVudC4gU28gdGhlcmUgYXJlIHN0aWxsIGEgbnVtYmVyIG9mIGRvY3VtZW50cyB0byB3b3JrIHRo cm91Z2ggYmVmb3JlIHdlIGhhdmUgYWxsIHRoZSBiaXRzIGZvciBzb21lb25lIHRvIHdvcmsgd2l0 aC4NCg0KSSBkbyB0aGluayB3ZSBoYXZlIGJlZW4gbWFraW5nIGdvb2QgcHJvZ3Jlc3Mgc2luY2Ug dGhlIGxhc3QgSUVURiBtZWV0aW5nLCBhbmQgSSBhbSBob3BlZnVsIHdlIGNhbiBrZWVwIHVwIHRo aXMgbW9tZW50dW0gYW5kIGZpbmFsaXplIGFsbCB0aGUgZG9jdW1lbnRzIGluIGEgdGltZWx5IG1h bm5lci4NCg0KL0RpY2sNCg0KDQpPbiBUdWUsIE9jdCAzMSwgMjAxNyBhdCAxMjo0OCBQTSwgTWlr ZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkl04oCZcyBoYXJkIGZvciBtZSB0byBldmVuIGV4cHJl c3MgbXkgbGV2ZWwgb2YgZnJ1c3RyYXRpb24gd2l0aCB0aGUgcmVjZW50IGF0dGVtcHRzIHRvIG9u Y2UgYWdhaW4gcmVkZXNpZ24gdGhlIFNlY0V2ZW50IFRva2VuIHNwZWMuICBXZeKAmXZlIGJlZW4g YXQgdGhpcyBmb3IgbXVsdGlwbGUgeWVhcnMgYmVjYXVzZSBwZW9wbGUga2VlcCB0cnlpbmcgdG8g cmV2aXNpdCBkZWNpc2lvbnMgdGhhdCB3ZXJlIGxvbmcgYWdvIG1hZGUgYnkgY29uc2Vuc3VzLiAg SXTigJlzIGJlZW4gc3RhYmxlIGZvciBvdmVyIGEgeWVhciBhbmQgdGhlIG1ham9yaXR5IG9mIFdH TEMgcmVzcG9uZGVudHMgc2FpZCBzb21lIHZhcmlhbnQgb2Yg4oCcV29ya3MgZm9yIG1lIOKAkyBz aGlwIGl0IeKAnQ0KDQpUaGVyZeKAmXMgbm90IHN1ZmZpY2llbnQganVzdGlmaWNhdGlvbiB0byB0 cnkgdG8gdW5kbyBjb25zZW5zdXMgcG9zaXRpb25zIHRoYXQgaGF2ZSBiZWVuIGRlYmF0ZWQgYW5k IGFmZmlybWVkIG92ZXIgYW5kIG92ZXIuICBDb3VudGVuYW5jaW5nIHdob2xlc2FsZSBjaGFuZ2Vz IGF0IHRoaXMgbGF0ZSBkYXRlIGlzIGNvdW50ZXJwcm9kdWN0aXZlIGluIHRoZSBleHRyZW1lIQ0K DQpJdOKAmXMgZmFyIGJldHRlciB0aGFuIGdvb2QgZW5vdWdoIGFzLWlzLiAgSW4gbXkgZXhwZXJp ZW5jZSwgaWYgd2Ugc3RhcnQgcmVkZXNpZ25pbmcgaXQsIGl0IHdpbGwgcmVzdWx0IGluIGFub3Ro ZXIgeWVhcuKAmXMgZGVsYXkuICBJdCBkb2VzIHNvbWV0aGluZyBzaW1wbGUgYW5kIHVzZWZ1bC4g IFBsZWFzZSwgbGV04oCZcyBqdXN0IHNoaXAgaXQsIHNvIHBlb3BsZSBjYW4gcmVseSBvbiBpdC4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0tIE1pa2UNCg0KRnJvbTogUGhpbCBIdW50IChJRE0pIFttYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPl0NClNlbnQ6IE1vbmRheSwgT2N0b2Jl ciAzMCwgMjAxNyAyOjQyIFBNDQpUbzogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208 bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkNjOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYu aWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+OyBSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1h em9uLmNvbT4+OyBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxp ZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KDQpTdWJqZWN0OiBS ZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPw0KDQpJ bmxpbmUuLi4NCg0KUGhpbA0KDQpPbiBPY3QgMzAsIDIwMTcsIGF0IDI6MjIgUE0sIERpY2sgSGFy ZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdy b3RlOg0KSGkgUGhpbA0KDQpDb3JyZWN0IG1lIGlmIEkgYW0gbWlzdW5kZXJzdGFuZGluZywgYnV0 IHRoZXJlIGlzIGEgUklTQyBwcm9maWxlIGV2ZW50DQoNCg0KDQoiaHR0cDovL3NjaGVtYXMub3Bl bmlkLm5ldC9zZWNldmVudC9yaXNjL2V2ZW50LXR5cGUvPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZlbnRf cmlzY19ldmVudC0yRHR5cGVfLTI1NUMmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBa aDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkx YUxjTE40S1pOQSZtPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cm cz0yNWwwOXNIOFlWNDJ4emdVLUNYU2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmU9PmFjY291bnQt Y3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWTigJ0NCg0KDQphbmQgYW4gU0NJTSBwcm9maWxlIGV2 ZW50DQoNCg0KImh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0 4oCdDQoNCg0KSSdtIHN1Z2dlc3RpbmcgdGhhdCB0d28gZGlmZmVyZW50IGV2ZW50cyB3b3VsZCBi ZSBzZW50LiBFbWJlZGRpbmcgb25lIGluIHRoZSBvdGhlciBkb2VzIG5vdCBtYWtlIHNlbnNlLg0K PHBoPkl0IGlzIGEgaHlwb3RoZXRpY2FsIGV4YW1wbGUuIEp1c3QgYmVjYXVzZSB5b3UgZGlzYWdy ZWUgb24gdGhpcyBkb2VzIG5vdCBtZWFuIG90aGVycyBhcmUgbm90IHZhbGlkLg0KDQpJIGp1c3Qg cGlja2VkIG92ZXJsYXBwaW5nIHByb3Bvc2FscyB0aGF0IGhhdmUgZGlmZmVyZW50IG1lYW5pbmcg KGJ1dCBub3QgdGhlIHNhbWUpIHRvIGlsbHVzdHJhdGUgdGhlIGRpZmZlcmVuY2UgZnJvbSBpc3N1 aW5nIGEgc2luZ2xlIHNldCB3aXRoIGRpZmZlcmVudCBldmVudHMuDQoNCkFzIEkgaGF2ZSBzdGF0 ZWQgdGhpcyBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIGFzc2VydGluZyBtdWx0aXBsZSBkaXN0aW5j dCBldmVudHMgaW4gb25lIFNFVC4NCg0KQWxzbywgSSB0aGluayBpdCBpcyBzaW1wbGVyIHRvIGhh dmUgZXZlbnRfdHlwZSBiZSBhdCB0aGUgc2FtZSBsZXZlbCBhcyBldmVudA0KDQo8cGg+bWF5IGJl LiBJIHdhcyB3b3JraW5nIGZyb20gQW5uYWJlbGxlJ3MgcHJvcG9zZWQgZm9ybWF0Lg0KDQp7DQog ICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KICAiaWF0IjogMTQ1 ODQ5NjAyNSwNCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5jb208aHR0cHM6Ly9zY2lt LmV4YW1wbGUuY29tLz4iLA0KICAiYXVkIjogWw0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5j b20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsDQogICAgImh0dHBzOi8vamh1Yi5l eGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Ig0KICAgXSwNCiAgICJl dmVudF90eXBlIjogImh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0 RXh0IiwNCiAgICJldmVudCI6IHsNCiAgICAgICAgICJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3 NTIxZDkiLA0KICAgICAgICAgInJlc2V0QXR0ZW1wdHMiOjUNCiAgICAgICB9DQp9DQoNCnsNCiAg Imp0aSI6ICIzZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCIsDQogICJpYXQiOiAxNDU4 NDk2MDI1LA0KICAiaXNzIjogImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbTxodHRwczovL3NjaW0u ZXhhbXBsZS5jb20vPiIsDQogICJhdWQiOiBbDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNv bS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiwNCiAgICAiaHR0cHM6Ly9qaHViLmV4 YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciDQogICBdLA0KICAgImV2 ZW50X3R5cGUiOiAiaHR0cDovL3NjaGVtYXMub3BlbmlkLm5ldC9zZWNldmVudC9yaXNjL2V2ZW50 LXR5cGUvYWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZDxodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVuaWQubmV0X3Nl Y2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlX2FjY291bnQtMkRjcmVkZW50aWFsLTJEY2hhbmdlLTJE cmVxdWlyZWQmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVh cElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPWl5 Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmcz1uUXk5ZXpQUmpER2R2 UlRDYWlEdGk0T0hlbEgzREtnVUNUS2pGMkdRLXNvJmU9PiIsDQogICAiZXZlbnQiOiB7DQogICAg ICAg4oCcc3Vi4oCdOuKAnTczNzU2MjZBNjU2Mzc04oCdLA0KICAgICAgIOKAnGlzc+KAnToiaHR0 cHM6Ly9pZHAuZXhhbXBsZS5jb20vIg0KICAgICAgIH0NCn0NCg0KDQoNCg0KDQpPbiBNb24sIE9j dCAzMCwgMjAxNyBhdCAxMjowOSBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCkFubmFiZWxsZS9EaWNrLA0KDQpU aGFua3MgZm9yIHRoZSBjb21tZW50cy4gSSB0aGluayB3ZSBuZWVkIHRvIGV4YW1pbmUgdGhlIGNv bnNlcXVlbmNlcyBvZiB0aGUgcHJvcG9zYWwgaW4gSlNPTi4NCg0KQXMgSSBzdGF0ZWQsIHdoYXQg Y2F1c2VzIG1vc3Qgb2YgdGhlIGlzc3VlIGlzIHRoZSBwcm9wb3NlZCBleHRlbnNpb24gbWVjaGFu aXNtIGluIHRoZSBwYXlsb2FkIChwb3NzaWJseSB1c2luZyBldmVudHMgaW4gYSByZWN1cnNpdmUg d2F5KS4gRG9lcyBpdCBmb2xsb3cgdGhlIG9sZCBmb3JtYXQgb3IgdGhlIG5ldz8NCg0KTGV04oCZ cyAgY29uc2lkZXIgYSB1c2UgY2FzZSB3aGVyZSB3ZSBoYXZlIGFuIGlkZW50aXR5IG1hbmFnZW1l bnQgc3lzdGVtIHRoYXQgdXNlcyBTQ0lNLCBidXQgdGhlIFNDSU0gc3lzdGVtIGlzIGFsc28gdGhl IHVuZGVybHlpbmcgZGF0YSBzdG9yZSBmb3IgQ29ubmVjdC4gIEEgUGFzc3dvcmQgcmVzZXQgbWln aHQgZ2VuZXJhdGUgdGhlIGZvbGxvd2luZyBldmVudCB3aGljaCBoYXMgYW4gZXh0ZW5zaW9uIChj b252ZXlpbmcgcmVzZXQgY291bnQpIEFORCBvdmVybGFwcGluZyBzdGF0ZW1lbnQgZnJvbSBSSVND LiAgQk9USCBvZiB3aGljaCBtaWdodCBiZSBpbXBvcnRhbnQgdG8gYSBzaW1pbGFyIHJlY2VpdmVy IHVzaW5nIFNDSU0gYW5kIE9JREMuDQoNClRoZSAwMyBzcGVjIGN1cnJlbnRseSB3b3VsZCBhbGxv dzoNCg0KDQp7DQoNCiAgImp0aSI6ICIzZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCIs DQoNCiAgImlhdCI6IDE0NTg0OTYwMjUsDQoNCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBs ZS5jb208aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLz4iLA0KDQogICJhdWQiOiBbDQoNCiAgICAi aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQi LA0KDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0 MWQ3Njc2ZWU3Ig0KDQogICBdLA0KDQogICAiZXZlbnRzIjogew0KDQogICAgICJ1cm46aWV0Zjpw YXJhbXM6c2NpbTpldmVudDpwYXNzd29yZFJlc2V0IjoNCg0KICAgICAgIHsgImlkIjoiNDRmNjE0 MmRmOTZiZDZhYjYxZTc1MjFkOSJ9LA0KDQogICAgICJodHRwczovL2V4YW1wbGUuY29tL3NjaW0v ZXZlbnQvcGFzc3dvcmRSZXNldEV4dCI6DQoNCiAgICAgICB7ICJyZXNldEF0dGVtcHRzIjo1fSwN Cg0KICAgICAiaHR0cDovL3NjaGVtYXMub3BlbmlkLm5ldC9zZWNldmVudC9yaXNjL2V2ZW50LXR5 cGUvXDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9f c2NoZW1hcy5vcGVuaWQubmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlXy0yNTVDJmQ9RHdN RmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZW ekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1peVZuclptcjlfdUdDUTZN RDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JnM9MjVsMDlzSDhZVjQyeHpnVS1DWFNnOHhIOXR2 eURKejQwdENSakZhbGhrdyZlPT4NCiAgICAgICBhY2NvdW50LWNyZWRlbnRpYWwtY2hhbmdlLXJl cXVpcmVkIjogew0KDQogICAgICAgICDigJxzdWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0sDQoN CiAgICAgICAgIOKAnGlzc+KAnToiaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vIg0KDQogICAgICAg fQ0KDQogIH0NCg0KfQ0KDQoNCg0KSW4gdGhlIGFib3ZlIC0gZWFjaCBwYXlsb2FkIGlzIGEg4oCY cGVlcicgYW5kIGlzc3VlZCB3aXRob3V0IHByZWZlcmVuY2UgYnkgdGhlIHRyYW5zbWl0dGVyLiBU aGUgcmVjZWl2ZXIgY2FuIGFzc2lnbiBwcmlvcml0eSBpbiBpdHMgb3duIGNvbnRleHQgaWYgdGhh dCBtYXR0ZXJzLg0KDQoNCg0KVGhlIG5ldyBwcm9wb3NhbDoNCg0KDQoNCnsNCg0KICAianRpIjog IjNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwIiwNCg0KICAiaWF0IjogMTQ1ODQ5NjAy NSwNCg0KICAiaXNzIjogImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbTxodHRwczovL3NjaW0uZXhh bXBsZS5jb20vPiIsDQoNCiAgImF1ZCI6IFsNCg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5j b20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsDQoNCiAgICAiaHR0cHM6Ly9qaHVi LmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciDQoNCiAgIF0sDQoN CiAgICJldmVudCI6IHsNCg0KICAgICDigJxldmVudF90eXBl4oCdOiJ1cm46aWV0ZjpwYXJhbXM6 c2NpbTpldmVudDpwYXNzd29yZFJlc2V04oCdLA0KDQogICAgICJpZCI64oCdNDRmNjE0MmRmOTZi ZDZhYjYxZTc1MjFkOeKAnSwNCg0KICAgICDigJxldmVudHPigJ06ew0KDQogICAgIC0+bm90ZSDi gKZpcyB0aGlzIHRoZSBvbGQgb3IgbmV3IHN0cnVjdHVyZT8gPC0NCg0KICAgICAgICJodHRwczov L2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dCI6DQoNCiAgICAgICAgIHsg InJlc2V0QXR0ZW1wdHMiOjV9LA0KDQogICAgICAgImh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQv c2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL1w8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2 ZW50LTJEdHlwZV8tMjU1QyZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJ ck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRL Wk5BJm09aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZzPTI1bDA5 c0g4WVY0Mnh6Z1UtQ1hTZzh4SDl0dnlESno0MHRDUmpGYWxoa3cmZT0+DQogICAgICAgICBhY2Nv dW50LWNyZWRlbnRpYWwtY2hhbmdlLXJlcXVpcmVkIjogew0KDQogICAgICAgICDigJxzdWLigJ06 4oCdNzM3NTYyNkE2NTYzNzTigJ0sDQoNCiAgICAgICAgIOKAnGlzc+KAnToiaHR0cHM6Ly9pZHAu ZXhhbXBsZS5jb20vIg0KDQogICAgICAgfQ0KDQogICAgIH0NCg0KICAgfQ0KDQp9DQoNCg0KDQpJ biB0aGUgYWJvdmUsIHN1Yi1ldmVudHMgb3IgZXh0ZW5zaW9ucyBoYXZlIGEgZGlmZmVyZW50IGZv cm1hdC4gVGhlIHNhbWUgY29tcGxhaW50IGFib3V0IHRoZSBvcmlnaW5hbCBzdGFuZHMuDQoNCg0K DQoqT1IqIChpZiB0aGUgcmVjZWl2ZXIgY2FyZXMgYWJvdXQgUklTQyBtb3JlKS4gIE5vdGUgdGhh dCB0aGlzIGxlYWRzIHRvIGEgdHJpcGxlIG5lc3RlZCBzdHJ1Y3R1cmUuDQoNCg0KDQp7DQoNCiAg Imp0aSI6ICIzZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCIsDQoNCiAgImlhdCI6IDE0 NTg0OTYwMjUsDQoNCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5jb208aHR0cHM6Ly9z Y2ltLmV4YW1wbGUuY29tLz4iLA0KDQogICJhdWQiOiBbDQoNCiAgICAiaHR0cHM6Ly9qaHViLmV4 YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLA0KDQogICAgImh0dHBz Oi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Ig0KDQog ICBdLA0KDQogICAiZXZlbnQiOiB7DQoNCiAgICAg4oCcZXZlbnRfdHlwZeKAnToiaHR0cDovL3Nj aGVtYXMub3BlbmlkLm5ldC9zZWNldmVudC9yaXNjL2V2ZW50LXR5cGUvXDxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVuaWQubmV0 X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlXy0yNTVDJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dh V0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlY UHB1WXFQa0FJMWFMY0xONEtaTkEmbT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZf OHU4X3FTQ193JnM9MjVsMDlzSDhZVjQyeHpnVS1DWFNnOHhIOXR2eURKejQwdENSakZhbGhrdyZl PT4NCg0KICAgICAgICAgICAgIGFjY291bnQtY3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWTigJ0s DQoNCiAgICAgIOKAnHN1YuKAnTrigJ03Mzc1NjI2QTY1NjM3NOKAnSwNCg0KICAgICAg4oCcaXNz 4oCdOiJodHRwczovL2lkcC5leGFtcGxlLmNvbS/igJw8aHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20v JUUyJTgwJTlDPiwNCg0KICAgICAg4oCcZXZlbnRz4oCdOnsNCg0KICAgICAgICAidXJuOmlldGY6 cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldCI6DQoNCiAgICAgICAgew0KDQogICAgICAg ICAgImlkIjrigJ00NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ54oCdLA0KDQogICAgICAgICAg4oCc ZXZlbnRz4oCdOnsNCg0KICAgICAgICAgICAgICJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZl bnQvcGFzc3dvcmRSZXNldEV4dCI6DQoNCiAgICAgICAgICAgICAgIHsgInJlc2V0QXR0ZW1wdHMi OjV9LA0KDQogICAgICAgICAgfQ0KDQogICAgICAgIH0NCg0KICAgICAgfQ0KDQogICB9DQoNCn0N Cg0KDQoNCkluIHRoZSBhYm92ZSwgdGhlIGV4dGVuc2lvbiBpcyBwbGFjZWQgaW5zaWRlIHRoZSBl dmVudCBpdCBleHRlbmRzLiBJdCBmb2xsb3dzIHRoZSBvbGQgZm9ybWF0IChvciBzaG91bGQgaXQg Zm9sbG93IHRoZSBuZXc/KQ0KDQoqT1IqIEZvbGxvd2luZyB0aGUgdG9wIGxheWVyIHBhdHRlcm4g b2Ygc2luZ3VsYXIgZXZlbnQgIE5vdGUgdGhhdCB0aGlzIGxlYWRzIHRvIGEgdHJpcGxlIG5lc3Rl ZCBzdHJ1Y3R1cmUuDQoNCg0KDQp7DQoNCiAgImp0aSI6ICIzZDBjM2NmNzk3NTg0YmQxOTNiZDBm YjFiZDRlN2QzMCIsDQoNCiAgImlhdCI6IDE0NTg0OTYwMjUsDQoNCiAgImlzcyI6ICJodHRwczov L3NjaW0uZXhhbXBsZS5jb208aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLz4iLA0KDQogICJhdWQi OiBbDQoNCiAgICAiaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJj ODc5NTkzYjc3NTQiLA0KDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2 MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Ig0KDQogICBdLA0KDQogICAiZXZlbnQiOiB7DQoNCiAgICAg 4oCcZXZlbnRfdHlwZeKAnToiaHR0cDovL3NjaGVtYXMub3BlbmlkLm5ldC9zZWNldmVudC9yaXNj L2V2ZW50LXR5cGUvXDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cC0zQV9fc2NoZW1hcy5vcGVuaWQubmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlXy0y NTVDJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0pu RSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1peVZuclpt cjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JnM9MjVsMDlzSDhZVjQyeHpnVS1D WFNnOHhIOXR2eURKejQwdENSakZhbGhrdyZlPT4NCg0KICAgICAgICAgICAgIGFjY291bnQtY3Jl ZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWTigJ0sDQoNCiAgICAgIOKAnHN1YuKAnTrigJ03Mzc1NjI2 QTY1NjM3NOKAnSwNCg0KICAgICAg4oCcaXNz4oCdOiJodHRwczovL2lkcC5leGFtcGxlLmNvbS/i gJw8aHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vJUUyJTgwJTlDPiwNCg0KICAgICAg4oCcZXZlbnTi gJ06ew0KDQogICAgICAgIOKAnGV2ZW50X3R5cGXigJ06InVybjppZXRmOnBhcmFtczpzY2ltOmV2 ZW50OnBhc3N3b3JkUmVzZXTigJ0sDQoNCiAgICAgICAgImlkIjrigJ00NGY2MTQyZGY5NmJkNmFi NjFlNzUyMWQ54oCdLA0KDQogICAgICAgIOKAnGV2ZW504oCdOnsNCg0KICAgICAgICAgIOKAnGV2 ZW50X3R5cGXigJ06Imh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0 RXh04oCdLA0KDQogICAgICAgICAgInJlc2V0QXR0ZW1wdHMiOjUNCg0KICAgICAgICB9DQoNCiAg ICAgIH0NCg0KICAgfQ0KDQp9DQoNCg0KDQpUaGlzIGZvcm1hdCBmb2xsb3dzIHRoZSBwcm9wb3Nl ZCBzaW5ndWxhciBldmVudCBmb3JtYXQgcmVjdXJzaXZlbHkgYW5kIGlzIDMgbGF5ZXJzIGRlZXAu IE5vdGUgdGhhdCB0aGUgcGFyc2VyIGhhcyB0byBjb250aW51ZSB0byBzZWFyY2ggdGhlIGRvY3Vt ZW50IGZvciB0aGluZ3MgdGhhdCBhcmVu4oCZdCB0aGVyZSBhcyBpdCBoYXMgdG8gc3RvcCB3aGVu IG5vIOKAnGV2ZW504oCdIGF0dHJpYnV0ZSBpcyBmb3VuZCByYXRoZXIgdGhhbiBpdGVyYXRlIG92 ZXIgYW4gYXJyYXkuDQoNCg0KUGhpbA0KDQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENs b3VkIFNlcnZpY2VzIEFyY2hpdGVjdA0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlk LmNvbTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9f d3d3LmluZGVwZW5kZW50aWQuY29tJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4 QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFM Y0xONEtaTkEmbT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JnM9 OXNZaGdwRXpiN3hQbFFGbUNDWE5tSG82ZlFOOUlCdS1TSEphbWdfQjRIcyZlPT4NCnBoaWwuaHVu dEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KT24gT2N0IDMwLCAy MDE3LCBhdCA4OjU3IEFNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1h em9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KDQpSZXBsaWVzIGlu bGluZS4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCklkZW50aXR5IFNlcnZpY2Vz DQoNCg0KRnJvbTogUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20+Pg0KRGF0ZTogU3VuZGF5LCBPY3RvYmVyIDI5LCAyMDE3IGF0IDU6MjUg UE0NClRvOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJk dEBnbWFpbC5jb20+Pg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxt YWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4sICJSaWNo YXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hh bm5hQGFtYXpvbi5jb20+PiwgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5v cmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIFVz ZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQ/DQoNCkkgaG9wZSB0aGlzIGFuc3dl cnMgeW91ciBxdWVzdGlvbi4NCg0KTXkg4oCcbWF54oCdIHdhcyBiZWNhdXNlIEkgY2Fu4oCZdCBz ZWUgYSByZWFzb24gd2h5IG5vdC4gVGhlIHF1ZXN0aW9uIHNob3VsZCBiZSwgd2hhdCBpcyB0aGUg anVzdGlmaWNhdGlvbiB0byBtYWtlIOKAnGV2ZW50c+KAnSBzaW5ndWxhcj8NCltyaWNoYW5uYV1U aGUgc2luZ3VsYXIg4oCcZXZlbnTigJ0gY2xhaW0gaGFzIGNsZWFyZXIgc2VtYW50aWNzIGFuZCBp cyBlYXNpZXIgdG8gcHJvY2Vzcy4gV2Ugc2hvdWxkIG9wdCBmb3IgZWFzaWVyIHNvbHV0aW9ucyB1 bmxlc3MgdGhlcmUgYXJlIHVzZSBjYXNlcyB0aGF0IHJlcXVpcmUgbW9yZSBjb21wbGV4aXR5Llsv cmljaGFubmFdDQoNClRoZXJlIGFyZSBtYW55IHJlYXNvbnMgZm9yIG11bHRpcGxlIGV2ZW50cyBp biBhIFNFVC4gIFNvbWUgYXJlIGdvb2QsIHNvbWUgbm90IHNvIGdvb2QuIFNvbWUgb2YgdGhlIHJl YXNvbnMuLi4NCg0KMS4gIE11bHRpcGxlIGV2ZW50IHBheWxvYWRzIGV4cHJlc3Npbmcgc3RhdGVt ZW50cyBhYm91dCBsYXJnZWx5IHRoZSAqc2FtZSp0aGluZy4gRm9yIGV4YW1wbGUsIFNDSU0gcGFz c3dvcmQgcmVzZXQgQU5EIFJJU0MgcGFzc3dvcmQgcmVzZXQuICBBIFJJU0MgRXZlbnQgYW5kIGFu IE9wZW5CYW5raW5nIEV2ZW50LiBJcyBvbmUgYSBjb21wbGVtZW50IHRvIHRoZSBvdGhlcj8gIERv IHRoZXkgb3ZlcmxhcCBvciBhcmUgdGhleSBkaXN0aW5jdD8NCltyaWNoYW5uYV1Db3B5L3Bhc3Rl ZCBmcm9tIG15IGVhcmxpZXIgZW1haWw6DQpXaHkgaXMgaXQgbmVjZXNzYXJ5IG9yIGFwcHJvcHJp YXRlIHRvIGluY2x1ZGUgdGhlc2UgZXZlbnRzIGluIHRoZSBzYW1lIFNFVD8gVGhleSBhcmUgbGlr ZWx5IGJlaW5nIGdlbmVyYXRlZCBieSBkaWZmZXJlbnQgc3lzdGVtcyBhdCBkaWZmZXJlbnQgdGlt ZXMgb24gdGhlIHRyYW5zbWl0dGVy4oCZcyBzaWRlLCBjb25zdW1lZCBieSBkaWZmZXJlbnQgc3lz dGVtcyBvbiB0aGUgcmVjZWl2ZXLigJlzIHNpZGUsIGFuZCBwb3NzaWJseSBiZWluZyB0cmFuc21p dHRlZCBvdmVyIGRpZmZlcmVudCBldmVudCBzdHJlYW1zLiBJIGtub3cgdGhlIGxhdHRlciB3b3Vs ZCBiZSB0aGUgY2FzZSBmb3IgdXMsIGFzIGEgcmVjZWl2ZXIuIEV2ZW4gaWYgaXTigJlzIG5vdCwg aXMgaXQgYnVyZGVuc29tZSB0byBzZW5kIHRoZXNlIGV2ZW50cyBzZXBhcmF0ZWx5PyBXaGF0IHZh bHVlIGlzIGdhaW5lZCBpbiBjb21iaW5pbmcgdGhlbT8NCg0KQWRkaXRpb25hbGx5LCBzaW5jZSB0 aGUgc2lnbmF0dXJlIGlzIG92ZXIgdGhlIFNFVCBhbmQgbm90IHRoZSBldmVudCBvYmplY3RzLCBS ZWNlaXZlcnMgaW5kZXBlbmRlbnRseSByb3V0ZSBzZXBhcmF0ZSBldmVudHMgZnJvbSBhIHNpbmds ZSB0b2tlbiB3aXRob3V0IGVpdGhlciBsb3NpbmcgdGhlIGFiaWxpdHkgdG8gdmVyaWZ5IHRoZSBh dXRoZW50aWNpdHkgb2YgdGhlIGV2ZW50IG9yIHNoYXJpbmcgYWxsIGluZm9ybWF0aW9uIGluIHRo ZSBTRVQgd2l0aCBldmVyeSBzeXN0ZW0gaGFuZGxpbmcgYW55IGV2ZW50IGluIHRoZSB0b2tlbi5b L3JpY2hhbm5hXQ0KDQoyLiAgTXVsdGlwbGUgZXZlbnRzIHBheWxvYWRzIGV4cHJlc3NpbmcgZGlm ZmVyZW50IHN0YXRlbWVudHMgYWJvdXQgdGhlIHNhbWUgdHJhbnNhY3Rpb24gLSBSSVNDIFBhc3N3 b3JkIFJlc2V0IGFuZCBSSVNDIFNlc3Npb24gQ2FuY2VsDQpbcmljaGFubmFdU2FtZSBhcyBhYm92 ZVsvcmljaGFubmFdDQozLiAgQSBuZXcgcHJvZmlsZSBkZWZpbmVzIG5ldyBldmVudCBhdHRyaWJ1 dGVzIHRvIGJlIGFkZGVkIG9uIHRvIGFuIGV4aXN0aW5nIGV2ZW50IHR5cGUgKGEgcHVyZSBleHRl bnNpb24pDQpbcmljaGFubmFdSSBoYXZlIHN1Z2dlc3RlZCBhIHdheSB0byBzdXBwb3J0IGV4dGVu c2lvbnMgd2l0aGluIGFuIGV2ZW50IGJvZHksIG11bHRpcGxlIHRpbWVzIG5vdy4gSWYgeW91IHNl ZSBwcm9ibGVtcyB3aXRoIGl0LCBwbGVhc2UgcG9pbnQgdGhlbSBvdXQuWy9yaWNoYW5uYV0NCg0K SSB0aGluayBpdCBpcyBxdWl0ZSB2YWxpZCB0byBhbGxvdyAxIGFuZCAzLiAgMiBjb3VsZCBiZSBs aW1pdGVkIGJ5IHNwZWNpZmljIHByb2ZpbGVzIGxpa2UgUklTQyBpZiB0aGV5IHdhbnQuDQoNCkkg YW0gbm90IGluIGFncmVlbWVudCB0aGF0IG1ha2luZyBldmVudCBzaW5ndWxhciBzaW1wbGlmaWVz IGFueXRoaW5nLiBGb3Igb25lIGlzIG1ha2VzIGV4dGVuc2lvbnMgY29tcGxleCAoYW5vdGhlciBu ZXN0ZWQgSlNPTiBzdHJ1Y3R1cmUpIGFuZCBwb3RlbnRpYWxseSBjb25mbGljdGluZy4NCltyaWNo YW5uYV0NCldheXMgdGhhdCBtdWx0aXBsZS1ldmVudCBTRVRzIGFyZSBtb3JlIGNvbXBsaWNhdGVk Og0KDQogIDEuICBJdCByZXN1bHRzIGluIGEgbW9yZSBjb21wbGV4IHN0cnVjdHVyZSBmb3IgdGhl IHNpbmdsZSBldmVudCB1c2UgY2FzZSwgd2hpY2ggSSB0aGluayB3ZSBhbGwgYWdyZWUgaXMgdGhl IG1ham9yaXR5IHVzZSBjYXNlLg0KICAyLiAgTXVsdGlwbGUtZXZlbnQgU0VUcyBoYXZlIGFtYmln dW91cyBzZW1hbnRpY3MuIFRoZSBwcmVzZW5jZSBvZiB0d28gZXZlbnRzIEEgYW5kIEIgaW4gdGhl IHNhbWUgU0VUIGNvdWxkIG1lYW4gYW55IG9mOg0KDQogICAgICogICBUaGV5IGFyZSByZWxhdGVk IHRvIHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQgKGkuZS4gdGhlIHNhbWUgdGhpbmcgYXMgaWYgdGhl eSB3ZXJlIGZyb20gZGlmZmVyZW50IFNFVHMgdGhhdCBoYXZlIGEgY29tbW9uIHR4bikuDQogICAg ICogICBBIGlzIGFuIGV4dGVuc2lvbiBvZiBCLg0KICAgICAqICAgQiBpcyBhbiBleHRlbnNpb24g b2YgQS4NCiAgICAgKiAgIFRoZXkgYXJlIGFsaWFzZXMgZm9yIG9uZSBhbm90aGVyLg0KICAgICAq ICAgVGhleSBhcmUgbm90IGFjdHVhbGx5IHJlbGF0ZWQgdG8gb25lIGFub3RoZXIgaW4gYW55IHdh eS4NCg0KICAxLiAgQ2xhaW0gc2VtYW50aWNzIGJlY29tZSBoYXJkZXIgdG8gZGVmaW5lLCBhcyBk aWZmZXJlbnQgcHJvZmlsZXMgbWF5IHdhbnQgdG8gdXNlIHRoZSBzYW1lIGNsYWltcyBpbiBkaWZm ZXJlbnQgd2F5cy4NCg0KSWYgdGhlIFdHIHdhbnRzIHRvIGJsb2NrIDEgYW5kIDIgYWJvdmUsIHRo ZW4gSSBiZWxpZXZlIHdlIGhhdmUgdG8gZXN0YWJsaXNoIGFuIGV2ZW50IHJlZ2lzdHJ5IHRvIGVu c3VyZSBuZXcgRXZlbnQgcHJvZmlsZXMgZG8gbm90IG92ZXJsYXAgdG8gZWxpbWluYXRlIHRoZSBu ZWVkIHRvIGV4cHJlc3MgbXVsdGlwbGUgZXZlbnRzLg0KW3JpY2hhbm5hXUnigJltIG5vdCBzdXJl IHdoYXQgeW91IG1lYW4gYnkgdGhpcy4gQXJlIHlvdSByZWZlcnJpbmcgdG8gZXZlbnQgbmFtZXM/ IFRob3NlIGFyZSBhbHJlYWR5IGRlZmluZWQgYnkgdGhlIHNwZWMgdG8gYmUgVVJJcy5bL3JpY2hh bm5hXQ0KUGhpbA0KDQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2Vz IEFyY2hpdGVjdA0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fd3d3LmluZGVwZW5k ZW50aWQuY29tJmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVl YXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1V LWE1SEJORDBIYVRYNGFuTlpmelg3cERzZks1ZjBoOW1aOUNaa2tHaWVjJnM9S0J3S1BGbnFZX1E5 NUNUQV9fV0dDWUdUeHJEN0FHQ3h1ZW9QWG5LRVVUMCZlPT4NCnBoaWwuaHVudEBvcmFjbGUuY29t PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KT24gT2N0IDI5LCAyMDE3LCBhdCA0OjEy IFBNLCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBn bWFpbC5jb20+PiB3cm90ZToNCg0KUGhpbDoNCg0KSW4geW91ciBleGFtcGxlcyBmb3IgaGF2aW5n IGEgcGx1cmFsaXR5IG9mIGV2ZW50cywgeW91IHVzZSB0aGUgd29yZCAibWF5Iiwgd2hpY2ggbGVh ZHMgbWUgdG8gcXVlc3Rpb24gaWYgYSBwbHVyYWxpdHkgb2YgZXZlbnRzIGlzIHJlYWxseSByZXF1 aXJlZCBpbiBTRVQuDQoNCllvdSBwb3NpdCB0aGF0IGl0IHdpbGwgYmUgZGlmZmljdWx0IGZvciBh IGRpc3RyaWJ1dGVkIHN5c3RlbSB0byBjb3JyZWxhdGUgbXVsdGlwbGUgU0VUcyB3aXRoIHRoZSBz YW1lICJ0eG4iLCBidXQgdGhlIGRpc3RyaWJ1dGVkIHN5c3RlbSB3aWxsIGNlcnRhaW5seSBuZWVk IHRvIGNvcnJlbGF0ZSBldmVudHMgb24gdGhlIHNhbWUgc3ViamVjdCAtLSBjb3JyZWxhdGluZyBl dmVudHMgb24gdGhlIHNhbWUgInR4biIgb24gdGhlIHNhbWUgc3ViamVjdCBzZWVtcyBmYWlybHkg c2ltcGxlLg0KDQpJIHRoaW5rIHRoYXQgYSByZWNlaXZlciB3aWxsIG5lZWQgdG8gY29ycmVsYXRl IG11bHRpcGxlIFNFdHMgb24gdGhlIHNhbWUgc3ViamVjdCwgc28gaGF2aW5nIG11bHRpcGxlIGV2 ZW50cyBpbiBhIFNFVCBpcyByZWR1bmRhbnQsIGFuZCBhZGRzIGNvbXBsZXhpdHkgd2l0aCBubyBj bGVhciBiZW5lZml0IHRoYXQgSSBjYW4gc2VlLg0KDQpBbiBpbXBsZW1lbnRvciBtYXkgY2hvb3Nl IHRvIHNlbmQgbXVsdGlwbGUgU0VUcywgb3Igc2VuZCBhIHNpbmdsZSBTRVQgd2l0aCBtdWx0aXBs ZSBldmVudHMsIHNvIGEgcmVjZWl2ZXIgd2lsbCBuZWVkIHRvIHN1cHBvcnQgYm90aC4gSSBwcmVm ZXIgd2UgcGljayBvbmUgd2F5IGFuZCBtaW5pbWl6ZSB0aGUgY29kZSBwYXRocywgYW5kIHdlIHdp bGwgbmVlZCB0byBzdXBwb3J0IGNvcnJlbGF0aW5nIGFjcm9zcyBtdWx0aXBsZSBTRVRzLCBzbyB0 aGF0IHNlZW1zIHRoZSBiZXN0IG1lY2hhbmlzbS4NCg0KTGV0IG1lIGtub3cgaWYgdGhlcmUgaXMg c29tZXRoaW5nIEkgbWlzc2VkIGluIG15IGxvZ2ljLg0KDQovRGljaw0KDQoNCk9uIFN1biwgT2N0 IDI5LCAyMDE3IGF0IDExOjI4IEFNLCBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5j b208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KSW4gdGhhdCBjYXNlLCBs ZXQncyBhZGQgdGV4dCB0byB0aGF0IGVmZmVjdCwgZS5nLiB3ZSBjb3VsZCBhZGQgdG8gdGhlIGRl ZmluaXRpb24gb2YgdGhlICJldmVudHMiIGNsYWltOg0KDQpQcm9maWxpbmcgc3BlY2lmaWNhdGlv bnMgU0hPVUxEIGRlZmluZSB0aGUgYWxsb3dlZCBldmVudCBzdGF0ZW1lbnRzLCBhbmQgTUFZIHJl c3RyaWN0IHRoZWlyIG51bWJlci4gRm9yIGV4YW1wbGUsIHNvbWUgcHJvZmlsZXMgbWF5IHJlcXVp cmUgdGhpcyBjbGFpbSB0byBjb250YWluIG9ubHkgYSBzaW5nbGUgZXZlbnQgc3RhdGVtZW50Lg0K DQpUaGFua3MsDQogICAgICAgIFlhcm9uDQoNCk9uIDI0LzEwLzE3IDIyOjEwLCBNaWtlIEpvbmVz IHdyb3RlOg0KSSBhZ3JlZSB3aXRoIG11Y2ggb2YgUGhpbOKAmXMgcmF0aW9uYWxlIGhlcmUuDQoN Ckl04oCZcyBmaW5lIGZvciBzb21lIHByb2ZpbGVzIHRvIHNheSB0aGF0IHRoZSDigJxldmVudHPi gJ0gc2V0IG11c3QgYmUgYSBzaW5nbGV0b24uICBUaGF0IGRvZXNu4oCZdCBoYXZlIHRvIGJlIHRy dWUgZm9yIGFsbCBldmVudHMuICBJIHRoaW5rIHRoaW5ncyBhcmUgZmluZSBhcy1pcy4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQoNCipGcm9tOiogSWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPl0gKk9uIEJlaGFsZiBP ZiAqUGhpbCBIdW50DQoqU2VudDoqIE1vbmRheSwgT2N0b2JlciAyMywgMjAxNyA4OjQ3IFBNDQoq VG86KiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWls dG86cmljaGFubmFAYW1hem9uLmNvbT4+DQoqQ2M6KiBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxp ZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KKlN1YmplY3Q6KiBS ZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPw0KDQpB bm5hYmVsbGUsDQoNCkkgaGF2ZSBhIG51bWJlciBvZiBjb25jZXJucyB3aXRoIHRoaXMgcHJvcG9z YWwuDQoNClByb2ZpbGluZyBJbmRlcGVuZGVuY2UgLyBLZWVwaW5nIEV2ZW50IFBheWxvYWRzIElu ZGVwZW5kZW50DQoNCkluZGljYXRpbmcgdGhhdCBleHRlbnNpb25zIHNob3VsZCBiZSBoYW5kbGVk IGJ5IHByb2ZpbGVzIGxlYWRzIHRvIG1vcmUgaW50ZXItb3BlcmFiaWxpdHkgaXNzdWVzIGFuZCBt b3JlIGltcG9ydGFudGx5IGludHJ1ZGVzIG9uIHRoZSBFdmVudCBwYXlsb2FkIHNwYWNlIGJ5IHN1 Z2dlc3RpbmcgYSBzdWItc2NoZW1hIGNyZWF0ZXMgcG90ZW50aWFsIGxpbWl0YXRpb25zIGFuZCBj b25mbGljdHMgdGhhdCBtYXkgYWRkIHRvIGNvbXBsZXhpdHkgbGF0ZXIgb24uIFRoZSBjdXJyZW50 IGZvcm1hdCBhbGxvd3MgYSBwYXJzZXIgdG8gZGlzY292ZXIgYW5kIHVubG9hZCBvbmUgb3IgbW9y ZSBKU09OIHBheWxvYWRzIHdoaWNoIGNhbiBlYWNoIGhhdmUgaW5kZXBlbmRlbnQgc3RydWN0dXJl Lg0KDQpHZW5lcmFsIGV4dGVuc2lvbnMNCg0KVGhlIHByb3Bvc2FsIGFsc28gcnVsZXMgb3V0IGdl bmVyYWwgcHVycG9zZSBleHRlbnNpb25zIG5vdCByZWxhdGVkIHRvIGFueSBzcGVjaWZpYyBldmVu dC4gR2l2ZW4gdGhlIGVtZXJnZW5jZSBvZiBpdGVtcyBsaWtlIEdQUkQsIEkgd291bGQgbm90IHdh bnQgdG8gYmxvY2sgdGhlIGFiaWxpdHkgdG8gYWRkIG1ldGEtZGF0YSBvciBvdGhlciBnZW5lcmFs IHB1cnBvc2UgaXRlbXMuIFdlIGNhbiBhbHNvIGFudGljaXBhdGUgc29tZSBkZWxpdmVyeSBzY2Vu YXJpb3Mgd2hlcmUgYWRkaXRpb25hbCBkYXRhIG1pZ2h0IGJlIHJlcXVpcmVkLiBFdmVuIHRob3Vn aCB0aGVyZSBpcyBubyBjdXJyZW50IHBsYW5uZWQgdXNlLCBJIHNlZSBubyBnb29kIHJlYXNvbiB0 byBydWxlIHRoaXMgb3V0Lg0KDQpNdWx0aXBsZSBFdmVudHMgRnJvbSBEaWZmZXJlbnQgRmFtaWxp ZXMgKHZzLiBNdWx0aXBsZSBFdmVudHMgZnJvbSBhIHNpbmdsZSBmYW1pbHkgbGlrZSBSSVNDKQ0K DQpJbiBvdXIgUklTQyBzZXNzaW9uIHdlIGRpc2N1c3NlZCBleHByZXNzaW5nIG11bHRpcGxlIGRp c3RpbmN0IFJJU0MgZXZlbnRzIGluIG9uZSBTRVQuIFRoZSBkaXNjdXNzaW9uIHdhcyB0aGF0IG9u bHkgb25lIFJJU0MgZXZlbnQgYXQgYSB0aW1lLiBXZSBkaWQgbm90IGRpc2N1c3Mgb3RoZXIgZXZl bnQgcHJvZmlsZXMuIEkgZG9u4oCZdCBzZWUgYSByZWFzb24gdG8gcnVsZSBvdXQgbXVsdGktZXZl bnRzIGZyb20gZGlmZmVyZW50IGZhbWlsaWVzIGF0IHRoZSBTRVQgbGV2ZWwuIEVhY2ggcHJvZmls ZSBpcyBleHByZXNzaW5nIHNsaWdodGx5IGRpZmZlcmVudCB0aGluZ3MgYWJvdXQgdGhlIHNhbWUg ZXZlbnQuDQoNCkkgY2FuIGZvcnNlZSBzb21lIGNhc2VzIHdoZXJlIGl0IGlzIG5vdCBjbGVhciB3 aGljaCBpcyB0aGUgcHJpbWFyeSBhbmQgd2hpY2ggaXMgdGhlIGV4dGVuc2lvbi4gIFRoZXJlIG1h eSBub3QgYmUgYSBjbGVhciB3aW5uZXIuDQoNCkEgY291cGxlIG9mIGV4YW1wbGVzICh0aGVzZSBh cmUgbmVjZXNzYXJpbHkgcmVhbOKApmp1c3QgcG9zc2liaWxpdGllcyk6DQoNCiogSXQgaXMgcHJv YmFibHkgdXNlZnVsIHRvIGJlIGFibGUgdG8gZXhwcmVzcyBzaW1sYXIvb3ZlcmxhcHBpbmcgZXZl bnRzIGZyb20gZGlmZmVyZW50IFNFVCBwcm9maWxlcyBpbiBvbmUgU0VULiAgRm9yIGV4YW1wbGUg YSBCYWNrY2hhbm5lbCBMb2dvdXQgJiBhIFJJU0Mgc2Vzc2lvbiBjYW5jZWwgZXZlbnQuDQoNCiog U0NJTSBtYXkgd2FudCB0byByZXByZXNlbnQgYSBzaW5nbGUgdHJhbnNhY3Rpb24gYXMgY2F1c2lu ZyBtdWx0aXBsZSBzdGF0ZSBjaGFuZ2VzIGluIGFuIGV2ZW50IChlLmcuIGEgcGFzc3dvcmQgY2hh bmdlIGNhdXNlcyBtdWx0aXBsZSBlZmZlY3RzKS4gSGF2aW5nIHRvIGNoYXNlIGRvd24gbXVsdGlw bGUgZXZlbnRzIGFuZCBjb3JyZWxhdGUgYnkg4oCcdHhu4oCdIHdvdWxkIGJlIGNoYWxsZW5naW5n IGluIGEgbXVsdGktdGhyZWFkZWQvbXVsdGktbm9kZSBkZWxpdmVyeSBzeXN0ZW0uICAgVGhlIFND SU0gbGlzdCBoYXMgbm90IGRpc2N1c3NlZCB0aGlzLCBidXQgSSB3b3VsZCBub3Qgd2FudCB0byBi bG9jayB0aGlzIGNhcGFiaWxpdHkuICBJT1cgLSBKdXN0IGJlY2F1c2UgUklTQyBkb2VzIG5vdCB3 YW50IHRvIGV4cHJlc3MgbXVsdGlwbGUgZXZlbnRzIGRvZXMgbm90IG1ha2UgdGhpcyB0cnVlIGZv ciBvdGhlciBwcm9maWxlcy4NCg0KKiBXZSBtYXkgd2lzaCB0byBpbmRpY2F0ZSBhIFNDSU0gUGFz c3dvcmQgUmVzZXQgd2FzIHBlcmZvcm1lZCBhbmQgYSBMb2dvdXQvc2Vzc2lvbiBjYW5jZWxsYXRp b24gaXMgZXhwcmVzc2VkIGF0IHRoZSBzYW1lIHRpbWUuICBUaGUgZXZlbnRzIGFyZSByZWxhdGVk IGJ1dCBleHByZXNzIGRpZmZlcmVudCBkYXRhLg0KDQpBdm9pZGluZyBDb25mdXNpb24gRnJvbSBT aW1pbGFyIEV2ZW50cyBPcmlnaW5hdGluZyBmcm9tIHRoZSBTYW1lIFRyYW5zYWN0aW9uDQoNCklm IGV2ZW50cyBhcmUgc2VudCBzZXBhcmF0ZWx5LCB0aGVuIG1vcmUgdHJhY2tpbmcgb2Ygc3RhdGUg KGUuZy4gYnkgdHhuKSB3b3VsZCBiZSByZXF1aXJlZCB0byBlbnN1cmUgc2ltaWxhciBldmVudHMg YXJlIG5vdCBtaXN0YWtlbiBvciBoYW5kbGVkIGFzIHJlcGVhdHMuIFdoaWxlIHR4biBwcm92aWRl cyB1c2VmdWwgYXVkaXQgYW5hbHlzaXMgY2FwYWJpbGl0eSwgSeKAmW0gbm90IHN1cmUgaXQgY2Fu IGJlIHVzZWQgaW4gbGl2ZSBvciBuZWFyLXJlYWwgdGltZSBzeXN0ZW1zIGdpdmVuIGRpc3RyaWJ1 dGVkIG11bHRpLW5vZGUsIG11bHRpLXRocmVhZGluZyBhcmNoaXRlY3R1cmVzLg0KDQpQcmV2aW91 cyBEaXNjdXNzaW9uDQoNCkkgbm90ZSB0aGF0IEkgb3JpZ2luYWxseSByYWlzZWQgaGF2aW5nIGFu IGF0dHJpYnV0ZSB0byBkZXNpZ25hdGUgcHJpbWFyeSBldmVudCBhdHRyaWJ1dGUgdG8gYWxsZXZp YXRlIHlvdXIgY29uY2VybiwgYnV0IHRoaXMgd2FzIG5vdCBhY2NlcHRlZC4gU2VlOg0KDQoqIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3VycmVudC9tc2cw MDQwNi5odG1sPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRf bXNnMDA0MDYuaHRtbCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1V QjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5B Jm09WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZzPVMzc01WaXFN dkVnbndHYkp3T1FOeWNyT3lyN1NlZnBxX01vRk9LY0VlQ0UmZT0+DQoNCiogaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pZC1ldmVudC9jdXJyZW50L21zZzAwMTQwLmh0bWw8 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbC0yRGFyY2hpdmVfd2ViX2lkLTJEZXZlbnRfY3VycmVudF9tc2cwMDE0MC5o dG1sJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0pu RSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1ZQkNHbEs5 bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JnM9R3k5Z3lSb0lJdGEtY1NoVjdi TjE2MWF5NHlFNnI5RzFfQWFfTmVCbnlsZyZlPT4NCg0KVGhlIGNvbnNlbnN1cywgYXQgbGVhc3Qg YXMgSSBpbnRlcnByZXRlZCBpdCBpcyB1cCB0byB0aGUgcmVjZWl2ZXIgdG8gZmlndXJlIHRoaXMg b3V0IGJhc2VkIG9uIHRoZSBkZWZpbml0aW9ucyBpdCBoYXMgZm9yIGVhY2ggZXZlbnQgVVJJIGFu ZCB0aGUgcHJvZmlsZXMgdGhleSByZXByZXNlbnQuIElPVyAtIFJJU0MgaXMgZnJlZSB0byBsaW1p dCB0aGF0IG9ubHkgb25lIFJJU0MgZXZlbnQgYmUgZXhwcmVzc2VkIGF0IGEgdGltZS4NCg0KUGhp bA0KDQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVj dA0KDQpAaW5kZXBlbmRlbnRpZA0KDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlk LmNvbSZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9K bkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09WUJDR2xL OW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZzPTlOUDVuYW1nNnJJVnp3dW45 Yy0xcTB3aHN5WHdTdnRIQjBmMmRLa2ZDWDgmZT0+IDxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQu Y29tPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193 d3cuaW5kZXBlbmRlbnRpZC5jb20mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhC djdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxj TE40S1pOQSZtPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmcz05 TlA1bmFtZzZySVZ6d3VuOWMtMXEwd2hzeVh3U3Z0SEIwZjJkS2tmQ1g4JmU9Pj4NCg0KcGhpbC5o dW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPiA8bWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQoNCiAgICBPbiBP Y3QgMjMsIDIwMTcsIGF0IDc6MDIgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlDQogICAg PHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+IDxtYWlsdG86 cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+PiB3cm90ZToN Cg0KICAgIFRoZSBjdXJyZW50IGRyYWZ0IG9mIHRoZSBTRVQgc3BlYyBhbGxvd3MgZm9yIGV4cHJl c3NpbmcgbXVsdGlwbGUNCiAgICBldmVudHMgd2l0aGluIHRoZSBzYW1lIHRva2VuLCB3aGljaCBp bnRyb2R1Y2VzIGFkZGl0aW9uYWwgY29tcGxleGl0eQ0KICAgIGFuZCByb29tIGZvciBhbWJpZ3Vv dXMgc2VtYW50aWNzLiBXZeKAmXZlIGRpc2N1c3NlZCB0aGlzIGluIHRoZSBPSURGDQogICAgUklT QyB3b3JraW5nIGdyb3VwIGFuZCB0aGUgY3VycmVudCBjb25zZW5zdXMgdGhlcmUgaXMgdGhhdCBS SVNDIHdpbGwNCiAgICByZXF1aXJlIHRoYXQgUklTQyBldmVudHMgbXVzdCBiZSB0aGUgb25seSBl dmVudCBpbiB0aGUgU0VULCBoYXZpbmcNCiAgICBpZGVudGlmaWVkIHdheXMgdG8gY2xlYXJseSBh bmQgZWFzaWx5IHN1cHBvcnQgdGhlIGhhbmRmdWwgb2YgdXNlDQogICAgY2FzZXMgZm9yIG11bHRp cGxlIGV2ZW50cyBwZXIgdG9rZW4gdGhhdCBwZW9wbGUgaGF2ZSByYWlzZWQuIFdpdGgNCiAgICB0 aGF0IGNvbnRleHQgaW4gbWluZCwgSSBwcm9wb3NlIHN0cmlraW5nIHRoZSBkZWZpbml0aW9uIG9m IHRoZQ0KICAgIOKAnGV2ZW50c+KAnSBjbGFpbSBmcm9tIHRoZSBTZWN1cml0eSBFdmVudCBUb2tl biBzcGVjLCBhbmQgcmVwbGFjaW5nIGl0DQogICAgd2l0aCB0aGUgZm9sbG93aW5nIGRlZmluaXRp b24gZm9yIGFuIOKAnGV2ZW504oCdIGNsYWltIChzaW5ndWxhcik6DQoNCiAgICBldmVudA0KDQog ICAgQSBKU09OIG9iamVjdCBjb250YWluaW5nIGFuICJldmVudF90eXBlIiBtZW1iZXIgd2hvc2Ug dmFsdWUgaXMgYSBVUkkNCiAgICByZXByZXNlbnRpbmcgYSB0eXBlIG9mIGV2ZW50IGRlZmluZWQg aW4gYSBQcm9maWxpbmcgU3BlY2lmaWNhdGlvbi4NCiAgICBUaGUgb2JqZWN0IE1BWSBvdGhlcndp c2UgYmUgZW1wdHksIG9yIE1BWSBjb250YWluIGFkZGl0aW9uYWwgbWVtYmVycw0KICAgIGFzIGRl c2NyaWJlZCBieSB0aGUgUHJvZmlsaW5nIFNwZWNpZmljYXRpb24uDQoNCiAgICBIZXJlIGlzIHRo ZSBleGFtcGxlIFNFVCBmcm9tIHNlY3Rpb24gMi4zLCByZXdyaXR0ZW4gd2l0aCB0aGlzIGNoYW5n ZQ0KICAgIG1pbmQ6DQoNCiAgICB7DQoNCiAgICAgICAianRpIjogIjRkMzU1OWVjNjc1MDRhYWJh NjVkNDBiMDM2M2ZhYWQ4IiwNCg0KICAgICAgICJpYXQiOiAxNDU4NDk2NDA0LA0KDQogICAgICAi aXNzIjogImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbTxodHRwczovL3NjaW0uZXhhbXBsZS5jb20v PiA8aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLz4iLA0KDQogICAgICAgImF1ZCI6IFsNCg0KICAg ICAgICAgImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5 M2I3NzU0IiwNCg0KICAgICAgICAgImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy81ZDc2 MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Ig0KDQogICAgICAgXSwNCg0KICAgICAgICJldmVudCI6IHsN Cg0KICAgICAgICAgImV2ZW50X3R5cGUiOiAidXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6Y3Jl YXRlIiwNCg0KICAgICAgICAgInJlZiI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMv NDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsDQoNCiAgICAgICAgICJhdHRyaWJ1dGVzIjogWyJp ZCIsICJuYW1lIiwgInVzZXJOYW1lIiwgInBhc3N3b3JkIiwgImVtYWlscyJdDQoNCiAgICAgICB9 DQoNCiAgICB9DQoNCiAgICBEb2VzIGFueW9uZSBpbiB0aGUgd29ya2luZyBncm91cCBoYXZlIHVz ZSBjYXNlcyBmb3IgU0VUcyB0aGF0IGNhbm5vdA0KICAgIGJlIG1ldCBieSB0aGlzIHByb3Bvc2Vk IHRleHQ/IFdpdGhpbiBSSVNDLCB3ZSBpZGVudGlmaWVkIHRocmVlIHVzZQ0KICAgIGNhc2VzLCB3 aXRoIHNvbHV0aW9ucyBvdXRsaW5lZCBiZWxvdzoNCg0KICAgICoqDQoNCiAgICAqRXh0ZW5zaW9u cyoNCg0KICAgIEV2ZW50IGV4dGVuc2lvbiBtZWNoYW5pc21zIGNhbiBiZSBkZWZpbmVkIGludGVy bmFsIHRvIHRoZSBldmVudA0KICAgIG9iamVjdC4gQSBzaW1wbGUgYXBwcm9hY2ggd291bGQgYmUg dG8gIGRlZmluZSBhbiDigJxleHRlbnNpb25z4oCdIG1lbWJlcg0KICAgIHRoYXQgaXMgYSBsaXN0 IG9mIGV2ZW50IG9iamVjdHMgKG9yIHNldCByZXNlbWJsaW5nIHRoZSDigJxldmVudHPigJ0NCiAg ICBjbGFpbSBhcyBkZWZpbmVkIGluIHRoZSBjdXJyZW50IHNwZWMpLiBUaGlzIGhhcyB0aGUgYWR2 YW50YWdlIG9mDQogICAgbWFraW5nIGl0IGNsZWFyIGluIHRoZSBkYXRhIHN0cnVjdHVyZSB0aGF0 IHRoZXJlIGlzIGEgc2luZ2xlIHByaW1hcnkNCiAgICBldmVudCwgd2l0aCB6ZXJvIG9yIG1vcmUg ZXh0ZW5zaW9ucy4gVGhlcmUgaXMgbm8gcm9vbSBmb3IgY29uZnVzaW9uDQogICAgb3ZlciB3aGlj aCBldmVudCBpcyBwcmltYXJ5LCBvciBpZiB0aGVyZSBpcyBhIHByaW1hcnkgZXZlbnQgYXQgYWxs Lg0KICAgIEkgd291bGQgYmUgZmluZSB3aXRoIGFkZGluZyBzb21ldGhpbmcgbGlrZSB0aGlzIHRv IG15IHByb3Bvc2VkIHRleHQsDQogICAgaWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRoYXQgaXQgaXMg YnJvYWRseSB1c2VmdWwuDQoNCiAgICAqQWxpYXNlcyoNCg0KICAgIFRoaXMgdXNlIGNhc2Ugd2Fz IGJyb3VnaHQgdXAgaW4gdGhlIGNvbnRleHQgb2YgbWlncmF0aW5nIGNsaWVudHMNCiAgICBmcm9t IGRyYWZ0IGV2ZW50IG5hbWVzIHRvIHN0YW5kYXJkaXplZCBldmVudCBuYW1lcy4gSW4gdGhpcyBj YXNlLA0KICAgIHRoZSBldmVudCB0cmFuc21pdHRlciBjYW4gdHJhbnNtaXQgdHdvIHRva2VucyBm b3IgdGhlIGxvZ2ljYWwgZXZlbnQsDQogICAgb25lIHVzaW5nIHRoZSBvbGQgbmFtZSBhbmQgYW5v dGhlciB1c2luZyB0aGUgbmV3IG5hbWUuDQoNCiAgICAqUmVsYXRlZCBFdmVudHMqDQoNCiAgICBU aGUgU0VUIHNwZWMgZGVmaW5lcyB0aGUgdHhuIGNsYWltIGFzIGEgbWVhbnMgb2YgY29ycmVsYXRp bmcNCiAgICBpbmRlcGVuZGVudCB0b2tlbnMgdGhhdCByZWxhdGUgdG8gdGhlIHNhbWUgbG9naWNh bCBldmVudC4NCg0KICAgIC0tDQogICAgQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KDQogICAg QW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlcw0KDQogICAgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAg ICBJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+IDxtYWlsdG86SWQt ZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPj4NCiAgICBodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empX d2xOS2U0Q19sTElHayZtPXM1YnlCZTVLQU5uR1Z1QWIxbUF1cEVHb0puOFhHNUpJVVV3V0dGU2li RWMmcz1YOG9SU3EzSXpsRjdqaVJBZVpoWHBSM2VWSTBJNThaRmQ0ZUVaZmd5b0lZJmU9DQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZl bnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBw dVlxUGtBSTFhTGNMTjRLWk5BJm09WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRr UmxRRzFpdyZzPVdyTXVRUndMVjgwMmlNUTR3WUIxZjJyRlVHdTR6YmhjVzAwMWZLMDJFWHMmZT0+ DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1l dmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dh V0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlY UHB1WXFQa0FJMWFMY0xONEtaTkEmbT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtB VGtSbFFHMWl3JnM9V3JNdVFSd0xWODAyaU1RNHdZQjFmMnJGVUd1NHpiaGNXMDAxZkswMkVYcyZl PT4NCg0KDQoNCi0tDQpTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRTxodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1Ed01G YVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6 QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPVlCQ0dsSzltampoY0Zzai0y dERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmcz1MWU43MkdnS1ZoSHNUNnRBcUJlLWVNb1dNdnlf N2RmRm4xdVowSEs2WXVRJmU9PiBtYWlsIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBh bSB3b3JraW5nIG9uIQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklk LWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9 RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5h NUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1ZQkNHbEs5bWpqaGNG c2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JnM9V3JNdVFSd0xWODAyaU1RNHdZQjFmMnJG VUd1NHpiaGNXMDAxZkswMkVYcyZlPQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9y ZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lk LTJEZXZlbnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVh cElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPVUt YTVIQk5EMEhhVFg0YW5OWmZ6WDdwRHNmSzVmMGg5bVo5Q1pra0dpZWMmcz1ydmRydEk3cllOUkFu cVpEbHRDd0JBWlZIS3AtTUoyMHVpMm5tNDZRU3owJmU9DQoNCg0KDQoNCi0tDQpTdWJzY3JpYmUg dG8gdGhlIEhBUkRUV0FSRTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBr QUkxYUxjTE40S1pOQSZtPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVND X3cmcz13dGdEM05wMHZ5aExkcEV3VWlxc2Y0SXRpd0EzT203R3JvYjcwTHgwcjNrJmU9PiBtYWls IGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcg bGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1 WXFQa0FJMWFMY0xONEtaTkEmbT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4 X3FTQ193JnM9T2UwcWZMRVg4M3Z0WE03V2wyY1lCZS1HZzFEVlBqaFhqVkprZmhWUnp3YyZlPQ0K DQoNCg0KLS0NClN1YnNjcmliZSB0byB0aGUgSEFSRFRXQVJFPGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZkPUR3TUdhUSZj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdt YW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09c0lHejhndXI0d05xWmt0Y21hZ3Y1 RWEyMVFFaXA0SFhwRVZLUmEwcWhsbyZzPVY5Z3lUVFg5cXVqckMyVmxpd0xQeTAtS3Z4UzlwWUtK Xy1reURhcHdPOGsmZT0+IG1haWwgbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdv cmtpbmcgb24hDQoNCg0KDQotLQ0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkU8aHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21f JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZy PW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1zSUd6OGd1cjR3 TnFaa3RjbWFndjVFYTIxUUVpcDRIWHBFVktSYTBxaGxvJnM9VjlneVRUWDlxdWpyQzJWbGl3TFB5 MC1LdnhTOXBZS0pfLWt5RGFwd084ayZlPT4gbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2pl Y3RzIEkgYW0gd29ya2luZyBvbiENCg0KDQoNCi0tDQpTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FS RTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFy ZHR3YXJlLmNvbV8mZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2 NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZt PXNJR3o4Z3VyNHdOcVprdGNtYWd2NUVhMjFRRWlwNEhYcEVWS1JhMHFobG8mcz1WOWd5VFRYOXF1 anJDMlZsaXdMUHkwLUt2eFM5cFlLSl8ta3lEYXB3TzhrJmU9PiBtYWlsIGxpc3QgdG8gbGVhcm4g YWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRA aWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUly TVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEta TkEmbT1zSUd6OGd1cjR3TnFaa3RjbWFndjVFYTIxUUVpcDRIWHBFVktSYTBxaGxvJnM9Z2ROcnM3 VURBdHRwYWJqTTVuZE9Yd1dLbVp1S2FYRWJUNXd1OXJjT1JWMCZlPQ0KDQo= --_000_CY4PR21MB0504111616783EB6E3E055E2F55F0CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uYXBwbGUtc3R5 bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uYXBwbGUt Y29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9 DQpzcGFuLm0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2 OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7 bXNvLXN0eWxlLW5hbWU6bS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAx bTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1z cGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjQ2MTg1MTc0MjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTc3ODAwNDcxNDt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTA4Mzgz OTYzNjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTg1ODQ4NDYyODt9DQpAbGlzdCBsMTpsZXZl bDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMg0KCXttc28tbGlzdC1pZDoxMjgyNjA4MTA5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlk czoxODE5MDE3NzM0O30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjE5MTQzODk5NzY7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi0yMTM0NDcwOTUyO30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28t bGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoaXMgd2VsbCBzYWlkLCBQaGls LiZuYnNwOyBZb3UgZGlkIGEgZ3JlYXQgam9iIGV4cGxhaW5pbmcgaG93IG1ha2luZyB0aGUg4oCc ZXZlbnRz4oCdIGNsYWltIHNpbmdsZS12YWx1ZWQgYW5kIGZvcmNpbmcgbXVsdGlwbGUgU0VUcyB3 aGVuIG9uZSB3aWxsIGRvIHNpZ25pZmljYW50bHkgY29tcGxpY2F0ZXMgbGlmZSBmb3IgYWxsIHBh cnRpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGFncmVlIHRoYXQg d2UgcHJvYmFibHkgd2FudCB0byBleGFtaW5lIHRoZSBleGlzdGluZyBkZXNjcmlwdGl2ZSB0ZXh0 IGFuZCBtYWtlIGl0IGNsZWFyIHRoYXQgd2hhdOKAmXMgaW4gdGhlIOKAnGV2ZW50c+KAnSBzZXQg YXJlIG11bHRpcGxlIGFzcGVjdHMgb2YgdGhlIHNhbWUgbG9naWNhbCBldmVudCDigJMgbm90IGRp c3RpbmN0IGV2ZW50cy4mbmJzcDsgSeKAmW0gZ3JlYXQgd2l0aCBzdHJlbmd0aGVuaW5nDQogdGhv c2Ugc3RhdGVtZW50cyBpZiB0aGV5IGFyZW7igJl0IGFscmVhZHkgY2xlYXIgZW5vdWdoLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEJlc3Qgd2lzaGVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPkZyb206PC9iPiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMSwgMjAxNyAxMjo0 NSBQTTxicj4NCjxiPlRvOjwvYj4gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hh bm5hQGFtYXpvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7OyBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWls LmNvbSZndDs7IFlhcm9uIFNoZWZmZXIgJmx0O3lhcm9uZi5pZXRmQGdtYWlsLmNvbSZndDs7IElE IEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0O2lkLWV2ZW50QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBw ZXIgU0VUPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGNhbuKA mXQgcmVhbGx5IGhhdmUgbXVsdGlwbGUgZXZlbnRzIChhdCBsZWFzdCBvZiB0aGUgc2FtZSB0eXBl KS4gJm5ic3A7VGhlIGN1cnJlbnQgc3BlYyBjYW4gb25seSBoYXZlIG9uZSBpbnN0YW5jZSBvZiBh IFVSSSAoYWZhaWspLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk5vdGUgdGhhdCB0aGUgc3BlYyBub3JtYXRpdmVseSBkb2VzIG5vdCBzdXBwb3J0 IG11bHRpcGxlIGV2ZW50IFNFVFMuICZuYnNwO0l0IGN1cnJlbnRseSBzdGF0ZXM6PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6IHBhZ2UiPmV2ZW50czxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8Yj5U aGUgc2VtYW50aWNzIG9mIHRoaXMgY2xhaW0gaXMgdG8gZGVmaW5lIGEgc2V0IG9mIGV2ZW50IHN0 YXRlbWVudHM8bzpwPjwvbzpwPjwvYj48L3ByZT4NCjxwcmU+PGI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHRoYXQgZWFjaCBNQVkgYWRkIGFkZGl0aW9uYWwgY2xhaW1zIHRvIGZ1bGx5 IGRlc2NyaWJlIGEgc2luZ2xlPG86cD48L286cD48L2I+PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsb2dpY2FsIGV2ZW50PC9iPiB0aGF0IGhhcyBvY2N1cnJl ZCAoZS5nLiBhIHN0YXRlIGNoYW5nZSB0byBhPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1YmplY3QpLiZuYnNwOyBNdWx0aXBsZSBldmVudCBz dGF0ZW1lbnRzIG9mIHRoZSBzYW1lIHR5cGUgU0hBTEwgTk9UIGJlPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFjY2VwdGVkLiZuYnNwOyBUaGUg JnF1b3Q7ZXZlbnRzJnF1b3Q7IGNsYWltIFNIT1VMRCBOT1QgYmUgdXNlZCB0byBleHByZXNzPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG11bHRp cGxlIGxvZ2ljYWwgZXZlbnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc3BlYyBoYXMgKmFsd2F5cyogc3VwcG9ydGVk IHJlcXVpcmVtZW50cyAoYXMgc3RhdGVkIGluIHRoZSBzcGVjKSBmb3IgbXVsdGlwbGUgc2VwYXJh dGUgcHJvZmlsZSBzdGF0ZW1lbnRzIChmcm9tIG9uZSBvciBtb3JlIHByb2ZpbGUgZmFtaWxpdGll cykgbmVlZGluZyB0byBiZSBzZW50IGFzIGEgc2luZ2xlIG1lc3NhZ2UuICZuYnNwO0l0IHdvdWxk IGJlIElOU0VDVVJFIHRvIGZvcmNlIG11bHRpcGxlIFNFVHMgYmVjYXVzZQ0KIHRoZSBjdXJyZW50 IGRlbGl2ZXJ5IG1lY2hhbmlzbSBvbmx5IGFsbG93cyBvbmUgU0VUIHRvIGJlIGRlbGl2ZXJlZCBh dCBhIHRpbWUuIFRoZXJlIGlzIG5vIHdheSB0byBhc3N1cmUgdGhhdCBhIHNpbmdsZSByZWNlaXZl ciBnZXRzIGFsbCBvZiB0aGUgU0VUcyBpdCBuZWVkcyBpbiBhIG11bHRpLXRocmVhZGVkLCBtdWx0 aS1ub2RlIGVudmlyb25tZW50IGF0IHNjYWxlLiAmbmJzcDtBc3NlbWJsaW5nIG11bHRpcGxlIFNF VHMgdG8gdHJhY2sg4oCcdHhu4oCdIGluIGENCiBjb21tb24gc3RhdGUgZGF0YWJhc2UgaXMgTk9U IHNpbXBsZSBub3IgY29zdCBlZmZlY3RpdmUuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSBhY2NvbW1vZGF0ZSB0aGlzIGlu IHRoZSBwcm9wb3NlZCBmb3JtLCB3ZSBlbmQgdXAgd2l0aCBhIGNvbXBsZXgsIGRlZXBseSBuZXN0 ZWQgSlNPTiBzdHJ1Y3R1cmUgd2l0aCB0aGUgcG9zc2liaWxpdHkgb2YgbmFtZXNwYWNlIGNvbmZs aWN0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SU1PIFRoZSBwcm9wb3NhbCBkb2VzIG5vdCBzaW1wbGlmeSwgaXQgY29tcGxpY2F0aW5nIGFu ZCBsaW1pdGluZy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBjdXJyZW50IHNwZWMgaGFzIHZlcnkgY2xlYW4gSlNPTiBhbmQg YXZvaWRzIG5hbWVzcGFjZSBjb25mbGljdHMgYmV0d2VlbiBwcm9maWxlcy4gSSB0aGluayB3ZSBz aG91bGQgc3RheSBvbiB0cmFjayB3aXRoIHRoZSBjdXJyZW50IGRyYWZ0IGFuZCBvYnNlcnZlIHRo ZSBub3JtYXRpdmUgdGV4dCBpZiBub3QgbWFrZSBpdCBzdHJvbmdlciBpbiByZWdhcmRzIHRvIG11 bHRpLWV2ZW50cyAodW5kZXJzdG9vZCB0aGF0DQogTWlrZSBtYXkgZGlzYWdyZWUpLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QaGlsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5P cmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iPnd3dy5pbmRl cGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3Jh Y2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiAx LCAyMDE3LCBhdCAxMjoxOCBQTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhy ZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+VW5sZXNzIHRoZSBwcm9maWxlIGd1YXJhbnRlZXMgdGhh dCBzdWNoIHJlbGF0ZWQgZXZlbnRzIHdpbGwgYWx3YXlzIGJlIGluY2x1ZGVkIGluIHRoZSBzYW1l IFNFVCwgdGhlbiB0aGUgcmVjZWl2ZXIgaGFzIHRvIGNvcnJlbGF0ZSBhY3Jvc3MgU0VUcyBhbnl3 YXksIGFuZCBtdWx0aXBsZSBldmVudHMgcGVyIFNFVCBpcyBqdXN0IGdpdmluZyB0aGUgcmVjZWl2 ZXIgYW5vdGhlcg0KIHNjZW5hcmlvIHRoYXQgdGhleSBoYXZlIHRvIHN1cHBvcnQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SeKAmXZlIGFscmVhZHkgcHJv dmlkZWQgc2V2ZXJhbCBvdGhlciByZWFzb25zIHdoeSB3ZSBzaG91bGQgbm90IHN1cHBvcnQgbXVs dGlwbGUgdG9rZW5zIHBlciBTRVQgdGhhdCBubyBvbmUgaGFzIGFkZHJlc3NlZC4gSGVyZSB0aGV5 IGFyZSBhZ2Fpbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9w OjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbGlzdDpsMCBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj5NdWx0aXBsZSBldmVudCBz dXBwb3J0IHJlc3VsdHMgaW4gYSBtb3JlIGNvbXBsZXggc3RydWN0dXJlIGZvciB0aGUgc2luZ2xl IGV2ZW50IHVzZSBjYXNlLCB3aGljaCBJIHRoaW5rIHdlIGFsbCBhZ3JlZSBpcyB0aGUgbWFqb3Jp dHkgdXNlIGNhc2UuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZSI+TXVsdGlwbGUtZXZlbnQg U0VUcyBoYXZlIGFtYmlndW91cyBzZW1hbnRpY3MuIFRoZSBwcmVzZW5jZSBvZiB0d28gZXZlbnRz IEEgYW5kIEIgaW4gdGhlIHNhbWUgU0VUIGNvdWxkIG1lYW4gYW55IG9mOjxvOnA+PC9vOnA+PC9s aT48L29sPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjIiIHR5cGU9IjEiPg0K PG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDIgbGZvMTtiYWNrZ3JvdW5kOndo aXRlIj5BIGFuZCBCIGFyZSByZWxhdGVkIHRvIHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQgKGkuZS4g dGhlIHNhbWUgdGhpbmcgYXMgaWYgdGhleSB3ZXJlIGZyb20gZGlmZmVyZW50IFNFVHMgdGhhdCBo YXZlIGEgY29tbW9uIHR4bikuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzE7YmFja2dyb3VuZDp3aGl0ZSI+QSBpcyBhbiBl eHRlbnNpb24gb2YgQi48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbGlzdDpsMCBsZXZlbDIgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj5CIGlzIGFuIGV4dGVu c2lvbiBvZiBBLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1saXN0OmwwIGxldmVsMiBsZm8xO2JhY2tncm91bmQ6d2hpdGUiPkEgaXMgYW4gYWxpYXMgZm9y IEIsIG9yIHZpY2UtdmVyc2EuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzE7YmFja2dyb3VuZDp3aGl0ZSI+QSBhbmQgQiBh cmUgbm90IGFjdHVhbGx5IHJlbGF0ZWQgdG8gb25lIGFub3RoZXIgaW4gYW55IHdheSwgYW5kIHRo ZSB0cmFuc21pdHRlciBidW5kbGVkIHRoZW0gdG9nZXRoZXIgYmVjYXVzZSB0aGV5IHdlcmUgZ29p bmcgdG8gdGhlIHNhbWUgcmVjZWl2ZXIuPG86cD48L286cD48L2xpPjwvb2w+DQo8L29sPg0KPG9s IHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjMiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRl Ij5Ub3AtbGV2ZWwgY2xhaW0gc2VtYW50aWNzIGJlY29tZSBoYXJkZXIgdG8gZGVmaW5lLCBhcyBk aWZmZXJlbnQgcHJvZmlsZXMgbWF5IHdhbnQgdG8gdXNlIHRoZSBzYW1lIGNsYWltcyBpbiBkaWZm ZXJlbnQgd2F5cy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbGlzdDpsMCBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj5FdmVudCBhdXRoZW50aWNp dHkgY2Fubm90IGJlIHZlcmlmaWVkIHdpdGhvdXQgaGF2aW5nIHRoZSBlbnRpcmUgU0VULiBUaGlz IGZvcmNlcyByZWNlaXZlcnMgdG8gZXhwb3NlIGRvd25zdHJlYW0gc3lzdGVtcyB0byBtb3JlIGlu Zm9ybWF0aW9uIG5lY2Vzc2FyeSwgaWYgdGhvc2Ugc3lzdGVtcyBuZWVkIHRvIGJlIGFibGUgdG8N CiB2ZXJpZnkgYXV0aGVudGljaXR5LjxvOnA+PC9vOnA+PC9saT48L29sPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJh Y2ttYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5BbWF6 b24g4oCTIElkZW50aXR5IFNlcnZpY2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPkZyb206PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk1pa2UgSm9uZXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPldlZG5lc2RheSwgTm92ZW1iZXIgMSwg MjAxNyBhdCAxMToyMSBBTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+RGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRp Y2suaGFyZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+ Q2M6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Z YXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIj55 YXJvbmYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OywgJnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5h YmVsbGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj5yaWNo YW5uYUBhbWF6b24uY29tPC9hPiZndDssIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhy ZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0OywN CiAmcXVvdDtQaGlsIEh1bnQgKElETSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5S RTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGNvbXBsZXRlbHkg YWdyZWUgb24gbW92aW5nIGNvbXBsZXhpdHkgdG8gdGhlIGlzc3VlciBvdmVyIHRoZSByZWNpcGll bnQuJm5ic3A7IEluIG15IHZpZXcsIGl04oCZcyBtb3JlIGNvbXBsZXggZm9yIHJlY2lwaWVudHMg dG8gaGF2ZSB0byBjb3JyZWxhdGUgYW5kIHByb2Nlc3MgYSBzZXF1ZW5jZSBvZiBtdWx0aXBsZSBT RVRzIHByb3ZpZGluZw0KIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQs IGFuZCB2YWxpZGF0ZSBOIHNpZ25hdHVyZXMsIHRoYW4gdG8gcmVjZWl2ZSBvbmUgU0VUIHdpdGgg YWxsIHRoZSBhc3BlY3RzIG9mIHRoZSBsb2dpY2FsIGV2ZW50IGFzIOKAnGV2ZW50c+KAnSBmaWVs ZHMsIHdpdGggbm8gY29ycmVsYXRpb24gb3ZlciB0aW1lIHRoZW4gcmVxdWlyZWQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bEVuZENvbXBvc2UiPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj5Gcm9tOjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RGljayBIYXJkdCBb PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj5tYWlsdG86ZGljay5oYXJkdEBn bWFpbC5jb208L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+V2VkbmVzZGF5LCBOb3ZlbWJlciAxLCAyMDE3IDk6MzkgQU08YnI+DQo8 Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pk1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5ZYXJvbiBTaGVm ZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIj55YXJvbmYuaWV0 ZkBnbWFpbC5jb208L2E+Jmd0OzsgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhy ZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZn dDs7IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBp ZXRmLm9yZyI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0OzsNCiBQaGlsIEh1bnQgKElETSkgJmx0 OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5j b208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRp cGxlIGV2ZW50cyBwZXIgU0VUPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+WW91ciBjb21tZW50cyBoaWdobGlnaHQgYSBjb3VwbGUg b2YgcG9pbnRzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjEpIFRoZSBleGFtcGxlIGlzIGhvdyB0byBo YXZlIGEgcHJlZGVmaW5lZCBleHRlbnNpb24gcG9pbnQgZm9yIGV4dGVuc2lvbnMgb2YgYSBzcGVj aWZpYyBldmVudCwgaXQgaXMgbm90IGhvdyB0byBhZGQgYW5vdGhlciBldmVudC4gTXlzZWxmLCBJ IHRoaW5rIHRoaXMgaXMgb3Zlcmx5IGNvbXBsaWNhdGVkLiBFdmVudHMgc2hvdWxkIGJlIGNvbXBh cmF0aXZlbHkgc3RhdGljLA0KIGFuZCBhcyB3aXRoIG1hbnkgb3RoZXIgSlNPTiBmb3JtYXRzLCB0 aGUgcmVjZWl2ZXIgc2hvdWxkIGlnbm9yZSBwcm9wZXJ0aWVzIGl0IGRvZXMgbm90IHVuZGVyc3Rh bmQsIHdoaWNoIGxldCdzIG5ldyBwcm9wZXJ0aWVzIGJlIGludHJvZHVjZWQgYXMgZXh0ZW5zaW9u cy4gVGhlcmUgc2hvdWxkIG5vdCBiZSBhbnkgY29uZmxpY3QgYXMgZXh0ZW5zaW9ucyBzaG91bGQg b25seSBiZSBkb25lIGJ5IHRoZSBwcm9maWxlIHRoYXQgY3JlYXRlZCB0aGUgZXZlbnQNCiBmb3Jt YXQgdG8gc3RhcnQgb2ZmIHdpdGguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+MikgSGF2aW5nIGFuIGx2 YWx1ZSBiZSBhIFVSSSBpcyBtdWNoIGhhcmRlciB0byBjb2RlIGFnYWluc3QuIEknbSBub3Qgc3Vy ZSB3aHkgTWFyaXVzIGhhZCB0aGF0IGluIGhpcyBleGFtcGxlLiBQZXIgdGhlIGV2ZW50LCB0aGUg dHlwZSBvZiB0aGUgZXZlbnQgaXMgd2VsbCBkZWZpbmVkIHdpdGgmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZxdW90O2V2ZW50X3R5cGUmcXVvdDs6ICZx dW90Ozwvc3Bhbj48YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dv cmRSZXNldEV4dCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cHVycGxlIj5odHRwczov L2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojNTAwMDUwIj4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4zKSBUaGlzIHRocmVhZCBpcyBhYm91dCByZWFzb25zIGZvciBtdWx0aXBsZSBldmVudHMgdG8g YmUgY29udGFpbmVkIGluIG9uZSBzZXQuIFlvdXIgbWVudGlvbiBvZiBhbiBpc3N1ZXIgbm90IHdh bnRpbmcgdG8gc2lnbiBzZXBhcmF0ZSBldmVudHMgYXMgYSByZWFzb24gdG8gYWxsb3cgbXVsdGlw bGUgZXZlbnRzLiBJIHRoaW5rIHdlIGhhdmUgZGVjaWRlZCB0aGF0IGdpdmVuDQogYSBwcmVmZXJl bmNlLCB3ZSB3aWxsIHB1c2ggZWZmb3J0IHRvIHRoZSB0cmFuc21pdHRlciBvdmVyIHRoZSByZWNl aXZlciBhcyBpbiBtYW55IHVzZSBjYXNlcyB0aGVyZSBhcmUgbWFueSBtb3JlIHJlY2VpdmVycy4g R2l2ZW4gdGhhdCwgaXQgaXMgbW9yZSBjb21wbGV4IGZvciBhIHJlY2VpdmVyIHRvIGhhdmUgZGlm ZmVyZW50IHdheXMgb2YgbWFuYWdpbmcgdGhlIHJlY2VpcHQgb2YgbXVsdGlwbGUgZXZlbnRzIGFz IG5vdCBhbGwgaXNzdWVycyB3aWxsDQogYnVuZGxlIHRoZSBldmVudHMsIHNvIGl0IGlzIHNpbXBs ZXIgdG8gaGF2ZSBvbmx5IG9uZSBldmVudCBwZXIgU0VULiBJbmNsdWRpbmcgdGhlIHNlcGFyYXRl IGV2ZW50cyB3aXRoIGEgVVJJIGFzIGFuIGx2YWx1ZSBpcyBjaGFsbGVuZ2luZyB0byBpbXBsZW1l bnQsIHNwZWFraW5nIGZyb20gZXhwZXJpZW5jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9uIFR1ZSwg T2N0IDMxLCAyMDE3IGF0IDExOjA1IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+TWFyaXVz4oCZIHByb3Bvc2VkIHN5bnRheCwgcGFzdGVkIGluIGJlbG93LCBoYXMgZXhh Y3RseSB0aGlzIGNoYXJhY3RlcmlzdGljLiZuYnNwOyBUaGUgd2F5IEkgc2VlIGl0LCBoaXMgcHJv cG9zYWwgZXNzZW50aWFsbHkgaGFzIGEgcHJpbWFyeSBwYXNzd29yZFJlc2V0IGV2ZW50IGFuZCBh IHNlY29uZGFyeSBwYXNzd29yZFJlc2V0RXh0DQogZGF0YSBzdHJ1Y3R1cmUsIHdoaWNoIGNvdWxk IGhhdmUgYmVlbiBzaW1wbHkgYW5vdGhlciBldmVudCB2YWx1ZSBpbiB0aGUgY3VycmVudCBkcmFm dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+VGhpcyBicmVha2luZyBjaGFuZ2UgbWFrZXMgdGhlIGRhdGEgc3RydWN0dXJlcyBtb3Jl IGNvbXBsaWNhdGVkIC0gbm90IGxlc3MuJm5ic3A7IEFuZCBpdCBtYWtlcyB0aGluZ3MgdGhhdCB1 c2VkIHRvIGJlIHBvc3NpYmxlIGltcG9zc2libGUsIHJlZHVjaW5nIGZsZXhpYmlsaXR5IHRvIHRo b3NlIHdobyB3b3VsZCB1c2UgdGhlIHNwZWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoZXNlIHNlZW0gbGlrZSBiYWQgdHJhZGVv ZmZzIHRvIG1lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPns8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZxdW90O2p0aSZxdW90Ozog JnF1b3Q7M2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAmcXVvdDssPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmcXVvdDtpYXQmcXVvdDs6IDE0NTg0OTYw MjUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmcXVvdDtpc3Mm cXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NjaW0uZXhhbXBsZS5j b208L3NwYW4+PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7ICZxdW90O2F1ZCZxdW90OzogWzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsgJm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNv bS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUy NDYxZmE1YmJjODc5NTkzYjc3NTQ8L3NwYW4+PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2po dWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNv bS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3PC9zcGFuPjwvYT4mcXVvdDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwO10sPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsmcXVvdDtldmVudF90eXBlJnF1 b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dv cmRSZXNldEV4dCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0 dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0PC9zcGFuPjwvYT4m cXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsm cXVvdDtldmVudCZxdW90OzogeyZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7aWQmcXVv dDs6JnF1b3Q7NDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSZxdW90Oyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZx dW90O2V4dGVuc2lvbnMmcXVvdDs6IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDs8YSBocmVm PSJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dCIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZXhhbXBsZS5jb20v c2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0PC9zcGFuPjwvYT7igJ06DQogezwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtyZXNldEF0dGVtcHRzJnF1b3Q7OjUsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPn08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+SW4gcGFydGljdWxhciwgaXQgbWFrZXMgaXQgaW1wb3NzaWJsZSB0 byBzaWduIG11bHRpcGxlIHJlbGF0ZWQgZXZlbnRzIHNoYXJpbmcgYSBjb21tb24gY2xhaW1zIHNj aGVtYSB3aXRoIGEgc2luZ2xlIHNpZ25hdHVyZSBieSB0aGUgaXNzdWVyLiZuYnNwOyBJdCBmb3Jj ZXMgdGhlIGlzc3VlciB0byBkbyB0aGUgZXh0cmEgd29yaw0KIG9mIHNpZ25pbmcgZWFjaCBvZiB0 aGUgcmVsYXRlZCBldmVudHMgKG9yIGZhY2V0cyBvZiB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50KSBp bmRpdmlkdWFsbHkgYW5kIGZvcmNlcyB0aGUgcmVjaXBpZW50cyB0byBkbyB0aGUgZXh0cmEgd29y ayBvZiBjaGVja2luZyBhbGwgdGhvc2UgdW5uZWNlc3Nhcnkgc2lnbmF0dXJlcy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Tm90IGV2 ZXJ5IHByb2ZpbGUgd2lsbCBldmVyIGhhdmUgbXVsdGlwbGUga2V5cyBpbiB0aGUg4oCcZXZlbnRz 4oCdIHNldCBidXQgdGhlcmXigJlzIGFic29sdXRlbHkgbm8gcmVhc29uIHRvIHByZWNsdWRlIGl0 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBuYW1lPSJtXy00Mzc3Nzg3NzU1ODczMjA4OTM1X19N YWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazptXy00Mzc3Nzg3NzU1ODczMjA4OTM1X19NYWls RW5kQ29tcG9zZSI+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPkZyb206PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5JZC1ldmVudCBbbWFp bHRvOjxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9y Zzwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48Yj5Pbg0KIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L2I+RGljayBIYXJkdDxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBPY3RvYmVyIDMx LCAyMDE3IDk6NTIgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDs8YnI+ DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPllhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj55YXJvbmYuaWV0 ZkBnbWFpbC5jb208L3NwYW4+PC9hPiZndDs7IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZs dDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPiZn dDs7DQogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50 QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQt ZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs7IFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPiZndDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW0lkLWV2ZW50 XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj5QbGVhc2UgZGlyZWN0IG1lIHRvIGEgcHJvcG9zYWwgdGhhdCBoYXMgYSAmcXVv dDtwcmltYXJ5JnF1b3Q7IGFuZCAmcXVvdDtzZWNvbmRhcnkmcXVvdDsgZXZlbnRzLiBJIGFncmVl IHRoYXQgaXMgdW5kZXNpcmFibGUuIEkgd291bGQgYWxzbyBlbmNvdXJhZ2UgdG8gZW5nYWdlIGlu IHRoZSBkaXNjdXNzaW9ucyBzbyB0aGF0IHdlIGNhbiBkcml2ZSBjbGFyaXR5IGFuZCBzaW1wbGlj aXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj5JIHRoaW5rIHRoZSBwcm9wb3NhbCBpcyB0aGF0IHRoZXJlIGlzIG9u ZSBldmVudCBwZXIgU0VULjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkkgdGhpbmsgaGF2aW5nIG1vcmUg dGhhbiBvbmUgZXZlbnQgcGVyIFNFVCBhZGRzIGNvbXBsZXhpdHkgYXMgYSByZWNlaXZlciBtdXN0 IGRlYWwgd2l0aCByZWNlaXZpbmcgY29ycmVsYXRlZCBldmVudHMgaW4gb25lIFNFVCBhcyB3ZWxs IGFzIGNvcnJlbGF0ZWQgZXZlbnRzIGluIHRoZSBzYW1lIFNFVC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4vRGljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9uIFR1ZSwgT2N0IDMxLCAyMDE3IGF0IDk6NDIg UE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGhlYXIgeW91IG9uIHRo ZSBmYWN0IHRoYXQgZGlmZmVyZW50IHBlb3BsZSBoYXZlIGpvaW5lZCB0aGUgZWZmb3J0IGF0IGRp ZmZlcmVudCB0aW1lcy4mbmJzcDsgVGhhdOKAmXMgYSBub3JtYWwgcHJvY2VzcyBhcyBhbiBlZmZv cnQgYnVpbGRzIG1vbWVudHVtLiZuYnNwOyBJIGdldCB0aGF0IG5vdCBldmVyeW9uZSB3YXMgdGhl cmUgd2hlbg0KIHByZXZpb3VzIGNvbnNlbnN1cyBjYWxscyB3ZXJlIHRha2VuLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIHNob3Vs ZCBub3RlIHRoYXQgSSBoYXZlIHNwZWNpZmljIHRlY2huaWNhbCBvYmplY3Rpb25zIHRvIHRoZSBz cGVjaWZpYyBwcm9wb3NlZCBjaGFuZ2VzIGJlaW5nIGRpc2N1c3NlZCBhcyB3ZWxsLiZuYnNwOyBD dXJyZW50bHkgYWxsIGV2ZW50cyBpbiB0aGUgc2V0IGhhdmUgdGhlIHNhbWUgc3ludGF4LiZuYnNw OyBUaGUgcHJvcG9zYWxzLA0KIGFzIEkgdW5kZXJzdGFuZCB0aGVtLCByZXZlcnQgdXMgdG8gYSBz dGF0ZSB3aGVyZSB0aGVyZeKAmXMgYSDigJxwcmltYXJ54oCdIGFuZCDigJxzZWNvbmRhcnnigJ0g ZXZlbnRzLCB3aXRoIGRpZmZlcmVudCBzeW50YXggZm9yIHRoZSB0d28gY2xhc3Nlcy4mbmJzcDsg VGhhdOKAmXMgbmVlZGxlc3NseSBtb3JlIGNvbXBsaWNhdGVkLCBhZGRpbmcgbm8gYWN0dWFsIHZh bHVlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPkZyb206PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5EaWNrIEhhcmR0IFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+ZGljay5oYXJkdEBnbWFpbC5jb208L3NwYW4+PC9hPl08c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNk YXksIE9jdG9iZXIgMzEsIDIwMTcgOTozNyBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TWlrZSBKb25lcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvc3Bh bj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+UGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0OzsgWWFyb24gU2hlZmZlciAm bHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48 L2E+Jmd0OzsNCiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5yaWNoYW5uYUBhbWF6b24uY29tPC9zcGFuPjwvYT4mZ3Q7OyBJRCBFdmVudHMgTWFp bGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudEBpZXRmLm9yZzwvc3Bh bj48L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGJyPg0KPGI+U3Vi amVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQ/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk1pa2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+QXMgeW91IHdlbGwga25v dywgbWFueSBwZW9wbGUgaW4gYSBXRyBkb24ndCBsb29rIGNsb3NlbHkgYXQgYSBzcGVjaWZpY2F0 aW9uIHVudGlsIGxhc3QgY2FsbCBpcyBtYWRlLiBBZGRpdGlvbmFsbHksIHdlIGFyZSBjb21pbmcg dXAgb24gb25seSB0aGUgM3JkIFdHIG1lZXRpbmcuIFRoZSBXRyBoYXMgbm90IGV4aXN0ZWQgZm9y IHZlcnkgbG9uZy4gV2hpbGUgc29tZSBvZg0KIHRoZSBwYXJ0aWNpcGFudHMgaGF2ZSBiZWVuIHdv cmtpbmcgb24gdGhpcyBmb3IgYSB3aGlsZSwgbWFueSBoYXZlIG5vdCwgYW5kIHdlIGFyZSBsb29r aW5nIGZvciBjb25zZW5zdXMgYWNyb3NzIHRoZSBXRy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5TaW5j ZSBTZWNFdmVudCBpcyBhIGZyYW1ld29yayB0aGF0IHdlIGV4cGVjdCB0byBiZSBwcm9maWxlZCwg SSBmZWVsIGl0IGlzIGltcG9ydGFudCB0byBlbnN1cmUgdGhhdCBTZWNFdmVudCBzcGVjaWZpY2F0 aW9ucyBhcmUgZWFzeSBmb3IgYSB2YXJpZXR5IG9mIHByb2ZpbGVzIHRvIGFkb3B0LCBhbmQgdGhh dCB0aGUgc2VtYW50aWNzIG1ha2Ugc2Vuc2UuIEkgYWxzbyB0aGluaw0KIHRoYXQgcHJvcGVydGll cyB0aGF0IGFyZSBzcGVjaWZpYyB0byBhIHByb2ZpbGUgc2hvdWxkIGJlIGxlZnQgdG8gdGhhdCBw cm9maWxlIGFuZCBub3QgYmUgaW5jbHVkZWQgaW4gU2VjRXZlbnQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+U2luY2UgdGhpcyBpcyBhIGZyYW1ld29yaywgaXQgaXMgZXhwZWN0ZWQgdGhhdCBhcyBkaWZm ZXJlbnQgZ3JvdXBzIHByb2ZpbGUgaXQsIHRoZXJlIHdpbGwgYmUgYWRkaXRpb25hbCBmZWVkYmFj ay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5TcGVjaWZpY2FsbHksIGFzIGEgcGFydGljaXBhbnQgaW4g dGhlIFJJU0MgcHJvZmlsZSBvZiBTRVQsIGEgbnVtYmVyIG9mIGlzc3VlcyBpbiBTRVQgaGF2ZSBz dXJmYWNlZCBhcyB0aGUgUklTQyBXRyBoYXMgbG9va2VkIGF0IGhvdyB0byB1c2UgdGhlIFNFVC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj5BcyBmb3IgU0VUIGJlaW5nIHN0YWJsZSBmb3Igb3ZlciBhIHll YXIsIHRoZXJlIGhhdmUgYmVlbiBhIG51bWJlciBvZiBjaGFuZ2VzIHRvIFNFVCBzaW5jZSB0aGVu LiBJIGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgd2FzIGNvbnNlbnN1cy4gQmVmb3JlIHRoZSBXRyB3 YXMgZm9ybWVkLCBJIGFuZCBzZXZlcmFsIG90aGVycyBoYWQgZXhwcmVzc2VkIGNvbmNlcm4gb24g dGhlDQogZGVzaWduIG9mIFNFVCB3aGVuIFBoaWwgcHJlc2VudGVkIGl0IGF0IGFuIElJVyBzZXNz aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkFzIHRvIHRha2luZyBhbm90aGVyIHllYXIsIEkgYW0g aG9wZWZ1bCB3ZSBjYW4gcmVzb2x2ZSB0aGUgcmVtYWluaW5nIGlzc3VlcyBpbiBTRVQgYW5kIHB1 Ymxpc2ggYSBuZXcgZHJhZnQgZm9yIGxhc3QgY2FsbC4gSSBkbyBub3QgdGhpbmsgd2Ugd2lsbCBu ZWVkIHRvIHdhaXQgZm9yIGFub3RoZXIgV0cgbWVldGluZyB0byBhc2sgZm9yIGxhc3QgY2FsbC4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5XZSBhbHNvIGhhdmUgYSBudW1iZXIgb2Ygb3RoZXIg ZG9jdW1lbnRzIHRoYXQgYXJlIG5vdCBpbiBsYXN0IGNhbGwsIGFuZCB3ZSBkb24ndCBoYXZlIGEg V0cgYWRvcHRlZCBkcmFmdCB5ZXQgZm9yIG1hbmFnZW1lbnQuIFNvIHRoZXJlIGFyZSBzdGlsbCBh IG51bWJlciBvZiBkb2N1bWVudHMgdG8gd29yayB0aHJvdWdoIGJlZm9yZSB3ZSBoYXZlIGFsbCB0 aGUgYml0cyBmb3INCiBzb21lb25lIHRvIHdvcmsgd2l0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5J IGRvIHRoaW5rIHdlIGhhdmUgYmVlbiBtYWtpbmcgZ29vZCBwcm9ncmVzcyBzaW5jZSB0aGUgbGFz dCBJRVRGIG1lZXRpbmcsIGFuZCBJIGFtIGhvcGVmdWwgd2UgY2FuIGtlZXAgdXAgdGhpcyBtb21l bnR1bSBhbmQgZmluYWxpemUgYWxsIHRoZSBkb2N1bWVudHMgaW4gYSB0aW1lbHkgbWFubmVyLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPi9EaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+T24gVHVlLCBPY3QgMzEsIDIwMTcgYXQgMTI6 NDggUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JdOKAmXMgaGFyZCBm b3IgbWUgdG8gZXZlbiBleHByZXNzIG15IGxldmVsIG9mIGZydXN0cmF0aW9uIHdpdGggdGhlIHJl Y2VudCBhdHRlbXB0cyB0byBvbmNlIGFnYWluIHJlZGVzaWduIHRoZSBTZWNFdmVudCBUb2tlbiBz cGVjLiZuYnNwOyBXZeKAmXZlIGJlZW4gYXQgdGhpcyBmb3IgbXVsdGlwbGUgeWVhcnMgYmVjYXVz ZSBwZW9wbGUNCiBrZWVwIHRyeWluZyB0byByZXZpc2l0IGRlY2lzaW9ucyB0aGF0IHdlcmUgbG9u ZyBhZ28gbWFkZSBieSBjb25zZW5zdXMuJm5ic3A7IEl04oCZcyBiZWVuIHN0YWJsZSBmb3Igb3Zl ciBhIHllYXIgYW5kIHRoZSBtYWpvcml0eSBvZiBXR0xDIHJlc3BvbmRlbnRzIHNhaWQgc29tZSB2 YXJpYW50IG9mIOKAnFdvcmtzIGZvciBtZSDigJMgc2hpcCBpdCHigJ08L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhlcmXigJlzIG5v dCBzdWZmaWNpZW50IGp1c3RpZmljYXRpb24gdG8gdHJ5IHRvIHVuZG8gY29uc2Vuc3VzIHBvc2l0 aW9ucyB0aGF0IGhhdmUgYmVlbiBkZWJhdGVkIGFuZCBhZmZpcm1lZCBvdmVyIGFuZCBvdmVyLiZu YnNwOyBDb3VudGVuYW5jaW5nIHdob2xlc2FsZSBjaGFuZ2VzIGF0IHRoaXMgbGF0ZSBkYXRlIGlz IGNvdW50ZXJwcm9kdWN0aXZlDQogaW4gdGhlIGV4dHJlbWUhPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkl04oCZcyBmYXIgYmV0dGVy IHRoYW4gZ29vZCBlbm91Z2ggYXMtaXMuJm5ic3A7IEluIG15IGV4cGVyaWVuY2UsIGlmIHdlIHN0 YXJ0IHJlZGVzaWduaW5nIGl0LCBpdCB3aWxsIHJlc3VsdCBpbiBhbm90aGVyIHllYXLigJlzIGRl bGF5LiZuYnNwOyBJdCBkb2VzIHNvbWV0aGluZyBzaW1wbGUgYW5kIHVzZWZ1bC4mbmJzcDsgUGxl YXNlLCBsZXTigJlzIGp1c3QNCiBzaGlwIGl0LCBzbyBwZW9wbGUgY2FuIHJlbHkgb24gaXQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxhIG5hbWU9Im1fLTQzNzc3ODc3NTU4NzMyMDg5MzVfbV8tNTAx Mzg1NDg2MTQxMDIiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6bV8tNDM3Nzc4Nzc1NTg3MzIwODkzNV9tXy01MDEz ODU0ODYxNDEwMiI+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48Yj5Gcm9tOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+UGhpbCBIdW50IChJRE0pIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1vbmRheSwgT2N0 b2JlciAzMCwgMjAxNyAyOjQyIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5EaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWls dG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNj OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+WWFy b24gU2hlZmZlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnlhcm9uZi5pZXRmQGdtYWls LmNvbTwvc3Bhbj48L2E+Jmd0OzsgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhy ZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+cmljaGFubmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+Jmd0OzsNCiBN aWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT4mZ3Q7OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZs dDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbSWQtZXZl bnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQ/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JbmxpbmUuLi48YnI+DQo8YnI+DQpQaGlsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48YnI+DQpPbiBP Y3QgMzAsIDIwMTcsIGF0IDI6MjIgUE0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpk aWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmRpY2suaGFyZHRAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5IaSBQaGlsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkNvcnJlY3Qg bWUgaWYgSSBhbSBtaXN1bmRlcnN0YW5kaW5nLCBidXQgdGhlcmUgaXMgYSBSSVNDIHByb2ZpbGUg ZXZlbnQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+Jm5ic3A7PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7d2hpdGUtc3BhY2U6cHJl LXdyYXAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij4mcXVvdDs8YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5v cGVuaWQubmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlXy0yNTVDJmFtcDtkPUR3TUZhUSZh bXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5h NUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209aXlWbnJabXI5 X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZhbXA7cz0yNWwwOXNIOFlWNDJ4emdV LUNYU2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQv cmlzYy9ldmVudC10eXBlLzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+YWNjb3VudC1j cmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj7igJ08L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7d2hpdGUtc3Bh Y2U6cHJlLXdyYXAiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPmFuZCBhbiBT Q0lNIHByb2ZpbGUgZXZlbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+JnF1b3Q7PGEgaHJlZj0iaHR0cHM6 Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZl bnQvcGFzc3dvcmRSZXNldEV4dDwvc3Bhbj48L2E+4oCdPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkknbSBzdWdnZXN0aW5nIHRoYXQgdHdvIGRpZmZlcmVu dCBldmVudHMgd291bGQgYmUgc2VudC4gRW1iZWRkaW5nIG9uZSBpbiB0aGUgb3RoZXIgZG9lcyBu b3QgbWFrZSBzZW5zZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbHQ7cGgmZ3Q7SXQgaXMgYSBoeXBvdGhldGljYWwgZXhhbXBsZS4g SnVzdCBiZWNhdXNlIHlvdSBkaXNhZ3JlZSBvbiB0aGlzIGRvZXMgbm90IG1lYW4gb3RoZXJzIGFy ZSBub3QgdmFsaWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkkganVzdCBwaWNrZWQgb3ZlcmxhcHBpbmcg cHJvcG9zYWxzIHRoYXQgaGF2ZSBkaWZmZXJlbnQgbWVhbmluZyAoYnV0IG5vdCB0aGUgc2FtZSkg dG8gaWxsdXN0cmF0ZSB0aGUgZGlmZmVyZW5jZSBmcm9tIGlzc3VpbmcgYSBzaW5nbGUgc2V0IHdp dGggZGlmZmVyZW50IGV2ZW50cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hp dGUiPkFzIEkgaGF2ZSBzdGF0ZWQgdGhpcyBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIGFzc2VydGlu ZyBtdWx0aXBsZSBkaXN0aW5jdCBldmVudHMgaW4gb25lIFNFVC4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj5BbHNvLCBJIHRoaW5rIGl0IGlzIHNpbXBsZXIgdG8gaGF2ZSBldmVudF90eXBlIGJl IGF0IHRoZSBzYW1lIGxldmVsIGFzIGV2ZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4mbHQ7cGgmZ3Q7bWF5IGJlLiBJIHdhcyB3b3Jr aW5nIGZyb20gQW5uYWJlbGxlJ3MgcHJvcG9zZWQgZm9ybWF0LiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPns8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJnF1b3Q7 anRpJnF1b3Q7OiAmcXVvdDszZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90Oyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7 OiAxNDU4NDk2MDI1LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAm cXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NjaW0u ZXhhbXBsZS5jb208L3NwYW4+PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiBbPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhh bXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVk cy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0PC9zcGFuPjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRw czovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5leGFt cGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3PC9zcGFuPjwvYT4mcXVvdDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7XSw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7JnF1b3Q7ZXZlbnRfdHlw ZSZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bh c3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwvc3Bhbj48 L2E+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJz cDsmcXVvdDtldmVudCZxdW90OzogeyZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtpZCZx dW90OzomcXVvdDs0NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5JnF1b3Q7LDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm cXVvdDtyZXNldEF0dGVtcHRzJnF1b3Q7OjU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPns8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJnF1b3Q7anRpJnF1b3Q7OiAmcXVvdDszZDBjM2NmNzk3NTg0 YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OiAxNDU4NDk2MDI1LDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmcXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9 Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5odHRwczovL3NjaW0uZXhhbXBsZS5jb208L3NwYW4+PC9hPiZxdW90Oyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7 OiBbPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmcXVv dDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4 Nzk1OTNiNzc1NCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0 dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0PC9z cGFuPjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 ICZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3 NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0 MWQ3Njc2ZWU3PC9zcGFuPjwvYT4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsgJm5ic3A7XSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsgJm5ic3A7JnF1b3Q7ZXZlbnRfdHlwZSZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3Bl bmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV9hY2NvdW50LTJEY3JlZGVudGlhbC0y RGNoYW5nZS0yRHJlcXVpcmVkJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1 WXFQa0FJMWFMY0xONEtaTkEmYW1wO209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lG Xzh1OF9xU0NfdyZhbXA7cz1uUXk5ZXpQUmpER2R2UlRDYWlEdGk0T0hlbEgzREtnVUNUS2pGMkdR LXNvJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0 dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL2FjY291bnQt Y3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWQ8L3NwYW4+PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7JnF1b3Q7ZXZlbnQmcXVvdDs6IHs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDvigJxzdWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A74oCcaXNz4oCdOiZxdW90 OzxhIGhyZWY9Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLzwvc3Bhbj48L2E+ JnF1b3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPn08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5PbiBN b24sIE9jdCAzMCwgMjAxNyBhdCAxMjowOSBQTSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWls dG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+QW5uYWJlbGxlL0RpY2ssPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+VGhhbmtzIGZvciB0aGUgY29tbWVudHMuIEkgdGhpbmsgd2UgbmVlZCB0byBleGFtaW5lIHRo ZSBjb25zZXF1ZW5jZXMgb2YgdGhlIHByb3Bvc2FsIGluIEpTT04uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5BcyBJ IHN0YXRlZCwgd2hhdCBjYXVzZXMgbW9zdCBvZiB0aGUgaXNzdWUgaXMgdGhlIHByb3Bvc2VkIGV4 dGVuc2lvbiBtZWNoYW5pc20gaW4gdGhlIHBheWxvYWQgKHBvc3NpYmx5IHVzaW5nIGV2ZW50cyBp biBhIHJlY3Vyc2l2ZSB3YXkpLiBEb2VzIGl0IGZvbGxvdyB0aGUgb2xkIGZvcm1hdCBvciB0aGUg bmV3PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj5MZXTigJlzICZuYnNwO2NvbnNpZGVyIGEgdXNlIGNhc2Ugd2hlcmUg d2UgaGF2ZSBhbiBpZGVudGl0eSBtYW5hZ2VtZW50IHN5c3RlbSB0aGF0IHVzZXMgU0NJTSwgYnV0 IHRoZSBTQ0lNIHN5c3RlbSBpcyBhbHNvIHRoZSB1bmRlcmx5aW5nIGRhdGEgc3RvcmUgZm9yIENv bm5lY3QuJm5ic3A7IEEgUGFzc3dvcmQgcmVzZXQgbWlnaHQgZ2VuZXJhdGUgdGhlIGZvbGxvd2lu ZyBldmVudCB3aGljaA0KIGhhcyBhbiBleHRlbnNpb24gKGNvbnZleWluZyByZXNldCBjb3VudCkg QU5EIG92ZXJsYXBwaW5nIHN0YXRlbWVudCBmcm9tIFJJU0MuJm5ic3A7IEJPVEggb2Ygd2hpY2gg bWlnaHQgYmUgaW1wb3J0YW50IHRvIGEgc2ltaWxhciByZWNlaXZlciB1c2luZyBTQ0lNIGFuZCBP SURDLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj5UaGUgMDMgc3BlYyBjdXJyZW50bHkg d291bGQgYWxsb3c6PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj57PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPiZuYnNwOyAmcXVvdDtqdGkmcXVvdDs6ICZxdW90OzNkMGMzY2Y3OTc1ODRiZDE5M2Jk MGZiMWJkNGU3ZDMwJnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OiAxNDU4NDk2MDI1LDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7aXNzJnF1 b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29t PC9zcGFuPjwvYT4mcXVvdDssPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDthdWQmcXVvdDs6IFs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhy ZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3 NzU0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9q aHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQ8L3NwYW4+PC9h PiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNv bS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYw NDUxNmIxZDA4NjQxZDc2NzZlZTc8L3NwYW4+PC9hPiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsgXSw8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7ICZxdW90O2V2 ZW50cyZxdW90OzogezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7dXJuOmlldGY6cGFyYW1zOnNjaW06 ZXZlbnQ6cGFzc3dvcmRSZXNldCZxdW90Ozo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHsg JnF1b3Q7aWQmcXVvdDs6JnF1b3Q7NDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSZxdW90O30sPG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZl bnQvcGFzc3dvcmRSZXNldEV4dCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0PC9z cGFuPjwvYT4mcXVvdDs6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB7ICZxdW90O3Jlc2V0 QXR0ZW1wdHMmcXVvdDs6NX0sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50 LTJEdHlwZV8tMjU1QyZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4 QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtB STFhTGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThf cVNDX3cmYW1wO3M9MjVsMDlzSDhZVjQyeHpnVS1DWFNnOHhIOXR2eURKejQwdENSakZhbGhrdyZh bXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8v c2NoZW1hcy5vcGVuaWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS9cPC9zcGFuPjwvYT48 YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1y ZXF1aXJlZCZxdW90Ozogezwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxzdWLigJ064oCdNzM3NTYy NkE2NTYzNzTigJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGlzc+KAnTomcXVvdDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPjxhIGhyZWY9Imh0dHBzOi8vaWRwLmV4YW1w bGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBz Oi8vaWRwLmV4YW1wbGUuY29tLzwvc3Bhbj48L2E+JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi Pn08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PkluIHRoZSBhYm92ZSAtIGVhY2ggcGF5bG9hZCBpcyBhIOKAmHBlZXInIGFuZCBpc3N1ZWQgd2l0 aG91dCBwcmVmZXJlbmNlIGJ5IHRoZSB0cmFuc21pdHRlci4gVGhlIHJlY2VpdmVyIGNhbiBhc3Np Z24gcHJpb3JpdHkgaW4gaXRzIG93biBjb250ZXh0IGlmIHRoYXQgbWF0dGVycy48L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxkaXY+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5UaGUgbmV3IHByb3Bvc2FsOjwvc3Bhbj48L2I+PG86cD48L286cD48L3By ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj57PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDtqdGkm cXVvdDs6ICZxdW90OzNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwJnF1b3Q7LDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7 aWF0JnF1b3Q7OiAxNDU4NDk2MDI1LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRw czovL3NjaW0uZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPC9zcGFuPjwvYT4mcXVvdDssPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDth dWQmcXVvdDs6IFs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxl LmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4 ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQ8L3NwYW4+PC9hPiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90 OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0 MWQ3Njc2ZWU3IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0 cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTc8L3Nw YW4+PC9hPiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDsmbmJzcDsgXSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7ICZxdW90O2V2ZW50JnF1b3Q7OiB7PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyDigJxldmVudF90eXBl4oCdOiZxdW90O3VybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBh c3N3b3JkUmVzZXTigJ0sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtpZCZxdW90OzrigJ00NGY2MTQy ZGY5NmJkNmFiNjFlNzUyMWQ54oCdLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXZlbnRz4oCdOns8bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0mZ3Q7bm90ZSDigKZpcyB0aGlzIHRoZSBvbGQgb3IgbmV3IHN0cnVjdHVy ZT8gJmx0Oy08bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBz Oi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0IiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2 ZW50L3Bhc3N3b3JkUmVzZXRFeHQ8L3NwYW4+PC9hPiZxdW90Ozo8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHsgJnF1b3Q7cmVzZXRBdHRlbXB0cyZxdW90Ozo1fSw8bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm cXVvdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cC0zQV9fc2NoZW1hcy5vcGVuaWQubmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlXy0y NTVDJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2 NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEta TkEmYW1wO209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZhbXA7 cz0yNWwwOXNIOFlWNDJ4emdVLUNYU2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmFtcDtlPSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9zY2hlbWFzLm9w ZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL1w8L3NwYW4+PC9hPjxicj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDthY2NvdW50LWNyZWRlbnRpYWwtY2hhbmdl LXJlcXVpcmVkJnF1b3Q7OiB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnHN1YuKAnTrigJ03Mzc1 NjI2QTY1NjM3NOKAnSw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcaXNz4oCdOiZxdW90Ozwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+PGEgaHJlZj0iaHR0cHM6Ly9pZHAuZXhh bXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0 cHM6Ly9pZHAuZXhhbXBsZS5jb20vPC9zcGFuPjwvYT4mcXVvdDs8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IH08L3NwYW4+Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gdGhlIGFib3ZlLCBzdWItZXZlbnRzIG9yIGV4 dGVuc2lvbnMgaGF2ZSBhIGRpZmZlcmVudCBmb3JtYXQuIFRoZSBzYW1lIGNvbXBsYWludCBhYm91 dCB0aGUgb3JpZ2luYWwgc3RhbmRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Kk9SKiAoaWYgdGhlIHJlY2VpdmVyIGNhcmVzIGFib3V0 IFJJU0MgbW9yZSkuJm5ic3A7IE5vdGUgdGhhdCB0aGlzIGxlYWRzIHRvIGEgdHJpcGxlIG5lc3Rl ZCBzdHJ1Y3R1cmUuPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPns8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+Jm5ic3A7ICZxdW90O2p0aSZxdW90OzogJnF1b3Q7M2QwYzNjZjc5NzU4NGJkMTkzYmQw ZmIxYmQ0ZTdkMzAmcXVvdDssPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDtpYXQmcXVvdDs6IDE0NTg0OTYwMjUsPG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDtpc3MmcXVv dDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NjaW0uZXhhbXBsZS5jb208 L3NwYW4+PC9hPiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Jm5ic3A7ICZxdW90O2F1ZCZxdW90OzogWzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJl Zj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3 NTQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2po dWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NDwvc3Bhbj48L2E+ JnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m bmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29t L0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0 NTE2YjFkMDg2NDFkNzY3NmVlNzwvc3Bhbj48L2E+JnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyBdLDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsgJnF1b3Q7ZXZl bnQmcXVvdDs6IHs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGV2ZW50X3R5cGXigJ06PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQiPiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZlbnRf cmlzY19ldmVudC0yRHR5cGVfLTI1NUMmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0 eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZs SzY3eUZfOHU4X3FTQ193JmFtcDtzPTI1bDA5c0g4WVY0Mnh6Z1UtQ1hTZzh4SDl0dnlESno0MHRD UmpGYWxoa3cmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+aHR0cDovL3NjaGVtYXMub3BlbmlkLm5ldC9zZWNldmVudC9yaXNjL2V2ZW50LXR5cGUvXDwv c3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDsgJm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDthY2NvdW50LWNyZWRl bnRpYWwtY2hhbmdlLXJlcXVpcmVkPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij7igJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IOKAnHN1YuKAnTrigJ03Mzc1NjI2QTY1NjM3NOKAnSw8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDvigJxpc3PigJ06JnF1 b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJodHRwczov L2lkcC5leGFtcGxlLmNvbS8lRTIlODAlOUMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5odHRwczovL2lkcC5leGFtcGxlLmNvbS/igJw8L3NwYW4+PC9hPiw8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg 4oCcZXZlbnRz4oCdOns8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7dXJuOmlldGY6cGFyYW1zOnNjaW06 ZXZlbnQ6cGFzc3dvcmRSZXNldCZxdW90Ozo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeyZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2lkJnF1 b3Q7OuKAnTQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDnigJ0sPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxldmVudHPigJ06ezxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEg aHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2V4YW1wbGUu Y29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwvc3Bhbj48L2E+JnF1b3Q7OjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgeyAmcXVvdDtyZXNldEF0dGVtcHRzJnF1b3Q7OjV9LDxzcGFuIHN0eWxlPSJm b250LXNpemU6MTMuNXB0Ij4mbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 fTwvc3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4N CjxkaXY+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt9PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0K PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IH0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJz cDsmbmJzcDsmbmJzcDt9PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+fTwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPkluIHRoZSBhYm92ZSwgdGhlIGV4dGVuc2lvbiBpcyBwbGFjZWQgaW5zaWRlIHRo ZSBldmVudCBpdCBleHRlbmRzLiBJdCBmb2xsb3dzIHRoZSBvbGQgZm9ybWF0IChvciBzaG91bGQg aXQgZm9sbG93IHRoZSBuZXc/KTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2 Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4qT1IqIEZvbGxvd2luZyB0aGUg dG9wIGxheWVyIHBhdHRlcm4gb2Ygc2luZ3VsYXIgZXZlbnQmbmJzcDsgTm90ZSB0aGF0IHRoaXMg bGVhZHMgdG8gYSB0cmlwbGUgbmVzdGVkIHN0cnVjdHVyZS48L3NwYW4+PC9iPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ezxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7anRpJnF1b3Q7OiAmcXVv dDszZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90Oyw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7ICZxdW90O2lhdCZxdW90Ozog MTQ1ODQ5NjAyNSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7ICZxdW90O2lzcyZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zY2ltLmV4 YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0 dHBzOi8vc2NpbS5leGFtcGxlLmNvbTwvc3Bhbj48L2E+JnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiBb PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZu YnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMv OThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJi Yzg3OTU5M2I3NzU0PC9zcGFuPjwvYT4mcXVvdDssPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJo dHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5l eGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3PC9zcGFuPjwvYT4mcXVv dDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 Jm5ic3A7IF0sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PiZuYnNwOyZuYnNwOyAmcXVvdDtldmVudCZxdW90OzogezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXZl bnRfdHlwZeKAnTo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+JnF1b3Q7PGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVt YXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV8tMjU1QyZhbXA7ZD1Ed01G YVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7 cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPWl5Vm5y Wm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmYW1wO3M9MjVsMDlzSDhZVjQy eHpnVS1DWFNnOHhIOXR2eURKejQwdENSakZhbGhrdyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0L3NlY2V2 ZW50L3Jpc2MvZXZlbnQtdHlwZS9cPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO2FjY291bnQtY3JlZGVudGlhbC1j aGFuZ2UtcmVxdWlyZWQ8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+4oCdLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMy41cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxz dWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg 4oCcaXNz4oCdOiZxdW90OzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJo dHRwczovL2lkcC5leGFtcGxlLmNvbS8lRTIlODAlOUMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2lkcC5leGFtcGxlLmNvbS/igJw8L3NwYW4+PC9h Piw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsg4oCcZXZlbnTigJ06ezwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxldmVudF90eXBl4oCdOiZxdW90 O3VybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3JkUmVzZXTigJ0sPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj4mcXVvdDtpZCZxdW90OzrigJ00NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ54oCd LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXZlbnTigJ06ezxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXZlbnRfdHlwZeKAnTom cXVvdDs8YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNl dEV4dCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8v ZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0PC9zcGFuPjwvYT7igJ0sPG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtyZXNldEF0 dGVtcHRzJnF1b3Q7OjU8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+IDwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308bzpwPjwvbzpwPjwv cHJlPg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwO308L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij59PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5UaGlzIGZvcm1hdCBmb2xsb3dzIHRoZSBwcm9wb3NlZCBzaW5ndWxhciBldmVudCBmb3JtYXQg cmVjdXJzaXZlbHkgYW5kIGlzIDMgbGF5ZXJzIGRlZXAuIE5vdGUgdGhhdCB0aGUgcGFyc2VyIGhh cyB0byBjb250aW51ZSB0byBzZWFyY2ggdGhlIGRvY3VtZW50IGZvciB0aGluZ3MgdGhhdCBhcmVu 4oCZdCB0aGVyZSBhcyBpdCBoYXMgdG8gc3RvcCB3aGVuIG5vIOKAnGV2ZW504oCdIGF0dHJpYnV0 ZSBpcyBmb3VuZCByYXRoZXIgdGhhbiBpdGVyYXRlIG92ZXIgYW4gYXJyYXkuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlBoaWw8YnI+DQo8YnI+DQpPcmFjbGUgQ29y cG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdDxicj4NCkBpbmRlcGVu ZGVudGlkPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNvbSZhbXA7ZD1Ed01GYVEmYW1wO2M9 Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpC VFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NR Nk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmYW1wO3M9OXNZaGdwRXpiN3hQbFFGbUNDWE5t SG82ZlFOOUlCdS1TSEphbWdfQjRIcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L3NwYW4+PC9hPjxicj4NCjxh IGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9uIE9jdCAzMCwgMjAxNywgYXQgODo1NyBBTSwgUmlj aGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6 b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cmljaGFu bmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojQzM0NkUwIj5S ZXBsaWVzIGlubGluZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+ SWRlbnRpdHkgU2VydmljZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RnJvbTo8c3BhbiBjbGFz cz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAy NDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlBoaWwNCiBI dW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bh bj48L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkz NW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAz NDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+U3VuZGF5LCBPY3Rv YmVyIDI5LCAyMDE3IGF0IDU6MjUgUE08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0ibS00Mzc3Nzg3 NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAy NjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5E aWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaWNrLmhhcmR0QGdtYWlsLmNv bTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMy MDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2 MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPllhcm9uIFNo ZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208 L3NwYW4+PC9hPiZndDssDQogTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0OywgJnF1b3Q7 UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNo YW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+cmljaGFubmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+Jmd0OywNCiBJRCBFdmVudHMgTWFpbGlu ZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48 L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkz NW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAz NDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UmU6IFtJZC1ldmVu dF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD88L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SSBob3BlIHRoaXMgYW5z d2VycyB5b3VyIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPk15IOKAnG1heeKAnSB3YXMgYmVjYXVzZSBJIGNhbuKAmXQgc2VlIGEgcmVh c29uIHdoeSBub3QuIFRoZSBxdWVzdGlvbiBzaG91bGQgYmUsIHdoYXQgaXMgdGhlIGp1c3RpZmlj YXRpb24gdG8gbWFrZSDigJxldmVudHPigJ0gc2luZ3VsYXI/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPltyaWNoYW5uYV1UaGUg c2luZ3VsYXIg4oCcZXZlbnTigJ0gY2xhaW0gaGFzIGNsZWFyZXIgc2VtYW50aWNzIGFuZCBpcyBl YXNpZXIgdG8gcHJvY2Vzcy4gV2Ugc2hvdWxkIG9wdCBmb3IgZWFzaWVyIHNvbHV0aW9ucyB1bmxl c3MgdGhlcmUgYXJlIHVzZSBjYXNlcyB0aGF0IHJlcXVpcmUgbW9yZSBjb21wbGV4aXR5Llsvcmlj aGFubmFdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPlRoZXJlIGFyZSBtYW55IHJlYXNvbnMgZm9yIG11bHRpcGxlIGV2ZW50cyBpbiBhIFNF VC4mbmJzcDsgU29tZSBhcmUgZ29vZCwgc29tZSBub3Qgc28gZ29vZC4gU29tZSBvZiB0aGUgcmVh c29ucy4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjEuJm5ic3A7IE11bHRpcGxlIGV2ZW50IHBheWxvYWRzIGV4cHJlc3Npbmcgc3RhdGVtZW50cyBh Ym91dCBsYXJnZWx5IHRoZSAqc2FtZSp0aGluZy4gRm9yIGV4YW1wbGUsIFNDSU0gcGFzc3dvcmQg cmVzZXQgQU5EIFJJU0MgcGFzc3dvcmQgcmVzZXQuJm5ic3A7IEEgUklTQyBFdmVudCBhbmQgYW4g T3BlbkJhbmtpbmcgRXZlbnQuIElzIG9uZSBhIGNvbXBsZW1lbnQgdG8gdGhlIG90aGVyPyZuYnNw Ow0KIERvIHRoZXkgb3ZlcmxhcCBvciBhcmUgdGhleSBkaXN0aW5jdD8gJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPlty aWNoYW5uYV1Db3B5L3Bhc3RlZCBmcm9tIG15IGVhcmxpZXIgZW1haWw6PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojQzM0NkUwIj5X aHkgaXMgaXQgbmVjZXNzYXJ5IG9yIGFwcHJvcHJpYXRlIHRvIGluY2x1ZGUgdGhlc2UgZXZlbnRz IGluIHRoZSBzYW1lIFNFVD8gVGhleSBhcmUgbGlrZWx5IGJlaW5nIGdlbmVyYXRlZCBieSBkaWZm ZXJlbnQgc3lzdGVtcyBhdCBkaWZmZXJlbnQgdGltZXMgb24gdGhlIHRyYW5zbWl0dGVy4oCZcyBz aWRlLCBjb25zdW1lZA0KIGJ5IGRpZmZlcmVudCBzeXN0ZW1zIG9uIHRoZSByZWNlaXZlcuKAmXMg c2lkZSwgYW5kIHBvc3NpYmx5IGJlaW5nIHRyYW5zbWl0dGVkIG92ZXIgZGlmZmVyZW50IGV2ZW50 IHN0cmVhbXMuIEkga25vdyB0aGUgbGF0dGVyIHdvdWxkIGJlIHRoZSBjYXNlIGZvciB1cywgYXMg YSByZWNlaXZlci4gRXZlbiBpZiBpdOKAmXMgbm90LCBpcyBpdCBidXJkZW5zb21lIHRvIHNlbmQg dGhlc2UgZXZlbnRzIHNlcGFyYXRlbHk/IFdoYXQgdmFsdWUgaXMgZ2FpbmVkIGluDQogY29tYmlu aW5nIHRoZW0/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJjb2xvcjojQzM0NkUwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPkFkZGl0aW9uYWxseSwg c2luY2UgdGhlIHNpZ25hdHVyZSBpcyBvdmVyIHRoZSBTRVQgYW5kIG5vdCB0aGUgZXZlbnQgb2Jq ZWN0cywgUmVjZWl2ZXJzIGluZGVwZW5kZW50bHkgcm91dGUgc2VwYXJhdGUgZXZlbnRzIGZyb20g YSBzaW5nbGUgdG9rZW4gd2l0aG91dCBlaXRoZXIgbG9zaW5nIHRoZSBhYmlsaXR5IHRvIHZlcmlm eQ0KIHRoZSBhdXRoZW50aWNpdHkgb2YgdGhlIGV2ZW50IG9yIHNoYXJpbmcgYWxsIGluZm9ybWF0 aW9uIGluIHRoZSBTRVQgd2l0aCBldmVyeSBzeXN0ZW0gaGFuZGxpbmcgYW55IGV2ZW50IGluIHRo ZSB0b2tlbi5bL3JpY2hhbm5hXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iY29sb3I6I0MzNDZFMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZTtiYWNr Z3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFs IGluaXRpYWwiPg0KMi4mbmJzcDsgTXVsdGlwbGUgZXZlbnRzIHBheWxvYWRzIGV4cHJlc3Npbmcg ZGlmZmVyZW50IHN0YXRlbWVudHMgYWJvdXQgdGhlIHNhbWUgdHJhbnNhY3Rpb24gLSBSSVNDIFBh c3N3b3JkIFJlc2V0IGFuZCBSSVNDIFNlc3Npb24gQ2FuY2VsPGJyPg0KPHNwYW4gc3R5bGU9ImNv bG9yOiNDMzQ2RTAiPltyaWNoYW5uYV1TYW1lIGFzIGFib3ZlWy9yaWNoYW5uYV08L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjMuJm5ic3A7IEEgbmV3IHBy b2ZpbGUgZGVmaW5lcyBuZXcgZXZlbnQgYXR0cmlidXRlcyB0byBiZSBhZGRlZCBvbiB0byBhbiBl eGlzdGluZyBldmVudCB0eXBlIChhIHB1cmUgZXh0ZW5zaW9uKSZuYnNwOzxicj4NCjxzcGFuIHN0 eWxlPSJjb2xvcjojQzM0NkUwIj5bcmljaGFubmFdSSBoYXZlIHN1Z2dlc3RlZCBhIHdheSB0byBz dXBwb3J0IGV4dGVuc2lvbnMgd2l0aGluIGFuIGV2ZW50IGJvZHksIG11bHRpcGxlIHRpbWVzIG5v dy4gSWYgeW91IHNlZSBwcm9ibGVtcyB3aXRoIGl0LCBwbGVhc2UgcG9pbnQgdGhlbSBvdXQuWy9y aWNoYW5uYV08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+SSB0aGluayBpdCBpcyBxdWl0ZSB2YWxpZCB0byBhbGxvdyAxIGFuZCAzLiAmbmJz cDsyIGNvdWxkIGJlIGxpbWl0ZWQgYnkgc3BlY2lmaWMgcHJvZmlsZXMgbGlrZSBSSVNDIGlmIHRo ZXkgd2FudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij5JIGFtIG5vdCBpbiBhZ3JlZW1lbnQgdGhhdCBtYWtpbmcgZXZlbnQgc2luZ3VsYXIgc2ltcGxp ZmllcyBhbnl0aGluZy4gRm9yIG9uZSBpcyBtYWtlcyBleHRlbnNpb25zIGNvbXBsZXggKGFub3Ro ZXIgbmVzdGVkIEpTT04gc3RydWN0dXJlKSBhbmQgcG90ZW50aWFsbHkgY29uZmxpY3RpbmcuJm5i c3A7PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPltyaWNoYW5uYV08L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2 RTAiPldheXMgdGhhdCBtdWx0aXBsZS1ldmVudCBTRVRzIGFyZSBtb3JlIGNvbXBsaWNhdGVkOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8b2wgc3R5bGU9Im1hcmdpbi10 b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNvbG9yOiNDMzQ2RTA7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZTti YWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0 aWFsIGluaXRpYWwiPg0KSXQgcmVzdWx0cyBpbiBhIG1vcmUgY29tcGxleCBzdHJ1Y3R1cmUgZm9y IHRoZSBzaW5nbGUgZXZlbnQgdXNlIGNhc2UsIHdoaWNoIEkgdGhpbmsgd2UgYWxsIGFncmVlIGlz IHRoZSBtYWpvcml0eSB1c2UgY2FzZS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjojQzM0NkUwO21zby1saXN0OmwyIGxldmVsMSBsZm8yO2JhY2tncm91 bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1y ZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCk11bHRpcGxlLWV2ZW50IFNFVHMgaGF2ZSBhbWJpZ3Vv dXMgc2VtYW50aWNzLiBUaGUgcHJlc2VuY2Ugb2YgdHdvIGV2ZW50cyBBIGFuZCBCIGluIHRoZSBz YW1lIFNFVCBjb3VsZCBtZWFuIGFueSBvZjo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxvbCBzdHls ZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIyIiB0eXBlPSIxIj4NCjxvbCBzdHlsZT0ibWFyZ2lu LXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY29sb3I6I0MzNDZFMDttc28tbGlzdDpsMyBsZXZlbDIgbGZvMztiYWNrZ3JvdW5kOndoaXRl O2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0Omlu aXRpYWwgaW5pdGlhbCI+DQpUaGV5IGFyZSByZWxhdGVkIHRvIHRoZSBzYW1lIGxvZ2ljYWwgZXZl bnQgKGkuZS4gdGhlIHNhbWUgdGhpbmcgYXMgaWYgdGhleSB3ZXJlIGZyb20gZGlmZmVyZW50IFNF VHMgdGhhdCBoYXZlIGEgY29tbW9uIHR4bikuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY29sb3I6I0MzNDZFMDttc28tbGlzdDpsMyBsZXZlbDIgbGZvMztiYWNr Z3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91 bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQpBIGlzIGFuIGV4dGVuc2lvbiBvZiBCLjxvOnA+ PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiNDMzQ2RTA7bXNv LWxpc3Q6bDMgbGV2ZWwyIGxmbzM7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9u OmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KQiBp cyBhbiBleHRlbnNpb24gb2YgQS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJjb2xvcjojQzM0NkUwO21zby1saXN0OmwzIGxldmVsMiBsZm8zO2JhY2tncm91bmQ6 d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBl YXQ6aW5pdGlhbCBpbml0aWFsIj4NClRoZXkgYXJlIGFsaWFzZXMgZm9yIG9uZSBhbm90aGVyLjxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiNDMzQ2RTA7 bXNvLWxpc3Q6bDMgbGV2ZWwyIGxmbzM7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0 aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0K VGhleSBhcmUgbm90IGFjdHVhbGx5IHJlbGF0ZWQgdG8gb25lIGFub3RoZXIgaW4gYW55IHdheS48 bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvb2w+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBz dGFydD0iMyIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiND MzQ2RTA7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQ7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5k LXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRp YWwiPg0KQ2xhaW0gc2VtYW50aWNzIGJlY29tZSBoYXJkZXIgdG8gZGVmaW5lLCBhcyBkaWZmZXJl bnQgcHJvZmlsZXMgbWF5IHdhbnQgdG8gdXNlIHRoZSBzYW1lIGNsYWltcyBpbiBkaWZmZXJlbnQg d2F5cy48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPklmIHRoZSBXRyB3 YW50cyB0byBibG9jayAxIGFuZCAyIGFib3ZlLCB0aGVuIEkgYmVsaWV2ZSB3ZSBoYXZlIHRvIGVz dGFibGlzaCBhbiBldmVudCByZWdpc3RyeSB0byBlbnN1cmUgbmV3IEV2ZW50IHByb2ZpbGVzIGRv IG5vdCBvdmVybGFwIHRvIGVsaW1pbmF0ZSB0aGUgbmVlZCB0byBleHByZXNzIG11bHRpcGxlIGV2 ZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iY29sb3I6I0MzNDZFMCI+W3JpY2hhbm5hXUnigJltIG5vdCBzdXJlIHdoYXQg eW91IG1lYW4gYnkgdGhpcy4gQXJlIHlvdSByZWZlcnJpbmcgdG8gZXZlbnQgbmFtZXM/IFRob3Nl IGFyZSBhbHJlYWR5IGRlZmluZWQgYnkgdGhlIHNwZWMgdG8gYmUgVVJJcy5bL3JpY2hhbm5hXTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj5QaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+T3JhY2xlIENvcnBvcmF0aW9uLCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNlcyBBcmNo aXRlY3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5A aW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5jb20mYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZ dW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFu cVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1VLWE1SEJORDBIYVRYNGFuTlpm elg3cERzZks1ZjBoOW1aOUNaa2tHaWVjJmFtcDtzPUtCd0tQRm5xWV9ROTVDVEFfX1dHQ1lHVHhy RDdBR0N4dWVvUFhuS0VVVDAmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxh IGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9uIE9jdCAyOSwgMjAxNywgYXQgNDoxMiBQ TSwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZGljay5oYXJkdEBnbWFp bC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlBoaWw6PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+SW4geW91ciBleGFtcGxlcyBmb3IgaGF2aW5nIGEgcGx1cmFsaXR5IG9m IGV2ZW50cywgeW91IHVzZSB0aGUgd29yZCAmcXVvdDttYXkmcXVvdDssIHdoaWNoIGxlYWRzIG1l IHRvIHF1ZXN0aW9uIGlmIGEgcGx1cmFsaXR5IG9mIGV2ZW50cyBpcyByZWFsbHkgcmVxdWlyZWQN CiBpbiBTRVQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Zb3Ug cG9zaXQgdGhhdCBpdCB3aWxsIGJlIGRpZmZpY3VsdCBmb3IgYSBkaXN0cmlidXRlZCBzeXN0ZW0g dG8gY29ycmVsYXRlIG11bHRpcGxlIFNFVHMgd2l0aCB0aGUgc2FtZSAmcXVvdDt0eG4mcXVvdDss IGJ1dCB0aGUgZGlzdHJpYnV0ZWQgc3lzdGVtIHdpbGwgY2VydGFpbmx5DQogbmVlZCB0byBjb3Jy ZWxhdGUgZXZlbnRzIG9uIHRoZSBzYW1lIHN1YmplY3QgLS0gY29ycmVsYXRpbmcgZXZlbnRzIG9u IHRoZSBzYW1lICZxdW90O3R4biZxdW90OyBvbiB0aGUgc2FtZSBzdWJqZWN0IHNlZW1zIGZhaXJs eSBzaW1wbGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIHRo aW5rIHRoYXQgYSByZWNlaXZlciB3aWxsIG5lZWQgdG8gY29ycmVsYXRlIG11bHRpcGxlIFNFdHMg b24gdGhlIHNhbWUgc3ViamVjdCwgc28gaGF2aW5nIG11bHRpcGxlIGV2ZW50cyBpbiBhIFNFVCBp cyByZWR1bmRhbnQsIGFuZCBhZGRzIGNvbXBsZXhpdHkNCiB3aXRoIG5vIGNsZWFyIGJlbmVmaXQg dGhhdCBJIGNhbiBzZWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5BbiBpbXBsZW1lbnRvciBtYXkgY2hvb3NlIHRvIHNlbmQgbXVsdGlwbGUgU0VUcywgb3Igc2Vu ZCBhIHNpbmdsZSBTRVQgd2l0aCBtdWx0aXBsZSBldmVudHMsIHNvIGEgcmVjZWl2ZXIgd2lsbCBu ZWVkIHRvIHN1cHBvcnQgYm90aC4gSSBwcmVmZXIgd2UgcGljaw0KIG9uZSB3YXkgYW5kIG1pbmlt aXplIHRoZSBjb2RlIHBhdGhzLCBhbmQgd2Ugd2lsbCBuZWVkIHRvIHN1cHBvcnQgY29ycmVsYXRp bmcgYWNyb3NzIG11bHRpcGxlIFNFVHMsIHNvIHRoYXQgc2VlbXMgdGhlIGJlc3QgbWVjaGFuaXNt Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TGV0IG1lIGtub3cg aWYgdGhlcmUgaXMgc29tZXRoaW5nIEkgbWlzc2VkIGluIG15IGxvZ2ljLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+L0RpY2s8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBTdW4sIE9j dCAyOSwgMjAxNyBhdCAxMToyOCBBTSwgWWFyb24gU2hlZmZlcjxzcGFuIGNsYXNzPSJtLTQzNzc3 ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200 MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0 OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L3NwYW4+PC9h PiZndDs8c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1 MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkluIHRoYXQgY2FzZSwgbGV0J3MgYWRkIHRleHQgdG8g dGhhdCBlZmZlY3QsIGUuZy4gd2UgY291bGQgYWRkIHRvIHRoZSBkZWZpbml0aW9uIG9mIHRoZSAm cXVvdDtldmVudHMmcXVvdDsgY2xhaW06PGJyPg0KPGJyPg0KUHJvZmlsaW5nIHNwZWNpZmljYXRp b25zIFNIT1VMRCBkZWZpbmUgdGhlIGFsbG93ZWQgZXZlbnQgc3RhdGVtZW50cywgYW5kIE1BWSBy ZXN0cmljdCB0aGVpciBudW1iZXIuIEZvciBleGFtcGxlLCBzb21lIHByb2ZpbGVzIG1heSByZXF1 aXJlIHRoaXMgY2xhaW0gdG8gY29udGFpbiBvbmx5IGEgc2luZ2xlIGV2ZW50IHN0YXRlbWVudC48 YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PHNwYW4g Y2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2 OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5ZYXJvbjxicj4NCjxicj4NCk9uIDI0LzEwLzE3IDIyOjEwLCBNaWtlIEpvbmVz IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91 bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5p dGlhbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGFncmVlIHdpdGggbXVjaCBvZiBQaGls4oCZcyBy YXRpb25hbGUgaGVyZS48YnI+DQo8YnI+DQpJdOKAmXMgZmluZSBmb3Igc29tZSBwcm9maWxlcyB0 byBzYXkgdGhhdCB0aGUg4oCcZXZlbnRz4oCdIHNldCBtdXN0IGJlIGEgc2luZ2xldG9uLiZuYnNw OyBUaGF0IGRvZXNu4oCZdCBoYXZlIHRvIGJlIHRydWUgZm9yIGFsbCBldmVudHMuJm5ic3A7IEkg dGhpbmsgdGhpbmdzIGFyZSBmaW5lIGFzLWlzLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5 MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgw MzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+LS0gTWlrZTxicj4NCjxi cj4NCipGcm9tOiogSWQtZXZlbnQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl0gKk9uIEJlaGFsZiBPZiAqUGhp bCBIdW50PGJyPg0KKlNlbnQ6KiBNb25kYXksIE9jdG9iZXIgMjMsIDIwMTcgODo0NyBQTTxicj4N CipUbzoqIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmlj aGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPnJpY2hhbm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPiZndDs8YnI+DQoqQ2M6KiBJRCBFdmVu dHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudEBpZXRmLm9y Zzwvc3Bhbj48L2E+Jmd0Ozxicj4NCipTdWJqZWN0OiogUmU6IFtJZC1ldmVudF0gVXNlIGNhc2Vz IGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD88YnI+DQo8YnI+DQpBbm5hYmVsbGUsPGJyPg0K PGJyPg0KSSBoYXZlIGEgbnVtYmVyIG9mIGNvbmNlcm5zIHdpdGggdGhpcyBwcm9wb3NhbC48YnI+ DQo8YnI+DQpQcm9maWxpbmcgSW5kZXBlbmRlbmNlIC8gS2VlcGluZyBFdmVudCBQYXlsb2FkcyBJ bmRlcGVuZGVudDxicj4NCjxicj4NCkluZGljYXRpbmcgdGhhdCBleHRlbnNpb25zIHNob3VsZCBi ZSBoYW5kbGVkIGJ5IHByb2ZpbGVzIGxlYWRzIHRvIG1vcmUgaW50ZXItb3BlcmFiaWxpdHkgaXNz dWVzIGFuZCBtb3JlIGltcG9ydGFudGx5IGludHJ1ZGVzIG9uIHRoZSBFdmVudCBwYXlsb2FkIHNw YWNlIGJ5IHN1Z2dlc3RpbmcgYSBzdWItc2NoZW1hIGNyZWF0ZXMgcG90ZW50aWFsIGxpbWl0YXRp b25zIGFuZCBjb25mbGljdHMgdGhhdCBtYXkgYWRkIHRvIGNvbXBsZXhpdHkgbGF0ZXINCiBvbi4g VGhlIGN1cnJlbnQgZm9ybWF0IGFsbG93cyBhIHBhcnNlciB0byBkaXNjb3ZlciBhbmQgdW5sb2Fk IG9uZSBvciBtb3JlIEpTT04gcGF5bG9hZHMgd2hpY2ggY2FuIGVhY2ggaGF2ZSBpbmRlcGVuZGVu dCBzdHJ1Y3R1cmUuPGJyPg0KPGJyPg0KR2VuZXJhbCBleHRlbnNpb25zPGJyPg0KPGJyPg0KVGhl IHByb3Bvc2FsIGFsc28gcnVsZXMgb3V0IGdlbmVyYWwgcHVycG9zZSBleHRlbnNpb25zIG5vdCBy ZWxhdGVkIHRvIGFueSBzcGVjaWZpYyBldmVudC4gR2l2ZW4gdGhlIGVtZXJnZW5jZSBvZiBpdGVt cyBsaWtlIEdQUkQsIEkgd291bGQgbm90IHdhbnQgdG8gYmxvY2sgdGhlIGFiaWxpdHkgdG8gYWRk IG1ldGEtZGF0YSBvciBvdGhlciBnZW5lcmFsIHB1cnBvc2UgaXRlbXMuIFdlIGNhbiBhbHNvIGFu dGljaXBhdGUgc29tZSBkZWxpdmVyeSBzY2VuYXJpb3MNCiB3aGVyZSBhZGRpdGlvbmFsIGRhdGEg bWlnaHQgYmUgcmVxdWlyZWQuIEV2ZW4gdGhvdWdoIHRoZXJlIGlzIG5vIGN1cnJlbnQgcGxhbm5l ZCB1c2UsIEkgc2VlIG5vIGdvb2QgcmVhc29uIHRvIHJ1bGUgdGhpcyBvdXQuPGJyPg0KPGJyPg0K TXVsdGlwbGUgRXZlbnRzIEZyb20gRGlmZmVyZW50IEZhbWlsaWVzICh2cy4gTXVsdGlwbGUgRXZl bnRzIGZyb20gYSBzaW5nbGUgZmFtaWx5IGxpa2UgUklTQyk8YnI+DQo8YnI+DQpJbiBvdXIgUklT QyBzZXNzaW9uIHdlIGRpc2N1c3NlZCBleHByZXNzaW5nIG11bHRpcGxlIGRpc3RpbmN0IFJJU0Mg ZXZlbnRzIGluIG9uZSBTRVQuIFRoZSBkaXNjdXNzaW9uIHdhcyB0aGF0IG9ubHkgb25lIFJJU0Mg ZXZlbnQgYXQgYSB0aW1lLiBXZSBkaWQgbm90IGRpc2N1c3Mgb3RoZXIgZXZlbnQgcHJvZmlsZXMu IEkgZG9u4oCZdCBzZWUgYSByZWFzb24gdG8gcnVsZSBvdXQgbXVsdGktZXZlbnRzIGZyb20gZGlm ZmVyZW50IGZhbWlsaWVzIGF0IHRoZQ0KIFNFVCBsZXZlbC4gRWFjaCBwcm9maWxlIGlzIGV4cHJl c3Npbmcgc2xpZ2h0bHkgZGlmZmVyZW50IHRoaW5ncyBhYm91dCB0aGUgc2FtZSBldmVudC48YnI+ DQo8YnI+DQpJIGNhbiBmb3JzZWUgc29tZSBjYXNlcyB3aGVyZSBpdCBpcyBub3QgY2xlYXIgd2hp Y2ggaXMgdGhlIHByaW1hcnkgYW5kIHdoaWNoIGlzIHRoZSBleHRlbnNpb24uJm5ic3A7IFRoZXJl IG1heSBub3QgYmUgYSBjbGVhciB3aW5uZXIuPGJyPg0KPGJyPg0KQSBjb3VwbGUgb2YgZXhhbXBs ZXMgKHRoZXNlIGFyZSBuZWNlc3NhcmlseSByZWFs4oCmanVzdCBwb3NzaWJpbGl0aWVzKTo8YnI+ DQo8YnI+DQoqIEl0IGlzIHByb2JhYmx5IHVzZWZ1bCB0byBiZSBhYmxlIHRvIGV4cHJlc3Mgc2lt bGFyL292ZXJsYXBwaW5nIGV2ZW50cyBmcm9tIGRpZmZlcmVudCBTRVQgcHJvZmlsZXMgaW4gb25l IFNFVC4mbmJzcDsgRm9yIGV4YW1wbGUgYSBCYWNrY2hhbm5lbCBMb2dvdXQgJmFtcDsgYSBSSVND IHNlc3Npb24gY2FuY2VsIGV2ZW50Ljxicj4NCjxicj4NCiogU0NJTSBtYXkgd2FudCB0byByZXBy ZXNlbnQgYSBzaW5nbGUgdHJhbnNhY3Rpb24gYXMgY2F1c2luZyBtdWx0aXBsZSBzdGF0ZSBjaGFu Z2VzIGluIGFuIGV2ZW50IChlLmcuIGEgcGFzc3dvcmQgY2hhbmdlIGNhdXNlcyBtdWx0aXBsZSBl ZmZlY3RzKS4gSGF2aW5nIHRvIGNoYXNlIGRvd24gbXVsdGlwbGUgZXZlbnRzIGFuZCBjb3JyZWxh dGUgYnkg4oCcdHhu4oCdIHdvdWxkIGJlIGNoYWxsZW5naW5nIGluIGEgbXVsdGktdGhyZWFkZWQv bXVsdGktbm9kZQ0KIGRlbGl2ZXJ5IHN5c3RlbS4mbmJzcDsgJm5ic3A7VGhlIFNDSU0gbGlzdCBo YXMgbm90IGRpc2N1c3NlZCB0aGlzLCBidXQgSSB3b3VsZCBub3Qgd2FudCB0byBibG9jayB0aGlz IGNhcGFiaWxpdHkuJm5ic3A7IElPVyAtIEp1c3QgYmVjYXVzZSBSSVNDIGRvZXMgbm90IHdhbnQg dG8gZXhwcmVzcyBtdWx0aXBsZSBldmVudHMgZG9lcyBub3QgbWFrZSB0aGlzIHRydWUgZm9yIG90 aGVyIHByb2ZpbGVzLjxicj4NCjxicj4NCiogV2UgbWF5IHdpc2ggdG8gaW5kaWNhdGUgYSBTQ0lN IFBhc3N3b3JkIFJlc2V0IHdhcyBwZXJmb3JtZWQgYW5kIGEgTG9nb3V0L3Nlc3Npb24gY2FuY2Vs bGF0aW9uIGlzIGV4cHJlc3NlZCBhdCB0aGUgc2FtZSB0aW1lLiZuYnNwOyBUaGUgZXZlbnRzIGFy ZSByZWxhdGVkIGJ1dCBleHByZXNzIGRpZmZlcmVudCBkYXRhLjxicj4NCjxicj4NCkF2b2lkaW5n IENvbmZ1c2lvbiBGcm9tIFNpbWlsYXIgRXZlbnRzIE9yaWdpbmF0aW5nIGZyb20gdGhlIFNhbWUg VHJhbnNhY3Rpb248YnI+DQo8YnI+DQpJZiBldmVudHMgYXJlIHNlbnQgc2VwYXJhdGVseSwgdGhl biBtb3JlIHRyYWNraW5nIG9mIHN0YXRlIChlLmcuIGJ5IHR4bikgd291bGQgYmUgcmVxdWlyZWQg dG8gZW5zdXJlIHNpbWlsYXIgZXZlbnRzIGFyZSBub3QgbWlzdGFrZW4gb3IgaGFuZGxlZCBhcyBy ZXBlYXRzLiBXaGlsZSB0eG4gcHJvdmlkZXMgdXNlZnVsIGF1ZGl0IGFuYWx5c2lzIGNhcGFiaWxp dHksIEnigJltIG5vdCBzdXJlIGl0IGNhbiBiZSB1c2VkIGluIGxpdmUgb3IgbmVhci1yZWFsDQog dGltZSBzeXN0ZW1zIGdpdmVuIGRpc3RyaWJ1dGVkIG11bHRpLW5vZGUsIG11bHRpLXRocmVhZGlu ZyBhcmNoaXRlY3R1cmVzLjxicj4NCjxicj4NClByZXZpb3VzIERpc2N1c3Npb248YnI+DQo8YnI+ DQpJIG5vdGUgdGhhdCBJIG9yaWdpbmFsbHkgcmFpc2VkIGhhdmluZyBhbiBhdHRyaWJ1dGUgdG8g ZGVzaWduYXRlIHByaW1hcnkgZXZlbnQgYXR0cmlidXRlIHRvIGFsbGV2aWF0ZSB5b3VyIGNvbmNl cm4sIGJ1dCB0aGlzIHdhcyBub3QgYWNjZXB0ZWQuIFNlZTo8YnI+DQo8YnI+DQoqPHNwYW4gY2xh c3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgw MjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfaWQtMkRldmVudF9j dXJyZW50X21zZzAwNDA2Lmh0bWwmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQ cHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWli OUtBVGtSbFFHMWl3JmFtcDtzPVMzc01WaXFNdkVnbndHYkp3T1FOeWNyT3lyN1NlZnBxX01vRk9L Y0VlQ0UmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pZC1ldmVudC9jdXJyZW50L21z ZzAwNDA2Lmh0bWw8L3NwYW4+PC9hPjxicj4NCjxicj4NCio8c3BhbiBjbGFzcz0ibS00Mzc3Nzg3 NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAy NjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRfbXNnMDAx NDAuaHRtbCZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUly TVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNM TjRLWk5BJmFtcDttPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcm YW1wO3M9R3k5Z3lSb0lJdGEtY1NoVjdiTjE2MWF5NHlFNnI5RzFfQWFfTmVCbnlsZyZhbXA7ZT0i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkLWV2ZW50L2N1cnJlbnQvbXNnMDAxNDAuaHRtbDwv c3Bhbj48L2E+PGJyPg0KPGJyPg0KVGhlIGNvbnNlbnN1cywgYXQgbGVhc3QgYXMgSSBpbnRlcnBy ZXRlZCBpdCBpcyB1cCB0byB0aGUgcmVjZWl2ZXIgdG8gZmlndXJlIHRoaXMgb3V0IGJhc2VkIG9u IHRoZSBkZWZpbml0aW9ucyBpdCBoYXMgZm9yIGVhY2ggZXZlbnQgVVJJIGFuZCB0aGUgcHJvZmls ZXMgdGhleSByZXByZXNlbnQuIElPVyAtIFJJU0MgaXMgZnJlZSB0byBsaW1pdCB0aGF0IG9ubHkg b25lIFJJU0MgZXZlbnQgYmUgZXhwcmVzc2VkIGF0IGEgdGltZS48YnI+DQo8YnI+DQpQaGlsPGJy Pg0KPGJyPg0KT3JhY2xlIENvcnBvcmF0aW9uLCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNlcyBBcmNo aXRlY3Q8YnI+DQo8YnI+DQpAaW5kZXBlbmRlbnRpZDxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBl bmRlbnRpZC5jb20mYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2 N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkx YUxjTE40S1pOQSZhbXA7bT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFH MWl3JmFtcDtzPTlOUDVuYW1nNnJJVnp3dW45Yy0xcTB3aHN5WHdTdnRIQjBmMmRLa2ZDWDgmYW1w O2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+d3d3LmluZGVw ZW5kZW50aWQuY29tPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1 bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0 OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDs8YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fd3d3LmluZGVw ZW5kZW50aWQuY29tJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhC djdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJ MWFMY0xONEtaTkEmYW1wO209WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxR RzFpdyZhbXA7cz05TlA1bmFtZzZySVZ6d3VuOWMtMXEwd2hzeVh3U3Z0SEIwZjJkS2tmQ1g4JmFt cDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly93 d3cuaW5kZXBlbmRlbnRpZC5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8YnI+DQo8YSBocmVmPSJt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9 Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2 NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUu Y29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBPbiBPY3QgMjMsIDIw MTcsIGF0IDc6MDIgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlPGJyPg0KJm5ic3A7ICZu YnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yaWNoYW5uYUBhbWF6b24uY29tPC9zcGFu PjwvYT48c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1 MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5h QGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5y aWNoYW5uYUBhbWF6b24uY29tPC9zcGFuPjwvYT4mZ3Q7Jmd0Ow0KIHdyb3RlOjxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgVGhlIGN1cnJlbnQgZHJhZnQgb2YgdGhlIFNFVCBzcGVjIGFsbG93cyBm b3IgZXhwcmVzc2luZyBtdWx0aXBsZTxicj4NCiZuYnNwOyAmbmJzcDsgZXZlbnRzIHdpdGhpbiB0 aGUgc2FtZSB0b2tlbiwgd2hpY2ggaW50cm9kdWNlcyBhZGRpdGlvbmFsIGNvbXBsZXhpdHk8YnI+ DQombmJzcDsgJm5ic3A7IGFuZCByb29tIGZvciBhbWJpZ3VvdXMgc2VtYW50aWNzLiBXZeKAmXZl IGRpc2N1c3NlZCB0aGlzIGluIHRoZSBPSURGPGJyPg0KJm5ic3A7ICZuYnNwOyBSSVNDIHdvcmtp bmcgZ3JvdXAgYW5kIHRoZSBjdXJyZW50IGNvbnNlbnN1cyB0aGVyZSBpcyB0aGF0IFJJU0Mgd2ls bDxicj4NCiZuYnNwOyAmbmJzcDsgcmVxdWlyZSB0aGF0IFJJU0MgZXZlbnRzIG11c3QgYmUgdGhl IG9ubHkgZXZlbnQgaW4gdGhlIFNFVCwgaGF2aW5nPGJyPg0KJm5ic3A7ICZuYnNwOyBpZGVudGlm aWVkIHdheXMgdG8gY2xlYXJseSBhbmQgZWFzaWx5IHN1cHBvcnQgdGhlIGhhbmRmdWwgb2YgdXNl PGJyPg0KJm5ic3A7ICZuYnNwOyBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciB0b2tlbiB0 aGF0IHBlb3BsZSBoYXZlIHJhaXNlZC4gV2l0aDxicj4NCiZuYnNwOyAmbmJzcDsgdGhhdCBjb250 ZXh0IGluIG1pbmQsIEkgcHJvcG9zZSBzdHJpa2luZyB0aGUgZGVmaW5pdGlvbiBvZiB0aGU8YnI+ DQombmJzcDsgJm5ic3A7IOKAnGV2ZW50c+KAnSBjbGFpbSBmcm9tIHRoZSBTZWN1cml0eSBFdmVu dCBUb2tlbiBzcGVjLCBhbmQgcmVwbGFjaW5nIGl0PGJyPg0KJm5ic3A7ICZuYnNwOyB3aXRoIHRo ZSBmb2xsb3dpbmcgZGVmaW5pdGlvbiBmb3IgYW4g4oCcZXZlbnTigJ0gY2xhaW0gKHNpbmd1bGFy KTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IGV2ZW50PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyBBIEpTT04gb2JqZWN0IGNvbnRhaW5pbmcgYW4gJnF1b3Q7ZXZlbnRfdHlwZSZxdW90OyBtZW1i ZXIgd2hvc2UgdmFsdWUgaXMgYSBVUkk8YnI+DQombmJzcDsgJm5ic3A7IHJlcHJlc2VudGluZyBh IHR5cGUgb2YgZXZlbnQgZGVmaW5lZCBpbiBhIFByb2ZpbGluZyBTcGVjaWZpY2F0aW9uLjxicj4N CiZuYnNwOyAmbmJzcDsgVGhlIG9iamVjdCBNQVkgb3RoZXJ3aXNlIGJlIGVtcHR5LCBvciBNQVkg Y29udGFpbiBhZGRpdGlvbmFsIG1lbWJlcnM8YnI+DQombmJzcDsgJm5ic3A7IGFzIGRlc2NyaWJl ZCBieSB0aGUgUHJvZmlsaW5nIFNwZWNpZmljYXRpb24uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyBIZXJlIGlzIHRoZSBleGFtcGxlIFNFVCBmcm9tIHNlY3Rpb24gMi4zLCByZXdyaXR0ZW4gd2l0 aCB0aGlzIGNoYW5nZTxicj4NCiZuYnNwOyAmbmJzcDsgbWluZDo8YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2 NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj57PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsm bmJzcDsgJnF1b3Q7anRpJnF1b3Q7OiAmcXVvdDs0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNm YWFkOCZxdW90Oyw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmcXVvdDtp YXQmcXVvdDs6IDE0NTg0OTY0MDQsPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJz cDsmcXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNv bS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3Nj aW0uZXhhbXBsZS5jb208L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5 MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgw MzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0OzxhIGhyZWY9Imh0 dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5odHRwczovL3NjaW0uZXhhbXBsZS5jb20vPC9zcGFuPjwvYT4mZ3Q7JnF1b3Q7 LDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZxdW90O2F1ZCZxdW90Ozog Wzxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZxdW90 OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3 OTU5M2I3NzU0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0 cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQ8L3Nw YW4+PC9hPiZxdW90Oyw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vRmVlZHMvNWQ3 NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0 MWQ3Njc2ZWU3PC9zcGFuPjwvYT4mcXVvdDs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyZuYnNwOyBdLDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZxdW90O2V2 ZW50JnF1b3Q7OiB7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJnF1b3Q7ZXZlbnRfdHlwZSZxdW90OzogJnF1b3Q7dXJuOmlldGY6cGFyYW1zOnNjaW06 ZXZlbnQ6Y3JlYXRlJnF1b3Q7LDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90O3JlZiZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zY2lt LmV4YW1wbGUuY29tL1VzZXJzLzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NjaW0uZXhhbXBsZS5jb20v VXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOTwvc3Bhbj48L2E+JnF1b3Q7LDxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2F0dHJpYnV0 ZXMmcXVvdDs6IFsmcXVvdDtpZCZxdW90OywgJnF1b3Q7bmFtZSZxdW90OywgJnF1b3Q7dXNlck5h bWUmcXVvdDssICZxdW90O3Bhc3N3b3JkJnF1b3Q7LCAmcXVvdDtlbWFpbHMmcXVvdDtdPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgfTxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgfTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgRG9lcyBhbnlvbmUgaW4gdGhlIHdvcmtpbmcg Z3JvdXAgaGF2ZSB1c2UgY2FzZXMgZm9yIFNFVHMgdGhhdCBjYW5ub3Q8YnI+DQombmJzcDsgJm5i c3A7IGJlIG1ldCBieSB0aGlzIHByb3Bvc2VkIHRleHQ/IFdpdGhpbiBSSVNDLCB3ZSBpZGVudGlm aWVkIHRocmVlIHVzZTxicj4NCiZuYnNwOyAmbmJzcDsgY2FzZXMsIHdpdGggc29sdXRpb25zIG91 dGxpbmVkIGJlbG93Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgKio8YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICpFeHRlbnNpb25zKjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgRXZlbnQgZXh0 ZW5zaW9uIG1lY2hhbmlzbXMgY2FuIGJlIGRlZmluZWQgaW50ZXJuYWwgdG8gdGhlIGV2ZW50PGJy Pg0KJm5ic3A7ICZuYnNwOyBvYmplY3QuIEEgc2ltcGxlIGFwcHJvYWNoIHdvdWxkIGJlIHRvICZu YnNwO2RlZmluZSBhbiDigJxleHRlbnNpb25z4oCdIG1lbWJlcjxicj4NCiZuYnNwOyAmbmJzcDsg dGhhdCBpcyBhIGxpc3Qgb2YgZXZlbnQgb2JqZWN0cyAob3Igc2V0IHJlc2VtYmxpbmcgdGhlIOKA nGV2ZW50c+KAnTxicj4NCiZuYnNwOyAmbmJzcDsgY2xhaW0gYXMgZGVmaW5lZCBpbiB0aGUgY3Vy cmVudCBzcGVjKS4gVGhpcyBoYXMgdGhlIGFkdmFudGFnZSBvZjxicj4NCiZuYnNwOyAmbmJzcDsg bWFraW5nIGl0IGNsZWFyIGluIHRoZSBkYXRhIHN0cnVjdHVyZSB0aGF0IHRoZXJlIGlzIGEgc2lu Z2xlIHByaW1hcnk8YnI+DQombmJzcDsgJm5ic3A7IGV2ZW50LCB3aXRoIHplcm8gb3IgbW9yZSBl eHRlbnNpb25zLiBUaGVyZSBpcyBubyByb29tIGZvciBjb25mdXNpb248YnI+DQombmJzcDsgJm5i c3A7IG92ZXIgd2hpY2ggZXZlbnQgaXMgcHJpbWFyeSwgb3IgaWYgdGhlcmUgaXMgYSBwcmltYXJ5 IGV2ZW50IGF0IGFsbC48YnI+DQombmJzcDsgJm5ic3A7IEkgd291bGQgYmUgZmluZSB3aXRoIGFk ZGluZyBzb21ldGhpbmcgbGlrZSB0aGlzIHRvIG15IHByb3Bvc2VkIHRleHQsPGJyPg0KJm5ic3A7 ICZuYnNwOyBpZiB0aGVyZSBpcyBjb25zZW5zdXMgdGhhdCBpdCBpcyBicm9hZGx5IHVzZWZ1bC48 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICpBbGlhc2VzKjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgVGhpcyB1c2UgY2FzZSB3YXMgYnJvdWdodCB1cCBpbiB0aGUgY29udGV4dCBvZiBtaWdyYXRp bmcgY2xpZW50czxicj4NCiZuYnNwOyAmbmJzcDsgZnJvbSBkcmFmdCBldmVudCBuYW1lcyB0byBz dGFuZGFyZGl6ZWQgZXZlbnQgbmFtZXMuIEluIHRoaXMgY2FzZSw8YnI+DQombmJzcDsgJm5ic3A7 IHRoZSBldmVudCB0cmFuc21pdHRlciBjYW4gdHJhbnNtaXQgdHdvIHRva2VucyBmb3IgdGhlIGxv Z2ljYWwgZXZlbnQsPGJyPg0KJm5ic3A7ICZuYnNwOyBvbmUgdXNpbmcgdGhlIG9sZCBuYW1lIGFu ZCBhbm90aGVyIHVzaW5nIHRoZSBuZXcgbmFtZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICpS ZWxhdGVkIEV2ZW50cyo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoZSBTRVQgc3BlYyBkZWZp bmVzIHRoZSB0eG4gY2xhaW0gYXMgYSBtZWFucyBvZiBjb3JyZWxhdGluZzxicj4NCiZuYnNwOyAm bmJzcDsgaW5kZXBlbmRlbnQgdG9rZW5zIHRoYXQgcmVsYXRlIHRvIHRoZSBzYW1lIGxvZ2ljYWwg ZXZlbnQuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAtLTxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3 NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2 MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0K Jm5ic3A7ICZuYnNwOyBBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyBBbWF6b24g4oCTIElkZW50aXR5IFNlcnZpY2VzPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZuYnNwOyAmbmJzcDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOzxz cGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1 ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3Nw YW4+PC9hPjxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAy NjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86SWQtZXZl bnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5J ZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDs8c3BhbiBj bGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5 ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZh bXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdT YksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFt cDttPXM1YnlCZTVLQU5uR1Z1QWIxbUF1cEVHb0puOFhHNUpJVVV3V0dGU2liRWMmYW1wO3M9WDhv UlNxM0l6bEY3amlSQWVaaFhwUjNlVkkwSTU4WkZkNGVFWmZneW9JWSZhbXA7ZT0iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFj eEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empX d2xOS2U0Q19sTElHayZhbXA7bT1zNWJ5QmU1S0FObkdWdUFiMW1BdXBFR29KbjhYRzVKSVVVd1dH RlNpYkVjJmFtcDtzPVg4b1JTcTNJemxGN2ppUkFlWmhYcFIzZVZJMEk1OFpGZDRlRVpmZ3lvSVkm YW1wO2U9PC9zcGFuPjwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9 RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUm YW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1Z QkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtzPVdyTXVRUndM VjgwMmlNUTR3WUIxZjJyRlVHdTR6YmhjVzAwMWZLMDJFWHMmYW1wO2U9IiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZC1ldmVudDwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3 TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFt cDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209WUJD R2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZhbXA7cz1Xck11UVJ3TFY4 MDJpTVE0d1lCMWYyckZVR3U0emJoY1cwMDFmSzAyRVhzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxi cj4NCjxiciBjbGVhcj0iYWxsIj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LS08c3Bh biBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3 NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5TdWJzY3JpYmUgdG8gdGhlPHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAx Mzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mYW1w O2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9K bkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7 bT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtzPUxZTjcy R2dLVmhIc1Q2dEFxQmUtZU1vV012eV83ZGZGbjF1WjBISzZZdVEmYW1wO2U9IiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SEFSRFRXQVJFPC9zcGFuPjwvYT48c3Bh biBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3 NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPm1haWwNCiBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29y a2luZyBvbiE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxi cj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQm YW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFw SV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZh bXA7bT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtzPVdy TXVRUndMVjgwMmlNUTR3WUIxZjJyRlVHdTR6YmhjVzAwMWZLMDJFWHMmYW1wO2U9IiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f bGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZ UjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBw dVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5 S0FUa1JsUUcxaXcmYW1wO3M9V3JNdVFSd0xWODAyaU1RNHdZQjFmMnJGVUd1NHpiaGNXMDAxZksw MkVYcyZhbXA7ZT08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6d2hp dGUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5J ZC1ldmVudCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 cHVycGxlO2JhY2tncm91bmQ6d2hpdGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1h bl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlY UHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209VS1hNUhCTkQwSGFUWDRhbk5aZnpYN3BEc2ZLNWYw aDltWjlDWmtrR2llYyZhbXA7cz1ydmRydEk3cllOUkFucVpEbHRDd0JBWlZIS3AtTUoyMHVpMm5t NDZRU3owJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVy cGxlO2JhY2tncm91bmQ6d2hpdGUiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVu dCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVl YXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5B JmFtcDttPVUtYTVIQk5EMEhhVFg0YW5OWmZ6WDdwRHNmSzVmMGg5bVo5Q1pra0dpZWMmYW1wO3M9 cnZkcnRJN3JZTlJBbnFaRGx0Q3dCQVpWSEtwLU1KMjB1aTJubTQ2UVN6MCZhbXA7ZT08L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4tLTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlN1YnNjcmliZSB0 byB0aGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEg aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0Ff X2hhcmR0d2FyZS5jb21fJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBa aDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQ a0FJMWFMY0xONEtaTkEmYW1wO209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1 OF9xU0NfdyZhbXA7cz13dGdEM05wMHZ5aExkcEV3VWlxc2Y0SXRpd0EzT203R3JvYjcwTHgwcjNr JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkhBUkRU V0FSRTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPm1haWwNCiBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBv biE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVu dCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9y Zzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0y RGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJN VUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xO NEtaTkEmYW1wO209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZh bXA7cz1PZTBxZkxFWDgzdnRYTTdXbDJjWUJlLUdnMURWUGpoWGpWSmtmaFZSendjJmFtcDtlPSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5 WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxL Njd5Rl84dThfcVNDX3cmYW1wO3M9T2UwcWZMRVg4M3Z0WE03V2wyY1lCZS1HZzFEVlBqaFhqVkpr ZmhWUnp3YyZhbXA7ZT08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+LS08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5T dWJzY3JpYmUgdG8gdGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dh V0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERw Y3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPXNJR3o4Z3VyNHdOcVprdGNtYWd2NUVhMjFR RWlwNEhYcEVWS1JhMHFobG8mYW1wO3M9VjlneVRUWDlxdWpyQzJWbGl3TFB5MC1LdnhTOXBZS0pf LWt5RGFwd084ayZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5IQVJEVFdBUkU8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5tYWlsDQogbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFt IHdvcmtpbmcgb24hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+LS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj5TdWJzY3JpYmUgdG8gdGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZhbXA7ZD1Ed01HYVEmYW1wO2M9 Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpC VFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPXNJR3o4Z3VyNHdOcVpr dGNtYWd2NUVhMjFRRWlwNEhYcEVWS1JhMHFobG8mYW1wO3M9VjlneVRUWDlxdWpyQzJWbGl3TFB5 MC1LdnhTOXBZS0pfLWt5RGFwd084ayZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5IQVJEVFdBUkU8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5tYWlsDQogbGlzdCB0byBsZWFybiBhYm91dCBw cm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGJyPg0KPGJyIGNsZWFy PSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+LS08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+U3Vic2NyaWJlIHRvIHRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mYW1wO2Q9RHdNR2FRJmFt cDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1 RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1zSUd6OGd1cjR3 TnFaa3RjbWFndjVFYTIxUUVpcDRIWHBFVktSYTBxaGxvJmFtcDtzPVY5Z3lUVFg5cXVqckMyVmxp d0xQeTAtS3Z4UzlwWUtKXy1reURhcHdPOGsmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+SEFSRFRXQVJFPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+bWFpbA0KIGxpc3QgdG8gbGVhcm4gYWJv dXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7YmFja2dyb3VuZDp3aGl0ZSI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPklkLWV2ZW50IG1h aWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGll dGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj5J ZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lD QWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7 cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPXNJR3o4 Z3VyNHdOcVprdGNtYWd2NUVhMjFRRWlwNEhYcEVWS1JhMHFobG8mYW1wO3M9Z2ROcnM3VURBdHRw YWJqTTVuZE9Yd1dLbVp1S2FYRWJUNXd1OXJjT1JWMCZhbXA7ZT0iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6cHVycGxlO2JhY2tncm91bmQ6d2hpdGUiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f aWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3 cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFh TGNMTjRLWk5BJmFtcDttPXNJR3o4Z3VyNHdOcVprdGNtYWd2NUVhMjFRRWlwNEhYcEVWS1JhMHFo bG8mYW1wO3M9Z2ROcnM3VURBdHRwYWJqTTVuZE9Yd1dLbVp1S2FYRWJUNXd1OXJjT1JWMCZhbXA7 ZT08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB0504111616783EB6E3E055E2F55F0CY4PR21MB0504namp_-- From nobody Wed Nov 1 13:20:04 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C22513F7FA for ; Wed, 1 Nov 2017 13:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.818 X-Spam-Level: X-Spam-Status: No, score=-11.818 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 T8Y-VEIooQNh for ; Wed, 1 Nov 2017 13:19:57 -0700 (PDT) Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C88F13F59E for ; Wed, 1 Nov 2017 13:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1509567596; x=1541103596; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=89zbrOhMG/6XE4nUfwvp1nLDwN80yd2F11b74NV8wgw=; b=gOZo85uFyTi0k2CCch/5G54W047DoeafFh/FqlY/TsNqbqU+D+tsCJqC opLih5b4scvQI260UH5yEkTNwHYTfYdLOFxm3Xj03OSNX7lbFaF7uUKVy iJQi//Sa7vdMcCRqTaR6mADqOvFJc4TdUB8jxU+aMSaxEthyvW+n/MQGJ 8=; X-IronPort-AV: E=Sophos;i="5.44,330,1505779200"; d="scan'208,217";a="316917996" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2a-538b0bfb.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2017 20:19:44 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-2a-538b0bfb.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id vA1KJh9Y061662 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2017 20:19:43 GMT Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 1 Nov 2017 20:19:43 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 1 Nov 2017 20:19:42 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Wed, 1 Nov 2017 20:19:42 +0000 From: "Richard Backman, Annabelle" To: Phil Hunt CC: Mike Jones , Dick Hardt , Yaron Sheffer , "ID Events Mailing List" Thread-Topic: [Id-event] Use cases for multiple events per SET? Thread-Index: AQHTTGwev6cV0D/tE06azbqzz7my9aLyXLkAgAEBjXCAB9BnAIAAT1IAgAAUagCAAQQ9AIAANauAgAAlNACAAAV2gIABcZJQgACUvYCAAADCcIAAA1kAgAASxcCAALLVgIAAG18AgAARHoCAAAeDAIAACakA Date: Wed, 1 Nov 2017 20:19:42 +0000 Message-ID: References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.99] Content-Type: multipart/alternative; boundary="_000_EFF86A7A874E4D6787A6C95AC93B3FF6amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 20:20:02 -0000 --_000_EFF86A7A874E4D6787A6C95AC93B3FF6amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGhpbCwNCg0KVGhlIG5vcm1hdGl2ZSB0ZXh0IHlvdSBxdW90ZWQgYWRkcmVzc2VzIG9ubHkgb25l IGV4YW1wbGUgb2Ygb25lIG9mIHRoZSBpc3N1ZXMgSeKAmXZlIHJhaXNlZC4gRXZlbiB0aGVuLCBJ IGV4cGVjdCB0aGlzIHRleHQgd2lsbCBiZSBpZ25vcmVkIOKAkyBpbnRlbnRpb25hbGx5IG9yIHVu aW50ZW50aW9uYWxseSDigJMgYmVjYXVzZSB0aGUgc3RydWN0dXJlIG9mIGEgU0VUIGFzIGl0IGlz IGRlZmluZWQgaW4gdGhlIGRyYWZ0IGFsbG93IGZvciB0aGlzIHJlcXVpcmVtZW50IHRvIGJlIHZp b2xhdGVkLCBhbmQgdGhlIGltcGxpZWQgc2VtYW50aWNzIGNvbnRyYWRpY3QgaXQuIE5vIG9uZSB3 aWxsIGxvb2sgYXQgYSBTRVQsIHNlZSBhIHBsdXJhbCDigJxldmVudHPigJ0gbWVtYmVyLCBhbmQg dW5kZXJzdGFuZCB0aGF0IGl0IG1lYW5zIOKAnG11bHRpcGxlIGV2ZW50IHN0YXRlbWVudHPigJ0g YW5kIG5vdCDigJxtdWx0aXBsZSBldmVudHMu4oCdDQoNCj4gVGhlcmUgaXMgbm8gd2F5IHRvIGFz c3VyZSB0aGF0IGEgc2luZ2xlIHJlY2VpdmVyIGdldHMgYWxsIG9mIHRoZSBTRVRzIGl0IG5lZWRz IGluIGEgbXVsdGktdGhyZWFkZWQsIG11bHRpLW5vZGUgZW52aXJvbm1lbnQgYXQgc2NhbGUuDQoN ClRoaXMgaXMgd2hhdCB0aGUgYWNrbm93bGVkZ2VtZW50IG1lY2hhbmlzbXMgaW4gdGhlIGRlbGl2 ZXJ5IHNwZWMgYXJlIGZvci4gVHJhbnNtaXR0ZXJzIGNhbiBjb3JyZWxhdGUgYWNrbm93bGVkZ2Vt ZW50cyBvZiBkaWZmZXJlbnQgU0VUcywgYXQgc2NhbGUgaWYgbmVjZXNzYXJ5LiBJbiBhbGwgdGhl IFNFVCB1c2UgY2FzZXMgd2XigJl2ZSBkaXNjdXNzZWQsIHRoZSB2b2x1bWUgb2YgU0VUcyBvbiBh IHN0cmVhbSBvbmx5IHNjYWxlcyB3aXRoIHRoZSByZWNlaXZlcuKAmXMgYnVzaW5lc3MsIHNvIG9u bHkgcmVjZWl2ZXJzIHdobyBhcmUgYWxyZWFkeSBvcGVyYXRpbmcgYXQgc2NhbGUgbmVlZCB0byBi ZSBjYXBhYmxlIG9mIGhhbmRsaW5nIFNFVHMgYXQgc2NhbGUuIElmIHlvdSBkaXNhZ3JlZSwgcGxl YXNlIHByb3ZpZGUgYSBjb3VudGVyZXhhbXBsZS4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJh Y2ttYW4NCklkZW50aXR5IFNlcnZpY2VzDQoNCg0KRnJvbTogUGhpbCBIdW50IDxwaGlsLmh1bnRA b3JhY2xlLmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgTm92ZW1iZXIgMSwgMjAxNyBhdCAxMjo0NSBQ TQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb20+ DQpDYzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiwgRGljayBIYXJk dCA8ZGljay5oYXJkdEBnbWFpbC5jb20+LCBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFp bC5jb20+LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQ/ DQoNCllvdSBjYW7igJl0IHJlYWxseSBoYXZlIG11bHRpcGxlIGV2ZW50cyAoYXQgbGVhc3Qgb2Yg dGhlIHNhbWUgdHlwZSkuICBUaGUgY3VycmVudCBzcGVjIGNhbiBvbmx5IGhhdmUgb25lIGluc3Rh bmNlIG9mIGEgVVJJIChhZmFpaykuDQoNCk5vdGUgdGhhdCB0aGUgc3BlYyBub3JtYXRpdmVseSBk b2VzIG5vdCBzdXBwb3J0IG11bHRpcGxlIGV2ZW50IFNFVFMuICBJdCBjdXJyZW50bHkgc3RhdGVz Og0KDQpldmVudHMNCg0KICAgICAgVGhlIHNlbWFudGljcyBvZiB0aGlzIGNsYWltIGlzIHRvIGRl ZmluZSBhIHNldCBvZiBldmVudCBzdGF0ZW1lbnRzDQoNCiAgICAgIHRoYXQgZWFjaCBNQVkgYWRk IGFkZGl0aW9uYWwgY2xhaW1zIHRvIGZ1bGx5IGRlc2NyaWJlIGEgc2luZ2xlDQoNCiAgICAgIGxv Z2ljYWwgZXZlbnQgdGhhdCBoYXMgb2NjdXJyZWQgKGUuZy4gYSBzdGF0ZSBjaGFuZ2UgdG8gYQ0K DQogICAgICBzdWJqZWN0KS4gIE11bHRpcGxlIGV2ZW50IHN0YXRlbWVudHMgb2YgdGhlIHNhbWUg dHlwZSBTSEFMTCBOT1QgYmUNCg0KICAgICAgYWNjZXB0ZWQuICBUaGUgImV2ZW50cyIgY2xhaW0g U0hPVUxEIE5PVCBiZSB1c2VkIHRvIGV4cHJlc3MNCg0KICAgICAgbXVsdGlwbGUgbG9naWNhbCBl dmVudHMuDQoNClRoZSBzcGVjIGhhcyAqYWx3YXlzKiBzdXBwb3J0ZWQgcmVxdWlyZW1lbnRzIChh cyBzdGF0ZWQgaW4gdGhlIHNwZWMpIGZvciBtdWx0aXBsZSBzZXBhcmF0ZSBwcm9maWxlIHN0YXRl bWVudHMgKGZyb20gb25lIG9yIG1vcmUgcHJvZmlsZSBmYW1pbGl0aWVzKSBuZWVkaW5nIHRvIGJl IHNlbnQgYXMgYSBzaW5nbGUgbWVzc2FnZS4gIEl0IHdvdWxkIGJlIElOU0VDVVJFIHRvIGZvcmNl IG11bHRpcGxlIFNFVHMgYmVjYXVzZSB0aGUgY3VycmVudCBkZWxpdmVyeSBtZWNoYW5pc20gb25s eSBhbGxvd3Mgb25lIFNFVCB0byBiZSBkZWxpdmVyZWQgYXQgYSB0aW1lLiBUaGVyZSBpcyBubyB3 YXkgdG8gYXNzdXJlIHRoYXQgYSBzaW5nbGUgcmVjZWl2ZXIgZ2V0cyBhbGwgb2YgdGhlIFNFVHMg aXQgbmVlZHMgaW4gYSBtdWx0aS10aHJlYWRlZCwgbXVsdGktbm9kZSBlbnZpcm9ubWVudCBhdCBz Y2FsZS4gIEFzc2VtYmxpbmcgbXVsdGlwbGUgU0VUcyB0byB0cmFjayDigJx0eG7igJ0gaW4gYSBj b21tb24gc3RhdGUgZGF0YWJhc2UgaXMgTk9UIHNpbXBsZSBub3IgY29zdCBlZmZlY3RpdmUuDQoN CklmIHdlIGFjY29tbW9kYXRlIHRoaXMgaW4gdGhlIHByb3Bvc2VkIGZvcm0sIHdlIGVuZCB1cCB3 aXRoIGEgY29tcGxleCwgZGVlcGx5IG5lc3RlZCBKU09OIHN0cnVjdHVyZSB3aXRoIHRoZSBwb3Nz aWJpbGl0eSBvZiBuYW1lc3BhY2UgY29uZmxpY3RzLg0KDQpJTU8gVGhlIHByb3Bvc2FsIGRvZXMg bm90IHNpbXBsaWZ5LCBpdCBjb21wbGljYXRpbmcgYW5kIGxpbWl0aW5nLg0KDQpUaGUgY3VycmVu dCBzcGVjIGhhcyB2ZXJ5IGNsZWFuIEpTT04gYW5kIGF2b2lkcyBuYW1lc3BhY2UgY29uZmxpY3Rz IGJldHdlZW4gcHJvZmlsZXMuIEkgdGhpbmsgd2Ugc2hvdWxkIHN0YXkgb24gdHJhY2sgd2l0aCB0 aGUgY3VycmVudCBkcmFmdCBhbmQgb2JzZXJ2ZSB0aGUgbm9ybWF0aXZlIHRleHQgaWYgbm90IG1h a2UgaXQgc3Ryb25nZXIgaW4gcmVnYXJkcyB0byBtdWx0aS1ldmVudHMgKHVuZGVyc3Rvb2QgdGhh dCBNaWtlIG1heSBkaXNhZ3JlZSkuDQoNClBoaWwNCg0KT3JhY2xlIENvcnBvcmF0aW9uLCBJZGVu dGl0eSBDbG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3QNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBl bmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4NCnBoaWwuaHVudEBvcmFj bGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KT24gTm92IDEsIDIwMTcsIGF0 IDEyOjE4IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNv bTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KDQpVbmxlc3MgdGhlIHByb2Zp bGUgZ3VhcmFudGVlcyB0aGF0IHN1Y2ggcmVsYXRlZCBldmVudHMgd2lsbCBhbHdheXMgYmUgaW5j bHVkZWQgaW4gdGhlIHNhbWUgU0VULCB0aGVuIHRoZSByZWNlaXZlciBoYXMgdG8gY29ycmVsYXRl IGFjcm9zcyBTRVRzIGFueXdheSwgYW5kIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUIGlzIGp1c3Qg Z2l2aW5nIHRoZSByZWNlaXZlciBhbm90aGVyIHNjZW5hcmlvIHRoYXQgdGhleSBoYXZlIHRvIHN1 cHBvcnQuDQoNCknigJl2ZSBhbHJlYWR5IHByb3ZpZGVkIHNldmVyYWwgb3RoZXIgcmVhc29ucyB3 aHkgd2Ugc2hvdWxkIG5vdCBzdXBwb3J0IG11bHRpcGxlIHRva2VucyBwZXIgU0VUIHRoYXQgbm8g b25lIGhhcyBhZGRyZXNzZWQuIEhlcmUgdGhleSBhcmUgYWdhaW46DQoNCiAgMS4gIE11bHRpcGxl IGV2ZW50IHN1cHBvcnQgcmVzdWx0cyBpbiBhIG1vcmUgY29tcGxleCBzdHJ1Y3R1cmUgZm9yIHRo ZSBzaW5nbGUgZXZlbnQgdXNlIGNhc2UsIHdoaWNoIEkgdGhpbmsgd2UgYWxsIGFncmVlIGlzIHRo ZSBtYWpvcml0eSB1c2UgY2FzZS4NCiAgMi4gIE11bHRpcGxlLWV2ZW50IFNFVHMgaGF2ZSBhbWJp Z3VvdXMgc2VtYW50aWNzLiBUaGUgcHJlc2VuY2Ugb2YgdHdvIGV2ZW50cyBBIGFuZCBCIGluIHRo ZSBzYW1lIFNFVCBjb3VsZCBtZWFuIGFueSBvZjoNCg0KICAgICAqICAgQSBhbmQgQiBhcmUgcmVs YXRlZCB0byB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50IChpLmUuIHRoZSBzYW1lIHRoaW5nIGFzIGlm IHRoZXkgd2VyZSBmcm9tIGRpZmZlcmVudCBTRVRzIHRoYXQgaGF2ZSBhIGNvbW1vbiB0eG4pLg0K ICAgICAqICAgQSBpcyBhbiBleHRlbnNpb24gb2YgQi4NCiAgICAgKiAgIEIgaXMgYW4gZXh0ZW5z aW9uIG9mIEEuDQogICAgICogICBBIGlzIGFuIGFsaWFzIGZvciBCLCBvciB2aWNlLXZlcnNhLg0K ICAgICAqICAgQSBhbmQgQiBhcmUgbm90IGFjdHVhbGx5IHJlbGF0ZWQgdG8gb25lIGFub3RoZXIg aW4gYW55IHdheSwgYW5kIHRoZSB0cmFuc21pdHRlciBidW5kbGVkIHRoZW0gdG9nZXRoZXIgYmVj YXVzZSB0aGV5IHdlcmUgZ29pbmcgdG8gdGhlIHNhbWUgcmVjZWl2ZXIuDQoNCiAgMS4gIFRvcC1s ZXZlbCBjbGFpbSBzZW1hbnRpY3MgYmVjb21lIGhhcmRlciB0byBkZWZpbmUsIGFzIGRpZmZlcmVu dCBwcm9maWxlcyBtYXkgd2FudCB0byB1c2UgdGhlIHNhbWUgY2xhaW1zIGluIGRpZmZlcmVudCB3 YXlzLg0KICAyLiAgRXZlbnQgYXV0aGVudGljaXR5IGNhbm5vdCBiZSB2ZXJpZmllZCB3aXRob3V0 IGhhdmluZyB0aGUgZW50aXJlIFNFVC4gVGhpcyBmb3JjZXMgcmVjZWl2ZXJzIHRvIGV4cG9zZSBk b3duc3RyZWFtIHN5c3RlbXMgdG8gbW9yZSBpbmZvcm1hdGlvbiBuZWNlc3NhcnksIGlmIHRob3Nl IHN5c3RlbXMgbmVlZCB0byBiZSBhYmxlIHRvIHZlcmlmeSBhdXRoZW50aWNpdHkuDQoNCi0tDQpB bm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBbWF6b24g4oCTIElkZW50aXR5IFNlcnZpY2VzDQoN Cg0KRnJvbTogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBOb3ZlbWJlciAx LCAyMDE3IGF0IDExOjIxIEFNDQpUbzogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208 bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkNjOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYu aWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+LCAiUmljaGFyZCBC YWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBh bWF6b24uY29tPj4sIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1h aWx0bzppZC1ldmVudEBpZXRmLm9yZz4+LCAiUGhpbCBIdW50IChJRE0pIiA8cGhpbC5odW50QG9y YWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NClN1YmplY3Q6IFJFOiBbSWQt ZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQ/DQoNCkkgY29tcGxl dGVseSBhZ3JlZSBvbiBtb3ZpbmcgY29tcGxleGl0eSB0byB0aGUgaXNzdWVyIG92ZXIgdGhlIHJl Y2lwaWVudC4gIEluIG15IHZpZXcsIGl04oCZcyBtb3JlIGNvbXBsZXggZm9yIHJlY2lwaWVudHMg dG8gaGF2ZSB0byBjb3JyZWxhdGUgYW5kIHByb2Nlc3MgYSBzZXF1ZW5jZSBvZiBtdWx0aXBsZSBT RVRzIHByb3ZpZGluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50LCBh bmQgdmFsaWRhdGUgTiBzaWduYXR1cmVzLCB0aGFuIHRvIHJlY2VpdmUgb25lIFNFVCB3aXRoIGFs bCB0aGUgYXNwZWN0cyBvZiB0aGUgbG9naWNhbCBldmVudCBhcyDigJxldmVudHPigJ0gZmllbGRz LCB3aXRoIG5vIGNvcnJlbGF0aW9uIG92ZXIgdGltZSB0aGVuIHJlcXVpcmVkLg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K DQpGcm9tOiBEaWNrIEhhcmR0IFttYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb21dDQpTZW50OiBX ZWRuZXNkYXksIE5vdmVtYmVyIDEsIDIwMTcgOTozOSBBTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t Pj4NCkNjOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9u Zi5pZXRmQGdtYWlsLmNvbT4+OyBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFA YW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+OyBJRCBFdmVudHMgTWFpbGlu ZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+PjsgUGhp bCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBl dmVudHMgcGVyIFNFVD8NCg0KWW91ciBjb21tZW50cyBoaWdobGlnaHQgYSBjb3VwbGUgb2YgcG9p bnRzOg0KDQoxKSBUaGUgZXhhbXBsZSBpcyBob3cgdG8gaGF2ZSBhIHByZWRlZmluZWQgZXh0ZW5z aW9uIHBvaW50IGZvciBleHRlbnNpb25zIG9mIGEgc3BlY2lmaWMgZXZlbnQsIGl0IGlzIG5vdCBo b3cgdG8gYWRkIGFub3RoZXIgZXZlbnQuIE15c2VsZiwgSSB0aGluayB0aGlzIGlzIG92ZXJseSBj b21wbGljYXRlZC4gRXZlbnRzIHNob3VsZCBiZSBjb21wYXJhdGl2ZWx5IHN0YXRpYywgYW5kIGFz IHdpdGggbWFueSBvdGhlciBKU09OIGZvcm1hdHMsIHRoZSByZWNlaXZlciBzaG91bGQgaWdub3Jl IHByb3BlcnRpZXMgaXQgZG9lcyBub3QgdW5kZXJzdGFuZCwgd2hpY2ggbGV0J3MgbmV3IHByb3Bl cnRpZXMgYmUgaW50cm9kdWNlZCBhcyBleHRlbnNpb25zLiBUaGVyZSBzaG91bGQgbm90IGJlIGFu eSBjb25mbGljdCBhcyBleHRlbnNpb25zIHNob3VsZCBvbmx5IGJlIGRvbmUgYnkgdGhlIHByb2Zp bGUgdGhhdCBjcmVhdGVkIHRoZSBldmVudCBmb3JtYXQgdG8gc3RhcnQgb2ZmIHdpdGguDQoNCjIp IEhhdmluZyBhbiBsdmFsdWUgYmUgYSBVUkkgaXMgbXVjaCBoYXJkZXIgdG8gY29kZSBhZ2FpbnN0 LiBJJ20gbm90IHN1cmUgd2h5IE1hcml1cyBoYWQgdGhhdCBpbiBoaXMgZXhhbXBsZS4gUGVyIHRo ZSBldmVudCwgdGhlIHR5cGUgb2YgdGhlIGV2ZW50IGlzIHdlbGwgZGVmaW5lZCB3aXRoDQoNCiJl dmVudF90eXBlIjogImh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0 RXh0IiwNCg0KMykgVGhpcyB0aHJlYWQgaXMgYWJvdXQgcmVhc29ucyBmb3IgbXVsdGlwbGUgZXZl bnRzIHRvIGJlIGNvbnRhaW5lZCBpbiBvbmUgc2V0LiBZb3VyIG1lbnRpb24gb2YgYW4gaXNzdWVy IG5vdCB3YW50aW5nIHRvIHNpZ24gc2VwYXJhdGUgZXZlbnRzIGFzIGEgcmVhc29uIHRvIGFsbG93 IG11bHRpcGxlIGV2ZW50cy4gSSB0aGluayB3ZSBoYXZlIGRlY2lkZWQgdGhhdCBnaXZlbiBhIHBy ZWZlcmVuY2UsIHdlIHdpbGwgcHVzaCBlZmZvcnQgdG8gdGhlIHRyYW5zbWl0dGVyIG92ZXIgdGhl IHJlY2VpdmVyIGFzIGluIG1hbnkgdXNlIGNhc2VzIHRoZXJlIGFyZSBtYW55IG1vcmUgcmVjZWl2 ZXJzLiBHaXZlbiB0aGF0LCBpdCBpcyBtb3JlIGNvbXBsZXggZm9yIGEgcmVjZWl2ZXIgdG8gaGF2 ZSBkaWZmZXJlbnQgd2F5cyBvZiBtYW5hZ2luZyB0aGUgcmVjZWlwdCBvZiBtdWx0aXBsZSBldmVu dHMgYXMgbm90IGFsbCBpc3N1ZXJzIHdpbGwgYnVuZGxlIHRoZSBldmVudHMsIHNvIGl0IGlzIHNp bXBsZXIgdG8gaGF2ZSBvbmx5IG9uZSBldmVudCBwZXIgU0VULiBJbmNsdWRpbmcgdGhlIHNlcGFy YXRlIGV2ZW50cyB3aXRoIGEgVVJJIGFzIGFuIGx2YWx1ZSBpcyBjaGFsbGVuZ2luZyB0byBpbXBs ZW1lbnQsIHNwZWFraW5nIGZyb20gZXhwZXJpZW5jZS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Ck9uIFR1ZSwgT2N0IDMxLCAyMDE3IGF0IDExOjA1IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdy b3RlOg0KTWFyaXVz4oCZIHByb3Bvc2VkIHN5bnRheCwgcGFzdGVkIGluIGJlbG93LCBoYXMgZXhh Y3RseSB0aGlzIGNoYXJhY3RlcmlzdGljLiAgVGhlIHdheSBJIHNlZSBpdCwgaGlzIHByb3Bvc2Fs IGVzc2VudGlhbGx5IGhhcyBhIHByaW1hcnkgcGFzc3dvcmRSZXNldCBldmVudCBhbmQgYSBzZWNv bmRhcnkgcGFzc3dvcmRSZXNldEV4dCBkYXRhIHN0cnVjdHVyZSwgd2hpY2ggY291bGQgaGF2ZSBi ZWVuIHNpbXBseSBhbm90aGVyIGV2ZW50IHZhbHVlIGluIHRoZSBjdXJyZW50IGRyYWZ0Lg0KDQpU aGlzIGJyZWFraW5nIGNoYW5nZSBtYWtlcyB0aGUgZGF0YSBzdHJ1Y3R1cmVzIG1vcmUgY29tcGxp Y2F0ZWQgLSBub3QgbGVzcy4gIEFuZCBpdCBtYWtlcyB0aGluZ3MgdGhhdCB1c2VkIHRvIGJlIHBv c3NpYmxlIGltcG9zc2libGUsIHJlZHVjaW5nIGZsZXhpYmlsaXR5IHRvIHRob3NlIHdobyB3b3Vs ZCB1c2UgdGhlIHNwZWMuDQoNClRoZXNlIHNlZW0gbGlrZSBiYWQgdHJhZGVvZmZzIHRvIG1lLg0K DQp7DQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KICAiaWF0 IjogMTQ1ODQ5NjAyNSwNCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5jb208aHR0cHM6 Ly9zY2ltLmV4YW1wbGUuY29tLz4iLA0KICAiYXVkIjogWw0KICAgICJodHRwczovL2podWIuZXhh bXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsDQogICAgImh0dHBzOi8v amh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Ig0KICAgXSwN CiAgICJldmVudF90eXBlIjogImh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29y ZFJlc2V0RXh0IiwNCiAgICJldmVudCI6IHsNCiAgICAgICAgICJpZCI6IjQ0ZjYxNDJkZjk2YmQ2 YWI2MWU3NTIxZDkiLA0KICAgICAgICAgImV4dGVuc2lvbnMiOiB7DQogICAgICAgICAgICJodHRw czovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dOKAnTogew0KICAgICAg ICAgICAgICJyZXNldEF0dGVtcHRzIjo1LA0KICAgICAgICAgICB9DQogICAgICAgICB9DQogICAg ICAgfQ0KfQ0KDQpJbiBwYXJ0aWN1bGFyLCBpdCBtYWtlcyBpdCBpbXBvc3NpYmxlIHRvIHNpZ24g bXVsdGlwbGUgcmVsYXRlZCBldmVudHMgc2hhcmluZyBhIGNvbW1vbiBjbGFpbXMgc2NoZW1hIHdp dGggYSBzaW5nbGUgc2lnbmF0dXJlIGJ5IHRoZSBpc3N1ZXIuICBJdCBmb3JjZXMgdGhlIGlzc3Vl ciB0byBkbyB0aGUgZXh0cmEgd29yayBvZiBzaWduaW5nIGVhY2ggb2YgdGhlIHJlbGF0ZWQgZXZl bnRzIChvciBmYWNldHMgb2YgdGhlIHNhbWUgbG9naWNhbCBldmVudCkgaW5kaXZpZHVhbGx5IGFu ZCBmb3JjZXMgdGhlIHJlY2lwaWVudHMgdG8gZG8gdGhlIGV4dHJhIHdvcmsgb2YgY2hlY2tpbmcg YWxsIHRob3NlIHVubmVjZXNzYXJ5IHNpZ25hdHVyZXMuDQoNCk5vdCBldmVyeSBwcm9maWxlIHdp bGwgZXZlciBoYXZlIG11bHRpcGxlIGtleXMgaW4gdGhlIOKAnGV2ZW50c+KAnSBzZXQgYnV0IHRo ZXJl4oCZcyBhYnNvbHV0ZWx5IG5vIHJlYXNvbiB0byBwcmVjbHVkZSBpdC4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K RnJvbTogSWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpp ZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIERpY2sgSGFyZHQNClNlbnQ6 IFR1ZXNkYXksIE9jdG9iZXIgMzEsIDIwMTcgOTo1MiBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t Pj4NCkNjOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9u Zi5pZXRmQGdtYWlsLmNvbT4+OyBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFA YW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+OyBJRCBFdmVudHMgTWFpbGlu ZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+PjsgUGhp bCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20+Pg0KDQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxl IGV2ZW50cyBwZXIgU0VUPw0KDQpQbGVhc2UgZGlyZWN0IG1lIHRvIGEgcHJvcG9zYWwgdGhhdCBo YXMgYSAicHJpbWFyeSIgYW5kICJzZWNvbmRhcnkiIGV2ZW50cy4gSSBhZ3JlZSB0aGF0IGlzIHVu ZGVzaXJhYmxlLiBJIHdvdWxkIGFsc28gZW5jb3VyYWdlIHRvIGVuZ2FnZSBpbiB0aGUgZGlzY3Vz c2lvbnMgc28gdGhhdCB3ZSBjYW4gZHJpdmUgY2xhcml0eSBhbmQgc2ltcGxpY2l0eS4NCg0KSSB0 aGluayB0aGUgcHJvcG9zYWwgaXMgdGhhdCB0aGVyZSBpcyBvbmUgZXZlbnQgcGVyIFNFVC4NCg0K SSB0aGluayBoYXZpbmcgbW9yZSB0aGFuIG9uZSBldmVudCBwZXIgU0VUIGFkZHMgY29tcGxleGl0 eSBhcyBhIHJlY2VpdmVyIG11c3QgZGVhbCB3aXRoIHJlY2VpdmluZyBjb3JyZWxhdGVkIGV2ZW50 cyBpbiBvbmUgU0VUIGFzIHdlbGwgYXMgY29ycmVsYXRlZCBldmVudHMgaW4gdGhlIHNhbWUgU0VU Lg0KDQovRGljaw0KDQpPbiBUdWUsIE9jdCAzMSwgMjAxNyBhdCA5OjQyIFBNLCBNaWtlIEpvbmVz IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbT4+IHdyb3RlOg0KSSBoZWFyIHlvdSBvbiB0aGUgZmFjdCB0aGF0IGRpZmZlcmVudCBw ZW9wbGUgaGF2ZSBqb2luZWQgdGhlIGVmZm9ydCBhdCBkaWZmZXJlbnQgdGltZXMuICBUaGF04oCZ cyBhIG5vcm1hbCBwcm9jZXNzIGFzIGFuIGVmZm9ydCBidWlsZHMgbW9tZW50dW0uICBJIGdldCB0 aGF0IG5vdCBldmVyeW9uZSB3YXMgdGhlcmUgd2hlbiBwcmV2aW91cyBjb25zZW5zdXMgY2FsbHMg d2VyZSB0YWtlbi4NCg0KSSBzaG91bGQgbm90ZSB0aGF0IEkgaGF2ZSBzcGVjaWZpYyB0ZWNobmlj YWwgb2JqZWN0aW9ucyB0byB0aGUgc3BlY2lmaWMgcHJvcG9zZWQgY2hhbmdlcyBiZWluZyBkaXNj dXNzZWQgYXMgd2VsbC4gIEN1cnJlbnRseSBhbGwgZXZlbnRzIGluIHRoZSBzZXQgaGF2ZSB0aGUg c2FtZSBzeW50YXguICBUaGUgcHJvcG9zYWxzLCBhcyBJIHVuZGVyc3RhbmQgdGhlbSwgcmV2ZXJ0 IHVzIHRvIGEgc3RhdGUgd2hlcmUgdGhlcmXigJlzIGEg4oCccHJpbWFyeeKAnSBhbmQg4oCcc2Vj b25kYXJ54oCdIGV2ZW50cywgd2l0aCBkaWZmZXJlbnQgc3ludGF4IGZvciB0aGUgdHdvIGNsYXNz ZXMuICBUaGF04oCZcyBuZWVkbGVzc2x5IG1vcmUgY29tcGxpY2F0ZWQsIGFkZGluZyBubyBhY3R1 YWwgdmFsdWUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IERpY2sgSGFyZHQgW21haWx0bzpk aWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+XQ0KU2VudDog VHVlc2RheSwgT2N0b2JlciAzMSwgMjAxNyA5OjM3IFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+ Pg0KQ2M6IFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tPj47IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxt YWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxl IDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj47IElEIEV2 ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRm Lm9yZz4+DQoNClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUg ZXZlbnRzIHBlciBTRVQ/DQoNCk1pa2UNCg0KQXMgeW91IHdlbGwga25vdywgbWFueSBwZW9wbGUg aW4gYSBXRyBkb24ndCBsb29rIGNsb3NlbHkgYXQgYSBzcGVjaWZpY2F0aW9uIHVudGlsIGxhc3Qg Y2FsbCBpcyBtYWRlLiBBZGRpdGlvbmFsbHksIHdlIGFyZSBjb21pbmcgdXAgb24gb25seSB0aGUg M3JkIFdHIG1lZXRpbmcuIFRoZSBXRyBoYXMgbm90IGV4aXN0ZWQgZm9yIHZlcnkgbG9uZy4gV2hp bGUgc29tZSBvZiB0aGUgcGFydGljaXBhbnRzIGhhdmUgYmVlbiB3b3JraW5nIG9uIHRoaXMgZm9y IGEgd2hpbGUsIG1hbnkgaGF2ZSBub3QsIGFuZCB3ZSBhcmUgbG9va2luZyBmb3IgY29uc2Vuc3Vz IGFjcm9zcyB0aGUgV0cuDQoNClNpbmNlIFNlY0V2ZW50IGlzIGEgZnJhbWV3b3JrIHRoYXQgd2Ug ZXhwZWN0IHRvIGJlIHByb2ZpbGVkLCBJIGZlZWwgaXQgaXMgaW1wb3J0YW50IHRvIGVuc3VyZSB0 aGF0IFNlY0V2ZW50IHNwZWNpZmljYXRpb25zIGFyZSBlYXN5IGZvciBhIHZhcmlldHkgb2YgcHJv ZmlsZXMgdG8gYWRvcHQsIGFuZCB0aGF0IHRoZSBzZW1hbnRpY3MgbWFrZSBzZW5zZS4gSSBhbHNv IHRoaW5rIHRoYXQgcHJvcGVydGllcyB0aGF0IGFyZSBzcGVjaWZpYyB0byBhIHByb2ZpbGUgc2hv dWxkIGJlIGxlZnQgdG8gdGhhdCBwcm9maWxlIGFuZCBub3QgYmUgaW5jbHVkZWQgaW4gU2VjRXZl bnQuDQoNClNpbmNlIHRoaXMgaXMgYSBmcmFtZXdvcmssIGl0IGlzIGV4cGVjdGVkIHRoYXQgYXMg ZGlmZmVyZW50IGdyb3VwcyBwcm9maWxlIGl0LCB0aGVyZSB3aWxsIGJlIGFkZGl0aW9uYWwgZmVl ZGJhY2suDQoNClNwZWNpZmljYWxseSwgYXMgYSBwYXJ0aWNpcGFudCBpbiB0aGUgUklTQyBwcm9m aWxlIG9mIFNFVCwgYSBudW1iZXIgb2YgaXNzdWVzIGluIFNFVCBoYXZlIHN1cmZhY2VkIGFzIHRo ZSBSSVNDIFdHIGhhcyBsb29rZWQgYXQgaG93IHRvIHVzZSB0aGUgU0VULg0KDQpBcyBmb3IgU0VU IGJlaW5nIHN0YWJsZSBmb3Igb3ZlciBhIHllYXIsIHRoZXJlIGhhdmUgYmVlbiBhIG51bWJlciBv ZiBjaGFuZ2VzIHRvIFNFVCBzaW5jZSB0aGVuLiBJIGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgd2Fz IGNvbnNlbnN1cy4gQmVmb3JlIHRoZSBXRyB3YXMgZm9ybWVkLCBJIGFuZCBzZXZlcmFsIG90aGVy cyBoYWQgZXhwcmVzc2VkIGNvbmNlcm4gb24gdGhlIGRlc2lnbiBvZiBTRVQgd2hlbiBQaGlsIHBy ZXNlbnRlZCBpdCBhdCBhbiBJSVcgc2Vzc2lvbi4NCg0KQXMgdG8gdGFraW5nIGFub3RoZXIgeWVh ciwgSSBhbSBob3BlZnVsIHdlIGNhbiByZXNvbHZlIHRoZSByZW1haW5pbmcgaXNzdWVzIGluIFNF VCBhbmQgcHVibGlzaCBhIG5ldyBkcmFmdCBmb3IgbGFzdCBjYWxsLiBJIGRvIG5vdCB0aGluayB3 ZSB3aWxsIG5lZWQgdG8gd2FpdCBmb3IgYW5vdGhlciBXRyBtZWV0aW5nIHRvIGFzayBmb3IgbGFz dCBjYWxsLg0KDQpXZSBhbHNvIGhhdmUgYSBudW1iZXIgb2Ygb3RoZXIgZG9jdW1lbnRzIHRoYXQg YXJlIG5vdCBpbiBsYXN0IGNhbGwsIGFuZCB3ZSBkb24ndCBoYXZlIGEgV0cgYWRvcHRlZCBkcmFm dCB5ZXQgZm9yIG1hbmFnZW1lbnQuIFNvIHRoZXJlIGFyZSBzdGlsbCBhIG51bWJlciBvZiBkb2N1 bWVudHMgdG8gd29yayB0aHJvdWdoIGJlZm9yZSB3ZSBoYXZlIGFsbCB0aGUgYml0cyBmb3Igc29t ZW9uZSB0byB3b3JrIHdpdGguDQoNCkkgZG8gdGhpbmsgd2UgaGF2ZSBiZWVuIG1ha2luZyBnb29k IHByb2dyZXNzIHNpbmNlIHRoZSBsYXN0IElFVEYgbWVldGluZywgYW5kIEkgYW0gaG9wZWZ1bCB3 ZSBjYW4ga2VlcCB1cCB0aGlzIG1vbWVudHVtIGFuZCBmaW5hbGl6ZSBhbGwgdGhlIGRvY3VtZW50 cyBpbiBhIHRpbWVseSBtYW5uZXIuDQoNCi9EaWNrDQoNCg0KT24gVHVlLCBPY3QgMzEsIDIwMTcg YXQgMTI6NDggUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpJdOKAmXMgaGFyZCBmb3Ig bWUgdG8gZXZlbiBleHByZXNzIG15IGxldmVsIG9mIGZydXN0cmF0aW9uIHdpdGggdGhlIHJlY2Vu dCBhdHRlbXB0cyB0byBvbmNlIGFnYWluIHJlZGVzaWduIHRoZSBTZWNFdmVudCBUb2tlbiBzcGVj LiAgV2XigJl2ZSBiZWVuIGF0IHRoaXMgZm9yIG11bHRpcGxlIHllYXJzIGJlY2F1c2UgcGVvcGxl IGtlZXAgdHJ5aW5nIHRvIHJldmlzaXQgZGVjaXNpb25zIHRoYXQgd2VyZSBsb25nIGFnbyBtYWRl IGJ5IGNvbnNlbnN1cy4gIEl04oCZcyBiZWVuIHN0YWJsZSBmb3Igb3ZlciBhIHllYXIgYW5kIHRo ZSBtYWpvcml0eSBvZiBXR0xDIHJlc3BvbmRlbnRzIHNhaWQgc29tZSB2YXJpYW50IG9mIOKAnFdv cmtzIGZvciBtZSDigJMgc2hpcCBpdCHigJ0NCg0KVGhlcmXigJlzIG5vdCBzdWZmaWNpZW50IGp1 c3RpZmljYXRpb24gdG8gdHJ5IHRvIHVuZG8gY29uc2Vuc3VzIHBvc2l0aW9ucyB0aGF0IGhhdmUg YmVlbiBkZWJhdGVkIGFuZCBhZmZpcm1lZCBvdmVyIGFuZCBvdmVyLiAgQ291bnRlbmFuY2luZyB3 aG9sZXNhbGUgY2hhbmdlcyBhdCB0aGlzIGxhdGUgZGF0ZSBpcyBjb3VudGVycHJvZHVjdGl2ZSBp biB0aGUgZXh0cmVtZSENCg0KSXTigJlzIGZhciBiZXR0ZXIgdGhhbiBnb29kIGVub3VnaCBhcy1p cy4gIEluIG15IGV4cGVyaWVuY2UsIGlmIHdlIHN0YXJ0IHJlZGVzaWduaW5nIGl0LCBpdCB3aWxs IHJlc3VsdCBpbiBhbm90aGVyIHllYXLigJlzIGRlbGF5LiAgSXQgZG9lcyBzb21ldGhpbmcgc2lt cGxlIGFuZCB1c2VmdWwuICBQbGVhc2UsIGxldOKAmXMganVzdCBzaGlwIGl0LCBzbyBwZW9wbGUg Y2FuIHJlbHkgb24gaXQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFBoaWwgSHVudCAoSURNKSBbbWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT5dDQpTZW50 OiBNb25kYXksIE9jdG9iZXIgMzAsIDIwMTcgMjo0MiBQTQ0KVG86IERpY2sgSGFyZHQgPGRpY2su aGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQpDYzogWWFyb24g U2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5j b20+PjsgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFp bHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PjsgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PjsgSUQgRXZlbnRz IE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3Jn Pj4NCg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVu dHMgcGVyIFNFVD8NCg0KSW5saW5lLi4uDQoNClBoaWwNCg0KT24gT2N0IDMwLCAyMDE3LCBhdCAy OjIyIFBNLCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJk dEBnbWFpbC5jb20+PiB3cm90ZToNCkhpIFBoaWwNCg0KQ29ycmVjdCBtZSBpZiBJIGFtIG1pc3Vu ZGVyc3RhbmRpbmcsIGJ1dCB0aGVyZSBpcyBhIFJJU0MgcHJvZmlsZSBldmVudA0KDQoNCg0KImh0 dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlLzxodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVu aWQubmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlXy0yNTVDJmQ9RHdNRmFRJmM9Um9QMVl1 bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0 RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZs SzY3eUZfOHU4X3FTQ193JnM9MjVsMDlzSDhZVjQyeHpnVS1DWFNnOHhIOXR2eURKejQwdENSakZh bGhrdyZlPT5hY2NvdW50LWNyZWRlbnRpYWwtY2hhbmdlLXJlcXVpcmVk4oCdDQoNCg0KYW5kIGFu IFNDSU0gcHJvZmlsZSBldmVudA0KDQoNCiJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQv cGFzc3dvcmRSZXNldEV4dOKAnQ0KDQoNCkknbSBzdWdnZXN0aW5nIHRoYXQgdHdvIGRpZmZlcmVu dCBldmVudHMgd291bGQgYmUgc2VudC4gRW1iZWRkaW5nIG9uZSBpbiB0aGUgb3RoZXIgZG9lcyBu b3QgbWFrZSBzZW5zZS4NCjxwaD5JdCBpcyBhIGh5cG90aGV0aWNhbCBleGFtcGxlLiBKdXN0IGJl Y2F1c2UgeW91IGRpc2FncmVlIG9uIHRoaXMgZG9lcyBub3QgbWVhbiBvdGhlcnMgYXJlIG5vdCB2 YWxpZC4NCg0KSSBqdXN0IHBpY2tlZCBvdmVybGFwcGluZyBwcm9wb3NhbHMgdGhhdCBoYXZlIGRp ZmZlcmVudCBtZWFuaW5nIChidXQgbm90IHRoZSBzYW1lKSB0byBpbGx1c3RyYXRlIHRoZSBkaWZm ZXJlbmNlIGZyb20gaXNzdWluZyBhIHNpbmdsZSBzZXQgd2l0aCBkaWZmZXJlbnQgZXZlbnRzLg0K DQpBcyBJIGhhdmUgc3RhdGVkIHRoaXMgaXMgdmVyeSBkaWZmZXJlbnQgZnJvbSBhc3NlcnRpbmcg bXVsdGlwbGUgZGlzdGluY3QgZXZlbnRzIGluIG9uZSBTRVQuDQoNCkFsc28sIEkgdGhpbmsgaXQg aXMgc2ltcGxlciB0byBoYXZlIGV2ZW50X3R5cGUgYmUgYXQgdGhlIHNhbWUgbGV2ZWwgYXMgZXZl bnQNCg0KPHBoPm1heSBiZS4gSSB3YXMgd29ya2luZyBmcm9tIEFubmFiZWxsZSdzIHByb3Bvc2Vk IGZvcm1hdC4NCg0Kew0KICAianRpIjogIjNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMw IiwNCiAgImlhdCI6IDE0NTg0OTYwMjUsDQogICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUu Y29tPGh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8+IiwNCiAgImF1ZCI6IFsNCiAgICAiaHR0cHM6 Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLA0KICAg ICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVl NyINCiAgIF0sDQogICAiZXZlbnRfdHlwZSI6ICJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZl bnQvcGFzc3dvcmRSZXNldEV4dCIsDQogICAiZXZlbnQiOiB7DQogICAgICAgICAiaWQiOiI0NGY2 MTQyZGY5NmJkNmFiNjFlNzUyMWQ5IiwNCiAgICAgICAgICJyZXNldEF0dGVtcHRzIjo1DQogICAg ICAgfQ0KfQ0KDQp7DQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAi LA0KICAiaWF0IjogMTQ1ODQ5NjAyNSwNCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5j b208aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLz4iLA0KICAiYXVkIjogWw0KICAgICJodHRwczov L2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsDQogICAg Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3 Ig0KICAgXSwNCiAgICJldmVudF90eXBlIjogImh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2Vj ZXZlbnQvcmlzYy9ldmVudC10eXBlL2FjY291bnQtY3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWQ8 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVt YXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV9hY2NvdW50LTJEY3JlZGVu dGlhbC0yRGNoYW5nZS0yRHJlcXVpcmVkJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQ Wmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJ MWFMY0xONEtaTkEmbT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193 JnM9blF5OWV6UFJqREdkdlJUQ2FpRHRpNE9IZWxIM0RLZ1VDVEtqRjJHUS1zbyZlPT4iLA0KICAg ImV2ZW50Ijogew0KICAgICAgIOKAnHN1YuKAnTrigJ03Mzc1NjI2QTY1NjM3NOKAnSwNCiAgICAg ICDigJxpc3PigJ06Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLyINCiAgICAgICB9DQp9DQoNCg0K DQoNCg0KT24gTW9uLCBPY3QgMzAsIDIwMTcgYXQgMTI6MDkgUE0sIFBoaWwgSHVudCA8cGhpbC5o dW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQpBbm5h YmVsbGUvRGljaywNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMuIEkgdGhpbmsgd2UgbmVlZCB0 byBleGFtaW5lIHRoZSBjb25zZXF1ZW5jZXMgb2YgdGhlIHByb3Bvc2FsIGluIEpTT04uDQoNCkFz IEkgc3RhdGVkLCB3aGF0IGNhdXNlcyBtb3N0IG9mIHRoZSBpc3N1ZSBpcyB0aGUgcHJvcG9zZWQg ZXh0ZW5zaW9uIG1lY2hhbmlzbSBpbiB0aGUgcGF5bG9hZCAocG9zc2libHkgdXNpbmcgZXZlbnRz IGluIGEgcmVjdXJzaXZlIHdheSkuIERvZXMgaXQgZm9sbG93IHRoZSBvbGQgZm9ybWF0IG9yIHRo ZSBuZXc/DQoNCkxldOKAmXMgIGNvbnNpZGVyIGEgdXNlIGNhc2Ugd2hlcmUgd2UgaGF2ZSBhbiBp ZGVudGl0eSBtYW5hZ2VtZW50IHN5c3RlbSB0aGF0IHVzZXMgU0NJTSwgYnV0IHRoZSBTQ0lNIHN5 c3RlbSBpcyBhbHNvIHRoZSB1bmRlcmx5aW5nIGRhdGEgc3RvcmUgZm9yIENvbm5lY3QuICBBIFBh c3N3b3JkIHJlc2V0IG1pZ2h0IGdlbmVyYXRlIHRoZSBmb2xsb3dpbmcgZXZlbnQgd2hpY2ggaGFz IGFuIGV4dGVuc2lvbiAoY29udmV5aW5nIHJlc2V0IGNvdW50KSBBTkQgb3ZlcmxhcHBpbmcgc3Rh dGVtZW50IGZyb20gUklTQy4gIEJPVEggb2Ygd2hpY2ggbWlnaHQgYmUgaW1wb3J0YW50IHRvIGEg c2ltaWxhciByZWNlaXZlciB1c2luZyBTQ0lNIGFuZCBPSURDLg0KDQpUaGUgMDMgc3BlYyBjdXJy ZW50bHkgd291bGQgYWxsb3c6DQoNCg0Kew0KDQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkz YmQwZmIxYmQ0ZTdkMzAiLA0KDQogICJpYXQiOiAxNDU4NDk2MDI1LA0KDQogICJpc3MiOiAiaHR0 cHM6Ly9zY2ltLmV4YW1wbGUuY29tPGh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8+IiwNCg0KICAi YXVkIjogWw0KDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZh NWJiYzg3OTU5M2I3NzU0IiwNCg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMv NWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyINCg0KICAgXSwNCg0KICAgImV2ZW50cyI6IHsNCg0K ICAgICAidXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldCI6DQoNCiAgICAg ICB7ICJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkifSwNCg0KICAgICAiaHR0cHM6Ly9l eGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiOg0KDQogICAgICAgeyAicmVz ZXRBdHRlbXB0cyI6NX0sDQoNCiAgICAgImh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZl bnQvcmlzYy9ldmVudC10eXBlL1w8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJE dHlwZV8tMjU1QyZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1 ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09 aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZzPTI1bDA5c0g4WVY0 Mnh6Z1UtQ1hTZzh4SDl0dnlESno0MHRDUmpGYWxoa3cmZT0+DQogICAgICAgYWNjb3VudC1jcmVk ZW50aWFsLWNoYW5nZS1yZXF1aXJlZCI6IHsNCg0KICAgICAgICAg4oCcc3Vi4oCdOuKAnTczNzU2 MjZBNjU2Mzc04oCdLA0KDQogICAgICAgICDigJxpc3PigJ06Imh0dHBzOi8vaWRwLmV4YW1wbGUu Y29tLyINCg0KICAgICAgIH0NCg0KICB9DQoNCn0NCg0KDQoNCkluIHRoZSBhYm92ZSAtIGVhY2gg cGF5bG9hZCBpcyBhIOKAmHBlZXInIGFuZCBpc3N1ZWQgd2l0aG91dCBwcmVmZXJlbmNlIGJ5IHRo ZSB0cmFuc21pdHRlci4gVGhlIHJlY2VpdmVyIGNhbiBhc3NpZ24gcHJpb3JpdHkgaW4gaXRzIG93 biBjb250ZXh0IGlmIHRoYXQgbWF0dGVycy4NCg0KDQoNClRoZSBuZXcgcHJvcG9zYWw6DQoNCg0K DQp7DQoNCiAgImp0aSI6ICIzZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCIsDQoNCiAg ImlhdCI6IDE0NTg0OTYwMjUsDQoNCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5jb208 aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLz4iLA0KDQogICJhdWQiOiBbDQoNCiAgICAiaHR0cHM6 Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLA0KDQog ICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2 ZWU3Ig0KDQogICBdLA0KDQogICAiZXZlbnQiOiB7DQoNCiAgICAg4oCcZXZlbnRfdHlwZeKAnToi dXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldOKAnSwNCg0KICAgICAiaWQi OuKAnTQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDnigJ0sDQoNCiAgICAg4oCcZXZlbnRz4oCdOnsN Cg0KICAgICAtPm5vdGUg4oCmaXMgdGhpcyB0aGUgb2xkIG9yIG5ldyBzdHJ1Y3R1cmU/IDwtDQoN CiAgICAgICAiaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQi Og0KDQogICAgICAgICB7ICJyZXNldEF0dGVtcHRzIjo1fSwNCg0KICAgICAgICJodHRwOi8vc2No ZW1hcy5vcGVuaWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS9cPGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRf c2VjZXZlbnRfcmlzY19ldmVudC0yRHR5cGVfLTI1NUMmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQ cHVZcVBrQUkxYUxjTE40S1pOQSZtPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84 dThfcVNDX3cmcz0yNWwwOXNIOFlWNDJ4emdVLUNYU2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmU9 Pg0KICAgICAgICAgYWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZCI6IHsNCg0KICAg ICAgICAg4oCcc3Vi4oCdOuKAnTczNzU2MjZBNjU2Mzc04oCdLA0KDQogICAgICAgICDigJxpc3Pi gJ06Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLyINCg0KICAgICAgIH0NCg0KICAgICB9DQoNCiAg IH0NCg0KfQ0KDQoNCg0KSW4gdGhlIGFib3ZlLCBzdWItZXZlbnRzIG9yIGV4dGVuc2lvbnMgaGF2 ZSBhIGRpZmZlcmVudCBmb3JtYXQuIFRoZSBzYW1lIGNvbXBsYWludCBhYm91dCB0aGUgb3JpZ2lu YWwgc3RhbmRzLg0KDQoNCg0KKk9SKiAoaWYgdGhlIHJlY2VpdmVyIGNhcmVzIGFib3V0IFJJU0Mg bW9yZSkuICBOb3RlIHRoYXQgdGhpcyBsZWFkcyB0byBhIHRyaXBsZSBuZXN0ZWQgc3RydWN0dXJl Lg0KDQoNCg0Kew0KDQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAi LA0KDQogICJpYXQiOiAxNDU4NDk2MDI1LA0KDQogICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1w bGUuY29tPGh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8+IiwNCg0KICAiYXVkIjogWw0KDQogICAg Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0 IiwNCg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2 NDFkNzY3NmVlNyINCg0KICAgXSwNCg0KICAgImV2ZW50Ijogew0KDQogICAgIOKAnGV2ZW50X3R5 cGXigJ06Imh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBl L1w8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3Nj aGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV8tMjU1QyZkPUR3TUZh USZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpC VFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09aXlWbnJabXI5X3VHQ1E2TUQw ekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZzPTI1bDA5c0g4WVY0Mnh6Z1UtQ1hTZzh4SDl0dnlE Sno0MHRDUmpGYWxoa3cmZT0+DQoNCiAgICAgICAgICAgICBhY2NvdW50LWNyZWRlbnRpYWwtY2hh bmdlLXJlcXVpcmVk4oCdLA0KDQogICAgICDigJxzdWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0s DQoNCiAgICAgIOKAnGlzc+KAnToiaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20v4oCcPGh0dHBzOi8v aWRwLmV4YW1wbGUuY29tLyVFMiU4MCU5Qz4sDQoNCiAgICAgIOKAnGV2ZW50c+KAnTp7DQoNCiAg ICAgICAgInVybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3JkUmVzZXQiOg0KDQogICAg ICAgIHsNCg0KICAgICAgICAgICJpZCI64oCdNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOeKAnSwN Cg0KICAgICAgICAgIOKAnGV2ZW50c+KAnTp7DQoNCiAgICAgICAgICAgICAiaHR0cHM6Ly9leGFt cGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiOg0KDQogICAgICAgICAgICAgICB7 ICJyZXNldEF0dGVtcHRzIjo1fSwNCg0KICAgICAgICAgIH0NCg0KICAgICAgICB9DQoNCiAgICAg IH0NCg0KICAgfQ0KDQp9DQoNCg0KDQpJbiB0aGUgYWJvdmUsIHRoZSBleHRlbnNpb24gaXMgcGxh Y2VkIGluc2lkZSB0aGUgZXZlbnQgaXQgZXh0ZW5kcy4gSXQgZm9sbG93cyB0aGUgb2xkIGZvcm1h dCAob3Igc2hvdWxkIGl0IGZvbGxvdyB0aGUgbmV3PykNCg0KKk9SKiBGb2xsb3dpbmcgdGhlIHRv cCBsYXllciBwYXR0ZXJuIG9mIHNpbmd1bGFyIGV2ZW50ICBOb3RlIHRoYXQgdGhpcyBsZWFkcyB0 byBhIHRyaXBsZSBuZXN0ZWQgc3RydWN0dXJlLg0KDQoNCg0Kew0KDQogICJqdGkiOiAiM2QwYzNj Zjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KDQogICJpYXQiOiAxNDU4NDk2MDI1LA0KDQog ICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPGh0dHBzOi8vc2NpbS5leGFtcGxlLmNv bS8+IiwNCg0KICAiYXVkIjogWw0KDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVk cy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiwNCg0KICAgICJodHRwczovL2podWIuZXhhbXBs ZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyINCg0KICAgXSwNCg0KICAgImV2 ZW50Ijogew0KDQogICAgIOKAnGV2ZW50X3R5cGXigJ06Imh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5u ZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL1w8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNj X2V2ZW50LTJEdHlwZV8tMjU1QyZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2 N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNM TjRLWk5BJm09aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZzPTI1 bDA5c0g4WVY0Mnh6Z1UtQ1hTZzh4SDl0dnlESno0MHRDUmpGYWxoa3cmZT0+DQoNCiAgICAgICAg ICAgICBhY2NvdW50LWNyZWRlbnRpYWwtY2hhbmdlLXJlcXVpcmVk4oCdLA0KDQogICAgICDigJxz dWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0sDQoNCiAgICAgIOKAnGlzc+KAnToiaHR0cHM6Ly9p ZHAuZXhhbXBsZS5jb20v4oCcPGh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLyVFMiU4MCU5Qz4sDQoN CiAgICAgIOKAnGV2ZW504oCdOnsNCg0KICAgICAgICDigJxldmVudF90eXBl4oCdOiJ1cm46aWV0 ZjpwYXJhbXM6c2NpbTpldmVudDpwYXNzd29yZFJlc2V04oCdLA0KDQogICAgICAgICJpZCI64oCd NDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOeKAnSwNCg0KICAgICAgICDigJxldmVudOKAnTp7DQoN CiAgICAgICAgICDigJxldmVudF90eXBl4oCdOiJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZl bnQvcGFzc3dvcmRSZXNldEV4dOKAnSwNCg0KICAgICAgICAgICJyZXNldEF0dGVtcHRzIjo1DQoN CiAgICAgICAgfQ0KDQogICAgICB9DQoNCiAgIH0NCg0KfQ0KDQoNCg0KVGhpcyBmb3JtYXQgZm9s bG93cyB0aGUgcHJvcG9zZWQgc2luZ3VsYXIgZXZlbnQgZm9ybWF0IHJlY3Vyc2l2ZWx5IGFuZCBp cyAzIGxheWVycyBkZWVwLiBOb3RlIHRoYXQgdGhlIHBhcnNlciBoYXMgdG8gY29udGludWUgdG8g c2VhcmNoIHRoZSBkb2N1bWVudCBmb3IgdGhpbmdzIHRoYXQgYXJlbuKAmXQgdGhlcmUgYXMgaXQg aGFzIHRvIHN0b3Agd2hlbiBubyDigJxldmVudOKAnSBhdHRyaWJ1dGUgaXMgZm91bmQgcmF0aGVy IHRoYW4gaXRlcmF0ZSBvdmVyIGFuIGFycmF5Lg0KDQoNClBoaWwNCg0KT3JhY2xlIENvcnBvcmF0 aW9uLCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3QNCkBpbmRlcGVuZGVudGlkDQp3 d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNvbSZkPUR3TUZhUSZjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERw Y3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2 N3lGXzh1OF9xU0NfdyZzPTlzWWhncEV6Yjd4UGxRRm1DQ1hObUhvNmZRTjlJQnUtU0hKYW1nX0I0 SHMmZT0+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+ DQoNCk9uIE9jdCAzMCwgMjAxNywgYXQgODo1NyBBTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiB3cm90 ZToNCg0KUmVwbGllcyBpbmxpbmUuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpJ ZGVudGl0eSBTZXJ2aWNlcw0KDQoNCkZyb206IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCkRhdGU6IFN1bmRheSwgT2N0b2JlciAy OSwgMjAxNyBhdCA1OjI1IFBNDQpUbzogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208 bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkNjOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYu aWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+LCBNaWtlIEpvbmVz IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbT4+LCAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24u Y29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4sIElEIEV2ZW50cyBNYWlsaW5nIExpc3Qg PGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBS ZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPw0KDQpJ IGhvcGUgdGhpcyBhbnN3ZXJzIHlvdXIgcXVlc3Rpb24uDQoNCk15IOKAnG1heeKAnSB3YXMgYmVj YXVzZSBJIGNhbuKAmXQgc2VlIGEgcmVhc29uIHdoeSBub3QuIFRoZSBxdWVzdGlvbiBzaG91bGQg YmUsIHdoYXQgaXMgdGhlIGp1c3RpZmljYXRpb24gdG8gbWFrZSDigJxldmVudHPigJ0gc2luZ3Vs YXI/DQpbcmljaGFubmFdVGhlIHNpbmd1bGFyIOKAnGV2ZW504oCdIGNsYWltIGhhcyBjbGVhcmVy IHNlbWFudGljcyBhbmQgaXMgZWFzaWVyIHRvIHByb2Nlc3MuIFdlIHNob3VsZCBvcHQgZm9yIGVh c2llciBzb2x1dGlvbnMgdW5sZXNzIHRoZXJlIGFyZSB1c2UgY2FzZXMgdGhhdCByZXF1aXJlIG1v cmUgY29tcGxleGl0eS5bL3JpY2hhbm5hXQ0KDQpUaGVyZSBhcmUgbWFueSByZWFzb25zIGZvciBt dWx0aXBsZSBldmVudHMgaW4gYSBTRVQuICBTb21lIGFyZSBnb29kLCBzb21lIG5vdCBzbyBnb29k LiBTb21lIG9mIHRoZSByZWFzb25zLi4uDQoNCjEuICBNdWx0aXBsZSBldmVudCBwYXlsb2FkcyBl eHByZXNzaW5nIHN0YXRlbWVudHMgYWJvdXQgbGFyZ2VseSB0aGUgKnNhbWUqdGhpbmcuIEZvciBl eGFtcGxlLCBTQ0lNIHBhc3N3b3JkIHJlc2V0IEFORCBSSVNDIHBhc3N3b3JkIHJlc2V0LiAgQSBS SVNDIEV2ZW50IGFuZCBhbiBPcGVuQmFua2luZyBFdmVudC4gSXMgb25lIGEgY29tcGxlbWVudCB0 byB0aGUgb3RoZXI/ICBEbyB0aGV5IG92ZXJsYXAgb3IgYXJlIHRoZXkgZGlzdGluY3Q/DQpbcmlj aGFubmFdQ29weS9wYXN0ZWQgZnJvbSBteSBlYXJsaWVyIGVtYWlsOg0KV2h5IGlzIGl0IG5lY2Vz c2FyeSBvciBhcHByb3ByaWF0ZSB0byBpbmNsdWRlIHRoZXNlIGV2ZW50cyBpbiB0aGUgc2FtZSBT RVQ/IFRoZXkgYXJlIGxpa2VseSBiZWluZyBnZW5lcmF0ZWQgYnkgZGlmZmVyZW50IHN5c3RlbXMg YXQgZGlmZmVyZW50IHRpbWVzIG9uIHRoZSB0cmFuc21pdHRlcuKAmXMgc2lkZSwgY29uc3VtZWQg YnkgZGlmZmVyZW50IHN5c3RlbXMgb24gdGhlIHJlY2VpdmVy4oCZcyBzaWRlLCBhbmQgcG9zc2li bHkgYmVpbmcgdHJhbnNtaXR0ZWQgb3ZlciBkaWZmZXJlbnQgZXZlbnQgc3RyZWFtcy4gSSBrbm93 IHRoZSBsYXR0ZXIgd291bGQgYmUgdGhlIGNhc2UgZm9yIHVzLCBhcyBhIHJlY2VpdmVyLiBFdmVu IGlmIGl04oCZcyBub3QsIGlzIGl0IGJ1cmRlbnNvbWUgdG8gc2VuZCB0aGVzZSBldmVudHMgc2Vw YXJhdGVseT8gV2hhdCB2YWx1ZSBpcyBnYWluZWQgaW4gY29tYmluaW5nIHRoZW0/DQoNCkFkZGl0 aW9uYWxseSwgc2luY2UgdGhlIHNpZ25hdHVyZSBpcyBvdmVyIHRoZSBTRVQgYW5kIG5vdCB0aGUg ZXZlbnQgb2JqZWN0cywgUmVjZWl2ZXJzIGluZGVwZW5kZW50bHkgcm91dGUgc2VwYXJhdGUgZXZl bnRzIGZyb20gYSBzaW5nbGUgdG9rZW4gd2l0aG91dCBlaXRoZXIgbG9zaW5nIHRoZSBhYmlsaXR5 IHRvIHZlcmlmeSB0aGUgYXV0aGVudGljaXR5IG9mIHRoZSBldmVudCBvciBzaGFyaW5nIGFsbCBp bmZvcm1hdGlvbiBpbiB0aGUgU0VUIHdpdGggZXZlcnkgc3lzdGVtIGhhbmRsaW5nIGFueSBldmVu dCBpbiB0aGUgdG9rZW4uWy9yaWNoYW5uYV0NCg0KMi4gIE11bHRpcGxlIGV2ZW50cyBwYXlsb2Fk cyBleHByZXNzaW5nIGRpZmZlcmVudCBzdGF0ZW1lbnRzIGFib3V0IHRoZSBzYW1lIHRyYW5zYWN0 aW9uIC0gUklTQyBQYXNzd29yZCBSZXNldCBhbmQgUklTQyBTZXNzaW9uIENhbmNlbA0KW3JpY2hh bm5hXVNhbWUgYXMgYWJvdmVbL3JpY2hhbm5hXQ0KMy4gIEEgbmV3IHByb2ZpbGUgZGVmaW5lcyBu ZXcgZXZlbnQgYXR0cmlidXRlcyB0byBiZSBhZGRlZCBvbiB0byBhbiBleGlzdGluZyBldmVudCB0 eXBlIChhIHB1cmUgZXh0ZW5zaW9uKQ0KW3JpY2hhbm5hXUkgaGF2ZSBzdWdnZXN0ZWQgYSB3YXkg dG8gc3VwcG9ydCBleHRlbnNpb25zIHdpdGhpbiBhbiBldmVudCBib2R5LCBtdWx0aXBsZSB0aW1l cyBub3cuIElmIHlvdSBzZWUgcHJvYmxlbXMgd2l0aCBpdCwgcGxlYXNlIHBvaW50IHRoZW0gb3V0 LlsvcmljaGFubmFdDQoNCkkgdGhpbmsgaXQgaXMgcXVpdGUgdmFsaWQgdG8gYWxsb3cgMSBhbmQg My4gIDIgY291bGQgYmUgbGltaXRlZCBieSBzcGVjaWZpYyBwcm9maWxlcyBsaWtlIFJJU0MgaWYg dGhleSB3YW50Lg0KDQpJIGFtIG5vdCBpbiBhZ3JlZW1lbnQgdGhhdCBtYWtpbmcgZXZlbnQgc2lu Z3VsYXIgc2ltcGxpZmllcyBhbnl0aGluZy4gRm9yIG9uZSBpcyBtYWtlcyBleHRlbnNpb25zIGNv bXBsZXggKGFub3RoZXIgbmVzdGVkIEpTT04gc3RydWN0dXJlKSBhbmQgcG90ZW50aWFsbHkgY29u ZmxpY3RpbmcuDQpbcmljaGFubmFdDQpXYXlzIHRoYXQgbXVsdGlwbGUtZXZlbnQgU0VUcyBhcmUg bW9yZSBjb21wbGljYXRlZDoNCg0KICAxLiAgSXQgcmVzdWx0cyBpbiBhIG1vcmUgY29tcGxleCBz dHJ1Y3R1cmUgZm9yIHRoZSBzaW5nbGUgZXZlbnQgdXNlIGNhc2UsIHdoaWNoIEkgdGhpbmsgd2Ug YWxsIGFncmVlIGlzIHRoZSBtYWpvcml0eSB1c2UgY2FzZS4NCiAgMi4gIE11bHRpcGxlLWV2ZW50 IFNFVHMgaGF2ZSBhbWJpZ3VvdXMgc2VtYW50aWNzLiBUaGUgcHJlc2VuY2Ugb2YgdHdvIGV2ZW50 cyBBIGFuZCBCIGluIHRoZSBzYW1lIFNFVCBjb3VsZCBtZWFuIGFueSBvZjoNCg0KICAgICAqICAg VGhleSBhcmUgcmVsYXRlZCB0byB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50IChpLmUuIHRoZSBzYW1l IHRoaW5nIGFzIGlmIHRoZXkgd2VyZSBmcm9tIGRpZmZlcmVudCBTRVRzIHRoYXQgaGF2ZSBhIGNv bW1vbiB0eG4pLg0KICAgICAqICAgQSBpcyBhbiBleHRlbnNpb24gb2YgQi4NCiAgICAgKiAgIEIg aXMgYW4gZXh0ZW5zaW9uIG9mIEEuDQogICAgICogICBUaGV5IGFyZSBhbGlhc2VzIGZvciBvbmUg YW5vdGhlci4NCiAgICAgKiAgIFRoZXkgYXJlIG5vdCBhY3R1YWxseSByZWxhdGVkIHRvIG9uZSBh bm90aGVyIGluIGFueSB3YXkuDQoNCiAgMS4gIENsYWltIHNlbWFudGljcyBiZWNvbWUgaGFyZGVy IHRvIGRlZmluZSwgYXMgZGlmZmVyZW50IHByb2ZpbGVzIG1heSB3YW50IHRvIHVzZSB0aGUgc2Ft ZSBjbGFpbXMgaW4gZGlmZmVyZW50IHdheXMuDQoNCklmIHRoZSBXRyB3YW50cyB0byBibG9jayAx IGFuZCAyIGFib3ZlLCB0aGVuIEkgYmVsaWV2ZSB3ZSBoYXZlIHRvIGVzdGFibGlzaCBhbiBldmVu dCByZWdpc3RyeSB0byBlbnN1cmUgbmV3IEV2ZW50IHByb2ZpbGVzIGRvIG5vdCBvdmVybGFwIHRv IGVsaW1pbmF0ZSB0aGUgbmVlZCB0byBleHByZXNzIG11bHRpcGxlIGV2ZW50cy4NCltyaWNoYW5u YV1J4oCZbSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IHRoaXMuIEFyZSB5b3UgcmVmZXJyaW5n IHRvIGV2ZW50IG5hbWVzPyBUaG9zZSBhcmUgYWxyZWFkeSBkZWZpbmVkIGJ5IHRoZSBzcGVjIHRv IGJlIFVSSXMuWy9yaWNoYW5uYV0NClBoaWwNCg0KT3JhY2xlIENvcnBvcmF0aW9uLCBJZGVudGl0 eSBDbG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3QNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRl bnRpZC5jb208aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAt M0FfX3d3dy5pbmRlcGVuZGVudGlkLmNvbSZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4 UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtB STFhTGNMTjRLWk5BJm09VS1hNUhCTkQwSGFUWDRhbk5aZnpYN3BEc2ZLNWYwaDltWjlDWmtrR2ll YyZzPUtCd0tQRm5xWV9ROTVDVEFfX1dHQ1lHVHhyRDdBR0N4dWVvUFhuS0VVVDAmZT0+DQpwaGls Lmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCk9uIE9jdCAy OSwgMjAxNywgYXQgNDoxMiBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFp bHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQoNClBoaWw6DQoNCkluIHlvdXIgZXhh bXBsZXMgZm9yIGhhdmluZyBhIHBsdXJhbGl0eSBvZiBldmVudHMsIHlvdSB1c2UgdGhlIHdvcmQg Im1heSIsIHdoaWNoIGxlYWRzIG1lIHRvIHF1ZXN0aW9uIGlmIGEgcGx1cmFsaXR5IG9mIGV2ZW50 cyBpcyByZWFsbHkgcmVxdWlyZWQgaW4gU0VULg0KDQpZb3UgcG9zaXQgdGhhdCBpdCB3aWxsIGJl IGRpZmZpY3VsdCBmb3IgYSBkaXN0cmlidXRlZCBzeXN0ZW0gdG8gY29ycmVsYXRlIG11bHRpcGxl IFNFVHMgd2l0aCB0aGUgc2FtZSAidHhuIiwgYnV0IHRoZSBkaXN0cmlidXRlZCBzeXN0ZW0gd2ls bCBjZXJ0YWlubHkgbmVlZCB0byBjb3JyZWxhdGUgZXZlbnRzIG9uIHRoZSBzYW1lIHN1YmplY3Qg LS0gY29ycmVsYXRpbmcgZXZlbnRzIG9uIHRoZSBzYW1lICJ0eG4iIG9uIHRoZSBzYW1lIHN1Ympl Y3Qgc2VlbXMgZmFpcmx5IHNpbXBsZS4NCg0KSSB0aGluayB0aGF0IGEgcmVjZWl2ZXIgd2lsbCBu ZWVkIHRvIGNvcnJlbGF0ZSBtdWx0aXBsZSBTRXRzIG9uIHRoZSBzYW1lIHN1YmplY3QsIHNvIGhh dmluZyBtdWx0aXBsZSBldmVudHMgaW4gYSBTRVQgaXMgcmVkdW5kYW50LCBhbmQgYWRkcyBjb21w bGV4aXR5IHdpdGggbm8gY2xlYXIgYmVuZWZpdCB0aGF0IEkgY2FuIHNlZS4NCg0KQW4gaW1wbGVt ZW50b3IgbWF5IGNob29zZSB0byBzZW5kIG11bHRpcGxlIFNFVHMsIG9yIHNlbmQgYSBzaW5nbGUg U0VUIHdpdGggbXVsdGlwbGUgZXZlbnRzLCBzbyBhIHJlY2VpdmVyIHdpbGwgbmVlZCB0byBzdXBw b3J0IGJvdGguIEkgcHJlZmVyIHdlIHBpY2sgb25lIHdheSBhbmQgbWluaW1pemUgdGhlIGNvZGUg cGF0aHMsIGFuZCB3ZSB3aWxsIG5lZWQgdG8gc3VwcG9ydCBjb3JyZWxhdGluZyBhY3Jvc3MgbXVs dGlwbGUgU0VUcywgc28gdGhhdCBzZWVtcyB0aGUgYmVzdCBtZWNoYW5pc20uDQoNCkxldCBtZSBr bm93IGlmIHRoZXJlIGlzIHNvbWV0aGluZyBJIG1pc3NlZCBpbiBteSBsb2dpYy4NCg0KL0RpY2sN Cg0KDQpPbiBTdW4sIE9jdCAyOSwgMjAxNyBhdCAxMToyOCBBTSwgWWFyb24gU2hlZmZlciA8eWFy b25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToN CkluIHRoYXQgY2FzZSwgbGV0J3MgYWRkIHRleHQgdG8gdGhhdCBlZmZlY3QsIGUuZy4gd2UgY291 bGQgYWRkIHRvIHRoZSBkZWZpbml0aW9uIG9mIHRoZSAiZXZlbnRzIiBjbGFpbToNCg0KUHJvZmls aW5nIHNwZWNpZmljYXRpb25zIFNIT1VMRCBkZWZpbmUgdGhlIGFsbG93ZWQgZXZlbnQgc3RhdGVt ZW50cywgYW5kIE1BWSByZXN0cmljdCB0aGVpciBudW1iZXIuIEZvciBleGFtcGxlLCBzb21lIHBy b2ZpbGVzIG1heSByZXF1aXJlIHRoaXMgY2xhaW0gdG8gY29udGFpbiBvbmx5IGEgc2luZ2xlIGV2 ZW50IHN0YXRlbWVudC4NCg0KVGhhbmtzLA0KICAgICAgICBZYXJvbg0KDQpPbiAyNC8xMC8xNyAy MjoxMCwgTWlrZSBKb25lcyB3cm90ZToNCkkgYWdyZWUgd2l0aCBtdWNoIG9mIFBoaWzigJlzIHJh dGlvbmFsZSBoZXJlLg0KDQpJdOKAmXMgZmluZSBmb3Igc29tZSBwcm9maWxlcyB0byBzYXkgdGhh dCB0aGUg4oCcZXZlbnRz4oCdIHNldCBtdXN0IGJlIGEgc2luZ2xldG9uLiAgVGhhdCBkb2VzbuKA mXQgaGF2ZSB0byBiZSB0cnVlIGZvciBhbGwgZXZlbnRzLiAgSSB0aGluayB0aGluZ3MgYXJlIGZp bmUgYXMtaXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQoqRnJvbToqIElkLWV2ZW50IFttYWlsdG86 aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9y Zz5dICpPbiBCZWhhbGYgT2YgKlBoaWwgSHVudA0KKlNlbnQ6KiBNb25kYXksIE9jdG9iZXIgMjMs IDIwMTcgODo0NyBQTQ0KKlRvOiogUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5h QGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+Pg0KKkNjOiogSUQgRXZlbnRz IE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3Jn Pj4NCipTdWJqZWN0OiogUmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVu dHMgcGVyIFNFVD8NCg0KQW5uYWJlbGxlLA0KDQpJIGhhdmUgYSBudW1iZXIgb2YgY29uY2VybnMg d2l0aCB0aGlzIHByb3Bvc2FsLg0KDQpQcm9maWxpbmcgSW5kZXBlbmRlbmNlIC8gS2VlcGluZyBF dmVudCBQYXlsb2FkcyBJbmRlcGVuZGVudA0KDQpJbmRpY2F0aW5nIHRoYXQgZXh0ZW5zaW9ucyBz aG91bGQgYmUgaGFuZGxlZCBieSBwcm9maWxlcyBsZWFkcyB0byBtb3JlIGludGVyLW9wZXJhYmls aXR5IGlzc3VlcyBhbmQgbW9yZSBpbXBvcnRhbnRseSBpbnRydWRlcyBvbiB0aGUgRXZlbnQgcGF5 bG9hZCBzcGFjZSBieSBzdWdnZXN0aW5nIGEgc3ViLXNjaGVtYSBjcmVhdGVzIHBvdGVudGlhbCBs aW1pdGF0aW9ucyBhbmQgY29uZmxpY3RzIHRoYXQgbWF5IGFkZCB0byBjb21wbGV4aXR5IGxhdGVy IG9uLiBUaGUgY3VycmVudCBmb3JtYXQgYWxsb3dzIGEgcGFyc2VyIHRvIGRpc2NvdmVyIGFuZCB1 bmxvYWQgb25lIG9yIG1vcmUgSlNPTiBwYXlsb2FkcyB3aGljaCBjYW4gZWFjaCBoYXZlIGluZGVw ZW5kZW50IHN0cnVjdHVyZS4NCg0KR2VuZXJhbCBleHRlbnNpb25zDQoNClRoZSBwcm9wb3NhbCBh bHNvIHJ1bGVzIG91dCBnZW5lcmFsIHB1cnBvc2UgZXh0ZW5zaW9ucyBub3QgcmVsYXRlZCB0byBh bnkgc3BlY2lmaWMgZXZlbnQuIEdpdmVuIHRoZSBlbWVyZ2VuY2Ugb2YgaXRlbXMgbGlrZSBHUFJE LCBJIHdvdWxkIG5vdCB3YW50IHRvIGJsb2NrIHRoZSBhYmlsaXR5IHRvIGFkZCBtZXRhLWRhdGEg b3Igb3RoZXIgZ2VuZXJhbCBwdXJwb3NlIGl0ZW1zLiBXZSBjYW4gYWxzbyBhbnRpY2lwYXRlIHNv bWUgZGVsaXZlcnkgc2NlbmFyaW9zIHdoZXJlIGFkZGl0aW9uYWwgZGF0YSBtaWdodCBiZSByZXF1 aXJlZC4gRXZlbiB0aG91Z2ggdGhlcmUgaXMgbm8gY3VycmVudCBwbGFubmVkIHVzZSwgSSBzZWUg bm8gZ29vZCByZWFzb24gdG8gcnVsZSB0aGlzIG91dC4NCg0KTXVsdGlwbGUgRXZlbnRzIEZyb20g RGlmZmVyZW50IEZhbWlsaWVzICh2cy4gTXVsdGlwbGUgRXZlbnRzIGZyb20gYSBzaW5nbGUgZmFt aWx5IGxpa2UgUklTQykNCg0KSW4gb3VyIFJJU0Mgc2Vzc2lvbiB3ZSBkaXNjdXNzZWQgZXhwcmVz c2luZyBtdWx0aXBsZSBkaXN0aW5jdCBSSVNDIGV2ZW50cyBpbiBvbmUgU0VULiBUaGUgZGlzY3Vz c2lvbiB3YXMgdGhhdCBvbmx5IG9uZSBSSVNDIGV2ZW50IGF0IGEgdGltZS4gV2UgZGlkIG5vdCBk aXNjdXNzIG90aGVyIGV2ZW50IHByb2ZpbGVzLiBJIGRvbuKAmXQgc2VlIGEgcmVhc29uIHRvIHJ1 bGUgb3V0IG11bHRpLWV2ZW50cyBmcm9tIGRpZmZlcmVudCBmYW1pbGllcyBhdCB0aGUgU0VUIGxl dmVsLiBFYWNoIHByb2ZpbGUgaXMgZXhwcmVzc2luZyBzbGlnaHRseSBkaWZmZXJlbnQgdGhpbmdz IGFib3V0IHRoZSBzYW1lIGV2ZW50Lg0KDQpJIGNhbiBmb3JzZWUgc29tZSBjYXNlcyB3aGVyZSBp dCBpcyBub3QgY2xlYXIgd2hpY2ggaXMgdGhlIHByaW1hcnkgYW5kIHdoaWNoIGlzIHRoZSBleHRl bnNpb24uICBUaGVyZSBtYXkgbm90IGJlIGEgY2xlYXIgd2lubmVyLg0KDQpBIGNvdXBsZSBvZiBl eGFtcGxlcyAodGhlc2UgYXJlIG5lY2Vzc2FyaWx5IHJlYWzigKZqdXN0IHBvc3NpYmlsaXRpZXMp Og0KDQoqIEl0IGlzIHByb2JhYmx5IHVzZWZ1bCB0byBiZSBhYmxlIHRvIGV4cHJlc3Mgc2ltbGFy L292ZXJsYXBwaW5nIGV2ZW50cyBmcm9tIGRpZmZlcmVudCBTRVQgcHJvZmlsZXMgaW4gb25lIFNF VC4gIEZvciBleGFtcGxlIGEgQmFja2NoYW5uZWwgTG9nb3V0ICYgYSBSSVNDIHNlc3Npb24gY2Fu Y2VsIGV2ZW50Lg0KDQoqIFNDSU0gbWF5IHdhbnQgdG8gcmVwcmVzZW50IGEgc2luZ2xlIHRyYW5z YWN0aW9uIGFzIGNhdXNpbmcgbXVsdGlwbGUgc3RhdGUgY2hhbmdlcyBpbiBhbiBldmVudCAoZS5n LiBhIHBhc3N3b3JkIGNoYW5nZSBjYXVzZXMgbXVsdGlwbGUgZWZmZWN0cykuIEhhdmluZyB0byBj aGFzZSBkb3duIG11bHRpcGxlIGV2ZW50cyBhbmQgY29ycmVsYXRlIGJ5IOKAnHR4buKAnSB3b3Vs ZCBiZSBjaGFsbGVuZ2luZyBpbiBhIG11bHRpLXRocmVhZGVkL211bHRpLW5vZGUgZGVsaXZlcnkg c3lzdGVtLiAgIFRoZSBTQ0lNIGxpc3QgaGFzIG5vdCBkaXNjdXNzZWQgdGhpcywgYnV0IEkgd291 bGQgbm90IHdhbnQgdG8gYmxvY2sgdGhpcyBjYXBhYmlsaXR5LiAgSU9XIC0gSnVzdCBiZWNhdXNl IFJJU0MgZG9lcyBub3Qgd2FudCB0byBleHByZXNzIG11bHRpcGxlIGV2ZW50cyBkb2VzIG5vdCBt YWtlIHRoaXMgdHJ1ZSBmb3Igb3RoZXIgcHJvZmlsZXMuDQoNCiogV2UgbWF5IHdpc2ggdG8gaW5k aWNhdGUgYSBTQ0lNIFBhc3N3b3JkIFJlc2V0IHdhcyBwZXJmb3JtZWQgYW5kIGEgTG9nb3V0L3Nl c3Npb24gY2FuY2VsbGF0aW9uIGlzIGV4cHJlc3NlZCBhdCB0aGUgc2FtZSB0aW1lLiAgVGhlIGV2 ZW50cyBhcmUgcmVsYXRlZCBidXQgZXhwcmVzcyBkaWZmZXJlbnQgZGF0YS4NCg0KQXZvaWRpbmcg Q29uZnVzaW9uIEZyb20gU2ltaWxhciBFdmVudHMgT3JpZ2luYXRpbmcgZnJvbSB0aGUgU2FtZSBU cmFuc2FjdGlvbg0KDQpJZiBldmVudHMgYXJlIHNlbnQgc2VwYXJhdGVseSwgdGhlbiBtb3JlIHRy YWNraW5nIG9mIHN0YXRlIChlLmcuIGJ5IHR4bikgd291bGQgYmUgcmVxdWlyZWQgdG8gZW5zdXJl IHNpbWlsYXIgZXZlbnRzIGFyZSBub3QgbWlzdGFrZW4gb3IgaGFuZGxlZCBhcyByZXBlYXRzLiBX aGlsZSB0eG4gcHJvdmlkZXMgdXNlZnVsIGF1ZGl0IGFuYWx5c2lzIGNhcGFiaWxpdHksIEnigJlt IG5vdCBzdXJlIGl0IGNhbiBiZSB1c2VkIGluIGxpdmUgb3IgbmVhci1yZWFsIHRpbWUgc3lzdGVt cyBnaXZlbiBkaXN0cmlidXRlZCBtdWx0aS1ub2RlLCBtdWx0aS10aHJlYWRpbmcgYXJjaGl0ZWN0 dXJlcy4NCg0KUHJldmlvdXMgRGlzY3Vzc2lvbg0KDQpJIG5vdGUgdGhhdCBJIG9yaWdpbmFsbHkg cmFpc2VkIGhhdmluZyBhbiBhdHRyaWJ1dGUgdG8gZGVzaWduYXRlIHByaW1hcnkgZXZlbnQgYXR0 cmlidXRlIHRvIGFsbGV2aWF0ZSB5b3VyIGNvbmNlcm4sIGJ1dCB0aGlzIHdhcyBub3QgYWNjZXB0 ZWQuIFNlZToNCg0KKiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkLWV2 ZW50L2N1cnJlbnQvbXNnMDA0MDYuaHRtbDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfaWQt MkRldmVudF9jdXJyZW50X21zZzAwNDA2Lmh0bWwmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZ cVBrQUkxYUxjTE40S1pOQSZtPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1Js UUcxaXcmcz1TM3NNVmlxTXZFZ253R2JKd09RTnljck95cjdTZWZwcV9Nb0ZPS2NFZUNFJmU9Pg0K DQoqIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3VycmVu dC9tc2cwMDE0MC5odG1sPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1 cnJlbnRfbXNnMDAxNDAuaHRtbCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2 N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNM TjRLWk5BJm09WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZzPUd5 OWd5Um9JSXRhLWNTaFY3Yk4xNjFheTR5RTZyOUcxX0FhX05lQm55bGcmZT0+DQoNClRoZSBjb25z ZW5zdXMsIGF0IGxlYXN0IGFzIEkgaW50ZXJwcmV0ZWQgaXQgaXMgdXAgdG8gdGhlIHJlY2VpdmVy IHRvIGZpZ3VyZSB0aGlzIG91dCBiYXNlZCBvbiB0aGUgZGVmaW5pdGlvbnMgaXQgaGFzIGZvciBl YWNoIGV2ZW50IFVSSSBhbmQgdGhlIHByb2ZpbGVzIHRoZXkgcmVwcmVzZW50LiBJT1cgLSBSSVND IGlzIGZyZWUgdG8gbGltaXQgdGhhdCBvbmx5IG9uZSBSSVNDIGV2ZW50IGJlIGV4cHJlc3NlZCBh dCBhIHRpbWUuDQoNClBoaWwNCg0KT3JhY2xlIENvcnBvcmF0aW9uLCBJZGVudGl0eSBDbG91ZCBT ZXJ2aWNlcyBBcmNoaXRlY3QNCg0KQGluZGVwZW5kZW50aWQNCg0Kd3d3LmluZGVwZW5kZW50aWQu Y29tPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193 d3cuaW5kZXBlbmRlbnRpZC5jb20mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhC djdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxj TE40S1pOQSZtPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmcz05 TlA1bmFtZzZySVZ6d3VuOWMtMXEwd2hzeVh3U3Z0SEIwZjJkS2tmQ1g4JmU9PiA8aHR0cDovL3d3 dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cC0zQV9fd3d3LmluZGVwZW5kZW50aWQuY29tJmQ9RHdNRmFRJmM9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBj dHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWli OUtBVGtSbFFHMWl3JnM9OU5QNW5hbWc2cklWend1bjljLTFxMHdoc3lYd1N2dEhCMGYyZEtrZkNY OCZlPT4+DQoNCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv bT4gPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5j b20+Pg0KDQogICAgT24gT2N0IDIzLCAyMDE3LCBhdCA3OjAyIFBNLCBSaWNoYXJkIEJhY2ttYW4s IEFubmFiZWxsZQ0KICAgIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6 b24uY29tPiA8bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpv bi5jb20+Pj4gd3JvdGU6DQoNCiAgICBUaGUgY3VycmVudCBkcmFmdCBvZiB0aGUgU0VUIHNwZWMg YWxsb3dzIGZvciBleHByZXNzaW5nIG11bHRpcGxlDQogICAgZXZlbnRzIHdpdGhpbiB0aGUgc2Ft ZSB0b2tlbiwgd2hpY2ggaW50cm9kdWNlcyBhZGRpdGlvbmFsIGNvbXBsZXhpdHkNCiAgICBhbmQg cm9vbSBmb3IgYW1iaWd1b3VzIHNlbWFudGljcy4gV2XigJl2ZSBkaXNjdXNzZWQgdGhpcyBpbiB0 aGUgT0lERg0KICAgIFJJU0Mgd29ya2luZyBncm91cCBhbmQgdGhlIGN1cnJlbnQgY29uc2Vuc3Vz IHRoZXJlIGlzIHRoYXQgUklTQyB3aWxsDQogICAgcmVxdWlyZSB0aGF0IFJJU0MgZXZlbnRzIG11 c3QgYmUgdGhlIG9ubHkgZXZlbnQgaW4gdGhlIFNFVCwgaGF2aW5nDQogICAgaWRlbnRpZmllZCB3 YXlzIHRvIGNsZWFybHkgYW5kIGVhc2lseSBzdXBwb3J0IHRoZSBoYW5kZnVsIG9mIHVzZQ0KICAg IGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIHRva2VuIHRoYXQgcGVvcGxlIGhhdmUgcmFp c2VkLiBXaXRoDQogICAgdGhhdCBjb250ZXh0IGluIG1pbmQsIEkgcHJvcG9zZSBzdHJpa2luZyB0 aGUgZGVmaW5pdGlvbiBvZiB0aGUNCiAgICDigJxldmVudHPigJ0gY2xhaW0gZnJvbSB0aGUgU2Vj dXJpdHkgRXZlbnQgVG9rZW4gc3BlYywgYW5kIHJlcGxhY2luZyBpdA0KICAgIHdpdGggdGhlIGZv bGxvd2luZyBkZWZpbml0aW9uIGZvciBhbiDigJxldmVudOKAnSBjbGFpbSAoc2luZ3VsYXIpOg0K DQogICAgZXZlbnQNCg0KICAgIEEgSlNPTiBvYmplY3QgY29udGFpbmluZyBhbiAiZXZlbnRfdHlw ZSIgbWVtYmVyIHdob3NlIHZhbHVlIGlzIGEgVVJJDQogICAgcmVwcmVzZW50aW5nIGEgdHlwZSBv ZiBldmVudCBkZWZpbmVkIGluIGEgUHJvZmlsaW5nIFNwZWNpZmljYXRpb24uDQogICAgVGhlIG9i amVjdCBNQVkgb3RoZXJ3aXNlIGJlIGVtcHR5LCBvciBNQVkgY29udGFpbiBhZGRpdGlvbmFsIG1l bWJlcnMNCiAgICBhcyBkZXNjcmliZWQgYnkgdGhlIFByb2ZpbGluZyBTcGVjaWZpY2F0aW9uLg0K DQogICAgSGVyZSBpcyB0aGUgZXhhbXBsZSBTRVQgZnJvbSBzZWN0aW9uIDIuMywgcmV3cml0dGVu IHdpdGggdGhpcyBjaGFuZ2UNCiAgICBtaW5kOg0KDQogICAgew0KDQogICAgICAgImp0aSI6ICI0 ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsDQoNCiAgICAgICAiaWF0IjogMTQ1ODQ5 NjQwNCwNCg0KICAgICAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5jb208aHR0cHM6Ly9z Y2ltLmV4YW1wbGUuY29tLz4gPGh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8+IiwNCg0KICAgICAg ICJhdWQiOiBbDQoNCiAgICAgICAgICJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vRmVlZHMvOThk NTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsDQoNCiAgICAgICAgICJodHRwczovL3NjaW0uZXhhbXBs ZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyINCg0KICAgICAgIF0sDQoNCiAg ICAgICAiZXZlbnQiOiB7DQoNCiAgICAgICAgICJldmVudF90eXBlIjogInVybjppZXRmOnBhcmFt czpzY2ltOmV2ZW50OmNyZWF0ZSIsDQoNCiAgICAgICAgICJyZWYiOiAiaHR0cHM6Ly9zY2ltLmV4 YW1wbGUuY29tL1VzZXJzLzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLA0KDQogICAgICAgICAi YXR0cmlidXRlcyI6IFsiaWQiLCAibmFtZSIsICJ1c2VyTmFtZSIsICJwYXNzd29yZCIsICJlbWFp bHMiXQ0KDQogICAgICAgfQ0KDQogICAgfQ0KDQogICAgRG9lcyBhbnlvbmUgaW4gdGhlIHdvcmtp bmcgZ3JvdXAgaGF2ZSB1c2UgY2FzZXMgZm9yIFNFVHMgdGhhdCBjYW5ub3QNCiAgICBiZSBtZXQg YnkgdGhpcyBwcm9wb3NlZCB0ZXh0PyBXaXRoaW4gUklTQywgd2UgaWRlbnRpZmllZCB0aHJlZSB1 c2UNCiAgICBjYXNlcywgd2l0aCBzb2x1dGlvbnMgb3V0bGluZWQgYmVsb3c6DQoNCiAgICAqKg0K DQogICAgKkV4dGVuc2lvbnMqDQoNCiAgICBFdmVudCBleHRlbnNpb24gbWVjaGFuaXNtcyBjYW4g YmUgZGVmaW5lZCBpbnRlcm5hbCB0byB0aGUgZXZlbnQNCiAgICBvYmplY3QuIEEgc2ltcGxlIGFw cHJvYWNoIHdvdWxkIGJlIHRvICBkZWZpbmUgYW4g4oCcZXh0ZW5zaW9uc+KAnSBtZW1iZXINCiAg ICB0aGF0IGlzIGEgbGlzdCBvZiBldmVudCBvYmplY3RzIChvciBzZXQgcmVzZW1ibGluZyB0aGUg 4oCcZXZlbnRz4oCdDQogICAgY2xhaW0gYXMgZGVmaW5lZCBpbiB0aGUgY3VycmVudCBzcGVjKS4g VGhpcyBoYXMgdGhlIGFkdmFudGFnZSBvZg0KICAgIG1ha2luZyBpdCBjbGVhciBpbiB0aGUgZGF0 YSBzdHJ1Y3R1cmUgdGhhdCB0aGVyZSBpcyBhIHNpbmdsZSBwcmltYXJ5DQogICAgZXZlbnQsIHdp dGggemVybyBvciBtb3JlIGV4dGVuc2lvbnMuIFRoZXJlIGlzIG5vIHJvb20gZm9yIGNvbmZ1c2lv bg0KICAgIG92ZXIgd2hpY2ggZXZlbnQgaXMgcHJpbWFyeSwgb3IgaWYgdGhlcmUgaXMgYSBwcmlt YXJ5IGV2ZW50IGF0IGFsbC4NCiAgICBJIHdvdWxkIGJlIGZpbmUgd2l0aCBhZGRpbmcgc29tZXRo aW5nIGxpa2UgdGhpcyB0byBteSBwcm9wb3NlZCB0ZXh0LA0KICAgIGlmIHRoZXJlIGlzIGNvbnNl bnN1cyB0aGF0IGl0IGlzIGJyb2FkbHkgdXNlZnVsLg0KDQogICAgKkFsaWFzZXMqDQoNCiAgICBU aGlzIHVzZSBjYXNlIHdhcyBicm91Z2h0IHVwIGluIHRoZSBjb250ZXh0IG9mIG1pZ3JhdGluZyBj bGllbnRzDQogICAgZnJvbSBkcmFmdCBldmVudCBuYW1lcyB0byBzdGFuZGFyZGl6ZWQgZXZlbnQg bmFtZXMuIEluIHRoaXMgY2FzZSwNCiAgICB0aGUgZXZlbnQgdHJhbnNtaXR0ZXIgY2FuIHRyYW5z bWl0IHR3byB0b2tlbnMgZm9yIHRoZSBsb2dpY2FsIGV2ZW50LA0KICAgIG9uZSB1c2luZyB0aGUg b2xkIG5hbWUgYW5kIGFub3RoZXIgdXNpbmcgdGhlIG5ldyBuYW1lLg0KDQogICAgKlJlbGF0ZWQg RXZlbnRzKg0KDQogICAgVGhlIFNFVCBzcGVjIGRlZmluZXMgdGhlIHR4biBjbGFpbSBhcyBhIG1l YW5zIG9mIGNvcnJlbGF0aW5nDQogICAgaW5kZXBlbmRlbnQgdG9rZW5zIHRoYXQgcmVsYXRlIHRv IHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQuDQoNCiAgICAtLQ0KICAgIEFubmFiZWxsZSBSaWNoYXJk IEJhY2ttYW4NCg0KICAgIEFtYXpvbiDigJMgSWRlbnRpdHkgU2VydmljZXMNCg0KICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgSWQtZXZlbnQg bWFpbGluZyBsaXN0DQogICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYu b3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4+ DQogICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gw RmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1zNWJ5QmU1S0FObkdWdUFiMW1BdXBFR29K bjhYRzVKSVVVd1dHRlNpYkVjJnM9WDhvUlNxM0l6bEY3amlSQWVaaFhwUjNlVkkwSTU4WkZkNGVF WmZneW9JWSZlPQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRv OklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZC1ldmVudDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01GYVEm Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRX bWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPVlCQ0dsSzltampoY0Zzai0ydERr bjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmcz1Xck11UVJ3TFY4MDJpTVE0d1lCMWYyckZVR3U0emJo Y1cwMDFmSzAyRVhzJmU9Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWls dG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUZh USZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpC VFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09WUJDR2xLOW1qamhjRnNqLTJ0 RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZzPVdyTXVRUndMVjgwMmlNUTR3WUIxZjJyRlVHdTR6 YmhjVzAwMWZLMDJFWHMmZT0+DQoNCg0KDQotLQ0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkU8 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0 d2FyZS5jb21fJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVl YXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1Z QkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JnM9TFlONzJHZ0tWaEhz VDZ0QXFCZS1lTW9XTXZ5XzdkZkZuMXVaMEhLNll1USZlPT4gbWFpbCBsaXN0IHRvIGxlYXJuIGFi b3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGll dGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9faWQtMkRldmVudCZkPUR3SUNBZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1V QjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5B Jm09WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZzPVdyTXVRUndM VjgwMmlNUTR3WUIxZjJyRlVHdTR6YmhjVzAwMWZLMDJFWHMmZT0NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0K SWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQ Wmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJ MWFMY0xONEtaTkEmbT1VLWE1SEJORDBIYVRYNGFuTlpmelg3cERzZks1ZjBoOW1aOUNaa2tHaWVj JnM9cnZkcnRJN3JZTlJBbnFaRGx0Q3dCQVpWSEtwLU1KMjB1aTJubTQ2UVN6MCZlPQ0KDQoNCg0K DQotLQ0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkU8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmQ9RHdNRmFRJmM9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFX Tnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJR UzZsSzY3eUZfOHU4X3FTQ193JnM9d3RnRDNOcDB2eWhMZHBFd1VpcXNmNEl0aXdBM09tN0dyb2I3 MEx4MHIzayZlPT4gbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2lu ZyBvbiENCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJ ZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdt YW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09aXlWbnJabXI5X3VHQ1E2TUQwekYy eW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZzPU9lMHFmTEVYODN2dFhNN1dsMmNZQmUtR2cxRFZQamhY alZKa2ZoVlJ6d2MmZT0NCg0KDQoNCi0tDQpTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRTxodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJl LmNvbV8mZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElf Sm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPXNJR3o4 Z3VyNHdOcVprdGNtYWd2NUVhMjFRRWlwNEhYcEVWS1JhMHFobG8mcz1WOWd5VFRYOXF1anJDMlZs aXdMUHkwLUt2eFM5cFlLSl8ta3lEYXB3TzhrJmU9PiBtYWlsIGxpc3QgdG8gbGVhcm4gYWJvdXQg cHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0KDQoNCg0KLS0NClN1YnNjcmliZSB0byB0aGUgSEFS RFRXQVJFPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNB X19oYXJkdHdhcmUuY29tXyZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJ ck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRL Wk5BJm09c0lHejhndXI0d05xWmt0Y21hZ3Y1RWEyMVFFaXA0SFhwRVZLUmEwcWhsbyZzPVY5Z3lU VFg5cXVqckMyVmxpd0xQeTAtS3Z4UzlwWUtKXy1reURhcHdPOGsmZT0+IG1haWwgbGlzdCB0byBs ZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hDQoNCg0KDQotLQ0KU3Vic2NyaWJl IHRvIHRoZSBIQVJEVFdBUkU8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZ UjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQ a0FJMWFMY0xONEtaTkEmbT1zSUd6OGd1cjR3TnFaa3RjbWFndjVFYTIxUUVpcDRIWHBFVktSYTBx aGxvJnM9VjlneVRUWDlxdWpyQzJWbGl3TFB5MC1LdnhTOXBZS0pfLWt5RGFwd084ayZlPT4gbWFp bCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5n IGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBw dVlxUGtBSTFhTGNMTjRLWk5BJm09c0lHejhndXI0d05xWmt0Y21hZ3Y1RWEyMVFFaXA0SFhwRVZL UmEwcWhsbyZzPWdkTnJzN1VEQXR0cGFiak01bmRPWHdXS21adUthWEViVDV3dTlyY09SVjAmZT0N Cg0K --_000_EFF86A7A874E4D6787A6C95AC93B3FF6amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <21E806B03B44D247BA8B7122D3435019@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCXBh bm9zZS0xOjIgNyAzIDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi Q2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseToiQ291cmllciIsc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1z dHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UN Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4ubS00Mzc3Nzg3 NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAy NjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTpt LTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2 MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1h aWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjI3Njg0MDI3MzsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE5ODY2MTM5NDA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1zdGFydC1hdDozOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDENCgl7bXNvLWxpc3QtaWQ6Mjg0MzExNTMxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTY1 MDk2NjA0NDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDINCgl7bXNvLWxpc3QtaWQ6MTM5MTg4NDk1ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEx NzA1NDkwNzY7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzDQoJe21zby1s aXN0LWlkOjE1ODIzNzU2MjE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjkyODU0NDg1NDt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5QaGlsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbm9ybWF0 aXZlIHRleHQgeW91IHF1b3RlZCBhZGRyZXNzZXMgb25seSBvbmUgZXhhbXBsZSBvZiBvbmUgb2Yg dGhlIGlzc3VlcyBJ4oCZdmUgcmFpc2VkLiBFdmVuIHRoZW4sIEkgZXhwZWN0IHRoaXMgdGV4dCB3 aWxsIGJlIGlnbm9yZWQg4oCTIGludGVudGlvbmFsbHkgb3IgdW5pbnRlbnRpb25hbGx5IOKAkyBi ZWNhdXNlIHRoZSBzdHJ1Y3R1cmUgb2YgYSBTRVQgYXMgaXQgaXMgZGVmaW5lZCBpbiB0aGUgZHJh ZnQgYWxsb3cNCiBmb3IgdGhpcyByZXF1aXJlbWVudCB0byBiZSB2aW9sYXRlZCwgYW5kIHRoZSBp bXBsaWVkIHNlbWFudGljcyBjb250cmFkaWN0IGl0LiBObyBvbmUgd2lsbCBsb29rIGF0IGEgU0VU LCBzZWUgYSBwbHVyYWwg4oCcZXZlbnRz4oCdIG1lbWJlciwgYW5kIHVuZGVyc3RhbmQgdGhhdCBp dCBtZWFucyDigJxtdWx0aXBsZSBldmVudCBzdGF0ZW1lbnRz4oCdIGFuZCBub3Qg4oCcbXVsdGlw bGUgZXZlbnRzLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFRoZXJlIGlzIG5vIHdh eSB0byBhc3N1cmUgdGhhdCBhIHNpbmdsZSByZWNlaXZlciBnZXRzIGFsbCBvZiB0aGUgU0VUcyBp dCBuZWVkcyBpbiBhIG11bHRpLXRocmVhZGVkLCBtdWx0aS1ub2RlIGVudmlyb25tZW50IGF0IHNj YWxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHdoYXQgdGhlIGFja25vd2xlZGdl bWVudCBtZWNoYW5pc21zIGluIHRoZSBkZWxpdmVyeSBzcGVjIGFyZSBmb3IuIFRyYW5zbWl0dGVy cyBjYW4gY29ycmVsYXRlIGFja25vd2xlZGdlbWVudHMgb2YgZGlmZmVyZW50IFNFVHMsIGF0IHNj YWxlIGlmIG5lY2Vzc2FyeS4gSW4gYWxsIHRoZSBTRVQgdXNlIGNhc2VzIHdl4oCZdmUgZGlzY3Vz c2VkLCB0aGUgdm9sdW1lIG9mIFNFVHMgb24gYSBzdHJlYW0gb25seQ0KIHNjYWxlcyB3aXRoIHRo ZSByZWNlaXZlcuKAmXMgYnVzaW5lc3MsIHNvIG9ubHkgcmVjZWl2ZXJzIHdobyBhcmUgYWxyZWFk eSBvcGVyYXRpbmcgYXQgc2NhbGUgbmVlZCB0byBiZSBjYXBhYmxlIG9mIGhhbmRsaW5nIFNFVHMg YXQgc2NhbGUuIElmIHlvdSBkaXNhZ3JlZSwgcGxlYXNlIHByb3ZpZGUgYSBjb3VudGVyZXhhbXBs ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPklkZW50aXR5IFNl cnZpY2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlBoaWwg SHVudCAmbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5l c2RheSwgTm92ZW1iZXIgMSwgMjAxNyBhdCAxMjo0NSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7 UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20m Z3Q7PGJyPg0KPGI+Q2M6IDwvYj5NaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20mZ3Q7LCBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDssIFlhcm9u IFNoZWZmZXIgJmx0O3lhcm9uZi5pZXRmQGdtYWlsLmNvbSZndDssIElEIEV2ZW50cyBNYWlsaW5n IExpc3QgJmx0O2lkLWV2ZW50QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog W0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgY2Fu4oCZ dCByZWFsbHkgaGF2ZSBtdWx0aXBsZSBldmVudHMgKGF0IGxlYXN0IG9mIHRoZSBzYW1lIHR5cGUp LiAmbmJzcDtUaGUgY3VycmVudCBzcGVjIGNhbiBvbmx5IGhhdmUgb25lIGluc3RhbmNlIG9mIGEg VVJJIChhZmFpaykuICZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ob3RlIHRoYXQgdGhlIHNwZWMgbm9ybWF0aXZlbHkgZG9lcyBub3Qgc3VwcG9y dCBtdWx0aXBsZSBldmVudCBTRVRTLiAmbmJzcDtJdCBjdXJyZW50bHkgc3RhdGVzOg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6IHBhZ2UiPmV2ZW50 czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 Yj5UaGUgc2VtYW50aWNzIG9mIHRoaXMgY2xhaW0gaXMgdG8gZGVmaW5lIGEgc2V0IG9mIGV2ZW50 IHN0YXRlbWVudHM8bzpwPjwvbzpwPjwvYj48L3ByZT4NCjxwcmU+PGI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRoYXQgZWFjaCBNQVkgYWRkIGFkZGl0aW9uYWwgY2xhaW1zIHRvIGZ1 bGx5IGRlc2NyaWJlIGEgc2luZ2xlPG86cD48L286cD48L2I+PC9wcmU+DQo8cHJlPjxiPiZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDtsb2dpY2FsIGV2ZW50PC9iPiB0aGF0IGhhcyBvY2N1 cnJlZCAoZS5nLiBhIHN0YXRlIGNoYW5nZSB0byBhPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1YmplY3QpLiZuYnNwOyBNdWx0aXBsZSBldmVu dCBzdGF0ZW1lbnRzIG9mIHRoZSBzYW1lIHR5cGUgU0hBTEwgTk9UIGJlPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFjY2VwdGVkLiZuYnNwOyBU aGUgJnF1b3Q7ZXZlbnRzJnF1b3Q7IGNsYWltIFNIT1VMRCBOT1QgYmUgdXNlZCB0byBleHByZXNz PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG11 bHRpcGxlIGxvZ2ljYWwgZXZlbnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc3BlYyBoYXMgKmFsd2F5cyogc3VwcG9y dGVkIHJlcXVpcmVtZW50cyAoYXMgc3RhdGVkIGluIHRoZSBzcGVjKSBmb3IgbXVsdGlwbGUgc2Vw YXJhdGUgcHJvZmlsZSBzdGF0ZW1lbnRzIChmcm9tIG9uZSBvciBtb3JlIHByb2ZpbGUgZmFtaWxp dGllcykgbmVlZGluZyB0byBiZSBzZW50IGFzIGEgc2luZ2xlIG1lc3NhZ2UuICZuYnNwO0l0IHdv dWxkIGJlIElOU0VDVVJFIHRvIGZvcmNlIG11bHRpcGxlIFNFVHMgYmVjYXVzZQ0KIHRoZSBjdXJy ZW50IGRlbGl2ZXJ5IG1lY2hhbmlzbSBvbmx5IGFsbG93cyBvbmUgU0VUIHRvIGJlIGRlbGl2ZXJl ZCBhdCBhIHRpbWUuIFRoZXJlIGlzIG5vIHdheSB0byBhc3N1cmUgdGhhdCBhIHNpbmdsZSByZWNl aXZlciBnZXRzIGFsbCBvZiB0aGUgU0VUcyBpdCBuZWVkcyBpbiBhIG11bHRpLXRocmVhZGVkLCBt dWx0aS1ub2RlIGVudmlyb25tZW50IGF0IHNjYWxlLiAmbmJzcDtBc3NlbWJsaW5nIG11bHRpcGxl IFNFVHMgdG8gdHJhY2sg4oCcdHhu4oCdIGluIGENCiBjb21tb24gc3RhdGUgZGF0YWJhc2UgaXMg Tk9UIHNpbXBsZSBub3IgY29zdCBlZmZlY3RpdmUuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSBhY2NvbW1vZGF0ZSB0aGlz IGluIHRoZSBwcm9wb3NlZCBmb3JtLCB3ZSBlbmQgdXAgd2l0aCBhIGNvbXBsZXgsIGRlZXBseSBu ZXN0ZWQgSlNPTiBzdHJ1Y3R1cmUgd2l0aCB0aGUgcG9zc2liaWxpdHkgb2YgbmFtZXNwYWNlIGNv bmZsaWN0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SU1PIFRoZSBwcm9wb3NhbCBkb2VzIG5vdCBzaW1wbGlmeSwgaXQgY29tcGxpY2F0aW5n IGFuZCBsaW1pdGluZy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjdXJyZW50IHNwZWMgaGFzIHZlcnkgY2xlYW4gSlNPTiBh bmQgYXZvaWRzIG5hbWVzcGFjZSBjb25mbGljdHMgYmV0d2VlbiBwcm9maWxlcy4gSSB0aGluayB3 ZSBzaG91bGQgc3RheSBvbiB0cmFjayB3aXRoIHRoZSBjdXJyZW50IGRyYWZ0IGFuZCBvYnNlcnZl IHRoZSBub3JtYXRpdmUgdGV4dCBpZiBub3QgbWFrZSBpdCBzdHJvbmdlciBpbiByZWdhcmRzIHRv IG11bHRpLWV2ZW50cyAodW5kZXJzdG9vZCB0aGF0DQogTWlrZSBtYXkgZGlzYWdyZWUpLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QaGlsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5PcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iPnd3dy5p bmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5v diAxLCAyMDE3LCBhdCAxMjoxOCBQTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0Ozxh IGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj5yaWNoYW5uYUBhbWF6b24uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+VW5sZXNzIHRoZSBwcm9maWxlIGd1YXJhbnRlZXMg dGhhdCBzdWNoIHJlbGF0ZWQgZXZlbnRzIHdpbGwgYWx3YXlzIGJlIGluY2x1ZGVkIGluIHRoZSBz YW1lIFNFVCwgdGhlbiB0aGUgcmVjZWl2ZXIgaGFzIHRvIGNvcnJlbGF0ZSBhY3Jvc3MgU0VUcyBh bnl3YXksIGFuZCBtdWx0aXBsZSBldmVudHMgcGVyIFNFVCBpcyBqdXN0IGdpdmluZyB0aGUgcmVj ZWl2ZXIgYW5vdGhlcg0KIHNjZW5hcmlvIHRoYXQgdGhleSBoYXZlIHRvIHN1cHBvcnQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SeKAmXZlIGFscmVhZHkg cHJvdmlkZWQgc2V2ZXJhbCBvdGhlciByZWFzb25zIHdoeSB3ZSBzaG91bGQgbm90IHN1cHBvcnQg bXVsdGlwbGUgdG9rZW5zIHBlciBTRVQgdGhhdCBubyBvbmUgaGFzIGFkZHJlc3NlZC4gSGVyZSB0 aGV5IGFyZSBhZ2Fpbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPG9sIHN0eWxlPSJtYXJnaW4t dG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0 ZSI+DQpNdWx0aXBsZSBldmVudCBzdXBwb3J0IHJlc3VsdHMgaW4gYSBtb3JlIGNvbXBsZXggc3Ry dWN0dXJlIGZvciB0aGUgc2luZ2xlIGV2ZW50IHVzZSBjYXNlLCB3aGljaCBJIHRoaW5rIHdlIGFs bCBhZ3JlZSBpcyB0aGUgbWFqb3JpdHkgdXNlIGNhc2UuPG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBs Zm8xO2JhY2tncm91bmQ6d2hpdGUiPg0KTXVsdGlwbGUtZXZlbnQgU0VUcyBoYXZlIGFtYmlndW91 cyBzZW1hbnRpY3MuIFRoZSBwcmVzZW5jZSBvZiB0d28gZXZlbnRzIEEgYW5kIEIgaW4gdGhlIHNh bWUgU0VUIGNvdWxkIG1lYW4gYW55IG9mOg0KPG86cD48L286cD48L2xpPjwvb2w+DQo8b2wgc3R5 bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMiIgdHlwZT0iMSI+DQo8b2wgc3R5bGU9Im1hcmdp bi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDIgbGZvMTtiYWNrZ3JvdW5kOndo aXRlIj4NCkEgYW5kIEIgYXJlIHJlbGF0ZWQgdG8gdGhlIHNhbWUgbG9naWNhbCBldmVudCAoaS5l LiB0aGUgc2FtZSB0aGluZyBhcyBpZiB0aGV5IHdlcmUgZnJvbSBkaWZmZXJlbnQgU0VUcyB0aGF0 IGhhdmUgYSBjb21tb24gdHhuKS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzE7YmFja2dyb3Vu ZDp3aGl0ZSI+DQpBIGlzIGFuIGV4dGVuc2lvbiBvZiBCLjxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDIg bGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4NCkIgaXMgYW4gZXh0ZW5zaW9uIG9mIEEuPG86cD48L286 cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwyIGxldmVsMiBsZm8xO2JhY2tncm91bmQ6d2hpdGUiPg0KQSBpcyBhbiBhbGlhcyBmb3Ig Qiwgb3IgdmljZS12ZXJzYS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzE7YmFja2dyb3VuZDp3 aGl0ZSI+DQpBIGFuZCBCIGFyZSBub3QgYWN0dWFsbHkgcmVsYXRlZCB0byBvbmUgYW5vdGhlciBp biBhbnkgd2F5LCBhbmQgdGhlIHRyYW5zbWl0dGVyIGJ1bmRsZWQgdGhlbSB0b2dldGhlciBiZWNh dXNlIHRoZXkgd2VyZSBnb2luZyB0byB0aGUgc2FtZSByZWNlaXZlci48bzpwPjwvbzpwPjwvbGk+ PC9vbD4NCjwvb2w+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMyIgdHlwZT0i MSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsMiBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4NClRvcC1sZXZlbCBjbGFpbSBzZW1h bnRpY3MgYmVjb21lIGhhcmRlciB0byBkZWZpbmUsIGFzIGRpZmZlcmVudCBwcm9maWxlcyBtYXkg d2FudCB0byB1c2UgdGhlIHNhbWUgY2xhaW1zIGluIGRpZmZlcmVudCB3YXlzLjxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsMiBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4NCkV2ZW50IGF1dGhlbnRpY2l0eSBj YW5ub3QgYmUgdmVyaWZpZWQgd2l0aG91dCBoYXZpbmcgdGhlIGVudGlyZSBTRVQuIFRoaXMgZm9y Y2VzIHJlY2VpdmVycyB0byBleHBvc2UgZG93bnN0cmVhbSBzeXN0ZW1zIHRvIG1vcmUgaW5mb3Jt YXRpb24gbmVjZXNzYXJ5LCBpZiB0aG9zZSBzeXN0ZW1zIG5lZWQgdG8gYmUgYWJsZSB0byB2ZXJp ZnkgYXV0aGVudGljaXR5LjxvOnA+PC9vOnA+PC9saT48L29sPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5BbWF6b24g4oCT IElkZW50aXR5IFNlcnZpY2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkZy b206PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk1pa2UgSm9uZXMgJmx0OzxhIGhy ZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPldlZG5lc2RheSwgTm92ZW1iZXIgMSwgMjAxNyBh dCAxMToyMSBBTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L2I+RGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFy ZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5ZYXJvbiBT aGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIj55YXJvbmYu aWV0ZkBnbWFpbC5jb208L2E+Jmd0OywgJnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUm cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj5yaWNoYW5uYUBh bWF6b24uY29tPC9hPiZndDssIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1h aWx0bzppZC1ldmVudEBpZXRmLm9yZyI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVv dDtQaGlsIEh1bnQgKElETSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SRTogW0lk LWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGNvbXBsZXRlbHkgYWdyZWUg b24gbW92aW5nIGNvbXBsZXhpdHkgdG8gdGhlIGlzc3VlciBvdmVyIHRoZSByZWNpcGllbnQuJm5i c3A7IEluIG15IHZpZXcsIGl04oCZcyBtb3JlIGNvbXBsZXggZm9yIHJlY2lwaWVudHMgdG8gaGF2 ZSB0byBjb3JyZWxhdGUgYW5kIHByb2Nlc3MgYSBzZXF1ZW5jZSBvZiBtdWx0aXBsZSBTRVRzIHBy b3ZpZGluZw0KIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQsIGFuZCB2 YWxpZGF0ZSBOIHNpZ25hdHVyZXMsIHRoYW4gdG8gcmVjZWl2ZSBvbmUgU0VUIHdpdGggYWxsIHRo ZSBhc3BlY3RzIG9mIHRoZSBsb2dpY2FsIGV2ZW50IGFzIOKAnGV2ZW50c+KAnSBmaWVsZHMsIHdp dGggbm8gY29ycmVsYXRpb24gb3ZlciB0aW1lIHRoZW4gcmVxdWlyZWQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+RnJvbTo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkRpY2sgSGFyZHQg WzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+bWFpbHRvOmRpY2suaGFyZHRA Z21haWwuY29tPC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPldlZG5lc2RheSwgTm92ZW1iZXIgMSwgMjAxNyA5OjM5IEFNPGJyPg0K PGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5NaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+WWFyb24gU2hl ZmZlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSI+eWFyb25mLmll dGZAZ21haWwuY29tPC9hPiZndDs7IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBo cmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4m Z3Q7OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRA aWV0Zi5vcmciPmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDs7DQogUGhpbCBIdW50IChJRE0pICZs dDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUu Y29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0 aXBsZSBldmVudHMgcGVyIFNFVD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPllvdXIgY29tbWVudHMgaGlnaGxpZ2h0IGEgY291cGxl IG9mIHBvaW50czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4xKSBUaGUgZXhhbXBsZSBpcyBob3cgdG8g aGF2ZSBhIHByZWRlZmluZWQgZXh0ZW5zaW9uIHBvaW50IGZvciBleHRlbnNpb25zIG9mIGEgc3Bl Y2lmaWMgZXZlbnQsIGl0IGlzIG5vdCBob3cgdG8gYWRkIGFub3RoZXIgZXZlbnQuIE15c2VsZiwg SSB0aGluayB0aGlzIGlzIG92ZXJseSBjb21wbGljYXRlZC4gRXZlbnRzIHNob3VsZCBiZSBjb21w YXJhdGl2ZWx5IHN0YXRpYywNCiBhbmQgYXMgd2l0aCBtYW55IG90aGVyIEpTT04gZm9ybWF0cywg dGhlIHJlY2VpdmVyIHNob3VsZCBpZ25vcmUgcHJvcGVydGllcyBpdCBkb2VzIG5vdCB1bmRlcnN0 YW5kLCB3aGljaCBsZXQncyBuZXcgcHJvcGVydGllcyBiZSBpbnRyb2R1Y2VkIGFzIGV4dGVuc2lv bnMuIFRoZXJlIHNob3VsZCBub3QgYmUgYW55IGNvbmZsaWN0IGFzIGV4dGVuc2lvbnMgc2hvdWxk IG9ubHkgYmUgZG9uZSBieSB0aGUgcHJvZmlsZSB0aGF0IGNyZWF0ZWQgdGhlIGV2ZW50DQogZm9y bWF0IHRvIHN0YXJ0IG9mZiB3aXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjIpIEhhdmluZyBhbiBs dmFsdWUgYmUgYSBVUkkgaXMgbXVjaCBoYXJkZXIgdG8gY29kZSBhZ2FpbnN0LiBJJ20gbm90IHN1 cmUgd2h5IE1hcml1cyBoYWQgdGhhdCBpbiBoaXMgZXhhbXBsZS4gUGVyIHRoZSBldmVudCwgdGhl IHR5cGUgb2YgdGhlIGV2ZW50IGlzIHdlbGwgZGVmaW5lZCB3aXRoJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNTAwMDUwIj4mcXVvdDtldmVudF90eXBlJnF1 b3Q7OiAmcXVvdDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50 L3Bhc3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOnB1 cnBsZSI+aHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQ8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzUwMDA1MCI+JnF1b3Q7LDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+MykgVGhpcyB0aHJlYWQgaXMgYWJvdXQgcmVhc29ucyBmb3Ig bXVsdGlwbGUgZXZlbnRzIHRvIGJlIGNvbnRhaW5lZCBpbiBvbmUgc2V0LiBZb3VyIG1lbnRpb24g b2YgYW4gaXNzdWVyIG5vdCB3YW50aW5nIHRvIHNpZ24gc2VwYXJhdGUgZXZlbnRzIGFzIGEgcmVh c29uIHRvIGFsbG93IG11bHRpcGxlIGV2ZW50cy4gSSB0aGluayB3ZSBoYXZlIGRlY2lkZWQgdGhh dCBnaXZlbg0KIGEgcHJlZmVyZW5jZSwgd2Ugd2lsbCBwdXNoIGVmZm9ydCB0byB0aGUgdHJhbnNt aXR0ZXIgb3ZlciB0aGUgcmVjZWl2ZXIgYXMgaW4gbWFueSB1c2UgY2FzZXMgdGhlcmUgYXJlIG1h bnkgbW9yZSByZWNlaXZlcnMuIEdpdmVuIHRoYXQsIGl0IGlzIG1vcmUgY29tcGxleCBmb3IgYSBy ZWNlaXZlciB0byBoYXZlIGRpZmZlcmVudCB3YXlzIG9mIG1hbmFnaW5nIHRoZSByZWNlaXB0IG9m IG11bHRpcGxlIGV2ZW50cyBhcyBub3QgYWxsIGlzc3VlcnMgd2lsbA0KIGJ1bmRsZSB0aGUgZXZl bnRzLCBzbyBpdCBpcyBzaW1wbGVyIHRvIGhhdmUgb25seSBvbmUgZXZlbnQgcGVyIFNFVC4gSW5j bHVkaW5nIHRoZSBzZXBhcmF0ZSBldmVudHMgd2l0aCBhIFVSSSBhcyBhbiBsdmFsdWUgaXMgY2hh bGxlbmdpbmcgdG8gaW1wbGVtZW50LCBzcGVha2luZyBmcm9tIGV4cGVyaWVuY2UuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj5PbiBUdWUsIE9jdCAzMSwgMjAxNyBhdCAxMTowNSBQTSwgTWlrZSBKb25lcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPk1hcml1c+KAmSBwcm9wb3NlZCBzeW50YXgsIHBhc3Rl ZCBpbiBiZWxvdywgaGFzIGV4YWN0bHkgdGhpcyBjaGFyYWN0ZXJpc3RpYy4mbmJzcDsgVGhlIHdh eSBJIHNlZSBpdCwgaGlzIHByb3Bvc2FsIGVzc2VudGlhbGx5IGhhcyBhIHByaW1hcnkgcGFzc3dv cmRSZXNldCBldmVudCBhbmQgYSBzZWNvbmRhcnkgcGFzc3dvcmRSZXNldEV4dA0KIGRhdGEgc3Ry dWN0dXJlLCB3aGljaCBjb3VsZCBoYXZlIGJlZW4gc2ltcGx5IGFub3RoZXIgZXZlbnQgdmFsdWUg aW4gdGhlIGN1cnJlbnQgZHJhZnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoaXMgYnJlYWtpbmcgY2hhbmdlIG1ha2VzIHRoZSBk YXRhIHN0cnVjdHVyZXMgbW9yZSBjb21wbGljYXRlZCAtIG5vdCBsZXNzLiZuYnNwOyBBbmQgaXQg bWFrZXMgdGhpbmdzIHRoYXQgdXNlZCB0byBiZSBwb3NzaWJsZSBpbXBvc3NpYmxlLCByZWR1Y2lu ZyBmbGV4aWJpbGl0eSB0byB0aG9zZSB3aG8gd291bGQgdXNlIHRoZSBzcGVjLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGVzZSBz ZWVtIGxpa2UgYmFkIHRyYWRlb2ZmcyB0byBtZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj57PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss c2VyaWYiPiZuYnNwOyAmcXVvdDtqdGkmcXVvdDs6ICZxdW90OzNkMGMzY2Y3OTc1ODRiZDE5M2Jk MGZiMWJkNGU3ZDMwJnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmIj4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OiAxNDU4NDk2MDI1LDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8 YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPC9zcGFuPjwvYT4m cXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAm cXVvdDthdWQmcXVvdDs6IFs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJp ZiI+Jm5ic3A7ICZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20v RmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2 MWZhNWJiYzg3OTU5M2I3NzU0PC9zcGFuPjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6 Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2podWIuZXhhbXBs ZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNzwvc3Bhbj48L2E+JnF1b3Q7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDtdLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7JnF1 b3Q7ZXZlbnRfdHlwZSZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9z Y2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNl dEV4dDwvc3Bhbj48L2E+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmIj4mbmJzcDsgJm5ic3A7JnF1b3Q7ZXZlbnQmcXVvdDs6IHsmbmJzcDsmbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZxdW90O2lkJnF1b3Q7OiZxdW90OzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3 NTIxZDkmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtleHRlbnNpb25zJnF1b3Q7OiB7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxl LmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dv cmRSZXNldEV4dDwvc3Bhbj48L2E+4oCdOg0KIHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7JnF1b3Q7cmVzZXRBdHRlbXB0cyZxdW90Ozo1LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO308L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj59PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkluIHBhcnRpY3VsYXIsIGl0IG1ha2VzIGl0 IGltcG9zc2libGUgdG8gc2lnbiBtdWx0aXBsZSByZWxhdGVkIGV2ZW50cyBzaGFyaW5nIGEgY29t bW9uIGNsYWltcyBzY2hlbWEgd2l0aCBhIHNpbmdsZSBzaWduYXR1cmUgYnkgdGhlIGlzc3Vlci4m bmJzcDsgSXQgZm9yY2VzIHRoZSBpc3N1ZXIgdG8gZG8gdGhlIGV4dHJhIHdvcmsNCiBvZiBzaWdu aW5nIGVhY2ggb2YgdGhlIHJlbGF0ZWQgZXZlbnRzIChvciBmYWNldHMgb2YgdGhlIHNhbWUgbG9n aWNhbCBldmVudCkgaW5kaXZpZHVhbGx5IGFuZCBmb3JjZXMgdGhlIHJlY2lwaWVudHMgdG8gZG8g dGhlIGV4dHJhIHdvcmsgb2YgY2hlY2tpbmcgYWxsIHRob3NlIHVubmVjZXNzYXJ5IHNpZ25hdHVy ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPk5vdCBldmVyeSBwcm9maWxlIHdpbGwgZXZlciBoYXZlIG11bHRpcGxlIGtleXMgaW4g dGhlIOKAnGV2ZW50c+KAnSBzZXQgYnV0IHRoZXJl4oCZcyBhYnNvbHV0ZWx5IG5vIHJlYXNvbiB0 byBwcmVjbHVkZSBpdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEgbmFtZT0ibV8tNDM3Nzc4Nzc1 NTg3MzIwODkzNV9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4m bmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPkZyb206PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5JZC1ldmVudCBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwv c3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48Yj5Pbg0KIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L2I+RGljayBIYXJkdDxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBPY3RvYmVyIDMxLCAy MDE3IDk6NTIgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPk1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pllhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj55YXJvbmYuaWV0ZkBn bWFpbC5jb208L3NwYW4+PC9hPiZndDs7IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8 YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPiZndDs7 DQogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZl bnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs7IFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPiZndDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW0lkLWV2ZW50XSBV c2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj5QbGVhc2UgZGlyZWN0IG1lIHRvIGEgcHJvcG9zYWwgdGhhdCBoYXMgYSAmcXVvdDtw cmltYXJ5JnF1b3Q7IGFuZCAmcXVvdDtzZWNvbmRhcnkmcXVvdDsgZXZlbnRzLiBJIGFncmVlIHRo YXQgaXMgdW5kZXNpcmFibGUuIEkgd291bGQgYWxzbyBlbmNvdXJhZ2UgdG8gZW5nYWdlIGluIHRo ZSBkaXNjdXNzaW9ucyBzbyB0aGF0IHdlIGNhbiBkcml2ZSBjbGFyaXR5IGFuZCBzaW1wbGljaXR5 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj5JIHRoaW5rIHRoZSBwcm9wb3NhbCBpcyB0aGF0IHRoZXJlIGlzIG9uZSBl dmVudCBwZXIgU0VULjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkkgdGhpbmsgaGF2aW5nIG1vcmUgdGhh biBvbmUgZXZlbnQgcGVyIFNFVCBhZGRzIGNvbXBsZXhpdHkgYXMgYSByZWNlaXZlciBtdXN0IGRl YWwgd2l0aCByZWNlaXZpbmcgY29ycmVsYXRlZCBldmVudHMgaW4gb25lIFNFVCBhcyB3ZWxsIGFz IGNvcnJlbGF0ZWQgZXZlbnRzIGluIHRoZSBzYW1lIFNFVC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4v RGljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9uIFR1ZSwgT2N0IDMxLCAyMDE3IGF0IDk6NDIgUE0s IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGhlYXIgeW91IG9uIHRoZSBm YWN0IHRoYXQgZGlmZmVyZW50IHBlb3BsZSBoYXZlIGpvaW5lZCB0aGUgZWZmb3J0IGF0IGRpZmZl cmVudCB0aW1lcy4mbmJzcDsgVGhhdOKAmXMgYSBub3JtYWwgcHJvY2VzcyBhcyBhbiBlZmZvcnQg YnVpbGRzIG1vbWVudHVtLiZuYnNwOyBJIGdldCB0aGF0IG5vdCBldmVyeW9uZSB3YXMgdGhlcmUg d2hlbg0KIHByZXZpb3VzIGNvbnNlbnN1cyBjYWxscyB3ZXJlIHRha2VuLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIHNob3VsZCBu b3RlIHRoYXQgSSBoYXZlIHNwZWNpZmljIHRlY2huaWNhbCBvYmplY3Rpb25zIHRvIHRoZSBzcGVj aWZpYyBwcm9wb3NlZCBjaGFuZ2VzIGJlaW5nIGRpc2N1c3NlZCBhcyB3ZWxsLiZuYnNwOyBDdXJy ZW50bHkgYWxsIGV2ZW50cyBpbiB0aGUgc2V0IGhhdmUgdGhlIHNhbWUgc3ludGF4LiZuYnNwOyBU aGUgcHJvcG9zYWxzLA0KIGFzIEkgdW5kZXJzdGFuZCB0aGVtLCByZXZlcnQgdXMgdG8gYSBzdGF0 ZSB3aGVyZSB0aGVyZeKAmXMgYSDigJxwcmltYXJ54oCdIGFuZCDigJxzZWNvbmRhcnnigJ0gZXZl bnRzLCB3aXRoIGRpZmZlcmVudCBzeW50YXggZm9yIHRoZSB0d28gY2xhc3Nlcy4mbmJzcDsgVGhh dOKAmXMgbmVlZGxlc3NseSBtb3JlIGNvbXBsaWNhdGVkLCBhZGRpbmcgbm8gYWN0dWFsIHZhbHVl Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPkZyb206PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5EaWNrIEhhcmR0IFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+ZGljay5oYXJkdEBnbWFpbC5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXks IE9jdG9iZXIgMzEsIDIwMTcgOTozNyBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0i bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvc3Bhbj48 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+UGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0OzsgWWFyb24gU2hlZmZlciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+ Jmd0OzsNCiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJp Y2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5yaWNoYW5uYUBhbWF6b24uY29tPC9zcGFuPjwvYT4mZ3Q7OyBJRCBFdmVudHMgTWFpbGlu ZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48 L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGJyPg0KPGI+U3ViamVj dDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJl OiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQ/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPk1pa2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+QXMgeW91IHdlbGwga25vdywg bWFueSBwZW9wbGUgaW4gYSBXRyBkb24ndCBsb29rIGNsb3NlbHkgYXQgYSBzcGVjaWZpY2F0aW9u IHVudGlsIGxhc3QgY2FsbCBpcyBtYWRlLiBBZGRpdGlvbmFsbHksIHdlIGFyZSBjb21pbmcgdXAg b24gb25seSB0aGUgM3JkIFdHIG1lZXRpbmcuIFRoZSBXRyBoYXMgbm90IGV4aXN0ZWQgZm9yIHZl cnkgbG9uZy4gV2hpbGUgc29tZSBvZg0KIHRoZSBwYXJ0aWNpcGFudHMgaGF2ZSBiZWVuIHdvcmtp bmcgb24gdGhpcyBmb3IgYSB3aGlsZSwgbWFueSBoYXZlIG5vdCwgYW5kIHdlIGFyZSBsb29raW5n IGZvciBjb25zZW5zdXMgYWNyb3NzIHRoZSBXRy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5TaW5jZSBT ZWNFdmVudCBpcyBhIGZyYW1ld29yayB0aGF0IHdlIGV4cGVjdCB0byBiZSBwcm9maWxlZCwgSSBm ZWVsIGl0IGlzIGltcG9ydGFudCB0byBlbnN1cmUgdGhhdCBTZWNFdmVudCBzcGVjaWZpY2F0aW9u cyBhcmUgZWFzeSBmb3IgYSB2YXJpZXR5IG9mIHByb2ZpbGVzIHRvIGFkb3B0LCBhbmQgdGhhdCB0 aGUgc2VtYW50aWNzIG1ha2Ugc2Vuc2UuIEkgYWxzbyB0aGluaw0KIHRoYXQgcHJvcGVydGllcyB0 aGF0IGFyZSBzcGVjaWZpYyB0byBhIHByb2ZpbGUgc2hvdWxkIGJlIGxlZnQgdG8gdGhhdCBwcm9m aWxlIGFuZCBub3QgYmUgaW5jbHVkZWQgaW4gU2VjRXZlbnQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ U2luY2UgdGhpcyBpcyBhIGZyYW1ld29yaywgaXQgaXMgZXhwZWN0ZWQgdGhhdCBhcyBkaWZmZXJl bnQgZ3JvdXBzIHByb2ZpbGUgaXQsIHRoZXJlIHdpbGwgYmUgYWRkaXRpb25hbCBmZWVkYmFjay48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj5TcGVjaWZpY2FsbHksIGFzIGEgcGFydGljaXBhbnQgaW4gdGhl IFJJU0MgcHJvZmlsZSBvZiBTRVQsIGEgbnVtYmVyIG9mIGlzc3VlcyBpbiBTRVQgaGF2ZSBzdXJm YWNlZCBhcyB0aGUgUklTQyBXRyBoYXMgbG9va2VkIGF0IGhvdyB0byB1c2UgdGhlIFNFVC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj5BcyBmb3IgU0VUIGJlaW5nIHN0YWJsZSBmb3Igb3ZlciBhIHllYXIs IHRoZXJlIGhhdmUgYmVlbiBhIG51bWJlciBvZiBjaGFuZ2VzIHRvIFNFVCBzaW5jZSB0aGVuLiBJ IGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgd2FzIGNvbnNlbnN1cy4gQmVmb3JlIHRoZSBXRyB3YXMg Zm9ybWVkLCBJIGFuZCBzZXZlcmFsIG90aGVycyBoYWQgZXhwcmVzc2VkIGNvbmNlcm4gb24gdGhl DQogZGVzaWduIG9mIFNFVCB3aGVuIFBoaWwgcHJlc2VudGVkIGl0IGF0IGFuIElJVyBzZXNzaW9u LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPkFzIHRvIHRha2luZyBhbm90aGVyIHllYXIsIEkgYW0gaG9w ZWZ1bCB3ZSBjYW4gcmVzb2x2ZSB0aGUgcmVtYWluaW5nIGlzc3VlcyBpbiBTRVQgYW5kIHB1Ymxp c2ggYSBuZXcgZHJhZnQgZm9yIGxhc3QgY2FsbC4gSSBkbyBub3QgdGhpbmsgd2Ugd2lsbCBuZWVk IHRvIHdhaXQgZm9yIGFub3RoZXIgV0cgbWVldGluZyB0byBhc2sgZm9yIGxhc3QgY2FsbC4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5XZSBhbHNvIGhhdmUgYSBudW1iZXIgb2Ygb3RoZXIgZG9j dW1lbnRzIHRoYXQgYXJlIG5vdCBpbiBsYXN0IGNhbGwsIGFuZCB3ZSBkb24ndCBoYXZlIGEgV0cg YWRvcHRlZCBkcmFmdCB5ZXQgZm9yIG1hbmFnZW1lbnQuIFNvIHRoZXJlIGFyZSBzdGlsbCBhIG51 bWJlciBvZiBkb2N1bWVudHMgdG8gd29yayB0aHJvdWdoIGJlZm9yZSB3ZSBoYXZlIGFsbCB0aGUg Yml0cyBmb3INCiBzb21lb25lIHRvIHdvcmsgd2l0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JIGRv IHRoaW5rIHdlIGhhdmUgYmVlbiBtYWtpbmcgZ29vZCBwcm9ncmVzcyBzaW5jZSB0aGUgbGFzdCBJ RVRGIG1lZXRpbmcsIGFuZCBJIGFtIGhvcGVmdWwgd2UgY2FuIGtlZXAgdXAgdGhpcyBtb21lbnR1 bSBhbmQgZmluYWxpemUgYWxsIHRoZSBkb2N1bWVudHMgaW4gYSB0aW1lbHkgbWFubmVyLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPi9EaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+T24gVHVlLCBPY3QgMzEsIDIwMTcgYXQgMTI6NDgg UE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JdOKAmXMgaGFyZCBmb3Ig bWUgdG8gZXZlbiBleHByZXNzIG15IGxldmVsIG9mIGZydXN0cmF0aW9uIHdpdGggdGhlIHJlY2Vu dCBhdHRlbXB0cyB0byBvbmNlIGFnYWluIHJlZGVzaWduIHRoZSBTZWNFdmVudCBUb2tlbiBzcGVj LiZuYnNwOyBXZeKAmXZlIGJlZW4gYXQgdGhpcyBmb3IgbXVsdGlwbGUgeWVhcnMgYmVjYXVzZSBw ZW9wbGUNCiBrZWVwIHRyeWluZyB0byByZXZpc2l0IGRlY2lzaW9ucyB0aGF0IHdlcmUgbG9uZyBh Z28gbWFkZSBieSBjb25zZW5zdXMuJm5ic3A7IEl04oCZcyBiZWVuIHN0YWJsZSBmb3Igb3ZlciBh IHllYXIgYW5kIHRoZSBtYWpvcml0eSBvZiBXR0xDIHJlc3BvbmRlbnRzIHNhaWQgc29tZSB2YXJp YW50IG9mIOKAnFdvcmtzIGZvciBtZSDigJMgc2hpcCBpdCHigJ08L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhlcmXigJlzIG5vdCBz dWZmaWNpZW50IGp1c3RpZmljYXRpb24gdG8gdHJ5IHRvIHVuZG8gY29uc2Vuc3VzIHBvc2l0aW9u cyB0aGF0IGhhdmUgYmVlbiBkZWJhdGVkIGFuZCBhZmZpcm1lZCBvdmVyIGFuZCBvdmVyLiZuYnNw OyBDb3VudGVuYW5jaW5nIHdob2xlc2FsZSBjaGFuZ2VzIGF0IHRoaXMgbGF0ZSBkYXRlIGlzIGNv dW50ZXJwcm9kdWN0aXZlDQogaW4gdGhlIGV4dHJlbWUhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkl04oCZcyBmYXIgYmV0dGVyIHRo YW4gZ29vZCBlbm91Z2ggYXMtaXMuJm5ic3A7IEluIG15IGV4cGVyaWVuY2UsIGlmIHdlIHN0YXJ0 IHJlZGVzaWduaW5nIGl0LCBpdCB3aWxsIHJlc3VsdCBpbiBhbm90aGVyIHllYXLigJlzIGRlbGF5 LiZuYnNwOyBJdCBkb2VzIHNvbWV0aGluZyBzaW1wbGUgYW5kIHVzZWZ1bC4mbmJzcDsgUGxlYXNl LCBsZXTigJlzIGp1c3QNCiBzaGlwIGl0LCBzbyBwZW9wbGUgY2FuIHJlbHkgb24gaXQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxhIG5hbWU9Im1fLTQzNzc3ODc3NTU4NzMyMDg5MzVfbV8tNTAxMzg1 NDg2MTQxMDIiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj5G cm9tOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ UGhpbCBIdW50IChJRE0pIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50 QG9yYWNsZS5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1vbmRheSwgT2N0b2JlciAzMCwgMjAxNyAyOjQyIFBN PGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5EaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaWNrLmhhcmR0 QGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+WWFyb24gU2hlZmZlciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0Ozsg UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBh bWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cmlj aGFubmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+Jmd0OzsNCiBNaWtlIEpvbmVzICZsdDs8YSBocmVm PSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9zcGFu PjwvYT4mZ3Q7OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQt ZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5pZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVs dGlwbGUgZXZlbnRzIHBlciBTRVQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj5JbmxpbmUuLi48YnI+DQo8YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48YnI+DQpPbiBPY3QgMzAsIDIwMTcsIGF0IDI6MjIg UE0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRpY2suaGFyZHRAZ21h aWwuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj5IaSBQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkNvcnJlY3QgbWUgaWYgSSBhbSBtaXN1bmRlcnN0 YW5kaW5nLCBidXQgdGhlcmUgaXMgYSBSSVNDIHByb2ZpbGUgZXZlbnQmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTMuNXB0Ij4mcXVvdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVuaWQubmV0X3NlY2V2ZW50X3Jp c2NfZXZlbnQtMkR0eXBlXy0yNTVDJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlY UHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2 N3lGXzh1OF9xU0NfdyZhbXA7cz0yNWwwOXNIOFlWNDJ4emdVLUNYU2c4eEg5dHZ5REp6NDB0Q1Jq RmFsaGt3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pmh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlLzwvc3Bh bj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+YWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1 aXJlZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj7igJ08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPmFuZCBhbiBTQ0lNIHByb2ZpbGUgZXZlbnQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTt3aGl0ZS1z cGFjZTpwcmUtd3JhcCI+JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2 ZW50L3Bhc3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwv c3Bhbj48L2E+4oCdPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPkknbSBzdWdnZXN0aW5nIHRoYXQgdHdvIGRpZmZlcmVudCBldmVudHMgd291bGQgYmUgc2Vu dC4gRW1iZWRkaW5nIG9uZSBpbiB0aGUgb3RoZXIgZG9lcyBub3QgbWFrZSBzZW5zZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbHQ7 cGgmZ3Q7SXQgaXMgYSBoeXBvdGhldGljYWwgZXhhbXBsZS4gSnVzdCBiZWNhdXNlIHlvdSBkaXNh Z3JlZSBvbiB0aGlzIGRvZXMgbm90IG1lYW4gb3RoZXJzIGFyZSBub3QgdmFsaWQuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPkkganVzdCBwaWNrZWQgb3ZlcmxhcHBpbmcgcHJvcG9zYWxzIHRoYXQgaGF2ZSBk aWZmZXJlbnQgbWVhbmluZyAoYnV0IG5vdCB0aGUgc2FtZSkgdG8gaWxsdXN0cmF0ZSB0aGUgZGlm ZmVyZW5jZSBmcm9tIGlzc3VpbmcgYSBzaW5nbGUgc2V0IHdpdGggZGlmZmVyZW50IGV2ZW50cy4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPkFzIEkgaGF2ZSBzdGF0ZWQg dGhpcyBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIGFzc2VydGluZyBtdWx0aXBsZSBkaXN0aW5jdCBl dmVudHMgaW4gb25lIFNFVC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5BbHNvLCBJIHRoaW5r IGl0IGlzIHNpbXBsZXIgdG8gaGF2ZSBldmVudF90eXBlIGJlIGF0IHRoZSBzYW1lIGxldmVsIGFz IGV2ZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5k OndoaXRlIj4mbHQ7cGgmZ3Q7bWF5IGJlLiBJIHdhcyB3b3JraW5nIGZyb20gQW5uYWJlbGxlJ3Mg cHJvcG9zZWQgZm9ybWF0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPns8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7anRpJnF1b3Q7 OiAmcXVvdDszZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90Oyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OiAx NDU4NDk2MDI1LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNw OyAmcXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNv bS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3Nj aW0uZXhhbXBsZS5jb208L3NwYW4+PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiBbPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmcXVvdDs8YSBocmVmPSJo dHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5l eGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0PC9zcGFuPjwvYT4mcXVv dDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNw OyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2 YjFkMDg2NDFkNzY3NmVlNyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2 ZWU3PC9zcGFuPjwvYT4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmIj4mbmJzcDsgJm5ic3A7XSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmIj4mbmJzcDsgJm5ic3A7JnF1b3Q7ZXZlbnRfdHlwZSZxdW90OzogJnF1b3Q7PGEgaHJlZj0i aHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2V4YW1wbGUuY29tL3Nj aW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwvc3Bhbj48L2E+JnF1b3Q7LDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsmcXVvdDtldmVudCZxdW90 OzogeyZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtpZCZxdW90OzomcXVvdDs0 NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDty ZXNldEF0dGVtcHRzJnF1b3Q7OjU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyxzZXJpZiI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPns8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7anRpJnF1b3Q7OiAm cXVvdDszZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90Oyw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OiAxNDU4 NDk2MDI1LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAm cXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NjaW0u ZXhhbXBsZS5jb208L3NwYW4+PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiBbPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRw czovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5leGFt cGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0PC9zcGFuPjwvYT4mcXVvdDss PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAm cXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFk MDg2NDFkNzY3NmVlNyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3 PC9zcGFuPjwvYT4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij4mbmJzcDsgJm5ic3A7XSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij4mbmJzcDsgJm5ic3A7JnF1b3Q7ZXZlbnRfdHlwZSZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMu b3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV9hY2NvdW50LTJEY3JlZGVudGlh bC0yRGNoYW5nZS0yRHJlcXVpcmVkJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlY UHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2 N3lGXzh1OF9xU0NfdyZhbXA7cz1uUXk5ZXpQUmpER2R2UlRDYWlEdGk0T0hlbEgzREtnVUNUS2pG MkdRLXNvJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pmh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL2FjY291 bnQtY3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWQ8L3NwYW4+PC9hPiZxdW90Oyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7JnF1b3Q7ZXZlbnQm cXVvdDs6IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDvigJxzdWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0sPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A74oCcaXNz4oCdOiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLyIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vaWRwLmV4 YW1wbGUuY29tLzwvc3Bhbj48L2E+JnF1b3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPn08L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5PbiBNb24sIE9jdCAzMCwgMjAxNyBhdCAxMjow OSBQTSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3Jh Y2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ QW5uYWJlbGxlL0RpY2ssPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+VGhhbmtzIGZvciB0aGUgY29tbWVu dHMuIEkgdGhpbmsgd2UgbmVlZCB0byBleGFtaW5lIHRoZSBjb25zZXF1ZW5jZXMgb2YgdGhlIHBy b3Bvc2FsIGluIEpTT04uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5BcyBJIHN0YXRlZCwgd2hhdCBjYXVzZXMgbW9z dCBvZiB0aGUgaXNzdWUgaXMgdGhlIHByb3Bvc2VkIGV4dGVuc2lvbiBtZWNoYW5pc20gaW4gdGhl IHBheWxvYWQgKHBvc3NpYmx5IHVzaW5nIGV2ZW50cyBpbiBhIHJlY3Vyc2l2ZSB3YXkpLiBEb2Vz IGl0IGZvbGxvdyB0aGUgb2xkIGZvcm1hdCBvciB0aGUgbmV3PzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5MZXTigJlz ICZuYnNwO2NvbnNpZGVyIGEgdXNlIGNhc2Ugd2hlcmUgd2UgaGF2ZSBhbiBpZGVudGl0eSBtYW5h Z2VtZW50IHN5c3RlbSB0aGF0IHVzZXMgU0NJTSwgYnV0IHRoZSBTQ0lNIHN5c3RlbSBpcyBhbHNv IHRoZSB1bmRlcmx5aW5nIGRhdGEgc3RvcmUgZm9yIENvbm5lY3QuJm5ic3A7IEEgUGFzc3dvcmQg cmVzZXQgbWlnaHQgZ2VuZXJhdGUgdGhlIGZvbGxvd2luZyBldmVudCB3aGljaA0KIGhhcyBhbiBl eHRlbnNpb24gKGNvbnZleWluZyByZXNldCBjb3VudCkgQU5EIG92ZXJsYXBwaW5nIHN0YXRlbWVu dCBmcm9tIFJJU0MuJm5ic3A7IEJPVEggb2Ygd2hpY2ggbWlnaHQgYmUgaW1wb3J0YW50IHRvIGEg c2ltaWxhciByZWNlaXZlciB1c2luZyBTQ0lNIGFuZCBPSURDLiAmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48Yj5UaGUgMDMgc3BlYyBjdXJyZW50bHkgd291bGQgYWxsb3c6PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj57PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDtqdGkm cXVvdDs6ICZxdW90OzNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwJnF1b3Q7LDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7 aWF0JnF1b3Q7OiAxNDU4NDk2MDI1LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRw czovL3NjaW0uZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPC9zcGFuPjwvYT4mcXVvdDssPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDth dWQmcXVvdDs6IFs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxl LmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4 ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQ8L3NwYW4+PC9hPiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90 OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0 MWQ3Njc2ZWU3IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0 cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTc8L3Nw YW4+PC9hPiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDsmbmJzcDsgXSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7ICZxdW90O2V2ZW50cyZxdW90OzogezxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJnF1b3Q7dXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldCZxdW90 Ozo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHsgJnF1b3Q7aWQmcXVvdDs6JnF1b3Q7NDRm NjE0MmRmOTZiZDZhYjYxZTc1MjFkOSZxdW90O30sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBo cmVmPSJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dCIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZXhhbXBsZS5j b20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0PC9zcGFuPjwvYT4mcXVvdDs6PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB7ICZxdW90O3Jlc2V0QXR0ZW1wdHMmcXVvdDs6NX0sPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVt YXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV8tMjU1QyZhbXA7ZD1Ed01G YVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7 cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPWl5Vm5y Wm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmYW1wO3M9MjVsMDlzSDhZVjQy eHpnVS1DWFNnOHhIOXR2eURKejQwdENSakZhbGhrdyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0L3NlY2V2 ZW50L3Jpc2MvZXZlbnQtdHlwZS9cPC9zcGFuPjwvYT48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7YWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZCZxdW90Ozogezwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyDigJxzdWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0sPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IOKAnGlzc+KAnTomcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox My41cHQiPjxhIGhyZWY9Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLzwvc3Bh bj48L2E+JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJz cDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPn08L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkluIHRoZSBhYm92ZSAtIGVhY2ggcGF5 bG9hZCBpcyBhIOKAmHBlZXInIGFuZCBpc3N1ZWQgd2l0aG91dCBwcmVmZXJlbmNlIGJ5IHRoZSB0 cmFuc21pdHRlci4gVGhlIHJlY2VpdmVyIGNhbiBhc3NpZ24gcHJpb3JpdHkgaW4gaXRzIG93biBj b250ZXh0IGlmIHRoYXQgbWF0dGVycy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8 cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9k aXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgbmV3IHBy b3Bvc2FsOjwvc3Bhbj48L2I+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj57PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDtqdGkmcXVvdDs6ICZxdW90OzNkMGMzY2Y3OTc1 ODRiZDE5M2JkMGZiMWJkNGU3ZDMwJnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OiAxNDU4NDk2MDI1LDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsgJnF1 b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9zY2ltLmV4 YW1wbGUuY29tPC9zcGFuPjwvYT4mcXVvdDssPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDthdWQmcXVvdDs6IFs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJi Yzg3OTU5M2I3NzU0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQ8 L3NwYW4+PC9hPiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5l eGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3IiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0Zl ZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTc8L3NwYW4+PC9hPiZxdW90OzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsgXSw8bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7 ICZxdW90O2V2ZW50JnF1b3Q7OiB7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxldmVudF90eXBl4oCdOiZx dW90O3VybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3JkUmVzZXTigJ0sPG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmcXVvdDtpZCZxdW90OzrigJ00NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ54oCdLDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsg4oCcZXZlbnRz4oCdOns8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0mZ3Q7bm90ZSDi gKZpcyB0aGlzIHRoZSBvbGQgb3IgbmV3IHN0cnVjdHVyZT8gJmx0Oy08bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVu dC9wYXNzd29yZFJlc2V0RXh0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQ8L3Nw YW4+PC9hPiZxdW90Ozo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHsg JnF1b3Q7cmVzZXRBdHRlbXB0cyZxdW90Ozo1fSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVuaWQu bmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlXy0yNTVDJmFtcDtkPUR3TUZhUSZhbXA7Yz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJU V21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209aXlWbnJabXI5X3VHQ1E2 TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZhbXA7cz0yNWwwOXNIOFlWNDJ4emdVLUNYU2c4 eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9l dmVudC10eXBlL1w8L3NwYW4+PC9hPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDthY2NvdW50LWNyZWRlbnRpYWwtY2hhbmdlLXJlcXVpcmVkJnF1b3Q7OiB7PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IOKAnHN1YuKAnTrigJ03Mzc1NjI2QTY1NjM3NOKAnSw8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsg4oCcaXNz4oCdOiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdCI+PGEgaHJlZj0iaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vPC9z cGFuPjwvYT4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5i c3A7Jm5ic3A7IH08L3NwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+SW4gdGhlIGFib3ZlLCBzdWItZXZlbnRzIG9yIGV4dGVuc2lvbnMgaGF2ZSBhIGRpZmZlcmVu dCBmb3JtYXQuIFRoZSBzYW1lIGNvbXBsYWludCBhYm91dCB0aGUgb3JpZ2luYWwgc3RhbmRzLjwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5i c3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Kk9SKiAoaWYgdGhlIHJlY2VpdmVyIGNhcmVzIGFib3V0IFJJU0MgbW9yZSkuJm5ic3A7IE5vdGUg dGhhdCB0aGlzIGxlYWRzIHRvIGEgdHJpcGxlIG5lc3RlZCBzdHJ1Y3R1cmUuPC9zcGFuPjwvYj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPns8bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7ICZxdW90O2p0aSZx dW90OzogJnF1b3Q7M2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAmcXVvdDssPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDtp YXQmcXVvdDs6IDE0NTg0OTYwMjUsPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBz Oi8vc2NpbS5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5odHRwczovL3NjaW0uZXhhbXBsZS5jb208L3NwYW4+PC9hPiZxdW90Oyw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7ICZxdW90O2F1 ZCZxdW90OzogWzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUu Y29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThk NTI0NjFmYTViYmM4Nzk1OTNiNzc1NDwvc3Bhbj48L2E+JnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7 PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQx ZDc2NzZlZTciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRw czovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNzwvc3Bh bj48L2E+JnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPiZuYnNwOyZuYnNwOyBdLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj4mbmJzcDsmbmJzcDsgJnF1b3Q7ZXZlbnQmcXVvdDs6IHs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IOKAnGV2ZW50X3R5cGXigJ06PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPiZxdW90 OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw LTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZlbnRfcmlzY19ldmVudC0yRHR5cGVfLTI1NUMm YW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFw SV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZh bXA7bT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JmFtcDtzPTI1 bDA5c0g4WVY0Mnh6Z1UtQ1hTZzh4SDl0dnlESno0MHRDUmpGYWxoa3cmYW1wO2U9IiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL3NjaGVtYXMub3Blbmlk Lm5ldC9zZWNldmVudC9yaXNjL2V2ZW50LXR5cGUvXDwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDthY2NvdW50LWNyZWRlbnRpYWwtY2hhbmdlLXJlcXVpcmVkPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJ0sPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEzLjVwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnHN1YuKAnTrigJ03 Mzc1NjI2QTY1NjM3NOKAnSw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDvigJxpc3PigJ06JnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2lkcC5leGFtcGxlLmNvbS8lRTIlODAl OUMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2lk cC5leGFtcGxlLmNvbS/igJw8L3NwYW4+PC9hPiw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXZlbnRz4oCdOns8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJnF1b3Q7dXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldCZxdW90 Ozo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgeyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2lkJnF1b3Q7OuKAnTQ0ZjYxNDJkZjk2YmQ2YWI2 MWU3NTIxZDnigJ0sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyDigJxldmVudHPigJ06ezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNv bS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRS ZXNldEV4dDwvc3Bhbj48L2E+JnF1b3Q7OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeyAmcXVvdDtyZXNl dEF0dGVtcHRzJnF1b3Q7OjV9LDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij4mbmJzcDsg PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTwvc3Bhbj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cHJlIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDt9PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDt9PC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rp dj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkluIHRoZSBhYm92ZSwg dGhlIGV4dGVuc2lvbiBpcyBwbGFjZWQgaW5zaWRlIHRoZSBldmVudCBpdCBleHRlbmRzLiBJdCBm b2xsb3dzIHRoZSBvbGQgZm9ybWF0IChvciBzaG91bGQgaXQgZm9sbG93IHRoZSBuZXc/KTwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4qT1IqIEZvbGxvd2luZyB0aGUgdG9wIGxheWVyIHBhdHRlcm4gb2Ygc2lu Z3VsYXIgZXZlbnQmbmJzcDsgTm90ZSB0aGF0IHRoaXMgbGVhZHMgdG8gYSB0cmlwbGUgbmVzdGVk IHN0cnVjdHVyZS48L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+ezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDsgJnF1b3Q7anRpJnF1b3Q7OiAmcXVvdDszZDBjM2NmNzk3NTg0YmQxOTNiZDBm YjFiZDRlN2QzMCZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Jm5ic3A7ICZxdW90O2lhdCZxdW90OzogMTQ1ODQ5NjAyNSw8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7ICZxdW90O2lzcyZxdW90 OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbTwv c3Bhbj48L2E+JnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiBbPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVm PSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1 NCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1 Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0PC9zcGFuPjwvYT4m cXVvdDssPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZu YnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20v RmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1 MTZiMWQwODY0MWQ3Njc2ZWU3PC9zcGFuPjwvYT4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7IF0sPG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyAmcXVvdDtldmVu dCZxdW90OzogezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXZlbnRfdHlwZeKAnTo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEzLjVwdCI+JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9y aXNjX2V2ZW50LTJEdHlwZV8tMjU1QyZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5 WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxL Njd5Rl84dThfcVNDX3cmYW1wO3M9MjVsMDlzSDhZVjQyeHpnVS1DWFNnOHhIOXR2eURKejQwdENS akZhbGhrdyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5odHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS9cPC9z cGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwO2FjY291bnQtY3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWQ8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+4oCdLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxzdWLigJ064oCdNzM3NTYyNkE2NTYzNzTi gJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcaXNz4oCdOiZxdW90OzxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2lkcC5leGFtcGxlLmNvbS8l RTIlODAlOUMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRw czovL2lkcC5leGFtcGxlLmNvbS/igJw8L3NwYW4+PC9hPiw8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXZlbnTigJ06ezwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyDigJxldmVudF90eXBl4oCdOiZxdW90O3VybjppZXRmOnBhcmFtczpzY2ltOmV2 ZW50OnBhc3N3b3JkUmVzZXTigJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4mcXVvdDtpZCZxdW90 OzrigJ00NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ54oCdLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsg4oCcZXZlbnTigJ06ezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsg4oCcZXZlbnRfdHlwZeKAnTomcXVvdDs8YSBocmVmPSJodHRwczovL2V4 YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dCIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9w YXNzd29yZFJlc2V0RXh0PC9zcGFuPjwvYT7igJ0sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtyZXNldEF0dGVtcHRzJnF1b3Q7OjU8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdCI+IDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO308bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8cHJlIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwO308L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij59PC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGZvcm1hdCBmb2xsb3dzIHRo ZSBwcm9wb3NlZCBzaW5ndWxhciBldmVudCBmb3JtYXQgcmVjdXJzaXZlbHkgYW5kIGlzIDMgbGF5 ZXJzIGRlZXAuIE5vdGUgdGhhdCB0aGUgcGFyc2VyIGhhcyB0byBjb250aW51ZSB0byBzZWFyY2gg dGhlIGRvY3VtZW50IGZvciB0aGluZ3MgdGhhdCBhcmVu4oCZdCB0aGVyZSBhcyBpdCBoYXMgdG8g c3RvcCB3aGVuIG5vIOKAnGV2ZW504oCdIGF0dHJpYnV0ZSBpcyBmb3VuZCByYXRoZXIgdGhhbiBp dGVyYXRlIG92ZXIgYW4gYXJyYXkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPlBoaWw8YnI+DQo8YnI+DQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3Vk IFNlcnZpY2VzIEFyY2hpdGVjdDxicj4NCkBpbmRlcGVuZGVudGlkPGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRl cGVuZGVudGlkLmNvbSZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4 QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtB STFhTGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThf cVNDX3cmYW1wO3M9OXNZaGdwRXpiN3hQbFFGbUNDWE5tSG82ZlFOOUlCdS1TSEphbWdfQjRIcyZh bXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53d3cuaW5k ZXBlbmRlbnRpZC5jb208L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBo aWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi Pk9uIE9jdCAzMCwgMjAxNywgYXQgODo1NyBBTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUg Jmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cmljaGFubmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojQzM0NkUwIj5SZXBsaWVzIGlubGluZS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+SWRlbnRpdHkgU2VydmljZXM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+RnJvbTo8c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1 bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0 OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlBoaWwNCiBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkRhdGU6 PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02 OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L2I+U3VuZGF5LCBPY3RvYmVyIDI5LCAyMDE3IGF0IDU6MjUgUE08 YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYx NDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5EaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJt YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxi PkNjOjxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUz MDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPllhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0 bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L3NwYW4+PC9hPiZndDssDQogTWlrZSBK b25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0OywgJnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cmljaGFubmFAYW1hem9uLmNvbTwv c3Bhbj48L2E+Jmd0OywNCiBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWls dG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5pZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02 OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L2I+UmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBs ZSBldmVudHMgcGVyIFNFVD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+SSBob3BlIHRoaXMgYW5zd2VycyB5b3VyIHF1ZXN0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk15IOKAnG1heeKA nSB3YXMgYmVjYXVzZSBJIGNhbuKAmXQgc2VlIGEgcmVhc29uIHdoeSBub3QuIFRoZSBxdWVzdGlv biBzaG91bGQgYmUsIHdoYXQgaXMgdGhlIGp1c3RpZmljYXRpb24gdG8gbWFrZSDigJxldmVudHPi gJ0gc2luZ3VsYXI/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOiNDMzQ2RTAiPltyaWNoYW5uYV1UaGUgc2luZ3VsYXIg4oCcZXZlbnTigJ0gY2xh aW0gaGFzIGNsZWFyZXIgc2VtYW50aWNzIGFuZCBpcyBlYXNpZXIgdG8gcHJvY2Vzcy4gV2Ugc2hv dWxkIG9wdCBmb3IgZWFzaWVyIHNvbHV0aW9ucyB1bmxlc3MgdGhlcmUgYXJlIHVzZSBjYXNlcyB0 aGF0IHJlcXVpcmUgbW9yZSBjb21wbGV4aXR5LlsvcmljaGFubmFdPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRoZXJlIGFyZSBtYW55IHJl YXNvbnMgZm9yIG11bHRpcGxlIGV2ZW50cyBpbiBhIFNFVC4mbmJzcDsgU29tZSBhcmUgZ29vZCwg c29tZSBub3Qgc28gZ29vZC4gU29tZSBvZiB0aGUgcmVhc29ucy4uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjEuJm5ic3A7IE11bHRpcGxlIGV2ZW50 IHBheWxvYWRzIGV4cHJlc3Npbmcgc3RhdGVtZW50cyBhYm91dCBsYXJnZWx5IHRoZSAqc2FtZSp0 aGluZy4gRm9yIGV4YW1wbGUsIFNDSU0gcGFzc3dvcmQgcmVzZXQgQU5EIFJJU0MgcGFzc3dvcmQg cmVzZXQuJm5ic3A7IEEgUklTQyBFdmVudCBhbmQgYW4gT3BlbkJhbmtpbmcgRXZlbnQuIElzIG9u ZSBhIGNvbXBsZW1lbnQgdG8gdGhlIG90aGVyPyZuYnNwOw0KIERvIHRoZXkgb3ZlcmxhcCBvciBh cmUgdGhleSBkaXN0aW5jdD8gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPltyaWNoYW5uYV1Db3B5L3Bhc3RlZCBmcm9t IG15IGVhcmxpZXIgZW1haWw6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojQzM0NkUwIj5XaHkgaXMgaXQgbmVjZXNzYXJ5IG9yIGFw cHJvcHJpYXRlIHRvIGluY2x1ZGUgdGhlc2UgZXZlbnRzIGluIHRoZSBzYW1lIFNFVD8gVGhleSBh cmUgbGlrZWx5IGJlaW5nIGdlbmVyYXRlZCBieSBkaWZmZXJlbnQgc3lzdGVtcyBhdCBkaWZmZXJl bnQgdGltZXMgb24gdGhlIHRyYW5zbWl0dGVy4oCZcyBzaWRlLCBjb25zdW1lZA0KIGJ5IGRpZmZl cmVudCBzeXN0ZW1zIG9uIHRoZSByZWNlaXZlcuKAmXMgc2lkZSwgYW5kIHBvc3NpYmx5IGJlaW5n IHRyYW5zbWl0dGVkIG92ZXIgZGlmZmVyZW50IGV2ZW50IHN0cmVhbXMuIEkga25vdyB0aGUgbGF0 dGVyIHdvdWxkIGJlIHRoZSBjYXNlIGZvciB1cywgYXMgYSByZWNlaXZlci4gRXZlbiBpZiBpdOKA mXMgbm90LCBpcyBpdCBidXJkZW5zb21lIHRvIHNlbmQgdGhlc2UgZXZlbnRzIHNlcGFyYXRlbHk/ IFdoYXQgdmFsdWUgaXMgZ2FpbmVkIGluDQogY29tYmluaW5nIHRoZW0/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojQzM0NkUwIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOiNDMzQ2RTAiPkFkZGl0aW9uYWxseSwgc2luY2UgdGhlIHNpZ25hdHVyZSBpcyBv dmVyIHRoZSBTRVQgYW5kIG5vdCB0aGUgZXZlbnQgb2JqZWN0cywgUmVjZWl2ZXJzIGluZGVwZW5k ZW50bHkgcm91dGUgc2VwYXJhdGUgZXZlbnRzIGZyb20gYSBzaW5nbGUgdG9rZW4gd2l0aG91dCBl aXRoZXIgbG9zaW5nIHRoZSBhYmlsaXR5IHRvIHZlcmlmeQ0KIHRoZSBhdXRoZW50aWNpdHkgb2Yg dGhlIGV2ZW50IG9yIHNoYXJpbmcgYWxsIGluZm9ybWF0aW9uIGluIHRoZSBTRVQgd2l0aCBldmVy eSBzeXN0ZW0gaGFuZGxpbmcgYW55IGV2ZW50IGluIHRoZSB0b2tlbi5bL3JpY2hhbm5hXTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6 I0MzNDZFMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwg aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KMi4mbmJzcDsgTXVs dGlwbGUgZXZlbnRzIHBheWxvYWRzIGV4cHJlc3NpbmcgZGlmZmVyZW50IHN0YXRlbWVudHMgYWJv dXQgdGhlIHNhbWUgdHJhbnNhY3Rpb24gLSBSSVNDIFBhc3N3b3JkIFJlc2V0IGFuZCBSSVNDIFNl c3Npb24gQ2FuY2VsPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPltyaWNoYW5uYV1T YW1lIGFzIGFib3ZlWy9yaWNoYW5uYV08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjMuJm5ic3A7IEEgbmV3IHByb2ZpbGUgZGVmaW5lcyBuZXcgZXZlbnQg YXR0cmlidXRlcyB0byBiZSBhZGRlZCBvbiB0byBhbiBleGlzdGluZyBldmVudCB0eXBlIChhIHB1 cmUgZXh0ZW5zaW9uKSZuYnNwOzxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojQzM0NkUwIj5bcmlj aGFubmFdSSBoYXZlIHN1Z2dlc3RlZCBhIHdheSB0byBzdXBwb3J0IGV4dGVuc2lvbnMgd2l0aGlu IGFuIGV2ZW50IGJvZHksIG11bHRpcGxlIHRpbWVzIG5vdy4gSWYgeW91IHNlZSBwcm9ibGVtcyB3 aXRoIGl0LCBwbGVhc2UgcG9pbnQgdGhlbSBvdXQuWy9yaWNoYW5uYV08L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SSB0aGluayBpdCBpcyBx dWl0ZSB2YWxpZCB0byBhbGxvdyAxIGFuZCAzLiAmbmJzcDsyIGNvdWxkIGJlIGxpbWl0ZWQgYnkg c3BlY2lmaWMgcHJvZmlsZXMgbGlrZSBSSVNDIGlmIHRoZXkgd2FudC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JIGFtIG5vdCBpbiBhZ3JlZW1lbnQg dGhhdCBtYWtpbmcgZXZlbnQgc2luZ3VsYXIgc2ltcGxpZmllcyBhbnl0aGluZy4gRm9yIG9uZSBp cyBtYWtlcyBleHRlbnNpb25zIGNvbXBsZXggKGFub3RoZXIgbmVzdGVkIEpTT04gc3RydWN0dXJl KSBhbmQgcG90ZW50aWFsbHkgY29uZmxpY3RpbmcuJm5ic3A7PGJyPg0KPHNwYW4gc3R5bGU9ImNv bG9yOiNDMzQ2RTAiPltyaWNoYW5uYV08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPldheXMgdGhhdCBtdWx0aXBsZS1l dmVudCBTRVRzIGFyZSBtb3JlIGNvbXBsaWNhdGVkOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0i MSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiNDMzQ2RTA7bWFyZ2luLWxl ZnQ6MGluO21zby1saXN0OmwzIGxldmVsMSBsZm8yO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3Vu ZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0 aWFsIj4NCkl0IHJlc3VsdHMgaW4gYSBtb3JlIGNvbXBsZXggc3RydWN0dXJlIGZvciB0aGUgc2lu Z2xlIGV2ZW50IHVzZSBjYXNlLCB3aGljaCBJIHRoaW5rIHdlIGFsbCBhZ3JlZSBpcyB0aGUgbWFq b3JpdHkgdXNlIGNhc2UuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY29sb3I6I0MzNDZFMDttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzI7 YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNr Z3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KTXVsdGlwbGUtZXZlbnQgU0VUcyBoYXZl IGFtYmlndW91cyBzZW1hbnRpY3MuIFRoZSBwcmVzZW5jZSBvZiB0d28gZXZlbnRzIEEgYW5kIEIg aW4gdGhlIHNhbWUgU0VUIGNvdWxkIG1lYW4gYW55IG9mOjxvOnA+PC9vOnA+PC9saT48L29sPg0K PG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjIiIHR5cGU9IjEiPg0KPG9sIHN0eWxl PSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjojQzM0NkUwO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZl bDIgbGZvMztiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0 aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQpUaGV5IGFyZSByZWxhdGVk IHRvIHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQgKGkuZS4gdGhlIHNhbWUgdGhpbmcgYXMgaWYgdGhl eSB3ZXJlIGZyb20gZGlmZmVyZW50IFNFVHMgdGhhdCBoYXZlIGEgY29tbW9uIHR4bikuPG86cD48 L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6I0MzNDZFMDttYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzM7YmFja2dyb3VuZDp3aGl0ZTtiYWNr Z3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFs IGluaXRpYWwiPg0KQSBpcyBhbiBleHRlbnNpb24gb2YgQi48bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojQzM0NkUwO21hcmdpbi1sZWZ0OjBpbjttc28t bGlzdDpsMSBsZXZlbDIgbGZvMztiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246 aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQpCIGlz IGFuIGV4dGVuc2lvbiBvZiBBLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImNvbG9yOiNDMzQ2RTA7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMiBs Zm8zO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7 YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NClRoZXkgYXJlIGFsaWFzZXMgZm9y IG9uZSBhbm90aGVyLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNvbG9yOiNDMzQ2RTA7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMiBsZm8zO2Jh Y2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dy b3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NClRoZXkgYXJlIG5vdCBhY3R1YWxseSByZWxh dGVkIHRvIG9uZSBhbm90aGVyIGluIGFueSB3YXkuPG86cD48L286cD48L2xpPjwvb2w+DQo8L29s Pg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjMiIHR5cGU9IjEiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojQzM0NkUwO21hcmdpbi1sZWZ0OjBpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvNDtiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246 aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQpDbGFp bSBzZW1hbnRpY3MgYmVjb21lIGhhcmRlciB0byBkZWZpbmUsIGFzIGRpZmZlcmVudCBwcm9maWxl cyBtYXkgd2FudCB0byB1c2UgdGhlIHNhbWUgY2xhaW1zIGluIGRpZmZlcmVudCB3YXlzLjxvOnA+ PC9vOnA+PC9saT48L29sPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SWYgdGhlIFdHIHdhbnRzIHRvIGJs b2NrIDEgYW5kIDIgYWJvdmUsIHRoZW4gSSBiZWxpZXZlIHdlIGhhdmUgdG8gZXN0YWJsaXNoIGFu IGV2ZW50IHJlZ2lzdHJ5IHRvIGVuc3VyZSBuZXcgRXZlbnQgcHJvZmlsZXMgZG8gbm90IG92ZXJs YXAgdG8gZWxpbWluYXRlIHRoZSBuZWVkIHRvIGV4cHJlc3MgbXVsdGlwbGUgZXZlbnRzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJjb2xvcjojQzM0NkUwIj5bcmljaGFubmFdSeKAmW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBi eSB0aGlzLiBBcmUgeW91IHJlZmVycmluZyB0byBldmVudCBuYW1lcz8gVGhvc2UgYXJlIGFscmVh ZHkgZGVmaW5lZCBieSB0aGUgc3BlYyB0byBiZSBVUklzLlsvcmljaGFubmFdPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PlBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5P cmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkBpbmRlcGVuZGVu dGlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEg aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0Ff X3d3dy5pbmRlcGVuZGVudGlkLmNvbSZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5 WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPVUtYTVIQk5EMEhhVFg0YW5OWmZ6WDdwRHNmSzVm MGg5bVo5Q1pra0dpZWMmYW1wO3M9S0J3S1BGbnFZX1E5NUNUQV9fV0dDWUdUeHJEN0FHQ3h1ZW9Q WG5LRVVUMCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij53d3cuaW5kZXBlbmRlbnRpZC5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEgaHJlZj0ibWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+T24gT2N0IDI5LCAyMDE3LCBhdCA0OjEyIFBNLCBEaWNrIEhh cmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvc3Bh bj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+UGhpbDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5JbiB5b3VyIGV4YW1wbGVzIGZvciBoYXZpbmcgYSBwbHVyYWxpdHkgb2YgZXZlbnRzLCB5 b3UgdXNlIHRoZSB3b3JkICZxdW90O21heSZxdW90Oywgd2hpY2ggbGVhZHMgbWUgdG8gcXVlc3Rp b24gaWYgYSBwbHVyYWxpdHkgb2YgZXZlbnRzIGlzIHJlYWxseSByZXF1aXJlZA0KIGluIFNFVC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPllvdSBwb3NpdCB0aGF0 IGl0IHdpbGwgYmUgZGlmZmljdWx0IGZvciBhIGRpc3RyaWJ1dGVkIHN5c3RlbSB0byBjb3JyZWxh dGUgbXVsdGlwbGUgU0VUcyB3aXRoIHRoZSBzYW1lICZxdW90O3R4biZxdW90OywgYnV0IHRoZSBk aXN0cmlidXRlZCBzeXN0ZW0gd2lsbCBjZXJ0YWlubHkNCiBuZWVkIHRvIGNvcnJlbGF0ZSBldmVu dHMgb24gdGhlIHNhbWUgc3ViamVjdCAtLSBjb3JyZWxhdGluZyBldmVudHMgb24gdGhlIHNhbWUg JnF1b3Q7dHhuJnF1b3Q7IG9uIHRoZSBzYW1lIHN1YmplY3Qgc2VlbXMgZmFpcmx5IHNpbXBsZS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgdGhpbmsgdGhhdCBh IHJlY2VpdmVyIHdpbGwgbmVlZCB0byBjb3JyZWxhdGUgbXVsdGlwbGUgU0V0cyBvbiB0aGUgc2Ft ZSBzdWJqZWN0LCBzbyBoYXZpbmcgbXVsdGlwbGUgZXZlbnRzIGluIGEgU0VUIGlzIHJlZHVuZGFu dCwgYW5kIGFkZHMgY29tcGxleGl0eQ0KIHdpdGggbm8gY2xlYXIgYmVuZWZpdCB0aGF0IEkgY2Fu IHNlZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFuIGltcGxl bWVudG9yIG1heSBjaG9vc2UgdG8gc2VuZCBtdWx0aXBsZSBTRVRzLCBvciBzZW5kIGEgc2luZ2xl IFNFVCB3aXRoIG11bHRpcGxlIGV2ZW50cywgc28gYSByZWNlaXZlciB3aWxsIG5lZWQgdG8gc3Vw cG9ydCBib3RoLiBJIHByZWZlciB3ZSBwaWNrDQogb25lIHdheSBhbmQgbWluaW1pemUgdGhlIGNv ZGUgcGF0aHMsIGFuZCB3ZSB3aWxsIG5lZWQgdG8gc3VwcG9ydCBjb3JyZWxhdGluZyBhY3Jvc3Mg bXVsdGlwbGUgU0VUcywgc28gdGhhdCBzZWVtcyB0aGUgYmVzdCBtZWNoYW5pc20uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5MZXQgbWUga25vdyBpZiB0aGVyZSBp cyBzb21ldGhpbmcgSSBtaXNzZWQgaW4gbXkgbG9naWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4vRGljazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIFN1biwgT2N0IDI5LCAyMDE3 IGF0IDExOjI4IEFNLCBZYXJvbiBTaGVmZmVyPHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIw ODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYw ODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7PGEgaHJlZj0i bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0OzxzcGFu IGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3 Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+d3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+SW4gdGhhdCBjYXNlLCBsZXQncyBhZGQgdGV4dCB0byB0aGF0IGVmZmVj dCwgZS5nLiB3ZSBjb3VsZCBhZGQgdG8gdGhlIGRlZmluaXRpb24gb2YgdGhlICZxdW90O2V2ZW50 cyZxdW90OyBjbGFpbTo8YnI+DQo8YnI+DQpQcm9maWxpbmcgc3BlY2lmaWNhdGlvbnMgU0hPVUxE IGRlZmluZSB0aGUgYWxsb3dlZCBldmVudCBzdGF0ZW1lbnRzLCBhbmQgTUFZIHJlc3RyaWN0IHRo ZWlyIG51bWJlci4gRm9yIGV4YW1wbGUsIHNvbWUgcHJvZmlsZXMgbWF5IHJlcXVpcmUgdGhpcyBj bGFpbSB0byBjb250YWluIG9ubHkgYSBzaW5nbGUgZXZlbnQgc3RhdGVtZW50Ljxicj4NCjxicj4N ClRoYW5rcyw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0ibS00 Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3 MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pllhcm9uPGJyPg0KPGJyPg0KT24gMjQvMTAvMTcgMjI6MTAsIE1pa2UgSm9uZXMgd3JvdGU6PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlv bjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPkkgYWdyZWUgd2l0aCBtdWNoIG9mIFBoaWzigJlzIHJhdGlvbmFsZSBo ZXJlLjxicj4NCjxicj4NCkl04oCZcyBmaW5lIGZvciBzb21lIHByb2ZpbGVzIHRvIHNheSB0aGF0 IHRoZSDigJxldmVudHPigJ0gc2V0IG11c3QgYmUgYSBzaW5nbGV0b24uJm5ic3A7IFRoYXQgZG9l c27igJl0IGhhdmUgdG8gYmUgdHJ1ZSBmb3IgYWxsIGV2ZW50cy4mbmJzcDsgSSB0aGluayB0aGlu Z3MgYXJlIGZpbmUgYXMtaXMuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1 NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4tLSBNaWtlPGJyPg0KPGJyPg0KKkZyb206 KiBJZC1ldmVudCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnQt Ym91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSAqT24gQmVoYWxmIE9mICpQaGlsIEh1bnQ8YnI+ DQoqU2VudDoqIE1vbmRheSwgT2N0b2JlciAyMywgMjAxNyA4OjQ3IFBNPGJyPg0KKlRvOiogUmlj aGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6 b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cmljaGFu bmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCipDYzoqIElEIEV2ZW50cyBNYWlsaW5n IExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwv YT4mZ3Q7PGJyPg0KKlN1YmplY3Q6KiBSZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRp cGxlIGV2ZW50cyBwZXIgU0VUPzxicj4NCjxicj4NCkFubmFiZWxsZSw8YnI+DQo8YnI+DQpJIGhh dmUgYSBudW1iZXIgb2YgY29uY2VybnMgd2l0aCB0aGlzIHByb3Bvc2FsLjxicj4NCjxicj4NClBy b2ZpbGluZyBJbmRlcGVuZGVuY2UgLyBLZWVwaW5nIEV2ZW50IFBheWxvYWRzIEluZGVwZW5kZW50 PGJyPg0KPGJyPg0KSW5kaWNhdGluZyB0aGF0IGV4dGVuc2lvbnMgc2hvdWxkIGJlIGhhbmRsZWQg YnkgcHJvZmlsZXMgbGVhZHMgdG8gbW9yZSBpbnRlci1vcGVyYWJpbGl0eSBpc3N1ZXMgYW5kIG1v cmUgaW1wb3J0YW50bHkgaW50cnVkZXMgb24gdGhlIEV2ZW50IHBheWxvYWQgc3BhY2UgYnkgc3Vn Z2VzdGluZyBhIHN1Yi1zY2hlbWEgY3JlYXRlcyBwb3RlbnRpYWwgbGltaXRhdGlvbnMgYW5kIGNv bmZsaWN0cyB0aGF0IG1heSBhZGQgdG8gY29tcGxleGl0eSBsYXRlcg0KIG9uLiBUaGUgY3VycmVu dCBmb3JtYXQgYWxsb3dzIGEgcGFyc2VyIHRvIGRpc2NvdmVyIGFuZCB1bmxvYWQgb25lIG9yIG1v cmUgSlNPTiBwYXlsb2FkcyB3aGljaCBjYW4gZWFjaCBoYXZlIGluZGVwZW5kZW50IHN0cnVjdHVy ZS48YnI+DQo8YnI+DQpHZW5lcmFsIGV4dGVuc2lvbnM8YnI+DQo8YnI+DQpUaGUgcHJvcG9zYWwg YWxzbyBydWxlcyBvdXQgZ2VuZXJhbCBwdXJwb3NlIGV4dGVuc2lvbnMgbm90IHJlbGF0ZWQgdG8g YW55IHNwZWNpZmljIGV2ZW50LiBHaXZlbiB0aGUgZW1lcmdlbmNlIG9mIGl0ZW1zIGxpa2UgR1BS RCwgSSB3b3VsZCBub3Qgd2FudCB0byBibG9jayB0aGUgYWJpbGl0eSB0byBhZGQgbWV0YS1kYXRh IG9yIG90aGVyIGdlbmVyYWwgcHVycG9zZSBpdGVtcy4gV2UgY2FuIGFsc28gYW50aWNpcGF0ZSBz b21lIGRlbGl2ZXJ5IHNjZW5hcmlvcw0KIHdoZXJlIGFkZGl0aW9uYWwgZGF0YSBtaWdodCBiZSBy ZXF1aXJlZC4gRXZlbiB0aG91Z2ggdGhlcmUgaXMgbm8gY3VycmVudCBwbGFubmVkIHVzZSwgSSBz ZWUgbm8gZ29vZCByZWFzb24gdG8gcnVsZSB0aGlzIG91dC48YnI+DQo8YnI+DQpNdWx0aXBsZSBF dmVudHMgRnJvbSBEaWZmZXJlbnQgRmFtaWxpZXMgKHZzLiBNdWx0aXBsZSBFdmVudHMgZnJvbSBh IHNpbmdsZSBmYW1pbHkgbGlrZSBSSVNDKTxicj4NCjxicj4NCkluIG91ciBSSVNDIHNlc3Npb24g d2UgZGlzY3Vzc2VkIGV4cHJlc3NpbmcgbXVsdGlwbGUgZGlzdGluY3QgUklTQyBldmVudHMgaW4g b25lIFNFVC4gVGhlIGRpc2N1c3Npb24gd2FzIHRoYXQgb25seSBvbmUgUklTQyBldmVudCBhdCBh IHRpbWUuIFdlIGRpZCBub3QgZGlzY3VzcyBvdGhlciBldmVudCBwcm9maWxlcy4gSSBkb27igJl0 IHNlZSBhIHJlYXNvbiB0byBydWxlIG91dCBtdWx0aS1ldmVudHMgZnJvbSBkaWZmZXJlbnQgZmFt aWxpZXMgYXQgdGhlDQogU0VUIGxldmVsLiBFYWNoIHByb2ZpbGUgaXMgZXhwcmVzc2luZyBzbGln aHRseSBkaWZmZXJlbnQgdGhpbmdzIGFib3V0IHRoZSBzYW1lIGV2ZW50Ljxicj4NCjxicj4NCkkg Y2FuIGZvcnNlZSBzb21lIGNhc2VzIHdoZXJlIGl0IGlzIG5vdCBjbGVhciB3aGljaCBpcyB0aGUg cHJpbWFyeSBhbmQgd2hpY2ggaXMgdGhlIGV4dGVuc2lvbi4mbmJzcDsgVGhlcmUgbWF5IG5vdCBi ZSBhIGNsZWFyIHdpbm5lci48YnI+DQo8YnI+DQpBIGNvdXBsZSBvZiBleGFtcGxlcyAodGhlc2Ug YXJlIG5lY2Vzc2FyaWx5IHJlYWzigKZqdXN0IHBvc3NpYmlsaXRpZXMpOjxicj4NCjxicj4NCiog SXQgaXMgcHJvYmFibHkgdXNlZnVsIHRvIGJlIGFibGUgdG8gZXhwcmVzcyBzaW1sYXIvb3Zlcmxh cHBpbmcgZXZlbnRzIGZyb20gZGlmZmVyZW50IFNFVCBwcm9maWxlcyBpbiBvbmUgU0VULiZuYnNw OyBGb3IgZXhhbXBsZSBhIEJhY2tjaGFubmVsIExvZ291dCAmYW1wOyBhIFJJU0Mgc2Vzc2lvbiBj YW5jZWwgZXZlbnQuPGJyPg0KPGJyPg0KKiBTQ0lNIG1heSB3YW50IHRvIHJlcHJlc2VudCBhIHNp bmdsZSB0cmFuc2FjdGlvbiBhcyBjYXVzaW5nIG11bHRpcGxlIHN0YXRlIGNoYW5nZXMgaW4gYW4g ZXZlbnQgKGUuZy4gYSBwYXNzd29yZCBjaGFuZ2UgY2F1c2VzIG11bHRpcGxlIGVmZmVjdHMpLiBI YXZpbmcgdG8gY2hhc2UgZG93biBtdWx0aXBsZSBldmVudHMgYW5kIGNvcnJlbGF0ZSBieSDigJx0 eG7igJ0gd291bGQgYmUgY2hhbGxlbmdpbmcgaW4gYSBtdWx0aS10aHJlYWRlZC9tdWx0aS1ub2Rl DQogZGVsaXZlcnkgc3lzdGVtLiZuYnNwOyAmbmJzcDtUaGUgU0NJTSBsaXN0IGhhcyBub3QgZGlz Y3Vzc2VkIHRoaXMsIGJ1dCBJIHdvdWxkIG5vdCB3YW50IHRvIGJsb2NrIHRoaXMgY2FwYWJpbGl0 eS4mbmJzcDsgSU9XIC0gSnVzdCBiZWNhdXNlIFJJU0MgZG9lcyBub3Qgd2FudCB0byBleHByZXNz IG11bHRpcGxlIGV2ZW50cyBkb2VzIG5vdCBtYWtlIHRoaXMgdHJ1ZSBmb3Igb3RoZXIgcHJvZmls ZXMuPGJyPg0KPGJyPg0KKiBXZSBtYXkgd2lzaCB0byBpbmRpY2F0ZSBhIFNDSU0gUGFzc3dvcmQg UmVzZXQgd2FzIHBlcmZvcm1lZCBhbmQgYSBMb2dvdXQvc2Vzc2lvbiBjYW5jZWxsYXRpb24gaXMg ZXhwcmVzc2VkIGF0IHRoZSBzYW1lIHRpbWUuJm5ic3A7IFRoZSBldmVudHMgYXJlIHJlbGF0ZWQg YnV0IGV4cHJlc3MgZGlmZmVyZW50IGRhdGEuPGJyPg0KPGJyPg0KQXZvaWRpbmcgQ29uZnVzaW9u IEZyb20gU2ltaWxhciBFdmVudHMgT3JpZ2luYXRpbmcgZnJvbSB0aGUgU2FtZSBUcmFuc2FjdGlv bjxicj4NCjxicj4NCklmIGV2ZW50cyBhcmUgc2VudCBzZXBhcmF0ZWx5LCB0aGVuIG1vcmUgdHJh Y2tpbmcgb2Ygc3RhdGUgKGUuZy4gYnkgdHhuKSB3b3VsZCBiZSByZXF1aXJlZCB0byBlbnN1cmUg c2ltaWxhciBldmVudHMgYXJlIG5vdCBtaXN0YWtlbiBvciBoYW5kbGVkIGFzIHJlcGVhdHMuIFdo aWxlIHR4biBwcm92aWRlcyB1c2VmdWwgYXVkaXQgYW5hbHlzaXMgY2FwYWJpbGl0eSwgSeKAmW0g bm90IHN1cmUgaXQgY2FuIGJlIHVzZWQgaW4gbGl2ZSBvciBuZWFyLXJlYWwNCiB0aW1lIHN5c3Rl bXMgZ2l2ZW4gZGlzdHJpYnV0ZWQgbXVsdGktbm9kZSwgbXVsdGktdGhyZWFkaW5nIGFyY2hpdGVj dHVyZXMuPGJyPg0KPGJyPg0KUHJldmlvdXMgRGlzY3Vzc2lvbjxicj4NCjxicj4NCkkgbm90ZSB0 aGF0IEkgb3JpZ2luYWxseSByYWlzZWQgaGF2aW5nIGFuIGF0dHJpYnV0ZSB0byBkZXNpZ25hdGUg cHJpbWFyeSBldmVudCBhdHRyaWJ1dGUgdG8gYWxsZXZpYXRlIHlvdXIgY29uY2VybiwgYnV0IHRo aXMgd2FzIG5vdCBhY2NlcHRlZC4gU2VlOjxicj4NCjxicj4NCio8c3BhbiBjbGFzcz0ibS00Mzc3 Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNt NDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRfbXNn MDA0MDYuaHRtbCZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3 cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFh TGNMTjRLWk5BJmFtcDttPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcx aXcmYW1wO3M9UzNzTVZpcU12RWdud0diSndPUU55Y3JPeXI3U2VmcHFfTW9GT0tjRWVDRSZhbXA7 ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkLWV2ZW50L2N1cnJlbnQvbXNnMDA0MDYuaHRt bDwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KKjxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5 MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgw MzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbC0yRGFyY2hpdmVfd2ViX2lkLTJEZXZlbnRfY3VycmVudF9tc2cwMDE0MC5odG1sJmFt cDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElf Sm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1w O209WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZhbXA7cz1HeTln eVJvSUl0YS1jU2hWN2JOMTYxYXk0eUU2cjlHMV9BYV9OZUJueWxnJmFtcDtlPSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3VycmVudC9tc2cwMDE0MC5odG1sPC9zcGFuPjwvYT48 YnI+DQo8YnI+DQpUaGUgY29uc2Vuc3VzLCBhdCBsZWFzdCBhcyBJIGludGVycHJldGVkIGl0IGlz IHVwIHRvIHRoZSByZWNlaXZlciB0byBmaWd1cmUgdGhpcyBvdXQgYmFzZWQgb24gdGhlIGRlZmlu aXRpb25zIGl0IGhhcyBmb3IgZWFjaCBldmVudCBVUkkgYW5kIHRoZSBwcm9maWxlcyB0aGV5IHJl cHJlc2VudC4gSU9XIC0gUklTQyBpcyBmcmVlIHRvIGxpbWl0IHRoYXQgb25seSBvbmUgUklTQyBl dmVudCBiZSBleHByZXNzZWQgYXQgYSB0aW1lLjxicj4NCjxicj4NClBoaWw8YnI+DQo8YnI+DQpP cmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdDxicj4N Cjxicj4NCkBpbmRlcGVuZGVudGlkPGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNv bSZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVl YXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5B JmFtcDttPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmYW1wO3M9 OU5QNW5hbWc2cklWend1bjljLTFxMHdoc3lYd1N2dEhCMGYyZEtrZkNYOCZhbXA7ZT0iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53d3cuaW5kZXBlbmRlbnRpZC5j b208L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4 NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5j b20mYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1 ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pO QSZhbXA7bT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtz PTlOUDVuYW1nNnJJVnp3dW45Yy0xcTB3aHN5WHdTdnRIQjBmMmRLa2ZDWDgmYW1wO2U9IiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL3d3dy5pbmRlcGVu ZGVudGlkLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxicj4NCjxhIGhyZWY9Im1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ibS00Mzc3Nzg3 NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAy NjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+ PC9hPiZndDs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE9uIE9jdCAyMywgMjAxNywgYXQgNzow MiBQTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGU8YnI+DQombmJzcDsgJm5ic3A7ICZsdDs8 YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPjxzcGFu IGNsYXNzPSJtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3 Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFt YXpvbi5jb208L3NwYW4+PC9hPiZndDsmZ3Q7DQogd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyBUaGUgY3VycmVudCBkcmFmdCBvZiB0aGUgU0VUIHNwZWMgYWxsb3dzIGZvciBleHByZXNz aW5nIG11bHRpcGxlPGJyPg0KJm5ic3A7ICZuYnNwOyBldmVudHMgd2l0aGluIHRoZSBzYW1lIHRv a2VuLCB3aGljaCBpbnRyb2R1Y2VzIGFkZGl0aW9uYWwgY29tcGxleGl0eTxicj4NCiZuYnNwOyAm bmJzcDsgYW5kIHJvb20gZm9yIGFtYmlndW91cyBzZW1hbnRpY3MuIFdl4oCZdmUgZGlzY3Vzc2Vk IHRoaXMgaW4gdGhlIE9JREY8YnI+DQombmJzcDsgJm5ic3A7IFJJU0Mgd29ya2luZyBncm91cCBh bmQgdGhlIGN1cnJlbnQgY29uc2Vuc3VzIHRoZXJlIGlzIHRoYXQgUklTQyB3aWxsPGJyPg0KJm5i c3A7ICZuYnNwOyByZXF1aXJlIHRoYXQgUklTQyBldmVudHMgbXVzdCBiZSB0aGUgb25seSBldmVu dCBpbiB0aGUgU0VULCBoYXZpbmc8YnI+DQombmJzcDsgJm5ic3A7IGlkZW50aWZpZWQgd2F5cyB0 byBjbGVhcmx5IGFuZCBlYXNpbHkgc3VwcG9ydCB0aGUgaGFuZGZ1bCBvZiB1c2U8YnI+DQombmJz cDsgJm5ic3A7IGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIHRva2VuIHRoYXQgcGVvcGxl IGhhdmUgcmFpc2VkLiBXaXRoPGJyPg0KJm5ic3A7ICZuYnNwOyB0aGF0IGNvbnRleHQgaW4gbWlu ZCwgSSBwcm9wb3NlIHN0cmlraW5nIHRoZSBkZWZpbml0aW9uIG9mIHRoZTxicj4NCiZuYnNwOyAm bmJzcDsg4oCcZXZlbnRz4oCdIGNsYWltIGZyb20gdGhlIFNlY3VyaXR5IEV2ZW50IFRva2VuIHNw ZWMsIGFuZCByZXBsYWNpbmcgaXQ8YnI+DQombmJzcDsgJm5ic3A7IHdpdGggdGhlIGZvbGxvd2lu ZyBkZWZpbml0aW9uIGZvciBhbiDigJxldmVudOKAnSBjbGFpbSAoc2luZ3VsYXIpOjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgZXZlbnQ8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEEgSlNPTiBv YmplY3QgY29udGFpbmluZyBhbiAmcXVvdDtldmVudF90eXBlJnF1b3Q7IG1lbWJlciB3aG9zZSB2 YWx1ZSBpcyBhIFVSSTxicj4NCiZuYnNwOyAmbmJzcDsgcmVwcmVzZW50aW5nIGEgdHlwZSBvZiBl dmVudCBkZWZpbmVkIGluIGEgUHJvZmlsaW5nIFNwZWNpZmljYXRpb24uPGJyPg0KJm5ic3A7ICZu YnNwOyBUaGUgb2JqZWN0IE1BWSBvdGhlcndpc2UgYmUgZW1wdHksIG9yIE1BWSBjb250YWluIGFk ZGl0aW9uYWwgbWVtYmVyczxicj4NCiZuYnNwOyAmbmJzcDsgYXMgZGVzY3JpYmVkIGJ5IHRoZSBQ cm9maWxpbmcgU3BlY2lmaWNhdGlvbi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEhlcmUgaXMg dGhlIGV4YW1wbGUgU0VUIGZyb20gc2VjdGlvbiAyLjMsIHJld3JpdHRlbiB3aXRoIHRoaXMgY2hh bmdlPGJyPg0KJm5ic3A7ICZuYnNwOyBtaW5kOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDs8c3Bh biBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3 NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPns8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmcXVv dDtqdGkmcXVvdDs6ICZxdW90OzRkMzU1OWVjNjc1MDRhYWJhNjVkNDBiMDM2M2ZhYWQ4JnF1b3Q7 LDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZxdW90O2lhdCZxdW90Ozog MTQ1ODQ5NjQwNCw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZxdW90O2lz cyZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLyIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vc2NpbS5leGFtcGxl LmNvbTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1 NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7PGEgaHJlZj0iaHR0cHM6Ly9zY2lt LmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pmh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS88L3NwYW4+PC9hPiZndDsmcXVvdDssPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiBbPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7JnF1b3Q7PGEgaHJlZj0i aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NjaW0u ZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NDwvc3Bhbj48L2E+JnF1 b3Q7LDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZx dW90OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQw ODY0MWQ3Njc2ZWU3IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTc8 L3NwYW4+PC9hPiZxdW90Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IF0s PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJnF1b3Q7ZXZlbnQmcXVvdDs6 IHs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVv dDtldmVudF90eXBlJnF1b3Q7OiAmcXVvdDt1cm46aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpjcmVh dGUmcXVvdDssPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJnF1b3Q7cmVmJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5j b20vVXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9Vc2Vycy80NGY2 MTQyZGY5NmJkNmFiNjFlNzUyMWQ5PC9zcGFuPjwvYT4mcXVvdDssPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7YXR0cmlidXRlcyZxdW90Ozog WyZxdW90O2lkJnF1b3Q7LCAmcXVvdDtuYW1lJnF1b3Q7LCAmcXVvdDt1c2VyTmFtZSZxdW90Oywg JnF1b3Q7cGFzc3dvcmQmcXVvdDssICZxdW90O2VtYWlscyZxdW90O108YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyZuYnNwOyB9PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyB9PGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyBEb2VzIGFueW9uZSBpbiB0aGUgd29ya2luZyBncm91cCBoYXZl IHVzZSBjYXNlcyBmb3IgU0VUcyB0aGF0IGNhbm5vdDxicj4NCiZuYnNwOyAmbmJzcDsgYmUgbWV0 IGJ5IHRoaXMgcHJvcG9zZWQgdGV4dD8gV2l0aGluIFJJU0MsIHdlIGlkZW50aWZpZWQgdGhyZWUg dXNlPGJyPg0KJm5ic3A7ICZuYnNwOyBjYXNlcywgd2l0aCBzb2x1dGlvbnMgb3V0bGluZWQgYmVs b3c6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAqKjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg KkV4dGVuc2lvbnMqPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBFdmVudCBleHRlbnNpb24gbWVj aGFuaXNtcyBjYW4gYmUgZGVmaW5lZCBpbnRlcm5hbCB0byB0aGUgZXZlbnQ8YnI+DQombmJzcDsg Jm5ic3A7IG9iamVjdC4gQSBzaW1wbGUgYXBwcm9hY2ggd291bGQgYmUgdG8gJm5ic3A7ZGVmaW5l IGFuIOKAnGV4dGVuc2lvbnPigJ0gbWVtYmVyPGJyPg0KJm5ic3A7ICZuYnNwOyB0aGF0IGlzIGEg bGlzdCBvZiBldmVudCBvYmplY3RzIChvciBzZXQgcmVzZW1ibGluZyB0aGUg4oCcZXZlbnRz4oCd PGJyPg0KJm5ic3A7ICZuYnNwOyBjbGFpbSBhcyBkZWZpbmVkIGluIHRoZSBjdXJyZW50IHNwZWMp LiBUaGlzIGhhcyB0aGUgYWR2YW50YWdlIG9mPGJyPg0KJm5ic3A7ICZuYnNwOyBtYWtpbmcgaXQg Y2xlYXIgaW4gdGhlIGRhdGEgc3RydWN0dXJlIHRoYXQgdGhlcmUgaXMgYSBzaW5nbGUgcHJpbWFy eTxicj4NCiZuYnNwOyAmbmJzcDsgZXZlbnQsIHdpdGggemVybyBvciBtb3JlIGV4dGVuc2lvbnMu IFRoZXJlIGlzIG5vIHJvb20gZm9yIGNvbmZ1c2lvbjxicj4NCiZuYnNwOyAmbmJzcDsgb3ZlciB3 aGljaCBldmVudCBpcyBwcmltYXJ5LCBvciBpZiB0aGVyZSBpcyBhIHByaW1hcnkgZXZlbnQgYXQg YWxsLjxicj4NCiZuYnNwOyAmbmJzcDsgSSB3b3VsZCBiZSBmaW5lIHdpdGggYWRkaW5nIHNvbWV0 aGluZyBsaWtlIHRoaXMgdG8gbXkgcHJvcG9zZWQgdGV4dCw8YnI+DQombmJzcDsgJm5ic3A7IGlm IHRoZXJlIGlzIGNvbnNlbnN1cyB0aGF0IGl0IGlzIGJyb2FkbHkgdXNlZnVsLjxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgKkFsaWFzZXMqPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGlzIHVz ZSBjYXNlIHdhcyBicm91Z2h0IHVwIGluIHRoZSBjb250ZXh0IG9mIG1pZ3JhdGluZyBjbGllbnRz PGJyPg0KJm5ic3A7ICZuYnNwOyBmcm9tIGRyYWZ0IGV2ZW50IG5hbWVzIHRvIHN0YW5kYXJkaXpl ZCBldmVudCBuYW1lcy4gSW4gdGhpcyBjYXNlLDxicj4NCiZuYnNwOyAmbmJzcDsgdGhlIGV2ZW50 IHRyYW5zbWl0dGVyIGNhbiB0cmFuc21pdCB0d28gdG9rZW5zIGZvciB0aGUgbG9naWNhbCBldmVu dCw8YnI+DQombmJzcDsgJm5ic3A7IG9uZSB1c2luZyB0aGUgb2xkIG5hbWUgYW5kIGFub3RoZXIg dXNpbmcgdGhlIG5ldyBuYW1lLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgKlJlbGF0ZWQgRXZl bnRzKjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgVGhlIFNFVCBzcGVjIGRlZmluZXMgdGhlIHR4 biBjbGFpbSBhcyBhIG1lYW5zIG9mIGNvcnJlbGF0aW5nPGJyPg0KJm5ic3A7ICZuYnNwOyBpbmRl cGVuZGVudCB0b2tlbnMgdGhhdCByZWxhdGUgdG8gdGhlIHNhbWUgbG9naWNhbCBldmVudC48YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7IC0tPHNwYW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkz NW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAz NDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQombmJzcDsgJm5i c3A7IEFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEFt YXpvbiDigJMgSWRlbnRpdHkgU2VydmljZXM8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZu YnNwOyBJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9 Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2 NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNw YW4gY2xhc3M9Im0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4 Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGll dGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJtLTQz Nzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcw M200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNB ZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDty PUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209czVieUJl NUtBTm5HVnVBYjFtQXVwRUdvSm44WEc1SklVVXdXR0ZTaWJFYyZhbXA7cz1YOG9SU3EzSXpsRjdq aVJBZVpoWHBSM2VWSTBJNThaRmQ0ZUVaZmd5b0lZJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRl dmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBr S1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xM SUdrJmFtcDttPXM1YnlCZTVLQU5uR1Z1QWIxbUF1cEVHb0puOFhHNUpJVVV3V0dGU2liRWMmYW1w O3M9WDhvUlNxM0l6bEY3amlSQWVaaFhwUjNlVkkwSTU4WkZkNGVFWmZneW9JWSZhbXA7ZT08L3Nw YW4+PC9hPjxicj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed01GYVEmYW1w O2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVG VnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPVlCQ0dsSzltampo Y0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmYW1wO3M9V3JNdVFSd0xWODAyaU1RNHdZ QjFmMnJGVUd1NHpiaGNXMDAxZkswMkVYcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lkLWV2ZW50PC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNRmFRJmFtcDtj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6 QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1ZQkNHbEs5bWpqaGNG c2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtzPVdyTXVRUndMVjgwMmlNUTR3WUIx ZjJyRlVHdTR6YmhjVzAwMWZLMDJFWHMmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZC1ldmVudDwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGJyIGNs ZWFyPSJhbGwiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4tLTxzcGFuIGNsYXNzPSJt LTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2 MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlN1YnNjcmli ZSB0byB0aGU8c3BhbiBjbGFzcz0ibS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEw MjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZhbXA7ZD1Ed01GYVEm YW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1u YTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPVlCQ0dsSzlt ampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmYW1wO3M9TFlONzJHZ0tWaEhzVDZ0 QXFCZS1lTW9XTXZ5XzdkZkZuMXVaMEhLNll1USZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5IQVJEVFdBUkU8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJt LTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2 MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+bWFpbA0KIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uITwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQt ZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5J ZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lD QWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7 cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPVlCQ0ds SzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmYW1wO3M9V3JNdVFSd0xWODAy aU1RNHdZQjFmMnJGVUd1NHpiaGNXMDAxZkswMkVYcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19p ZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdx SXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFM Y0xONEtaTkEmYW1wO209WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFp dyZhbXA7cz1Xck11UVJ3TFY4MDJpTVE0d1lCMWYyckZVR3U0emJoY1cwMDFmSzAyRVhzJmFtcDtl PTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7YmFja2dyb3VuZDp3aGl0ZSI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPklkLWV2ZW50IG1h aWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGU7YmFj a2dyb3VuZDp3aGl0ZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv X2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2 N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkx YUxjTE40S1pOQSZhbXA7bT1VLWE1SEJORDBIYVRYNGFuTlpmelg3cERzZks1ZjBoOW1aOUNaa2tH aWVjJmFtcDtzPXJ2ZHJ0STdyWU5SQW5xWkRsdEN3QkFaVkhLcC1NSjIwdWkybm00NlFTejAmYW1w O2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGU7YmFja2dy b3VuZDp3aGl0ZSI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3 SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFt cDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209VS1h NUhCTkQwSGFUWDRhbk5aZnpYN3BEc2ZLNWYwaDltWjlDWmtrR2llYyZhbXA7cz1ydmRydEk3cllO UkFucVpEbHRDd0JBWlZIS3AtTUoyMHVpMm5tNDZRU3owJmFtcDtlPTwvc3Bhbj48L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxi cj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPi0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+U3Vic2NyaWJlIHRvIHRoZTxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJl LmNvbV8mYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1V QjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40 S1pOQSZhbXA7bT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JmFt cDtzPXd0Z0QzTnAwdnloTGRwRXdVaXFzZjRJdGl3QTNPbTdHcm9iNzBMeDByM2smYW1wO2U9IiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SEFSRFRXQVJFPC9zcGFu PjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+bWFp bA0KIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uITxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1w O2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9K bkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7 bT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JmFtcDtzPU9lMHFm TEVYODN2dFhNN1dsMmNZQmUtR2cxRFZQamhYalZKa2ZoVlJ6d2MmYW1wO2U9IiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5m b19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhC djdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJ MWFMY0xONEtaTkEmYW1wO209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9x U0NfdyZhbXA7cz1PZTBxZkxFWDgzdnRYTTdXbDJjWUJlLUdnMURWUGpoWGpWSmtmaFZSendjJmFt cDtlPTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4tLTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlN1YnNjcmliZSB0 byB0aGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEg aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0Ff X2hhcmR0d2FyZS5jb21fJmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBa aDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQ a0FJMWFMY0xONEtaTkEmYW1wO209c0lHejhndXI0d05xWmt0Y21hZ3Y1RWEyMVFFaXA0SFhwRVZL UmEwcWhsbyZhbXA7cz1WOWd5VFRYOXF1anJDMlZsaXdMUHkwLUt2eFM5cFlLSl8ta3lEYXB3Tzhr JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkhBUkRU V0FSRTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPm1haWwNCiBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBv biE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4tLTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PlN1YnNjcmliZSB0byB0aGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hD Z2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0 RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209c0lHejhndXI0d05xWmt0Y21hZ3Y1RWEy MVFFaXA0SFhwRVZLUmEwcWhsbyZhbXA7cz1WOWd5VFRYOXF1anJDMlZsaXdMUHkwLUt2eFM5cFlL Sl8ta3lEYXB3TzhrJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPkhBUkRUV0FSRTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPm1haWwNCiBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkg YW0gd29ya2luZyBvbiE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4tLTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj5TdWJzY3JpYmUgdG8gdGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1 bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5x V055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPXNJR3o4Z3VyNHdOcVprdGNtYWd2 NUVhMjFRRWlwNEhYcEVWS1JhMHFobG8mYW1wO3M9VjlneVRUWDlxdWpyQzJWbGl3TFB5MC1LdnhT OXBZS0pfLWt5RGFwd084ayZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5IQVJEVFdBUkU8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5tYWlsDQogbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0 cyBJIGFtIHdvcmtpbmcgb24hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtiYWNrZ3JvdW5kOndoaXRlIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48 YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SWQtZXZlbnQgbWFpbGluZyBsaXN0 PC9zcGFuPjxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlO2JhY2tncm91bmQ6d2hpdGUiPklkLWV2ZW50QGll dGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJU V21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209c0lHejhndXI0d05xWmt0 Y21hZ3Y1RWEyMVFFaXA0SFhwRVZLUmEwcWhsbyZhbXA7cz1nZE5yczdVREF0dHBhYmpNNW5kT1h3 V0ttWnVLYVhFYlQ1d3U5cmNPUlYwJmFtcDtlPSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJw bGU7YmFja2dyb3VuZDp3aGl0ZSI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50 JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVh cElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEm YW1wO209c0lHejhndXI0d05xWmt0Y21hZ3Y1RWEyMVFFaXA0SFhwRVZLUmEwcWhsbyZhbXA7cz1n ZE5yczdVREF0dHBhYmpNNW5kT1h3V0ttWnVLYVhFYlQ1d3U5cmNPUlYwJmFtcDtlPTwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_EFF86A7A874E4D6787A6C95AC93B3FF6amazoncom_-- From nobody Wed Nov 1 14:38:18 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42A113F6B2 for ; Wed, 1 Nov 2017 14:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 hYsLzunYKgQw for ; Wed, 1 Nov 2017 14:38:10 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68CA13F6AC for ; Wed, 1 Nov 2017 14:38:09 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id h70so9301798ioi.4 for ; Wed, 01 Nov 2017 14:38:09 -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=6mtHyE6/0PX8zKJ/ofGbHgTtCfJR90HH17CPeW2n2bo=; b=GE+A1V8k3pX5jnSVDUOadptmeh3sxIvXtAURn4y4cL9rNsIKMvbZCmVfmvv+KF0KqQ k9IE16TbjXv8MIbNZqkAhV6T1UVPMkI2VFZIlYkJp80W7qw9AntFQ9vNxv+5UbzRTUyo 2HuLiBQSMlMuSfGyMvFGEOqSZWW0ZJYpAKyxCyqGfcasehBbJgj4Yt9ovsNffvl1q8Bp L3LsWcnkr+uvjZsN9cxQDmf1NsRuiYBo/NHCakT88zcetWdWNSzdf/90XR4f99CgQ+y0 AsU5LLoB4Q1ytBG0X5xRh1Zye9likKtFQPseBv1fCyxuWv6KBeb8VEgAptR5ebb7RXHD EDng== 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=6mtHyE6/0PX8zKJ/ofGbHgTtCfJR90HH17CPeW2n2bo=; b=g9XAPquKIPGei8ZjT3+C/vNBgAmIM1wIj+yICjGGJO3qGPKlaz9IzkrGVsbC9v9W3a huqvNDu2/am+jzQp8JD0cgG+7Knty8qUJsDxL0KHoFkEBe5I//DVR/PT6SNXKN/0cJv+ SmPczxY83baTsZqFzXrL5uy0dx0C2FEqdtyIho5Fv4N9zByLQXJs65qvRYvYsb0Ow7RG Kl28BzJUa3qqRQBLlHjOg5KRasDp5oE7DS5iL1V3T2DZcr/8LNZU6/zmr44G2/LHv8z9 s8i6NFTuZ5G811NFFYRJhRXBgBnEAzC6JkWPqH6HJE9D0Wy7WLA0tfppjM+OoKpXL5+9 fVfA== X-Gm-Message-State: AMCzsaU/Sg4C4FVDgYR53rjjz/Y0ECl6CFCue4ByImO3nfhDnbo8Ml+1 hD5GMGIoC10FAT5MSU78qybVXXPzRDFGAH2tG5uEyg== X-Google-Smtp-Source: ABhQp+S2Xf5edhIeBvIEDmqgrO+cBa0NtNo/FU0OQu1MMrZBtZMekC7PxufNLJLvLYKb17unDkxEhmaXrdnvpxiDM+k= X-Received: by 10.36.227.7 with SMTP id d7mr2439888ith.141.1509572288221; Wed, 01 Nov 2017 14:38:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.34.9 with HTTP; Wed, 1 Nov 2017 14:37:46 -0700 (PDT) In-Reply-To: References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> From: Marius Scurtescu Date: Wed, 1 Nov 2017 14:37:46 -0700 Message-ID: To: Phil Hunt Cc: "Richard Backman, Annabelle" , Yaron Sheffer , Mike Jones , ID Events Mailing List , Dick Hardt Content-Type: multipart/alternative; boundary="94eb2c111b060111a2055cf2b08c" Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 21:38:17 -0000 --94eb2c111b060111a2055cf2b08c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt wrote: > You can=E2=80=99t really have multiple events (at least of the same type)= . The > current spec can only have one instance of a URI (afaik). > > Note that the spec normatively does not support multiple event SETS. It > currently states: > > events > *The semantics of this claim is to define a set of event statements > that each MAY add additional claims to fully describe a single > logical event* that has occurred (e.g. a state change to a > subject). Multiple event statements of the same type SHALL NOT be > accepted. The "events" claim SHOULD NOT be used to express > multiple logical events. > > > The spec has *always* supported requirements (as stated in the spec) for > multiple separate profile statements (from one or more profile familities= ) > needing to be sent as a single message. It would be INSECURE to force > multiple SETs because the current delivery mechanism only allows one SET = to > be delivered at a time. There is no way to assure that a single receiver > gets all of the SETs it needs in a multi-threaded, multi-node environment > at scale. Assembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a c= ommon state > database is NOT simple nor cost effective. > I totally agree that it is difficult for receivers to receive separate events, in no particular order and correlate based on "txn". But, receivers have to solve this issue regardless of "events" or "event", so it is unrelated to this proposal. > > If we accommodate this in the proposed form, we end up with a complex, > deeply nested JSON structure with the possibility of namespace conflicts. > > IMO The proposal does not simplify, it complicating and limiting. > > The current spec has very clean JSON and avoids namespace conflicts > between profiles. I think we should stay on track with the current draft > and observe the normative text if not make it stronger in regards to > multi-events (understood that Mike may disagree). > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Nov 1, 2017, at 12:18 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Unless the profile guarantees that such related events will always be > included in the same SET, then the receiver has to correlate across SETs > anyway, and multiple events per SET is just giving the receiver another > scenario that they have to support. > > I=E2=80=99ve already provided several other reasons why we should not sup= port > multiple tokens per SET that no one has addressed. Here they are again: > > 1. Multiple event support results in a more complex structure for the > single event use case, which I think we all agree is the majority use = case. > 2. Multiple-event SETs have ambiguous semantics. The presence of two > events A and B in the same SET could mean any of: > 1. A and B are related to the same logical event (i.e. the same > thing as if they were from different SETs that have a common txn). > 2. A is an extension of B. > 3. B is an extension of A. > 4. A is an alias for B, or vice-versa. > 5. A and B are not actually related to one another in any way, and > the transmitter bundled them together because they were going to th= e same > receiver. > 3. Top-level claim semantics become harder to define, as different > profiles may want to use the same claims in different ways. > 4. Event authenticity cannot be verified without having the entire > SET. This forces receivers to expose downstream systems to more inform= ation > necessary, if those systems need to be able to verify authenticity. > > > -- > Annabelle Richard Backman > Amazon =E2=80=93 Identity Services > > > *From: *Mike Jones > *Date: *Wednesday, November 1, 2017 at 11:21 AM > *To: *Dick Hardt > *Cc: *Yaron Sheffer , "Richard Backman, Annabelle" > , ID Events Mailing List , "Phil > Hunt (IDM)" > *Subject: *RE: [Id-event] Use cases for multiple events per SET? > > I completely agree on moving complexity to the issuer over the recipient. > In my view, it=E2=80=99s more complex for recipients to have to correlate= and > process a sequence of multiple SETs providing information about the same > logical event, and validate N signatures, than to receive one SET with al= l > the aspects of the logical event as =E2=80=9Cevents=E2=80=9D fields, with= no correlation > over time then required. > > -- Mike > > *From:* Dick Hardt [mailto:dick.hardt@gmail.com ] > *Sent:* Wednesday, November 1, 2017 9:39 AM > *To:* Mike Jones > *Cc:* Yaron Sheffer ; Richard Backman, Annabelle < > richanna@amazon.com>; ID Events Mailing List ; Phil > Hunt (IDM) > *Subject:* Re: [Id-event] Use cases for multiple events per SET? > > Your comments highlight a couple of points: > > 1) The example is how to have a predefined extension point for extensions > of a specific event, it is not how to add another event. Myself, I think > this is overly complicated. Events should be comparatively static, and as > with many other JSON formats, the receiver should ignore properties it do= es > not understand, which let's new properties be introduced as extensions. > There should not be any conflict as extensions should only be done by the > profile that created the event format to start off with. > > 2) Having an lvalue be a URI is much harder to code against. I'm not sure > why Marius had that in his example. Per the event, the type of the event = is > well defined with > > "event_type": "https://example.com/scim/event/passwordResetExt", > > 3) This thread is about reasons for multiple events to be contained in on= e > set. Your mention of an issuer not wanting to sign separate events as a > reason to allow multiple events. I think we have decided that given a > preference, we will push effort to the transmitter over the receiver as i= n > many use cases there are many more receivers. Given that, it is more > complex for a receiver to have different ways of managing the receipt of > multiple events as not all issuers will bundle the events, so it is simpl= er > to have only one event per SET. Including the separate events with a URI = as > an lvalue is challenging to implement, speaking from experience. > > > > > > > > > > > > > On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones > wrote: > > Marius=E2=80=99 proposed syntax, pasted in below, has exactly this > characteristic. The way I see it, his proposal essentially has a primary > passwordReset event and a secondary passwordResetExt data structure, whic= h > could have been simply another event value in the current draft. > > This breaking change makes the data structures more complicated - not > less. And it makes things that used to be possible impossible, reducing > flexibility to those who would use the spec. > > These seem like bad tradeoffs to me. > > { > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458496025, > "iss": "https://scim.example.com", > "aud": [ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > ], > "event_type": "https://example.com/scim/event/passwordResetExt", > "event": { > "id":"44f6142df96bd6ab61e7521d9", > "extensions": { > "https://example.com/scim/event/passwordResetExt=E2=80=9D: { > "resetAttempts":5, > } > } > } > } > > In particular, it makes it impossible to sign multiple related events > sharing a common claims schema with a single signature by the issuer. It > forces the issuer to do the extra work of signing each of the related > events (or facets of the same logical event) individually and forces the > recipients to do the extra work of checking all those unnecessary > signatures. > > Not every profile will ever have multiple keys in the =E2=80=9Cevents=E2= =80=9D set but > there=E2=80=99s absolutely no reason to preclude it. > > -- Mike > > *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Dick > Hardt > *Sent:* Tuesday, October 31, 2017 9:52 PM > *To:* Mike Jones > *Cc:* Yaron Sheffer ; Richard Backman, Annabelle < > richanna@amazon.com>; ID Events Mailing List ; Phil > Hunt (IDM) > > *Subject:* Re: [Id-event] Use cases for multiple events per SET? > > Please direct me to a proposal that has a "primary" and "secondary" > events. I agree that is undesirable. I would also encourage to engage in > the discussions so that we can drive clarity and simplicity. > > I think the proposal is that there is one event per SET. > > I think having more than one event per SET adds complexity as a receiver > must deal with receiving correlated events in one SET as well as correlat= ed > events in the same SET. > > /Dick > > On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones > wrote: > > I hear you on the fact that different people have joined the effort at > different times. That=E2=80=99s a normal process as an effort builds mom= entum. I > get that not everyone was there when previous consensus calls were taken. > > I should note that I have specific technical objections to the specific > proposed changes being discussed as well. Currently all events in the se= t > have the same syntax. The proposals, as I understand them, revert us to = a > state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and =E2=80=9Cseco= ndary=E2=80=9D events, with different > syntax for the two classes. That=E2=80=99s needlessly more complicated, = adding no > actual value. > > -- Mike > > *From:* Dick Hardt [mailto:dick.hardt@gmail.com] > *Sent:* Tuesday, October 31, 2017 9:37 PM > *To:* Mike Jones > *Cc:* Phil Hunt (IDM) ; Yaron Sheffer < > yaronf.ietf@gmail.com>; Richard Backman, Annabelle ; > ID Events Mailing List > > *Subject:* Re: [Id-event] Use cases for multiple events per SET? > > Mike > > As you well know, many people in a WG don't look closely at a > specification until last call is made. Additionally, we are coming up on > only the 3rd WG meeting. The WG has not existed for very long. While some > of the participants have been working on this for a while, many have not, > and we are looking for consensus across the WG. > > Since SecEvent is a framework that we expect to be profiled, I feel it is > important to ensure that SecEvent specifications are easy for a variety o= f > profiles to adopt, and that the semantics make sense. I also think that > properties that are specific to a profile should be left to that profile > and not be included in SecEvent. > > Since this is a framework, it is expected that as different groups profil= e > it, there will be additional feedback. > > Specifically, as a participant in the RISC profile of SET, a number of > issues in SET have surfaced as the RISC WG has looked at how to use the S= ET. > > As for SET being stable for over a year, there have been a number of > changes to SET since then. I also don't think there was consensus. Before > the WG was formed, I and several others had expressed concern on the desi= gn > of SET when Phil presented it at an IIW session. > > As to taking another year, I am hopeful we can resolve the remaining > issues in SET and publish a new draft for last call. I do not think we wi= ll > need to wait for another WG meeting to ask for last call. > > We also have a number of other documents that are not in last call, and w= e > don't have a WG adopted draft yet for management. So there are still a > number of documents to work through before we have all the bits for someo= ne > to work with. > > I do think we have been making good progress since the last IETF meeting, > and I am hopeful we can keep up this momentum and finalize all the > documents in a timely manner. > > /Dick > > > On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones > wrote: > > It=E2=80=99s hard for me to even express my level of frustration with the= recent > attempts to once again redesign the SecEvent Token spec. We=E2=80=99ve b= een at > this for multiple years because people keep trying to revisit decisions > that were long ago made by consensus. It=E2=80=99s been stable for over = a year and > the majority of WGLC respondents said some variant of =E2=80=9CWorks for = me =E2=80=93 ship > it!=E2=80=9D > > There=E2=80=99s not sufficient justification to try to undo consensus pos= itions > that have been debated and affirmed over and over. Countenancing wholesa= le > changes at this late date is counterproductive in the extreme! > > It=E2=80=99s far better than good enough as-is. In my experience, if we = start > redesigning it, it will result in another year=E2=80=99s delay. It does = something > simple and useful. Please, let=E2=80=99s just ship it, so people can rel= y on it. > > -- Mike > > *From:* Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] > *Sent:* Monday, October 30, 2017 2:42 PM > *To:* Dick Hardt > *Cc:* Yaron Sheffer ; Richard Backman, Annabelle < > richanna@amazon.com>; Mike Jones ; ID Events > Mailing List > > *Subject:* Re: [Id-event] Use cases for multiple events per SET? > > Inline... > > Phil > > > On Oct 30, 2017, at 2:22 PM, Dick Hardt wrote: > > Hi Phil > > Correct me if I am misunderstanding, but there is a RISC profile event > > > > "http://schemas.openid.net/secevent/risc/event-type/ accou= nt-credential-change-required=E2=80=9D > > > > and an SCIM profile event > > > "https://example.com/scim/event/passwordResetExt=E2=80=9D > > > > I'm suggesting that two different events would be sent. Embedding one in > the other does not make sense. > > It is a hypothetical example. Just because you disagree on this does > not mean others are not valid. > > I just picked overlapping proposals that have different meaning (but not > the same) to illustrate the difference from issuing a single set with > different events. > > > As I have stated this is very different from asserting multiple distinct > events in one SET. > > > Also, I think it is simpler to have event_type be at the same level as > event > > > > may be. I was working from Annabelle's proposed format. > > > { > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458496025, > "iss": "https://scim.example.com", > "aud": [ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > ], > "event_type": "https://example.com/scim/event/passwordResetExt", > "event": { > "id":"44f6142df96bd6ab61e7521d9", > "resetAttempts":5 > } > } > > { > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458496025, > "iss": "https://scim.example.com", > "aud": [ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > ], > "event_type": "http://schemas.openid.net/secevent/risc/event-type/ > account-credential-change-required > > ", > "event": { > =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, > =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" > } > } > > > > > > On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt wrote: > > Annabelle/Dick, > > Thanks for the comments. I think we need to examine the consequences of > the proposal in JSON. > > As I stated, what causes most of the issue is the proposed extension > mechanism in the payload (possibly using events in a recursive way). Does > it follow the old format or the new? > > Let=E2=80=99s consider a use case where we have an identity management s= ystem > that uses SCIM, but the SCIM system is also the underlying data store for > Connect. A Password reset might generate the following event which has a= n > extension (conveying reset count) AND overlapping statement from RISC. > BOTH of which might be important to a similar receiver using SCIM and OID= C. > > > *The 03 spec currently would allow:* > > > { > > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "iat": 1458496025, > > "iss": "https://scim.example.com", > > "aud": [ > > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "events": { > > "urn:ietf:params:scim:event:passwordReset": > > { "id":"44f6142df96bd6ab61e7521d9"}, > > "https://example.com/scim/event/passwordResetExt": > > { "resetAttempts":5}, > > "http://schemas.openid.net/secevent/risc/event-type/\ > account-credential-change-required": { > > =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, > > =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" > > } > > } > > } > > > > In the above - each payload is a =E2=80=98peer' and issued without prefer= ence by the transmitter. The receiver can assign priority in its own contex= t if that matters. > > > > *The new proposal:* > > > > { > > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "iat": 1458496025, > > "iss": "https://scim.example.com", > > "aud": [ > > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "event": { > > =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passwordRes= et=E2=80=9D, > > "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, > > =E2=80=9Cevents=E2=80=9D:{ > > ->note =E2=80=A6is this the old or new structure? <- > > "https://example.com/scim/event/passwordResetExt": > > { "resetAttempts":5}, > > "http://schemas.openid.net/secevent/risc/event-type/\ > account-credential-change-required": { > > =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, > > =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" > > } > > } > > } > > } > > > > In the above, sub-events or extensions have a different format. The same = complaint about the original stands. > > > > **OR* (if the receiver cares about RISC more). Note that this leads to a= triple nested structure.* > > > > { > > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "iat": 1458496025, > > "iss": "https://scim.example.com", > > "aud": [ > > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "event": { > > =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/ris= c/event-type/\ > > account-credential-change-required=E2=80=9D, > > =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, > > =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, > > =E2=80=9Cevents=E2=80=9D:{ > > "urn:ietf:params:scim:event:passwordReset": > > { > > "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, > > =E2=80=9Cevents=E2=80=9D:{ > > "https://example.com/scim/event/passwordResetExt": > > { "resetAttempts":5}, > > } > > } > > } > > } > > } > > > > In the above, the extension is placed inside the event it extends. It fol= lows the old format (or should it follow the new?) > > **OR* Following the top layer pattern of singular event Note that this l= eads to a triple nested structure.* > > > > { > > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "iat": 1458496025, > > "iss": "https://scim.example.com", > > "aud": [ > > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "event": { > > =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/ris= c/event-type/\ > > account-credential-change-required=E2=80=9D, > > =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, > > =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, > > =E2=80=9Cevent=E2=80=9D:{ > > =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:password= Reset=E2=80=9D, > > "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, > > =E2=80=9Cevent=E2=80=9D:{ > > =E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/event/pa= sswordResetExt=E2=80=9D, > > "resetAttempts":5 > > } > > } > > } > > } > > > > This format follows the proposed singular event format recursively and is= 3 layers deep. Note that the parser has to continue to search the document= for things that aren=E2=80=99t there as it has to stop when no =E2=80=9Cev= ent=E2=80=9D attribute is found rather than iterate over an array. > > > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > > phil.hunt@oracle.com > > > On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Replies inline. > > -- > Annabelle Richard Backman > Identity Services > > > *From: *Phil Hunt > *Date: *Sunday, October 29, 2017 at 5:25 PM > *To: *Dick Hardt > *Cc: *Yaron Sheffer , Mike Jones < > Michael.Jones@microsoft.com>, "Richard Backman, Annabelle" < > richanna@amazon.com>, ID Events Mailing List > *Subject: *Re: [Id-event] Use cases for multiple events per SET? > > I hope this answers your question. > > My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reason why not= . The question should be, > what is the justification to make =E2=80=9Cevents=E2=80=9D singular? > [richanna]The singular =E2=80=9Cevent=E2=80=9D claim has clearer semantic= s and is easier > to process. We should opt for easier solutions unless there are use cases > that require more complexity.[/richanna] > > There are many reasons for multiple events in a SET. Some are good, some > not so good. Some of the reasons... > > 1. Multiple event payloads expressing statements about largely the > *same*thing. For example, SCIM password reset AND RISC password reset. A > RISC Event and an OpenBanking Event. Is one a complement to the other? D= o > they overlap or are they distinct? > [richanna]Copy/pasted from my earlier email: > Why is it necessary or appropriate to include these events in the same > SET? They are likely being generated by different systems at different > times on the transmitter=E2=80=99s side, consumed by different systems on= the > receiver=E2=80=99s side, and possibly being transmitted over different ev= ent > streams. I know the latter would be the case for us, as a receiver. Even = if > it=E2=80=99s not, is it burdensome to send these events separately? What = value is > gained in combining them? > > Additionally, since the signature is over the SET and not the event > objects, Receivers independently route separate events from a single toke= n > without either losing the ability to verify the authenticity of the event > or sharing all information in the SET with every system handling any even= t > in the token.[/richanna] > > > 2. Multiple events payloads expressing different statements about the > same transaction - RISC Password Reset and RISC Session Cancel > [richanna]Same as above[/richanna] > 3. A new profile defines new event attributes to be added on to an > existing event type (a pure extension) > [richanna]I have suggested a way to support extensions within an event > body, multiple times now. If you see problems with it, please point them > out.[/richanna] > > I think it is quite valid to allow 1 and 3. 2 could be limited by > specific profiles like RISC if they want. > > I am not in agreement that making event singular simplifies anything. For > one is makes extensions complex (another nested JSON structure) and > potentially conflicting. > [richanna] > Ways that multiple-event SETs are more complicated: > > 1. It results in a more complex structure for the single event use > case, which I think we all agree is the majority use case. > 2. Multiple-event SETs have ambiguous semantics. The presence of two > events A and B in the same SET could mean any of: > > > 1. They are related to the same logical event (i.e. the same thing as > if they were from different SETs that have a common txn). > 2. A is an extension of B. > 3. B is an extension of A. > 4. They are aliases for one another. > 5. They are not actually related to one another in any way. > > > 1. Claim semantics become harder to define, as different profiles may > want to use the same claims in different ways. > > > If the WG wants to block 1 and 2 above, then I believe we have to > establish an event registry to ensure new Event profiles do not overlap t= o > eliminate the need to express multiple events. > [richanna]I=E2=80=99m not sure what you mean by this. Are you referring t= o event > names? Those are already defined by the spec to be URIs.[/richanna] > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > > phil.hunt@oracle.com > > > On Oct 29, 2017, at 4:12 PM, Dick Hardt wrote: > > Phil: > > In your examples for having a plurality of events, you use the word "may"= , > which leads me to question if a plurality of events is really required in > SET. > > You posit that it will be difficult for a distributed system to correlate > multiple SETs with the same "txn", but the distributed system will > certainly need to correlate events on the same subject -- correlating > events on the same "txn" on the same subject seems fairly simple. > > I think that a receiver will need to correlate multiple SEts on the same > subject, so having multiple events in a SET is redundant, and adds > complexity with no clear benefit that I can see. > > An implementor may choose to send multiple SETs, or send a single SET wit= h > multiple events, so a receiver will need to support both. I prefer we pic= k > one way and minimize the code paths, and we will need to support > correlating across multiple SETs, so that seems the best mechanism. > > Let me know if there is something I missed in my logic. > > /Dick > > > On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer > wrote: > > In that case, let's add text to that effect, e.g. we could add to the > definition of the "events" claim: > > Profiling specifications SHOULD define the allowed event statements, and > MAY restrict their number. For example, some profiles may require this > claim to contain only a single event statement. > > Thanks, > Yaron > > On 24/10/17 22:10, Mike Jones wrote: > > I agree with much of Phil=E2=80=99s rationale here. > > It=E2=80=99s fine for some profiles to say that the =E2=80=9Cevents=E2=80= =9D set must be a > singleton. That doesn=E2=80=99t have to be true for all events. I think= things > are fine as-is. > > -- Mike > > *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Phil > Hunt > *Sent:* Monday, October 23, 2017 8:47 PM > *To:* Richard Backman, Annabelle > *Cc:* ID Events Mailing List > *Subject:* Re: [Id-event] Use cases for multiple events per SET? > > Annabelle, > > I have a number of concerns with this proposal. > > Profiling Independence / Keeping Event Payloads Independent > > Indicating that extensions should be handled by profiles leads to more > inter-operability issues and more importantly intrudes on the Event paylo= ad > space by suggesting a sub-schema creates potential limitations and > conflicts that may add to complexity later on. The current format allows = a > parser to discover and unload one or more JSON payloads which can each ha= ve > independent structure. > > General extensions > > The proposal also rules out general purpose extensions not related to any > specific event. Given the emergence of items like GPRD, I would not want = to > block the ability to add meta-data or other general purpose items. We can > also anticipate some delivery scenarios where additional data might be > required. Even though there is no current planned use, I see no good reas= on > to rule this out. > > Multiple Events From Different Families (vs. Multiple Events from a singl= e > family like RISC) > > In our RISC session we discussed expressing multiple distinct RISC events > in one SET. The discussion was that only one RISC event at a time. We did > not discuss other event profiles. I don=E2=80=99t see a reason to rule ou= t > multi-events from different families at the SET level. Each profile is > expressing slightly different things about the same event. > > I can forsee some cases where it is not clear which is the primary and > which is the extension. There may not be a clear winner. > > A couple of examples (these are necessarily real=E2=80=A6just possibiliti= es): > > * It is probably useful to be able to express simlar/overlapping events > from different SET profiles in one SET. For example a Backchannel Logout= & > a RISC session cancel event. > > * SCIM may want to represent a single transaction as causing multiple > state changes in an event (e.g. a password change causes multiple effects= ). > Having to chase down multiple events and correlate by =E2=80=9Ctxn=E2=80= =9D would be > challenging in a multi-threaded/multi-node delivery system. The SCIM li= st > has not discussed this, but I would not want to block this capability. I= OW > - Just because RISC does not want to express multiple events does not mak= e > this true for other profiles. > > * We may wish to indicate a SCIM Password Reset was performed and a > Logout/session cancellation is expressed at the same time. The events ar= e > related but express different data. > > Avoiding Confusion From Similar Events Originating from the Same > Transaction > > If events are sent separately, then more tracking of state (e.g. by txn) > would be required to ensure similar events are not mistaken or handled as > repeats. While txn provides useful audit analysis capability, I=E2=80=99m= not sure > it can be used in live or near-real time systems given distributed > multi-node, multi-threading architectures. > > Previous Discussion > > I note that I originally raised having an attribute to designate primary > event attribute to alleviate your concern, but this was not accepted. See= : > > * https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html > > > * https://www.ietf.org/mail-archive/web/id-event/current/msg00140.html > > > The consensus, at least as I interpreted it is up to the receiver to > figure this out based on the definitions it has for each event URI and th= e > profiles they represent. IOW - RISC is free to limit that only one RISC > event be expressed at a time. > > Phil > > Oracle Corporation, Identity Cloud Services Architect > > @independentid > > www.independentid.com > > > > > > phil.hunt@oracle.com > > On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle > > wrote: > > The current draft of the SET spec allows for expressing multiple > events within the same token, which introduces additional complexity > and room for ambiguous semantics. We=E2=80=99ve discussed this in the= OIDF > RISC working group and the current consensus there is that RISC will > require that RISC events must be the only event in the SET, having > identified ways to clearly and easily support the handful of use > cases for multiple events per token that people have raised. With > that context in mind, I propose striking the definition of the > =E2=80=9Cevents=E2=80=9D claim from the Security Event Token spec, an= d replacing it > with the following definition for an =E2=80=9Cevent=E2=80=9D claim (s= ingular): > > event > > A JSON object containing an "event_type" member whose value is a URI > representing a type of event defined in a Profiling Specification. > The object MAY otherwise be empty, or MAY contain additional members > as described by the Profiling Specification. > > Here is the example SET from section 2.3, rewritten with this change > mind: > > { > > "jti": "4d3559ec67504aaba65d40b0363faad8", > > "iat": 1458496404, > > "iss": "https://scim.example.com ", > > "aud": [ > > "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "event": { > > "event_type": "urn:ietf:params:scim:event:create", > > "ref": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 > ", > > "attributes": ["id", "name", "userName", "password", "emails"] > > } > > } > > Does anyone in the working group have use cases for SETs that cannot > be met by this proposed text? Within RISC, we identified three use > cases, with solutions outlined below: > > ** > > *Extensions* > > Event extension mechanisms can be defined internal to the event > object. A simple approach would be to define an =E2=80=9Cextensions= =E2=80=9D member > that is a list of event objects (or set resembling the =E2=80=9Cevent= s=E2=80=9D > claim as defined in the current spec). This has the advantage of > making it clear in the data structure that there is a single primary > event, with zero or more extensions. There is no room for confusion > over which event is primary, or if there is a primary event at all. > I would be fine with adding something like this to my proposed text, > if there is consensus that it is broadly useful. > > *Aliases* > > This use case was brought up in the context of migrating clients > from draft event names to standardized event names. In this case, > the event transmitter can transmit two tokens for the logical event, > one using the old name and another using the new name. > > *Related Events* > > The SET spec defines the txn claim as a means of correlating > independent tokens that relate to the same logical event. > > -- > Annabelle Richard Backman > > Amazon =E2=80=93 Identity Services > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > s5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=3D > X8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > -- > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DYBCGlK9mjjhcFsj- > 2tDkn31Auxuruib9KATkRlQG1iw&s=3DWrMuQRwLV802iMQ4wYB1f2rFUGu4zb > hcW001fK02EXs&e=3D > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DU- > a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=3DrvdrtI7rYNRAnqZDltCwBAZVHKp= - > MJ20ui2nm46QSz0&e=3D > > > > > > > -- > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DiyVnrZmr9_ > uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=3DOe0qfLEX83vtXM7Wl2cYBe- > Gg1DVPjhXjVJkfhVRzwc&e=3D > > > > > -- > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > > > > -- > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > > > > -- > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D > sIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=3D > gdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=3D > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --94eb2c111b060111a2055cf2b08c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 1, 2017 at 12:45 PM, Phil Hunt <phil.hunt@orac= le.com> wrote:
You can=E2=80=99t really have multiple events (at= least of the same type).=C2=A0 The current spec can only have one instance= of a URI (afaik). =C2=A0

Note that the spec normatively= does not support multiple event SETS.=C2=A0 It currently states:
events
      The semantics of this claim is to define a set of event statements
      that each MAY add additional claims to fully describe a single
      logical event that has occurred (e.g. a state change to a
      subject).  Multiple event statements of the same type SHALL NOT be
      accepted.  The "events" claim SHOULD NOT be used to express
      multiple logical events.

The sp= ec has *always* supported requirements (as stated in the spec) for multiple= separate profile statements (from one or more profile familities) needing = to be sent as a single message.=C2=A0 It would be INSECURE to force multipl= e SETs because the current delivery mechanism only allows one SET to be del= ivered at a time. There is no way to assure that a single receiver gets all= of the SETs it needs in a multi-threaded, multi-node environment at scale.= =C2=A0 Assembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a common = state database is NOT simple nor cost effective.

I totally agree that it is difficult for rece= ivers to receive separate events, in no particular order and correlate base= d on "txn". But, receivers have to solve this issue regardless of= "events" or "event", so it is unrelated to this propos= al.

=C2=A0

If we accomm= odate this in the proposed form, we end up with a complex, deeply nested JS= ON structure with the possibility of namespace conflicts.

IMO The proposal does not simplify, it complicating and limiting. = =C2=A0

The current spec has very clean JSON and av= oids namespace conflicts between profiles. I think we should stay on track = with the current draft and observe the normative text if not make it strong= er in regards to multi-events (understood that Mike may disagree).

Phil
<= div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-i= ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap= :break-word">

Oracle Corporation, Identity Cloud Services Architec= t
@independentid
=
phil.hunt@oracle.com

On Nov 1, 2017, at 12:18 PM, Richar= d Backman, Annabelle <richanna@amazon.com> wrote:

Unles= s the profile guarantees that such related events will always be included i= n the same SET, then the receiver has to correlate across SETs anyway, and = multiple events per SET is just giving the receiver another scenario that t= hey have to support.
=C2=A0
I=E2=80=99ve already provided several other reasons why we shoul= d not support multiple tokens per SET that no one has addressed. Here they = are again:
  1. Multiple event support results in a more complex structure for the s= ingle event use case, which I think we all agree is the majority use case.<= u>
  2. = Multiple-event SETs have ambiguous semantics. The presence of two events A = and B in the same SET could mean any of:
    1. A and B are related to the same logical eve= nt (i.e. the same thing as if they were from different SETs that have a com= mon txn).
    2. A is an extension of B.
    3. B is an extension of A.
    4. A is an alias for= B, or vice-versa.
    5. A and B are not actually related to one another in any w= ay, and the transmitter bundled them together because they were going to th= e same receiver.
  3. Top-level claim semantics become harder to defin= e, as different profiles may want to use the same claims in different ways.=
  4. Event authenticity cannot be verified without having the entire SET. This = forces receivers to expose downstream systems to more information necessary= , if those systems need to be able to verify authenticity.
=C2=A0
--=C2=A0
Annabelle Richard Backman<= /div>
Amazon =E2=80=93 Identity Services
=C2=A0
=C2=A0
From:=C2=A0Mike Jones <= ;Michael.Jones@microsoft.com>
Date:=C2=A0Wednesday, November= 1, 2017 at 11:21 AM
To:=C2=A0Dick Hardt <dick.hardt@gmail.com><= br>Cc:=C2=A0<= /span>Yaron Sheffer <yaronf.ietf@gmail.com>, "Richard B= ackman, Annabelle" <richanna@amazon.com>, ID Events Mailing= List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hu= nt@oracle.com>
Subject:=C2=A0RE: [Id-event] Use cases for multiple = events per SET?
=C2= =A0
I comple= tely agree on moving complexity to the issuer over the recipient.=C2=A0 In = my view, it=E2=80=99s more complex for recipients to have to correlate and = process a sequence of multiple SETs providing information about the same lo= gical event, and validate N signatures, than to receive one SET with all th= e aspects of the logical event as =E2=80=9Cevents=E2=80=9D fields, with no = correlation over time then required.
= =C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke
From:=C2=A0Dick Hardt [mailto:dick.hard= t@gmail.com]= =C2=A0
Sent:=C2=A0Wednesday, November 1, 2017 9:39 AM
To:= =C2=A0Mik= e Jones <Michael.Jones@microsoft.com>
Cc:=C2=A0Yaron Shef= fer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle <richa= nna@amazon.com>; ID Events Mailing List <id-event@ietf.org>; = Phil Hunt (IDM) <phil.hunt@oracle.com>
Subject:=C2=A0Re: [Id-eve= nt] Use cases for multiple events per SET?
=C2= =A0
Your comments highlight a couple= of points:
=C2=A0
1) The example is how to have a predefined extensio= n point for extensions of a specific event, it is not how to add another ev= ent. Myself, I think this is overly complicated. Events should be comparati= vely static, and as with many other JSON formats, the receiver should ignor= e properties it does not understand, which let's new properties be intr= oduced as extensions. There should not be any conflict as extensions should= only be done by the profile that created the event format to start off wit= h.
=C2=A0
=
2) Having an lvalue be a URI is much harder to code against.= I'm not sure why Marius had that in his example. Per the event, the ty= pe of the event is well defined with=C2=A0
=C2=A0
=
=C2=A0
3) This threa= d is about reasons for multiple events to be contained in one set. Your men= tion of an issuer not wanting to sign separate events as a reason to allow = multiple events. I think we have decided that given a preference, we will p= ush effort to the transmitter over the receiver as in many use cases there = are many more receivers. Given that, it is more complex for a receiver to h= ave different ways of managing the receipt of multiple events as not all is= suers will bundle the events, so it is simpler to have only one event per S= ET. Including the separate events with a URI as an lvalue is challenging to= implement, speaking from experience.
=C2=A0
=C2=A0
=C2=A0
=C2=A0=
=C2=A0
=C2=A0
=C2=A0=
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2= =A0
On Tue, Oct 31, 2017 at 11:05 PM, Mik= e Jones <Michael= .Jones@microsoft.com> wrote:
Marius=E2=80= =99 proposed syntax, pasted in below, has exactly this characteristic.=C2= =A0 The way I see it, his proposal essentially has a primary passwordReset = event and a secondary passwordResetExt data structure, which could have bee= n simply another event value in the current draft.
=C2=A0<= /div>
This breaking change make= s the data structures more complicated - not less.=C2=A0 And it makes thing= s that used to be possible impossible, reducing flexibility to those who wo= uld use the spec.
=C2=A0
These seem like bad tradeoffs to me.<= /div>
=C2=A0
{
=C2=A0 "jti": &= quot;3d0c3cf797584bd193bd0fb1bd4e7d30",=
=C2=A0 "iat": 1458496025,
=
=C2=A0 "iss": "https://scim.example.com",
=C2=A0 "aud": [
=C2=A0 =C2=A0],
=C2=A0 =C2=A0"event_type": "https://example.com/scim/eve= nt/passwordResetExt",
=C2=A0 =C2= =A0"event": {=C2=A0=C2=A0
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0"id":"44f6142df96bd6ab61e75= 21d9",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"extensions": {
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"https://example.com/scim/event/password= ResetExt=E2=80=9D: {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"resetAttempts":5,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<= u>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}=
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
= }
= =C2=A0
In particular, it makes it impossible to sign multiple related events sh= aring a common claims schema with a single signature by the issuer.=C2=A0 I= t forces the issuer to do the extra work of signing each of the related eve= nts (or facets of the same logical event) individually and forces the recip= ients to do the extra work of checking all those unnecessary signatures.
=C2=A0=
Not= every profile will ever have multiple keys in the =E2=80=9Cevents=E2=80=9D= set but there=E2=80=99s absolutely no reason to preclude it.=
=C2=A0<= /u>
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 -- Mike
=
From:=C2=A0Id-event [mailto:id-event-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Dick Hardt=
Sent:= =C2=A0Tuesday, October 31, 2017 9:52 PM
To:=C2=A0Mike Jones <Michael.Jones@microsof= t.com>
Cc:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle = <richanna@amazon.com= >; ID Events Mailing List <id-event@ietf.org>; Phil Hunt (IDM) <phil.hunt@oracle.com>

Subject:=C2=A0Re: [Id-event] Use cases for multiple eve= nts per SET?
=C2=A0
Please direct me to a proposal that has a &qu= ot;primary" and "secondary" events. I agree that is undesira= ble. I would also encourage to engage in the discussions so that we can dri= ve clarity and simplicity.
=C2=A0<= u>
I think the proposal is that there is one = event per SET.
=C2=A0=
I think having more than one event per SET adds = complexity as a receiver must deal with receiving correlated events in one = SET as well as correlated events in the same SET.
=
=C2=A0
/Dick<= u>
=C2=A0
On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones <Michael.Jones@microsoft.com> wrote= :
I hear you on the fact that different people hav= e joined the effort at different times.=C2=A0 That=E2=80=99s a normal proce= ss as an effort builds momentum.=C2=A0 I get that not everyone was there wh= en previous consensus calls were taken.
=C2=A0
I should note that I have specific t= echnical objections to the specific proposed changes being discussed as wel= l.=C2=A0 Currently all events in the set have the same syntax.=C2=A0 The pr= oposals, as I understand them, revert us to a state where there=E2=80=99s a= =E2=80=9Cprimary=E2=80=9D and =E2=80=9Csecondary=E2=80=9D events, with dif= ferent syntax for the two classes.=C2=A0 That=E2=80=99s needlessly more com= plicated, adding no actual value.
=C2=A0
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=
=C2=A0=
From:=C2=A0Dick Hardt [mailto:dick.hardt@gmail.com]=C2=A0
Sent:=C2=A0Tuesday, Octob= er 31, 2017 9:37 PM
To:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
Cc:= =C2=A0Phi= l Hunt (IDM) <phil.hunt= @oracle.com>; Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle <= ;richanna@amazon.com>= ;; ID Events Mailing List <id-event@ietf.org>

Su= bject:=C2=A0= Re: [Id-event] Use cases for multiple events per SET?<= /div>
=C2=A0
Mike
=C2=A0
<= div>
As you well know, many people in a WG don't look closely = at a specification until last call is made. Additionally, we are coming up = on only the 3rd WG meeting. The WG has not existed for very long. While som= e of the participants have been working on this for a while, many have not,= and we are looking for consensus across the WG.
<= div>
=C2=A0
Since SecEvent= is a framework that we expect to be profiled, I feel it is important to en= sure that SecEvent specifications are easy for a variety of profiles to ado= pt, and that the semantics make sense. I also think that properties that ar= e specific to a profile should be left to that profile and not be included = in SecEvent.
=C2=A0
Since this is a framework, it is expected that as = different groups profile it, there will be additional feedback.
=C2=A0
Specifically, as a participant in the RISC profile of SET, a number of iss= ues in SET have surfaced as the RISC WG has looked at how to use the SET.
=C2=A0
As for SET being stable for over a year, there have been a numbe= r of changes to SET since then. I also don't think there was consensus.= Before the WG was formed, I and several others had expressed concern on th= e design of SET when Phil presented it at an IIW session.
=C2=A0
As to= taking another year, I am hopeful we can resolve the remaining issues in S= ET and publish a new draft for last call. I do not think we will need to wa= it for another WG meeting to ask for last call.=C2=A0
=C2=A0
We also h= ave a number of other documents that are not in last call, and we don't= have a WG adopted draft yet for management. So there are still a number of= documents to work through before we have all the bits for someone to work = with.
=C2=A0
I do think we have been making good progress since the la= st IETF meeting, and I am hopeful we can keep up this momentum and finalize= all the documents in a timely manner.
=C2=A0
/Dick
=C2=A0
= =C2=A0
On Tue, Oct 31, 2017 at 12:48 PM, = Mike Jones <Mich= ael.Jones@microsoft.com> wrote:
It=E2=80= =99s hard for me to even express my level of frustration with the recent at= tempts to once again redesign the SecEvent Token spec.=C2=A0 We=E2=80=99ve = been at this for multiple years because people keep trying to revisit decis= ions that were long ago made by consensus.=C2=A0 It=E2=80=99s been stable f= or over a year and the majority of WGLC respondents said some variant of = =E2=80=9CWorks for me =E2=80=93 ship it!=E2=80=9D
=C2=A0
There=E2=80=99s not suffic= ient justification to try to undo consensus positions that have been debate= d and affirmed over and over.=C2=A0 Countenancing wholesale changes at this= late date is counterproductive in the extreme!
<= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0
It=E2=80=99s far better than= good enough as-is.=C2=A0 In my experience, if we start redesigning it, it = will result in another year=E2=80=99s delay.=C2=A0 It does something simple= and useful.=C2=A0 Please, let=E2=80=99s just ship it, so people can rely o= n it.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
=C2=A0=
From:= =C2=A0Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=C2=A0
Sent:=C2=A0Monday, October 30, 2017 2:4= 2 PM
To:=C2=A0Dick Hardt <dick.hardt@gmail.com>
Cc:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>; Richard = Backman, Annabelle <rich= anna@amazon.com>; Mike Jones <Michael.Jones@microsoft.com>; ID Events Mailing= List <id-event@ietf.org>


= On Oct 30, 2017, at 2:22 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hi Phil
=C2=A0<= /u>
Correct me if I am misunderstanding, but ther= e is a RISC profile event=C2=A0
=C2=A0
"http://schemas.openid.net/s=
ecevent/risc/event-type/account-credential-change-required=E2=80=9D
=C2=A0
and an SCIM profile event
<= div>
=C2=A0
I'm suggesting that two different= events would be sent. Embedding one in the other does not make sense.
<ph>It is a h= ypothetical example. Just because you disagree on this does not mean others= are not valid.=C2=A0
=C2=A0
I just picked overlapping proposals that have d= ifferent meaning (but not the same) to illustrate the difference from issui= ng a single set with different events.=C2=A0
=
=C2=A0

As I= have stated this is very different from asserting multiple distinct events= in one SET.=C2=A0

=C2=A0=
Also, I think it is simpler to have event_type b= e at the same level as event
=C2=A0

= <ph>may be. I was working from Annabelle's proposed format.=C2=A0=

=C2=A0
<= div>
{
=C2=A0 "jti": "3d0c3cf797584bd= 193bd0fb1bd4e7d30",
=C2=A0 "iat&= quot;: 1458496025,
=C2=A0 "iss": &quo= t;https://scim.example.com",
=
=C2=A0 =C2=A0],=
= =C2=A0 =C2=A0"event": {=C2=A0=C2=A0
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"id":"44f6142df96bd6a= b61e7521d9",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"resetAttempts":5
=C2=A0 =C2=A0= =C2=A0 =C2=A0}
}
=C2=A0
{
=
=C2=A0 "iat": 1458496025,
=C2=A0 "iss": "https://scim.example.com",=
=C2=A0 "aud": [
=C2=A0 =C2=A0],
<= div>
=C2=A0 =C2=A0"event&q= uot;: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=9Csub= =E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
=C2= =A0 =C2=A0 =C2=A0 =C2=A0=E2=80=9Ciss=E2=80=9D:"https://idp.example.com/"=C2=A0 =C2=A0= =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
}
=C2=A0
=C2=A0<= /div>
=C2=A0
= =C2=A0
=C2=A0
On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt <phil.hunt@oracle.com> wrot= e:
Annabel= le/Dick,
=C2=A0
=
Thanks for the comments. I think we need to examine th= e consequences of the proposal in JSON.
=C2=A0
As I stated, what causes mos= t of the issue is the proposed extension mechanism in the payload (possibly= using events in a recursive way). Does it follow the old format or the new= ?
=C2=A0
Let=E2=80=99s =C2=A0consider a use case where we have an identity m= anagement system that uses SCIM, but the SCIM system is also the underlying= data store for Connect.=C2=A0 A Password reset might generate the followin= g event which has an extension (conveying reset count) AND overlapping stat= ement from RISC.=C2=A0 BOTH of which might be important to a similar receiv= er using SCIM and OIDC. =C2=A0
=C2= =A0
The 03 spec currently would = allow:
=C2=A0
{
=C2=
=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30"=
,
=C2=A0 "iat": 1458496025,=

=C2=A0 "iss": "https://scim.example.com"=
,
=C2=A0 "aud": [=

=C2=A0=C2=A0=C2=A0 "https://jhub.examp=
le.com/Feeds/98d52461fa5bbc879593b7754",
=C2=A0=C2=A0=C2=A0 "https://jhub.example.com=
/Feeds/5d7604516b1d08641d7676ee7"
=C2=A0=C2=A0 ],
=C2=
=A0=C2=A0 "events": {
=C2=
=A0=C2=A0=C2=A0=C2=A0 "urn:ietf:params:scim:event:passwordReset&q=
uot;:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 { "id":"44f6142df96bd6ab61e7521d9"},=

=C2=A0=C2=A0=C2=A0=C2=A0 "https://example.co=
m/scim/event/passwordResetExt":
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAttempts":5=
},
=C2=
=A0=C2=A0=C2=A0=C2=A0 "http://schemas.openid.net/secevent/risc/event-type/\=

=C2=A0 =C2=A0 =C2=A0 =C2=A0account-credential-change-required"=
;: {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Csub=E2=80=
=9D:=E2=80=9D7375626A656374=E2=80=9D,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 =E2=80=9Ciss=E2=80=9D:"https://idp.example.=
com/"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0 }
}
=C2=A0
In the above =
- each payload is a =E2=80=98peer' and issued without preference by the=
 transmitter. The receiver can assign priority in its own context if that m=
atters.
=C2=A0<=
/u>
The new proposal:
= 
=C2=A0
{=

=C2=A0 "jti": "3d0c3cf7975=
84bd193bd0fb1bd4e7d30",
=C2=
=A0 "iat": 1458496025,
=C2=
=A0 "iss": "h=
ttps://scim.example.com",
=
=C2=A0 "aud": [
=C2=A0=C2=
=A0=C2=A0 "https://jhub.example.com/Feeds/98d52461fa5bbc8=
79593b7754",
=C2=A0=C2=A0=C2=
=A0 "https://jhub.example.com/Feeds/5d7604516b1d08641d767=
6ee7"
=C2=A0=C2=A0 ],=

=C2=A0=C2=A0 "event": {=

=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=
=E2=80=9D:"urn:ietf:params:scim:event:passwordReset=E2=80=9D,<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0 "id":=
=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevents=E2=80=9D:{<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0 ->note =E2=80=A6is =
this the old or new structure? <-
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://example.com/scim/event/pa=
sswordResetExt":
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAttempts":5},<=
/u>
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 "http://schemas.openid.net/secevent/risc/event-type=
/\
=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0account-credential-change-=
required": {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ciss=E2=80=9D:"https=
://idp.example.com/"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0 
}=

=C2=A0
In the above, sub-ev=
ents or extensions have a different format. The same complaint about the or=
iginal stands.
=C2=A0
*OR* (if the receiver cares about RISC more).=C2=A0 Note that this l=
eads to a triple nested structure.
=C2=A0
{
= 
=C2=A0 "jti": "3d0c3cf797584bd193bd0=
fb1bd4e7d30",
=C2=A0 "=
iat": 1458496025,
=C2=A0 "i=
ss": "https://scim=
.example.com",
=C2=A0 "=
aud": [
=C2=A0=C2=A0=C2=A0 "=
;https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754&=
quot;,
=C2=A0=C2=A0=C2=A0 "ht=
tps://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"<=
u>
=C2=A0=C2=A0 ],
=C2=A0=C2=A0 "event": {
=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/risc/event-typ=
e/\
=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0acco=
unt-credential-change-required=
=E2=80=9D,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Csub=E2=80=9D:=E2=80=
=9D7375626A656374=E2=80=9D,
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=E2=80=9Ciss=E2=
=80=9D:"https://idp.example.com/=E2=80=9C,<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevents=E2=80=9D:{=

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 "urn:ietf:params:scim:event:passwordR=
eset":
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=
=80=9D,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevents=E2=80=9D:{
<= pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courie= r New',serif">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "https://example.com/scim/event/passwordResetExt&qu= ot;:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAttempt=
s":5},=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0}
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0}=

}=

=C2=A0
I=
n the above, the extension is placed inside the event it extends. It follow=
s the old format (or should it follow the new?)
<= /div>
*OR* Following the top layer pattern of singular event=C2=A0 Note tha=
t this leads to a triple nested structure.
=C2=A0
{
=C2=A0 "jti": "3d0c3cf797584=
bd193bd0fb1bd4e7d30",
=C2=
=A0 "iat": 1458496025,
=C2=
=A0 "iss": "h=
ttps://scim.example.com",
=
=C2=A0 "aud": [
=C2=A0=C2=
=A0=C2=A0 "https://jhub.example.com/Feeds/98d52461fa5bbc8=
79593b7754",
=C2=A0=C2=A0=C2=
=A0 "https://jhub.example.com/Feeds/5d7604516b1d08641d767=
6ee7"
=C2=A0=C2=A0 ],=

=C2=A0=C2=A0 "event": {=

=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=
=E2=80=9D:"http://schemas.openid.net/secevent/ri=
sc/event-type/\
=C2=
=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0account-credent=
ial-change-required=E2=80=9D,=

=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=
=80=9D,
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 =E2=80=9Ciss=E2=80=9D:"https://idp.example.c=
om/=E2=80=9C,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent=E2=80=9D:=
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:=
"urn:ietf:params:scim:event:passwordReset=E2=80=9D,=

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "id":=E2=80=9D44f6142d=
f96bd6ab61e7521d9=E2=80=9D,
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent=E2=80=9D:{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 =E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/event/p=
asswordResetExt=E2=80=9D,
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "resetAttempts":=
5 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}<=
/pre>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=C2=A0=C2=A0=
=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0}
}
=C2=A0
This format follows the proposed singular event format =
recursively and is 3 layers deep. Note that the parser has to continue to s=
earch the document for things that aren=E2=80=99t there as it has to stop w=
hen no =E2=80=9Cevent=E2=80=9D attribute is found rather than iterate over =
an array.
=C2=A0<=
u>
Phil

Oracle Corporation, Identity C= loud Services Architect
@independentid
w= ww.independentid.com
phil.hunt@oracle.com
=C2=A0
On Oct 30, 2017, at 8:57 AM, Richard= Backman, Annabelle <ric= hanna@amazon.com> wrote:
=C2=A0
Replies inline.
=C2=A0=
--=C2=A0
Annabel= le Richard Backman
Identity Services
=
=C2=A0
=C2=A0
From:=C2=A0Phil Hunt <phil.hunt@oracle.com>
Date:=C2=A0S= unday, October 29, 2017 at 5:25 PM
To:=C2=A0Dick Hardt <dick= .hardt@gmail.com>
Cc:=C2=A0Yaron Sheffer <yar= onf.ietf@gmail.com>, Mike Jones <Michael.Jones@m= icrosoft.com>, "Richard Backman, Annabelle" <r= ichanna@amazon.com>, ID Events Mailing List <id-event@ietf= .org>
Subject:=C2=A0Re: [Id-event] Use cases for mult= iple events per SET?
=C2=A0
=
I hope this answers your question.<= u>
=C2=A0
My= =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reason why not. Th= e question should be, what is the justification to make =E2=80=9Cevents=E2= =80=9D singular?
[richanna]The singular =E2=80=9C= event=E2=80=9D claim has clearer semantics and is easier to process. We sho= uld opt for easier solutions unless there are use cases that require more c= omplexity.[/richanna]
=C2=A0
There are many reasons for multiple event= s in a SET.=C2=A0 Some are good, some not so good. Some of the reasons...
= =C2=A0
1.=C2=A0 Multiple event payloads expressing statements about largely = the *same*thing. For example, SCIM password reset AND RISC password reset.= =C2=A0 A RISC Event and an OpenBanking Event. Is one a complement to the ot= her?=C2=A0 Do they overlap or are they distinct? =C2=A0
=
[richanna]Copy/pasted from my earlier email:
Why is it necessary or appropriate to include these events in the= same SET? They are likely being generated by different systems at differen= t times on the transmitter=E2=80=99s side, consumed by different systems on= the receiver=E2=80=99s side, and possibly being transmitted over different= event streams. I know the latter would be the case for us, as a receiver. = Even if it=E2=80=99s not, is it burdensome to send these events separately?= What value is gained in combining them?
= =C2=A0
Additionally, since the signature i= s over the SET and not the event objects, Receivers independently route sep= arate events from a single token without either losing the ability to verif= y the authenticity of the event or sharing all information in the SET with = every system handling any event in the token.[/richanna]
=C2=A0

2.=C2=A0 Multiple events payloads expr= essing different statements about the same transaction - RISC Password Rese= t and RISC Session Cancel
[richann= a]Same as above[/richanna]

3.=C2=A0 A new profile defines new event att= ributes to be added on to an existing event type (a pure extension)=C2=A0[richanna]I have suggested a way to= support extensions within an event body, multiple times now. If you see pr= oblems with it, please point them out.[/richanna]
=C2=A0
I think it is= quite valid to allow 1 and 3. =C2=A02 could be limited by specific profile= s like RISC if they want.
=C2=A0
I am not in agreement that making event sing= ular simplifies anything. For one is makes extensions complex (another nest= ed JSON structure) and potentially conflicting.=C2=A0
[richanna]
Ways that m= ultiple-event SETs are more complicated:
  • It results in a more complex= structure for the single event use case, which I think we all agree is the= majority use case.
  • Multiple-event SETs have ambiguous semantic= s. The presence of two events A and B in the same SET could mean any of:=
      1. They are related to the s= ame logical event (i.e. the same thing as if they were from different SETs = that have a common txn).
      2. A is an extension of B.<= /li>
      3. B = is an extension of A.
      4. They are aliases for one another.<= u>
      5. They are not actually related to one another in any way.=
    1. Claim seman= tics become harder to define, as different profiles may want to use the sam= e claims in different ways.
    =C2=A0
    If the WG wants to block 1 and 2 above, then= I believe we have to establish an event registry to ensure new Event profi= les do not overlap to eliminate the need to express multiple events.=
    [richanna]I=E2=80=99m not sure what you mean= by this. Are you referring to event names? Those are already defined by th= e spec to be URIs.[/richanna]
    Phil
    =
    =C2=A0=
    Oracle Corpora= tion, Identity Cloud Services Architect
    @independentid
    =
    =C2=A0
    =
    <= div>
    On Oct 29, 2017, at 4:12 PM, Dick Hard= t <dick.hardt@gmail.com> wrote:
    =C2=A0
    Phil:
    =C2=A0
    In your examples for having a plurality o= f events, you use the word "may", which leads me to question if a= plurality of events is really required in SET.
    <= /div>
    =C2=A0
    =
    You posit that it will be diffic= ult for a distributed system to correlate multiple SETs with the same "= ;txn", but the distributed system will certainly need to correlate eve= nts on the same subject -- correlating events on the same "txn" o= n the same subject seems fairly simple.
    =C2=A0
    I think that a receiver will need to cor= relate multiple SEts on the same subject, so having multiple events in a SE= T is redundant, and adds complexity with no clear benefit that I can see.
    =C2=A0<= /span>
    An imp= lementor may choose to send multiple SETs, or send a single SET with multip= le events, so a receiver will need to support both. I prefer we pick one wa= y and minimize the code paths, and we will need to support correlating acro= ss multiple SETs, so that seems the best mechanism.
    =C2=A0
    Let me know if there is some= thing I missed in my logic.
    =C2=A0
    /Dick
    =C2=A0
    <= div>
    =C2=A0
    <= div>
    On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer=C2=A0<yaronf.ietf@gmail.com>=C2=A0wrote:<= u>
    In th= at case, let's add text to that effect, e.g. we could add to the defini= tion of the "events" claim:

    Profiling specifications SHOUL= D define the allowed event statements, and MAY restrict their number. For e= xample, some profiles may require this claim to contain only a single event= statement.

    Thanks,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Yaron

    O= n 24/10/17 22:10, Mike Jones wrote:

    I agree with much of Phil= =E2=80=99s rationale here.

    It=E2=80=99s fine for some profiles to sa= y that the =E2=80=9Cevents=E2=80=9D set must be a singleton.=C2=A0 That doe= sn=E2=80=99t have to be true for all events.=C2=A0 I think things are fine = as-is.

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-- Mike

    *From:* Id-event [mai= lto:id-event-bounces@ietf.org] *On Behalf Of *Phil = Hunt
    *Sent:* Monday, October 23, 2017 8:47 PM
    *To:* Richard Backman, = Annabelle <richanna@amazon.com>
    *Cc:* ID Events Mai= ling List <id-event@ietf.org>
    *Subject:* Re: [Id-event]= Use cases for multiple events per SET?

    Annabelle,

    I have a n= umber of concerns with this proposal.

    Profiling Independence / Keepi= ng Event Payloads Independent

    Indicating that extensions should be h= andled by profiles leads to more inter-operability issues and more importan= tly intrudes on the Event payload space by suggesting a sub-schema creates = potential limitations and conflicts that may add to complexity later on. Th= e current format allows a parser to discover and unload one or more JSON pa= yloads which can each have independent structure.

    General extensions=

    The proposal also rules out general purpose extensions not related = to any specific event. Given the emergence of items like GPRD, I would not = want to block the ability to add meta-data or other general purpose items. = We can also anticipate some delivery scenarios where additional data might = be required. Even though there is no current planned use, I see no good rea= son to rule this out.

    Multiple Events From Different Families (vs. M= ultiple Events from a single family like RISC)

    In our RISC session w= e discussed expressing multiple distinct RISC events in one SET. The discus= sion was that only one RISC event at a time. We did not discuss other event= profiles. I don=E2=80=99t see a reason to rule out multi-events from diffe= rent families at the SET level. Each profile is expressing slightly differe= nt things about the same event.

    I can forsee some cases where it is = not clear which is the primary and which is the extension.=C2=A0 There may = not be a clear winner.

    A couple of examples (these are necessarily r= eal=E2=80=A6just possibilities):

    * It is probably useful to be able = to express simlar/overlapping events from different SET profiles in one SET= .=C2=A0 For example a Backchannel Logout & a RISC session cancel event.=

    * SCIM may want to represent a single transaction as causing multip= le state changes in an event (e.g. a password change causes multiple effect= s). Having to chase down multiple events and correlate by =E2=80=9Ctxn=E2= =80=9D would be challenging in a multi-threaded/multi-node delivery system.= =C2=A0 =C2=A0The SCIM list has not discussed this, but I would not want to = block this capability.=C2=A0 IOW - Just because RISC does not want to expre= ss multiple events does not make this true for other profiles.

    * We = may wish to indicate a SCIM Password Reset was performed and a Logout/sessi= on cancellation is expressed at the same time.=C2=A0 The events are related= but express different data.

    Avoiding Confusion From Similar Events = Originating from the Same Transaction

    If events are sent separately,= then more tracking of state (e.g. by txn) would be required to ensure simi= lar events are not mistaken or handled as repeats. While txn provides usefu= l audit analysis capability, I=E2=80=99m not sure it can be used in live or= near-real time systems given distributed multi-node, multi-threading archi= tectures.

    Previous Discussion

    I note that I originally raised= having an attribute to designate primary event attribute to alleviate your= concern, but this was not accepted. See:

    *=C2=A0https://www.ietf.org/mail-archive/web/id-event/current/msg0= 0406.html

    *=C2=A0https://www.iet= f.org/mail-archive/web/id-event/current/msg00140.html<= br>
    The consensus, at least as I interpreted it is up to the receiver to= figure this out based on the definitions it has for each event URI and the= profiles they represent. IOW - RISC is free to limit that only one RISC ev= ent be expressed at a time.

    Phil

    Oracle Corporation, Identity= Cloud Services Architect

    @independentid

    www.independentid.com=C2=A0    &= lt;http://ww= w.independentid.com>

    phil.hunt@oracle.com=C2=A0<mailto:phil.hunt@oracle.com>

    =C2=A0 = =C2=A0 On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle
    =C2=A0 = =C2=A0 <richanna@amazon.com=C2=A0<mailto:richanna@a= mazon.com>> wrote:

    =C2=A0 =C2=A0 The current draft = of the SET spec allows for expressing multiple
    =C2=A0 =C2=A0 events with= in the same token, which introduces additional complexity
    =C2=A0 =C2=A0 = and room for ambiguous semantics. We=E2=80=99ve discussed this in the OIDF<= br>=C2=A0 =C2=A0 RISC working group and the current consensus there is that= RISC will
    =C2=A0 =C2=A0 require that RISC events must be the only event= in the SET, having
    =C2=A0 =C2=A0 identified ways to clearly and easily = support the handful of use
    =C2=A0 =C2=A0 cases for multiple events per t= oken that people have raised. With
    =C2=A0 =C2=A0 that context in mind, I= propose striking the definition of the
    =C2=A0 =C2=A0 =E2=80=9Cevents=E2= =80=9D claim from the Security Event Token spec, and replacing it
    =C2=A0= =C2=A0 with the following definition for an =E2=80=9Cevent=E2=80=9D claim = (singular):

    =C2=A0 =C2=A0 event

    =C2=A0 =C2=A0 A JSON object c= ontaining an "event_type" member whose value is a URI
    =C2=A0 = =C2=A0 representing a type of event defined in a Profiling Specification.=C2=A0 =C2=A0 The object MAY otherwise be empty, or MAY contain additiona= l members
    =C2=A0 =C2=A0 as described by the Profiling Specification.
    =
    =C2=A0 =C2=A0 Here is the example SET from section 2.3, rewritten with = this change
    =C2=A0 =C2=A0 mind:

    =C2=A0 =C2=A0=C2=A0{

    =C2=A0 = =C2=A0 =C2=A0=C2=A0 "jti": "4d3559ec67504aaba65d40b0363= faad8",

    =C2=A0 =C2=A0 =C2=A0=C2=A0 "iat": 145849= 6404,

    =C2=A0 =C2=A0 =C2=A0=C2=A0"iss": "https://scim= .example.com=C2=A0<https://scim.example.com/&= gt;",

    =C2=A0 =C2=A0 =C2=A0=C2=A0 "aud": [

    =C2= =A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0"h= ttps://scim.example.com/Feeds/98d52461fa5bbc879593b7754",

    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0"    https://scim.example.com/Feeds/5d7604516b1d0864= 1d7676ee7"

    =C2=A0 =C2=A0 =C2=A0=C2=A0 ],

    =C2= =A0 =C2=A0 =C2=A0=C2=A0 "event": {

    =C2=A0 =C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0 "event_type": "urn:ietf:params:scim:event:create",

    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 "ref&qu= ot;: "https://scim.example.com/Us= ers/44f6142df96bd6ab61e7521d9",

    =C2=A0 =C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0 "attributes": ["id", "nam= e", "userName", "password", "emails"]
    =C2=A0 =C2=A0 =C2=A0=C2=A0 }

    =C2=A0 =C2=A0 }

    =C2=A0 =C2= =A0 Does anyone in the working group have use cases for SETs that cannot=C2=A0 =C2=A0 be met by this proposed text? Within RISC, we identified thr= ee use
    =C2=A0 =C2=A0 cases, with solutions outlined below:

    =C2=A0= =C2=A0 **

    =C2=A0 =C2=A0 *Extensions*

    =C2=A0 =C2=A0 Event ext= ension mechanisms can be defined internal to the event
    =C2=A0 =C2=A0 obj= ect. A simple approach would be to =C2=A0define an =E2=80=9Cextensions=E2= =80=9D member
    =C2=A0 =C2=A0 that is a list of event objects (or set rese= mbling the =E2=80=9Cevents=E2=80=9D
    =C2=A0 =C2=A0 claim as defined in th= e current spec). This has the advantage of
    =C2=A0 =C2=A0 making it clear= in the data structure that there is a single primary
    =C2=A0 =C2=A0 even= t, with zero or more extensions. There is no room for confusion
    =C2=A0 = =C2=A0 over which event is primary, or if there is a primary event at all.<= br>=C2=A0 =C2=A0 I would be fine with adding something like this to my prop= osed text,
    =C2=A0 =C2=A0 if there is consensus that it is broadly useful= .

    =C2=A0 =C2=A0 *Aliases*

    =C2=A0 =C2=A0 This use case was bro= ught up in the context of migrating clients
    =C2=A0 =C2=A0 from draft eve= nt names to standardized event names. In this case,
    =C2=A0 =C2=A0 the ev= ent transmitter can transmit two tokens for the logical event,
    =C2=A0 = =C2=A0 one using the old name and another using the new name.

    =C2=A0= =C2=A0 *Related Events*

    =C2=A0 =C2=A0 The SET spec defines the txn = claim as a means of correlating
    =C2=A0 =C2=A0 independent tokens that re= late to the same logical event.

    =C2=A0 =C2=A0 --=C2=A0
    =C2=A0 =C2= =A0 Annabelle Richard Backman

    =C2=A0 =C2=A0 Amazon =E2=80=93 Identit= y Services

    =C2=A0 =C2=A0 ______________________________________= _________
    =C2=A0 =C2=A0 Id-event mailing list
    =C2=A0 =C2=A0=C2=A0Id-eve= nt@ietf.org=C2=A0<mailto:Id-event@ietf.org><= br>=C2=A0 =C2=A0=C2=A0https://urldefense.proofpoint.com/v2/url?u= =3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwI= CAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&= r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Ds5by= Be5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=3DX8oRSq3IzlF7jiRAe= ZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D



    ________= _______________________________________
    Id-event mailing list
    Id= -event@ietf.org
    https://www.ietf.org/mailman/listinfo= /id-event


    _______________________________________________
    Id-e= vent mailing list
    Id-event@ietf.org
    https://www.ietf.= org/mailman/listinfo/id-event


    =C2=A0=
    --=C2=A0=
    = Subscribe to the=C2=A0HA= RDTWARE=C2=A0mail list to learn about projects I am working on!
    =C2=A0
    <= /div>
    ___________________________________________= ____<= br>Id-event mailing list
    Id-event@= ietf.org
    =C2=A0


    =C2=A0
    --
    Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I am working on!=
    =


    Subscribe to the=C2=A0HAR= DTWARE=C2=A0= mail list to learn about projects I am working on!


    =C2=A0
    --
    Subscribe= to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I am = working on!
    <= /span>


    =C2=A0
    --=C2=A0=
    Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I am working on!=
    = _______________________________________________
    Id-event mailing li= st
    Id-event@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ie= tf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1Yum= CXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4Dpc= tyXPpuYqPkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcOR= V0&e=3D


    ______________________________<= wbr>_________________
    Id-event mailing list
    Id-event@ietf.org=
    https://www.ietf.org/mailman/lis= tinfo/id-event


    --94eb2c111b060111a2055cf2b08c-- From nobody Wed Nov 1 14:45:31 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E2813F6A1 for ; Wed, 1 Nov 2017 14:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi2fcjMm2OFi for ; Wed, 1 Nov 2017 14:45:24 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB93813F551 for ; Wed, 1 Nov 2017 14:45:23 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id n89so2936579pfk.11 for ; Wed, 01 Nov 2017 14:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W3s5zh8rZRvvbXo5ZXVKs4UVyCR5jewvahIKdaPeyCA=; b=EwCngmof8JM8Nux+kVS7H6YPhZN3cdv4aldQR2kq78GKdZaT8CJwkcYdGJtSNTesyN qg8oAxgVkGPiUeLrylut2SejW0IKTpHmmByMiqgHKDeDgLo/Ukvv8fFLRikYbWjsQvcB iwwYpQO2QjaBD8WBgkMTS4RxVpSsQuY+1alnXLDhRvTjA+pYcfNCNwPuLRPBXpQHe+FZ fh3CY90nhVCzSaNEdZPfZXzqLCQZeMdFH6jfnbAqDnk1csE4UqNG440cgIPCT48ANVPa h7/ncEakX+l19yS8jVg4IzxuaLFkz+V7vdwk9r8BhdTyqfyQ7hnVbFaEOWHYgU8LrAMm ttlQ== 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=W3s5zh8rZRvvbXo5ZXVKs4UVyCR5jewvahIKdaPeyCA=; b=sOsrqNB+Q2ICQrQZDGfDBm3bg27MK9wxsafIWQtpic1eLG2TwVGINDpV5B48hwYcri gw+b8aZy1cdo6WOneqboi3GHONWV8K3B6/4dgMSam2hadRjVCPmPos3Wj/oSQaKq19Mw kL3lqLgbpTJITHYCPZIw9lAqzdOCItHtCDfJKKJn1P+/Z2DXqF3dpUwYGbyfDf7sdcts HX5rTIwPyFvpjcPJ+Y7Suxlx2P2wr0BmzPHH2rw6xs724b+OpsksTTpRJXBofzzB09Cn 48bpHllBDjrp/PZlO5yFkPZ1E0Ond3m/DPZjb0oS33pB65G3DzdRUU5h6RBk+D1F7fs1 IfTg== X-Gm-Message-State: AMCzsaUfmEwfkU4VShpzoU90Nxji6gVDZu9Z6biFFKKwYLRokX2Xsmox 5ewK8kaBHaZzT5MpfYBCu9ILeiIsS+LfUo6OVZM= X-Google-Smtp-Source: ABhQp+R37CbOn4lU1VDvdwOqBs2SAs8zuqKNAvWV/tqndY5d8CUmAaCusUZcrDhd6kB16O6vQkwlf5ak/FodXxOmLCI= X-Received: by 10.99.132.72 with SMTP id k69mr1235220pgd.141.1509572722956; Wed, 01 Nov 2017 14:45:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.78 with HTTP; Wed, 1 Nov 2017 14:45:02 -0700 (PDT) In-Reply-To: References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> From: Dick Hardt Date: Wed, 1 Nov 2017 14:45:02 -0700 Message-ID: To: Marius Scurtescu Cc: Phil Hunt , "Richard Backman, Annabelle" , Yaron Sheffer , Mike Jones , ID Events Mailing List Content-Type: multipart/alternative; boundary="94eb2c0ba7aeea1ff8055cf2c928" Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 21:45:30 -0000 --94eb2c0ba7aeea1ff8055cf2c928 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Per my earlier message, a receiver will often be receiving events from multiple transmitters for the same subject. The receiver will already need a mechanism to correlate events on the same subject, A transmitter may have different services issuing SETs that are tied to the same event, and have the same transaction, but are transmitted separately. Will this not be the case? Given this, a receiver MUST be doing correlation across SETs. On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu wrote: > On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt wrote: > >> You can=E2=80=99t really have multiple events (at least of the same type= ). The >> current spec can only have one instance of a URI (afaik). >> >> Note that the spec normatively does not support multiple event SETS. It >> currently states: >> >> events >> *The semantics of this claim is to define a set of event statement= s >> that each MAY add additional claims to fully describe a single >> logical event* that has occurred (e.g. a state change to a >> subject). Multiple event statements of the same type SHALL NOT be >> accepted. The "events" claim SHOULD NOT be used to express >> multiple logical events. >> >> >> The spec has *always* supported requirements (as stated in the spec) for >> multiple separate profile statements (from one or more profile familitie= s) >> needing to be sent as a single message. It would be INSECURE to force >> multiple SETs because the current delivery mechanism only allows one SET= to >> be delivered at a time. There is no way to assure that a single receiver >> gets all of the SETs it needs in a multi-threaded, multi-node environmen= t >> at scale. Assembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a = common state >> database is NOT simple nor cost effective. >> > > I totally agree that it is difficult for receivers to receive separate > events, in no particular order and correlate based on "txn". But, receive= rs > have to solve this issue regardless of "events" or "event", so it is > unrelated to this proposal. > > > >> >> If we accommodate this in the proposed form, we end up with a complex, >> deeply nested JSON structure with the possibility of namespace conflicts= . >> >> IMO The proposal does not simplify, it complicating and limiting. >> >> The current spec has very clean JSON and avoids namespace conflicts >> between profiles. I think we should stay on track with the current draft >> and observe the normative text if not make it stronger in regards to >> multi-events (understood that Mike may disagree). >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> On Nov 1, 2017, at 12:18 PM, Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> Unless the profile guarantees that such related events will always be >> included in the same SET, then the receiver has to correlate across SETs >> anyway, and multiple events per SET is just giving the receiver another >> scenario that they have to support. >> >> I=E2=80=99ve already provided several other reasons why we should not su= pport >> multiple tokens per SET that no one has addressed. Here they are again: >> >> 1. Multiple event support results in a more complex structure for the >> single event use case, which I think we all agree is the majority use= case. >> 2. Multiple-event SETs have ambiguous semantics. The presence of two >> events A and B in the same SET could mean any of: >> 1. A and B are related to the same logical event (i.e. the same >> thing as if they were from different SETs that have a common txn). >> 2. A is an extension of B. >> 3. B is an extension of A. >> 4. A is an alias for B, or vice-versa. >> 5. A and B are not actually related to one another in any way, and >> the transmitter bundled them together because they were going to t= he same >> receiver. >> 3. Top-level claim semantics become harder to define, as different >> profiles may want to use the same claims in different ways. >> 4. Event authenticity cannot be verified without having the entire >> SET. This forces receivers to expose downstream systems to more infor= mation >> necessary, if those systems need to be able to verify authenticity. >> >> >> -- >> Annabelle Richard Backman >> Amazon =E2=80=93 Identity Services >> >> >> *From: *Mike Jones >> *Date: *Wednesday, November 1, 2017 at 11:21 AM >> *To: *Dick Hardt >> *Cc: *Yaron Sheffer , "Richard Backman, >> Annabelle" , ID Events Mailing List < >> id-event@ietf.org>, "Phil Hunt (IDM)" >> *Subject: *RE: [Id-event] Use cases for multiple events per SET? >> >> I completely agree on moving complexity to the issuer over the >> recipient. In my view, it=E2=80=99s more complex for recipients to have= to >> correlate and process a sequence of multiple SETs providing information >> about the same logical event, and validate N signatures, than to receive >> one SET with all the aspects of the logical event as =E2=80=9Cevents=E2= =80=9D fields, with >> no correlation over time then required. >> >> -- Mike >> >> *From:* Dick Hardt [mailto:dick.hardt@gmail.com ] >> *Sent:* Wednesday, November 1, 2017 9:39 AM >> *To:* Mike Jones >> *Cc:* Yaron Sheffer ; Richard Backman, Annabelle = < >> richanna@amazon.com>; ID Events Mailing List ; Phil >> Hunt (IDM) >> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >> >> Your comments highlight a couple of points: >> >> 1) The example is how to have a predefined extension point for extension= s >> of a specific event, it is not how to add another event. Myself, I think >> this is overly complicated. Events should be comparatively static, and a= s >> with many other JSON formats, the receiver should ignore properties it d= oes >> not understand, which let's new properties be introduced as extensions. >> There should not be any conflict as extensions should only be done by th= e >> profile that created the event format to start off with. >> >> 2) Having an lvalue be a URI is much harder to code against. I'm not sur= e >> why Marius had that in his example. Per the event, the type of the event= is >> well defined with >> >> "event_type": "https://example.com/scim/event/passwordResetExt", >> >> 3) This thread is about reasons for multiple events to be contained in >> one set. Your mention of an issuer not wanting to sign separate events a= s a >> reason to allow multiple events. I think we have decided that given a >> preference, we will push effort to the transmitter over the receiver as = in >> many use cases there are many more receivers. Given that, it is more >> complex for a receiver to have different ways of managing the receipt of >> multiple events as not all issuers will bundle the events, so it is simp= ler >> to have only one event per SET. Including the separate events with a URI= as >> an lvalue is challenging to implement, speaking from experience. >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones >> wrote: >> >> Marius=E2=80=99 proposed syntax, pasted in below, has exactly this >> characteristic. The way I see it, his proposal essentially has a primar= y >> passwordReset event and a secondary passwordResetExt data structure, whi= ch >> could have been simply another event value in the current draft. >> >> This breaking change makes the data structures more complicated - not >> less. And it makes things that used to be possible impossible, reducing >> flexibility to those who would use the spec. >> >> These seem like bad tradeoffs to me. >> >> { >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "iat": 1458496025, >> "iss": "https://scim.example.com", >> "aud": [ >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> ], >> "event_type": "https://example.com/scim/event/passwordResetExt", >> "event": { >> "id":"44f6142df96bd6ab61e7521d9", >> "extensions": { >> "https://example.com/scim/event/passwordResetExt=E2=80=9D: { >> "resetAttempts":5, >> } >> } >> } >> } >> >> In particular, it makes it impossible to sign multiple related events >> sharing a common claims schema with a single signature by the issuer. I= t >> forces the issuer to do the extra work of signing each of the related >> events (or facets of the same logical event) individually and forces the >> recipients to do the extra work of checking all those unnecessary >> signatures. >> >> Not every profile will ever have multiple keys in the =E2=80=9Cevents=E2= =80=9D set but >> there=E2=80=99s absolutely no reason to preclude it. >> >> -- Mike >> >> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Dick >> Hardt >> *Sent:* Tuesday, October 31, 2017 9:52 PM >> *To:* Mike Jones >> *Cc:* Yaron Sheffer ; Richard Backman, Annabelle = < >> richanna@amazon.com>; ID Events Mailing List ; Phil >> Hunt (IDM) >> >> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >> >> Please direct me to a proposal that has a "primary" and "secondary" >> events. I agree that is undesirable. I would also encourage to engage in >> the discussions so that we can drive clarity and simplicity. >> >> I think the proposal is that there is one event per SET. >> >> I think having more than one event per SET adds complexity as a receiver >> must deal with receiving correlated events in one SET as well as correla= ted >> events in the same SET. >> >> /Dick >> >> On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones >> wrote: >> >> I hear you on the fact that different people have joined the effort at >> different times. That=E2=80=99s a normal process as an effort builds mo= mentum. I >> get that not everyone was there when previous consensus calls were taken= . >> >> I should note that I have specific technical objections to the specific >> proposed changes being discussed as well. Currently all events in the s= et >> have the same syntax. The proposals, as I understand them, revert us to= a >> state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and =E2=80=9Csec= ondary=E2=80=9D events, with different >> syntax for the two classes. That=E2=80=99s needlessly more complicated,= adding no >> actual value. >> >> -- Mike >> >> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >> *Sent:* Tuesday, October 31, 2017 9:37 PM >> *To:* Mike Jones >> *Cc:* Phil Hunt (IDM) ; Yaron Sheffer < >> yaronf.ietf@gmail.com>; Richard Backman, Annabelle = ; >> ID Events Mailing List >> >> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >> >> Mike >> >> As you well know, many people in a WG don't look closely at a >> specification until last call is made. Additionally, we are coming up on >> only the 3rd WG meeting. The WG has not existed for very long. While som= e >> of the participants have been working on this for a while, many have not= , >> and we are looking for consensus across the WG. >> >> Since SecEvent is a framework that we expect to be profiled, I feel it i= s >> important to ensure that SecEvent specifications are easy for a variety = of >> profiles to adopt, and that the semantics make sense. I also think that >> properties that are specific to a profile should be left to that profile >> and not be included in SecEvent. >> >> Since this is a framework, it is expected that as different groups >> profile it, there will be additional feedback. >> >> Specifically, as a participant in the RISC profile of SET, a number of >> issues in SET have surfaced as the RISC WG has looked at how to use the = SET. >> >> As for SET being stable for over a year, there have been a number of >> changes to SET since then. I also don't think there was consensus. Befor= e >> the WG was formed, I and several others had expressed concern on the des= ign >> of SET when Phil presented it at an IIW session. >> >> As to taking another year, I am hopeful we can resolve the remaining >> issues in SET and publish a new draft for last call. I do not think we w= ill >> need to wait for another WG meeting to ask for last call. >> >> We also have a number of other documents that are not in last call, and >> we don't have a WG adopted draft yet for management. So there are still = a >> number of documents to work through before we have all the bits for some= one >> to work with. >> >> I do think we have been making good progress since the last IETF meeting= , >> and I am hopeful we can keep up this momentum and finalize all the >> documents in a timely manner. >> >> /Dick >> >> >> On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones >> wrote: >> >> It=E2=80=99s hard for me to even express my level of frustration with th= e recent >> attempts to once again redesign the SecEvent Token spec. We=E2=80=99ve = been at >> this for multiple years because people keep trying to revisit decisions >> that were long ago made by consensus. It=E2=80=99s been stable for over= a year and >> the majority of WGLC respondents said some variant of =E2=80=9CWorks for= me =E2=80=93 ship >> it!=E2=80=9D >> >> There=E2=80=99s not sufficient justification to try to undo consensus po= sitions >> that have been debated and affirmed over and over. Countenancing wholes= ale >> changes at this late date is counterproductive in the extreme! >> >> It=E2=80=99s far better than good enough as-is. In my experience, if we= start >> redesigning it, it will result in another year=E2=80=99s delay. It does= something >> simple and useful. Please, let=E2=80=99s just ship it, so people can re= ly on it. >> >> -- Mike >> >> *From:* Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] >> *Sent:* Monday, October 30, 2017 2:42 PM >> *To:* Dick Hardt >> *Cc:* Yaron Sheffer ; Richard Backman, Annabelle = < >> richanna@amazon.com>; Mike Jones ; ID >> Events Mailing List >> >> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >> >> Inline... >> >> Phil >> >> >> On Oct 30, 2017, at 2:22 PM, Dick Hardt wrote: >> >> Hi Phil >> >> Correct me if I am misunderstanding, but there is a RISC profile event >> >> >> >> "http://schemas.openid.net/secevent/risc/event-type/ ac= count-credential-change-required=E2=80=9D >> >> >> >> and an SCIM profile event >> >> >> "https://example.com/scim/event/passwordResetExt=E2=80=9D >> >> >> >> I'm suggesting that two different events would be sent. Embedding one in >> the other does not make sense. >> >> It is a hypothetical example. Just because you disagree on this does >> not mean others are not valid. >> >> I just picked overlapping proposals that have different meaning (but not >> the same) to illustrate the difference from issuing a single set with >> different events. >> >> >> As I have stated this is very different from asserting multiple distinct >> events in one SET. >> >> >> Also, I think it is simpler to have event_type be at the same level as >> event >> >> >> >> may be. I was working from Annabelle's proposed format. >> >> >> { >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "iat": 1458496025, >> "iss": "https://scim.example.com", >> "aud": [ >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> ], >> "event_type": "https://example.com/scim/event/passwordResetExt", >> "event": { >> "id":"44f6142df96bd6ab61e7521d9", >> "resetAttempts":5 >> } >> } >> >> { >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "iat": 1458496025, >> "iss": "https://scim.example.com", >> "aud": [ >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> ], >> "event_type": "http://schemas.openid.net/sec >> event/risc/event-type/account-credential-change-required >> >> ", >> "event": { >> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >> } >> } >> >> >> >> >> >> On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt wrote= : >> >> Annabelle/Dick, >> >> Thanks for the comments. I think we need to examine the consequences of >> the proposal in JSON. >> >> As I stated, what causes most of the issue is the proposed extension >> mechanism in the payload (possibly using events in a recursive way). Doe= s >> it follow the old format or the new? >> >> Let=E2=80=99s consider a use case where we have an identity management = system >> that uses SCIM, but the SCIM system is also the underlying data store fo= r >> Connect. A Password reset might generate the following event which has = an >> extension (conveying reset count) AND overlapping statement from RISC. >> BOTH of which might be important to a similar receiver using SCIM and OI= DC. >> >> >> *The 03 spec currently would allow:* >> >> >> { >> >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "iat": 1458496025, >> >> "iss": "https://scim.example.com", >> >> "aud": [ >> >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> >> ], >> >> "events": { >> >> "urn:ietf:params:scim:event:passwordReset": >> >> { "id":"44f6142df96bd6ab61e7521d9"}, >> >> "https://example.com/scim/event/passwordResetExt": >> >> { "resetAttempts":5}, >> >> "http://schemas.openid.net/secevent/risc/event-type/\ >> account-credential-change-required": { >> >> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >> >> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >> >> } >> >> } >> >> } >> >> >> >> In the above - each payload is a =E2=80=98peer' and issued without prefe= rence by the transmitter. The receiver can assign priority in its own conte= xt if that matters. >> >> >> >> *The new proposal:* >> >> >> >> { >> >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "iat": 1458496025, >> >> "iss": "https://scim.example.com", >> >> "aud": [ >> >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> >> ], >> >> "event": { >> >> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passwordRe= set=E2=80=9D, >> >> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >> >> =E2=80=9Cevents=E2=80=9D:{ >> >> ->note =E2=80=A6is this the old or new structure? <- >> >> "https://example.com/scim/event/passwordResetExt": >> >> { "resetAttempts":5}, >> >> "http://schemas.openid.net/secevent/risc/event-type/\ >> account-credential-change-required": { >> >> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >> >> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >> >> } >> >> } >> >> } >> >> } >> >> >> >> In the above, sub-events or extensions have a different format. The same= complaint about the original stands. >> >> >> >> **OR* (if the receiver cares about RISC more). Note that this leads to = a triple nested structure.* >> >> >> >> { >> >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "iat": 1458496025, >> >> "iss": "https://scim.example.com", >> >> "aud": [ >> >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> >> ], >> >> "event": { >> >> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/ri= sc/event-type/\ >> >> account-credential-change-required=E2=80=9D, >> >> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >> >> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >> >> =E2=80=9Cevents=E2=80=9D:{ >> >> "urn:ietf:params:scim:event:passwordReset": >> >> { >> >> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >> >> =E2=80=9Cevents=E2=80=9D:{ >> >> "https://example.com/scim/event/passwordResetExt": >> >> { "resetAttempts":5}, >> >> } >> >> } >> >> } >> >> } >> >> } >> >> >> >> In the above, the extension is placed inside the event it extends. It fo= llows the old format (or should it follow the new?) >> >> **OR* Following the top layer pattern of singular event Note that this = leads to a triple nested structure.* >> >> >> >> { >> >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "iat": 1458496025, >> >> "iss": "https://scim.example.com", >> >> "aud": [ >> >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> >> ], >> >> "event": { >> >> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/ri= sc/event-type/\ >> >> account-credential-change-required=E2=80=9D, >> >> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >> >> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >> >> =E2=80=9Cevent=E2=80=9D:{ >> >> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passwor= dReset=E2=80=9D, >> >> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >> >> =E2=80=9Cevent=E2=80=9D:{ >> >> =E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/event/p= asswordResetExt=E2=80=9D, >> >> "resetAttempts":5 >> >> } >> >> } >> >> } >> >> } >> >> >> >> This format follows the proposed singular event format recursively and i= s 3 layers deep. Note that the parser has to continue to search the documen= t for things that aren=E2=80=99t there as it has to stop when no =E2=80=9Ce= vent=E2=80=9D attribute is found rather than iterate over an array. >> >> >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> Replies inline. >> >> -- >> Annabelle Richard Backman >> Identity Services >> >> >> *From: *Phil Hunt >> *Date: *Sunday, October 29, 2017 at 5:25 PM >> *To: *Dick Hardt >> *Cc: *Yaron Sheffer , Mike Jones < >> Michael.Jones@microsoft.com>, "Richard Backman, Annabelle" < >> richanna@amazon.com>, ID Events Mailing List >> *Subject: *Re: [Id-event] Use cases for multiple events per SET? >> >> I hope this answers your question. >> >> My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reason why no= t. The question should >> be, what is the justification to make =E2=80=9Cevents=E2=80=9D singular? >> [richanna]The singular =E2=80=9Cevent=E2=80=9D claim has clearer semanti= cs and is easier >> to process. We should opt for easier solutions unless there are use case= s >> that require more complexity.[/richanna] >> >> There are many reasons for multiple events in a SET. Some are good, som= e >> not so good. Some of the reasons... >> >> 1. Multiple event payloads expressing statements about largely the >> *same*thing. For example, SCIM password reset AND RISC password reset. = A >> RISC Event and an OpenBanking Event. Is one a complement to the other? = Do >> they overlap or are they distinct? >> [richanna]Copy/pasted from my earlier email: >> Why is it necessary or appropriate to include these events in the same >> SET? They are likely being generated by different systems at different >> times on the transmitter=E2=80=99s side, consumed by different systems o= n the >> receiver=E2=80=99s side, and possibly being transmitted over different e= vent >> streams. I know the latter would be the case for us, as a receiver. Even= if >> it=E2=80=99s not, is it burdensome to send these events separately? What= value is >> gained in combining them? >> >> Additionally, since the signature is over the SET and not the event >> objects, Receivers independently route separate events from a single tok= en >> without either losing the ability to verify the authenticity of the even= t >> or sharing all information in the SET with every system handling any eve= nt >> in the token.[/richanna] >> >> >> 2. Multiple events payloads expressing different statements about the >> same transaction - RISC Password Reset and RISC Session Cancel >> [richanna]Same as above[/richanna] >> 3. A new profile defines new event attributes to be added on to an >> existing event type (a pure extension) >> [richanna]I have suggested a way to support extensions within an event >> body, multiple times now. If you see problems with it, please point them >> out.[/richanna] >> >> I think it is quite valid to allow 1 and 3. 2 could be limited by >> specific profiles like RISC if they want. >> >> I am not in agreement that making event singular simplifies anything. Fo= r >> one is makes extensions complex (another nested JSON structure) and >> potentially conflicting. >> [richanna] >> Ways that multiple-event SETs are more complicated: >> >> 1. It results in a more complex structure for the single event use >> case, which I think we all agree is the majority use case. >> 2. Multiple-event SETs have ambiguous semantics. The presence of two >> events A and B in the same SET could mean any of: >> >> >> 1. They are related to the same logical event (i.e. the same thing as >> if they were from different SETs that have a common txn). >> 2. A is an extension of B. >> 3. B is an extension of A. >> 4. They are aliases for one another. >> 5. They are not actually related to one another in any way. >> >> >> 1. Claim semantics become harder to define, as different profiles may >> want to use the same claims in different ways. >> >> >> If the WG wants to block 1 and 2 above, then I believe we have to >> establish an event registry to ensure new Event profiles do not overlap = to >> eliminate the need to express multiple events. >> [richanna]I=E2=80=99m not sure what you mean by this. Are you referring = to event >> names? Those are already defined by the spec to be URIs.[/richanna] >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> On Oct 29, 2017, at 4:12 PM, Dick Hardt wrote: >> >> Phil: >> >> In your examples for having a plurality of events, you use the word >> "may", which leads me to question if a plurality of events is really >> required in SET. >> >> You posit that it will be difficult for a distributed system to correlat= e >> multiple SETs with the same "txn", but the distributed system will >> certainly need to correlate events on the same subject -- correlating >> events on the same "txn" on the same subject seems fairly simple. >> >> I think that a receiver will need to correlate multiple SEts on the same >> subject, so having multiple events in a SET is redundant, and adds >> complexity with no clear benefit that I can see. >> >> An implementor may choose to send multiple SETs, or send a single SET >> with multiple events, so a receiver will need to support both. I prefer = we >> pick one way and minimize the code paths, and we will need to support >> correlating across multiple SETs, so that seems the best mechanism. >> >> Let me know if there is something I missed in my logic. >> >> /Dick >> >> >> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer >> wrote: >> >> In that case, let's add text to that effect, e.g. we could add to the >> definition of the "events" claim: >> >> Profiling specifications SHOULD define the allowed event statements, and >> MAY restrict their number. For example, some profiles may require this >> claim to contain only a single event statement. >> >> Thanks, >> Yaron >> >> On 24/10/17 22:10, Mike Jones wrote: >> >> I agree with much of Phil=E2=80=99s rationale here. >> >> It=E2=80=99s fine for some profiles to say that the =E2=80=9Cevents=E2= =80=9D set must be a >> singleton. That doesn=E2=80=99t have to be true for all events. I thin= k things >> are fine as-is. >> >> -- Mike >> >> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Phil >> Hunt >> *Sent:* Monday, October 23, 2017 8:47 PM >> *To:* Richard Backman, Annabelle >> *Cc:* ID Events Mailing List >> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >> >> Annabelle, >> >> I have a number of concerns with this proposal. >> >> Profiling Independence / Keeping Event Payloads Independent >> >> Indicating that extensions should be handled by profiles leads to more >> inter-operability issues and more importantly intrudes on the Event payl= oad >> space by suggesting a sub-schema creates potential limitations and >> conflicts that may add to complexity later on. The current format allows= a >> parser to discover and unload one or more JSON payloads which can each h= ave >> independent structure. >> >> General extensions >> >> The proposal also rules out general purpose extensions not related to an= y >> specific event. Given the emergence of items like GPRD, I would not want= to >> block the ability to add meta-data or other general purpose items. We ca= n >> also anticipate some delivery scenarios where additional data might be >> required. Even though there is no current planned use, I see no good rea= son >> to rule this out. >> >> Multiple Events From Different Families (vs. Multiple Events from a >> single family like RISC) >> >> In our RISC session we discussed expressing multiple distinct RISC event= s >> in one SET. The discussion was that only one RISC event at a time. We di= d >> not discuss other event profiles. I don=E2=80=99t see a reason to rule o= ut >> multi-events from different families at the SET level. Each profile is >> expressing slightly different things about the same event. >> >> I can forsee some cases where it is not clear which is the primary and >> which is the extension. There may not be a clear winner. >> >> A couple of examples (these are necessarily real=E2=80=A6just possibilit= ies): >> >> * It is probably useful to be able to express simlar/overlapping events >> from different SET profiles in one SET. For example a Backchannel Logou= t & >> a RISC session cancel event. >> >> * SCIM may want to represent a single transaction as causing multiple >> state changes in an event (e.g. a password change causes multiple effect= s). >> Having to chase down multiple events and correlate by =E2=80=9Ctxn=E2=80= =9D would be >> challenging in a multi-threaded/multi-node delivery system. The SCIM l= ist >> has not discussed this, but I would not want to block this capability. = IOW >> - Just because RISC does not want to express multiple events does not ma= ke >> this true for other profiles. >> >> * We may wish to indicate a SCIM Password Reset was performed and a >> Logout/session cancellation is expressed at the same time. The events a= re >> related but express different data. >> >> Avoiding Confusion From Similar Events Originating from the Same >> Transaction >> >> If events are sent separately, then more tracking of state (e.g. by txn) >> would be required to ensure similar events are not mistaken or handled a= s >> repeats. While txn provides useful audit analysis capability, I=E2=80=99= m not sure >> it can be used in live or near-real time systems given distributed >> multi-node, multi-threading architectures. >> >> Previous Discussion >> >> I note that I originally raised having an attribute to designate primary >> event attribute to alleviate your concern, but this was not accepted. Se= e: >> >> * https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html >> >> >> * https://www.ietf.org/mail-archive/web/id-event/current/msg00140.html >> >> >> The consensus, at least as I interpreted it is up to the receiver to >> figure this out based on the definitions it has for each event URI and t= he >> profiles they represent. IOW - RISC is free to limit that only one RISC >> event be expressed at a time. >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> >> @independentid >> >> www.independentid.com >> >> > >> > >> >> phil.hunt@oracle.com >> >> On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle >> > wrote: >> >> The current draft of the SET spec allows for expressing multiple >> events within the same token, which introduces additional complexity >> and room for ambiguous semantics. We=E2=80=99ve discussed this in th= e OIDF >> RISC working group and the current consensus there is that RISC will >> require that RISC events must be the only event in the SET, having >> identified ways to clearly and easily support the handful of use >> cases for multiple events per token that people have raised. With >> that context in mind, I propose striking the definition of the >> =E2=80=9Cevents=E2=80=9D claim from the Security Event Token spec, a= nd replacing it >> with the following definition for an =E2=80=9Cevent=E2=80=9D claim (= singular): >> >> event >> >> A JSON object containing an "event_type" member whose value is a URI >> representing a type of event defined in a Profiling Specification. >> The object MAY otherwise be empty, or MAY contain additional members >> as described by the Profiling Specification. >> >> Here is the example SET from section 2.3, rewritten with this change >> mind: >> >> { >> >> "jti": "4d3559ec67504aaba65d40b0363faad8", >> >> "iat": 1458496404, >> >> "iss": "https://scim.example.com ", >> >> "aud": [ >> >> "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", >> >> "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" >> >> ], >> >> "event": { >> >> "event_type": "urn:ietf:params:scim:event:create", >> >> "ref": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d= 9 >> ", >> >> "attributes": ["id", "name", "userName", "password", "emails"] >> >> } >> >> } >> >> Does anyone in the working group have use cases for SETs that cannot >> be met by this proposed text? Within RISC, we identified three use >> cases, with solutions outlined below: >> >> ** >> >> *Extensions* >> >> Event extension mechanisms can be defined internal to the event >> object. A simple approach would be to define an =E2=80=9Cextensions= =E2=80=9D member >> that is a list of event objects (or set resembling the =E2=80=9Ceven= ts=E2=80=9D >> claim as defined in the current spec). This has the advantage of >> making it clear in the data structure that there is a single primary >> event, with zero or more extensions. There is no room for confusion >> over which event is primary, or if there is a primary event at all. >> I would be fine with adding something like this to my proposed text, >> if there is consensus that it is broadly useful. >> >> *Aliases* >> >> This use case was brought up in the context of migrating clients >> from draft event names to standardized event names. In this case, >> the event transmitter can transmit two tokens for the logical event, >> one using the old name and another using the new name. >> >> *Related Events* >> >> The SET spec defines the txn claim as a means of correlating >> independent tokens that relate to the same logical event. >> >> -- >> Annabelle Richard Backman >> >> Amazon =E2=80=93 Identity Services >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. >> ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCg >> aWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPE >> ivzjWwlNKe4C_lLIGk&m=3Ds5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFS >> ibEc&s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> >> >> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYq >> PkAI1aLcLN4KZNA&m=3DYBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1i >> w&s=3DWrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=3D >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYq >> PkAI1aLcLN4KZNA&m=3DU-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGie >> c&s=3DrvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm46QSz0&e=3D >> >> >> >> >> >> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYq >> PkAI1aLcLN4KZNA&m=3DiyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_ >> w&s=3DOe0qfLEX83vtXM7Wl2cYBe-Gg1DVPjhXjVJkfhVRzwc&e=3D >> >> >> >> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> >> >> >> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> >> >> >> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYq >> PkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhl >> o&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=3D >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --94eb2c0ba7aeea1ff8055cf2c928 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Per my earlier message, a receiver will often be receiving= events from multiple transmitters for the same subject. The receiver will = already need a mechanism to correlate events on the same subject, A transmi= tter may have different services issuing SETs that are tied to the same eve= nt, and have the same transaction, but are transmitted separately.

    =
    Will this not be the case? Given this, a receiver MUST be doing = correlation across SETs.=C2=A0


    =C2=A0
    =
    --
    Subscribe = to the=C2=A0HARDTWAR= E=C2=A0mail list to learn about projects I am working on!
    <= /div>


    <= u>
    =C2=A0
    --=C2=A0
    = Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I am wor= king on!
    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet= f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumC= XCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4Dpct= yXPpuYqPkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZktcmagv5Ea21QEip4HXpE= VKRa0qhlo&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&= ;e=3D
    =

    ________________________________= _______________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf= .org/mailman/listinfo/id-event





    --
    Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
    --94eb2c0ba7aeea1ff8055cf2c928-- From nobody Wed Nov 1 14:47:26 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2215413F6D4 for ; Wed, 1 Nov 2017 14:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 539BDF6fMpyw for ; Wed, 1 Nov 2017 14:47:16 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE4313F3EE for ; Wed, 1 Nov 2017 14:47:16 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id t11so3060679ywg.12 for ; Wed, 01 Nov 2017 14:47:16 -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=QSv+h28NQusTjWBfAyCc+swdcIF+ekaVTrcvIJ1USkY=; b=FGDjGwBxpYSlfCjJNFCNhlYwegdETOUkrZehWpZusRYBs118coc53JDDsP0WZJHOFM LPhnGSvlvUBbK9rnegxoQz/m/DkukW7CDLL6BbzSQIAKmyk3187EpB9UPaYG8hZ7kCfh tqwmH6igX8cM8PZmhybQYx9deIrp/TsoL3z1ZgesNmOEPA3NQwvy+2H/OB7Psh6y2nun Fg/NHTix4zF7fzwRPvnVnBSUaSh3SDzPQHoFHsXwfoKL7MlnwYU28wOasznk3js9kiUr R92PDP1WBHx4GRR2dUvG2yilbphNCnVYPoLPhynDDuuilNUZFtFfCzYbMbQRdmB28kqi MKYw== 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=QSv+h28NQusTjWBfAyCc+swdcIF+ekaVTrcvIJ1USkY=; b=Rzad/2RyxruMH/No3hYMQLodeA7W+INzsWaETawIrSCInEWjQhgQiRxqwTfcuUbRFg Fvm6p1tWBgifypP5gER9TL+kQSzZeohbidKt1lWBv7Oqq+SgWZMmB54WR0lFKOARnxu2 bTtOGNf7d4WxlbJcJQdQ5kZ2lBAkKLDqCRZNc2Fld7fVEX8xF4/sdF1cJqAqsfprM53Z KAJKkTNdAuF3ZMuLFr5+wodFa+OQLL+ijskGUkzIUK8omI0y7cR7bts57uXQx64a9g0X SGvkIhkbZhqRi2ZSkQrPeWMf1wyoXf4fEX2haOm6H0YiZn7syVZkdefINmmLKUyY1fdI pxhg== X-Gm-Message-State: AMCzsaUs/24hQEmdFOzHeKCufopKPe3kkQH/yIEbP/t4vw7goIHnkjAC LDkX7Y92fWc7fIV0lvp9X2q8ZjUz0fbST3vyEa8usQ== X-Google-Smtp-Source: ABhQp+T+FLE1YnIGo5VapaRVa6JY+Iu37FkdoO8CaWj4UPGWVAzXWpD9gvWuO9MmPc3zPx48cv0SNUYg6C6EmoJUryU= X-Received: by 10.37.87.133 with SMTP id l127mr837304ybb.17.1509572834750; Wed, 01 Nov 2017 14:47:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.122.72 with HTTP; Wed, 1 Nov 2017 14:46:53 -0700 (PDT) In-Reply-To: References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> From: William Denniss Date: Wed, 1 Nov 2017 14:46:53 -0700 Message-ID: To: Marius Scurtescu Cc: Phil Hunt , Yaron Sheffer , "Richard Backman, Annabelle" , Dick Hardt , Mike Jones , ID Events Mailing List Content-Type: multipart/alternative; boundary="001a113ffcf0949d0a055cf2d031" Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 21:47:23 -0000 --001a113ffcf0949d0a055cf2d031 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Perhaps I can try and explain the original intent of the current design. The goal was always that a SET represents a single logical event. However multiple systems may have different representations of the event =E2=80=93 = the example given originally was one formatted for RISC, and one for SCIM. A good analogy is email. You send a single logical email, which may have two representations, HTML and plain text. Systems can consume the version that they understand and ignore the one they don't. I'm starting to regret the plural in "events", it was pluralized due to it being an array, not because it represented multiple logical events. Annabelle, I understand your concerns regarding confusion of the semantics between the JSON syntax and the specification language. Are there other ways to resolve that without removing the ability for multiple representations of the same event? On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu wrote: > On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt wrote: > >> You can=E2=80=99t really have multiple events (at least of the same type= ). The >> current spec can only have one instance of a URI (afaik). >> >> Note that the spec normatively does not support multiple event SETS. It >> currently states: >> >> events >> *The semantics of this claim is to define a set of event statement= s >> that each MAY add additional claims to fully describe a single >> logical event* that has occurred (e.g. a state change to a >> subject). Multiple event statements of the same type SHALL NOT be >> accepted. The "events" claim SHOULD NOT be used to express >> multiple logical events. >> >> >> The spec has *always* supported requirements (as stated in the spec) for >> multiple separate profile statements (from one or more profile familitie= s) >> needing to be sent as a single message. It would be INSECURE to force >> multiple SETs because the current delivery mechanism only allows one SET= to >> be delivered at a time. There is no way to assure that a single receiver >> gets all of the SETs it needs in a multi-threaded, multi-node environmen= t >> at scale. Assembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a = common state >> database is NOT simple nor cost effective. >> > > I totally agree that it is difficult for receivers to receive separate > events, in no particular order and correlate based on "txn". But, receive= rs > have to solve this issue regardless of "events" or "event", so it is > unrelated to this proposal. > > > >> >> If we accommodate this in the proposed form, we end up with a complex, >> deeply nested JSON structure with the possibility of namespace conflicts= . >> >> IMO The proposal does not simplify, it complicating and limiting. >> >> The current spec has very clean JSON and avoids namespace conflicts >> between profiles. I think we should stay on track with the current draft >> and observe the normative text if not make it stronger in regards to >> multi-events (understood that Mike may disagree). >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> On Nov 1, 2017, at 12:18 PM, Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> Unless the profile guarantees that such related events will always be >> included in the same SET, then the receiver has to correlate across SETs >> anyway, and multiple events per SET is just giving the receiver another >> scenario that they have to support. >> >> I=E2=80=99ve already provided several other reasons why we should not su= pport >> multiple tokens per SET that no one has addressed. Here they are again: >> >> 1. Multiple event support results in a more complex structure for the >> single event use case, which I think we all agree is the majority use= case. >> 2. Multiple-event SETs have ambiguous semantics. The presence of two >> events A and B in the same SET could mean any of: >> 1. A and B are related to the same logical event (i.e. the same >> thing as if they were from different SETs that have a common txn). >> 2. A is an extension of B. >> 3. B is an extension of A. >> 4. A is an alias for B, or vice-versa. >> 5. A and B are not actually related to one another in any way, and >> the transmitter bundled them together because they were going to t= he same >> receiver. >> 3. Top-level claim semantics become harder to define, as different >> profiles may want to use the same claims in different ways. >> 4. Event authenticity cannot be verified without having the entire >> SET. This forces receivers to expose downstream systems to more infor= mation >> necessary, if those systems need to be able to verify authenticity. >> >> >> -- >> Annabelle Richard Backman >> Amazon =E2=80=93 Identity Services >> >> >> *From: *Mike Jones >> *Date: *Wednesday, November 1, 2017 at 11:21 AM >> *To: *Dick Hardt >> *Cc: *Yaron Sheffer , "Richard Backman, >> Annabelle" , ID Events Mailing List < >> id-event@ietf.org>, "Phil Hunt (IDM)" >> *Subject: *RE: [Id-event] Use cases for multiple events per SET? >> >> I completely agree on moving complexity to the issuer over the >> recipient. In my view, it=E2=80=99s more complex for recipients to have= to >> correlate and process a sequence of multiple SETs providing information >> about the same logical event, and validate N signatures, than to receive >> one SET with all the aspects of the logical event as =E2=80=9Cevents=E2= =80=9D fields, with >> no correlation over time then required. >> >> -- Mike >> >> *From:* Dick Hardt [mailto:dick.hardt@gmail.com ] >> *Sent:* Wednesday, November 1, 2017 9:39 AM >> *To:* Mike Jones >> *Cc:* Yaron Sheffer ; Richard Backman, Annabelle = < >> richanna@amazon.com>; ID Events Mailing List ; Phil >> Hunt (IDM) >> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >> >> Your comments highlight a couple of points: >> >> 1) The example is how to have a predefined extension point for extension= s >> of a specific event, it is not how to add another event. Myself, I think >> this is overly complicated. Events should be comparatively static, and a= s >> with many other JSON formats, the receiver should ignore properties it d= oes >> not understand, which let's new properties be introduced as extensions. >> There should not be any conflict as extensions should only be done by th= e >> profile that created the event format to start off with. >> >> 2) Having an lvalue be a URI is much harder to code against. I'm not sur= e >> why Marius had that in his example. Per the event, the type of the event= is >> well defined with >> >> "event_type": "https://example.com/scim/event/passwordResetExt", >> >> 3) This thread is about reasons for multiple events to be contained in >> one set. Your mention of an issuer not wanting to sign separate events a= s a >> reason to allow multiple events. I think we have decided that given a >> preference, we will push effort to the transmitter over the receiver as = in >> many use cases there are many more receivers. Given that, it is more >> complex for a receiver to have different ways of managing the receipt of >> multiple events as not all issuers will bundle the events, so it is simp= ler >> to have only one event per SET. Including the separate events with a URI= as >> an lvalue is challenging to implement, speaking from experience. >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones >> wrote: >> >> Marius=E2=80=99 proposed syntax, pasted in below, has exactly this >> characteristic. The way I see it, his proposal essentially has a primar= y >> passwordReset event and a secondary passwordResetExt data structure, whi= ch >> could have been simply another event value in the current draft. >> >> This breaking change makes the data structures more complicated - not >> less. And it makes things that used to be possible impossible, reducing >> flexibility to those who would use the spec. >> >> These seem like bad tradeoffs to me. >> >> { >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "iat": 1458496025, >> "iss": "https://scim.example.com", >> "aud": [ >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> ], >> "event_type": "https://example.com/scim/event/passwordResetExt", >> "event": { >> "id":"44f6142df96bd6ab61e7521d9", >> "extensions": { >> "https://example.com/scim/event/passwordResetExt=E2=80=9D: { >> "resetAttempts":5, >> } >> } >> } >> } >> >> In particular, it makes it impossible to sign multiple related events >> sharing a common claims schema with a single signature by the issuer. I= t >> forces the issuer to do the extra work of signing each of the related >> events (or facets of the same logical event) individually and forces the >> recipients to do the extra work of checking all those unnecessary >> signatures. >> >> Not every profile will ever have multiple keys in the =E2=80=9Cevents=E2= =80=9D set but >> there=E2=80=99s absolutely no reason to preclude it. >> >> -- Mike >> >> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Dick >> Hardt >> *Sent:* Tuesday, October 31, 2017 9:52 PM >> *To:* Mike Jones >> *Cc:* Yaron Sheffer ; Richard Backman, Annabelle = < >> richanna@amazon.com>; ID Events Mailing List ; Phil >> Hunt (IDM) >> >> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >> >> Please direct me to a proposal that has a "primary" and "secondary" >> events. I agree that is undesirable. I would also encourage to engage in >> the discussions so that we can drive clarity and simplicity. >> >> I think the proposal is that there is one event per SET. >> >> I think having more than one event per SET adds complexity as a receiver >> must deal with receiving correlated events in one SET as well as correla= ted >> events in the same SET. >> >> /Dick >> >> On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones >> wrote: >> >> I hear you on the fact that different people have joined the effort at >> different times. That=E2=80=99s a normal process as an effort builds mo= mentum. I >> get that not everyone was there when previous consensus calls were taken= . >> >> I should note that I have specific technical objections to the specific >> proposed changes being discussed as well. Currently all events in the s= et >> have the same syntax. The proposals, as I understand them, revert us to= a >> state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and =E2=80=9Csec= ondary=E2=80=9D events, with different >> syntax for the two classes. That=E2=80=99s needlessly more complicated,= adding no >> actual value. >> >> -- Mike >> >> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >> *Sent:* Tuesday, October 31, 2017 9:37 PM >> *To:* Mike Jones >> *Cc:* Phil Hunt (IDM) ; Yaron Sheffer < >> yaronf.ietf@gmail.com>; Richard Backman, Annabelle = ; >> ID Events Mailing List >> >> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >> >> Mike >> >> As you well know, many people in a WG don't look closely at a >> specification until last call is made. Additionally, we are coming up on >> only the 3rd WG meeting. The WG has not existed for very long. While som= e >> of the participants have been working on this for a while, many have not= , >> and we are looking for consensus across the WG. >> >> Since SecEvent is a framework that we expect to be profiled, I feel it i= s >> important to ensure that SecEvent specifications are easy for a variety = of >> profiles to adopt, and that the semantics make sense. I also think that >> properties that are specific to a profile should be left to that profile >> and not be included in SecEvent. >> >> Since this is a framework, it is expected that as different groups >> profile it, there will be additional feedback. >> >> Specifically, as a participant in the RISC profile of SET, a number of >> issues in SET have surfaced as the RISC WG has looked at how to use the = SET. >> >> As for SET being stable for over a year, there have been a number of >> changes to SET since then. I also don't think there was consensus. Befor= e >> the WG was formed, I and several others had expressed concern on the des= ign >> of SET when Phil presented it at an IIW session. >> >> As to taking another year, I am hopeful we can resolve the remaining >> issues in SET and publish a new draft for last call. I do not think we w= ill >> need to wait for another WG meeting to ask for last call. >> >> We also have a number of other documents that are not in last call, and >> we don't have a WG adopted draft yet for management. So there are still = a >> number of documents to work through before we have all the bits for some= one >> to work with. >> >> I do think we have been making good progress since the last IETF meeting= , >> and I am hopeful we can keep up this momentum and finalize all the >> documents in a timely manner. >> >> /Dick >> >> >> On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones >> wrote: >> >> It=E2=80=99s hard for me to even express my level of frustration with th= e recent >> attempts to once again redesign the SecEvent Token spec. We=E2=80=99ve = been at >> this for multiple years because people keep trying to revisit decisions >> that were long ago made by consensus. It=E2=80=99s been stable for over= a year and >> the majority of WGLC respondents said some variant of =E2=80=9CWorks for= me =E2=80=93 ship >> it!=E2=80=9D >> >> There=E2=80=99s not sufficient justification to try to undo consensus po= sitions >> that have been debated and affirmed over and over. Countenancing wholes= ale >> changes at this late date is counterproductive in the extreme! >> >> It=E2=80=99s far better than good enough as-is. In my experience, if we= start >> redesigning it, it will result in another year=E2=80=99s delay. It does= something >> simple and useful. Please, let=E2=80=99s just ship it, so people can re= ly on it. >> >> -- Mike >> >> *From:* Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] >> *Sent:* Monday, October 30, 2017 2:42 PM >> *To:* Dick Hardt >> *Cc:* Yaron Sheffer ; Richard Backman, Annabelle = < >> richanna@amazon.com>; Mike Jones ; ID >> Events Mailing List >> >> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >> >> Inline... >> >> Phil >> >> >> On Oct 30, 2017, at 2:22 PM, Dick Hardt wrote: >> >> Hi Phil >> >> Correct me if I am misunderstanding, but there is a RISC profile event >> >> >> >> "http://schemas.openid.net/secevent/risc/event-type/ ac= count-credential-change-required=E2=80=9D >> >> >> >> and an SCIM profile event >> >> >> "https://example.com/scim/event/passwordResetExt=E2=80=9D >> >> >> >> I'm suggesting that two different events would be sent. Embedding one in >> the other does not make sense. >> >> It is a hypothetical example. Just because you disagree on this does >> not mean others are not valid. >> >> I just picked overlapping proposals that have different meaning (but not >> the same) to illustrate the difference from issuing a single set with >> different events. >> >> >> As I have stated this is very different from asserting multiple distinct >> events in one SET. >> >> >> Also, I think it is simpler to have event_type be at the same level as >> event >> >> >> >> may be. I was working from Annabelle's proposed format. >> >> >> { >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "iat": 1458496025, >> "iss": "https://scim.example.com", >> "aud": [ >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> ], >> "event_type": "https://example.com/scim/event/passwordResetExt", >> "event": { >> "id":"44f6142df96bd6ab61e7521d9", >> "resetAttempts":5 >> } >> } >> >> { >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "iat": 1458496025, >> "iss": "https://scim.example.com", >> "aud": [ >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> ], >> "event_type": "http://schemas.openid.net/sec >> event/risc/event-type/account-credential-change-required >> >> ", >> "event": { >> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >> } >> } >> >> >> >> >> >> On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt wrote= : >> >> Annabelle/Dick, >> >> Thanks for the comments. I think we need to examine the consequences of >> the proposal in JSON. >> >> As I stated, what causes most of the issue is the proposed extension >> mechanism in the payload (possibly using events in a recursive way). Doe= s >> it follow the old format or the new? >> >> Let=E2=80=99s consider a use case where we have an identity management = system >> that uses SCIM, but the SCIM system is also the underlying data store fo= r >> Connect. A Password reset might generate the following event which has = an >> extension (conveying reset count) AND overlapping statement from RISC. >> BOTH of which might be important to a similar receiver using SCIM and OI= DC. >> >> >> *The 03 spec currently would allow:* >> >> >> { >> >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "iat": 1458496025, >> >> "iss": "https://scim.example.com", >> >> "aud": [ >> >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> >> ], >> >> "events": { >> >> "urn:ietf:params:scim:event:passwordReset": >> >> { "id":"44f6142df96bd6ab61e7521d9"}, >> >> "https://example.com/scim/event/passwordResetExt": >> >> { "resetAttempts":5}, >> >> "http://schemas.openid.net/secevent/risc/event-type/\ >> account-credential-change-required": { >> >> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >> >> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >> >> } >> >> } >> >> } >> >> >> >> In the above - each payload is a =E2=80=98peer' and issued without prefe= rence by the transmitter. The receiver can assign priority in its own conte= xt if that matters. >> >> >> >> *The new proposal:* >> >> >> >> { >> >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "iat": 1458496025, >> >> "iss": "https://scim.example.com", >> >> "aud": [ >> >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> >> ], >> >> "event": { >> >> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passwordRe= set=E2=80=9D, >> >> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >> >> =E2=80=9Cevents=E2=80=9D:{ >> >> ->note =E2=80=A6is this the old or new structure? <- >> >> "https://example.com/scim/event/passwordResetExt": >> >> { "resetAttempts":5}, >> >> "http://schemas.openid.net/secevent/risc/event-type/\ >> account-credential-change-required": { >> >> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >> >> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >> >> } >> >> } >> >> } >> >> } >> >> >> >> In the above, sub-events or extensions have a different format. The same= complaint about the original stands. >> >> >> >> **OR* (if the receiver cares about RISC more). Note that this leads to = a triple nested structure.* >> >> >> >> { >> >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "iat": 1458496025, >> >> "iss": "https://scim.example.com", >> >> "aud": [ >> >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> >> ], >> >> "event": { >> >> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/ri= sc/event-type/\ >> >> account-credential-change-required=E2=80=9D, >> >> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >> >> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >> >> =E2=80=9Cevents=E2=80=9D:{ >> >> "urn:ietf:params:scim:event:passwordReset": >> >> { >> >> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >> >> =E2=80=9Cevents=E2=80=9D:{ >> >> "https://example.com/scim/event/passwordResetExt": >> >> { "resetAttempts":5}, >> >> } >> >> } >> >> } >> >> } >> >> } >> >> >> >> In the above, the extension is placed inside the event it extends. It fo= llows the old format (or should it follow the new?) >> >> **OR* Following the top layer pattern of singular event Note that this = leads to a triple nested structure.* >> >> >> >> { >> >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "iat": 1458496025, >> >> "iss": "https://scim.example.com", >> >> "aud": [ >> >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> >> ], >> >> "event": { >> >> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/ri= sc/event-type/\ >> >> account-credential-change-required=E2=80=9D, >> >> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >> >> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >> >> =E2=80=9Cevent=E2=80=9D:{ >> >> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passwor= dReset=E2=80=9D, >> >> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >> >> =E2=80=9Cevent=E2=80=9D:{ >> >> =E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/event/p= asswordResetExt=E2=80=9D, >> >> "resetAttempts":5 >> >> } >> >> } >> >> } >> >> } >> >> >> >> This format follows the proposed singular event format recursively and i= s 3 layers deep. Note that the parser has to continue to search the documen= t for things that aren=E2=80=99t there as it has to stop when no =E2=80=9Ce= vent=E2=80=9D attribute is found rather than iterate over an array. >> >> >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> Replies inline. >> >> -- >> Annabelle Richard Backman >> Identity Services >> >> >> *From: *Phil Hunt >> *Date: *Sunday, October 29, 2017 at 5:25 PM >> *To: *Dick Hardt >> *Cc: *Yaron Sheffer , Mike Jones < >> Michael.Jones@microsoft.com>, "Richard Backman, Annabelle" < >> richanna@amazon.com>, ID Events Mailing List >> *Subject: *Re: [Id-event] Use cases for multiple events per SET? >> >> I hope this answers your question. >> >> My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reason why no= t. The question should >> be, what is the justification to make =E2=80=9Cevents=E2=80=9D singular? >> [richanna]The singular =E2=80=9Cevent=E2=80=9D claim has clearer semanti= cs and is easier >> to process. We should opt for easier solutions unless there are use case= s >> that require more complexity.[/richanna] >> >> There are many reasons for multiple events in a SET. Some are good, som= e >> not so good. Some of the reasons... >> >> 1. Multiple event payloads expressing statements about largely the >> *same*thing. For example, SCIM password reset AND RISC password reset. = A >> RISC Event and an OpenBanking Event. Is one a complement to the other? = Do >> they overlap or are they distinct? >> [richanna]Copy/pasted from my earlier email: >> Why is it necessary or appropriate to include these events in the same >> SET? They are likely being generated by different systems at different >> times on the transmitter=E2=80=99s side, consumed by different systems o= n the >> receiver=E2=80=99s side, and possibly being transmitted over different e= vent >> streams. I know the latter would be the case for us, as a receiver. Even= if >> it=E2=80=99s not, is it burdensome to send these events separately? What= value is >> gained in combining them? >> >> Additionally, since the signature is over the SET and not the event >> objects, Receivers independently route separate events from a single tok= en >> without either losing the ability to verify the authenticity of the even= t >> or sharing all information in the SET with every system handling any eve= nt >> in the token.[/richanna] >> >> >> 2. Multiple events payloads expressing different statements about the >> same transaction - RISC Password Reset and RISC Session Cancel >> [richanna]Same as above[/richanna] >> 3. A new profile defines new event attributes to be added on to an >> existing event type (a pure extension) >> [richanna]I have suggested a way to support extensions within an event >> body, multiple times now. If you see problems with it, please point them >> out.[/richanna] >> >> I think it is quite valid to allow 1 and 3. 2 could be limited by >> specific profiles like RISC if they want. >> >> I am not in agreement that making event singular simplifies anything. Fo= r >> one is makes extensions complex (another nested JSON structure) and >> potentially conflicting. >> [richanna] >> Ways that multiple-event SETs are more complicated: >> >> 1. It results in a more complex structure for the single event use >> case, which I think we all agree is the majority use case. >> 2. Multiple-event SETs have ambiguous semantics. The presence of two >> events A and B in the same SET could mean any of: >> >> >> 1. They are related to the same logical event (i.e. the same thing as >> if they were from different SETs that have a common txn). >> 2. A is an extension of B. >> 3. B is an extension of A. >> 4. They are aliases for one another. >> 5. They are not actually related to one another in any way. >> >> >> 1. Claim semantics become harder to define, as different profiles may >> want to use the same claims in different ways. >> >> >> If the WG wants to block 1 and 2 above, then I believe we have to >> establish an event registry to ensure new Event profiles do not overlap = to >> eliminate the need to express multiple events. >> [richanna]I=E2=80=99m not sure what you mean by this. Are you referring = to event >> names? Those are already defined by the spec to be URIs.[/richanna] >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> On Oct 29, 2017, at 4:12 PM, Dick Hardt wrote: >> >> Phil: >> >> In your examples for having a plurality of events, you use the word >> "may", which leads me to question if a plurality of events is really >> required in SET. >> >> You posit that it will be difficult for a distributed system to correlat= e >> multiple SETs with the same "txn", but the distributed system will >> certainly need to correlate events on the same subject -- correlating >> events on the same "txn" on the same subject seems fairly simple. >> >> I think that a receiver will need to correlate multiple SEts on the same >> subject, so having multiple events in a SET is redundant, and adds >> complexity with no clear benefit that I can see. >> >> An implementor may choose to send multiple SETs, or send a single SET >> with multiple events, so a receiver will need to support both. I prefer = we >> pick one way and minimize the code paths, and we will need to support >> correlating across multiple SETs, so that seems the best mechanism. >> >> Let me know if there is something I missed in my logic. >> >> /Dick >> >> >> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer >> wrote: >> >> In that case, let's add text to that effect, e.g. we could add to the >> definition of the "events" claim: >> >> Profiling specifications SHOULD define the allowed event statements, and >> MAY restrict their number. For example, some profiles may require this >> claim to contain only a single event statement. >> >> Thanks, >> Yaron >> >> On 24/10/17 22:10, Mike Jones wrote: >> >> I agree with much of Phil=E2=80=99s rationale here. >> >> It=E2=80=99s fine for some profiles to say that the =E2=80=9Cevents=E2= =80=9D set must be a >> singleton. That doesn=E2=80=99t have to be true for all events. I thin= k things >> are fine as-is. >> >> -- Mike >> >> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Phil >> Hunt >> *Sent:* Monday, October 23, 2017 8:47 PM >> *To:* Richard Backman, Annabelle >> *Cc:* ID Events Mailing List >> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >> >> Annabelle, >> >> I have a number of concerns with this proposal. >> >> Profiling Independence / Keeping Event Payloads Independent >> >> Indicating that extensions should be handled by profiles leads to more >> inter-operability issues and more importantly intrudes on the Event payl= oad >> space by suggesting a sub-schema creates potential limitations and >> conflicts that may add to complexity later on. The current format allows= a >> parser to discover and unload one or more JSON payloads which can each h= ave >> independent structure. >> >> General extensions >> >> The proposal also rules out general purpose extensions not related to an= y >> specific event. Given the emergence of items like GPRD, I would not want= to >> block the ability to add meta-data or other general purpose items. We ca= n >> also anticipate some delivery scenarios where additional data might be >> required. Even though there is no current planned use, I see no good rea= son >> to rule this out. >> >> Multiple Events From Different Families (vs. Multiple Events from a >> single family like RISC) >> >> In our RISC session we discussed expressing multiple distinct RISC event= s >> in one SET. The discussion was that only one RISC event at a time. We di= d >> not discuss other event profiles. I don=E2=80=99t see a reason to rule o= ut >> multi-events from different families at the SET level. Each profile is >> expressing slightly different things about the same event. >> >> I can forsee some cases where it is not clear which is the primary and >> which is the extension. There may not be a clear winner. >> >> A couple of examples (these are necessarily real=E2=80=A6just possibilit= ies): >> >> * It is probably useful to be able to express simlar/overlapping events >> from different SET profiles in one SET. For example a Backchannel Logou= t & >> a RISC session cancel event. >> >> * SCIM may want to represent a single transaction as causing multiple >> state changes in an event (e.g. a password change causes multiple effect= s). >> Having to chase down multiple events and correlate by =E2=80=9Ctxn=E2=80= =9D would be >> challenging in a multi-threaded/multi-node delivery system. The SCIM l= ist >> has not discussed this, but I would not want to block this capability. = IOW >> - Just because RISC does not want to express multiple events does not ma= ke >> this true for other profiles. >> >> * We may wish to indicate a SCIM Password Reset was performed and a >> Logout/session cancellation is expressed at the same time. The events a= re >> related but express different data. >> >> Avoiding Confusion From Similar Events Originating from the Same >> Transaction >> >> If events are sent separately, then more tracking of state (e.g. by txn) >> would be required to ensure similar events are not mistaken or handled a= s >> repeats. While txn provides useful audit analysis capability, I=E2=80=99= m not sure >> it can be used in live or near-real time systems given distributed >> multi-node, multi-threading architectures. >> >> Previous Discussion >> >> I note that I originally raised having an attribute to designate primary >> event attribute to alleviate your concern, but this was not accepted. Se= e: >> >> * https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html >> >> >> * https://www.ietf.org/mail-archive/web/id-event/current/msg00140.html >> >> >> The consensus, at least as I interpreted it is up to the receiver to >> figure this out based on the definitions it has for each event URI and t= he >> profiles they represent. IOW - RISC is free to limit that only one RISC >> event be expressed at a time. >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> >> @independentid >> >> www.independentid.com >> >> > >> > >> >> phil.hunt@oracle.com >> >> On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle >> > wrote: >> >> The current draft of the SET spec allows for expressing multiple >> events within the same token, which introduces additional complexity >> and room for ambiguous semantics. We=E2=80=99ve discussed this in th= e OIDF >> RISC working group and the current consensus there is that RISC will >> require that RISC events must be the only event in the SET, having >> identified ways to clearly and easily support the handful of use >> cases for multiple events per token that people have raised. With >> that context in mind, I propose striking the definition of the >> =E2=80=9Cevents=E2=80=9D claim from the Security Event Token spec, a= nd replacing it >> with the following definition for an =E2=80=9Cevent=E2=80=9D claim (= singular): >> >> event >> >> A JSON object containing an "event_type" member whose value is a URI >> representing a type of event defined in a Profiling Specification. >> The object MAY otherwise be empty, or MAY contain additional members >> as described by the Profiling Specification. >> >> Here is the example SET from section 2.3, rewritten with this change >> mind: >> >> { >> >> "jti": "4d3559ec67504aaba65d40b0363faad8", >> >> "iat": 1458496404, >> >> "iss": "https://scim.example.com ", >> >> "aud": [ >> >> "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", >> >> "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" >> >> ], >> >> "event": { >> >> "event_type": "urn:ietf:params:scim:event:create", >> >> "ref": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d= 9 >> ", >> >> "attributes": ["id", "name", "userName", "password", "emails"] >> >> } >> >> } >> >> Does anyone in the working group have use cases for SETs that cannot >> be met by this proposed text? Within RISC, we identified three use >> cases, with solutions outlined below: >> >> ** >> >> *Extensions* >> >> Event extension mechanisms can be defined internal to the event >> object. A simple approach would be to define an =E2=80=9Cextensions= =E2=80=9D member >> that is a list of event objects (or set resembling the =E2=80=9Ceven= ts=E2=80=9D >> claim as defined in the current spec). This has the advantage of >> making it clear in the data structure that there is a single primary >> event, with zero or more extensions. There is no room for confusion >> over which event is primary, or if there is a primary event at all. >> I would be fine with adding something like this to my proposed text, >> if there is consensus that it is broadly useful. >> >> *Aliases* >> >> This use case was brought up in the context of migrating clients >> from draft event names to standardized event names. In this case, >> the event transmitter can transmit two tokens for the logical event, >> one using the old name and another using the new name. >> >> *Related Events* >> >> The SET spec defines the txn claim as a means of correlating >> independent tokens that relate to the same logical event. >> >> -- >> Annabelle Richard Backman >> >> Amazon =E2=80=93 Identity Services >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. >> ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCg >> aWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPE >> ivzjWwlNKe4C_lLIGk&m=3Ds5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFS >> ibEc&s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> >> >> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYq >> PkAI1aLcLN4KZNA&m=3DYBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1i >> w&s=3DWrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=3D >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYq >> PkAI1aLcLN4KZNA&m=3DU-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGie >> c&s=3DrvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm46QSz0&e=3D >> >> >> >> >> >> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYq >> PkAI1aLcLN4KZNA&m=3DiyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_ >> w&s=3DOe0qfLEX83vtXM7Wl2cYBe-Gg1DVPjhXjVJkfhVRzwc&e=3D >> >> >> >> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> >> >> >> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> >> >> >> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYq >> PkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhl >> o&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=3D >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --001a113ffcf0949d0a055cf2d031 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Perhaps I can try and explain the original intent of the c= urrent design. The goal was always that a SET represents a single logical e= vent. However multiple systems may have different representations of the ev= ent =E2=80=93 the example given originally was one formatted for RISC, and = one for SCIM.

    A good analogy is email. You send a single= logical email, which may have two representations, HTML and plain text. Sy= stems can consume the version that they understand and ignore the one they = don't.

    I'm starting to regret the plural i= n "events", it was pluralized due to it being an array, not becau= se it represented multiple logical events.

    Annabel= le, I understand your concerns regarding confusion of the semantics between= the JSON syntax and the specification language. Are there other ways to re= solve that without removing the ability for multiple representations of the= same event?

    On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu &= lt;mscurtescu@go= ogle.com> wrote:
    On Wed, Nov = 1, 2017 at 12:45 PM, Phil Hunt <p= hil.hunt@oracle.com> wrote:
    You can=E2=80=99t really have multiple= events (at least of the same type).=C2=A0 The current spec can only have o= ne instance of a URI (afaik). =C2=A0

    Note that the spec = normatively does not support multiple event SETS.=C2=A0 It currently states= :
    events
      The semantics of this claim is to define a set of event statements
      that each MAY add additional claims to fully describe a single
      logical event that has occurred (e.g. a state change to a
      subject).  Multiple event statements of the same type SHALL NOT be
      accepted.  The "events" claim SHOULD NOT be used to express
      multiple logical events.

    The sp= ec has *always* supported requirements (as stated in the spec) for multiple= separate profile statements (from one or more profile familities) needing = to be sent as a single message.=C2=A0 It would be INSECURE to force multipl= e SETs because the current delivery mechanism only allows one SET to be del= ivered at a time. There is no way to assure that a single receiver gets all= of the SETs it needs in a multi-threaded, multi-node environment at scale.= =C2=A0 Assembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a common = state database is NOT simple nor cost effective.

    I totally agree that it is difficult for rece= ivers to receive separate events, in no particular order and correlate base= d on "txn". But, receivers have to solve this issue regardless of= "events" or "event", so it is unrelated to this propos= al.

    =C2=A0

    If we accomm= odate this in the proposed form, we end up with a complex, deeply nested JS= ON structure with the possibility of namespace conflicts.

    IMO The proposal does not simplify, it complicating and limiting. = =C2=A0

    The current spec has very clean JSON and av= oids namespace conflicts between profiles. I think we should stay on track = with the current draft and observe the normative text if not make it strong= er in regards to multi-events (understood that Mike may disagree).

    Phil
    <= div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-i= ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap= :break-word">

    Oracle Corporation, Identity Cl= oud Services Architect
    @independentid
    phil.hunt@oracle.com

    On Nov 1, 2017, at 12:18 PM, Richar= d Backman, Annabelle <richanna@amazon.com> wr= ote:

    Unless the profile = guarantees that such related events will always be included in the same SET= , then the receiver has to correlate across SETs anyway, and multiple event= s per SET is just giving the receiver another scenario that they have to su= pport.
    =C2=A0
    I= =E2=80=99ve already provided several other reasons why we should not suppor= t multiple tokens per SET that no one has addressed. Here they are again:
    1. Multiple event support results in a more complex structure = for the single event use case, which I think we all agree is the majority u= se case.
    2. Multiple-event SETs have ambiguous semantics.= The presence of two events A and B in the same SET could mean any of:
      1. A and B are related to the same logical event (i.e. the same thing a= s if they were from different SETs that have a common txn).
      2. A is an extension of B.
      3. B is an extension of A.<= u>
      4. A is an alias for B, or vice-versa.
        5. =
      5. A and B are not actually related to one another in any way, and the tran= smitter bundled them together because they were going to the same receiver.=
    3. Top-level claim semantics become harder to = define, as different profiles may want to use the same claims in different = ways.
    4. Event authenticity cannot be verified without ha= ving the entire SET. This forces receivers to expose downstream systems to = more information necessary, if those systems need to be able to verify auth= enticity.
    =C2=A0
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">--=C2=A0
    Annabelle Richard Bac= kman
    Amazon =E2=80=93 Identity Services=
    =C2=A0
    =C2=A0
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">From:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
    Date:=C2=A0Wedne= sday, November 1, 2017 at 11:21 AM
    To:=C2=A0Dick Hard= t <dick.hardt@gmail.com>
    Cc:=C2= =A0Yaron Sheffer <yaronf.ietf@gmail.com= >, "Richard Backman, Annabelle" <ri= channa@amazon.com>, ID Events Mailing List <id-= event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
    Subject:=C2=A0RE: [Id-= event] Use cases for multiple events per SET?
    =C2=A0
    I completely agree on moving complexity to the issuer o= ver the recipient.=C2=A0 In my view, it=E2=80=99s more complex for recipien= ts to have to correlate and process a sequence of multiple SETs providing i= nformation about the same logical event, and validate N signatures, than to= receive one SET with all the aspects of the logical event as =E2=80=9Ceven= ts=E2=80=9D fields, with no correlation over time then required.<= /u>
    =C2=A0<= u>
    =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 -- Mike
    From:=C2=A0Dick Hardt= [mailto:dick.hardt@gmail.com]=C2=A0Sent:=C2=A0Wednesday, November 1, 2017 9:39 AM
    T= o:=C2=A0Mike Jones <Michael.= Jones@microsoft.com>
    Cc:=C2=A0Yaron Sheffer &l= t;yaronf.ietf@gmail.com>; Richard Backman, Ann= abelle <richanna@amazon.com>; ID Events Maili= ng List <id-event@ietf.org>; Phil Hunt (IDM) &l= t;phil.hunt@oracle.com>
    Subject:= =C2=A0Re: [Id-event] Use cases for multiple events per SET?
    =C2=A0
    Your com= ments highlight a couple of points:
    =C2=A0
    1) The example is how to ha= ve a predefined extension point for extensions of a specific event, it is n= ot how to add another event. Myself, I think this is overly complicated. Ev= ents should be comparatively static, and as with many other JSON formats, t= he receiver should ignore properties it does not understand, which let'= s new properties be introduced as extensions. There should not be any confl= ict as extensions should only be done by the profile that created the event= format to start off with.
    =C2=A0
    2) Having an lvalue be a URI is much= harder to code against. I'm not sure why Marius had that in his exampl= e. Per the event, the type of the event is well defined with=C2=A0
    =C2=A0
    =C2=A0
    3) This thread is about reasons for multiple = events to be contained in one set. Your mention of an issuer not wanting to= sign separate events as a reason to allow multiple events. I think we have= decided that given a preference, we will push effort to the transmitter ov= er the receiver as in many use cases there are many more receivers. Given t= hat, it is more complex for a receiver to have different ways of managing t= he receipt of multiple events as not all issuers will bundle the events, so= it is simpler to have only one event per SET. Including the separate event= s with a URI as an lvalue is challenging to implement, speaking from experi= ence.
    =C2=A0
    =C2=A0
    =C2=A0<= /u>
    =C2=A0
    =
    =C2=A0
    =C2=A0=
    =C2=A0
    =C2=A0
    =C2=A0
    <= div>
    =C2=A0
    =C2=A0<= u>
    =C2=A0
    On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones <Michael.Jones@micro= soft.com> wrote:
    <= div>
    Marius=E2=80=99 proposed s= yntax, pasted in below, has exactly this characteristic.=C2=A0 The way I se= e it, his proposal essentially has a primary passwordReset event and a seco= ndary passwordResetExt data structure, which could have been simply another= event value in the current draft.
    =C2=A0
    = This breaking change makes the data stru= ctures more complicated - not less.=C2=A0 And it makes things that used to = be possible impossible, reducing flexibility to those who would use the spe= c.
    = =C2=A0
    These seem like bad tradeoffs to me.
    =C2=A0
    {
    =C2=A0 "jti": "3d0c3cf79= 7584bd193bd0fb1bd4e7d30",
    =C2=A0= "iat": 1458496025,
    =C2=A0 "= ;iss": "https://scim.example.com",
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0 "aud": [
    =C2=A0 =C2= =A0],
    =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"resetAttempts":5,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<= u>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}=
    =C2=A0 =C2=A0 =C2=A0 =C2=A0}
    = }
    = =C2=A0
    In particular, it makes it impossible to sign multiple related events sh= aring a common claims schema with a single signature by the issuer.=C2=A0 I= t forces the issuer to do the extra work of signing each of the related eve= nts (or facets of the same logical event) individually and forces the recip= ients to do the extra work of checking all those unnecessary signatures.
    =C2=A0=
    Not= every profile will ever have multiple keys in the =E2=80=9Cevents=E2=80=9D= set but there=E2=80=99s absolutely no reason to preclude it.=
    =C2=A0<= /u>
    =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 -- Mike
    From:=C2= =A0Id-event [mailto:id-event-bounces@ietf.org]=C2=A0= On Behalf Of=C2=A0Dick Hardt
    Sent:= =C2=A0Tuesday, October 31, 2017 9:52 PM
    To:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
    Cc:= =C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, = Annabelle <richanna@amazon.com>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt (IDM) <phil.hunt@oracle.com>

    Subject:=C2=A0Re: [Id-event] Use c= ases for multiple events per SET?
    =
    =C2=A0
    Please direct me to a pr= oposal that has a "primary" and "secondary" events. I a= gree that is undesirable. I would also encourage to engage in the discussio= ns so that we can drive clarity and simplicity.
    =C2=A0
    I think the proposal = is that there is one event per SET.
    =C2=A0
    I think having more than on= e event per SET adds complexity as a receiver must deal with receiving corr= elated events in one SET as well as correlated events in the same SET.
    =C2=A0
    /Dick
    =C2=A0
    On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones <<= a href=3D"mailto:Michael.Jones@microsoft.com" style=3D"color:purple;text-de= coration:underline" class=3D"m_7476346946956833004cremed" target=3D"_blank"= >Michael.Jones@microsoft.com> wrote:
    I hear= you on the fact that different people have joined the effort at different = times.=C2=A0 That=E2=80=99s a normal process as an effort builds momentum.= =C2=A0 I get that not everyone was there when previous consensus calls were= taken.
    =C2=A0
    I should note that I have specific technical objections to the speci= fic proposed changes being discussed as well.=C2=A0 Currently all events in= the set have the same syntax.=C2=A0 The proposals, as I understand them, r= evert us to a state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and = =E2=80=9Csecondary=E2=80=9D events, with different syntax for the two class= es.=C2=A0 That=E2=80=99s needlessly more complicated, adding no actual valu= e.
    = =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 -- Mike
    =C2=A0
    From:= =C2=A0Dick Hardt [mailto:dick.hardt@gmail.com]=C2=A0
    Sent:=C2=A0Tuesday, October 31, 2017 9:37 PM
    = To:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
    Cc:=C2=A0Phil Hunt (IDM) <    phil.hunt@oracle.com>; Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabe= lle <richanna@amazon.com>; ID Events Mailing List <id-event@ietf.org>= ;

    Subject:=C2=A0Re: [Id-event] Use cases for multiple events per SET?
    =C2=A0
    = Mike
    =C2=A0
    As you well know, many people in a WG don't look closely at = a specification until last call is made. Additionally, we are coming up on = only the 3rd WG meeting. The WG has not existed for very long. While some o= f the participants have been working on this for a while, many have not, an= d we are looking for consensus across the WG.
    =C2=A0
    Since SecEvent is= a framework that we expect to be profiled, I feel it is important to ensur= e that SecEvent specifications are easy for a variety of profiles to adopt,= and that the semantics make sense. I also think that properties that are s= pecific to a profile should be left to that profile and not be included in = SecEvent.
    =C2=A0
    Since this is a framework, it is expected that as dif= ferent groups profile it, there will be additional feedback.<= /div>
    =C2=A0
    = Specifically, as a participant in the RISC profile of SET, a number of issu= es in SET have surfaced as the RISC WG has looked at how to use the SET.=
    =C2=A0
    =
    As for SET being stable for over a year, there have been a number= of changes to SET since then. I also don't think there was consensus. = Before the WG was formed, I and several others had expressed concern on the= design of SET when Phil presented it at an IIW session.
    =C2=A0
    As to = taking another year, I am hopeful we can resolve the remaining issues in SE= T and publish a new draft for last call. I do not think we will need to wai= t for another WG meeting to ask for last call.=C2=A0
    =C2=A0
    We also ha= ve a number of other documents that are not in last call, and we don't = have a WG adopted draft yet for management. So there are still a number of = documents to work through before we have all the bits for someone to work w= ith.
    =C2=A0
    I do think we have been making good progress since the las= t IETF meeting, and I am hopeful we can keep up this momentum and finalize = all the documents in a timely manner.
    =C2=A0
    /Dick
    =
    =C2=A0
    = =C2=A0
    On Tue, Oct 31, 2017 at 12:48 PM, = Mike Jones <Michael.Jones@microsoft.com> wrote:
    It=E2=80=99s hard for me to even express my level of frustration = with the recent attempts to once again redesign the SecEvent Token spec.=C2= =A0 We=E2=80=99ve been at this for multiple years because people keep tryin= g to revisit decisions that were long ago made by consensus.=C2=A0 It=E2=80= =99s been stable for over a year and the majority of WGLC respondents said = some variant of =E2=80=9CWorks for me =E2=80=93 ship it!=E2=80=9D=
    =C2=A0=
    There=E2= =80=99s not sufficient justification to try to undo consensus positions tha= t have been debated and affirmed over and over.=C2=A0 Countenancing wholesa= le changes at this late date is counterproductive in the extreme!=
    =C2=A0=
    It=E2=80= =99s far better than good enough as-is.=C2=A0 In my experience, if we start= redesigning it, it will result in another year=E2=80=99s delay.=C2=A0 It d= oes something simple and useful.=C2=A0 Please, let=E2=80=99s just ship it, = so people can rely on it.
    =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=
    =C2=A0<= /u>
    From= :=C2=A0Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=C2= =A0
    Sent:=C2=A0Monday, October 30, 2017 2:42 P= M
    To:=C2=A0Dick Hardt <dick.hardt@gmail.com>
    = Cc:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>; Ri= chard Backman, Annabelle <richanna@amazon.com>; Mike Jones <Mich= ael.Jones@microsoft.com>; ID Events Mailing List <id-event@ietf.org&g= t;

    Subject:=C2=A0Re: [Id-event] Use cases for multiple events per SET?
    =C2=A0
    Inline...

    Phil


    On Oct 30, 2017, at 2:22 PM, Dick Hardt <dick.hardt@gmail.co= m> wrote:

    Hi Phil=
    =C2=A0
    Correct= me if I am misunderstanding, but there is a RISC profile event=C2=A0
    =C2=A0<=
/u>
    "http://schemas.openid.net/secevent/risc/eve=
nt-type/account-credential-change-required=E2=80=9D
    =C2=A0
    and an SCIM profile event
    = =C2=A0
    https://example.com/scim/event/passwordResetE=
xt=E2=80=9D
    =
=C2=A0
    I'm suggesting that two = different events would be sent. Embedding one in the other does not make se= nse.
    <ph>= It is a hypothetical example. Just because you disagree on this does not me= an others are not valid.=C2=A0
    =C2=A0<= /u>
    I just picked overlapping proposals th= at have different meaning (but not the same) to illustrate the difference f= rom issuing a single set with different events.=C2=A0
    =C2=A0

    As I have stated this is very different from asserting multiple distin= ct events in one SET.=C2=A0

    =C2=A0
    Also, I think it is simpler to have eve= nt_type be at the same level as event
    =
    =C2=A0

    <ph>may be. I was working from Annabelle's proposed form= at.=C2=A0

    =C2=A0
    {
    =C2=A0 "jti": "3d0c3cf7975= 84bd193bd0fb1bd4e7d30",
    =C2=A0 "= iat": 1458496025,
    =C2=A0 "iss": = "h= ttps://scim.example.com",
    =C2=A0 "= ;aud": [
    =C2=A0 =C2=A0],
    <= /div>
    <= /div>
    =C2=A0 =C2=A0"event": {=C2=A0=C2=A0
    = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"id":"44f6142df96bd6ab61e7= 521d9",
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"resetAttempts":5
    =C2=A0 =C2=A0= =C2=A0 =C2=A0}
    =C2=A0
    On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt &= lt;ph= il.hunt@oracle.com> wrote:
    Annabelle/Dick,
    =C2=A0
    Thanks for the comments= . I think we need to examine the consequences of the proposal in JSON.
    =C2=A0
    As I stated, what causes most of the issue is the proposed extension mec= hanism in the payload (possibly using events in a recursive way). Does it f= ollow the old format or the new?
    =C2=A0
    Let=E2=80=99s =C2=A0consider a use c= ase where we have an identity management system that uses SCIM, but the SCI= M system is also the underlying data store for Connect.=C2=A0 A Password re= set might generate the following event which has an extension (conveying re= set count) AND overlapping statement from RISC.=C2=A0 BOTH of which might b= e important to a similar receiver using SCIM and OIDC. =C2=A0=
    =C2=A0
    = The 03 spec currently would allow:
    =C2=A0
    {<=
/u>
    =C2=A0 "jti": "3d0c3cf797584bd19=
3bd0fb1bd4e7d30",
    =C2=A0 &q=
uot;iat": 1458496025,
    =C2=A0 &qu=
ot;iss": "https://scim.example.com",
    =C2=A0 "aud": [
    =C2=A0=C2=A0=C2=A0 "https://jhub.example.com=
/Feeds/98d52461fa5bbc879593b7754",
    =C2=A0=C2=A0=C2=A0 "https://jhub.e=
xample.com/Feeds/5d7604516b1d08641d7676ee7"
    =C2=A0=C2=A0 ],
    =
=C2=A0=C2=A0 "events": {
    =
=C2=A0=C2=A0=C2=A0=C2=A0 "urn:ietf:params:scim:event:passwordRese=
t":
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 { "id":"44f6142df96bd6ab61e7521d9"},<=
/u>
    =C2=A0=C2=A0=C2=A0=C2=A0 "https://example.com/scim/event/passwordResetExt":<=
/u>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { &=
quot;resetAttempts":5},
    =C2=A0=C2=A0=C2=A0=C2=A0 "http://schemas.o=
penid.net/secevent/risc/event-type/\
    =C2=A0 =C2=A0 =C2=A0 =C2=
=A0account-credential-change-required": {
    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=
=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ciss=
=E2=80=9D:"https://idp.example.com/"
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
    =C2=A0 }
    }=

    =C2=A0
    In the above - each =
payload is a =E2=80=98peer' and issued without preference by the transm=
itter. The receiver can assign priority in its own context if that matters.=

    =C2=A0
    The new proposal:
    =C2=A0
    {
    =C2=A0 "jti": "3d0c3cf797584bd193bd0fb=
1bd4e7d30",
    =C2=A0 "ia=
t": 1458496025,
    =C2=A0 "iss=
": "https://scim.example.com",
    =C2=A0 "aud": [
    =C2=
=A0=C2=A0=C2=A0 "https://jhub.example.com/Feed=
s/98d52461fa5bbc879593b7754",
    =C2=A0=C2=A0=C2=A0 "https://jhub.exam=
ple.com/Feeds/5d7604516b1d08641d7676ee7"
    <=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courie=
r New',serif">=C2=A0=C2=A0 ],
    =C2=
=A0=C2=A0 "event": {
    =C2=A0=
=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:=
scim:event:passwordReset=E2=80=9D,
    =
=C2=A0=C2=A0=C2=A0=C2=A0 "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=
=A0 =E2=80=9Cevents=E2=80=9D:{
    =C2=A0=
=C2=A0=C2=A0=C2=A0 ->note =E2=80=A6is this the old or new structure? <=
;-
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 "https://example.com/scim/event/passwordResetE=
xt":
    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAttempts":5},
    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 "http://schemas.openid.net/secevent/risc/eve=
nt-type/\
    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0account-credential-=
change-required": {
    =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
    =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ciss=E2=80=9D:"=
https://idp.example.com/"<=
/u>
    =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
    =
=C2=A0=C2=A0=C2=A0=C2=A0 }<=
/u>
    =C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0 
    }
    =C2=A0
    In the above, sub-events or extensions have a different format. =
The same complaint about the original stands.
    =C2=A0
    *OR* (if the receiver cares about RIS=
C more).=C2=A0 Note that this leads to a triple nested structure.
    =C2=A0
    {
    =C2=A0 "jti": &=
quot;3d0c3cf797584bd193bd0fb1bd4e7d30",
    =C2=A0 "iat": 1458496025,
    =C2=A0 "iss": "https://scim.example.com",
    =C2=A0 "aud": [
    =C2=A0=C2=A0=C2=A0 "htt=
ps://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
    =C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7&qu=
ot;
    =C2=A0=C2=A0 ],
    =C2=A0=C2=A0 "event": {
    <=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courie=
r New',serif">=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/sec=
event/risc/event-type/\
    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 =C2=A0account-credential-change-required=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0=E2=80=9Ciss=E2=80=9D:"ht=
tps://idp.example.com/=E2=80=9C,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=E2=80=9Cevents=E2=80=9D:{
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &quo=
t;urn:ietf:params:scim:event:passwordReset":=

    =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 {=C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "id":=
=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=9Cevents=E2=80=9D:{
    =C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://example.com/scim/event/passwordResetExt":<=
u>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAttempts":5},<=
span style=3D"font-size:13.5pt">=C2=A0 
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0}=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0}
    =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0=C2=A0 
    =C2=A0=C2=A0=C2=A0}<=
/pre>
    }
    =C2=A0
    In the above,=
 the extension is placed inside the event it extends. It follows the old fo=
rmat (or should it follow the new?)
    *OR* F=
ollowing the top layer pattern of singular event=C2=A0 Note that this leads=
 to a triple nested structure.
    =C2=A0
    {
    =C2=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7<=
wbr>d30",
    =C2=A0 "iat"=
: 1458496025,
    =C2=A0 "iss":=
 "=
https://scim.example.com",
    =
=C2=A0 "aud": [
    =C2=A0=C2=
=A0=C2=A0 "https://jhub.example.com/Feeds=
/98d52461fa5bbc879593b7754",
    =C2=A0=C2=A0=C2=A0 "https://jhub.example.com=
/Feeds/5d7604516b1d08641d7676ee7"
    =C2=A0=C2=A0 ],
    =C2=A0=C2=
=A0 "event": {
    =C2=A0=C2=A0=
=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:=
"http://schemas.openid.net/secevent/risc/event-type/\<=
/a>
    =C2=A0 =C2=A0 =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0account-credential-change-require=
d=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ciss=
=E2=80=9D:"https://idp.example.com/=E2=80=9C,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent=E2=80=9D:=
{
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:=
"urn:ietf:params:scim:event:passwordReset=E2=80=9D,=

    =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "id":=E2=80=9D44f6142df96bd=
6ab61e7521d9=E2=80=9D,
    =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent=E2=80=9D:{
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 =E2=80=9Cevent_type=E2=80=9D:"https://example.=
com/scim/event/passwordResetExt=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=
resetAttempts":5 
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0}
    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 }=C2=A0=C2=A0=C2=A0=C2=A0 
    =
=C2=A0=C2=A0=C2=A0}
    }<=
/pre>
    =C2=A0
    This format follows the proposed=
 singular event format recursively and is 3 layers deep. Note that the pars=
er has to continue to search the document for things that aren=E2=80=99t th=
ere as it has to stop when no =E2=80=9Cevent=E2=80=9D attribute is found ra=
ther than iterate over an array.
    =C2=A0
    Phil

    Oracle = Corporation, Identity Cloud Services Architect
    @independentid
    www.independentid.com
    phil.hun= t@oracle.com
    =C2=A0
    On Oct 30, 2017, at 8:57 AM, Richard Backman, An= nabelle <richanna@amazon.com> wrote:
    =C2=A0
    Replies inline= .
    =C2= =A0
    --= =C2=A0
    Identity Services
    =C2=A0
    <= div>
    =C2=A0
    From:=C2=A0Phil Hunt <phil.= hunt@oracle.com>
    Date:=C2=A0Sund= ay, October 29, 2017 at 5:25 PM
    To:=C2=A0Dick = Hardt <dick.hardt@gmail.com>
    Cc:=C2=A0    Yaron Sheffer <yaronf.ietf@gmail.com>, Mike Jones <Michael.Jones@microsoft.com>, "Richard Backman= , Annabelle" <richanna@amazon.com= >, ID Events Mailing List <id-event@ietf.org>
    Subject:=C2=A0Re: [Id-event] Use c= ases for multiple events per SET?
    =C2=A0
    I hope this answers your ques= tion.
    =C2=A0
    My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reaso= n why not. The question should be, what is the justification to make =E2=80= =9Cevents=E2=80=9D singular?
    [richanna]The singul= ar =E2=80=9Cevent=E2=80=9D claim has clearer semantics and is easier to pro= cess. We should opt for easier solutions unless there are use cases that re= quire more complexity.[/richanna]
    =C2=A0
    There are many reasons for mu= ltiple events in a SET.=C2=A0 Some are good, some not so good. Some of the = reasons...
    =C2=A0
    1.=C2=A0 Multiple event payloads expressing statements abou= t largely the *same*thing. For example, SCIM password reset AND RISC passwo= rd reset.=C2=A0 A RISC Event and an OpenBanking Event. Is one a complement = to the other?=C2=A0 Do they overlap or are they distinct? =C2=A0<= /u>
    [richanna]Copy/pasted from my earlier email:<= u>
    Why is it necessary or appropriate to include these even= ts in the same SET? They are likely being generated by different systems at= different times on the transmitter=E2=80=99s side, consumed by different s= ystems on the receiver=E2=80=99s side, and possibly being transmitted over = different event streams. I know the latter would be the case for us, as a r= eceiver. Even if it=E2=80=99s not, is it burdensome to send these events se= parately? What value is gained in combining them?
    =C2=A0
    Additionally, since the sig= nature is over the SET and not the event objects, Receivers independently r= oute separate events from a single token without either losing the ability = to verify the authenticity of the event or sharing all information in the S= ET with every system handling any event in the token.[/richanna]<= /u>
    =C2=A0

    2.=C2=A0 Multiple events paylo= ads expressing different statements about the same transaction - RISC Passw= ord Reset and RISC Session Cancel
    = [richanna]Same as above[/richanna]

    3.=C2=A0 A new profile defines new e= vent attributes to be added on to an existing event type (a pure extension)= =C2=A0
    [richanna]I have suggested = a way to support extensions within an event body, multiple times now. If yo= u see problems with it, please point them out.[/richanna]<= /u>
    =C2=A0
    I thi= nk it is quite valid to allow 1 and 3. =C2=A02 could be limited by specific= profiles like RISC if they want.
    =
    =C2=A0
    I am not in agreement that making ev= ent singular simplifies anything. For one is makes extensions complex (anot= her nested JSON structure) and potentially conflicting.=C2=A0
    [richanna]
    Way= s that multiple-event SETs are more complicated:
    =
    1. It results in a more= complex structure for the single event use case, which I think we all agre= e is the majority use case.
    2. Multiple-event SETs have ambiguous = semantics. The presence of two events A and B in the same SET could mean an= y of:
      1. They are relate= d to the same logical event (i.e. the same thing as if they were from diffe= rent SETs that have a common txn).
      2. A is an extension of B.
      3. B is an extension of A.
      4. They are aliases for one anothe= r.
      5. They are not actually related to one another in any way.<= /u>
    1. C= laim semantics become harder to define, as different profiles may want to u= se the same claims in different ways.
    =C2=A0
    If the WG wants to block 1 and 2 a= bove, then I believe we have to establish an event registry to ensure new E= vent profiles do not overlap to eliminate the need to express multiple even= ts.
    [richanna]I=E2=80=99m not sure wha= t you mean by this. Are you referring to event names? Those are already def= ined by the spec to be URIs.[/richanna]
    Phil=
    =C2=A0<= /u>
    Orac= le Corporation, Identity Cloud Services Architect
    =
    @independentid
    <= div>
    =C2=A0
    On Oct 29, 2017, at 4:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
    =
    =C2=A0
    Phil:
    =
    =C2=A0
    In your examples for having a plurality of = events, you use the word "may", which leads me to question if a p= lurality of events is really required in SET.
    =C2=A0
    You posit that it will be difficul= t for a distributed system to correlate multiple SETs with the same "t= xn", but the distributed system will certainly need to correlate event= s on the same subject -- correlating events on the same "txn" on = the same subject seems fairly simple.
    =C2=A0
    I think that a receiver will need to corre= late multiple SEts on the same subject, so having multiple events in a SET = is redundant, and adds complexity with no clear benefit that I can see.
    =C2=A0
    An imple= mentor may choose to send multiple SETs, or send a single SET with multiple= events, so a receiver will need to support both. I prefer we pick one way = and minimize the code paths, and we will need to support correlating across= multiple SETs, so that seems the best mechanism.
    =C2=A0
    Let me know if there is someth= ing I missed in my logic.
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif;background-color:white">=C2=A0
    =
    /Dick
    =
    =C2=A0
    =C2=A0
    On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer=C2=A0<yaronf.ietf@gmail.com>=C2=A0wrote:
    In that case, let&#= 39;s add text to that effect, e.g. we could add to the definition of the &q= uot;events" claim:

    Profiling specifications SHOULD define the a= llowed event statements, and MAY restrict their number. For example, some p= rofiles may require this claim to contain only a single event statement.
    Thanks,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Yaron
    On 24/10/17 22:10, Mike Jones wrote:
    =

    I agree with much o= f Phil=E2=80=99s rationale here.

    It=E2=80=99s fine for some profiles= to say that the =E2=80=9Cevents=E2=80=9D set must be a singleton.=C2=A0 Th= at doesn=E2=80=99t have to be true for all events.=C2=A0 I think things are= fine as-is.

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-- Mike
    *From:* Id-event [mailto:id-event-bounce= s@ietf.org] *On Behalf Of *Phil Hunt
    *Sent:* Monday, Oct= ober 23, 2017 8:47 PM
    *To:* Richard Backman, Annabelle <richanna@amazon.com>
    *Cc:* ID Events Mailing Lis= t <id-event@ietf.org    >
    *Subject:* R= e: [Id-event] Use cases for multiple events per SET?

    Annabelle,
    <= br>I have a number of concerns with this proposal.

    Profiling Indepen= dence / Keeping Event Payloads Independent

    Indicating that extension= s should be handled by profiles leads to more inter-operability issues and = more importantly intrudes on the Event payload space by suggesting a sub-sc= hema creates potential limitations and conflicts that may add to complexity= later on. The current format allows a parser to discover and unload one or= more JSON payloads which can each have independent structure.

    Gener= al extensions

    The proposal also rules out general purpose extensions= not related to any specific event. Given the emergence of items like GPRD,= I would not want to block the ability to add meta-data or other general pu= rpose items. We can also anticipate some delivery scenarios where additiona= l data might be required. Even though there is no current planned use, I se= e no good reason to rule this out.

    Multiple Events From Different Fa= milies (vs. Multiple Events from a single family like RISC)

    In our R= ISC session we discussed expressing multiple distinct RISC events in one SE= T. The discussion was that only one RISC event at a time. We did not discus= s other event profiles. I don=E2=80=99t see a reason to rule out multi-even= ts from different families at the SET level. Each profile is expressing sli= ghtly different things about the same event.

    I can forsee some cases= where it is not clear which is the primary and which is the extension.=C2= =A0 There may not be a clear winner.

    A couple of examples (these are= necessarily real=E2=80=A6just possibilities):

    * It is probably usef= ul to be able to express simlar/overlapping events from different SET profi= les in one SET.=C2=A0 For example a Backchannel Logout & a RISC session= cancel event.

    * SCIM may want to represent a single transaction as = causing multiple state changes in an event (e.g. a password change causes m= ultiple effects). Having to chase down multiple events and correlate by =E2= =80=9Ctxn=E2=80=9D would be challenging in a multi-threaded/multi-node deli= very system.=C2=A0 =C2=A0The SCIM list has not discussed this, but I would = not want to block this capability.=C2=A0 IOW - Just because RISC does not w= ant to express multiple events does not make this true for other profiles.<= br>
    * We may wish to indicate a SCIM Password Reset was performed and a = Logout/session cancellation is expressed at the same time.=C2=A0 The events= are related but express different data.

    Avoiding Confusion From Sim= ilar Events Originating from the Same Transaction

    If events are sent= separately, then more tracking of state (e.g. by txn) would be required to= ensure similar events are not mistaken or handled as repeats. While txn pr= ovides useful audit analysis capability, I=E2=80=99m not sure it can be use= d in live or near-real time systems given distributed multi-node, multi-thr= eading architectures.

    Previous Discussion

    I note that I origi= nally raised having an attribute to designate primary event attribute to al= leviate your concern, but this was not accepted. See:

    *=C2=A0https://www= .ietf.org/mail-archive/web/id-event/current/msg00406.html<= /a>

    *=C2=A0    https://www.ietf.org/mail-archive/web/id-event/current/msg00140.html

    The consensus, at least as I interpreted it= is up to the receiver to figure this out based on the definitions it has f= or each event URI and the profiles they represent. IOW - RISC is free to li= mit that only one RISC event be expressed at a time.

    Phil

    Ora= cle Corporation, Identity Cloud Services Architect

    @independentid
    www.independentid.com=C2=A0<h= ttp://www.independentid.com>

    phil.hunt@oracle.com=C2=A0<mailto:phil.hunt@oracle.com>

    =C2=A0= =C2=A0 On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle
    =C2=A0 = =C2=A0 <richanna@amazon.com=C2=A0<mailto:richanna@amazon.com>> wrote:

    =C2=A0 =C2=A0 The current draft of the SET s= pec allows for expressing multiple
    =C2=A0 =C2=A0 events within the same = token, which introduces additional complexity
    =C2=A0 =C2=A0 and room for= ambiguous semantics. We=E2=80=99ve discussed this in the OIDF
    =C2=A0 = =C2=A0 RISC working group and the current consensus there is that RISC will=
    =C2=A0 =C2=A0 require that RISC events must be the only event in the SE= T, having
    =C2=A0 =C2=A0 identified ways to clearly and easily support th= e handful of use
    =C2=A0 =C2=A0 cases for multiple events per token that = people have raised. With
    =C2=A0 =C2=A0 that context in mind, I propose s= triking the definition of the
    =C2=A0 =C2=A0 =E2=80=9Cevents=E2=80=9D cla= im from the Security Event Token spec, and replacing it
    =C2=A0 =C2=A0 wi= th the following definition for an =E2=80=9Cevent=E2=80=9D claim (singular)= :

    =C2=A0 =C2=A0 event

    =C2=A0 =C2=A0 A JSON object containing = an "event_type" member whose value is a URI
    =C2=A0 =C2=A0 repr= esenting a type of event defined in a Profiling Specification.
    =C2=A0 = =C2=A0 The object MAY otherwise be empty, or MAY contain additional members=
    =C2=A0 =C2=A0 as described by the Profiling Specification.

    =C2= =A0 =C2=A0 Here is the example SET from section 2.3, rewritten with this ch= ange
    =C2=A0 =C2=A0 mind:

    =C2=A0 =C2=A0=C2=A0{<= br>
    =C2=A0 =C2=A0 =C2=A0=C2=A0 "jti": "4d3559ec67504aaba6= 5d40b0363faad8",

    =C2=A0 =C2=A0 =C2=A0=C2=A0 "iat"= ;: 1458496404,

    =C2=A0 =C2=A0 =C2=A0=C2=A0"iss": "https://scim.example.com=C2=A0<= https://scim.example.com/>&= quot;,

    =C2=A0 =C2=A0 =C2=A0=C2=A0 "aud": [

    =C2=A0 = =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0"https://scim.example.com/Feeds/98d52461fa5bbc879593b= 7754",

    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0&= quot;https://scim.exam= ple.com/Feeds/5d7604516b1d08641d7676ee7"

    =C2=A0= =C2=A0 =C2=A0=C2=A0 ],

    =C2=A0 =C2=A0 =C2=A0=C2=A0 "event"= : {

    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 "event_type": &= quot;urn:ietf:params:scim:event:create",

    =C2=A0 =C2=A0 =C2= =A0=C2=A0=C2=A0=C2=A0 "ref": "https://scim.example.com/Users/44f6142df96bd6ab= 61e7521d9",

    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 &= quot;attributes": ["id", "name", "userName&qu= ot;, "password", "emails"]

    =C2=A0 =C2=A0 =C2=A0= =C2=A0 }

    =C2=A0 =C2=A0 }

    =C2=A0 =C2=A0 Does anyone in the wor= king group have use cases for SETs that cannot
    =C2=A0 =C2=A0 be met by t= his proposed text? Within RISC, we identified three use
    =C2=A0 =C2=A0 ca= ses, with solutions outlined below:

    =C2=A0 =C2=A0 **

    =C2=A0 = =C2=A0 *Extensions*

    =C2=A0 =C2=A0 Event extension mechanisms can be = defined internal to the event
    =C2=A0 =C2=A0 object. A simple approach wo= uld be to =C2=A0define an =E2=80=9Cextensions=E2=80=9D member
    =C2=A0 =C2= =A0 that is a list of event objects (or set resembling the =E2=80=9Cevents= =E2=80=9D
    =C2=A0 =C2=A0 claim as defined in the current spec). This has = the advantage of
    =C2=A0 =C2=A0 making it clear in the data structure tha= t there is a single primary
    =C2=A0 =C2=A0 event, with zero or more exten= sions. There is no room for confusion
    =C2=A0 =C2=A0 over which event is = primary, or if there is a primary event at all.
    =C2=A0 =C2=A0 I would be= fine with adding something like this to my proposed text,
    =C2=A0 =C2=A0= if there is consensus that it is broadly useful.

    =C2=A0 =C2=A0 *Ali= ases*

    =C2=A0 =C2=A0 This use case was brought up in the context of m= igrating clients
    =C2=A0 =C2=A0 from draft event names to standardized ev= ent names. In this case,
    =C2=A0 =C2=A0 the event transmitter can transmi= t two tokens for the logical event,
    =C2=A0 =C2=A0 one using the old name= and another using the new name.

    =C2=A0 =C2=A0 *Related Events*
    <= br>=C2=A0 =C2=A0 The SET spec defines the txn claim as a means of correlati= ng
    =C2=A0 =C2=A0 independent tokens that relate to the same logical even= t.

    =C2=A0 =C2=A0 --=C2=A0
    =C2=A0 =C2=A0 Annabe= lle Richard Backman

    =C2=A0 =C2=A0 Amazon =E2=80=93 Identity Services=

    =C2=A0 =C2=A0 _______________________________________________<= br>=C2=A0 =C2=A0 Id-event mailing list
    =C2=A0 =C2=A0=C2=A0Id-event@ietf.org=C2=A0<mailto:Id-event@ietf.org>=C2=A0 =C2=A0=C2=A0https://url= defense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_= listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQ= cxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe= 4C_lLIGk&m=3Ds5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&= s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D


    _______________________________________________
    Id-eve= nt mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event

    _______________________________________________
    Id-event mailing = list
    = Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event
    =

    =C2=A0
    --=C2=A0
    Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn = about projects I am working on!
    =C2=A0
    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org

    =C2=A0
    --
    Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I a= m working on!
    =

    <= br clear=3D"all">
    =C2=A0
    --
    Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I = am working on!


    =C2=A0
    =
    --
    Subscribe = to the=C2=A0HARDTWAR= E=C2=A0mail list to learn about projects I am working on!
    <= /div>


    <= u>
    =C2=A0
    --=C2=A0
    = Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I am wor= king on!
    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet= f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumC= XCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4Dpct= yXPpuYqPkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZktcmagv5Ea21QEip4HXpE= VKRa0qhlo&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&= ;e=3D
    =

    ________________________________= _______________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf= .org/mailman/listinfo/id-event



    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event


    --001a113ffcf0949d0a055cf2d031-- From nobody Wed Nov 1 14:55:15 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B68313F6A5 for ; Wed, 1 Nov 2017 14:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ZbLmabAmYkXT for ; Wed, 1 Nov 2017 14:55:09 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32BD13F68E for ; Wed, 1 Nov 2017 14:55:08 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id 134so9419789ioo.0 for ; Wed, 01 Nov 2017 14:55:08 -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=LGVzFWrvgUcvWa7dridNYHlZ8b2qTF0HqoAFkGmnAt4=; b=vhZ9EI2oOXI9SexAuBdMPj1eDjwm17zrIaPxsmZZLw5Lh0XFtmzySCBFOYgB0vPKnD rxV7gocF2BEq9RRj6tRH3OgjcSCPXctsepOVSrlr7W/GtCHKcuPVwhwXjaKVtkkrFGmI 6CtPtJFm1PoekmnHIBPug8DsfjYWp3ehaIJexzL6btntOCALYTXtcHxJ/fK0sbwYHZqR JCdvWPenYYa7Aqnf+aGbrakuOALywqVUQmooMOGBCL69EUw37g+4MYJT43eaWo56R/j/ y8P0QiWQyUpcO6wZECLLRAAQ78b7GkBYngAKffgWx7cWrgazPhhKbQrqiniORSDd+EjY ck7w== 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=LGVzFWrvgUcvWa7dridNYHlZ8b2qTF0HqoAFkGmnAt4=; b=kMkvOytEhnA7VLEdKroBDj7qn1GQ8aCJIZf7tAW14c41ap8roFDOa5Le4Uwg8WPcu7 uhePDjL14StXPk/tD6qZqJFnhV5PgdtytAlw1fkD/vZQ7tuSJIJxyRRCnX1K90wt7mod e76nBCTioSzSH8zc6vQCQTxxEKw7DtGoF6LtX3+1b89p4fLHcaeP2z0uXc35Z0tUmowk k5qoC7fz/OlfhEkl4pDvFn/gUn9uDvmFJjpZvpXHd6riejNhgPeSISMpmSSGJWe+WnRM MGpW9/sz+PBBFMSPQmJqCwQQO93yjC+ovVC3nxbS7P9mVHmQwvDkYD2Jqss4j8cSOVEY 1+Kg== X-Gm-Message-State: AMCzsaVOjKWK6fMzEkm86sWLm3ulsHuG/8LUApQJaMsRe0+teGfVt3fA AAy31CBF8aoYNwTIlQEO4OXo3aXF6N6ByJ+J/uJOyA== X-Google-Smtp-Source: ABhQp+REsAz6SqCXSTqohzXf6uvbXF6JF5l3+2Pi4qb15IjYilPBW5ipdyV18tjt8D455OGiUDK0oG3JAnop6vpWT7k= X-Received: by 10.36.178.85 with SMTP id h21mr2641917iti.118.1509573307197; Wed, 01 Nov 2017 14:55:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.34.9 with HTTP; Wed, 1 Nov 2017 14:54:45 -0700 (PDT) In-Reply-To: References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> From: Marius Scurtescu Date: Wed, 1 Nov 2017 14:54:45 -0700 Message-ID: To: William Denniss Cc: Phil Hunt , Yaron Sheffer , "Richard Backman, Annabelle" , Dick Hardt , Mike Jones , ID Events Mailing List Content-Type: multipart/alternative; boundary="f403045d9a14bd8cf4055cf2ec3d" Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 21:55:14 -0000 --f403045d9a14bd8cf4055cf2ec3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 1, 2017 at 2:46 PM, William Denniss wrote= : > Perhaps I can try and explain the original intent of the current design. > The goal was always that a SET represents a single logical event. However > multiple systems may have different representations of the event =E2=80= =93 the > example given originally was one formatted for RISC, and one for SCIM. > > A good analogy is email. You send a single logical email, which may have > two representations, HTML and plain text. Systems can consume the version > that they understand and ignore the one they don't. > Yes, and I think this is well understood. > > I'm starting to regret the plural in "events", it was pluralized due to i= t > being an array, not because it represented multiple logical events. > I don't think this is the main concern or cause for confusion. > > Annabelle, I understand your concerns regarding confusion of the semantic= s > between the JSON syntax and the specification language. Are there other > ways to resolve that without removing the ability for multiple > representations of the same event? > The argument is that multiple representations can be sent as distinct SETs, if really needed. In practice this will happen quite rare though. Events are created for a specific receiver, the receiver either wants the SCIM or the RISC flavor, and they should be able to specify that in configuration (there is a proposal how to capture that). Do we have a compelling use case where a receiver must receive multiple variants all at once? > > On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu > wrote: > >> On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt wrote: >> >>> You can=E2=80=99t really have multiple events (at least of the same typ= e). The >>> current spec can only have one instance of a URI (afaik). >>> >>> Note that the spec normatively does not support multiple event SETS. I= t >>> currently states: >>> >>> events >>> *The semantics of this claim is to define a set of event statemen= ts >>> that each MAY add additional claims to fully describe a single >>> logical event* that has occurred (e.g. a state change to a >>> subject). Multiple event statements of the same type SHALL NOT b= e >>> accepted. The "events" claim SHOULD NOT be used to express >>> multiple logical events. >>> >>> >>> The spec has *always* supported requirements (as stated in the spec) fo= r >>> multiple separate profile statements (from one or more profile familiti= es) >>> needing to be sent as a single message. It would be INSECURE to force >>> multiple SETs because the current delivery mechanism only allows one SE= T to >>> be delivered at a time. There is no way to assure that a single receive= r >>> gets all of the SETs it needs in a multi-threaded, multi-node environme= nt >>> at scale. Assembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a= common state >>> database is NOT simple nor cost effective. >>> >> >> I totally agree that it is difficult for receivers to receive separate >> events, in no particular order and correlate based on "txn". But, receiv= ers >> have to solve this issue regardless of "events" or "event", so it is >> unrelated to this proposal. >> >> >> >>> >>> If we accommodate this in the proposed form, we end up with a complex, >>> deeply nested JSON structure with the possibility of namespace conflict= s. >>> >>> IMO The proposal does not simplify, it complicating and limiting. >>> >>> The current spec has very clean JSON and avoids namespace conflicts >>> between profiles. I think we should stay on track with the current draf= t >>> and observe the normative text if not make it stronger in regards to >>> multi-events (understood that Mike may disagree). >>> >>> Phil >>> >>> Oracle Corporation, Identity Cloud Services Architect >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> On Nov 1, 2017, at 12:18 PM, Richard Backman, Annabelle < >>> richanna@amazon.com> wrote: >>> >>> Unless the profile guarantees that such related events will always be >>> included in the same SET, then the receiver has to correlate across SET= s >>> anyway, and multiple events per SET is just giving the receiver another >>> scenario that they have to support. >>> >>> I=E2=80=99ve already provided several other reasons why we should not s= upport >>> multiple tokens per SET that no one has addressed. Here they are again: >>> >>> 1. Multiple event support results in a more complex structure for >>> the single event use case, which I think we all agree is the majorit= y use >>> case. >>> 2. Multiple-event SETs have ambiguous semantics. The presence of two >>> events A and B in the same SET could mean any of: >>> 1. A and B are related to the same logical event (i.e. the same >>> thing as if they were from different SETs that have a common txn)= . >>> 2. A is an extension of B. >>> 3. B is an extension of A. >>> 4. A is an alias for B, or vice-versa. >>> 5. A and B are not actually related to one another in any way, >>> and the transmitter bundled them together because they were going= to the >>> same receiver. >>> 3. Top-level claim semantics become harder to define, as different >>> profiles may want to use the same claims in different ways. >>> 4. Event authenticity cannot be verified without having the entire >>> SET. This forces receivers to expose downstream systems to more info= rmation >>> necessary, if those systems need to be able to verify authenticity. >>> >>> >>> -- >>> Annabelle Richard Backman >>> Amazon =E2=80=93 Identity Services >>> >>> >>> *From: *Mike Jones >>> *Date: *Wednesday, November 1, 2017 at 11:21 AM >>> *To: *Dick Hardt >>> *Cc: *Yaron Sheffer , "Richard Backman, >>> Annabelle" , ID Events Mailing List < >>> id-event@ietf.org>, "Phil Hunt (IDM)" >>> *Subject: *RE: [Id-event] Use cases for multiple events per SET? >>> >>> I completely agree on moving complexity to the issuer over the >>> recipient. In my view, it=E2=80=99s more complex for recipients to hav= e to >>> correlate and process a sequence of multiple SETs providing information >>> about the same logical event, and validate N signatures, than to receiv= e >>> one SET with all the aspects of the logical event as =E2=80=9Cevents=E2= =80=9D fields, with >>> no correlation over time then required. >>> >>> -- Mike >>> >>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com ] >>> *Sent:* Wednesday, November 1, 2017 9:39 AM >>> *To:* Mike Jones >>> *Cc:* Yaron Sheffer ; Richard Backman, Annabelle >>> ; ID Events Mailing List ; Phil >>> Hunt (IDM) >>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>> >>> Your comments highlight a couple of points: >>> >>> 1) The example is how to have a predefined extension point for >>> extensions of a specific event, it is not how to add another event. Mys= elf, >>> I think this is overly complicated. Events should be comparatively stat= ic, >>> and as with many other JSON formats, the receiver should ignore propert= ies >>> it does not understand, which let's new properties be introduced as >>> extensions. There should not be any conflict as extensions should only = be >>> done by the profile that created the event format to start off with. >>> >>> 2) Having an lvalue be a URI is much harder to code against. I'm not >>> sure why Marius had that in his example. Per the event, the type of the >>> event is well defined with >>> >>> "event_type": "https://example.com/scim/event/passwordResetExt", >>> >>> 3) This thread is about reasons for multiple events to be contained in >>> one set. Your mention of an issuer not wanting to sign separate events = as a >>> reason to allow multiple events. I think we have decided that given a >>> preference, we will push effort to the transmitter over the receiver as= in >>> many use cases there are many more receivers. Given that, it is more >>> complex for a receiver to have different ways of managing the receipt o= f >>> multiple events as not all issuers will bundle the events, so it is sim= pler >>> to have only one event per SET. Including the separate events with a UR= I as >>> an lvalue is challenging to implement, speaking from experience. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones < >>> Michael.Jones@microsoft.com> wrote: >>> >>> Marius=E2=80=99 proposed syntax, pasted in below, has exactly this >>> characteristic. The way I see it, his proposal essentially has a prima= ry >>> passwordReset event and a secondary passwordResetExt data structure, wh= ich >>> could have been simply another event value in the current draft. >>> >>> This breaking change makes the data structures more complicated - not >>> less. And it makes things that used to be possible impossible, reducin= g >>> flexibility to those who would use the spec. >>> >>> These seem like bad tradeoffs to me. >>> >>> { >>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>> "iat": 1458496025, >>> "iss": "https://scim.example.com", >>> "aud": [ >>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>> ], >>> "event_type": "https://example.com/scim/event/passwordResetExt", >>> "event": { >>> "id":"44f6142df96bd6ab61e7521d9", >>> "extensions": { >>> "https://example.com/scim/event/passwordResetExt=E2=80=9D: { >>> "resetAttempts":5, >>> } >>> } >>> } >>> } >>> >>> In particular, it makes it impossible to sign multiple related events >>> sharing a common claims schema with a single signature by the issuer. = It >>> forces the issuer to do the extra work of signing each of the related >>> events (or facets of the same logical event) individually and forces th= e >>> recipients to do the extra work of checking all those unnecessary >>> signatures. >>> >>> Not every profile will ever have multiple keys in the =E2=80=9Cevents= =E2=80=9D set but >>> there=E2=80=99s absolutely no reason to preclude it. >>> >>> -- Mike >>> >>> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Dick >>> Hardt >>> *Sent:* Tuesday, October 31, 2017 9:52 PM >>> *To:* Mike Jones >>> *Cc:* Yaron Sheffer ; Richard Backman, Annabelle >>> ; ID Events Mailing List ; Phil >>> Hunt (IDM) >>> >>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>> >>> Please direct me to a proposal that has a "primary" and "secondary" >>> events. I agree that is undesirable. I would also encourage to engage i= n >>> the discussions so that we can drive clarity and simplicity. >>> >>> I think the proposal is that there is one event per SET. >>> >>> I think having more than one event per SET adds complexity as a receive= r >>> must deal with receiving correlated events in one SET as well as correl= ated >>> events in the same SET. >>> >>> /Dick >>> >>> On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones >>> wrote: >>> >>> I hear you on the fact that different people have joined the effort at >>> different times. That=E2=80=99s a normal process as an effort builds m= omentum. I >>> get that not everyone was there when previous consensus calls were take= n. >>> >>> I should note that I have specific technical objections to the specific >>> proposed changes being discussed as well. Currently all events in the = set >>> have the same syntax. The proposals, as I understand them, revert us t= o a >>> state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and =E2=80=9Cse= condary=E2=80=9D events, with different >>> syntax for the two classes. That=E2=80=99s needlessly more complicated= , adding no >>> actual value. >>> >>> -- Mike >>> >>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>> *Sent:* Tuesday, October 31, 2017 9:37 PM >>> *To:* Mike Jones >>> *Cc:* Phil Hunt (IDM) ; Yaron Sheffer < >>> yaronf.ietf@gmail.com>; Richard Backman, Annabelle ; >>> ID Events Mailing List >>> >>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>> >>> Mike >>> >>> As you well know, many people in a WG don't look closely at a >>> specification until last call is made. Additionally, we are coming up o= n >>> only the 3rd WG meeting. The WG has not existed for very long. While so= me >>> of the participants have been working on this for a while, many have no= t, >>> and we are looking for consensus across the WG. >>> >>> Since SecEvent is a framework that we expect to be profiled, I feel it >>> is important to ensure that SecEvent specifications are easy for a vari= ety >>> of profiles to adopt, and that the semantics make sense. I also think t= hat >>> properties that are specific to a profile should be left to that profil= e >>> and not be included in SecEvent. >>> >>> Since this is a framework, it is expected that as different groups >>> profile it, there will be additional feedback. >>> >>> Specifically, as a participant in the RISC profile of SET, a number of >>> issues in SET have surfaced as the RISC WG has looked at how to use the= SET. >>> >>> As for SET being stable for over a year, there have been a number of >>> changes to SET since then. I also don't think there was consensus. Befo= re >>> the WG was formed, I and several others had expressed concern on the de= sign >>> of SET when Phil presented it at an IIW session. >>> >>> As to taking another year, I am hopeful we can resolve the remaining >>> issues in SET and publish a new draft for last call. I do not think we = will >>> need to wait for another WG meeting to ask for last call. >>> >>> We also have a number of other documents that are not in last call, and >>> we don't have a WG adopted draft yet for management. So there are still= a >>> number of documents to work through before we have all the bits for som= eone >>> to work with. >>> >>> I do think we have been making good progress since the last IETF >>> meeting, and I am hopeful we can keep up this momentum and finalize all= the >>> documents in a timely manner. >>> >>> /Dick >>> >>> >>> On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones < >>> Michael.Jones@microsoft.com> wrote: >>> >>> It=E2=80=99s hard for me to even express my level of frustration with t= he recent >>> attempts to once again redesign the SecEvent Token spec. We=E2=80=99ve= been at >>> this for multiple years because people keep trying to revisit decisions >>> that were long ago made by consensus. It=E2=80=99s been stable for ove= r a year and >>> the majority of WGLC respondents said some variant of =E2=80=9CWorks fo= r me =E2=80=93 ship >>> it!=E2=80=9D >>> >>> There=E2=80=99s not sufficient justification to try to undo consensus p= ositions >>> that have been debated and affirmed over and over. Countenancing whole= sale >>> changes at this late date is counterproductive in the extreme! >>> >>> It=E2=80=99s far better than good enough as-is. In my experience, if w= e start >>> redesigning it, it will result in another year=E2=80=99s delay. It doe= s something >>> simple and useful. Please, let=E2=80=99s just ship it, so people can r= ely on it. >>> >>> -- Mike >>> >>> *From:* Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] >>> *Sent:* Monday, October 30, 2017 2:42 PM >>> *To:* Dick Hardt >>> *Cc:* Yaron Sheffer ; Richard Backman, Annabelle >>> ; Mike Jones ; ID >>> Events Mailing List >>> >>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>> >>> Inline... >>> >>> Phil >>> >>> >>> On Oct 30, 2017, at 2:22 PM, Dick Hardt wrote: >>> >>> Hi Phil >>> >>> Correct me if I am misunderstanding, but there is a RISC profile event >>> >>> >>> >>> "http://schemas.openid.net/secevent/risc/event-type/ ac= count-credential-change-required=E2=80=9D >>> >>> >>> >>> and an SCIM profile event >>> >>> >>> "https://example.com/scim/event/passwordResetExt=E2=80=9D >>> >>> >>> >>> I'm suggesting that two different events would be sent. Embedding one i= n >>> the other does not make sense. >>> >>> It is a hypothetical example. Just because you disagree on this doe= s >>> not mean others are not valid. >>> >>> I just picked overlapping proposals that have different meaning (but no= t >>> the same) to illustrate the difference from issuing a single set with >>> different events. >>> >>> >>> As I have stated this is very different from asserting multiple distinc= t >>> events in one SET. >>> >>> >>> Also, I think it is simpler to have event_type be at the same level as >>> event >>> >>> >>> >>> may be. I was working from Annabelle's proposed format. >>> >>> >>> { >>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>> "iat": 1458496025, >>> "iss": "https://scim.example.com", >>> "aud": [ >>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>> ], >>> "event_type": "https://example.com/scim/event/passwordResetExt", >>> "event": { >>> "id":"44f6142df96bd6ab61e7521d9", >>> "resetAttempts":5 >>> } >>> } >>> >>> { >>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>> "iat": 1458496025, >>> "iss": "https://scim.example.com", >>> "aud": [ >>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>> ], >>> "event_type": "http://schemas.openid.net/sec >>> event/risc/event-type/account-credential-change-required >>> >>> ", >>> "event": { >>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>> } >>> } >>> >>> >>> >>> >>> >>> On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt >>> wrote: >>> >>> Annabelle/Dick, >>> >>> Thanks for the comments. I think we need to examine the consequences of >>> the proposal in JSON. >>> >>> As I stated, what causes most of the issue is the proposed extension >>> mechanism in the payload (possibly using events in a recursive way). Do= es >>> it follow the old format or the new? >>> >>> Let=E2=80=99s consider a use case where we have an identity management= system >>> that uses SCIM, but the SCIM system is also the underlying data store f= or >>> Connect. A Password reset might generate the following event which has= an >>> extension (conveying reset count) AND overlapping statement from RISC. >>> BOTH of which might be important to a similar receiver using SCIM and O= IDC. >>> >>> >>> *The 03 spec currently would allow:* >>> >>> >>> { >>> >>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>> >>> "iat": 1458496025, >>> >>> "iss": "https://scim.example.com", >>> >>> "aud": [ >>> >>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>> >>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>> >>> ], >>> >>> "events": { >>> >>> "urn:ietf:params:scim:event:passwordReset": >>> >>> { "id":"44f6142df96bd6ab61e7521d9"}, >>> >>> "https://example.com/scim/event/passwordResetExt": >>> >>> { "resetAttempts":5}, >>> >>> "http://schemas.openid.net/secevent/risc/event-type/\ >>> account-credential-change-required": { >>> >>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>> >>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>> >>> } >>> >>> } >>> >>> } >>> >>> >>> >>> In the above - each payload is a =E2=80=98peer' and issued without pref= erence by the transmitter. The receiver can assign priority in its own cont= ext if that matters. >>> >>> >>> >>> *The new proposal:* >>> >>> >>> >>> { >>> >>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>> >>> "iat": 1458496025, >>> >>> "iss": "https://scim.example.com", >>> >>> "aud": [ >>> >>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>> >>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>> >>> ], >>> >>> "event": { >>> >>> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passwordR= eset=E2=80=9D, >>> >>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>> >>> =E2=80=9Cevents=E2=80=9D:{ >>> >>> ->note =E2=80=A6is this the old or new structure? <- >>> >>> "https://example.com/scim/event/passwordResetExt": >>> >>> { "resetAttempts":5}, >>> >>> "http://schemas.openid.net/secevent/risc/event-type/\ >>> account-credential-change-required": { >>> >>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>> >>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>> >>> } >>> >>> } >>> >>> } >>> >>> } >>> >>> >>> >>> In the above, sub-events or extensions have a different format. The sam= e complaint about the original stands. >>> >>> >>> >>> **OR* (if the receiver cares about RISC more). Note that this leads to= a triple nested structure.* >>> >>> >>> >>> { >>> >>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>> >>> "iat": 1458496025, >>> >>> "iss": "https://scim.example.com", >>> >>> "aud": [ >>> >>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>> >>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>> >>> ], >>> >>> "event": { >>> >>> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/r= isc/event-type/\ >>> >>> account-credential-change-required=E2=80=9D, >>> >>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>> >>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >>> >>> =E2=80=9Cevents=E2=80=9D:{ >>> >>> "urn:ietf:params:scim:event:passwordReset": >>> >>> { >>> >>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>> >>> =E2=80=9Cevents=E2=80=9D:{ >>> >>> "https://example.com/scim/event/passwordResetExt": >>> >>> { "resetAttempts":5}, >>> >>> } >>> >>> } >>> >>> } >>> >>> } >>> >>> } >>> >>> >>> >>> In the above, the extension is placed inside the event it extends. It f= ollows the old format (or should it follow the new?) >>> >>> **OR* Following the top layer pattern of singular event Note that this= leads to a triple nested structure.* >>> >>> >>> >>> { >>> >>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>> >>> "iat": 1458496025, >>> >>> "iss": "https://scim.example.com", >>> >>> "aud": [ >>> >>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>> >>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>> >>> ], >>> >>> "event": { >>> >>> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/r= isc/event-type/\ >>> >>> account-credential-change-required=E2=80=9D, >>> >>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>> >>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >>> >>> =E2=80=9Cevent=E2=80=9D:{ >>> >>> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passwo= rdReset=E2=80=9D, >>> >>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>> >>> =E2=80=9Cevent=E2=80=9D:{ >>> >>> =E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/event/= passwordResetExt=E2=80=9D, >>> >>> "resetAttempts":5 >>> >>> } >>> >>> } >>> >>> } >>> >>> } >>> >>> >>> >>> This format follows the proposed singular event format recursively and = is 3 layers deep. Note that the parser has to continue to search the docume= nt for things that aren=E2=80=99t there as it has to stop when no =E2=80=9C= event=E2=80=9D attribute is found rather than iterate over an array. >>> >>> >>> >>> Phil >>> >>> Oracle Corporation, Identity Cloud Services Architect >>> @independentid >>> www.independentid.com >>> >>> phil.hunt@oracle.com >>> >>> >>> On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle < >>> richanna@amazon.com> wrote: >>> >>> Replies inline. >>> >>> -- >>> Annabelle Richard Backman >>> Identity Services >>> >>> >>> *From: *Phil Hunt >>> *Date: *Sunday, October 29, 2017 at 5:25 PM >>> *To: *Dick Hardt >>> *Cc: *Yaron Sheffer , Mike Jones < >>> Michael.Jones@microsoft.com>, "Richard Backman, Annabelle" < >>> richanna@amazon.com>, ID Events Mailing List >>> *Subject: *Re: [Id-event] Use cases for multiple events per SET? >>> >>> I hope this answers your question. >>> >>> My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reason why n= ot. The question should >>> be, what is the justification to make =E2=80=9Cevents=E2=80=9D singular= ? >>> [richanna]The singular =E2=80=9Cevent=E2=80=9D claim has clearer semant= ics and is easier >>> to process. We should opt for easier solutions unless there are use cas= es >>> that require more complexity.[/richanna] >>> >>> There are many reasons for multiple events in a SET. Some are good, >>> some not so good. Some of the reasons... >>> >>> 1. Multiple event payloads expressing statements about largely the >>> *same*thing. For example, SCIM password reset AND RISC password reset. = A >>> RISC Event and an OpenBanking Event. Is one a complement to the other? = Do >>> they overlap or are they distinct? >>> [richanna]Copy/pasted from my earlier email: >>> Why is it necessary or appropriate to include these events in the same >>> SET? They are likely being generated by different systems at different >>> times on the transmitter=E2=80=99s side, consumed by different systems = on the >>> receiver=E2=80=99s side, and possibly being transmitted over different = event >>> streams. I know the latter would be the case for us, as a receiver. Eve= n if >>> it=E2=80=99s not, is it burdensome to send these events separately? Wha= t value is >>> gained in combining them? >>> >>> Additionally, since the signature is over the SET and not the event >>> objects, Receivers independently route separate events from a single to= ken >>> without either losing the ability to verify the authenticity of the eve= nt >>> or sharing all information in the SET with every system handling any ev= ent >>> in the token.[/richanna] >>> >>> >>> 2. Multiple events payloads expressing different statements about the >>> same transaction - RISC Password Reset and RISC Session Cancel >>> [richanna]Same as above[/richanna] >>> 3. A new profile defines new event attributes to be added on to an >>> existing event type (a pure extension) >>> [richanna]I have suggested a way to support extensions within an event >>> body, multiple times now. If you see problems with it, please point the= m >>> out.[/richanna] >>> >>> I think it is quite valid to allow 1 and 3. 2 could be limited by >>> specific profiles like RISC if they want. >>> >>> I am not in agreement that making event singular simplifies anything. >>> For one is makes extensions complex (another nested JSON structure) and >>> potentially conflicting. >>> [richanna] >>> Ways that multiple-event SETs are more complicated: >>> >>> 1. It results in a more complex structure for the single event use >>> case, which I think we all agree is the majority use case. >>> 2. Multiple-event SETs have ambiguous semantics. The presence of two >>> events A and B in the same SET could mean any of: >>> >>> >>> 1. They are related to the same logical event (i.e. the same thing >>> as if they were from different SETs that have a common txn). >>> 2. A is an extension of B. >>> 3. B is an extension of A. >>> 4. They are aliases for one another. >>> 5. They are not actually related to one another in any way. >>> >>> >>> 1. Claim semantics become harder to define, as different profiles >>> may want to use the same claims in different ways. >>> >>> >>> If the WG wants to block 1 and 2 above, then I believe we have to >>> establish an event registry to ensure new Event profiles do not overlap= to >>> eliminate the need to express multiple events. >>> [richanna]I=E2=80=99m not sure what you mean by this. Are you referring= to event >>> names? Those are already defined by the spec to be URIs.[/richanna] >>> Phil >>> >>> Oracle Corporation, Identity Cloud Services Architect >>> @independentid >>> www.independentid.com >>> >>> phil.hunt@oracle.com >>> >>> >>> On Oct 29, 2017, at 4:12 PM, Dick Hardt wrote: >>> >>> Phil: >>> >>> In your examples for having a plurality of events, you use the word >>> "may", which leads me to question if a plurality of events is really >>> required in SET. >>> >>> You posit that it will be difficult for a distributed system to >>> correlate multiple SETs with the same "txn", but the distributed system >>> will certainly need to correlate events on the same subject -- correlat= ing >>> events on the same "txn" on the same subject seems fairly simple. >>> >>> I think that a receiver will need to correlate multiple SEts on the sam= e >>> subject, so having multiple events in a SET is redundant, and adds >>> complexity with no clear benefit that I can see. >>> >>> An implementor may choose to send multiple SETs, or send a single SET >>> with multiple events, so a receiver will need to support both. I prefer= we >>> pick one way and minimize the code paths, and we will need to support >>> correlating across multiple SETs, so that seems the best mechanism. >>> >>> Let me know if there is something I missed in my logic. >>> >>> /Dick >>> >>> >>> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer >>> wrote: >>> >>> In that case, let's add text to that effect, e.g. we could add to the >>> definition of the "events" claim: >>> >>> Profiling specifications SHOULD define the allowed event statements, an= d >>> MAY restrict their number. For example, some profiles may require this >>> claim to contain only a single event statement. >>> >>> Thanks, >>> Yaron >>> >>> On 24/10/17 22:10, Mike Jones wrote: >>> >>> I agree with much of Phil=E2=80=99s rationale here. >>> >>> It=E2=80=99s fine for some profiles to say that the =E2=80=9Cevents=E2= =80=9D set must be a >>> singleton. That doesn=E2=80=99t have to be true for all events. I thi= nk things >>> are fine as-is. >>> >>> -- Mik= e >>> >>> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Phil >>> Hunt >>> *Sent:* Monday, October 23, 2017 8:47 PM >>> *To:* Richard Backman, Annabelle >>> *Cc:* ID Events Mailing List >>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>> >>> Annabelle, >>> >>> I have a number of concerns with this proposal. >>> >>> Profiling Independence / Keeping Event Payloads Independent >>> >>> Indicating that extensions should be handled by profiles leads to more >>> inter-operability issues and more importantly intrudes on the Event pay= load >>> space by suggesting a sub-schema creates potential limitations and >>> conflicts that may add to complexity later on. The current format allow= s a >>> parser to discover and unload one or more JSON payloads which can each = have >>> independent structure. >>> >>> General extensions >>> >>> The proposal also rules out general purpose extensions not related to >>> any specific event. Given the emergence of items like GPRD, I would not >>> want to block the ability to add meta-data or other general purpose ite= ms. >>> We can also anticipate some delivery scenarios where additional data mi= ght >>> be required. Even though there is no current planned use, I see no good >>> reason to rule this out. >>> >>> Multiple Events From Different Families (vs. Multiple Events from a >>> single family like RISC) >>> >>> In our RISC session we discussed expressing multiple distinct RISC >>> events in one SET. The discussion was that only one RISC event at a tim= e. >>> We did not discuss other event profiles. I don=E2=80=99t see a reason t= o rule out >>> multi-events from different families at the SET level. Each profile is >>> expressing slightly different things about the same event. >>> >>> I can forsee some cases where it is not clear which is the primary and >>> which is the extension. There may not be a clear winner. >>> >>> A couple of examples (these are necessarily real=E2=80=A6just possibili= ties): >>> >>> * It is probably useful to be able to express simlar/overlapping events >>> from different SET profiles in one SET. For example a Backchannel Logo= ut & >>> a RISC session cancel event. >>> >>> * SCIM may want to represent a single transaction as causing multiple >>> state changes in an event (e.g. a password change causes multiple effec= ts). >>> Having to chase down multiple events and correlate by =E2=80=9Ctxn=E2= =80=9D would be >>> challenging in a multi-threaded/multi-node delivery system. The SCIM = list >>> has not discussed this, but I would not want to block this capability. = IOW >>> - Just because RISC does not want to express multiple events does not m= ake >>> this true for other profiles. >>> >>> * We may wish to indicate a SCIM Password Reset was performed and a >>> Logout/session cancellation is expressed at the same time. The events = are >>> related but express different data. >>> >>> Avoiding Confusion From Similar Events Originating from the Same >>> Transaction >>> >>> If events are sent separately, then more tracking of state (e.g. by txn= ) >>> would be required to ensure similar events are not mistaken or handled = as >>> repeats. While txn provides useful audit analysis capability, I=E2=80= =99m not sure >>> it can be used in live or near-real time systems given distributed >>> multi-node, multi-threading architectures. >>> >>> Previous Discussion >>> >>> I note that I originally raised having an attribute to designate primar= y >>> event attribute to alleviate your concern, but this was not accepted. S= ee: >>> >>> * https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html >>> >>> >>> * https://www.ietf.org/mail-archive/web/id-event/current/msg00140.html >>> >>> >>> The consensus, at least as I interpreted it is up to the receiver to >>> figure this out based on the definitions it has for each event URI and = the >>> profiles they represent. IOW - RISC is free to limit that only one RISC >>> event be expressed at a time. >>> >>> Phil >>> >>> Oracle Corporation, Identity Cloud Services Architect >>> >>> @independentid >>> >>> www.independentid.com >>> >>> >> >>> > >>> >>> phil.hunt@oracle.com >>> >>> On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle >>> > wrote: >>> >>> The current draft of the SET spec allows for expressing multiple >>> events within the same token, which introduces additional complexit= y >>> and room for ambiguous semantics. We=E2=80=99ve discussed this in t= he OIDF >>> RISC working group and the current consensus there is that RISC wil= l >>> require that RISC events must be the only event in the SET, having >>> identified ways to clearly and easily support the handful of use >>> cases for multiple events per token that people have raised. With >>> that context in mind, I propose striking the definition of the >>> =E2=80=9Cevents=E2=80=9D claim from the Security Event Token spec, = and replacing it >>> with the following definition for an =E2=80=9Cevent=E2=80=9D claim = (singular): >>> >>> event >>> >>> A JSON object containing an "event_type" member whose value is a UR= I >>> representing a type of event defined in a Profiling Specification. >>> The object MAY otherwise be empty, or MAY contain additional member= s >>> as described by the Profiling Specification. >>> >>> Here is the example SET from section 2.3, rewritten with this chang= e >>> mind: >>> >>> { >>> >>> "jti": "4d3559ec67504aaba65d40b0363faad8", >>> >>> "iat": 1458496404, >>> >>> "iss": "https://scim.example.com ", >>> >>> "aud": [ >>> >>> "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", >>> >>> "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" >>> >>> ], >>> >>> "event": { >>> >>> "event_type": "urn:ietf:params:scim:event:create", >>> >>> "ref": "https://scim.example.com/User >>> s/44f6142df96bd6ab61e7521d9", >>> >>> "attributes": ["id", "name", "userName", "password", "emails"] >>> >>> } >>> >>> } >>> >>> Does anyone in the working group have use cases for SETs that canno= t >>> be met by this proposed text? Within RISC, we identified three use >>> cases, with solutions outlined below: >>> >>> ** >>> >>> *Extensions* >>> >>> Event extension mechanisms can be defined internal to the event >>> object. A simple approach would be to define an =E2=80=9Cextension= s=E2=80=9D member >>> that is a list of event objects (or set resembling the =E2=80=9Ceve= nts=E2=80=9D >>> claim as defined in the current spec). This has the advantage of >>> making it clear in the data structure that there is a single primar= y >>> event, with zero or more extensions. There is no room for confusion >>> over which event is primary, or if there is a primary event at all. >>> I would be fine with adding something like this to my proposed text= , >>> if there is consensus that it is broadly useful. >>> >>> *Aliases* >>> >>> This use case was brought up in the context of migrating clients >>> from draft event names to standardized event names. In this case, >>> the event transmitter can transmit two tokens for the logical event= , >>> one using the old name and another using the new name. >>> >>> *Related Events* >>> >>> The SET spec defines the txn claim as a means of correlating >>> independent tokens that relate to the same logical event. >>> >>> -- >>> Annabelle Richard Backman >>> >>> Amazon =E2=80=93 Identity Services >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.i >>> etf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaW >>> HvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEiv >>> zjWwlNKe4C_lLIGk&m=3Ds5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSib >>> Ec&s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D >>> >>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >>> >>> >>> >>> -- >>> Subscribe to the HARDTWARE >>> >>> mail list to learn about projects I am working on! >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqP >>> kAI1aLcLN4KZNA&m=3DYBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw >>> &s=3DWrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=3D >>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqP >>> kAI1aLcLN4KZNA&m=3DU-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec >>> &s=3DrvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm46QSz0&e=3D >>> >>> >>> >>> >>> >>> >>> -- >>> Subscribe to the HARDTWARE >>> >>> mail list to learn about projects I am working on! >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqP >>> kAI1aLcLN4KZNA&m=3DiyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w >>> &s=3DOe0qfLEX83vtXM7Wl2cYBe-Gg1DVPjhXjVJkfhVRzwc&e=3D >>> >>> >>> >>> >>> -- >>> Subscribe to the HARDTWARE >>> >>> mail list to learn about projects I am working on! >>> >>> >>> >>> >>> -- >>> Subscribe to the HARDTWARE >>> >>> mail list to learn about projects I am working on! >>> >>> >>> >>> >>> -- >>> Subscribe to the HARDTWARE >>> >>> mail list to learn about projects I am working on! >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqP >>> kAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo >>> &s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=3D >>> >>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> > --f403045d9a14bd8cf4055cf2ec3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On W= ed, Nov 1, 2017 at 2:46 PM, William Denniss <wdenniss= @google.com> wrote:
    Perhaps I can try and explain the original intent of the current = design. The goal was always that a SET represents a single logical event. H= owever multiple systems may have different representations of the event =E2= =80=93 the example given originally was one formatted for RISC, and one for= SCIM.

    A good analogy is email. You send a single logica= l email, which may have two representations, HTML and plain text. Systems c= an consume the version that they understand and ignore the one they don'= ;t.

    Yes, and I think this is we= ll understood.

    =C2=A0

    I'm starting to regret the= plural in "events", it was pluralized due to it being an array, = not because it represented multiple logical events.

    I don't think this is the main concern or cause fo= r confusion.

    =C2=A0

    Annabelle, I understand your con= cerns regarding confusion of the semantics between the JSON syntax and the = specification language. Are there other ways to resolve that without removi= ng the ability for multiple representations of the same event?
    <= /blockquote>

    The argument is that multiple representatio= ns can be sent as distinct SETs, if really needed. In practice this will ha= ppen quite rare though. Events are created for a specific receiver, the rec= eiver either wants the SCIM or the RISC flavor, and they should be able to = specify that in configuration (there is a proposal how to capture that).

    Do we have a compelling use case where a receiver mu= st receive multiple variants all at once?

    =C2=A0

    On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
    On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt = <phil.hunt@oracle.com<= /a>> wrote:
    You can=E2=80=99t really have multiple events (at least of= the same type).=C2=A0 The current spec can only have one instance of a URI= (afaik). =C2=A0

    Note that the spec normatively does not= support multiple event SETS.=C2=A0 It currently states:
    events
      The semantics of this claim is to define a set of event statements
      that each MAY add additional claims to fully describe a single
      logical event that has occurred (e.g. a state change to a
      subject).  Multiple event statements of the same type SHALL NOT be
      accepted.  The "events" claim SHOULD NOT be used to express
      multiple logical events.

    The sp= ec has *always* supported requirements (as stated in the spec) for multiple= separate profile statements (from one or more profile familities) needing = to be sent as a single message.=C2=A0 It would be INSECURE to force multipl= e SETs because the current delivery mechanism only allows one SET to be del= ivered at a time. There is no way to assure that a single receiver gets all= of the SETs it needs in a multi-threaded, multi-node environment at scale.= =C2=A0 Assembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a common = state database is NOT simple nor cost effective.

    I totally agree that it is difficult for rece= ivers to receive separate events, in no particular order and correlate base= d on "txn". But, receivers have to solve this issue regardless of= "events" or "event", so it is unrelated to this propos= al.

    =C2=A0

    If we accomm= odate this in the proposed form, we end up with a complex, deeply nested JS= ON structure with the possibility of namespace conflicts.

    IMO The proposal does not simplify, it complicating and limiting. = =C2=A0

    The current spec has very clean JSON and av= oids namespace conflicts between profiles. I think we should stay on track = with the current draft and observe the normative text if not make it strong= er in regards to multi-events (understood that Mike may disagree).

    Phil


    Unless the profile gu= arantees that such related events will always be included in the same SET, = then the receiver has to correlate across SETs anyway, and multiple events = per SET is just giving the receiver another scenario that they have to supp= ort.
    =C2=A0
    I=E2= =80=99ve already provided several other reasons why we should not support m= ultiple tokens per SET that no one has addressed. Here they are again:
    1. Multiple event support results in a more= complex structure for the single event use case, which I think we all agre= e is the majority use case.
    2. Mult= iple-event SETs have ambiguous semantics. The presence of two events A and = B in the same SET could mean any of:
      1. A and= B are related to the same logical event (i.e. the same thing as if they we= re from different SETs that have a common txn).
      2. A is an extension of B.
      3. B is an extension of A.
      4. = A is an alias for B, or vice-versa.
      5. A and B are not actually related to one another in any way, and the tra= nsmitter bundled them together because they were going to the same receiver= .
    3. Top-level claim sema= ntics become harder to define, as different profiles may want to use the sa= me claims in different ways.
    4. Eve= nt authenticity cannot be verified without having the entire SET. This forc= es receivers to expose downstream systems to more information necessary, if= those systems need to be able to verify authenticity.
      5. =C2=A0
      --=C2=A0
      Annabelle Richard Backman
      Amazon =E2=80=93 Identity Services
      =C2=A0
      =C2=A0
      =
      From:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
      Date:=C2=A0Wednesday, November 1, 2017 at 11:21 = AM
      To:=C2=A0Dick Hardt <dick.hardt@gmail.com><= br>Cc:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>= ;, "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <= ;id-event@ietf.org>, = "Phil Hunt (IDM)" <phil.hunt@oracle.com>
      Subject:=C2=A0
      I completely agree on moving= complexity to the issuer over the recipient.=C2=A0 In my view, it=E2=80=99= s more complex for recipients to have to correlate and process a sequence o= f multiple SETs providing information about the same logical event, and val= idate N signatures, than to receive one SET with all the aspects of the log= ical event as =E2=80=9Cevents=E2=80=9D fields, with no correlation over tim= e then required.
      =C2=A0
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
      From:=C2=A0Dick Hardt [mailto:dick.hardt@gmail.com]=C2=A0Sent:=C2=A0Wednesday, November 1= , 2017 9:39 AM
      To:=C2=A0Mike Jo= nes <Michael.Jo= nes@microsoft.com>
      Cc:=C2=A0Yaron Sheffer <ya= ronf.ietf@gmail.com>; Richard Backman, Annabelle <richanna@amazon.com>; ID Events Ma= iling List <id-event@ietf= .org>; Phil Hunt (IDM) <phil.hunt@oracle.com>
      Subject:=C2=A0Re: [Id-event] Use cases for multiple events per SET?<= u>
      =C2=A0
      = Your comments highlight a couple of points:
      <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0
      1) The example is h= ow to have a predefined extension point for extensions of a specific event,= it is not how to add another event. Myself, I think this is overly complic= ated. Events should be comparatively static, and as with many other JSON fo= rmats, the receiver should ignore properties it does not understand, which = let's new properties be introduced as extensions. There should not be a= ny conflict as extensions should only be done by the profile that created t= he event format to start off with.
      = =C2=A0
      2) Having an lvalue be a URI= is much harder to code against. I'm not sure why Marius had that in hi= s example. Per the event, the type of the event is well defined with=C2=A0<= u>
      =C2=A0
      =
      =C2=A0
      3) This = thread is about reasons for multiple events to be contained in one set. You= r mention of an issuer not wanting to sign separate events as a reason to a= llow multiple events. I think we have decided that given a preference, we w= ill push effort to the transmitter over the receiver as in many use cases t= here are many more receivers. Given that, it is more complex for a receiver= to have different ways of managing the receipt of multiple events as not a= ll issuers will bundle the events, so it is simpler to have only one event = per SET. Including the separate events with a URI as an lvalue is challengi= ng to implement, speaking from experience.
      =C2=A0
      =C2=A0=
      =C2=A0
      = =C2=A0
      =C2=A0
      =C2=A0
      =C2= =A0
      =C2=A0
      =C2=A0
      =C2=A0
      =C2=A0
      On Tue, Oct 31, 2017 at 11:05 PM= , Mike Jones <Michael.Jones@microsoft.com= > wrote:
      Marius=E2=80=99 proposed syntax, p= asted in below, has exactly this characteristic.=C2=A0 The way I see it, hi= s proposal essentially has a primary passwordReset event and a secondary pa= sswordResetExt data structure, which could have been simply another event v= alue in the current draft.
      =C2=A0
      This breaking change makes the data structures m= ore complicated - not less.=C2=A0 And it makes things that used to be possi= ble impossible, reducing flexibility to those who would use the spec.
      =C2=A0
      These = seem like bad tradeoffs to me.
      =C2=A0
      {=
      =C2=A0 "jti": "3d0c3cf797584bd193= bd0fb1bd4e7d30",
      =C2=A0 "i= at": 1458496025,
      =C2=A0 "iss&quo= t;: "https://scim.example.com",<= u>
      =C2=A0 "aud": [
      =C2=A0 = =C2=A0],
      =C2=A0 =C2=A0"event_type&quo= t;: "https://example.com/s= cim/event/passwordResetExt",
      =C2=A0 =C2=A0"event": {=C2=A0=C2=A0
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"id":"44f6142df96bd6a= b61e7521d9",
      =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0"extensions": {
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"https://example.com/scim/event/passwordResetExt= =E2=80=9D: {
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0"resetAttempts":5,
      =
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
      }=
      =C2=A0=
      In particu= lar, it makes it impossible to sign multiple related events sharing a commo= n claims schema with a single signature by the issuer.=C2=A0 It forces the = issuer to do the extra work of signing each of the related events (or facet= s of the same logical event) individually and forces the recipients to do t= he extra work of checking all those unnecessary signatures.
      =C2=A0
      Not every profil= e will ever have multiple keys in the =E2=80=9Cevents=E2=80=9D set but ther= e=E2=80=99s absolutely no reason to preclude it.
      =
      =C2=A0
      =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 -- Mike
      =C2=A0<= /div>
      From:=C2=A0Id-event= [mailto:id-event-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Dick Hardt
      Sent:= =C2=A0Tuesday, October 31, 2017 9:52 PM
      To:=C2=A0Mike Jones <Mich= ael.Jones@microsoft.com>
      Cc:=C2= =A0Yaron Sheffer <yaronf.ietf@gmail.com= >; Richard Backman, Annabelle <richanna@am= azon.com>; ID Events Mailing List <id-event@= ietf.org>; Phil Hunt (IDM) <phil.hunt@ora= cle.com>

      Subject:<= span class=3D"m_-3151445958451029318m_7476346946956833004m_5683402937781561= 080Apple-converted-space">=C2=A0Re: [Id-event] Use cases for multipl= e events per SET?
      =C2=A0=
      Please direct me to a proposal that has = a "primary" and "secondary" events. I agree that is und= esirable. I would also encourage to engage in the discussions so that we ca= n drive clarity and simplicity.
      =C2=A0=
      I think the proposal is that there is= one event per SET.
      =C2=A0
      I think having more than one event per SET = adds complexity as a receiver must deal with receiving correlated events in= one SET as well as correlated events in the same SET.
      <= /div>
      =C2=A0
      /Dick=
      =C2=A0
      =
      On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
      I hear you on the fact that different people have joined the effort = at different times.=C2=A0 That=E2=80=99s a normal process as an effort buil= ds momentum.=C2=A0 I get that not everyone was there when previous consensu= s calls were taken.
      =C2=A0
      I should note that I have specific technical objections = to the specific proposed changes being discussed as well.=C2=A0 Currently a= ll events in the set have the same syntax.=C2=A0 The proposals, as I unders= tand them, revert us to a state where there=E2=80=99s a =E2=80=9Cprimary=E2= =80=9D and =E2=80=9Csecondary=E2=80=9D events, with different syntax for th= e two classes.=C2=A0 That=E2=80=99s needlessly more complicated, adding no = actual value.
      =C2=A0
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
      = =C2=A0
      From:=C2=A0Dick Hardt [mailto:<= a href=3D"mailto:dick.hardt@gmail.com" style=3D"color:purple;text-decoratio= n:underline" class=3D"m_-3151445958451029318m_7476346946956833004cremed cre= med" target=3D"_blank">dick.hardt@gmail.com]= =C2=A0
      Sent:=C2=A0Tuesda= y, October 31, 2017 9:37 PM
      To:=C2=A0<= /span>Mike Jones <Michael.Jones@microso= ft.com>
      Cc:=C2=A0Phil Hu= nt (IDM) <phil.hunt@oracle.com>; Yaron Sh= effer <yaronf.ietf@gmail.com>; Richard B= ackman, Annabelle <richanna@amazon.com>; I= D Events Mailing List <id-event@ietf.org>=

      Subject:=C2=A0Re: [Id-event] Use cases for multiple events per SET?<= u>
      =C2=A0
      Mike
      =C2=A0
      As you well know, many people in a WG don't= look closely at a specification until last call is made. Additionally, we = are coming up on only the 3rd WG meeting. The WG has not existed for very l= ong. While some of the participants have been working on this for a while, = many have not, and we are looking for consensus across the WG.
      =C2=A0
      = Since SecEvent is a framework that we expect to be profiled, I feel it is i= mportant to ensure that SecEvent specifications are easy for a variety of p= rofiles to adopt, and that the semantics make sense. I also think that prop= erties that are specific to a profile should be left to that profile and no= t be included in SecEvent.
      =C2=A0
      Since this is a framework, it is exp= ected that as different groups profile it, there will be additional feedbac= k.
      =C2=A0
      =
      Specifically, as a participant in the RISC profile of SET, a= number of issues in SET have surfaced as the RISC WG has looked at how to = use the SET.
      =C2=A0
      As for SET being stable for over a year, there hav= e been a number of changes to SET since then. I also don't think there = was consensus. Before the WG was formed, I and several others had expressed= concern on the design of SET when Phil presented it at an IIW session.<= /u>
      =C2=A0
      <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">As to taking another year, I am hopeful we can resolve the remaini= ng issues in SET and publish a new draft for last call. I do not think we w= ill need to wait for another WG meeting to ask for last call.=C2=A0<= u>
      =C2=A0
      We also have a number of other documents that are not in last call, an= d we don't have a WG adopted draft yet for management. So there are sti= ll a number of documents to work through before we have all the bits for so= meone to work with.
      =C2=A0
      I do think we have been making good progres= s since the last IETF meeting, and I am hopeful we can keep up this momentu= m and finalize all the documents in a timely manner.
      =C2=A0
      /Dick
      =C2=A0
      <= div>
      =C2=A0
      On Tue, Oct 31, 2017= at 12:48 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
      It=E2=80=99s hard for = me to even express my level of frustration with the recent attempts to once= again redesign the SecEvent Token spec.=C2=A0 We=E2=80=99ve been at this f= or multiple years because people keep trying to revisit decisions that were= long ago made by consensus.=C2=A0 It=E2=80=99s been stable for over a year= and the majority of WGLC respondents said some variant of =E2=80=9CWorks f= or me =E2=80=93 ship it!=E2=80=9D
      =C2=A0
      = There=E2=80=99s not sufficient justifica= tion to try to undo consensus positions that have been debated and affirmed= over and over.=C2=A0 Countenancing wholesale changes at this late date is = counterproductive in the extreme!
      =C2=A0
      = It=E2=80=99s far better than good enough= as-is.=C2=A0 In my experience, if we start redesigning it, it will result = in another year=E2=80=99s delay.=C2=A0 It does something simple and useful.= =C2=A0 Please, let=E2=80=99s just ship it, so people can rely on it.=
      =C2=A0
      =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
      From:=C2=A0Phil Hunt (= IDM) [mailto:phil.hunt@oracle.com]=C2=A0
      Sent:=C2= =A0Monday, October 30, 2017 2:42 PM
      To:=C2=A0Dick Hardt <dick.hardt@gmai= l.com>
      Cc:=C2=A0Yaron Sh= effer <yaronf.ietf@gmail.com>; Richard B= ackman, Annabelle <richanna@amazon.com>; M= ike Jones <Michael.Jones@microsoft.com>; ID Events Mailing List <id-event@ietf.org>
      Hi Phil
      =C2=A0
      Correct me if I am misunder= standing, but there is a RISC profile event=C2=A0
      = 
      =C2=A0
      "= http://schemas.openid.net/secevent/r= isc/event-type/account-credential-change-required=E2=80=9D
      =C2=A0
      <= div>
      and an SCIM profile event
      =C2=A0
      I'm suggesting that two different events would be sent. Embedding o= ne in the other does not make sense.
      <= /blockquote>
      <ph>It is a hypothetical example. Just because = you disagree on this does not mean others are not valid.=C2=A0
      =C2=A0
      I just= picked overlapping proposals that have different meaning (but not the same= ) to illustrate the difference from issuing a single set with different eve= nts.=C2=A0
      =C2=A0

      As I have stated this is very differen= t from asserting multiple distinct events in one SET.=C2=A0

      =C2=A0
      Also, I= think it is simpler to have event_type be at the same level as event
      =C2=A0

      <ph>may be. I was working fr= om Annabelle's proposed format.=C2=A0

      =C2=A0
      {
      =
      =C2=A0 &q= uot;jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",=
      =C2=A0 "iat": 1458496025,=
      =C2=A0 "aud": [<= /span>
      = =C2=A0 =C2=A0],
      =C2=A0 =C2=A0"event_type&= quot;: "https://example.co= m/scim/event/passwordResetExt",
      = =C2=A0 =C2=A0"event": {=C2=A0=C2=A0
      = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"id":"44f6142df96bd6ab61e7= 521d9",
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"resetAttempts":5
      =C2=A0 =C2=A0= =C2=A0 =C2=A0}
      }
      =C2=A0
      {
      =
      =C2=A0 "iat": 1458496025,=
      =C2=A0 "au= d": [
      =C2=A0 =C2=A0],
      =C2=A0 =C2=A0"event": {
      =
      =C2=A0 = =C2=A0 =C2=A0 =C2=A0=E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,=
      =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=9Ciss=E2=80= =9D:"https://idp.example.com/"=C2= =A0 =C2=A0 =C2=A0 =C2=A0
      =C2=A0 =C2=A0 =C2=A0 = =C2=A0}
      }
      =C2=A0
      =C2=A0
      =C2=A0
      =C2=A0
      =C2=A0
      On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt <<= a href=3D"mailto:phil.hunt@oracle.com" style=3D"color:purple;text-decoratio= n:underline" class=3D"m_-3151445958451029318m_7476346946956833004cremed cre= med" target=3D"_blank">phil.hunt@oracle.com> wrote:
      Annabelle/Dick,<= /u>
      =C2=A0
      =C2=A0<= u>
      As I stated, what causes most of the issue is t= he proposed extension mechanism in the payload (possibly using events in a = recursive way). Does it follow the old format or the new?
      =C2=A0
      Let=E2=80= =99s =C2=A0consider a use case where we have an identity management system = that uses SCIM, but the SCIM system is also the underlying data store for C= onnect.=C2=A0 A Password reset might generate the following event which has= an extension (conveying reset count) AND overlapping statement from RISC.= =C2=A0 BOTH of which might be important to a similar receiver using SCIM an= d OIDC. =C2=A0
      =C2=A0=
      The 03 spec currently would allow:=
      =C2=A0
      {
      =C2=A0 "jti&quo=
t;: "3d0c3cf797584bd193bd0fb1bd4e7d30",
      <= pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courie= r New',serif">=C2=A0 "iat": 1458496025,=C2=A0 "iss": "https:= //scim.example.com",
      =C2=A0 =
"aud": [
      =C2=A0=C2=A0=C2=A0=
 "https://jhub.ex=
ample.com/Feeds/98d52461fa5bbc879593b7754",
      =C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Feeds/5d7604516b1d086=
41d7676ee7"
      =C2=A0=C2=A0 ],<=
u>
      =C2=A0=C2=A0 "events": {=

      =C2=A0=C2=A0=C2=A0=C2=A0 "urn:ietf=
:params:scim:event:passwordReset":
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "id":"44f614=
2df96bd6ab61e7521d9"},
      =C2=
=A0=C2=A0=C2=A0=C2=A0 "htt=
ps://example.com/scim/event/passwordResetExt":<=
/pre>
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetA=
ttempts":5},
      =C2=A0=C2=A0=C2=A0=C2=A0 "http://schemas.openid.net/secevent/risc/event-type/\
      =C2=A0 =
=C2=A0 =C2=A0 =C2=A0account-credential-change-required": {      =

      =C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Csub=E2=80=9D:=E2=80=
=9D7375626A656374=E2=80=9D,
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/"<=
/u>
      =C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 }
      =C2=A0 }
      }
      =C2=A0
      In the above - each payload is a =E2=80=98peer&=
#39; and issued without preference by the transmitter. The receiver can ass=
ign priority in its own context if that matters.
      =

      =C2=A0
      The new proposal:<=
/span>
      =C2=A0
      {
      =C2=
=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",<=
/u>
      =C2=A0 "iat": 1458496025,
      =C2=A0 "iss": "https://scim.example.com",
      =C2=A0 "aud": [
      =
=C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754"=
;,
      =C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Feed=
s/5d7604516b1d08641d7676ee7"
      =C2=A0=C2=A0 ],
      =C2=A0=C2=A0 &q=
uot;event": {
      =C2=A0=C2=A0=C2=A0=
=C2=A0 =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:p=
asswordReset=E2=80=9D,
      =C2=A0=C2=A0=
=C2=A0=C2=A0 "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=
=9D,
      =C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=9Cevents=E2=80=9D:{
      =C2=A0=C2=A0=C2=
=A0=C2=A0 ->note =E2=80=A6is this the old or new structure? <-=

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=
https://example.com/scim/event/passwordResetExt":
      =C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAttempts":5=
},
      =C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "h=
ttp://schemas.openid.net/secevent/risc/event-type/\
      =C2=A0 =C2=
=A0 =C2=A0=C2=A0=C2=A0 =C2=A0account-credential-change-required":=
 {
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Csub=E2=80=9D:=
=E2=80=9D7375626A656374=E2=80=9D,
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/"
      =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
      =
=C2=A0=C2=A0=C2=A0=C2=A0 }<=
/u>
      =C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0 
      }
      =C2=A0
      In the above, sub-events or extensions have a different format. =
The same complaint about the original stands.
      =C2=A0
      *OR* (if the receiver cares about RIS=
C more).=C2=A0 Note that this leads to a triple nested structure.
      =C2=A0
      {
      =C2=A0 "jti": &=
quot;3d0c3cf797584bd193bd0fb1bd4e7d30",
      =C2=A0 "iat": 1458496025,
      =C2=A0 "iss": "https://sci=
m.example.com",
      =C2=A0 "=
;aud": [
      =C2=A0=C2=A0=C2=A0 &quo=
t;https://jhub.example=
.com/Feeds/98d52461fa5bbc879593b7754",
      =C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Feeds/5d7604516b1d08641d76=
76ee7"
      =C2=A0=C2=A0 ],
      =C2=A0=C2=A0 "event": {
      =C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=
=E2=80=9D:"http://schemas.openid.net/secevent/risc/event-type/\<=
/span>
      =
=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0account-cred=
ential-change-required=E2=80=9D,=

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A6=
56374=E2=80=9D,
      =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=E2=80=9Ciss=E2=80=9D:"=
https:/=
/idp.example.com/=E2=80=9C,
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=
=80=9Cevents=E2=80=9D:{
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "u=
rn:ietf:params:scim:event:passwordReset":
      =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 {=C2=A0
      =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "id":=E2=
=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ce=
vents=E2=80=9D:{
      =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://example.com/scim/event/passwordR=
esetExt":
      =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "=
resetAttempts":5},=C2=A0 
      =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 
      =C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0=C2=A0 =

      =C2=A0=C2=A0=C2=A0}=

      }
      =C2=A0<=
/pre>
      In the above, the extension is placed inside the event it extends.=
 It follows the old format (or should it follow the new?)<=
/u>
      *OR* Following the top layer pattern of singular event=C2=
=A0 Note that this leads to a triple nested structure.=

      =C2=A0
      {=

      =C2=A0 "jti": "3d0c3c=
f797584bd193bd0fb1bd4e7d30",
      =C2=A0 "iss": "https://scim.example.=
com",
      =C2=A0 "aud"=
: [
      =C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Feed=
s/98d52461fa5bbc879593b7754",
      =C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
      =C2=A0=C2=A0 ],
      =C2=A0=C2=A0 "event": {
      =C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=
=9D:"http://schemas.openid.net/secevent/risc/event-type/\=

      =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 =C2=A0account-credential-change-required=E2=80=9D,
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ciss=E2=80=9D:&q=
uot;https://id=
p.example.com/=E2=80=9C,
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9C=
event=E2=80=9D:{
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ceve=
nt_type=E2=80=9D:"urn:ietf:params:scim:event:passwordReset=E2=80=
=9D,
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "id":=E2=
=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent=E2=80=
=9D:{
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/event/passwordRe=
setExt=E2=80=9D,
      =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "resetAttempts":5 
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=
=A0=C2=A0 
      =C2=A0=C2=A0=C2=A0}
      }
      =
=C2=A0
      This format follows the proposed singular event format r=
ecursively and is 3 layers deep. Note that the parser has to continue to se=
arch the document for things that aren=E2=80=99t there as it has to stop wh=
en no =E2=80=9Cevent=E2=80=9D attribute is found rather than iterate over a=
n array.
      =C2=A0
      Phil

      Oracle Corporation, Identity Cl= oud Services Architect
      @independentid
      www.independentid.comphil.hunt@oracle.com
      =C2=A0
      On Oct 30, 201= 7, at 8:57 AM, Richard Backman, Annabelle <richan= na@amazon.com> wrote:
      =C2=A0
      Replies inline.
      =C2=A0=
      --=C2=A0<= u>
      Annabelle R= ichard Backman
      Identity Services
      =C2=A0
      =C2=A0
      From:=C2=A0<= /span>Phil Hunt <phil.hunt@oracle.com>
      Date:=C2=A0      Sunday, October 29= , 2017 at 5:25 PM
      To:=C2=A0<= /b>Dick Hardt <dick= .hardt@gmail.com>
      Cc:= =C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>, Mike Jones <Michael.Jones@microsof= t.com>, "Richard Backman, Annabelle" <richanna@amazon.com>= ;, ID Events Mailing List <id-event@ietf.org>
      Subject:=C2=A0Re: [Id-event] Use cases for multiple events pe= r SET?
      =C2=A0
      I hope this answers your question.
      =C2=A0
      My =E2=80=9Cmay= =E2=80=9D was because I can=E2=80=99t see a reason why not. The question sh= ould be, what is the justification to make =E2=80=9Cevents=E2=80=9D singula= r?
      [richanna]The singular =E2=80=9Cevent=E2=80=9D= claim has clearer semantics and is easier to process. We should opt for ea= sier solutions unless there are use cases that require more complexity.[/ri= channa]
      =C2=A0
      There are many reasons for multiple events in a SET.=C2= =A0 Some are good, some not so good. Some of the reasons...
      =C2=A0=
      1.=C2=A0 M= ultiple event payloads expressing statements about largely the *same*thing.= For example, SCIM password reset AND RISC password reset.=C2=A0 A RISC Eve= nt and an OpenBanking Event. Is one a complement to the other?=C2=A0 Do the= y overlap or are they distinct? =C2=A0
      [richanna]= Copy/pasted from my earlier email:
      Why is = it necessary or appropriate to include these events in the same SET? They a= re likely being generated by different systems at different times on the tr= ansmitter=E2=80=99s side, consumed by different systems on the receiver=E2= =80=99s side, and possibly being transmitted over different event streams. = I know the latter would be the case for us, as a receiver. Even if it=E2=80= =99s not, is it burdensome to send these events separately? What value is g= ained in combining them?
      =C2=A0<= /u>
      Additionally, since the signature is over the SET an= d not the event objects, Receivers independently route separate events from= a single token without either losing the ability to verify the authenticit= y of the event or sharing all information in the SET with every system hand= ling any event in the token.[/richanna]
      = =C2=A0

      2.=C2=A0 Multiple events payloads expressing differen= t statements about the same transaction - RISC Password Reset and RISC Sess= ion Cancel
      [richanna]Same as above= [/richanna]

      3.=C2=A0 A new profile defines new event attributes to be a= dded on to an existing event type (a pure extension)=C2=A0
      [richanna]I have suggested a way to support exte= nsions within an event body, multiple times now. If you see problems with i= t, please point them out.[/richanna]
      =
      =C2=A0
      =
      I think it is quite valid = to allow 1 and 3. =C2=A02 could be limited by specific profiles like RISC i= f they want.
      =C2=A0
      I am not in agreement that making event singular simplifi= es anything. For one is makes extensions complex (another nested JSON struc= ture) and potentially conflicting.=C2=A0
      [richanna]
      Ways that multiple-event= SETs are more complicated:
      1. It results in a more complex structure fo= r the single event use case, which I think we all agree is the majority use= case.
      2. Multiple-event SETs have ambiguous semantics. The presen= ce of two events A and B in the same SET could mean any of:
        1. They are related to the same logical e= vent (i.e. the same thing as if they were from different SETs that have a c= ommon txn).
        2. A is an extension of B.
        3. B is an extensi= on of A.
        4. They are aliases for one another.
          5. They are= not actually related to one another in any way.
        1. Claim semantics become h= arder to define, as different profiles may want to use the same claims in d= ifferent ways.
      =C2=A0
      If the WG wants to block 1 and 2 above, then I believe we= have to establish an event registry to ensure new Event profiles do not ov= erlap to eliminate the need to express multiple events.
      =
      [richanna]I=E2=80=99m not sure what you mean by this. Are= you referring to event names? Those are already defined by the spec to be = URIs.[/richanna]
      =
      =
      Phil
      <= div>
      =C2=A0
      <= /div>
      Oracle Corporation, Identit= y Cloud Services Architect
      @independentid
      <= /div>
      =
      =C2=A0
      On Oct 29, 2017, at 4:12 P= M, Dick Hardt <dick= .hardt@gmail.com> wrote:
      =
      =C2=A0
      =
      Phil:
      <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif;background-color:white">=C2=A0
      =
      In your examples for having a plurality of events, you= use the word "may", which leads me to question if a plurality of= events is really required in SET.
      =C2=A0
      <= div>
      You posit that it will be difficult for a dis= tributed system to correlate multiple SETs with the same "txn", b= ut the distributed system will certainly need to correlate events on the sa= me subject -- correlating events on the same "txn" on the same su= bject seems fairly simple.
      =
      =C2=A0
      I think that a receiver will need to correlate multip= le SEts on the same subject, so having multiple events in a SET is redundan= t, and adds complexity with no clear benefit that I can see.<= u>
      =C2=A0=
      An implementor may = choose to send multiple SETs, or send a single SET with multiple events, so= a receiver will need to support both. I prefer we pick one way and minimiz= e the code paths, and we will need to support correlating across multiple S= ETs, so that seems the best mechanism.
      =C2=A0
      Let me know if there is something I misse= d in my logic.
      =C2=A0
      /Dick
      =C2=A0
      =C2=A0
      On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer=C2=A0<yaronf.ietf@gmail.com>=C2=A0wrote:
      In that case, let's add = text to that effect, e.g. we could add to the definition of the "event= s" claim:

      Profiling specifications SHOULD define the allowed ev= ent statements, and MAY restrict their number. For example, some profiles m= ay require this claim to contain only a single event statement.

      Than= ks,
      =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0<= /span>Yaron

      On 24/10/17 22:10, Mike Jones wrote:

      I agre= e with much of Phil=E2=80=99s rationale here.

      It=E2=80=99s fine for = some profiles to say that the =E2=80=9Cevents=E2=80=9D set must be a single= ton.=C2=A0 That doesn=E2=80=99t have to be true for all events.=C2=A0 I thi= nk things are fine as-is.

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-- Mike

      *From:* Id-event [mailto:id-event-bounces@ietf.= org] *On Behalf Of *Phil Hunt
      *Sent:* Monday, October 23, 201= 7 8:47 PM
      *To:* Richard Backman, Annabelle <richanna@amazon.com      >
      *Cc:* ID E= vents Mailing List <id= -event@ietf.org>
      *Subject:* Re: [Id-event] Use cases for m= ultiple events per SET?

      Annabelle,

      I have a number of concern= s with this proposal.

      Profiling Independence / Keeping Event Payload= s Independent

      Indicating that extensions should be handled by profil= es leads to more inter-operability issues and more importantly intrudes on = the Event payload space by suggesting a sub-schema creates potential limita= tions and conflicts that may add to complexity later on. The current format= allows a parser to discover and unload one or more JSON payloads which can= each have independent structure.

      General extensions

      The prop= osal also rules out general purpose extensions not related to any specific = event. Given the emergence of items like GPRD, I would not want to block th= e ability to add meta-data or other general purpose items. We can also anti= cipate some delivery scenarios where additional data might be required. Eve= n though there is no current planned use, I see no good reason to rule this= out.

      Multiple Events From Different Families (vs. Multiple Events f= rom a single family like RISC)

      In our RISC session we discussed expr= essing multiple distinct RISC events in one SET. The discussion was that on= ly one RISC event at a time. We did not discuss other event profiles. I don= =E2=80=99t see a reason to rule out multi-events from different families at= the SET level. Each profile is expressing slightly different things about = the same event.

      I can forsee some cases where it is not clear which = is the primary and which is the extension.=C2=A0 There may not be a clear w= inner.

      A couple of examples (these are necessarily real=E2=80=A6just= possibilities):

      * It is probably useful to be able to express simla= r/overlapping events from different SET profiles in one SET.=C2=A0 For exam= ple a Backchannel Logout & a RISC session cancel event.

      * SCIM m= ay want to represent a single transaction as causing multiple state changes= in an event (e.g. a password change causes multiple effects). Having to ch= ase down multiple events and correlate by =E2=80=9Ctxn=E2=80=9D would be ch= allenging in a multi-threaded/multi-node delivery system.=C2=A0 =C2=A0The S= CIM list has not discussed this, but I would not want to block this capabil= ity.=C2=A0 IOW - Just because RISC does not want to express multiple events= does not make this true for other profiles.

      * We may wish to indica= te a SCIM Password Reset was performed and a Logout/session cancellation is= expressed at the same time.=C2=A0 The events are related but express diffe= rent data.

      Avoiding Confusion From Similar Events Originating from t= he Same Transaction

      If events are sent separately, then more trackin= g of state (e.g. by txn) would be required to ensure similar events are not= mistaken or handled as repeats. While txn provides useful audit analysis c= apability, I=E2=80=99m not sure it can be used in live or near-real time sy= stems given distributed multi-node, multi-threading architectures.

      P= revious Discussion

      I note that I originally raised having an attribu= te to designate primary event attribute to alleviate your concern, but this= was not accepted. See:

      *=C2=A0https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html

      *=C2=A0https://www.ietf.org/mail-archive/web/id-event/current/msg00= 140.html

      The consensus, at least as I interpreted it is u= p to the receiver to figure this out based on the definitions it has for ea= ch event URI and the profiles they represent. IOW - RISC is free to limit t= hat only one RISC event be expressed at a time.

      Phil

      Oracle C= orporation, Identity Cloud Services Architect

      @independentid

      = www.independentid.com=C2=A0<http://www.independentid.com>

      phil.hunt@oracle.com=C2=A0<mailto:phil.hunt@oracle.com      >

      = =C2=A0 =C2=A0 On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle
      = =C2=A0 =C2=A0 <richa= nna@amazon.com=C2=A0<= ;mailto:richanna@a= mazon.com>> wrote:

      =C2=A0 =C2=A0 The current draft = of the SET spec allows for expressing multiple
      =C2=A0 =C2=A0 events with= in the same token, which introduces additional complexity
      =C2=A0 =C2=A0 = and room for ambiguous semantics. We=E2=80=99ve discussed this in the OIDF<= br>=C2=A0 =C2=A0 RISC working group and the current consensus there is that= RISC will
      =C2=A0 =C2=A0 require that RISC events must be the only event= in the SET, having
      =C2=A0 =C2=A0 identified ways to clearly and easily = support the handful of use
      =C2=A0 =C2=A0 cases for multiple events per t= oken that people have raised. With
      =C2=A0 =C2=A0 that context in mind, I= propose striking the definition of the
      =C2=A0 =C2=A0 =E2=80=9Cevents=E2= =80=9D claim from the Security Event Token spec, and replacing it
      =C2=A0= =C2=A0 with the following definition for an =E2=80=9Cevent=E2=80=9D claim = (singular):

      =C2=A0 =C2=A0 event

      =C2=A0 =C2=A0 A JSON object c= ontaining an "event_type" member whose value is a URI
      =C2=A0 = =C2=A0 representing a type of event defined in a Profiling Specification.=C2=A0 =C2=A0 The object MAY otherwise be empty, or MAY contain additiona= l members
      =C2=A0 =C2=A0 as described by the Profiling Specification.
      =
      =C2=A0 =C2=A0 Here is the example SET from section 2.3, rewritten with = this change
      =C2=A0 =C2=A0 mind:

      =C2=A0 =C2=A0=C2=A0{

      =C2=A0 =C2=A0 =C2=A0=C2=A0 "jti&qu= ot;: "4d3559ec67504aaba65d40b0363faad8",

      =C2=A0 =C2= =A0 =C2=A0=C2=A0 "iat": 1458496404,

      =C2=A0 =C2=A0 =C2=A0= =C2=A0"iss": "https://scim.example.com= =C2=A0<https://scim.example.com/>",

      =C2=A0 =C2=A0 =C2=A0= =C2=A0 "aud": [

      =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0&qu= ot;https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",

      =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0"https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"

      =C2=A0 =C2=A0 =C2=A0=C2=A0 ],

      =C2=A0 =C2=A0 =C2=A0=C2= =A0 "event": {

      =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 &quo= t;event_type": "urn:ietf:params:scim:event:create",
      =
      =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 "ref": "      = https://scim.example.com/Users/44f6142df96bd6ab61e7521d9&qu= ot;,

      =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 "attributes": = ["id", "name", "userName", "password&quo= t;, "emails"]

      =C2=A0 =C2=A0 =C2=A0=C2=A0 }

      =C2=A0 = =C2=A0 }

      =C2=A0 =C2=A0 Does anyone in the working group have use cas= es for SETs that cannot
      =C2=A0 =C2=A0 be met by this proposed text? With= in RISC, we identified three use
      =C2=A0 =C2=A0 cases, with solutions out= lined below:

      =C2=A0 =C2=A0 **

      =C2=A0 =C2=A0 *Extensions*
      <= br>=C2=A0 =C2=A0 Event extension mechanisms can be defined internal to the = event
      =C2=A0 =C2=A0 object. A simple approach would be to =C2=A0define a= n =E2=80=9Cextensions=E2=80=9D member
      =C2=A0 =C2=A0 that is a list of ev= ent objects (or set resembling the =E2=80=9Cevents=E2=80=9D
      =C2=A0 =C2= =A0 claim as defined in the current spec). This has the advantage of
      =C2= =A0 =C2=A0 making it clear in the data structure that there is a single pri= mary
      =C2=A0 =C2=A0 event, with zero or more extensions. There is no room= for confusion
      =C2=A0 =C2=A0 over which event is primary, or if there is= a primary event at all.
      =C2=A0 =C2=A0 I would be fine with adding somet= hing like this to my proposed text,
      =C2=A0 =C2=A0 if there is consensus = that it is broadly useful.

      =C2=A0 =C2=A0 *Aliases*

      =C2=A0 =C2= =A0 This use case was brought up in the context of migrating clients
      =C2= =A0 =C2=A0 from draft event names to standardized event names. In this case= ,
      =C2=A0 =C2=A0 the event transmitter can transmit two tokens for the lo= gical event,
      =C2=A0 =C2=A0 one using the old name and another using the = new name.

      =C2=A0 =C2=A0 *Related Events*

      =C2=A0 =C2=A0 The SE= T spec defines the txn claim as a means of correlating
      =C2=A0 =C2=A0 ind= ependent tokens that relate to the same logical event.

      =C2=A0 =C2=A0= --=C2=A0
      =C2=A0 =C2=A0 Annabel= le Richard Backman

      =C2=A0 =C2=A0 Amazon =E2=80=93 Identity Services<= br>
      =C2=A0 =C2=A0 _______________________________________________=C2=A0 =C2=A0 Id-event mailing list
      =C2=A0 =C2=A0=C2=A0Id-event@ietf.org=C2=A0<mailto:Id-event= @ietf.org>
      =C2=A0 =C2=A0= =C2=A0https://u= rldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8= PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlN= Ke4C_lLIGk&m=3Ds5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&am= p;s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D<= br>


      _______________________________________________
      Id-e= vent mailing list
      Id-e= vent@ietf.org
      https://www.ietf.org/mailman/listinfo/id-event


      ____________= ___________________________________
      Id-event mailing list
      Id-event@ietf.orghttps://www.ietf.org/= mailman/listinfo/id-event
      <= /blockquote>


      =C2=A0=
      --=C2=A0
      <= div>
      Subscribe to the=C2=A0HARDTWARE<= span class=3D"m_-3151445958451029318m_7476346946956833004m_5683402937781561= 080m-4377787755873208935m-5013854861410265301m6958776980246660703m402623645= 6080349644apple-converted-space">=C2=A0mail list to learn about proj= ects I am working on!
      =C2=A0
      _________= ______________________________________
      Id-event mailing list
      Id-event@ietf.org
      =C2=A0


      =C2=A0
      --
      <= div>
      Subscribe to theHARDTWARE=C2=A0mail list = to learn about projects I am working on!


      =C2=A0=
      --
      Subscribe to the=C2=A0HARDT= WARE=C2=A0mail list to learn about pr= ojects I am working on!


    =C2=A0
    --
    Subscribe to the=C2=A0HARDTWARE=C2=A0m= ail list to learn about projects I am working on!
    =
    <= /blockquote>


    =
    =C2=A0
    --=C2=A0
    <= div>
    Subscribe to the=C2=A0= HAR= DTWARE=C2=A0mail list to learn about = projects I am working on!
    =
    _______________________________________________
    Id-event mailing li= st
    Id-event@ietf.org
    https://urldefense.proofpoint.com/v2/url?= u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDw= ICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D= na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZ= ktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=3D


    ________________= _______________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event



    _______________________________________________
    Id-event mailing list
    Id-= event@ietf.org
    https://www.ietf.org/mailman/lis= tinfo/id-event



    --f403045d9a14bd8cf4055cf2ec3d-- From nobody Wed Nov 1 14:59:59 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4420513F6B3 for ; Wed, 1 Nov 2017 14:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.997 X-Spam-Level: X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JXA1DD1Z57H for ; Wed, 1 Nov 2017 14:59:51 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 EE2D813F6A5 for ; Wed, 1 Nov 2017 14:59:50 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA1LxiEH029484 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Nov 2017 21:59:45 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA1Lxhut004257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Nov 2017 21:59:44 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vA1LxgCv003483; Wed, 1 Nov 2017 21:59:43 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 14:59:41 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-F443FA6E-E82E-4E66-8B42-43E3B96CCD6A Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 1 Nov 2017 14:59:38 -0700 Cc: Marius Scurtescu , "Richard Backman, Annabelle" , Yaron Sheffer , Mike Jones , ID Events Mailing List Content-Transfer-Encoding: 7bit Message-Id: <15E366B3-66E9-408B-9C9D-C7C78E11752D@oracle.com> References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> To: Dick Hardt X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 21:59:57 -0000 --Apple-Mail-F443FA6E-E82E-4E66-8B42-43E3B96CCD6A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think that is a red herring.=20 The issue is a multipayload message may be needed (for many reasons already d= iscussed) to convey one logical event.=20 An event from more than one txn are separate and distinct.=20 There may be cumulative conclusions but that is not in scope. =20 Breaking a single logical event across multiple sets is a different thing. I= t requires multi part signaling for the receiver to know they have the compl= ete message. More complexity in both delivery and set.=20 None of this is needed.=20 Phil > On Nov 1, 2017, at 2:45 PM, Dick Hardt wrote: >=20 > Per my earlier message, a receiver will often be receiving events from mul= tiple transmitters for the same subject. The receiver will already need a me= chanism to correlate events on the same subject, A transmitter may have diff= erent services issuing SETs that are tied to the same event, and have the sa= me transaction, but are transmitted separately. >=20 > Will this not be the case? Given this, a receiver MUST be doing correlatio= n across SETs.=20 >=20 >> On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu w= rote: >>> On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt wrote:= >>> You can=E2=80=99t really have multiple events (at least of the same type= ). The current spec can only have one instance of a URI (afaik). =20 >>>=20 >>> Note that the spec normatively does not support multiple event SETS. It= currently states: >>>> events >>>> The semantics of this claim is to define a set of event statement= s >>>> that each MAY add additional claims to fully describe a single >>>> logical event that has occurred (e.g. a state change to a >>>> subject). Multiple event statements of the same type SHALL NOT b= e >>>> accepted. The "events" claim SHOULD NOT be used to express >>>> multiple logical events. >>>=20 >>> The spec has *always* supported requirements (as stated in the spec) for= multiple separate profile statements (from one or more profile familities) n= eeding to be sent as a single message. It would be INSECURE to force multip= le SETs because the current delivery mechanism only allows one SET to be del= ivered at a time. There is no way to assure that a single receiver gets all o= f the SETs it needs in a multi-threaded, multi-node environment at scale. A= ssembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a common state dat= abase is NOT simple nor cost effective. >>=20 >> I totally agree that it is difficult for receivers to receive separate ev= ents, in no particular order and correlate based on "txn". But, receivers ha= ve to solve this issue regardless of "events" or "event", so it is unrelated= to this proposal. >>=20 >> =20 >>>=20 >>> If we accommodate this in the proposed form, we end up with a complex, d= eeply nested JSON structure with the possibility of namespace conflicts. >>>=20 >>> IMO The proposal does not simplify, it complicating and limiting. =20 >>>=20 >>> The current spec has very clean JSON and avoids namespace conflicts betw= een profiles. I think we should stay on track with the current draft and obs= erve the normative text if not make it stronger in regards to multi-events (= understood that Mike may disagree). >>>=20 >>> Phil >>>=20 >>> Oracle Corporation, Identity Cloud Services Architect >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>> On Nov 1, 2017, at 12:18 PM, Richard Backman, Annabelle wrote: >>>>=20 >>>> Unless the profile guarantees that such related events will always be i= ncluded in the same SET, then the receiver has to correlate across SETs anyw= ay, and multiple events per SET is just giving the receiver another scenario= that they have to support. >>>> =20 >>>> I=E2=80=99ve already provided several other reasons why we should not s= upport multiple tokens per SET that no one has addressed. Here they are agai= n: >>>> Multiple event support results in a more complex structure for the sing= le event use case, which I think we all agree is the majority use case. >>>> Multiple-event SETs have ambiguous semantics. The presence of two event= s A and B in the same SET could mean any of: >>>> A and B are related to the same logical event (i.e. the same thing as i= f they were from different SETs that have a common txn). >>>> A is an extension of B. >>>> B is an extension of A. >>>> A is an alias for B, or vice-versa. >>>> A and B are not actually related to one another in any way, and the tra= nsmitter bundled them together because they were going to the same receiver.= >>>> Top-level claim semantics become harder to define, as different profile= s may want to use the same claims in different ways. >>>> Event authenticity cannot be verified without having the entire SET. Th= is forces receivers to expose downstream systems to more information necessa= ry, if those systems need to be able to verify authenticity. >>>> =20 >>>> --=20 >>>> Annabelle Richard Backman >>>> Amazon =E2=80=93 Identity Services >>>> =20 >>>> =20 >>>> From: Mike Jones >>>> Date: Wednesday, November 1, 2017 at 11:21 AM >>>> To: Dick Hardt >>>> Cc: Yaron Sheffer , "Richard Backman, Annabelle"= , ID Events Mailing List , "Phil Hu= nt (IDM)" >>>> Subject: RE: [Id-event] Use cases for multiple events per SET? >>>> =20 >>>> I completely agree on moving complexity to the issuer over the recipien= t. In my view, it=E2=80=99s more complex for recipients to have to correlat= e and process a sequence of multiple SETs providing information about the sa= me logical event, and validate N signatures, than to receive one SET with al= l the aspects of the logical event as =E2=80=9Cevents=E2=80=9D fields, with n= o correlation over time then required. >>>> =20 >>>> -- Mike >>>> =20 >>>> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >>>> Sent: Wednesday, November 1, 2017 9:39 AM >>>> To: Mike Jones >>>> Cc: Yaron Sheffer ; Richard Backman, Annabelle <= richanna@amazon.com>; ID Events Mailing List ; Phil Hunt (= IDM) >>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>> =20 >>>> Your comments highlight a couple of points: >>>> =20 >>>> 1) The example is how to have a predefined extension point for extensio= ns of a specific event, it is not how to add another event. Myself, I think t= his is overly complicated. Events should be comparatively static, and as wit= h many other JSON formats, the receiver should ignore properties it does not= understand, which let's new properties be introduced as extensions. There s= hould not be any conflict as extensions should only be done by the profile t= hat created the event format to start off with. >>>> =20 >>>> 2) Having an lvalue be a URI is much harder to code against. I'm not su= re why Marius had that in his example. Per the event, the type of the event i= s well defined with=20 >>>> =20 >>>> "event_type": "https://example.com/scim/event/passwordResetExt", >>>> =20 >>>> 3) This thread is about reasons for multiple events to be contained in o= ne set. Your mention of an issuer not wanting to sign separate events as a r= eason to allow multiple events. I think we have decided that given a prefere= nce, we will push effort to the transmitter over the receiver as in many use= cases there are many more receivers. Given that, it is more complex for a r= eceiver to have different ways of managing the receipt of multiple events as= not all issuers will bundle the events, so it is simpler to have only one e= vent per SET. Including the separate events with a URI as an lvalue is chall= enging to implement, speaking from experience. >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>>> On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones wrote: >>>>> Marius=E2=80=99 proposed syntax, pasted in below, has exactly this cha= racteristic. The way I see it, his proposal essentially has a primary passw= ordReset event and a secondary passwordResetExt data structure, which could h= ave been simply another event value in the current draft. >>>>> =20 >>>>> This breaking change makes the data structures more complicated - not l= ess. And it makes things that used to be possible impossible, reducing flex= ibility to those who would use the spec. >>>>> =20 >>>>> These seem like bad tradeoffs to me. >>>>> =20 >>>>> { >>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>> "iat": 1458496025, >>>>> "iss": "https://scim.example.com", >>>>> "aud": [ >>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>> ], >>>>> "event_type": "https://example.com/scim/event/passwordResetExt", >>>>> "event": { =20 >>>>> "id":"44f6142df96bd6ab61e7521d9", >>>>> "extensions": { >>>>> "https://example.com/scim/event/passwordResetExt=E2=80=9D: {= >>>>> "resetAttempts":5, >>>>> } >>>>> } >>>>> } >>>>> } >>>>> =20 >>>>> In particular, it makes it impossible to sign multiple related events s= haring a common claims schema with a single signature by the issuer. It for= ces the issuer to do the extra work of signing each of the related events (o= r facets of the same logical event) individually and forces the recipients t= o do the extra work of checking all those unnecessary signatures. >>>>> =20 >>>>> Not every profile will ever have multiple keys in the =E2=80=9Cevents=E2= =80=9D set but there=E2=80=99s absolutely no reason to preclude it. >>>>> =20 >>>>> -- Mike >>>>> =20 >>>>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Dick Ha= rdt >>>>> Sent: Tuesday, October 31, 2017 9:52 PM >>>>> To: Mike Jones >>>>> Cc: Yaron Sheffer ; Richard Backman, Annabelle <= richanna@amazon.com>; ID Events Mailing List ; Phil Hunt (= IDM) >>>>>=20 >>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>> =20 >>>>> Please direct me to a proposal that has a "primary" and "secondary" ev= ents. I agree that is undesirable. I would also encourage to engage in the d= iscussions so that we can drive clarity and simplicity. >>>>> =20 >>>>> I think the proposal is that there is one event per SET. >>>>> =20 >>>>> I think having more than one event per SET adds complexity as a receiv= er must deal with receiving correlated events in one SET as well as correlat= ed events in the same SET. >>>>> =20 >>>>> /Dick >>>>> =20 >>>>>> On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones wrote: >>>>>> I hear you on the fact that different people have joined the effort a= t different times. That=E2=80=99s a normal process as an effort builds mome= ntum. I get that not everyone was there when previous consensus calls were t= aken. >>>>>> =20 >>>>>> I should note that I have specific technical objections to the specif= ic proposed changes being discussed as well. Currently all events in the se= t have the same syntax. The proposals, as I understand them, revert us to a= state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and =E2=80=9Csecond= ary=E2=80=9D events, with different syntax for the two classes. That=E2=80=99= s needlessly more complicated, adding no actual value. >>>>>> =20 >>>>>> -- Mi= ke >>>>>> =20 >>>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >>>>>> Sent: Tuesday, October 31, 2017 9:37 PM >>>>>> To: Mike Jones >>>>>> Cc: Phil Hunt (IDM) ; Yaron Sheffer ; Richard Backman, Annabelle ; ID Events Ma= iling List >>>>>>=20 >>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>> =20 >>>>>> Mike >>>>>> =20 >>>>>> As you well know, many people in a WG don't look closely at a specifi= cation until last call is made. Additionally, we are coming up on only the 3= rd WG meeting. The WG has not existed for very long. While some of the parti= cipants have been working on this for a while, many have not, and we are loo= king for consensus across the WG. >>>>>> =20 >>>>>> Since SecEvent is a framework that we expect to be profiled, I feel i= t is important to ensure that SecEvent specifications are easy for a variety= of profiles to adopt, and that the semantics make sense. I also think that p= roperties that are specific to a profile should be left to that profile and n= ot be included in SecEvent. >>>>>> =20 >>>>>> Since this is a framework, it is expected that as different groups pr= ofile it, there will be additional feedback. >>>>>> =20 >>>>>> Specifically, as a participant in the RISC profile of SET, a number o= f issues in SET have surfaced as the RISC WG has looked at how to use the SE= T. >>>>>> =20 >>>>>> As for SET being stable for over a year, there have been a number of c= hanges to SET since then. I also don't think there was consensus. Before the= WG was formed, I and several others had expressed concern on the design of S= ET when Phil presented it at an IIW session. >>>>>> =20 >>>>>> As to taking another year, I am hopeful we can resolve the remaining i= ssues in SET and publish a new draft for last call. I do not think we will n= eed to wait for another WG meeting to ask for last call.=20 >>>>>> =20 >>>>>> We also have a number of other documents that are not in last call, a= nd we don't have a WG adopted draft yet for management. So there are still a= number of documents to work through before we have all the bits for someone= to work with. >>>>>> =20 >>>>>> I do think we have been making good progress since the last IETF meet= ing, and I am hopeful we can keep up this momentum and finalize all the docu= ments in a timely manner. >>>>>> =20 >>>>>> /Dick >>>>>> =20 >>>>>> =20 >>>>>>> On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones wrote: >>>>>>> It=E2=80=99s hard for me to even express my level of frustration wit= h the recent attempts to once again redesign the SecEvent Token spec. We=E2= =80=99ve been at this for multiple years because people keep trying to revis= it decisions that were long ago made by consensus. It=E2=80=99s been stable= for over a year and the majority of WGLC respondents said some variant of =E2= =80=9CWorks for me =E2=80=93 ship it!=E2=80=9D >>>>>>> =20 >>>>>>> There=E2=80=99s not sufficient justification to try to undo consensu= s positions that have been debated and affirmed over and over. Countenancin= g wholesale changes at this late date is counterproductive in the extreme! >>>>>>> =20 >>>>>>> It=E2=80=99s far better than good enough as-is. In my experience, i= f we start redesigning it, it will result in another year=E2=80=99s delay. I= t does something simple and useful. Please, let=E2=80=99s just ship it, so p= eople can rely on it. >>>>>>> =20 >>>>>>> -- Mike >>>>>>> =20 >>>>>>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20 >>>>>>> Sent: Monday, October 30, 2017 2:42 PM >>>>>>> To: Dick Hardt >>>>>>> Cc: Yaron Sheffer ; Richard Backman, Annabell= e ; Mike Jones ; ID Events= Mailing List >>>>>>>=20 >>>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>>> =20 >>>>>>> Inline... >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Oct 30, 2017, at 2:22 PM, Dick Hardt wrot= e: >>>>>>>> Hi Phil >>>>>>>> =20 >>>>>>>> Correct me if I am misunderstanding, but there is a RISC profile ev= ent=20 >>>>>>>> =20 >>>>>>>> "http://schemas.openid.net/secevent/risc/event-type/account-credent= ial-change-required=E2=80=9D >>>>>>>> =20 >>>>>>>> and an SCIM profile event >>>>>>>> =20 >>>>>>>> "https://example.com/scim/event/passwordResetExt=E2=80=9D >>>>>>>> =20 >>>>>>>> I'm suggesting that two different events would be sent. Embedding o= ne in the other does not make sense. >>>>>>> It is a hypothetical example. Just because you disagree on this d= oes not mean others are not valid.=20 >>>>>>> =20 >>>>>>> I just picked overlapping proposals that have different meaning (but= not the same) to illustrate the difference from issuing a single set with d= ifferent events.=20 >>>>>>> =20 >>>>>>> As I have stated this is very different from asserting multiple dist= inct events in one SET.=20 >>>>>>>=20 >>>>>>>> =20 >>>>>>>> Also, I think it is simpler to have event_type be at the same level= as event >>>>>>> =20 >>>>>>> may be. I was working from Annabelle's proposed format.=20 >>>>>>>=20 >>>>>>>> =20 >>>>>>>> { >>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>> "iat": 1458496025, >>>>>>>> "iss": "https://scim.example.com", >>>>>>>> "aud": [ >>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>> ], >>>>>>>> "event_type": "https://example.com/scim/event/passwordResetExt",= >>>>>>>> "event": { =20 >>>>>>>> "id":"44f6142df96bd6ab61e7521d9", >>>>>>>> "resetAttempts":5 >>>>>>>> } >>>>>>>> } >>>>>>>> =20 >>>>>>>> { >>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>> "iat": 1458496025, >>>>>>>> "iss": "https://scim.example.com", >>>>>>>> "aud": [ >>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>> ], >>>>>>>> "event_type": "http://schemas.openid.net/secevent/risc/event-typ= e/account-credential-change-required", >>>>>>>> "event": { >>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" =20 >>>>>>>> } >>>>>>>> } >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>>> On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt = wrote: >>>>>>>>> Annabelle/Dick, >>>>>>>>> =20 >>>>>>>>> Thanks for the comments. I think we need to examine the consequenc= es of the proposal in JSON. >>>>>>>>> =20 >>>>>>>>> As I stated, what causes most of the issue is the proposed extensi= on mechanism in the payload (possibly using events in a recursive way). Does= it follow the old format or the new? >>>>>>>>> =20 >>>>>>>>> Let=E2=80=99s consider a use case where we have an identity manag= ement system that uses SCIM, but the SCIM system is also the underlying data= store for Connect. A Password reset might generate the following event whi= ch has an extension (conveying reset count) AND overlapping statement from R= ISC. BOTH of which might be important to a similar receiver using SCIM and O= IDC. =20 >>>>>>>>> =20 >>>>>>>>> The 03 spec currently would allow: >>>>>>>>> =20 >>>>>>>>> { >>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>> "iat": 1458496025, >>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>> "aud": [ >>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>> ], >>>>>>>>> "events": { >>>>>>>>> "urn:ietf:params:scim:event:passwordReset": >>>>>>>>> { "id":"44f6142df96bd6ab61e7521d9"}, >>>>>>>>> "https://example.com/scim/event/passwordResetExt": >>>>>>>>> { "resetAttempts":5}, >>>>>>>>> "http://schemas.openid.net/secevent/risc/event-type/\ >>>>>>>>> account-credential-change-required": { >>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> =20 >>>>>>>>> In the above - each payload is a =E2=80=98peer' and issued without= preference by the transmitter. The receiver can assign priority in its own c= ontext if that matters. >>>>>>>>> =20 >>>>>>>>> The new proposal: >>>>>>>>> =20 >>>>>>>>> { >>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>> "iat": 1458496025, >>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>> "aud": [ >>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>> ], >>>>>>>>> "event": { >>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:pass= wordReset=E2=80=9D, >>>>>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>>>>> ->note =E2=80=A6is this the old or new structure? <- >>>>>>>>> "https://example.com/scim/event/passwordResetExt": >>>>>>>>> { "resetAttempts":5}, >>>>>>>>> "http://schemas.openid.net/secevent/risc/event-type/\ >>>>>>>>> account-credential-change-required": { >>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } =20 >>>>>>>>> } >>>>>>>>> =20 >>>>>>>>> In the above, sub-events or extensions have a different format. Th= e same complaint about the original stands. >>>>>>>>> =20 >>>>>>>>> *OR* (if the receiver cares about RISC more). Note that this lead= s to a triple nested structure. >>>>>>>>> =20 >>>>>>>>> { >>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>> "iat": 1458496025, >>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>> "aud": [ >>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>> ], >>>>>>>>> "event": { >>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secev= ent/risc/event-type/\ >>>>>>>>> account-credential-change-required=E2=80=9D, >>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >>>>>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>>>>> "urn:ietf:params:scim:event:passwordReset": >>>>>>>>> {=20 >>>>>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>>>>> "https://example.com/scim/event/passwordResetExt": >>>>>>>>> { "resetAttempts":5}, =20 >>>>>>>>> } =20 >>>>>>>>> } >>>>>>>>> } =20 >>>>>>>>> } >>>>>>>>> } >>>>>>>>> =20 >>>>>>>>> In the above, the extension is placed inside the event it extends.= It follows the old format (or should it follow the new?) >>>>>>>>> *OR* Following the top layer pattern of singular event Note that t= his leads to a triple nested structure. >>>>>>>>> =20 >>>>>>>>> { >>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>> "iat": 1458496025, >>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>> "aud": [ >>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>> ], >>>>>>>>> "event": { >>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secev= ent/risc/event-type/\ >>>>>>>>> account-credential-change-required=E2=80=9D, >>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >>>>>>>>> =E2=80=9Cevent=E2=80=9D:{ >>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:p= asswordReset=E2=80=9D, >>>>>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>>>>> =E2=80=9Cevent=E2=80=9D:{ >>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/e= vent/passwordResetExt=E2=80=9D, >>>>>>>>> "resetAttempts":5=20 >>>>>>>>> } >>>>>>>>> } =20 >>>>>>>>> } >>>>>>>>> } >>>>>>>>> =20 >>>>>>>>> This format follows the proposed singular event format recursively= and is 3 layers deep. Note that the parser has to continue to search the do= cument for things that aren=E2=80=99t there as it has to stop when no =E2=80= =9Cevent=E2=80=9D attribute is found rather than iterate over an array. >>>>>>>>> =20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>>>> @independentid >>>>>>>>> www.independentid.com >>>>>>>>> phil.hunt@oracle.com >>>>>>>>> =20 >>>>>>>>>> On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle wrote: >>>>>>>>>> =20 >>>>>>>>>> Replies inline. >>>>>>>>>> =20 >>>>>>>>>> --=20 >>>>>>>>>> Annabelle Richard Backman >>>>>>>>>> Identity Services >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> From: Phil Hunt >>>>>>>>>> Date: Sunday, October 29, 2017 at 5:25 PM >>>>>>>>>> To: Dick Hardt >>>>>>>>>> Cc: Yaron Sheffer , Mike Jones , "Richard Backman, Annabelle" , ID E= vents Mailing List >>>>>>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>>>>>> =20 >>>>>>>>>> I hope this answers your question. >>>>>>>>>> =20 >>>>>>>>>> My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reason= why not. The question should be, what is the justification to make =E2=80=9C= events=E2=80=9D singular? >>>>>>>>>> [richanna]The singular =E2=80=9Cevent=E2=80=9D claim has clearer s= emantics and is easier to process. We should opt for easier solutions unless= there are use cases that require more complexity.[/richanna] >>>>>>>>>> =20 >>>>>>>>>> There are many reasons for multiple events in a SET. Some are go= od, some not so good. Some of the reasons... >>>>>>>>>> =20 >>>>>>>>>> 1. Multiple event payloads expressing statements about largely t= he *same*thing. For example, SCIM password reset AND RISC password reset. A= RISC Event and an OpenBanking Event. Is one a complement to the other? Do t= hey overlap or are they distinct? =20 >>>>>>>>>> [richanna]Copy/pasted from my earlier email: >>>>>>>>>> Why is it necessary or appropriate to include these events in the= same SET? They are likely being generated by different systems at different= times on the transmitter=E2=80=99s side, consumed by different systems on t= he receiver=E2=80=99s side, and possibly being transmitted over different ev= ent streams. I know the latter would be the case for us, as a receiver. Even= if it=E2=80=99s not, is it burdensome to send these events separately? What= value is gained in combining them? >>>>>>>>>> =20 >>>>>>>>>> Additionally, since the signature is over the SET and not the eve= nt objects, Receivers independently route separate events from a single toke= n without either losing the ability to verify the authenticity of the event o= r sharing all information in the SET with every system handling any event in= the token.[/richanna] >>>>>>>>>> =20 >>>>>>>>>> 2. Multiple events payloads expressing different statements abou= t the same transaction - RISC Password Reset and RISC Session Cancel >>>>>>>>>> [richanna]Same as above[/richanna] >>>>>>>>>>=20 >>>>>>>>>> 3. A new profile defines new event attributes to be added on to a= n existing event type (a pure extension)=20 >>>>>>>>>> [richanna]I have suggested a way to support extensions within an e= vent body, multiple times now. If you see problems with it, please point the= m out.[/richanna] >>>>>>>>>> =20 >>>>>>>>>> I think it is quite valid to allow 1 and 3. 2 could be limited b= y specific profiles like RISC if they want. >>>>>>>>>> =20 >>>>>>>>>> I am not in agreement that making event singular simplifies anyth= ing. For one is makes extensions complex (another nested JSON structure) and= potentially conflicting.=20 >>>>>>>>>> [richanna] >>>>>>>>>> Ways that multiple-event SETs are more complicated: >>>>>>>>>> It results in a more complex structure for the single event use c= ase, which I think we all agree is the majority use case. >>>>>>>>>> Multiple-event SETs have ambiguous semantics. The presence of two= events A and B in the same SET could mean any of: >>>>>>>>>> They are related to the same logical event (i.e. the same thing a= s if they were from different SETs that have a common txn). >>>>>>>>>> A is an extension of B. >>>>>>>>>> B is an extension of A. >>>>>>>>>> They are aliases for one another. >>>>>>>>>> They are not actually related to one another in any way. >>>>>>>>>> Claim semantics become harder to define, as different profiles ma= y want to use the same claims in different ways. >>>>>>>>>> =20 >>>>>>>>>> If the WG wants to block 1 and 2 above, then I believe we have to= establish an event registry to ensure new Event profiles do not overlap to e= liminate the need to express multiple events. >>>>>>>>>> [richanna]I=E2=80=99m not sure what you mean by this. Are you ref= erring to event names? Those are already defined by the spec to be URIs.[/ri= channa] >>>>>>>>>> Phil >>>>>>>>>> =20 >>>>>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>> =20 >>>>>>>>>>> On Oct 29, 2017, at 4:12 PM, Dick Hardt w= rote: >>>>>>>>>>> =20 >>>>>>>>>>> Phil: >>>>>>>>>>> =20 >>>>>>>>>>> In your examples for having a plurality of events, you use the w= ord "may", which leads me to question if a plurality of events is really req= uired in SET. >>>>>>>>>>> =20 >>>>>>>>>>> You posit that it will be difficult for a distributed system to c= orrelate multiple SETs with the same "txn", but the distributed system will c= ertainly need to correlate events on the same subject -- correlating events o= n the same "txn" on the same subject seems fairly simple. >>>>>>>>>>> =20 >>>>>>>>>>> I think that a receiver will need to correlate multiple SEts on t= he same subject, so having multiple events in a SET is redundant, and adds c= omplexity with no clear benefit that I can see. >>>>>>>>>>> =20 >>>>>>>>>>> An implementor may choose to send multiple SETs, or send a singl= e SET with multiple events, so a receiver will need to support both. I prefe= r we pick one way and minimize the code paths, and we will need to support c= orrelating across multiple SETs, so that seems the best mechanism. >>>>>>>>>>> =20 >>>>>>>>>>> Let me know if there is something I missed in my logic. >>>>>>>>>>> =20 >>>>>>>>>>> /Dick >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>>> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer wrote: >>>>>>>>>>>> In that case, let's add text to that effect, e.g. we could add t= o the definition of the "events" claim: >>>>>>>>>>>>=20 >>>>>>>>>>>> Profiling specifications SHOULD define the allowed event statem= ents, and MAY restrict their number. For example, some profiles may require t= his claim to contain only a single event statement. >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Yaron >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 24/10/17 22:10, Mike Jones wrote: >>>>>>>>>>>>> I agree with much of Phil=E2=80=99s rationale here. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> It=E2=80=99s fine for some profiles to say that the =E2=80=9Ce= vents=E2=80=9D set must be a singleton. That doesn=E2=80=99t have to be tru= e for all events. I think things are fine as-is. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> = -- Mike >>>>>>>>>>>>>=20 >>>>>>>>>>>>> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf= Of *Phil Hunt >>>>>>>>>>>>> *Sent:* Monday, October 23, 2017 8:47 PM >>>>>>>>>>>>> *To:* Richard Backman, Annabelle >>>>>>>>>>>>> *Cc:* ID Events Mailing List >>>>>>>>>>>>> *Subject:* Re: [Id-event] Use cases for multiple events per SE= T? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Annabelle, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I have a number of concerns with this proposal. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Profiling Independence / Keeping Event Payloads Independent >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Indicating that extensions should be handled by profiles leads= to more inter-operability issues and more importantly intrudes on the Event= payload space by suggesting a sub-schema creates potential limitations and c= onflicts that may add to complexity later on. The current format allows a pa= rser to discover and unload one or more JSON payloads which can each have in= dependent structure. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> General extensions >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The proposal also rules out general purpose extensions not rel= ated to any specific event. Given the emergence of items like GPRD, I would n= ot want to block the ability to add meta-data or other general purpose items= . We can also anticipate some delivery scenarios where additional data might= be required. Even though there is no current planned use, I see no good rea= son to rule this out. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Multiple Events =46rom Different Families (vs. Multiple Events= from a single family like RISC) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> In our RISC session we discussed expressing multiple distinct R= ISC events in one SET. The discussion was that only one RISC event at a time= . We did not discuss other event profiles. I don=E2=80=99t see a reason to r= ule out multi-events from different families at the SET level. Each profile i= s expressing slightly different things about the same event. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I can forsee some cases where it is not clear which is the pri= mary and which is the extension. There may not be a clear winner. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A couple of examples (these are necessarily real=E2=80=A6just p= ossibilities): >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * It is probably useful to be able to express simlar/overlappi= ng events from different SET profiles in one SET. For example a Backchannel= Logout & a RISC session cancel event. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * SCIM may want to represent a single transaction as causing m= ultiple state changes in an event (e.g. a password change causes multiple ef= fects). Having to chase down multiple events and correlate by =E2=80=9Ctxn=E2= =80=9D would be challenging in a multi-threaded/multi-node delivery system. = The SCIM list has not discussed this, but I would not want to block this c= apability. IOW - Just because RISC does not want to express multiple events= does not make this true for other profiles. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * We may wish to indicate a SCIM Password Reset was performed a= nd a Logout/session cancellation is expressed at the same time. The events a= re related but express different data. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Avoiding Confusion =46rom Similar Events Originating from the S= ame Transaction >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If events are sent separately, then more tracking of state (e.= g. by txn) would be required to ensure similar events are not mistaken or ha= ndled as repeats. While txn provides useful audit analysis capability, I=E2=80= =99m not sure it can be used in live or near-real time systems given distrib= uted multi-node, multi-threading architectures. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Previous Discussion >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I note that I originally raised having an attribute to designa= te primary event attribute to alleviate your concern, but this was not accep= ted. See: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * https://www.ietf.org/mail-archive/web/id-event/current/msg00= 406.html >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * https://www.ietf.org/mail-archive/web/id-event/current/msg00= 140.html >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The consensus, at least as I interpreted it is up to the recei= ver to figure this out based on the definitions it has for each event URI an= d the profiles they represent. IOW - RISC is free to limit that only one RIS= C event be expressed at a time. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Phil >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>>>>>>>>=20 >>>>>>>>>>>>> @independentid >>>>>>>>>>>>>=20 >>>>>>>>>>>>> www.independentid.com >>>>>>>>>>>>>=20 >>>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The current draft of the SET spec allows for expressing mu= ltiple >>>>>>>>>>>>> events within the same token, which introduces additional c= omplexity >>>>>>>>>>>>> and room for ambiguous semantics. We=E2=80=99ve discussed t= his in the OIDF >>>>>>>>>>>>> RISC working group and the current consensus there is that= RISC will >>>>>>>>>>>>> require that RISC events must be the only event in the SET= , having >>>>>>>>>>>>> identified ways to clearly and easily support the handful o= f use >>>>>>>>>>>>> cases for multiple events per token that people have raise= d. With >>>>>>>>>>>>> that context in mind, I propose striking the definition of= the >>>>>>>>>>>>> =E2=80=9Cevents=E2=80=9D claim from the Security Event Tok= en spec, and replacing it >>>>>>>>>>>>> with the following definition for an =E2=80=9Cevent=E2=80=9D= claim (singular): >>>>>>>>>>>>>=20 >>>>>>>>>>>>> event >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A JSON object containing an "event_type" member whose valu= e is a URI >>>>>>>>>>>>> representing a type of event defined in a Profiling Specif= ication. >>>>>>>>>>>>> The object MAY otherwise be empty, or MAY contain addition= al members >>>>>>>>>>>>> as described by the Profiling Specification. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Here is the example SET from section 2.3, rewritten with t= his change >>>>>>>>>>>>> mind: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> { >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "jti": "4d3559ec67504aaba65d40b0363faad8", >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "iat": 1458496404, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "iss": "https://scim.example.com ", >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "aud": [ >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "https://scim.example.com/Feeds/98d52461fa5bbc879593b= 7754", >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "https://scim.example.com/Feeds/5d7604516b1d08641d767= 6ee7" >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ], >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "event": { >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "event_type": "urn:ietf:params:scim:event:create", >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "ref": "https://scim.example.com/Users/44f6142df96bd6= ab61e7521d9", >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "attributes": ["id", "name", "userName", "password", "= emails"] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> } >>>>>>>>>>>>>=20 >>>>>>>>>>>>> } >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Does anyone in the working group have use cases for SETs t= hat cannot >>>>>>>>>>>>> be met by this proposed text? Within RISC, we identified t= hree use >>>>>>>>>>>>> cases, with solutions outlined below: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ** >>>>>>>>>>>>>=20 >>>>>>>>>>>>> *Extensions* >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Event extension mechanisms can be defined internal to the e= vent >>>>>>>>>>>>> object. A simple approach would be to define an =E2=80=9C= extensions=E2=80=9D member >>>>>>>>>>>>> that is a list of event objects (or set resembling the =E2= =80=9Cevents=E2=80=9D >>>>>>>>>>>>> claim as defined in the current spec). This has the advant= age of >>>>>>>>>>>>> making it clear in the data structure that there is a sing= le primary >>>>>>>>>>>>> event, with zero or more extensions. There is no room for c= onfusion >>>>>>>>>>>>> over which event is primary, or if there is a primary even= t at all. >>>>>>>>>>>>> I would be fine with adding something like this to my prop= osed text, >>>>>>>>>>>>> if there is consensus that it is broadly useful. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> *Aliases* >>>>>>>>>>>>>=20 >>>>>>>>>>>>> This use case was brought up in the context of migrating c= lients >>>>>>>>>>>>> from draft event names to standardized event names. In thi= s case, >>>>>>>>>>>>> the event transmitter can transmit two tokens for the logi= cal event, >>>>>>>>>>>>> one using the old name and another using the new name. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> *Related Events* >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The SET spec defines the txn claim as a means of correlati= ng >>>>>>>>>>>>> independent tokens that relate to the same logical event. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Amazon =E2=80=93 Identity Services >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www= .ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQc= xBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Ds5b= yBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58Z= Fd4eEZfgyoIY&e=3D >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> --=20 >>>>>>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I a= m working on! >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Id-event mailing list >>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.= org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qI= rMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DYBCGlK9mj= jhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=3DWrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001f= K02EXs&e=3D >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> Id-event mailing list >>>>>>>>>> Id-event@ietf.org >>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIr= MUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DU-a5HBND0H= aTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=3DrvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm4= 6QSz0&e=3D >>>>>>>>>=20 >>>>>>>>> =20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> -- >>>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am w= orking on! >>>>>>>> _______________________________________________ >>>>>>>> Id-event mailing list >>>>>>>> Id-event@ietf.org >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMU= B65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DiyVnrZmr9_uG= CQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=3DOe0qfLEX83vtXM7Wl2cYBe-Gg1DVPjhXjVJkfhVR= zwc&e=3D >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>> -- >>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am wor= king on! >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> -- >>>>> Subscribe to the HARDTWARE mail list to learn about projects I am work= ing on! >>>>=20 >>>>=20 >>>>=20 >>>> =20 >>>> --=20 >>>> Subscribe to the HARDTWARE mail list to learn about projects I am worki= ng on! >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65e= apI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZktc= magv5Ea21QEip4HXpEVKRa0qhlo&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&= e=3D >>>=20 >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>>=20 >>=20 >=20 >=20 >=20 > --=20 > Subscribe to the HARDTWARE mail list to learn about projects I am working o= n! --Apple-Mail-F443FA6E-E82E-4E66-8B42-43E3B96CCD6A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    I think that is a red herring. 

    = The issue is a multipayload message may be needed (for many reasons already d= iscussed) to convey one logical event. 

    An event from more than one tx= n are separate and distinct. 

    <= /div>
    There may be cumulative conclusions but t= hat is not in scope.  

    Breaking a single logical event across multiple= sets is a different thing. It requires multi part signaling for the receive= r to know they have the complete message. More complexity in both delivery a= nd set. 

    None of this is needed. 

    Phil

    On No= v 1, 2017, at 2:45 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    Per my earlier message, a receiver will often be rece= iving events from multiple transmitters for the same subject. The receiver w= ill already need a mechanism to correlate events on the same subject, A tran= smitter may have different services issuing SETs that are tied to the same e= vent, and have the same transaction, but are transmitted separately.
    Will this not be the case? Given this, a receiver MUST be doing c= orrelation across SETs. 

    On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
    On W= ed, Nov 1, 2017 at 12:45 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
    You can=E2=80=99t really have multi= ple events (at least of the same type).  The current spec can only have= one instance of a URI (afaik).  

    Note that the spec= normatively does not support multiple event SETS.  It currently states= :
    events
      The semantics of this claim is to define a set of event statements
      that each MAY add additional claims to fully describe a single
      logical event that has occurred (e.g. a state change to a
      subject).  Multiple event statements of the same type SHALL NOT be
      accepted.  The "events" claim SHOULD NOT be used to express
      multiple logical events.

    The spe= c has *always* supported requirements (as stated in the spec) for multiple s= eparate profile statements (from one or more profile familities) needing to b= e sent as a single message.  It would be INSECURE to force multiple SET= s because the current delivery mechanism only allows one SET to be delivered= at a time. There is no way to assure that a single receiver gets all of the= SETs it needs in a multi-threaded, multi-node environment at scale.  A= ssembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a common state dat= abase is NOT simple nor cost effective.
    =

    I totally agree that it is difficult for receivers to re= ceive separate events, in no particular order and correlate based on "txn". B= ut, receivers have to solve this issue regardless of "events" or "event", so= it is unrelated to this proposal.

     

    If we accommodate this in the proposed form, we end up with a= complex, deeply nested JSON structure with the possibility of namespace con= flicts.

    IMO The proposal does not simplify, it comp= licating and limiting.  

    The current spec has v= ery clean JSON and avoids namespace conflicts between profiles. I think we s= hould stay on track with the current draft and observe the normative text if= not make it stronger in regards to multi-events (understood that Mike may d= isagree).

    Phil
    <= div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-in= dent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:b= reak-word">

    Oracle Corporation, Identity Cloud Services= Architect
    @independentid
    phil.hunt@oracle.com

    On Nov 1, 2017, at 12:18 PM, Richard= Backman, Annabelle <richanna@amazon.com> wrote= :

    Unless the profile guarantees= that such related events will always be included in the same SET, then the r= eceiver has to correlate across SETs anyway, and multiple events per SET is j= ust giving the receiver another scenario that they have to support.
     
    I=E2=80=99ve already p= rovided several other reasons why we should not support multiple tokens per S= ET that no one has addressed. Here they are again:
    1. Multiple ev= ent support results in a more complex structure for the single event use cas= e, which I think we all agree is the majority use case.
      2. M= ultiple-event SETs have ambiguous semantics. The presence of two events A an= d B in the same SET could mean any of:
      1. A and B are related to the sa= me logical event (i.e. the same thing as if they were from different SETs th= at have a common txn).
      2. A is an extension of B.<= /u>
      3. B is an extension of A.
      4. A is an alias for B, or v= ice-versa.
      5. A and B are not actually related to one anothe= r in any way, and the transmitter bundled them together because they were go= ing to the same receiver.
    2. Top-level claim seman= tics become harder to define, as different profiles may want to use the same= claims in different ways.
    3. Event authenticity cannot be v= erified without having the entire SET. This forces receivers to expose downs= tream systems to more information necessary, if those systems need to be abl= e to verify authenticity.
     
    -- 
    Annabelle Richard Backman=
    Amazon =E2=80=93 Identity Services
     
     <= /u>
    From: Mike Jones <Michael.Jones@microsoft.com>
    Date: Wednesday, November 1, 2017 at 11:21 A= M
    To: Dick Hardt <    dick.hard= t@gmail.com>
    Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
    Subject: RE: [Id= -event] Use cases for multiple events per SET?
     
    I completely agree on moving complexity to the issuer over t= he recipient.  In my view, it=E2=80=99s more complex for recipients to h= ave to correlate and process a sequence of multiple SETs providing informati= on about the same logical event, and validate N signatures, than to receive o= ne SET with all the aspects of the logical event as =E2=80=9Cevents=E2=80=9D= fields, with no correlation over time then required.
     <= /div>
        &nb= sp;            &= nbsp;            = ;           &nbs= p;             -= - Mike
    From: Dick Hardt [mailto:dic= k.hardt@gmail.com] 
    Sent: Wedn= esday, November 1, 2017 9:39 AM
    To: Mike Jones <= ;Michael.Jones@microsoft.com>
    Cc: Yaron Sheffer <yaronf.ietf@gmail.c= om>; Richard Backman, Annabelle <richanna@amazo= n.com>; ID Events Mailing List <id-event@ietf.org= >; Phil Hunt (IDM) <phil.hunt@oracle.com>=
    Subject: Re: [Id-event] Use cases for multiple ev= ents per SET?
     
    Your comments highlight a couple of points:
     
    1) The examp= le is how to have a predefined extension point for extensions of a specific e= vent, it is not how to add another event. Myself, I think this is overly com= plicated. Events should be comparatively static, and as with many other JSON= formats, the receiver should ignore properties it does not understand, whic= h let's new properties be introduced as extensions. There should not be any c= onflict as extensions should only be done by the profile that created the ev= ent format to start off with.
     <= u>
    2) Having an lvalue be a URI is much h= arder to code against. I'm not sure why Marius had that in his example. Per t= he event, the type of the event is well defined with 
     
     
    3) This thread is about reasons for m= ultiple events to be contained in one set. Your mention of an issuer not wan= ting to sign separate events as a reason to allow multiple events. I think w= e have decided that given a preference, we will push effort to the transmitt= er over the receiver as in many use cases there are many more receivers. Giv= en that, it is more complex for a receiver to have different ways of managin= g the receipt of multiple events as not all issuers will bundle the events, s= o it is simpler to have only one event per SET. Including the separate event= s with a URI as an lvalue is challenging to implement, speaking from experie= nce.
     
    =
     
     <= /u>
     
     
     
     
     =
     
    &nbs= p;
     
     
    On Tue, Oct 31, 20= 17 at 11:05 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:=
    Marius=E2=80=99 proposed syntax, pasted in below, has exac= tly this characteristic.  The way I see it, his proposal essentially ha= s a primary passwordReset event and a secondary passwordResetExt data struct= ure, which could have been simply another event value in the current draft.<= /span>
     =
    This b= reaking change makes the data structures more complicated - not less.  A= nd it makes things that used to be possible impossible, reducing flexibility= to those who would use the spec.
     
    These seem like bad tradeoffs to me.
     <= /u>
    {
      "jti": "3d0c3cf797584bd193bd0fb= 1bd4e7d30",
      "iat": 1458496025,<= /u>
    =
    &nb= sp; "aud": [
       ],<= /span>
     =  "event": {  
          &n= bsp;  "id":"44f6142df96bd6ab61e7521d9",
    =
    &nb= sp;        "extensions": {
     =          "https://example.com/scim/eve= nt/passwordResetExt=E2=80=9D: {
    =    = ;          "resetAttempts":5,<= /div>
      &n= bsp;      }
           = ;}
    }
     
    In particular, it makes it impossible to sign multiple r= elated events sharing a common claims schema with a single signature by the i= ssuer.  It forces the issuer to do the extra work of signing each of th= e related events (or facets of the same logical event) individually and forc= es the recipients to do the extra work of checking all those unnecessary sig= natures.
     
    Not every profile will ever have multiple keys in the =E2=80=9Cevents=E2= =80=9D set but there=E2=80=99s absolutely no reason to preclude it.
     <= u>
      &= nbsp;            = ;            &nb= sp;           &n= bsp;            =    -- Mike
    From: Id-eve= nt [mailto:id-event-bounces@ietf.org] On Behalf Of=  Dick Hardt
    Sent: Tuesday, Oct= ober 31, 2017 9:52 PM
    To: Mike Jones <Michael.Jo= nes@microsoft.com>
    Cc: Yaron Sheffer <yaronf.i= etf@gmail.com>; Richard Backman, Annabelle <richanna@amazon.com>; I= D Events Mailing List <id-event@ietf.org>; Phil Hunt (IDM) <phil.hunt@oracle.com<= /a>>
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif">I hear you on the fact that diffe= rent people have joined the effort at different times.  That=E2=80=99s a= normal process as an effort builds momentum.  I get that not everyone w= as there when previous consensus calls were taken.
     
    I should note that I have spec= ific technical objections to the specific proposed changes being discussed a= s well.  Currently all events in the set have the same syntax.  Th= e proposals, as I understand them, revert us to a state where there=E2=80=99= s a =E2=80=9Cprimary=E2=80=9D and =E2=80=9Csecondary=E2=80=9D events, with d= ifferent syntax for the two classes.  That=E2=80=99s needlessly more co= mplicated, adding no actual value.
     
            =             &nbs= p;           &nb= sp;            &= nbsp;            = ;      -- Mike
     
    From: Dick Hardt [mailto:dick.hardt@gmail.com]&nb= sp;
    Sent: Tuesday, October 31, 2017 9:37 PM=
    To: Mike Jones <Michael.Jones@microsoft.com>
    Cc: Phil Hunt (IDM) <    phil.hunt@oracle.com>= ; Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle <= richanna= @amazon.com>; ID Events Mailing List <id-event@ietf.org>

    Subject: Re: [Id-event]= Use cases for multiple events per SET?
    =
     
    Mike
     
    As you well kn= ow, many people in a WG don't look closely at a specification until last cal= l is made. Additionally, we are coming up on only the 3rd WG meeting. The WG= has not existed for very long. While some of the participants have been wor= king on this for a while, many have not, and we are looking for consensus ac= ross the WG.
     
    Since SecEvent is a framework that we expect to be pro= filed, I feel it is important to ensure that SecEvent specifications are eas= y for a variety of profiles to adopt, and that the semantics make sense. I a= lso think that properties that are specific to a profile should be left to t= hat profile and not be included in SecEvent.
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif"> 
    Since this is a framew= ork, it is expected that as different groups profile it, there will be addit= ional feedback.
     <= /div>
    Specifically, as a participant in the RISC profile o= f SET, a number of issues in SET have surfaced as the RISC WG has looked at h= ow to use the SET.
     
    As for SET being stable for over a year, there h= ave been a number of changes to SET since then. I also don't think there was= consensus. Before the WG was formed, I and several others had expressed con= cern on the design of SET when Phil presented it at an IIW session.
     
    As to taking another year, I am hopeful we can resolve the remaining issues= in SET and publish a new draft for last call. I do not think we will need t= o wait for another WG meeting to ask for last call. 
     
    We also h= ave a number of other documents that are not in last call, and we don't have= a WG adopted draft yet for management. So there are still a number of docum= ents to work through before we have all the bits for someone to work with.
     
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif">I do think we have been making good progress since the last IETF mee= ting, and I am hopeful we can keep up this momentum and finalize all the doc= uments in a timely manner.
     <= /u>
    /Dick
     
     
    On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:
    It=E2=80=99s hard f= or me to even express my level of frustration with the recent attempts to on= ce again redesign the SecEvent Token spec.  We=E2=80=99ve been at this f= or multiple years because people keep trying to revisit decisions that were l= ong ago made by consensus.  It=E2=80=99s been stable for over a year an= d the majority of WGLC respondents said some variant of =E2=80=9CWorks for m= e =E2=80=93 ship it!=E2=80=9D
     
    There=E2=80=99s not sufficient justification to try= to undo consensus positions that have been debated and affirmed over and ov= er.  Countenancing wholesale changes at this late date is counterproduc= tive in the extreme!
     
    It=E2=80=99s far better than good enough as-is.  In my ex= perience, if we start redesigning it, it will result in another year=E2=80=99= s delay.  It does something simple and useful.  Please, let=E2=80=99= s just ship it, so people can rely on it.
     
          &nb= sp;            &= nbsp;           =             &nbs= p;           -- Mike
     <= /u>
    From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 
    Sent: Monday, October 30, 2017 2:42 PM
    To= : Dick Hardt <dick.hardt@gmail.com>
    Cc:=      Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Ann= abelle <richanna@amazon.com>; Mike Jones <Michael.Jones@microsoft.com>; ID Events Mailing List <id-event@ietf.org>
    <= div>

    Subject: Re: [Id-event] Use cases fo= r multiple events per SET?
    <= div>
     
    Inline...

    Phil


    On Oct 30, 2017, a= t 2:22 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    <= /div>
    Hi Phil
     
    Correct me if I am misunderstanding, but there i= s a RISC profile event 
     
    "http://schemas.openid.net/secevent/risc/event-=
type/a=
ccount-credential-change-required=E2=80=9D
     
    and an SCIM p= rofile event
     
    I'm sugg= esting that two different events would be sent. Embedding one in the other d= oes not make sense.
    <ph>It is a hypothetical example. Just because you disagree on this= does not mean others are not valid. 
    =  
    I just picked overlapping prop= osals that have different meaning (but not the same) to illustrate the diffe= rence from issuing a single set with different events. 
     

    As I have stated this is very different from asserting multiple dist= inct events in one SET. 

     
    Also, I think it is simpler to have event_= type be at the same level as event
     

     
    {=
    &n= bsp; "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     = ; "iat": 1458496025,
      "iss": "https://scim.example.com",<= /span>
      "aud": [
      &= nbsp;],
      &= nbsp;"event": {  
            &nbs= p;"id":"44f6142df96bd6ab61e7521d9",
        &nb= sp;    "resetAttempts":5
          &n= bsp;}
    }
    &nbs= p;
    {
      "jti": "3d0c3cf797584bd193bd0fb1bd4= e7d30",
      "iat": 1458496025,
    &= nbsp; "iss": "https://scim.example.com",
      "aud": [=
       ],
       "event": {
          &= nbsp;=E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
           =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/= "       
    <= span style=3D"font-family:'Courier New',serif">       }<= /span>
    }
    &nbs= p;
     
     
     
     
    On M= on, Oct 30, 2017 at 12:09 PM, Phil Hunt <phil.hunt@oracle.com> wrote:<= /u>
    Annabelle/Dick,
     
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif">Thanks for the comments. I think we need to examine the consequences= of the proposal in JSON.
     
    As I stated, what causes most of the issue is t= he proposed extension mechanism in the payload (possibly using events in a r= ecursive way). Does it follow the old format or the new?
    =
     
    Let=E2=80=99s &nb= sp;consider a use case where we have an identity management system that uses= SCIM, but the SCIM system is also the underlying data store for Connect.&nb= sp; A Password reset might generate the following event which has an extensi= on (conveying reset count) AND overlapping statement from RISC.  BOTH o= f which might be important to a similar receiver using SCIM and OIDC.  =
     
    The 03 spec currently would allow:
     
    {
      "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
      "iat": 1458496025,
      "iss": "https://scim.example.com",
      "=
aud": [
        "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
        "https://jh=
ub.example.com/Feeds/5d7604516b1d08641d7676ee7"
    = 
       ],
       "events"=
: {
         "urn:ietf:params:s=
cim:event:passwordReset":
      &nbs=
p;    { "id":"44f6142df96bd6ab61e7521d9"},=

         "https://example.com/s=
cim/event/passwordResetExt":
     &nb=
sp;     { "resetAttempts":5},
         "http://schemas.op=
enid.net/secevent/risc/event-type/\
           a=
ccount-credential-change-required": {
           =
  =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,=

       &nbs=
p;     =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/"
           }=

      }=

    }=

     
    In the above - each payload is a =E2=80=98peer'=
 and issued without preference by the transmitter. The receiver can assign p=
riority in its own context if that matters.
    <= pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courier New= ',serif"> 
    The new proposal:
     
    {<=
/pre>
      "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",=

      "iat": 1458496025,
    https://scim.example.com",
      "=
aud": [
        "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
        "https://jh=
ub.example.com/Feeds/5d7604516b1d08641d7676ee7"
    =

       ],
       "event":=
 {
         =E2=80=9Cevent_type=
=E2=80=9D:"urn:ietf:params:scim:event:passwordReset=E2=80=9D,=

         "id":=E2=80=9D44f6142df96bd6ab6=
1e7521d9=E2=80=9D,
        =
; =E2=80=9Cevents=E2=80=9D:{
       =
  ->note =E2=80=A6is this the old or new structure? <-<=
/u>
           "https:=
//example.com/scim/event/passwordResetExt":
             { "resetAttempts":5},=

      &nb=
sp;    "http://schemas.openid.net/secevent/risc/event-type=
/\
             account-credential-change-r=
equired": {
             =E2=80=9Csub=E2=80=9D=
:=E2=80=9D7375626A656374=E2=80=9D,
             =E2=
=80=9Ciss=E2=80=9D:"https://idp.example.com=
/"
    &n=
bsp;      }
         }<=
/pre>
       } &nb=
sp;  
    }
     
    In the above, sub-events or extens=
ions have a different format. The same complaint about the original stands.<=
/span>
     
    <=
span style=3D"font-family:Helvetica,sans-serif">*OR* (if the receiver cares a=
bout RISC more).  Note that this leads to a triple nested structure.
     
    {
      "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
      "iat": 1458496025,<=
/pre>
      "iss": "https://scim.example.com",
      "aud": [
        "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754=
",
        "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"<=
u>
       ],
     &nb=
sp; "event": {
         =E2=80=9C=
event_type=E2=80=9D:"http://schemas.ope=
nid.net/secevent/risc/event-type/\
            &nbs=
p;    account-credential-change-required=E2=80=9D,
          =E2=80=9Csub=E2=80=9D=
:=E2=80=9D7375626A656374=E2=80=9D,
          =E2=80=9Ciss=E2=80=9D=
:"https://idp.example.com/=E2=80=9C=
,
    &nb=
sp;     =E2=80=9Cevents=E2=80=9D:{<=
/pre>
         =
   "urn:ietf:params:scim:event:passwordReset":<=
u>
        =
;    { 
      =
        "id":=E2=80=9D44f6142df96bd6ab61e=
7521d9=E2=80=9D,
        &=
nbsp;     =E2=80=9Cevents=E2=80=9D:{
    =

               =
  "https://example.com/scim/event/passwordResetExt":
           &=
nbsp;       { "resetAttempts":5},  
              =
;}      
          }     
       }
    }
        "https://jhub.example.com/Feeds/98d52461fa5bbc879593=
b7754",
        "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"=

       ],
    &nbs=
p;  "event": {
         =E2=
=80=9Cevent_type=E2=80=9D:"http://schemas.o<=
wbr>penid.net/secevent/risc/event-type/\
    =

                 acc=
ount-credential-change-required=E2=80=9D=
,
     =
;     =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=
=9D,
          =E2=80=
=9Ciss=E2=80=9D:"https://idp.example.com/=
=E2=80=9C,
          =E2=80=9Cevent=E2=80=9D:{=

       &nbs=
p;    =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim=
:event:passwordReset=E2=80=9D,
            "id"=
:=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
            =E2=80=9Cevent=E2=80=9D:{<=
/u>
            &n=
bsp; =E2=80=9Cevent_type=E2=80=9D:"https://example.com/sci=
m/event/passwordResetExt=E2=80=9D,
    &nb=
sp;         "resetAttempts":5 
     &=
nbsp;      }
       }
    }
     
    This format follows the proposed singular event fo=
rmat recursively and is 3 layers deep. Note that the parser has to continue t=
o search the document for things that aren=E2=80=99t there as it has to stop=
 when no =E2=80=9Cevent=E2=80=9D attribute is found rather than iterate over=
 an array.
     
    Phil

    Oracle Corporation, Identity Cloud Servic= es Architect
    @independentid
    www.independentid.com
    phil.hunt@oracle.com
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif"> 
    On Oct 30, 2017, at 8= :57 AM, Richard Backman, Annabelle <richanna@amazon.com> wrote:<= /u>
     
    Replies inline.
     
    -- 
    Anna= belle Richard Backman
    Identity Services
     
     
    From: Phil Hunt <phil.hunt@oracle.com>Date: Sunday, October 29, 2017 at 5:25 PM
    <= b>To:     Dick Hardt <dick.ha= rdt@gmail.com>
    Cc: Yaron Sheff= er <yaronf.ietf@gmail.com>, Mike Jon= es <Michael.Jones@microsoft.com&g= t;, "Richard Backman, Annabelle" <richanna@amazon.com= >, ID Events Mailing List <id-event@ietf= .org>
    Subject: Re: [Id-event] U= se cases for multiple events per SET?
    =
     
    I hope this answers your quest= ion.
     
    My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reason why n= ot. The question should be, what is the justification to make =E2=80=9Cevent= s=E2=80=9D singular?
    [richanna]The singular =E2=80=9C= event=E2=80=9D claim has clearer semantics and is easier to process. We shou= ld opt for easier solutions unless there are use cases that require more com= plexity.[/richanna]
     
    There are many reasons for multiple events in a S= ET.  Some are good, some not so good. Some of the reasons...<= /u>
     =
    1.  M= ultiple event payloads expressing statements about largely the *same*thing. = For example, SCIM password reset AND RISC password reset.  A RISC Event= and an OpenBanking Event. Is one a complement to the other?  Do they o= verlap or are they distinct?  
    [richanna]Copy/p= asted from my earlier email:
    Why is it necess= ary or appropriate to include these events in the same SET? They are likely b= eing generated by different systems at different times on the transmitter=E2= =80=99s side, consumed by different systems on the receiver=E2=80=99s side, a= nd possibly being transmitted over different event streams. I know the latte= r would be the case for us, as a receiver. Even if it=E2=80=99s not, is it b= urdensome to send these events separately? What value is gained in combining= them?
    =  
    = Additionally, since the signature is over the SET and not the event objects,= Receivers independently route separate events from a single token without e= ither losing the ability to verify the authenticity of the event or sharing a= ll information in the SET with every system handling any event in the token.= [/richanna]
     
    =

    2.  Multi= ple events payloads expressing different statements about the same transacti= on - RISC Password Reset and RISC Session Cancel
    [richanna]Same as above[/richanna]

    3.  A new profile de= fines new event attributes to be added on to an existing event type (a pure e= xtension) 
    [richanna]I have su= ggested a way to support extensions within an event body, multiple times now= . If you see problems with it, please point them out.[/richanna]
     <= u>
    I t= hink it is quite valid to allow 1 and 3.  2 could be limited by specifi= c profiles like RISC if they want.
    =
     
    <= div>
    I am not in agreement that making event s= ingular simplifies anything. For one is makes extensions complex (another ne= sted JSON structure) and potentially conflicting. 
    [richanna]
    Ways that mul= tiple-event SETs are more complicated:
    1. It results in a more complex struct= ure for the single event use case, which I think we all agree is the majorit= y use case.
    2. Multiple-event SETs have ambiguous semantics. The prese= nce of two events A and B in the same SET could mean any of:
      1. They are related to the same logical event (= i.e. the same thing as if they were from different SETs that have a common t= xn).
      2. A is an extension of B.
      3. B is an extension of A.
      4. They are aliases for one another.
      5. They are not actually related= to one another in any way.
    1. Claim semantics become harder to define, as differ= ent profiles may want to use the same claims in different ways.
     <= /u>
    If the WG wan= ts to block 1 and 2 above, then I believe we have to establish an event regi= stry to ensure new Event profiles do not overlap to eliminate the need to ex= press multiple events.
    [richanna]I=E2=80=99= m not sure what you mean by this. Are you referring to event names? Those ar= e already defined by the spec to be URIs.[/richanna]
    <= div>
    Phil<= u>
    &nb= sp;
    Oracle Corporation, Identity Cloud Services Architect
    @independentid=
     
    Phil:
    =  
    In= your examples for having a plurality of events, you use the word "may", whi= ch leads me to question if a plurality of events is really required in SET.<= /span>
     
    You posit t= hat it will be difficult for a distributed system to correlate multiple SETs= with the same "txn", but the distributed system will certainly need to corr= elate events on the same subject -- correlating events on the same "txn" on t= he same subject seems fairly simple.
    <= div>
     
    I think that a receiver will need to correlate mul= tiple SEts on the same subject, so having multiple events in a SET is redund= ant, and adds complexity with no clear benefit that I can see.=
     
    An implementor may choos= e to send multiple SETs, or send a single SET with multiple events, so a rec= eiver will need to support both. I prefer we pick one way and minimize the c= ode paths, and we will need to support correlating across multiple SETs, so t= hat seems the best mechanism.
     
    =
    Let me know if there is something I missed in my logic.
     
    = /Dick<= u>
     =
     
    On Sun, Oct 29, 2017= at 11:28 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
    I= n that case, let's add text to that effect, e.g. we could add to the definit= ion of the "events" claim:

    Profiling specifications SHOULD define the= allowed event statements, and MAY restrict their number. For example, some p= rofiles may require this claim to contain only a single event statement.
    =
    Thanks,
            Yaron
    On 24/10/17 22:10, Mike Jones wrote:

    I agree with much of Phil=E2=80= =99s rationale here.

    It=E2=80=99s fine for some profiles to say that t= he =E2=80=9Cevents=E2=80=9D set must be a singleton.  That doesn=E2=80=99= t have to be true for all events.  I think things are fine as-is.
                &n= bsp;            =             = ;            &nb= sp;           &n= bsp;   -- Mike

    *From:* Id-event [mail= to:id-event-bounces@ietf.org] *On= Behalf Of *Phil Hunt
    *Sent:* Monday, October 23, 2017 8:47 PM
    *To:* R= ichard Backman, Annabelle <richanna@amazon.com= >
    *Cc:* ID Events Mailing List <id-event@iet= f.org>
    *Subject:* Re: [Id-event] Use cases for multiple eve= nts per SET?

    Annabelle,

    I have a number of concerns with this p= roposal.

    Profiling Independence / Keeping Event Payloads Independent<= br>
    Indicating that extensions should be handled by profiles leads to mor= e inter-operability issues and more importantly intrudes on the Event payloa= d space by suggesting a sub-schema creates potential limitations and conflic= ts that may add to complexity later on. The current format allows a parser t= o discover and unload one or more JSON payloads which can each have independ= ent structure.

    General extensions

    The proposal also rules out g= eneral purpose extensions not related to any specific event. Given the emerg= ence of items like GPRD, I would not want to block the ability to add meta-d= ata or other general purpose items. We can also anticipate some delivery sce= narios where additional data might be required. Even though there is no curr= ent planned use, I see no good reason to rule this out.

    Multiple Even= ts =46rom Different Families (vs. Multiple Events from a single family like R= ISC)

    In our RISC session we discussed expressing multiple distinct RI= SC events in one SET. The discussion was that only one RISC event at a time.= We did not discuss other event profiles. I don=E2=80=99t see a reason to ru= le out multi-events from different families at the SET level. Each profile i= s expressing slightly different things about the same event.

    I can fo= rsee some cases where it is not clear which is the primary and which is the e= xtension.  There may not be a clear winner.

    A couple of examples= (these are necessarily real=E2=80=A6just possibilities):

    * It is pro= bably useful to be able to express simlar/overlapping events from different S= ET profiles in one SET.  For example a Backchannel Logout & a RISC s= ession cancel event.

    * SCIM may want to represent a single transactio= n as causing multiple state changes in an event (e.g. a password change caus= es multiple effects). Having to chase down multiple events and correlate by =E2= =80=9Ctxn=E2=80=9D would be challenging in a multi-threaded/multi-node deliv= ery system.   The SCIM list has not discussed this, but I would no= t want to block this capability.  IOW - Just because RISC does not want= to express multiple events does not make this true for other profiles.
    <= br>* We may wish to indicate a SCIM Password Reset was performed and a Logou= t/session cancellation is expressed at the same time.  The events are r= elated but express different data.

    Avoiding Confusion =46rom Similar E= vents Originating from the Same Transaction

    If events are sent separa= tely, then more tracking of state (e.g. by txn) would be required to ensure s= imilar events are not mistaken or handled as repeats. While txn provides use= ful audit analysis capability, I=E2=80=99m not sure it can be used in live o= r near-real time systems given distributed multi-node, multi-threading archi= tectures.

    Previous Discussion

    I note that I originally raised h= aving an attribute to designate primary event attribute to alleviate your co= ncern, but this was not accepted. See:

    * https://www.ietf.org/mail-archive/w= eb/id-event/current/msg00406.html

    * https://www.ietf.org/mail-archive/web/id-event/current/msg00140.html

    The conse= nsus, at least as I interpreted it is up to the receiver to figure this out b= ased on the definitions it has for each event URI and the profiles they repr= esent. IOW - RISC is free to limit that only one RISC event be expressed at a= time.

    Phil

    Oracle Corporation, Identity Cloud Services Archit= ect

    @independentid

    www.independentid.com&nbs= p;<http://www.independentid.com>

    phil.hunt@oracle.com <mailto= :phil.hunt@oracle.com>

     =   On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle
      &n= bsp; <richanna@amazon.com = <mailto:richanna@amazon.com>= ;> wrote:

        The current draft of the SET spec allows f= or expressing multiple
        events within the same token, which i= ntroduces additional complexity
        and room for ambiguous sema= ntics. We=E2=80=99ve discussed this in the OIDF
        RISC workin= g group and the current consensus there is that RISC will
        r= equire that RISC events must be the only event in the SET, having
      &= nbsp; identified ways to clearly and easily support the handful of use
    &n= bsp;   cases for multiple events per token that people have raised. Wit= h
        that context in mind, I propose striking the definition o= f the
        =E2=80=9Cevents=E2=80=9D claim from the Security Even= t Token spec, and replacing it
        with the following definitio= n for an =E2=80=9Cevent=E2=80=9D claim (singular):

        even= t

        A JSON object containing an "event_type" member whose= value is a URI
        representing a type of event defined in a P= rofiling Specification.
        The object MAY otherwise be empty, o= r MAY contain additional members
        as described by the Profil= ing Specification.

        Here is the example SET from section= 2.3, rewritten with this change
        mind:

       =  {

           "jti": "4d3559ec6= 7504aaba65d40b0363faad8",

           "iat": 1458= 496404,

          "iss": "https:/= /scim.example.com <h= ttps://scim.example.com/>",

         &n= bsp; "aud": [

             "https://scim.example.com/Feeds/98d5= 2461fa5bbc879593b7754",

           &n= bsp; "https://scim.e= xample.com/Feeds/5d7604516b1d08641d7676ee7"

      &n= bsp;    ],

           "event": {

    &nb= sp;        "event_type": "urn:ietf:params:scim:even= t:create",

             "ref": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",

          = ;   "attributes": ["id", "name", "userName", "password", "emails"]=

           }

        }

      &n= bsp; Does anyone in the working group have use cases for SETs that cannot    be met by this proposed text? Within RISC, we identified thre= e use
        cases, with solutions outlined below:

      &= nbsp; **

        *Extensions*

        Event extens= ion mechanisms can be defined internal to the event
        object.= A simple approach would be to  define an =E2=80=9Cextensions=E2=80=9D m= ember
        that is a list of event objects (or set resembling th= e =E2=80=9Cevents=E2=80=9D
        claim as defined in the current s= pec). This has the advantage of
        making it clear in the data= structure that there is a single primary
        event, with zero o= r more extensions. There is no room for confusion
        over whic= h event is primary, or if there is a primary event at all.
        I= would be fine with adding something like this to my proposed text,
     = ;   if there is consensus that it is broadly useful.

      &nbs= p; *Aliases*

        This use case was brought up in the contex= t of migrating clients
        from draft event names to standardiz= ed event names. In this case,
        the event transmitter can tra= nsmit two tokens for the logical event,
        one using the old n= ame and another using the new name.

        *Related Events*
        The SET spec defines the txn claim as a means of correlat= ing
        independent tokens that relate to the same logical even= t.

        -- 
        Annabelle= Richard Backman

        Amazon =E2=80=93 Identity Services
    =
        _______________________________________________
    &n= bsp;   Id-event mailing list
        Id-event@ietf.org <mailto= :Id-event@ietf.org>
            https://urldefense.proofpoint.com/v= 2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d= =3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&= r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Ds5byBe5KAN= nGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=3DX8oRSq3IzlF7jiRAeZhXpR3e= VI0I58ZFd4eEZfgyoIY&e=3D



    _____________________= __________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailm= an/listinfo/id-event


    _____________________________________________= __
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event<= /span>


    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif;background-color:white"> 
    -- 
    Subscribe to the&nbs= p;= HARDTWARE mail list to learn about projects= I am working on!
     =
    _________________________= ______________________
    Id-event mailing l= ist
    Id-event@ietf.org
     

    <= br clear=3D"all">
     
    --
    Subscribe to the HARD= TWARE mail list to learn about projects I am working on!=


     
    --<= /div>
    Subscribe to the HARDTWARE mail li= st to learn about projects I am working on!
    <= /div>


     
    --
    =
    Subscribe to the HARDTWARE mail list to learn about projects I am wor= king on!


     
    -- 
    Subs= cribe to the HARDTWARE=  mail list to learn about projects I am working on!
    _______________= ________________________________
    Id-event m= ailing list
    Id-event@ietf.org<= br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-vari= ant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;te= xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgr= ound-color:rgb(255,255,255)">https://urldefense.proofpoint.com/v2/= url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3D= DwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D= na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZk= tcmagv5Ea21QEip4HXpEVKRa0qhlo&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuK= aXEbT5wu9rcORV0&e=3D


    _______________________= ________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinf= o/id-event





    --
    <= div dir=3D"ltr">
    Subscribe to the HARDTWARE mail list to learn about projects I am working on!
    <= /div>
    = --Apple-Mail-F443FA6E-E82E-4E66-8B42-43E3B96CCD6A-- From nobody Wed Nov 1 15:01:04 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECAB13F6A5 for ; Wed, 1 Nov 2017 15:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SU_n5KHj-F2D for ; Wed, 1 Nov 2017 15:00:56 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 E897813F6AC for ; Wed, 1 Nov 2017 15:00:55 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA1M0oBZ023912 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Nov 2017 22:00:50 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA1M0nPX008823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Nov 2017 22:00:49 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA1M0me7014067; Wed, 1 Nov 2017 22:00:48 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 15:00:46 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-D8B4B242-FE96-4A37-9264-48287C46CB37 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 1 Nov 2017 15:00:44 -0700 Cc: Marius Scurtescu , Yaron Sheffer , "Richard Backman, Annabelle" , Dick Hardt , Mike Jones , ID Events Mailing List Content-Transfer-Encoding: 7bit Message-Id: <77365705-D4BA-49F3-B783-370056ADBC12@oracle.com> References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> To: William Denniss X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 22:01:02 -0000 --Apple-Mail-D8B4B242-FE96-4A37-9264-48287C46CB37 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Phil > On Nov 1, 2017, at 2:46 PM, William Denniss wrote: >=20 > Perhaps I can try and explain the original intent of the current design. T= he goal was always that a SET represents a single logical event. However mul= tiple systems may have different representations of the event =E2=80=93 the e= xample given originally was one formatted for RISC, and one for SCIM. >=20 > A good analogy is email. You send a single logical email, which may have t= wo representations, HTML and plain text. Systems can consume the version tha= t they understand and ignore the one they don't. >=20 > I'm starting to regret the plural in "events", it was pluralized due to it= being an array, not because it represented multiple logical events. >=20 > Annabelle, I understand your concerns regarding confusion of the semantics= between the JSON syntax and the specification language. Are there other way= s to resolve that without removing the ability for multiple representations o= f the same event? >=20 >> On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu w= rote: >>> On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt wrote:= >>> You can=E2=80=99t really have multiple events (at least of the same type= ). The current spec can only have one instance of a URI (afaik). =20 >>>=20 >>> Note that the spec normatively does not support multiple event SETS. It= currently states: >>>> events >>>> The semantics of this claim is to define a set of event statement= s >>>> that each MAY add additional claims to fully describe a single >>>> logical event that has occurred (e.g. a state change to a >>>> subject). Multiple event statements of the same type SHALL NOT b= e >>>> accepted. The "events" claim SHOULD NOT be used to express >>>> multiple logical events. >>>=20 >>> The spec has *always* supported requirements (as stated in the spec) for= multiple separate profile statements (from one or more profile familities) n= eeding to be sent as a single message. It would be INSECURE to force multip= le SETs because the current delivery mechanism only allows one SET to be del= ivered at a time. There is no way to assure that a single receiver gets all o= f the SETs it needs in a multi-threaded, multi-node environment at scale. A= ssembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a common state dat= abase is NOT simple nor cost effective. >>=20 >> I totally agree that it is difficult for receivers to receive separate ev= ents, in no particular order and correlate based on "txn". But, receivers ha= ve to solve this issue regardless of "events" or "event", so it is unrelated= to this proposal. >>=20 >> =20 >>>=20 >>> If we accommodate this in the proposed form, we end up with a complex, d= eeply nested JSON structure with the possibility of namespace conflicts. >>>=20 >>> IMO The proposal does not simplify, it complicating and limiting. =20 >>>=20 >>> The current spec has very clean JSON and avoids namespace conflicts betw= een profiles. I think we should stay on track with the current draft and obs= erve the normative text if not make it stronger in regards to multi-events (= understood that Mike may disagree). >>>=20 >>> Phil >>>=20 >>> Oracle Corporation, Identity Cloud Services Architect >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>> On Nov 1, 2017, at 12:18 PM, Richard Backman, Annabelle wrote: >>>>=20 >>>> Unless the profile guarantees that such related events will always be i= ncluded in the same SET, then the receiver has to correlate across SETs anyw= ay, and multiple events per SET is just giving the receiver another scenario= that they have to support. >>>> =20 >>>> I=E2=80=99ve already provided several other reasons why we should not s= upport multiple tokens per SET that no one has addressed. Here they are agai= n: >>>> Multiple event support results in a more complex structure for the sing= le event use case, which I think we all agree is the majority use case. >>>> Multiple-event SETs have ambiguous semantics. The presence of two event= s A and B in the same SET could mean any of: >>>> A and B are related to the same logical event (i.e. the same thing as i= f they were from different SETs that have a common txn). >>>> A is an extension of B. >>>> B is an extension of A. >>>> A is an alias for B, or vice-versa. >>>> A and B are not actually related to one another in any way, and the tra= nsmitter bundled them together because they were going to the same receiver.= >>>> Top-level claim semantics become harder to define, as different profile= s may want to use the same claims in different ways. >>>> Event authenticity cannot be verified without having the entire SET. Th= is forces receivers to expose downstream systems to more information necessa= ry, if those systems need to be able to verify authenticity. >>>> =20 >>>> --=20 >>>> Annabelle Richard Backman >>>> Amazon =E2=80=93 Identity Services >>>> =20 >>>> =20 >>>> From: Mike Jones >>>> Date: Wednesday, November 1, 2017 at 11:21 AM >>>> To: Dick Hardt >>>> Cc: Yaron Sheffer , "Richard Backman, Annabelle"= , ID Events Mailing List , "Phil Hu= nt (IDM)" >>>> Subject: RE: [Id-event] Use cases for multiple events per SET? >>>> =20 >>>> I completely agree on moving complexity to the issuer over the recipien= t. In my view, it=E2=80=99s more complex for recipients to have to correlat= e and process a sequence of multiple SETs providing information about the sa= me logical event, and validate N signatures, than to receive one SET with al= l the aspects of the logical event as =E2=80=9Cevents=E2=80=9D fields, with n= o correlation over time then required. >>>> =20 >>>> -- Mike >>>> =20 >>>> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >>>> Sent: Wednesday, November 1, 2017 9:39 AM >>>> To: Mike Jones >>>> Cc: Yaron Sheffer ; Richard Backman, Annabelle <= richanna@amazon.com>; ID Events Mailing List ; Phil Hunt (= IDM) >>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>> =20 >>>> Your comments highlight a couple of points: >>>> =20 >>>> 1) The example is how to have a predefined extension point for extensio= ns of a specific event, it is not how to add another event. Myself, I think t= his is overly complicated. Events should be comparatively static, and as wit= h many other JSON formats, the receiver should ignore properties it does not= understand, which let's new properties be introduced as extensions. There s= hould not be any conflict as extensions should only be done by the profile t= hat created the event format to start off with. >>>> =20 >>>> 2) Having an lvalue be a URI is much harder to code against. I'm not su= re why Marius had that in his example. Per the event, the type of the event i= s well defined with=20 >>>> =20 >>>> "event_type": "https://example.com/scim/event/passwordResetExt", >>>> =20 >>>> 3) This thread is about reasons for multiple events to be contained in o= ne set. Your mention of an issuer not wanting to sign separate events as a r= eason to allow multiple events. I think we have decided that given a prefere= nce, we will push effort to the transmitter over the receiver as in many use= cases there are many more receivers. Given that, it is more complex for a r= eceiver to have different ways of managing the receipt of multiple events as= not all issuers will bundle the events, so it is simpler to have only one e= vent per SET. Including the separate events with a URI as an lvalue is chall= enging to implement, speaking from experience. >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>>> On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones wrote: >>>>> Marius=E2=80=99 proposed syntax, pasted in below, has exactly this cha= racteristic. The way I see it, his proposal essentially has a primary passw= ordReset event and a secondary passwordResetExt data structure, which could h= ave been simply another event value in the current draft. >>>>> =20 >>>>> This breaking change makes the data structures more complicated - not l= ess. And it makes things that used to be possible impossible, reducing flex= ibility to those who would use the spec. >>>>> =20 >>>>> These seem like bad tradeoffs to me. >>>>> =20 >>>>> { >>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>> "iat": 1458496025, >>>>> "iss": "https://scim.example.com", >>>>> "aud": [ >>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>> ], >>>>> "event_type": "https://example.com/scim/event/passwordResetExt", >>>>> "event": { =20 >>>>> "id":"44f6142df96bd6ab61e7521d9", >>>>> "extensions": { >>>>> "https://example.com/scim/event/passwordResetExt=E2=80=9D: {= >>>>> "resetAttempts":5, >>>>> } >>>>> } >>>>> } >>>>> } >>>>> =20 >>>>> In particular, it makes it impossible to sign multiple related events s= haring a common claims schema with a single signature by the issuer. It for= ces the issuer to do the extra work of signing each of the related events (o= r facets of the same logical event) individually and forces the recipients t= o do the extra work of checking all those unnecessary signatures. >>>>> =20 >>>>> Not every profile will ever have multiple keys in the =E2=80=9Cevents=E2= =80=9D set but there=E2=80=99s absolutely no reason to preclude it. >>>>> =20 >>>>> -- Mike >>>>> =20 >>>>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Dick Ha= rdt >>>>> Sent: Tuesday, October 31, 2017 9:52 PM >>>>> To: Mike Jones >>>>> Cc: Yaron Sheffer ; Richard Backman, Annabelle <= richanna@amazon.com>; ID Events Mailing List ; Phil Hunt (= IDM) >>>>>=20 >>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>> =20 >>>>> Please direct me to a proposal that has a "primary" and "secondary" ev= ents. I agree that is undesirable. I would also encourage to engage in the d= iscussions so that we can drive clarity and simplicity. >>>>> =20 >>>>> I think the proposal is that there is one event per SET. >>>>> =20 >>>>> I think having more than one event per SET adds complexity as a receiv= er must deal with receiving correlated events in one SET as well as correlat= ed events in the same SET. >>>>> =20 >>>>> /Dick >>>>> =20 >>>>>> On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones wrote: >>>>>> I hear you on the fact that different people have joined the effort a= t different times. That=E2=80=99s a normal process as an effort builds mome= ntum. I get that not everyone was there when previous consensus calls were t= aken. >>>>>> =20 >>>>>> I should note that I have specific technical objections to the specif= ic proposed changes being discussed as well. Currently all events in the se= t have the same syntax. The proposals, as I understand them, revert us to a= state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and =E2=80=9Csecond= ary=E2=80=9D events, with different syntax for the two classes. That=E2=80=99= s needlessly more complicated, adding no actual value. >>>>>> =20 >>>>>> -- Mi= ke >>>>>> =20 >>>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >>>>>> Sent: Tuesday, October 31, 2017 9:37 PM >>>>>> To: Mike Jones >>>>>> Cc: Phil Hunt (IDM) ; Yaron Sheffer ; Richard Backman, Annabelle ; ID Events Ma= iling List >>>>>>=20 >>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>> =20 >>>>>> Mike >>>>>> =20 >>>>>> As you well know, many people in a WG don't look closely at a specifi= cation until last call is made. Additionally, we are coming up on only the 3= rd WG meeting. The WG has not existed for very long. While some of the parti= cipants have been working on this for a while, many have not, and we are loo= king for consensus across the WG. >>>>>> =20 >>>>>> Since SecEvent is a framework that we expect to be profiled, I feel i= t is important to ensure that SecEvent specifications are easy for a variety= of profiles to adopt, and that the semantics make sense. I also think that p= roperties that are specific to a profile should be left to that profile and n= ot be included in SecEvent. >>>>>> =20 >>>>>> Since this is a framework, it is expected that as different groups pr= ofile it, there will be additional feedback. >>>>>> =20 >>>>>> Specifically, as a participant in the RISC profile of SET, a number o= f issues in SET have surfaced as the RISC WG has looked at how to use the SE= T. >>>>>> =20 >>>>>> As for SET being stable for over a year, there have been a number of c= hanges to SET since then. I also don't think there was consensus. Before the= WG was formed, I and several others had expressed concern on the design of S= ET when Phil presented it at an IIW session. >>>>>> =20 >>>>>> As to taking another year, I am hopeful we can resolve the remaining i= ssues in SET and publish a new draft for last call. I do not think we will n= eed to wait for another WG meeting to ask for last call.=20 >>>>>> =20 >>>>>> We also have a number of other documents that are not in last call, a= nd we don't have a WG adopted draft yet for management. So there are still a= number of documents to work through before we have all the bits for someone= to work with. >>>>>> =20 >>>>>> I do think we have been making good progress since the last IETF meet= ing, and I am hopeful we can keep up this momentum and finalize all the docu= ments in a timely manner. >>>>>> =20 >>>>>> /Dick >>>>>> =20 >>>>>> =20 >>>>>>> On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones wrote: >>>>>>> It=E2=80=99s hard for me to even express my level of frustration wit= h the recent attempts to once again redesign the SecEvent Token spec. We=E2= =80=99ve been at this for multiple years because people keep trying to revis= it decisions that were long ago made by consensus. It=E2=80=99s been stable= for over a year and the majority of WGLC respondents said some variant of =E2= =80=9CWorks for me =E2=80=93 ship it!=E2=80=9D >>>>>>> =20 >>>>>>> There=E2=80=99s not sufficient justification to try to undo consensu= s positions that have been debated and affirmed over and over. Countenancin= g wholesale changes at this late date is counterproductive in the extreme! >>>>>>> =20 >>>>>>> It=E2=80=99s far better than good enough as-is. In my experience, i= f we start redesigning it, it will result in another year=E2=80=99s delay. I= t does something simple and useful. Please, let=E2=80=99s just ship it, so p= eople can rely on it. >>>>>>> =20 >>>>>>> -- Mike >>>>>>> =20 >>>>>>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20 >>>>>>> Sent: Monday, October 30, 2017 2:42 PM >>>>>>> To: Dick Hardt >>>>>>> Cc: Yaron Sheffer ; Richard Backman, Annabell= e ; Mike Jones ; ID Events= Mailing List >>>>>>>=20 >>>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>>> =20 >>>>>>> Inline... >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Oct 30, 2017, at 2:22 PM, Dick Hardt wrot= e: >>>>>>>> Hi Phil >>>>>>>> =20 >>>>>>>> Correct me if I am misunderstanding, but there is a RISC profile ev= ent=20 >>>>>>>> =20 >>>>>>>> "http://schemas.openid.net/secevent/risc/event-type/account-credent= ial-change-required=E2=80=9D >>>>>>>> =20 >>>>>>>> and an SCIM profile event >>>>>>>> =20 >>>>>>>> "https://example.com/scim/event/passwordResetExt=E2=80=9D >>>>>>>> =20 >>>>>>>> I'm suggesting that two different events would be sent. Embedding o= ne in the other does not make sense. >>>>>>> It is a hypothetical example. Just because you disagree on this d= oes not mean others are not valid.=20 >>>>>>> =20 >>>>>>> I just picked overlapping proposals that have different meaning (but= not the same) to illustrate the difference from issuing a single set with d= ifferent events.=20 >>>>>>> =20 >>>>>>> As I have stated this is very different from asserting multiple dist= inct events in one SET.=20 >>>>>>>=20 >>>>>>>> =20 >>>>>>>> Also, I think it is simpler to have event_type be at the same level= as event >>>>>>> =20 >>>>>>> may be. I was working from Annabelle's proposed format.=20 >>>>>>>=20 >>>>>>>> =20 >>>>>>>> { >>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>> "iat": 1458496025, >>>>>>>> "iss": "https://scim.example.com", >>>>>>>> "aud": [ >>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>> ], >>>>>>>> "event_type": "https://example.com/scim/event/passwordResetExt",= >>>>>>>> "event": { =20 >>>>>>>> "id":"44f6142df96bd6ab61e7521d9", >>>>>>>> "resetAttempts":5 >>>>>>>> } >>>>>>>> } >>>>>>>> =20 >>>>>>>> { >>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>> "iat": 1458496025, >>>>>>>> "iss": "https://scim.example.com", >>>>>>>> "aud": [ >>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>> ], >>>>>>>> "event_type": "http://schemas.openid.net/secevent/risc/event-typ= e/account-credential-change-required", >>>>>>>> "event": { >>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" =20 >>>>>>>> } >>>>>>>> } >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>>> On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt = wrote: >>>>>>>>> Annabelle/Dick, >>>>>>>>> =20 >>>>>>>>> Thanks for the comments. I think we need to examine the consequenc= es of the proposal in JSON. >>>>>>>>> =20 >>>>>>>>> As I stated, what causes most of the issue is the proposed extensi= on mechanism in the payload (possibly using events in a recursive way). Does= it follow the old format or the new? >>>>>>>>> =20 >>>>>>>>> Let=E2=80=99s consider a use case where we have an identity manag= ement system that uses SCIM, but the SCIM system is also the underlying data= store for Connect. A Password reset might generate the following event whi= ch has an extension (conveying reset count) AND overlapping statement from R= ISC. BOTH of which might be important to a similar receiver using SCIM and O= IDC. =20 >>>>>>>>> =20 >>>>>>>>> The 03 spec currently would allow: >>>>>>>>> =20 >>>>>>>>> { >>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>> "iat": 1458496025, >>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>> "aud": [ >>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>> ], >>>>>>>>> "events": { >>>>>>>>> "urn:ietf:params:scim:event:passwordReset": >>>>>>>>> { "id":"44f6142df96bd6ab61e7521d9"}, >>>>>>>>> "https://example.com/scim/event/passwordResetExt": >>>>>>>>> { "resetAttempts":5}, >>>>>>>>> "http://schemas.openid.net/secevent/risc/event-type/\ >>>>>>>>> account-credential-change-required": { >>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> =20 >>>>>>>>> In the above - each payload is a =E2=80=98peer' and issued without= preference by the transmitter. The receiver can assign priority in its own c= ontext if that matters. >>>>>>>>> =20 >>>>>>>>> The new proposal: >>>>>>>>> =20 >>>>>>>>> { >>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>> "iat": 1458496025, >>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>> "aud": [ >>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>> ], >>>>>>>>> "event": { >>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:pass= wordReset=E2=80=9D, >>>>>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>>>>> ->note =E2=80=A6is this the old or new structure? <- >>>>>>>>> "https://example.com/scim/event/passwordResetExt": >>>>>>>>> { "resetAttempts":5}, >>>>>>>>> "http://schemas.openid.net/secevent/risc/event-type/\ >>>>>>>>> account-credential-change-required": { >>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } =20 >>>>>>>>> } >>>>>>>>> =20 >>>>>>>>> In the above, sub-events or extensions have a different format. Th= e same complaint about the original stands. >>>>>>>>> =20 >>>>>>>>> *OR* (if the receiver cares about RISC more). Note that this lead= s to a triple nested structure. >>>>>>>>> =20 >>>>>>>>> { >>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>> "iat": 1458496025, >>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>> "aud": [ >>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>> ], >>>>>>>>> "event": { >>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secev= ent/risc/event-type/\ >>>>>>>>> account-credential-change-required=E2=80=9D, >>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >>>>>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>>>>> "urn:ietf:params:scim:event:passwordReset": >>>>>>>>> {=20 >>>>>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>>>>> "https://example.com/scim/event/passwordResetExt": >>>>>>>>> { "resetAttempts":5}, =20 >>>>>>>>> } =20 >>>>>>>>> } >>>>>>>>> } =20 >>>>>>>>> } >>>>>>>>> } >>>>>>>>> =20 >>>>>>>>> In the above, the extension is placed inside the event it extends.= It follows the old format (or should it follow the new?) >>>>>>>>> *OR* Following the top layer pattern of singular event Note that t= his leads to a triple nested structure. >>>>>>>>> =20 >>>>>>>>> { >>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>> "iat": 1458496025, >>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>> "aud": [ >>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>> ], >>>>>>>>> "event": { >>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secev= ent/risc/event-type/\ >>>>>>>>> account-credential-change-required=E2=80=9D, >>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >>>>>>>>> =E2=80=9Cevent=E2=80=9D:{ >>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:p= asswordReset=E2=80=9D, >>>>>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>>>>> =E2=80=9Cevent=E2=80=9D:{ >>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/e= vent/passwordResetExt=E2=80=9D, >>>>>>>>> "resetAttempts":5=20 >>>>>>>>> } >>>>>>>>> } =20 >>>>>>>>> } >>>>>>>>> } >>>>>>>>> =20 >>>>>>>>> This format follows the proposed singular event format recursively= and is 3 layers deep. Note that the parser has to continue to search the do= cument for things that aren=E2=80=99t there as it has to stop when no =E2=80= =9Cevent=E2=80=9D attribute is found rather than iterate over an array. >>>>>>>>> =20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>>>> @independentid >>>>>>>>> www.independentid.com >>>>>>>>> phil.hunt@oracle.com >>>>>>>>> =20 >>>>>>>>>> On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle wrote: >>>>>>>>>> =20 >>>>>>>>>> Replies inline. >>>>>>>>>> =20 >>>>>>>>>> --=20 >>>>>>>>>> Annabelle Richard Backman >>>>>>>>>> Identity Services >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> From: Phil Hunt >>>>>>>>>> Date: Sunday, October 29, 2017 at 5:25 PM >>>>>>>>>> To: Dick Hardt >>>>>>>>>> Cc: Yaron Sheffer , Mike Jones , "Richard Backman, Annabelle" , ID E= vents Mailing List >>>>>>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>>>>>> =20 >>>>>>>>>> I hope this answers your question. >>>>>>>>>> =20 >>>>>>>>>> My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reason= why not. The question should be, what is the justification to make =E2=80=9C= events=E2=80=9D singular? >>>>>>>>>> [richanna]The singular =E2=80=9Cevent=E2=80=9D claim has clearer s= emantics and is easier to process. We should opt for easier solutions unless= there are use cases that require more complexity.[/richanna] >>>>>>>>>> =20 >>>>>>>>>> There are many reasons for multiple events in a SET. Some are go= od, some not so good. Some of the reasons... >>>>>>>>>> =20 >>>>>>>>>> 1. Multiple event payloads expressing statements about largely t= he *same*thing. For example, SCIM password reset AND RISC password reset. A= RISC Event and an OpenBanking Event. Is one a complement to the other? Do t= hey overlap or are they distinct? =20 >>>>>>>>>> [richanna]Copy/pasted from my earlier email: >>>>>>>>>> Why is it necessary or appropriate to include these events in the= same SET? They are likely being generated by different systems at different= times on the transmitter=E2=80=99s side, consumed by different systems on t= he receiver=E2=80=99s side, and possibly being transmitted over different ev= ent streams. I know the latter would be the case for us, as a receiver. Even= if it=E2=80=99s not, is it burdensome to send these events separately? What= value is gained in combining them? >>>>>>>>>> =20 >>>>>>>>>> Additionally, since the signature is over the SET and not the eve= nt objects, Receivers independently route separate events from a single toke= n without either losing the ability to verify the authenticity of the event o= r sharing all information in the SET with every system handling any event in= the token.[/richanna] >>>>>>>>>> =20 >>>>>>>>>> 2. Multiple events payloads expressing different statements abou= t the same transaction - RISC Password Reset and RISC Session Cancel >>>>>>>>>> [richanna]Same as above[/richanna] >>>>>>>>>>=20 >>>>>>>>>> 3. A new profile defines new event attributes to be added on to a= n existing event type (a pure extension)=20 >>>>>>>>>> [richanna]I have suggested a way to support extensions within an e= vent body, multiple times now. If you see problems with it, please point the= m out.[/richanna] >>>>>>>>>> =20 >>>>>>>>>> I think it is quite valid to allow 1 and 3. 2 could be limited b= y specific profiles like RISC if they want. >>>>>>>>>> =20 >>>>>>>>>> I am not in agreement that making event singular simplifies anyth= ing. For one is makes extensions complex (another nested JSON structure) and= potentially conflicting.=20 >>>>>>>>>> [richanna] >>>>>>>>>> Ways that multiple-event SETs are more complicated: >>>>>>>>>> It results in a more complex structure for the single event use c= ase, which I think we all agree is the majority use case. >>>>>>>>>> Multiple-event SETs have ambiguous semantics. The presence of two= events A and B in the same SET could mean any of: >>>>>>>>>> They are related to the same logical event (i.e. the same thing a= s if they were from different SETs that have a common txn). >>>>>>>>>> A is an extension of B. >>>>>>>>>> B is an extension of A. >>>>>>>>>> They are aliases for one another. >>>>>>>>>> They are not actually related to one another in any way. >>>>>>>>>> Claim semantics become harder to define, as different profiles ma= y want to use the same claims in different ways. >>>>>>>>>> =20 >>>>>>>>>> If the WG wants to block 1 and 2 above, then I believe we have to= establish an event registry to ensure new Event profiles do not overlap to e= liminate the need to express multiple events. >>>>>>>>>> [richanna]I=E2=80=99m not sure what you mean by this. Are you ref= erring to event names? Those are already defined by the spec to be URIs.[/ri= channa] >>>>>>>>>> Phil >>>>>>>>>> =20 >>>>>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>> =20 >>>>>>>>>>> On Oct 29, 2017, at 4:12 PM, Dick Hardt w= rote: >>>>>>>>>>> =20 >>>>>>>>>>> Phil: >>>>>>>>>>> =20 >>>>>>>>>>> In your examples for having a plurality of events, you use the w= ord "may", which leads me to question if a plurality of events is really req= uired in SET. >>>>>>>>>>> =20 >>>>>>>>>>> You posit that it will be difficult for a distributed system to c= orrelate multiple SETs with the same "txn", but the distributed system will c= ertainly need to correlate events on the same subject -- correlating events o= n the same "txn" on the same subject seems fairly simple. >>>>>>>>>>> =20 >>>>>>>>>>> I think that a receiver will need to correlate multiple SEts on t= he same subject, so having multiple events in a SET is redundant, and adds c= omplexity with no clear benefit that I can see. >>>>>>>>>>> =20 >>>>>>>>>>> An implementor may choose to send multiple SETs, or send a singl= e SET with multiple events, so a receiver will need to support both. I prefe= r we pick one way and minimize the code paths, and we will need to support c= orrelating across multiple SETs, so that seems the best mechanism. >>>>>>>>>>> =20 >>>>>>>>>>> Let me know if there is something I missed in my logic. >>>>>>>>>>> =20 >>>>>>>>>>> /Dick >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>>> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer wrote: >>>>>>>>>>>> In that case, let's add text to that effect, e.g. we could add t= o the definition of the "events" claim: >>>>>>>>>>>>=20 >>>>>>>>>>>> Profiling specifications SHOULD define the allowed event statem= ents, and MAY restrict their number. For example, some profiles may require t= his claim to contain only a single event statement. >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Yaron >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 24/10/17 22:10, Mike Jones wrote: >>>>>>>>>>>>> I agree with much of Phil=E2=80=99s rationale here. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> It=E2=80=99s fine for some profiles to say that the =E2=80=9Ce= vents=E2=80=9D set must be a singleton. That doesn=E2=80=99t have to be tru= e for all events. I think things are fine as-is. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> = -- Mike >>>>>>>>>>>>>=20 >>>>>>>>>>>>> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf= Of *Phil Hunt >>>>>>>>>>>>> *Sent:* Monday, October 23, 2017 8:47 PM >>>>>>>>>>>>> *To:* Richard Backman, Annabelle >>>>>>>>>>>>> *Cc:* ID Events Mailing List >>>>>>>>>>>>> *Subject:* Re: [Id-event] Use cases for multiple events per SE= T? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Annabelle, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I have a number of concerns with this proposal. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Profiling Independence / Keeping Event Payloads Independent >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Indicating that extensions should be handled by profiles leads= to more inter-operability issues and more importantly intrudes on the Event= payload space by suggesting a sub-schema creates potential limitations and c= onflicts that may add to complexity later on. The current format allows a pa= rser to discover and unload one or more JSON payloads which can each have in= dependent structure. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> General extensions >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The proposal also rules out general purpose extensions not rel= ated to any specific event. Given the emergence of items like GPRD, I would n= ot want to block the ability to add meta-data or other general purpose items= . We can also anticipate some delivery scenarios where additional data might= be required. Even though there is no current planned use, I see no good rea= son to rule this out. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Multiple Events =46rom Different Families (vs. Multiple Events= from a single family like RISC) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> In our RISC session we discussed expressing multiple distinct R= ISC events in one SET. The discussion was that only one RISC event at a time= . We did not discuss other event profiles. I don=E2=80=99t see a reason to r= ule out multi-events from different families at the SET level. Each profile i= s expressing slightly different things about the same event. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I can forsee some cases where it is not clear which is the pri= mary and which is the extension. There may not be a clear winner. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A couple of examples (these are necessarily real=E2=80=A6just p= ossibilities): >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * It is probably useful to be able to express simlar/overlappi= ng events from different SET profiles in one SET. For example a Backchannel= Logout & a RISC session cancel event. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * SCIM may want to represent a single transaction as causing m= ultiple state changes in an event (e.g. a password change causes multiple ef= fects). Having to chase down multiple events and correlate by =E2=80=9Ctxn=E2= =80=9D would be challenging in a multi-threaded/multi-node delivery system. = The SCIM list has not discussed this, but I would not want to block this c= apability. IOW - Just because RISC does not want to express multiple events= does not make this true for other profiles. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * We may wish to indicate a SCIM Password Reset was performed a= nd a Logout/session cancellation is expressed at the same time. The events a= re related but express different data. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Avoiding Confusion =46rom Similar Events Originating from the S= ame Transaction >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If events are sent separately, then more tracking of state (e.= g. by txn) would be required to ensure similar events are not mistaken or ha= ndled as repeats. While txn provides useful audit analysis capability, I=E2=80= =99m not sure it can be used in live or near-real time systems given distrib= uted multi-node, multi-threading architectures. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Previous Discussion >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I note that I originally raised having an attribute to designa= te primary event attribute to alleviate your concern, but this was not accep= ted. See: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * https://www.ietf.org/mail-archive/web/id-event/current/msg00= 406.html >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * https://www.ietf.org/mail-archive/web/id-event/current/msg00= 140.html >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The consensus, at least as I interpreted it is up to the recei= ver to figure this out based on the definitions it has for each event URI an= d the profiles they represent. IOW - RISC is free to limit that only one RIS= C event be expressed at a time. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Phil >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>>>>>>>>=20 >>>>>>>>>>>>> @independentid >>>>>>>>>>>>>=20 >>>>>>>>>>>>> www.independentid.com >>>>>>>>>>>>>=20 >>>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The current draft of the SET spec allows for expressing mu= ltiple >>>>>>>>>>>>> events within the same token, which introduces additional c= omplexity >>>>>>>>>>>>> and room for ambiguous semantics. We=E2=80=99ve discussed t= his in the OIDF >>>>>>>>>>>>> RISC working group and the current consensus there is that= RISC will >>>>>>>>>>>>> require that RISC events must be the only event in the SET= , having >>>>>>>>>>>>> identified ways to clearly and easily support the handful o= f use >>>>>>>>>>>>> cases for multiple events per token that people have raise= d. With >>>>>>>>>>>>> that context in mind, I propose striking the definition of= the >>>>>>>>>>>>> =E2=80=9Cevents=E2=80=9D claim from the Security Event Tok= en spec, and replacing it >>>>>>>>>>>>> with the following definition for an =E2=80=9Cevent=E2=80=9D= claim (singular): >>>>>>>>>>>>>=20 >>>>>>>>>>>>> event >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A JSON object containing an "event_type" member whose valu= e is a URI >>>>>>>>>>>>> representing a type of event defined in a Profiling Specif= ication. >>>>>>>>>>>>> The object MAY otherwise be empty, or MAY contain addition= al members >>>>>>>>>>>>> as described by the Profiling Specification. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Here is the example SET from section 2.3, rewritten with t= his change >>>>>>>>>>>>> mind: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> { >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "jti": "4d3559ec67504aaba65d40b0363faad8", >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "iat": 1458496404, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "iss": "https://scim.example.com ", >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "aud": [ >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "https://scim.example.com/Feeds/98d52461fa5bbc879593b= 7754", >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "https://scim.example.com/Feeds/5d7604516b1d08641d767= 6ee7" >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ], >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "event": { >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "event_type": "urn:ietf:params:scim:event:create", >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "ref": "https://scim.example.com/Users/44f6142df96bd6= ab61e7521d9", >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "attributes": ["id", "name", "userName", "password", "= emails"] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> } >>>>>>>>>>>>>=20 >>>>>>>>>>>>> } >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Does anyone in the working group have use cases for SETs t= hat cannot >>>>>>>>>>>>> be met by this proposed text? Within RISC, we identified t= hree use >>>>>>>>>>>>> cases, with solutions outlined below: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ** >>>>>>>>>>>>>=20 >>>>>>>>>>>>> *Extensions* >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Event extension mechanisms can be defined internal to the e= vent >>>>>>>>>>>>> object. A simple approach would be to define an =E2=80=9C= extensions=E2=80=9D member >>>>>>>>>>>>> that is a list of event objects (or set resembling the =E2= =80=9Cevents=E2=80=9D >>>>>>>>>>>>> claim as defined in the current spec). This has the advant= age of >>>>>>>>>>>>> making it clear in the data structure that there is a sing= le primary >>>>>>>>>>>>> event, with zero or more extensions. There is no room for c= onfusion >>>>>>>>>>>>> over which event is primary, or if there is a primary even= t at all. >>>>>>>>>>>>> I would be fine with adding something like this to my prop= osed text, >>>>>>>>>>>>> if there is consensus that it is broadly useful. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> *Aliases* >>>>>>>>>>>>>=20 >>>>>>>>>>>>> This use case was brought up in the context of migrating c= lients >>>>>>>>>>>>> from draft event names to standardized event names. In thi= s case, >>>>>>>>>>>>> the event transmitter can transmit two tokens for the logi= cal event, >>>>>>>>>>>>> one using the old name and another using the new name. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> *Related Events* >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The SET spec defines the txn claim as a means of correlati= ng >>>>>>>>>>>>> independent tokens that relate to the same logical event. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Amazon =E2=80=93 Identity Services >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www= .ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQc= xBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Ds5b= yBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58Z= Fd4eEZfgyoIY&e=3D >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> --=20 >>>>>>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I a= m working on! >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Id-event mailing list >>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.= org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qI= rMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DYBCGlK9mj= jhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=3DWrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001f= K02EXs&e=3D >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> Id-event mailing list >>>>>>>>>> Id-event@ietf.org >>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIr= MUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DU-a5HBND0H= aTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=3DrvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm4= 6QSz0&e=3D >>>>>>>>>=20 >>>>>>>>> =20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> -- >>>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am w= orking on! >>>>>>>> _______________________________________________ >>>>>>>> Id-event mailing list >>>>>>>> Id-event@ietf.org >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMU= B65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DiyVnrZmr9_uG= CQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=3DOe0qfLEX83vtXM7Wl2cYBe-Gg1DVPjhXjVJkfhVR= zwc&e=3D >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>> -- >>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am wor= king on! >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> -- >>>>> Subscribe to the HARDTWARE mail list to learn about projects I am work= ing on! >>>>=20 >>>>=20 >>>>=20 >>>> =20 >>>> --=20 >>>> Subscribe to the HARDTWARE mail list to learn about projects I am worki= ng on! >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65e= apI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZktc= magv5Ea21QEip4HXpEVKRa0qhlo&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&= e=3D >>>=20 >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>>=20 >>=20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >>=20 >=20 --Apple-Mail-D8B4B242-FE96-4A37-9264-48287C46CB37 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    +1

    Phil

    On Nov 1,= 2017, at 2:46 PM, William Denniss <wdenniss@google.com> wrote:

    =
    Perhaps I can try and explain the original intent of t= he current design. The goal was always that a SET represents a single logica= l event. However multiple systems may have different representations of the e= vent =E2=80=93 the example given originally was one formatted for RISC, and o= ne for SCIM.

    A good analogy is email. You send a single l= ogical email, which may have two representations, HTML and plain text. Syste= ms can consume the version that they understand and ignore the one they don'= t.

    I'm starting to regret the plural in "events", i= t was pluralized due to it being an array, not because it represented multip= le logical events.

    Annabelle, I understand your con= cerns regarding confusion of the semantics between the JSON syntax and the s= pecification language. Are there other ways to resolve that without removing= the ability for multiple representations of the same event?

    On Wed, Nov 1, 2017 at= 2:37 PM, Marius Scurtescu <mscurtescu@google.com> wrote:<= br>
    On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt <phil.hunt@oracle.com> wro= te:
    You= can=E2=80=99t really have multiple events (at least of the same type). = ; The current spec can only have one instance of a URI (afaik).  
    <= br>
    Note that the spec normatively does not support multiple event= SETS.  It currently states:
    events
      The semantics of this claim is to define a set of event statements
      that each MAY add additional claims to fully describe a single
      logical event that has occurred (e.g. a state change to a
      subject).  Multiple event statements of the same type SHALL NOT be
      accepted.  The "events" claim SHOULD NOT be used to express
      multiple logical events.

    The spe= c has *always* supported requirements (as stated in the spec) for multiple s= eparate profile statements (from one or more profile familities) needing to b= e sent as a single message.  It would be INSECURE to force multiple SET= s because the current delivery mechanism only allows one SET to be delivered= at a time. There is no way to assure that a single receiver gets all of the= SETs it needs in a multi-threaded, multi-node environment at scale.  A= ssembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a common state dat= abase is NOT simple nor cost effective.
    =

    I totally agree that it is difficult for receivers to re= ceive separate events, in no particular order and correlate based on "txn". B= ut, receivers have to solve this issue regardless of "events" or "event", so= it is unrelated to this proposal.

     

    If we accommodate this in the proposed form, we end up with a= complex, deeply nested JSON structure with the possibility of namespace con= flicts.

    IMO The proposal does not simplify, it comp= licating and limiting.  

    The current spec has v= ery clean JSON and avoids namespace conflicts between profiles. I think we s= hould stay on track with the current draft and observe the normative text if= not make it stronger in regards to multi-events (understood that Mike may d= isagree).

    Phil
    <= div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-in= dent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:b= reak-word">

    Oracle Corporation, Identity Cloud Services= Architect
    @independentid
    phil.hunt@oracle.com

    On Nov 1, 2017, at 12:18 PM, Richard= Backman, Annabelle <richanna@amazon.com> wrote= :

    Unless the profile guarantees= that such related events will always be included in the same SET, then the r= eceiver has to correlate across SETs anyway, and multiple events per SET is j= ust giving the receiver another scenario that they have to support.
     
    I=E2=80=99ve already p= rovided several other reasons why we should not support multiple tokens per S= ET that no one has addressed. Here they are again:
    1. Multiple ev= ent support results in a more complex structure for the single event use cas= e, which I think we all agree is the majority use case.
      2. M= ultiple-event SETs have ambiguous semantics. The presence of two events A an= d B in the same SET could mean any of:
      1. A and B are related to the sa= me logical event (i.e. the same thing as if they were from different SETs th= at have a common txn).
      2. A is an extension of B.<= /u>
      3. B is an extension of A.
      4. A is an alias for B, or v= ice-versa.
      5. A and B are not actually related to one anothe= r in any way, and the transmitter bundled them together because they were go= ing to the same receiver.
    2. Top-level claim seman= tics become harder to define, as different profiles may want to use the same= claims in different ways.
    3. Event authenticity cannot be v= erified without having the entire SET. This forces receivers to expose downs= tream systems to more information necessary, if those systems need to be abl= e to verify authenticity.
     
    -- 
    Annabelle Richard Backman=
    Amazon =E2=80=93 Identity Services
     
     <= /u>
    From: Mike Jones <Michael.Jones@microsoft.com>
    Date: Wednesday, November 1, 2017 at 11:21 A= M
    To: Dick Hardt <    dick.hard= t@gmail.com>
    Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
    Subject: RE: [Id= -event] Use cases for multiple events per SET?
     
    I completely agree on moving complexity to the issuer over t= he recipient.  In my view, it=E2=80=99s more complex for recipients to h= ave to correlate and process a sequence of multiple SETs providing informati= on about the same logical event, and validate N signatures, than to receive o= ne SET with all the aspects of the logical event as =E2=80=9Cevents=E2=80=9D= fields, with no correlation over time then required.
     <= /div>
        &nb= sp;            &= nbsp;            = ;           &nbs= p;             -= - Mike
    From: Dick Hardt [mailto:dic= k.hardt@gmail.com] 
    Sent: Wedn= esday, November 1, 2017 9:39 AM
    To: Mike Jones <= ;Michael.Jones@microsoft.com>
    Cc: Yaron Sheffer <yaronf.ietf@gmail.c= om>; Richard Backman, Annabelle <richanna@amazo= n.com>; ID Events Mailing List <id-event@ietf.org= >; Phil Hunt (IDM) <phil.hunt@oracle.com>=
    Subject: Re: [Id-event] Use cases for multiple ev= ents per SET?
     
    Your comments highlight a couple of points:
     
    1) The examp= le is how to have a predefined extension point for extensions of a specific e= vent, it is not how to add another event. Myself, I think this is overly com= plicated. Events should be comparatively static, and as with many other JSON= formats, the receiver should ignore properties it does not understand, whic= h let's new properties be introduced as extensions. There should not be any c= onflict as extensions should only be done by the profile that created the ev= ent format to start off with.
     <= u>
    2) Having an lvalue be a URI is much h= arder to code against. I'm not sure why Marius had that in his example. Per t= he event, the type of the event is well defined with 
     
     
    3) This thread is about reasons for m= ultiple events to be contained in one set. Your mention of an issuer not wan= ting to sign separate events as a reason to allow multiple events. I think w= e have decided that given a preference, we will push effort to the transmitt= er over the receiver as in many use cases there are many more receivers. Giv= en that, it is more complex for a receiver to have different ways of managin= g the receipt of multiple events as not all issuers will bundle the events, s= o it is simpler to have only one event per SET. Including the separate event= s with a URI as an lvalue is challenging to implement, speaking from experie= nce.
     
    =
     
     <= /u>
     
     
     
     
     =
     
    &nbs= p;
     
     
    On Tue, Oct 31, 20= 17 at 11:05 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:=
    Marius=E2=80=99 proposed syntax, pasted in below, has exac= tly this characteristic.  The way I see it, his proposal essentially ha= s a primary passwordReset event and a secondary passwordResetExt data struct= ure, which could have been simply another event value in the current draft.<= /span>
     =
    This b= reaking change makes the data structures more complicated - not less.  A= nd it makes things that used to be possible impossible, reducing flexibility= to those who would use the spec.
     
    These seem like bad tradeoffs to me.
     <= /u>
    {
      "jti": "3d0c3cf797584bd193bd0fb= 1bd4e7d30",
      "iat": 1458496025,<= /u>
    =
    &nb= sp; "aud": [
       ],<= /span>
     =  "event": {  
          &n= bsp;  "id":"44f6142df96bd6ab61e7521d9",
    =
    &nb= sp;        "extensions": {
     =          "https://example.com/scim/eve= nt/passwordResetExt=E2=80=9D: {
    =    = ;          "resetAttempts":5,<= /div>
      &n= bsp;      }
           = ;}
    }
     
    In particular, it makes it impossible to sign multiple r= elated events sharing a common claims schema with a single signature by the i= ssuer.  It forces the issuer to do the extra work of signing each of th= e related events (or facets of the same logical event) individually and forc= es the recipients to do the extra work of checking all those unnecessary sig= natures.
     
    Not every profile will ever have multiple keys in the =E2=80=9Cevents=E2= =80=9D set but there=E2=80=99s absolutely no reason to preclude it.
     <= u>
      &= nbsp;            = ;            &nb= sp;           &n= bsp;            =    -- Mike
    From: Id-eve= nt [mailto:id-event-bounces@ietf.org] On Behalf Of=  Dick Hardt
    Sent: Tuesday, Oct= ober 31, 2017 9:52 PM
    To: Mike Jones <Michael.Jo= nes@microsoft.com>
    Cc: Yaron Sheffer <yaronf.i= etf@gmail.com>; Richard Backman, Annabelle <richanna@amazon.com>; I= D Events Mailing List <id-event@ietf.org>; Phil Hunt (IDM) <phil.hunt@oracle.com<= /a>>
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif">I hear you on the fact that diffe= rent people have joined the effort at different times.  That=E2=80=99s a= normal process as an effort builds momentum.  I get that not everyone w= as there when previous consensus calls were taken.
     
    I should note that I have spec= ific technical objections to the specific proposed changes being discussed a= s well.  Currently all events in the set have the same syntax.  Th= e proposals, as I understand them, revert us to a state where there=E2=80=99= s a =E2=80=9Cprimary=E2=80=9D and =E2=80=9Csecondary=E2=80=9D events, with d= ifferent syntax for the two classes.  That=E2=80=99s needlessly more co= mplicated, adding no actual value.
     
            =             &nbs= p;           &nb= sp;            &= nbsp;            = ;      -- Mike
     
    From: Dick Hardt [mailto:dick.hardt@gmail.com]&nb= sp;
    Sent: Tuesday, October 31, 2017 9:37 PM=
    To: Mike Jones <Michael.Jones@microsoft.com>
    Cc: Phil Hunt (IDM) <    phil.hunt@oracle.com>= ; Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle <= richanna= @amazon.com>; ID Events Mailing List <id-event@ietf.org>

    Subject: Re: [Id-event]= Use cases for multiple events per SET?
    =
     
    Mike
     
    As you well kn= ow, many people in a WG don't look closely at a specification until last cal= l is made. Additionally, we are coming up on only the 3rd WG meeting. The WG= has not existed for very long. While some of the participants have been wor= king on this for a while, many have not, and we are looking for consensus ac= ross the WG.
     
    Since SecEvent is a framework that we expect to be pro= filed, I feel it is important to ensure that SecEvent specifications are eas= y for a variety of profiles to adopt, and that the semantics make sense. I a= lso think that properties that are specific to a profile should be left to t= hat profile and not be included in SecEvent.
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif"> 
    Since this is a framew= ork, it is expected that as different groups profile it, there will be addit= ional feedback.
     <= /div>
    Specifically, as a participant in the RISC profile o= f SET, a number of issues in SET have surfaced as the RISC WG has looked at h= ow to use the SET.
     
    As for SET being stable for over a year, there h= ave been a number of changes to SET since then. I also don't think there was= consensus. Before the WG was formed, I and several others had expressed con= cern on the design of SET when Phil presented it at an IIW session.
     
    As to taking another year, I am hopeful we can resolve the remaining issues= in SET and publish a new draft for last call. I do not think we will need t= o wait for another WG meeting to ask for last call. 
     
    We also h= ave a number of other documents that are not in last call, and we don't have= a WG adopted draft yet for management. So there are still a number of docum= ents to work through before we have all the bits for someone to work with.
     
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif">I do think we have been making good progress since the last IETF mee= ting, and I am hopeful we can keep up this momentum and finalize all the doc= uments in a timely manner.
     <= /u>
    /Dick
     
     
    On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:
    It=E2=80=99s hard f= or me to even express my level of frustration with the recent attempts to on= ce again redesign the SecEvent Token spec.  We=E2=80=99ve been at this f= or multiple years because people keep trying to revisit decisions that were l= ong ago made by consensus.  It=E2=80=99s been stable for over a year an= d the majority of WGLC respondents said some variant of =E2=80=9CWorks for m= e =E2=80=93 ship it!=E2=80=9D
     
    There=E2=80=99s not sufficient justification to try= to undo consensus positions that have been debated and affirmed over and ov= er.  Countenancing wholesale changes at this late date is counterproduc= tive in the extreme!
     
    It=E2=80=99s far better than good enough as-is.  In my ex= perience, if we start redesigning it, it will result in another year=E2=80=99= s delay.  It does something simple and useful.  Please, let=E2=80=99= s just ship it, so people can rely on it.
     
          &nb= sp;            &= nbsp;           =             &nbs= p;           -- Mike
     <= /u>
    From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 
    Sent: Monday, October 30, 2017 2:42 PM
    To= : Dick Hardt <dick.hardt@gmail.com>
    Cc:=      Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Ann= abelle <richanna@amazon.com>; Mike Jones <Michael.Jones@microsoft.com>; ID Events Mailing List <id-event@ietf.org>
    <= div>

    Subject: Re: [Id-event] Use cases fo= r multiple events per SET?
    <= div>
     
    Inline...

    Phil


    On Oct 30, 2017, a= t 2:22 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    <= /div>
    Hi Phil
     
    Correct me if I am misunderstanding, but there i= s a RISC profile event 
     
    "http://schemas.openid.net/secevent/risc/event-=
type/a=
ccount-credential-change-required=E2=80=9D
     
    and an SCIM p= rofile event
     
    I'm sugg= esting that two different events would be sent. Embedding one in the other d= oes not make sense.
    <ph>It is a hypothetical example. Just because you disagree on this= does not mean others are not valid. 
    =  
    I just picked overlapping prop= osals that have different meaning (but not the same) to illustrate the diffe= rence from issuing a single set with different events. 
     

    As I have stated this is very different from asserting multiple dist= inct events in one SET. 

     
    Also, I think it is simpler to have event_= type be at the same level as event
     

     
    {=
    &n= bsp; "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     = ; "iat": 1458496025,
      "iss": "https://scim.example.com",<= /span>
      "aud": [
      &= nbsp;],
      &= nbsp;"event": {  
            &nbs= p;"id":"44f6142df96bd6ab61e7521d9",
        &nb= sp;    "resetAttempts":5
          &n= bsp;}
    }
    &nbs= p;
    {
      "jti": "3d0c3cf797584bd193bd0fb1bd4= e7d30",
      "iat": 1458496025,
    &= nbsp; "iss": "https://scim.example.com",
      "aud": [=
       ],
       "event": {
          &= nbsp;=E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
           =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/= "       
    <= span style=3D"font-family:'Courier New',serif">       }<= /span>
    }
    &nbs= p;
     
     
     
     
    On M= on, Oct 30, 2017 at 12:09 PM, Phil Hunt <phil.hunt@oracle.com> wrote:<= /u>
    Annabelle/Dick,
     
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif">Thanks for the comments. I think we need to examine the consequences= of the proposal in JSON.
     
    As I stated, what causes most of the issue is t= he proposed extension mechanism in the payload (possibly using events in a r= ecursive way). Does it follow the old format or the new?
    =
     
    Let=E2=80=99s &nb= sp;consider a use case where we have an identity management system that uses= SCIM, but the SCIM system is also the underlying data store for Connect.&nb= sp; A Password reset might generate the following event which has an extensi= on (conveying reset count) AND overlapping statement from RISC.  BOTH o= f which might be important to a similar receiver using SCIM and OIDC.  =
     
    The 03 spec currently would allow:
     
    {
      "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
      "iat": 1458496025,
      "iss": "https://scim.example.com",
      "=
aud": [
        "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
        "https://jh=
ub.example.com/Feeds/5d7604516b1d08641d7676ee7"
    = 
       ],
       "events"=
: {
         "urn:ietf:params:s=
cim:event:passwordReset":
      &nbs=
p;    { "id":"44f6142df96bd6ab61e7521d9"},=

         "https://example.com/s=
cim/event/passwordResetExt":
     &nb=
sp;     { "resetAttempts":5},
         "http://schemas.op=
enid.net/secevent/risc/event-type/\
           a=
ccount-credential-change-required": {
           =
  =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,=

       &nbs=
p;     =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/"
           }=

      }=

    }=

     
    In the above - each payload is a =E2=80=98peer'=
 and issued without preference by the transmitter. The receiver can assign p=
riority in its own context if that matters.
    <= pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courier New= ',serif"> 
    The new proposal:
     
    {<=
/pre>
      "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",=

      "iat": 1458496025,
    https://scim.example.com",
      "=
aud": [
        "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
        "https://jh=
ub.example.com/Feeds/5d7604516b1d08641d7676ee7"
    =

       ],
       "event":=
 {
         =E2=80=9Cevent_type=
=E2=80=9D:"urn:ietf:params:scim:event:passwordReset=E2=80=9D,=

         "id":=E2=80=9D44f6142df96bd6ab6=
1e7521d9=E2=80=9D,
        =
; =E2=80=9Cevents=E2=80=9D:{
       =
  ->note =E2=80=A6is this the old or new structure? <-<=
/u>
           "https:=
//example.com/scim/event/passwordResetExt":
             { "resetAttempts":5},=

      &nb=
sp;    "http://schemas.openid.net/secevent/risc/event-type=
/\
             account-credential-change-r=
equired": {
             =E2=80=9Csub=E2=80=9D=
:=E2=80=9D7375626A656374=E2=80=9D,
             =E2=
=80=9Ciss=E2=80=9D:"https://idp.example.com=
/"
    &n=
bsp;      }
         }<=
/pre>
       } &nb=
sp;  
    }
     
    In the above, sub-events or extens=
ions have a different format. The same complaint about the original stands.<=
/span>
     
    <=
span style=3D"font-family:Helvetica,sans-serif">*OR* (if the receiver cares a=
bout RISC more).  Note that this leads to a triple nested structure.
     
    {
      "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
      "iat": 1458496025,<=
/pre>
      "iss": "https://scim.example.com",
      "aud": [
        "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754=
",
        "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"<=
u>
       ],
     &nb=
sp; "event": {
         =E2=80=9C=
event_type=E2=80=9D:"http://schemas.ope=
nid.net/secevent/risc/event-type/\
            &nbs=
p;    account-credential-change-required=E2=80=9D,
          =E2=80=9Csub=E2=80=9D=
:=E2=80=9D7375626A656374=E2=80=9D,
          =E2=80=9Ciss=E2=80=9D=
:"https://idp.example.com/=E2=80=9C=
,
    &nb=
sp;     =E2=80=9Cevents=E2=80=9D:{<=
/pre>
         =
   "urn:ietf:params:scim:event:passwordReset":<=
u>
        =
;    { 
      =
        "id":=E2=80=9D44f6142df96bd6ab61e=
7521d9=E2=80=9D,
        &=
nbsp;     =E2=80=9Cevents=E2=80=9D:{
    =

               =
  "https://example.com/scim/event/passwordResetExt":
           &=
nbsp;       { "resetAttempts":5},  
              =
;}      
          }     
       }
    }
        "https://jhub.example.com/Feeds/98d52461fa5bbc879593=
b7754",
        "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"=

       ],
    &nbs=
p;  "event": {
         =E2=
=80=9Cevent_type=E2=80=9D:"http://schemas.o<=
wbr>penid.net/secevent/risc/event-type/\
    =

                 acc=
ount-credential-change-required=E2=80=9D=
,
     =
;     =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=
=9D,
          =E2=80=
=9Ciss=E2=80=9D:"https://idp.example.com/=
=E2=80=9C,
          =E2=80=9Cevent=E2=80=9D:{=

       &nbs=
p;    =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim=
:event:passwordReset=E2=80=9D,
            "id"=
:=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
            =E2=80=9Cevent=E2=80=9D:{<=
/u>
            &n=
bsp; =E2=80=9Cevent_type=E2=80=9D:"https://example.com/sci=
m/event/passwordResetExt=E2=80=9D,
    &nb=
sp;         "resetAttempts":5 
     &=
nbsp;      }
       }
    }
     
    This format follows the proposed singular event fo=
rmat recursively and is 3 layers deep. Note that the parser has to continue t=
o search the document for things that aren=E2=80=99t there as it has to stop=
 when no =E2=80=9Cevent=E2=80=9D attribute is found rather than iterate over=
 an array.
     
    Phil

    Oracle Corporation, Identity Cloud Servic= es Architect
    @independentid
    www.independentid.com
    phil.hunt@oracle.com
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif"> 
    On Oct 30, 2017, at 8= :57 AM, Richard Backman, Annabelle <richanna@amazon.com> wrote:<= /u>
     
    Replies inline.
     
    -- 
    Anna= belle Richard Backman
    Identity Services
     
     
    From: Phil Hunt <phil.hunt@oracle.com>Date: Sunday, October 29, 2017 at 5:25 PM
    <= b>To:     Dick Hardt <dick.ha= rdt@gmail.com>
    Cc: Yaron Sheff= er <yaronf.ietf@gmail.com>, Mike Jon= es <Michael.Jones@microsoft.com&g= t;, "Richard Backman, Annabelle" <richanna@amazon.com= >, ID Events Mailing List <id-event@ietf= .org>
    Subject: Re: [Id-event] U= se cases for multiple events per SET?
    =
     
    I hope this answers your quest= ion.
     
    My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reason why n= ot. The question should be, what is the justification to make =E2=80=9Cevent= s=E2=80=9D singular?
    [richanna]The singular =E2=80=9C= event=E2=80=9D claim has clearer semantics and is easier to process. We shou= ld opt for easier solutions unless there are use cases that require more com= plexity.[/richanna]
     
    There are many reasons for multiple events in a S= ET.  Some are good, some not so good. Some of the reasons...<= /u>
     =
    1.  M= ultiple event payloads expressing statements about largely the *same*thing. = For example, SCIM password reset AND RISC password reset.  A RISC Event= and an OpenBanking Event. Is one a complement to the other?  Do they o= verlap or are they distinct?  
    [richanna]Copy/p= asted from my earlier email:
    Why is it necess= ary or appropriate to include these events in the same SET? They are likely b= eing generated by different systems at different times on the transmitter=E2= =80=99s side, consumed by different systems on the receiver=E2=80=99s side, a= nd possibly being transmitted over different event streams. I know the latte= r would be the case for us, as a receiver. Even if it=E2=80=99s not, is it b= urdensome to send these events separately? What value is gained in combining= them?
    =  
    = Additionally, since the signature is over the SET and not the event objects,= Receivers independently route separate events from a single token without e= ither losing the ability to verify the authenticity of the event or sharing a= ll information in the SET with every system handling any event in the token.= [/richanna]
     
    =

    2.  Multi= ple events payloads expressing different statements about the same transacti= on - RISC Password Reset and RISC Session Cancel
    [richanna]Same as above[/richanna]

    3.  A new profile de= fines new event attributes to be added on to an existing event type (a pure e= xtension) 
    [richanna]I have su= ggested a way to support extensions within an event body, multiple times now= . If you see problems with it, please point them out.[/richanna]
     <= u>
    I t= hink it is quite valid to allow 1 and 3.  2 could be limited by specifi= c profiles like RISC if they want.
    =
     
    <= div>
    I am not in agreement that making event s= ingular simplifies anything. For one is makes extensions complex (another ne= sted JSON structure) and potentially conflicting. 
    [richanna]
    Ways that mul= tiple-event SETs are more complicated:
    1. It results in a more complex struct= ure for the single event use case, which I think we all agree is the majorit= y use case.
    2. Multiple-event SETs have ambiguous semantics. The prese= nce of two events A and B in the same SET could mean any of:
      1. They are related to the same logical event (= i.e. the same thing as if they were from different SETs that have a common t= xn).
      2. A is an extension of B.
      3. B is an extension of A.
      4. They are aliases for one another.
      5. They are not actually related= to one another in any way.
    1. Claim semantics become harder to define, as differ= ent profiles may want to use the same claims in different ways.
     <= /u>
    If the WG wan= ts to block 1 and 2 above, then I believe we have to establish an event regi= stry to ensure new Event profiles do not overlap to eliminate the need to ex= press multiple events.
    [richanna]I=E2=80=99= m not sure what you mean by this. Are you referring to event names? Those ar= e already defined by the spec to be URIs.[/richanna]
    <= div>
    Phil<= u>
    &nb= sp;
    Oracle Corporation, Identity Cloud Services Architect
    @independentid=
     
    Phil:
    =  
    In= your examples for having a plurality of events, you use the word "may", whi= ch leads me to question if a plurality of events is really required in SET.<= /span>
     
    You posit t= hat it will be difficult for a distributed system to correlate multiple SETs= with the same "txn", but the distributed system will certainly need to corr= elate events on the same subject -- correlating events on the same "txn" on t= he same subject seems fairly simple.
    <= div>
     
    I think that a receiver will need to correlate mul= tiple SEts on the same subject, so having multiple events in a SET is redund= ant, and adds complexity with no clear benefit that I can see.=
     
    An implementor may choos= e to send multiple SETs, or send a single SET with multiple events, so a rec= eiver will need to support both. I prefer we pick one way and minimize the c= ode paths, and we will need to support correlating across multiple SETs, so t= hat seems the best mechanism.
     
    =
    Let me know if there is something I missed in my logic.
     
    = /Dick<= u>
     =
     
    On Sun, Oct 29, 2017= at 11:28 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
    I= n that case, let's add text to that effect, e.g. we could add to the definit= ion of the "events" claim:

    Profiling specifications SHOULD define the= allowed event statements, and MAY restrict their number. For example, some p= rofiles may require this claim to contain only a single event statement.
    =
    Thanks,
            Yaron
    On 24/10/17 22:10, Mike Jones wrote:

    I agree with much of Phil=E2=80= =99s rationale here.

    It=E2=80=99s fine for some profiles to say that t= he =E2=80=9Cevents=E2=80=9D set must be a singleton.  That doesn=E2=80=99= t have to be true for all events.  I think things are fine as-is.
                &n= bsp;            =             = ;            &nb= sp;           &n= bsp;   -- Mike

    *From:* Id-event [mail= to:id-event-bounces@ietf.org] *On= Behalf Of *Phil Hunt
    *Sent:* Monday, October 23, 2017 8:47 PM
    *To:* R= ichard Backman, Annabelle <richanna@amazon.com= >
    *Cc:* ID Events Mailing List <id-event@iet= f.org>
    *Subject:* Re: [Id-event] Use cases for multiple eve= nts per SET?

    Annabelle,

    I have a number of concerns with this p= roposal.

    Profiling Independence / Keeping Event Payloads Independent<= br>
    Indicating that extensions should be handled by profiles leads to mor= e inter-operability issues and more importantly intrudes on the Event payloa= d space by suggesting a sub-schema creates potential limitations and conflic= ts that may add to complexity later on. The current format allows a parser t= o discover and unload one or more JSON payloads which can each have independ= ent structure.

    General extensions

    The proposal also rules out g= eneral purpose extensions not related to any specific event. Given the emerg= ence of items like GPRD, I would not want to block the ability to add meta-d= ata or other general purpose items. We can also anticipate some delivery sce= narios where additional data might be required. Even though there is no curr= ent planned use, I see no good reason to rule this out.

    Multiple Even= ts =46rom Different Families (vs. Multiple Events from a single family like R= ISC)

    In our RISC session we discussed expressing multiple distinct RI= SC events in one SET. The discussion was that only one RISC event at a time.= We did not discuss other event profiles. I don=E2=80=99t see a reason to ru= le out multi-events from different families at the SET level. Each profile i= s expressing slightly different things about the same event.

    I can fo= rsee some cases where it is not clear which is the primary and which is the e= xtension.  There may not be a clear winner.

    A couple of examples= (these are necessarily real=E2=80=A6just possibilities):

    * It is pro= bably useful to be able to express simlar/overlapping events from different S= ET profiles in one SET.  For example a Backchannel Logout & a RISC s= ession cancel event.

    * SCIM may want to represent a single transactio= n as causing multiple state changes in an event (e.g. a password change caus= es multiple effects). Having to chase down multiple events and correlate by =E2= =80=9Ctxn=E2=80=9D would be challenging in a multi-threaded/multi-node deliv= ery system.   The SCIM list has not discussed this, but I would no= t want to block this capability.  IOW - Just because RISC does not want= to express multiple events does not make this true for other profiles.
    <= br>* We may wish to indicate a SCIM Password Reset was performed and a Logou= t/session cancellation is expressed at the same time.  The events are r= elated but express different data.

    Avoiding Confusion =46rom Similar E= vents Originating from the Same Transaction

    If events are sent separa= tely, then more tracking of state (e.g. by txn) would be required to ensure s= imilar events are not mistaken or handled as repeats. While txn provides use= ful audit analysis capability, I=E2=80=99m not sure it can be used in live o= r near-real time systems given distributed multi-node, multi-threading archi= tectures.

    Previous Discussion

    I note that I originally raised h= aving an attribute to designate primary event attribute to alleviate your co= ncern, but this was not accepted. See:

    * https://www.ietf.org/mail-archive/w= eb/id-event/current/msg00406.html

    * https://www.ietf.org/mail-archive/web/id-event/current/msg00140.html

    The conse= nsus, at least as I interpreted it is up to the receiver to figure this out b= ased on the definitions it has for each event URI and the profiles they repr= esent. IOW - RISC is free to limit that only one RISC event be expressed at a= time.

    Phil

    Oracle Corporation, Identity Cloud Services Archit= ect

    @independentid

    www.independentid.com&nbs= p;<http://www.independentid.com>

    phil.hunt@oracle.com <mailto= :phil.hunt@oracle.com>

     =   On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle
      &n= bsp; <richanna@amazon.com = <mailto:richanna@amazon.com>= ;> wrote:

        The current draft of the SET spec allows f= or expressing multiple
        events within the same token, which i= ntroduces additional complexity
        and room for ambiguous sema= ntics. We=E2=80=99ve discussed this in the OIDF
        RISC workin= g group and the current consensus there is that RISC will
        r= equire that RISC events must be the only event in the SET, having
      &= nbsp; identified ways to clearly and easily support the handful of use
    &n= bsp;   cases for multiple events per token that people have raised. Wit= h
        that context in mind, I propose striking the definition o= f the
        =E2=80=9Cevents=E2=80=9D claim from the Security Even= t Token spec, and replacing it
        with the following definitio= n for an =E2=80=9Cevent=E2=80=9D claim (singular):

        even= t

        A JSON object containing an "event_type" member whose= value is a URI
        representing a type of event defined in a P= rofiling Specification.
        The object MAY otherwise be empty, o= r MAY contain additional members
        as described by the Profil= ing Specification.

        Here is the example SET from section= 2.3, rewritten with this change
        mind:

       =  {

           "jti": "4d3559ec6= 7504aaba65d40b0363faad8",

           "iat": 1458= 496404,

          "iss": "https:/= /scim.example.com <h= ttps://scim.example.com/>",

         &n= bsp; "aud": [

             "https://scim.example.com/Feeds/98d5= 2461fa5bbc879593b7754",

           &n= bsp; "https://scim.e= xample.com/Feeds/5d7604516b1d08641d7676ee7"

      &n= bsp;    ],

           "event": {

    &nb= sp;        "event_type": "urn:ietf:params:scim:even= t:create",

             "ref": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",

          = ;   "attributes": ["id", "name", "userName", "password", "emails"]=

           }

        }

      &n= bsp; Does anyone in the working group have use cases for SETs that cannot    be met by this proposed text? Within RISC, we identified thre= e use
        cases, with solutions outlined below:

      &= nbsp; **

        *Extensions*

        Event extens= ion mechanisms can be defined internal to the event
        object.= A simple approach would be to  define an =E2=80=9Cextensions=E2=80=9D m= ember
        that is a list of event objects (or set resembling th= e =E2=80=9Cevents=E2=80=9D
        claim as defined in the current s= pec). This has the advantage of
        making it clear in the data= structure that there is a single primary
        event, with zero o= r more extensions. There is no room for confusion
        over whic= h event is primary, or if there is a primary event at all.
        I= would be fine with adding something like this to my proposed text,
     = ;   if there is consensus that it is broadly useful.

      &nbs= p; *Aliases*

        This use case was brought up in the contex= t of migrating clients
        from draft event names to standardiz= ed event names. In this case,
        the event transmitter can tra= nsmit two tokens for the logical event,
        one using the old n= ame and another using the new name.

        *Related Events*
        The SET spec defines the txn claim as a means of correlat= ing
        independent tokens that relate to the same logical even= t.

        -- 
        Annabelle= Richard Backman

        Amazon =E2=80=93 Identity Services
    =
        _______________________________________________
    &n= bsp;   Id-event mailing list
        Id-event@ietf.org <mailto= :Id-event@ietf.org>
            https://urldefense.proofpoint.com/v= 2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d= =3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&= r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Ds5byBe5KAN= nGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=3DX8oRSq3IzlF7jiRAeZhXpR3e= VI0I58ZFd4eEZfgyoIY&e=3D



    _____________________= __________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailm= an/listinfo/id-event


    _____________________________________________= __
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event<= /span>


    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif;background-color:white"> 
    -- 
    Subscribe to the&nbs= p;= HARDTWARE mail list to learn about projects= I am working on!
     =
    _________________________= ______________________
    Id-event mailing l= ist
    Id-event@ietf.org
     

    <= br clear=3D"all">
     
    --
    Subscribe to the HARD= TWARE mail list to learn about projects I am working on!=


     
    --<= /div>
    Subscribe to the HARDTWARE mail li= st to learn about projects I am working on!
    <= /div>


     
    --
    =
    Subscribe to the HARDTWARE mail list to learn about projects I am wor= king on!


     
    -- 
    Subs= cribe to the HARDTWARE=  mail list to learn about projects I am working on!
    _______________= ________________________________
    Id-event m= ailing list
    Id-event@ietf.org<= br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-vari= ant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;te= xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgr= ound-color:rgb(255,255,255)">https://urldefense.proofpoint.com/v2/= url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3D= DwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D= na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZk= tcmagv5Ea21QEip4HXpEVKRa0qhlo&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuK= aXEbT5wu9rcORV0&e=3D


    _______________________= ________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinf= o/id-event



    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    htt= ps://www.ietf.org/mailman/listinfo/id-event


    = --Apple-Mail-D8B4B242-FE96-4A37-9264-48287C46CB37-- From nobody Wed Nov 1 15:01:35 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372AE13F6A5 for ; Wed, 1 Nov 2017 15:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 6UN-Uu6zslCi for ; Wed, 1 Nov 2017 15:01:26 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E52313F6AC for ; Wed, 1 Nov 2017 15:01:23 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id i198so3105100ywe.7 for ; Wed, 01 Nov 2017 15:01:23 -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=bEHc3lP8atEpAK6t8M3nQHftkNfk/v2SylNrpSrohDg=; b=sX0IUZjO+v0hh799fRmRVhBw54uGWbNBIcGEgzhMnK5bUcETpnTYbxGGo41M6sRPlJ xHp78+C8NYNaMpck/qZXhndXVScCVqupNlhkUj7kMasR1h5v9+Q8ePt6M0THVfG/Gvnq nX0PviT50jDfe6n1aQf7uP99AQ0MfaEgq1YGiV1emlmuA8bsBeMCV6lYCS+8uEXY1iNh T7fCp2u6qO5hHgMmeqLebUYmSVF9g11D0qF7oqr40+Izs7/VUeyzPDSOMVZOK0fMUPLo sPrSjqhxjGtmzzuTEPT95keHvZTor88CbUis/I+tEMDI1Pt13z09JI/YqiFAc8EtHZka IUOQ== 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=bEHc3lP8atEpAK6t8M3nQHftkNfk/v2SylNrpSrohDg=; b=aeichdmRbZpBl39Pq1CSHgeqHoddxM3t0sa4Tnvs1vPpoS7GycJq2j/3zMQxkA2isT 46MoU8pbFd/oHRPEHEdR/RPhrkG9YL1aTcWpMHi8PnSRULCEgYxP15eGhdJK9fhLkuvE ukHcqJCxh7a5oGGjGAjEj5F4f8lw6DrbWnd3xf/15sLM7Ou4szKUqTIIeV3/rcCvT6G+ n+S0M+513BvVXL11jqWcKshJc1xMCrZIkZVp1+ffBM5urPuuSpbxGcZJZoqkJIOxp6HT 9DIaWuLkgNxCf/6qfBWYvxtbIz27FkzpzzFT96X0n9OcpjB6cNdTNsDTSJ4tAeM7Hy8q ie+g== X-Gm-Message-State: AMCzsaXJ2t/DpJa2JWfAXttMhapAgNsSq0TwWl/DuWmUBOlVXQkLZ77t fflk8ABEO+ueQxE/E/B6DhvP4sgyu3HC073IwjNQJQ== X-Google-Smtp-Source: ABhQp+ShVELeestUrY6sHmsKKPMueBDdFrnILrzb9KRnSnEBHyxgogsqGePp6hTkhBPOBQCp3iElrpW4vHtZUsP1854= X-Received: by 10.129.137.2 with SMTP id z2mr883316ywf.159.1509573681326; Wed, 01 Nov 2017 15:01:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.122.72 with HTTP; Wed, 1 Nov 2017 15:00:59 -0700 (PDT) In-Reply-To: References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> From: William Denniss Date: Wed, 1 Nov 2017 15:00:59 -0700 Message-ID: To: Marius Scurtescu Cc: Phil Hunt , Yaron Sheffer , "Richard Backman, Annabelle" , Dick Hardt , Mike Jones , ID Events Mailing List Content-Type: multipart/alternative; boundary="001a114885820a7284055cf30366" Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 22:01:33 -0000 --001a114885820a7284055cf30366 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The receiver probably knows which version they want, but does the sender? Using the email analogy, you may have configured your email client to accept plain text only. Fortunately, my client sends both =E2=80=93 not kno= wing what you prefer =E2=80=93 and you are able to view my message. I think it would help if we broke this problem down into two parts. 1/ Are multi-format SETs desirable? That's been the design since the earliest version. 2/ What is the best representation of the SET based on what we decide for #1. My understanding was that the "events" plural (related to #2, the best representation of a SET) *was* in fact a concern, as people may skip the text and look directly at the JSON syntax, then jump to conclusions. On Wed, Nov 1, 2017 at 2:54 PM, Marius Scurtescu wrote: > On Wed, Nov 1, 2017 at 2:46 PM, William Denniss > wrote: > >> Perhaps I can try and explain the original intent of the current design. >> The goal was always that a SET represents a single logical event. Howeve= r >> multiple systems may have different representations of the event =E2=80= =93 the >> example given originally was one formatted for RISC, and one for SCIM. >> >> A good analogy is email. You send a single logical email, which may have >> two representations, HTML and plain text. Systems can consume the versio= n >> that they understand and ignore the one they don't. >> > > Yes, and I think this is well understood. > > > >> >> I'm starting to regret the plural in "events", it was pluralized due to >> it being an array, not because it represented multiple logical events. >> > > I don't think this is the main concern or cause for confusion. > > > >> >> Annabelle, I understand your concerns regarding confusion of the >> semantics between the JSON syntax and the specification language. Are th= ere >> other ways to resolve that without removing the ability for multiple >> representations of the same event? >> > > The argument is that multiple representations can be sent as distinct > SETs, if really needed. In practice this will happen quite rare though. > Events are created for a specific receiver, the receiver either wants the > SCIM or the RISC flavor, and they should be able to specify that in > configuration (there is a proposal how to capture that). > > Do we have a compelling use case where a receiver must receive multiple > variants all at once? > > > >> >> On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu >> wrote: >> >>> On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt wrote= : >>> >>>> You can=E2=80=99t really have multiple events (at least of the same ty= pe). The >>>> current spec can only have one instance of a URI (afaik). >>>> >>>> Note that the spec normatively does not support multiple event SETS. >>>> It currently states: >>>> >>>> events >>>> *The semantics of this claim is to define a set of event stateme= nts >>>> that each MAY add additional claims to fully describe a single >>>> logical event* that has occurred (e.g. a state change to a >>>> subject). Multiple event statements of the same type SHALL NOT = be >>>> accepted. The "events" claim SHOULD NOT be used to express >>>> multiple logical events. >>>> >>>> >>>> The spec has *always* supported requirements (as stated in the spec) >>>> for multiple separate profile statements (from one or more profile >>>> familities) needing to be sent as a single message. It would be INSEC= URE >>>> to force multiple SETs because the current delivery mechanism only all= ows >>>> one SET to be delivered at a time. There is no way to assure that a si= ngle >>>> receiver gets all of the SETs it needs in a multi-threaded, multi-node >>>> environment at scale. Assembling multiple SETs to track =E2=80=9Ctxn= =E2=80=9D in a common >>>> state database is NOT simple nor cost effective. >>>> >>> >>> I totally agree that it is difficult for receivers to receive separate >>> events, in no particular order and correlate based on "txn". But, recei= vers >>> have to solve this issue regardless of "events" or "event", so it is >>> unrelated to this proposal. >>> >>> >>> >>>> >>>> If we accommodate this in the proposed form, we end up with a complex, >>>> deeply nested JSON structure with the possibility of namespace conflic= ts. >>>> >>>> IMO The proposal does not simplify, it complicating and limiting. >>>> >>>> The current spec has very clean JSON and avoids namespace conflicts >>>> between profiles. I think we should stay on track with the current dra= ft >>>> and observe the normative text if not make it stronger in regards to >>>> multi-events (understood that Mike may disagree). >>>> >>>> Phil >>>> >>>> Oracle Corporation, Identity Cloud Services Architect >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> On Nov 1, 2017, at 12:18 PM, Richard Backman, Annabelle < >>>> richanna@amazon.com> wrote: >>>> >>>> Unless the profile guarantees that such related events will always be >>>> included in the same SET, then the receiver has to correlate across SE= Ts >>>> anyway, and multiple events per SET is just giving the receiver anothe= r >>>> scenario that they have to support. >>>> >>>> I=E2=80=99ve already provided several other reasons why we should not = support >>>> multiple tokens per SET that no one has addressed. Here they are again= : >>>> >>>> 1. Multiple event support results in a more complex structure for >>>> the single event use case, which I think we all agree is the majori= ty use >>>> case. >>>> 2. Multiple-event SETs have ambiguous semantics. The presence of >>>> two events A and B in the same SET could mean any of: >>>> 1. A and B are related to the same logical event (i.e. the same >>>> thing as if they were from different SETs that have a common txn= ). >>>> 2. A is an extension of B. >>>> 3. B is an extension of A. >>>> 4. A is an alias for B, or vice-versa. >>>> 5. A and B are not actually related to one another in any way, >>>> and the transmitter bundled them together because they were goin= g to the >>>> same receiver. >>>> 3. Top-level claim semantics become harder to define, as different >>>> profiles may want to use the same claims in different ways. >>>> 4. Event authenticity cannot be verified without having the entire >>>> SET. This forces receivers to expose downstream systems to more inf= ormation >>>> necessary, if those systems need to be able to verify authenticity. >>>> >>>> >>>> -- >>>> Annabelle Richard Backman >>>> Amazon =E2=80=93 Identity Services >>>> >>>> >>>> *From: *Mike Jones >>>> *Date: *Wednesday, November 1, 2017 at 11:21 AM >>>> *To: *Dick Hardt >>>> *Cc: *Yaron Sheffer , "Richard Backman, >>>> Annabelle" , ID Events Mailing List < >>>> id-event@ietf.org>, "Phil Hunt (IDM)" >>>> *Subject: *RE: [Id-event] Use cases for multiple events per SET? >>>> >>>> I completely agree on moving complexity to the issuer over the >>>> recipient. In my view, it=E2=80=99s more complex for recipients to ha= ve to >>>> correlate and process a sequence of multiple SETs providing informatio= n >>>> about the same logical event, and validate N signatures, than to recei= ve >>>> one SET with all the aspects of the logical event as =E2=80=9Cevents= =E2=80=9D fields, with >>>> no correlation over time then required. >>>> >>>> -- Mike >>>> >>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com = ] >>>> >>>> *Sent:* Wednesday, November 1, 2017 9:39 AM >>>> *To:* Mike Jones >>>> *Cc:* Yaron Sheffer ; Richard Backman, >>>> Annabelle ; ID Events Mailing List < >>>> id-event@ietf.org>; Phil Hunt (IDM) >>>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>>> >>>> Your comments highlight a couple of points: >>>> >>>> 1) The example is how to have a predefined extension point for >>>> extensions of a specific event, it is not how to add another event. My= self, >>>> I think this is overly complicated. Events should be comparatively sta= tic, >>>> and as with many other JSON formats, the receiver should ignore proper= ties >>>> it does not understand, which let's new properties be introduced as >>>> extensions. There should not be any conflict as extensions should only= be >>>> done by the profile that created the event format to start off with. >>>> >>>> 2) Having an lvalue be a URI is much harder to code against. I'm not >>>> sure why Marius had that in his example. Per the event, the type of th= e >>>> event is well defined with >>>> >>>> "event_type": "https://example.com/scim/event/passwordResetExt", >>>> >>>> 3) This thread is about reasons for multiple events to be contained in >>>> one set. Your mention of an issuer not wanting to sign separate events= as a >>>> reason to allow multiple events. I think we have decided that given a >>>> preference, we will push effort to the transmitter over the receiver a= s in >>>> many use cases there are many more receivers. Given that, it is more >>>> complex for a receiver to have different ways of managing the receipt = of >>>> multiple events as not all issuers will bundle the events, so it is si= mpler >>>> to have only one event per SET. Including the separate events with a U= RI as >>>> an lvalue is challenging to implement, speaking from experience. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones < >>>> Michael.Jones@microsoft.com> wrote: >>>> >>>> Marius=E2=80=99 proposed syntax, pasted in below, has exactly this >>>> characteristic. The way I see it, his proposal essentially has a prim= ary >>>> passwordReset event and a secondary passwordResetExt data structure, w= hich >>>> could have been simply another event value in the current draft. >>>> >>>> This breaking change makes the data structures more complicated - not >>>> less. And it makes things that used to be possible impossible, reduci= ng >>>> flexibility to those who would use the spec. >>>> >>>> These seem like bad tradeoffs to me. >>>> >>>> { >>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>> "iat": 1458496025, >>>> "iss": "https://scim.example.com", >>>> "aud": [ >>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>> ], >>>> "event_type": "https://example.com/scim/event/passwordResetExt", >>>> "event": { >>>> "id":"44f6142df96bd6ab61e7521d9", >>>> "extensions": { >>>> "https://example.com/scim/event/passwordResetExt=E2=80=9D: = { >>>> "resetAttempts":5, >>>> } >>>> } >>>> } >>>> } >>>> >>>> In particular, it makes it impossible to sign multiple related events >>>> sharing a common claims schema with a single signature by the issuer. = It >>>> forces the issuer to do the extra work of signing each of the related >>>> events (or facets of the same logical event) individually and forces t= he >>>> recipients to do the extra work of checking all those unnecessary >>>> signatures. >>>> >>>> Not every profile will ever have multiple keys in the =E2=80=9Cevents= =E2=80=9D set but >>>> there=E2=80=99s absolutely no reason to preclude it. >>>> >>>> -- Mike >>>> >>>> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Dic= k >>>> Hardt >>>> *Sent:* Tuesday, October 31, 2017 9:52 PM >>>> *To:* Mike Jones >>>> *Cc:* Yaron Sheffer ; Richard Backman, >>>> Annabelle ; ID Events Mailing List < >>>> id-event@ietf.org>; Phil Hunt (IDM) >>>> >>>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>>> >>>> Please direct me to a proposal that has a "primary" and "secondary" >>>> events. I agree that is undesirable. I would also encourage to engage = in >>>> the discussions so that we can drive clarity and simplicity. >>>> >>>> I think the proposal is that there is one event per SET. >>>> >>>> I think having more than one event per SET adds complexity as a >>>> receiver must deal with receiving correlated events in one SET as well= as >>>> correlated events in the same SET. >>>> >>>> /Dick >>>> >>>> On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones < >>>> Michael.Jones@microsoft.com> wrote: >>>> >>>> I hear you on the fact that different people have joined the effort at >>>> different times. That=E2=80=99s a normal process as an effort builds = momentum. I >>>> get that not everyone was there when previous consensus calls were tak= en. >>>> >>>> I should note that I have specific technical objections to the specifi= c >>>> proposed changes being discussed as well. Currently all events in the= set >>>> have the same syntax. The proposals, as I understand them, revert us = to a >>>> state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and =E2=80=9Cs= econdary=E2=80=9D events, with different >>>> syntax for the two classes. That=E2=80=99s needlessly more complicate= d, adding no >>>> actual value. >>>> >>>> -- Mik= e >>>> >>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>>> *Sent:* Tuesday, October 31, 2017 9:37 PM >>>> *To:* Mike Jones >>>> *Cc:* Phil Hunt (IDM) ; Yaron Sheffer < >>>> yaronf.ietf@gmail.com>; Richard Backman, Annabelle ; >>>> ID Events Mailing List >>>> >>>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>>> >>>> Mike >>>> >>>> As you well know, many people in a WG don't look closely at a >>>> specification until last call is made. Additionally, we are coming up = on >>>> only the 3rd WG meeting. The WG has not existed for very long. While s= ome >>>> of the participants have been working on this for a while, many have n= ot, >>>> and we are looking for consensus across the WG. >>>> >>>> Since SecEvent is a framework that we expect to be profiled, I feel it >>>> is important to ensure that SecEvent specifications are easy for a var= iety >>>> of profiles to adopt, and that the semantics make sense. I also think = that >>>> properties that are specific to a profile should be left to that profi= le >>>> and not be included in SecEvent. >>>> >>>> Since this is a framework, it is expected that as different groups >>>> profile it, there will be additional feedback. >>>> >>>> Specifically, as a participant in the RISC profile of SET, a number of >>>> issues in SET have surfaced as the RISC WG has looked at how to use th= e SET. >>>> >>>> As for SET being stable for over a year, there have been a number of >>>> changes to SET since then. I also don't think there was consensus. Bef= ore >>>> the WG was formed, I and several others had expressed concern on the d= esign >>>> of SET when Phil presented it at an IIW session. >>>> >>>> As to taking another year, I am hopeful we can resolve the remaining >>>> issues in SET and publish a new draft for last call. I do not think we= will >>>> need to wait for another WG meeting to ask for last call. >>>> >>>> We also have a number of other documents that are not in last call, an= d >>>> we don't have a WG adopted draft yet for management. So there are stil= l a >>>> number of documents to work through before we have all the bits for so= meone >>>> to work with. >>>> >>>> I do think we have been making good progress since the last IETF >>>> meeting, and I am hopeful we can keep up this momentum and finalize al= l the >>>> documents in a timely manner. >>>> >>>> /Dick >>>> >>>> >>>> On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones < >>>> Michael.Jones@microsoft.com> wrote: >>>> >>>> It=E2=80=99s hard for me to even express my level of frustration with = the >>>> recent attempts to once again redesign the SecEvent Token spec. We=E2= =80=99ve been >>>> at this for multiple years because people keep trying to revisit decis= ions >>>> that were long ago made by consensus. It=E2=80=99s been stable for ov= er a year and >>>> the majority of WGLC respondents said some variant of =E2=80=9CWorks f= or me =E2=80=93 ship >>>> it!=E2=80=9D >>>> >>>> There=E2=80=99s not sufficient justification to try to undo consensus = positions >>>> that have been debated and affirmed over and over. Countenancing whol= esale >>>> changes at this late date is counterproductive in the extreme! >>>> >>>> It=E2=80=99s far better than good enough as-is. In my experience, if = we start >>>> redesigning it, it will result in another year=E2=80=99s delay. It do= es something >>>> simple and useful. Please, let=E2=80=99s just ship it, so people can = rely on it. >>>> >>>> -- Mike >>>> >>>> *From:* Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] >>>> *Sent:* Monday, October 30, 2017 2:42 PM >>>> *To:* Dick Hardt >>>> *Cc:* Yaron Sheffer ; Richard Backman, >>>> Annabelle ; Mike Jones < >>>> Michael.Jones@microsoft.com>; ID Events Mailing List >>> > >>>> >>>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>>> >>>> Inline... >>>> >>>> Phil >>>> >>>> >>>> On Oct 30, 2017, at 2:22 PM, Dick Hardt wrote: >>>> >>>> Hi Phil >>>> >>>> Correct me if I am misunderstanding, but there is a RISC profile event >>>> >>>> >>>> >>>> "http://schemas.openid.net/secevent/risc/event-type/ ac= count-credential-change-required=E2=80=9D >>>> >>>> >>>> >>>> and an SCIM profile event >>>> >>>> >>>> "https://example.com/scim/event/passwordResetExt=E2=80=9D >>>> >>>> >>>> >>>> I'm suggesting that two different events would be sent. Embedding one >>>> in the other does not make sense. >>>> >>>> It is a hypothetical example. Just because you disagree on this >>>> does not mean others are not valid. >>>> >>>> I just picked overlapping proposals that have different meaning (but >>>> not the same) to illustrate the difference from issuing a single set w= ith >>>> different events. >>>> >>>> >>>> As I have stated this is very different from asserting multiple >>>> distinct events in one SET. >>>> >>>> >>>> Also, I think it is simpler to have event_type be at the same level as >>>> event >>>> >>>> >>>> >>>> may be. I was working from Annabelle's proposed format. >>>> >>>> >>>> { >>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>> "iat": 1458496025, >>>> "iss": "https://scim.example.com", >>>> "aud": [ >>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>> ], >>>> "event_type": "https://example.com/scim/event/passwordResetExt", >>>> "event": { >>>> "id":"44f6142df96bd6ab61e7521d9", >>>> "resetAttempts":5 >>>> } >>>> } >>>> >>>> { >>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>> "iat": 1458496025, >>>> "iss": "https://scim.example.com", >>>> "aud": [ >>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>> ], >>>> "event_type": "http://schemas.openid.net/sec >>>> event/risc/event-type/account-credential-change-required >>>> >>>> ", >>>> "event": { >>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>>> } >>>> } >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt >>>> wrote: >>>> >>>> Annabelle/Dick, >>>> >>>> Thanks for the comments. I think we need to examine the consequences o= f >>>> the proposal in JSON. >>>> >>>> As I stated, what causes most of the issue is the proposed extension >>>> mechanism in the payload (possibly using events in a recursive way). D= oes >>>> it follow the old format or the new? >>>> >>>> Let=E2=80=99s consider a use case where we have an identity managemen= t system >>>> that uses SCIM, but the SCIM system is also the underlying data store = for >>>> Connect. A Password reset might generate the following event which ha= s an >>>> extension (conveying reset count) AND overlapping statement from RISC. >>>> BOTH of which might be important to a similar receiver using SCIM and = OIDC. >>>> >>>> >>>> *The 03 spec currently would allow:* >>>> >>>> >>>> { >>>> >>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>> >>>> "iat": 1458496025, >>>> >>>> "iss": "https://scim.example.com", >>>> >>>> "aud": [ >>>> >>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>> >>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>> >>>> ], >>>> >>>> "events": { >>>> >>>> "urn:ietf:params:scim:event:passwordReset": >>>> >>>> { "id":"44f6142df96bd6ab61e7521d9"}, >>>> >>>> "https://example.com/scim/event/passwordResetExt": >>>> >>>> { "resetAttempts":5}, >>>> >>>> "http://schemas.openid.net/secevent/risc/event-type/\ >>>> account-credential-change-required": { >>>> >>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>> >>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>>> >>>> } >>>> >>>> } >>>> >>>> } >>>> >>>> >>>> >>>> In the above - each payload is a =E2=80=98peer' and issued without pre= ference by the transmitter. The receiver can assign priority in its own con= text if that matters. >>>> >>>> >>>> >>>> *The new proposal:* >>>> >>>> >>>> >>>> { >>>> >>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>> >>>> "iat": 1458496025, >>>> >>>> "iss": "https://scim.example.com", >>>> >>>> "aud": [ >>>> >>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>> >>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>> >>>> ], >>>> >>>> "event": { >>>> >>>> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:password= Reset=E2=80=9D, >>>> >>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>> >>>> =E2=80=9Cevents=E2=80=9D:{ >>>> >>>> ->note =E2=80=A6is this the old or new structure? <- >>>> >>>> "https://example.com/scim/event/passwordResetExt": >>>> >>>> { "resetAttempts":5}, >>>> >>>> "http://schemas.openid.net/secevent/risc/event-type/\ >>>> account-credential-change-required": { >>>> >>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>> >>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>>> >>>> } >>>> >>>> } >>>> >>>> } >>>> >>>> } >>>> >>>> >>>> >>>> In the above, sub-events or extensions have a different format. The sa= me complaint about the original stands. >>>> >>>> >>>> >>>> **OR* (if the receiver cares about RISC more). Note that this leads t= o a triple nested structure.* >>>> >>>> >>>> >>>> { >>>> >>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>> >>>> "iat": 1458496025, >>>> >>>> "iss": "https://scim.example.com", >>>> >>>> "aud": [ >>>> >>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>> >>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>> >>>> ], >>>> >>>> "event": { >>>> >>>> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/= risc/event-type/\ >>>> >>>> account-credential-change-required=E2=80=9D, >>>> >>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>> >>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >>>> >>>> =E2=80=9Cevents=E2=80=9D:{ >>>> >>>> "urn:ietf:params:scim:event:passwordReset": >>>> >>>> { >>>> >>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>> >>>> =E2=80=9Cevents=E2=80=9D:{ >>>> >>>> "https://example.com/scim/event/passwordResetExt": >>>> >>>> { "resetAttempts":5}, >>>> >>>> } >>>> >>>> } >>>> >>>> } >>>> >>>> } >>>> >>>> } >>>> >>>> >>>> >>>> In the above, the extension is placed inside the event it extends. It = follows the old format (or should it follow the new?) >>>> >>>> **OR* Following the top layer pattern of singular event Note that thi= s leads to a triple nested structure.* >>>> >>>> >>>> >>>> { >>>> >>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>> >>>> "iat": 1458496025, >>>> >>>> "iss": "https://scim.example.com", >>>> >>>> "aud": [ >>>> >>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>> >>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>> >>>> ], >>>> >>>> "event": { >>>> >>>> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/= risc/event-type/\ >>>> >>>> account-credential-change-required=E2=80=9D, >>>> >>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>> >>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >>>> >>>> =E2=80=9Cevent=E2=80=9D:{ >>>> >>>> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passw= ordReset=E2=80=9D, >>>> >>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>> >>>> =E2=80=9Cevent=E2=80=9D:{ >>>> >>>> =E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/event= /passwordResetExt=E2=80=9D, >>>> >>>> "resetAttempts":5 >>>> >>>> } >>>> >>>> } >>>> >>>> } >>>> >>>> } >>>> >>>> >>>> >>>> This format follows the proposed singular event format recursively and= is 3 layers deep. Note that the parser has to continue to search the docum= ent for things that aren=E2=80=99t there as it has to stop when no =E2=80= =9Cevent=E2=80=9D attribute is found rather than iterate over an array. >>>> >>>> >>>> >>>> Phil >>>> >>>> Oracle Corporation, Identity Cloud Services Architect >>>> @independentid >>>> www.independentid.com >>>> >>>> phil.hunt@oracle.com >>>> >>>> >>>> On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle < >>>> richanna@amazon.com> wrote: >>>> >>>> Replies inline. >>>> >>>> -- >>>> Annabelle Richard Backman >>>> Identity Services >>>> >>>> >>>> *From: *Phil Hunt >>>> *Date: *Sunday, October 29, 2017 at 5:25 PM >>>> *To: *Dick Hardt >>>> *Cc: *Yaron Sheffer , Mike Jones < >>>> Michael.Jones@microsoft.com>, "Richard Backman, Annabelle" < >>>> richanna@amazon.com>, ID Events Mailing List >>>> *Subject: *Re: [Id-event] Use cases for multiple events per SET? >>>> >>>> I hope this answers your question. >>>> >>>> My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reason why = not. The question should >>>> be, what is the justification to make =E2=80=9Cevents=E2=80=9D singula= r? >>>> [richanna]The singular =E2=80=9Cevent=E2=80=9D claim has clearer seman= tics and is >>>> easier to process. We should opt for easier solutions unless there are= use >>>> cases that require more complexity.[/richanna] >>>> >>>> There are many reasons for multiple events in a SET. Some are good, >>>> some not so good. Some of the reasons... >>>> >>>> 1. Multiple event payloads expressing statements about largely the >>>> *same*thing. For example, SCIM password reset AND RISC password reset.= A >>>> RISC Event and an OpenBanking Event. Is one a complement to the other?= Do >>>> they overlap or are they distinct? >>>> [richanna]Copy/pasted from my earlier email: >>>> Why is it necessary or appropriate to include these events in the same >>>> SET? They are likely being generated by different systems at different >>>> times on the transmitter=E2=80=99s side, consumed by different systems= on the >>>> receiver=E2=80=99s side, and possibly being transmitted over different= event >>>> streams. I know the latter would be the case for us, as a receiver. Ev= en if >>>> it=E2=80=99s not, is it burdensome to send these events separately? Wh= at value is >>>> gained in combining them? >>>> >>>> Additionally, since the signature is over the SET and not the event >>>> objects, Receivers independently route separate events from a single t= oken >>>> without either losing the ability to verify the authenticity of the ev= ent >>>> or sharing all information in the SET with every system handling any e= vent >>>> in the token.[/richanna] >>>> >>>> >>>> 2. Multiple events payloads expressing different statements about the >>>> same transaction - RISC Password Reset and RISC Session Cancel >>>> [richanna]Same as above[/richanna] >>>> 3. A new profile defines new event attributes to be added on to an >>>> existing event type (a pure extension) >>>> [richanna]I have suggested a way to support extensions within an event >>>> body, multiple times now. If you see problems with it, please point th= em >>>> out.[/richanna] >>>> >>>> I think it is quite valid to allow 1 and 3. 2 could be limited by >>>> specific profiles like RISC if they want. >>>> >>>> I am not in agreement that making event singular simplifies anything. >>>> For one is makes extensions complex (another nested JSON structure) an= d >>>> potentially conflicting. >>>> [richanna] >>>> Ways that multiple-event SETs are more complicated: >>>> >>>> 1. It results in a more complex structure for the single event use >>>> case, which I think we all agree is the majority use case. >>>> 2. Multiple-event SETs have ambiguous semantics. The presence of >>>> two events A and B in the same SET could mean any of: >>>> >>>> >>>> 1. They are related to the same logical event (i.e. the same thing >>>> as if they were from different SETs that have a common txn). >>>> 2. A is an extension of B. >>>> 3. B is an extension of A. >>>> 4. They are aliases for one another. >>>> 5. They are not actually related to one another in any way. >>>> >>>> >>>> 1. Claim semantics become harder to define, as different profiles >>>> may want to use the same claims in different ways. >>>> >>>> >>>> If the WG wants to block 1 and 2 above, then I believe we have to >>>> establish an event registry to ensure new Event profiles do not overla= p to >>>> eliminate the need to express multiple events. >>>> [richanna]I=E2=80=99m not sure what you mean by this. Are you referrin= g to >>>> event names? Those are already defined by the spec to be URIs.[/richan= na] >>>> Phil >>>> >>>> Oracle Corporation, Identity Cloud Services Architect >>>> @independentid >>>> www.independentid.com >>>> >>>> phil.hunt@oracle.com >>>> >>>> >>>> On Oct 29, 2017, at 4:12 PM, Dick Hardt wrote: >>>> >>>> Phil: >>>> >>>> In your examples for having a plurality of events, you use the word >>>> "may", which leads me to question if a plurality of events is really >>>> required in SET. >>>> >>>> You posit that it will be difficult for a distributed system to >>>> correlate multiple SETs with the same "txn", but the distributed syste= m >>>> will certainly need to correlate events on the same subject -- correla= ting >>>> events on the same "txn" on the same subject seems fairly simple. >>>> >>>> I think that a receiver will need to correlate multiple SEts on the >>>> same subject, so having multiple events in a SET is redundant, and add= s >>>> complexity with no clear benefit that I can see. >>>> >>>> An implementor may choose to send multiple SETs, or send a single SET >>>> with multiple events, so a receiver will need to support both. I prefe= r we >>>> pick one way and minimize the code paths, and we will need to support >>>> correlating across multiple SETs, so that seems the best mechanism. >>>> >>>> Let me know if there is something I missed in my logic. >>>> >>>> /Dick >>>> >>>> >>>> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer >>>> wrote: >>>> >>>> In that case, let's add text to that effect, e.g. we could add to the >>>> definition of the "events" claim: >>>> >>>> Profiling specifications SHOULD define the allowed event statements, >>>> and MAY restrict their number. For example, some profiles may require = this >>>> claim to contain only a single event statement. >>>> >>>> Thanks, >>>> Yaron >>>> >>>> On 24/10/17 22:10, Mike Jones wrote: >>>> >>>> I agree with much of Phil=E2=80=99s rationale here. >>>> >>>> It=E2=80=99s fine for some profiles to say that the =E2=80=9Cevents=E2= =80=9D set must be a >>>> singleton. That doesn=E2=80=99t have to be true for all events. I th= ink things >>>> are fine as-is. >>>> >>>> -- >>>> Mike >>>> >>>> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of >>>> *Phil Hunt >>>> *Sent:* Monday, October 23, 2017 8:47 PM >>>> *To:* Richard Backman, Annabelle >>>> *Cc:* ID Events Mailing List >>>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>>> >>>> Annabelle, >>>> >>>> I have a number of concerns with this proposal. >>>> >>>> Profiling Independence / Keeping Event Payloads Independent >>>> >>>> Indicating that extensions should be handled by profiles leads to more >>>> inter-operability issues and more importantly intrudes on the Event pa= yload >>>> space by suggesting a sub-schema creates potential limitations and >>>> conflicts that may add to complexity later on. The current format allo= ws a >>>> parser to discover and unload one or more JSON payloads which can each= have >>>> independent structure. >>>> >>>> General extensions >>>> >>>> The proposal also rules out general purpose extensions not related to >>>> any specific event. Given the emergence of items like GPRD, I would no= t >>>> want to block the ability to add meta-data or other general purpose it= ems. >>>> We can also anticipate some delivery scenarios where additional data m= ight >>>> be required. Even though there is no current planned use, I see no goo= d >>>> reason to rule this out. >>>> >>>> Multiple Events From Different Families (vs. Multiple Events from a >>>> single family like RISC) >>>> >>>> In our RISC session we discussed expressing multiple distinct RISC >>>> events in one SET. The discussion was that only one RISC event at a ti= me. >>>> We did not discuss other event profiles. I don=E2=80=99t see a reason = to rule out >>>> multi-events from different families at the SET level. Each profile is >>>> expressing slightly different things about the same event. >>>> >>>> I can forsee some cases where it is not clear which is the primary and >>>> which is the extension. There may not be a clear winner. >>>> >>>> A couple of examples (these are necessarily real=E2=80=A6just possibil= ities): >>>> >>>> * It is probably useful to be able to express simlar/overlapping event= s >>>> from different SET profiles in one SET. For example a Backchannel Log= out & >>>> a RISC session cancel event. >>>> >>>> * SCIM may want to represent a single transaction as causing multiple >>>> state changes in an event (e.g. a password change causes multiple effe= cts). >>>> Having to chase down multiple events and correlate by =E2=80=9Ctxn=E2= =80=9D would be >>>> challenging in a multi-threaded/multi-node delivery system. The SCIM= list >>>> has not discussed this, but I would not want to block this capability.= IOW >>>> - Just because RISC does not want to express multiple events does not = make >>>> this true for other profiles. >>>> >>>> * We may wish to indicate a SCIM Password Reset was performed and a >>>> Logout/session cancellation is expressed at the same time. The events= are >>>> related but express different data. >>>> >>>> Avoiding Confusion From Similar Events Originating from the Same >>>> Transaction >>>> >>>> If events are sent separately, then more tracking of state (e.g. by >>>> txn) would be required to ensure similar events are not mistaken or ha= ndled >>>> as repeats. While txn provides useful audit analysis capability, I=E2= =80=99m not >>>> sure it can be used in live or near-real time systems given distribute= d >>>> multi-node, multi-threading architectures. >>>> >>>> Previous Discussion >>>> >>>> I note that I originally raised having an attribute to designate >>>> primary event attribute to alleviate your concern, but this was not >>>> accepted. See: >>>> >>>> * https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html >>>> >>>> >>>> * https://www.ietf.org/mail-archive/web/id-event/current/msg00140.html >>>> >>>> >>>> The consensus, at least as I interpreted it is up to the receiver to >>>> figure this out based on the definitions it has for each event URI and= the >>>> profiles they represent. IOW - RISC is free to limit that only one RIS= C >>>> event be expressed at a time. >>>> >>>> Phil >>>> >>>> Oracle Corporation, Identity Cloud Services Architect >>>> >>>> @independentid >>>> >>>> www.independentid.com >>>> >>>> >>> >>>> > >>>> >>>> phil.hunt@oracle.com >>>> >>>> On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle >>>> > wrote: >>>> >>>> The current draft of the SET spec allows for expressing multiple >>>> events within the same token, which introduces additional complexi= ty >>>> and room for ambiguous semantics. We=E2=80=99ve discussed this in = the OIDF >>>> RISC working group and the current consensus there is that RISC wi= ll >>>> require that RISC events must be the only event in the SET, having >>>> identified ways to clearly and easily support the handful of use >>>> cases for multiple events per token that people have raised. With >>>> that context in mind, I propose striking the definition of the >>>> =E2=80=9Cevents=E2=80=9D claim from the Security Event Token spec,= and replacing it >>>> with the following definition for an =E2=80=9Cevent=E2=80=9D claim= (singular): >>>> >>>> event >>>> >>>> A JSON object containing an "event_type" member whose value is a U= RI >>>> representing a type of event defined in a Profiling Specification. >>>> The object MAY otherwise be empty, or MAY contain additional membe= rs >>>> as described by the Profiling Specification. >>>> >>>> Here is the example SET from section 2.3, rewritten with this chan= ge >>>> mind: >>>> >>>> { >>>> >>>> "jti": "4d3559ec67504aaba65d40b0363faad8", >>>> >>>> "iat": 1458496404, >>>> >>>> "iss": "https://scim.example.com ", >>>> >>>> "aud": [ >>>> >>>> "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", >>>> >>>> "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>> >>>> ], >>>> >>>> "event": { >>>> >>>> "event_type": "urn:ietf:params:scim:event:create", >>>> >>>> "ref": "https://scim.example.com/User >>>> s/44f6142df96bd6ab61e7521d9", >>>> >>>> "attributes": ["id", "name", "userName", "password", "emails"= ] >>>> >>>> } >>>> >>>> } >>>> >>>> Does anyone in the working group have use cases for SETs that cann= ot >>>> be met by this proposed text? Within RISC, we identified three use >>>> cases, with solutions outlined below: >>>> >>>> ** >>>> >>>> *Extensions* >>>> >>>> Event extension mechanisms can be defined internal to the event >>>> object. A simple approach would be to define an =E2=80=9Cextensio= ns=E2=80=9D member >>>> that is a list of event objects (or set resembling the =E2=80=9Cev= ents=E2=80=9D >>>> claim as defined in the current spec). This has the advantage of >>>> making it clear in the data structure that there is a single prima= ry >>>> event, with zero or more extensions. There is no room for confusio= n >>>> over which event is primary, or if there is a primary event at all= . >>>> I would be fine with adding something like this to my proposed tex= t, >>>> if there is consensus that it is broadly useful. >>>> >>>> *Aliases* >>>> >>>> This use case was brought up in the context of migrating clients >>>> from draft event names to standardized event names. In this case, >>>> the event transmitter can transmit two tokens for the logical even= t, >>>> one using the old name and another using the new name. >>>> >>>> *Related Events* >>>> >>>> The SET spec defines the txn claim as a means of correlating >>>> independent tokens that relate to the same logical event. >>>> >>>> -- >>>> Annabelle Richard Backman >>>> >>>> Amazon =E2=80=93 Identity Services >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.i >>>> etf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaW >>>> HvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEiv >>>> zjWwlNKe4C_lLIGk&m=3Ds5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSib >>>> Ec&s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D >>>> >>>> >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>> >>>> >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Subscribe to the HARDTWARE >>>> >>>> mail list to learn about projects I am working on! >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqP >>>> kAI1aLcLN4KZNA&m=3DYBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw >>>> &s=3DWrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=3D >>>> >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqP >>>> kAI1aLcLN4KZNA&m=3DU-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec >>>> &s=3DrvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm46QSz0&e=3D >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Subscribe to the HARDTWARE >>>> >>>> mail list to learn about projects I am working on! >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqP >>>> kAI1aLcLN4KZNA&m=3DiyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w >>>> &s=3DOe0qfLEX83vtXM7Wl2cYBe-Gg1DVPjhXjVJkfhVRzwc&e=3D >>>> >>>> >>>> >>>> >>>> -- >>>> Subscribe to the HARDTWARE >>>> >>>> mail list to learn about projects I am working on! >>>> >>>> >>>> >>>> >>>> -- >>>> Subscribe to the HARDTWARE >>>> >>>> mail list to learn about projects I am working on! >>>> >>>> >>>> >>>> >>>> -- >>>> Subscribe to the HARDTWARE >>>> >>>> mail list to learn about projects I am working on! >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqP >>>> kAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo >>>> &s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=3D >>>> >>>> >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>> >>>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >> > --001a114885820a7284055cf30366 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    The receiver probably knows which version they want, but d= oes the sender? Using the email analogy, you may have configured your email= client to accept plain text only. Fortunately, my client sends both =E2=80= =93 not knowing what you prefer =E2=80=93 and you are able to view my messa= ge.

    I think it would help if we broke this problem down = into two parts. 1/ Are multi-format SETs desirable? That's been the des= ign since the earliest version. 2/ What is the best representation of the S= ET based on what we decide for #1.

    My understandin= g was that the "events" plural (related to #2, the best represent= ation of a SET) was in fact=C2=A0a concern, as people may skip the t= ext and look directly at the JSON syntax, then jump to conclusions.

    On Wed, Nov 1, 2017= at 2:54 PM, Marius Scurtescu <mscurtescu@google.com> wr= ote:
    On Wed, Nov 1, 2017 at 2:46 PM, William = Denniss <wdenniss@google.com&= gt; wrote:
    Perhap= s I can try and explain the original intent of the current design. The goal= was always that a SET represents a single logical event. However multiple = systems may have different representations of the event =E2=80=93 the examp= le given originally was one formatted for RISC, and one for SCIM.

    <= /div>
    A good analogy is email. You send a single logical email, which m= ay have two representations, HTML and plain text. Systems can consume the v= ersion that they understand and ignore the one they don't.
    <= /blockquote>

    Yes, and I think this is well understood.

    =C2=A0

    I'm starting to regret the plural in "= ;events", it was pluralized due to it being an array, not because it r= epresented multiple logical events.

    =
    I don't think this is the main concern or cause for confusion.

    =C2=A0

    Annabelle, I understand your concerns regardin= g confusion of the semantics between the JSON syntax and the specification = language. Are there other ways to resolve that without removing the ability= for multiple representations of the same event?

    The argument is that multiple representations can be sent= as distinct SETs, if really needed. In practice this will happen quite rar= e though. Events are created for a specific receiver, the receiver either w= ants the SCIM or the RISC flavor, and they should be able to specify that i= n configuration (there is a proposal how to capture that).

    Do we have a compelling use case where a receiver must receive mul= tiple variants all at once?

    =C2=A0

    On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu <= mscurtescu@google.com> wrote:
    On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
    You can= =E2=80=99t really have multiple events (at least of the same type).=C2=A0 T= he current spec can only have one instance of a URI (afaik). =C2=A0
    Note that the spec normatively does not support multiple event = SETS.=C2=A0 It currently states:
    events
      The semantics of this claim is to define a set of event statements
      that each MAY add additional claims to fully describe a single
      logical event that has occurred (e.g. a state change to a
      subject).  Multiple event statements of the same type SHALL NOT be
      accepted.  The "events" claim SHOULD NOT be used to express
      multiple logical events.

    The sp= ec has *always* supported requirements (as stated in the spec) for multiple= separate profile statements (from one or more profile familities) needing = to be sent as a single message.=C2=A0 It would be INSECURE to force multipl= e SETs because the current delivery mechanism only allows one SET to be del= ivered at a time. There is no way to assure that a single receiver gets all= of the SETs it needs in a multi-threaded, multi-node environment at scale.= =C2=A0 Assembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a common = state database is NOT simple nor cost effective.

    I totally agree that it is difficult for rece= ivers to receive separate events, in no particular order and correlate base= d on "txn". But, receivers have to solve this issue regardless of= "events" or "event", so it is unrelated to this propos= al.

    =C2=A0

    If we accomm= odate this in the proposed form, we end up with a complex, deeply nested JS= ON structure with the possibility of namespace conflicts.

    IMO The proposal does not simplify, it complicating and limiting. = =C2=A0

    The current spec has very clean JSON and av= oids namespace conflicts between profiles. I think we should stay on track = with the current draft and observe the normative text if not make it strong= er in regards to multi-events (understood that Mike may disagree).

    Phil
    <= div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-i= ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap= :break-word">
    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    =
    phil.hunt@oracle.com

    On Nov 1, 2017, at 12:18 PM, Richar= d Backman, Annabelle <richanna@amazon.com> wrote:=

    Unless the p= rofile guarantees that such related events will always be included in the s= ame SET, then the receiver has to correlate across SETs anyway, and multipl= e events per SET is just giving the receiver another scenario that they hav= e to support.
    =C2=A0
    I=E2=80=99ve already provided several other reasons why we should not s= upport multiple tokens per SET that no one has addressed. Here they are aga= in:
    1. Multiple ev= ent support results in a more complex structure for the single event use ca= se, which I think we all agree is the majority use case.
      2. =
    2. Multiple-event SETs have ambi= guous semantics. The presence of two events A and B in the same SET could m= ean any of:
      1. A and B a= re related to the same logical event (i.e. the same thing as if they were f= rom different SETs that have a common txn).
      2. A is an extension of B.
        3. =
      3. B is an extension of A.
      4. A is an alias fo= r B, or vice-versa.
      5. A and B are not actually related to one another in any way, and th= e transmitter bundled them together because they were going to the same rec= eiver.
    3. Top-level claim semantics become harder to define, as different profi= les may want to use the same claims in different ways.
      4. Event authenticity cannot be ve= rified without having the entire SET. This forces receivers to expose downs= tream systems to more information necessary, if those systems need to be ab= le to verify authenticity.
    =C2=A0
    --=C2=A0
    Anna= belle Richard Backman
    Amazon =E2=80=93 = Identity Services
    =C2=A0
    =C2=A0
    From:=C2=A0Mike Jones <Michael.Jones@mi= crosoft.com>
    Date:=C2=A0Wednesday, November 1, 2017 at 11:21 AM
    To:=C2=A0    Dick Hardt <= dick.hardt@gmail.com>
    Cc:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>, "Richard Backman, Annabelle"= <richanna@amazon.com>, ID Events Mailing List &l= t;id-event@ietf.org>, "Phil Hunt (IDM)" <= phil.hunt@oracle.com>
    Subject:=C2=A0RE: [Id-event] Use cases = for multiple events per SET?
    =C2=A0
    I completely agree on moving complexity to the issuer over the recipient= .=C2=A0 In my view, it=E2=80=99s more complex for recipients to have to cor= relate and process a sequence of multiple SETs providing information about = the same logical event, and validate N signatures, than to receive one SET = with all the aspects of the logical event as =E2=80=9Cevents=E2=80=9D field= s, with no correlation over time then required.
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 -- Mike
    From:=C2=A0Dick Hardt [mailto:dick.hardt@gmail.com]=C2=A0
    Sent:=C2=A0Wednesday, November 1, 2017 9:39 AM
    T= o:=C2=A0Mike Jon= es <Michael.Jones@microsoft.com>
    Cc= :=C2=A0Yaron She= ffer <yaronf.ietf@gmail.com>; Richard Backman, = Annabelle <richanna@amazon.com>; ID Events Mailin= g List <id-event@ietf.org>; Phil Hunt (IDM) <phil.hunt@oracle.com>
    Subject:=C2=A0Re: [Id-event] Use cases for= multiple events per SET?
    =C2=A0=
    Your comments highlight a couple of points:
    =C2=A0
    1) The example is how to have a predefined extension point for exten= sions of a specific event, it is not how to add another event. Myself, I th= ink this is overly complicated. Events should be comparatively static, and = as with many other JSON formats, the receiver should ignore properties it d= oes not understand, which let's new properties be introduced as extensi= ons. There should not be any conflict as extensions should only be done by = the profile that created the event format to start off with.<= /div>
    =C2=A0
    = 2) Having an lvalue be a URI is much harder to code against. I'm not su= re why Marius had that in his example. Per the event, the type of the event= is well defined with=C2=A0
    =C2=A0<= u>
    =
    =C2=A0
    3) This threa= d is about reasons for multiple events to be contained in one set. Your men= tion of an issuer not wanting to sign separate events as a reason to allow = multiple events. I think we have decided that given a preference, we will p= ush effort to the transmitter over the receiver as in many use cases there = are many more receivers. Given that, it is more complex for a receiver to h= ave different ways of managing the receipt of multiple events as not all is= suers will bundle the events, so it is simpler to have only one event per S= ET. Including the separate events with a URI as an lvalue is challenging to= implement, speaking from experience.
    =C2=A0
    =C2=A0
    =C2=A0
    =C2=A0=
    =C2=A0
    =C2=A0
    =C2=A0=
    =C2=A0
    =C2=A0
    =C2=A0
    =C2=A0
    =C2= =A0
    On Tue, Oct 31, 2017 at 11:05 PM, Mik= e Jones <Michael.Jones@microsoft.com> wrote:
    <= blockquote style=3D"border-style:none none none solid;border-left-width:1pt= ;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in = 5pt 4.8pt" type=3D"cite">
    Marius=E2=80=99 proposed syntax, pasted in below, has exactly this cha= racteristic.=C2=A0 The way I see it, his proposal essentially has a primary= passwordReset event and a secondary passwordResetExt data structure, which= could have been simply another event value in the current draft.=
    =C2=A0=
    This break= ing change makes the data structures more complicated - not less.=C2=A0 And= it makes things that used to be possible impossible, reducing flexibility = to those who would use the spec.
    =C2=A0
    These seem like bad tradeoffs to me.=
    =C2=A0
    {
    =C2=A0 &qu= ot;jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",<= /u>
    =C2=A0 "iat": 1458496025,=
    =C2=A0 "iss": "https://scim.example.com",
    =C2=A0 "aud": [
    =C2=A0 =C2=A0"e= vent": {=C2=A0=C2=A0
    =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0"id":"44f6142df96bd6ab61e7521d9&quo= t;,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quo= t;extensions": {
    =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0"https://example.com/scim/event/p= asswordResetExt=E2=80=9D: {
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"resetAttempts":5,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<= u>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}=
    =C2=A0 =C2=A0 =C2=A0 =C2=A0}
    =
    }
    =C2=A0
    In particular, it makes it impossible to sign multiple related even= ts sharing a common claims schema with a single signature by the issuer.=C2= =A0 It forces the issuer to do the extra work of signing each of the relate= d events (or facets of the same logical event) individually and forces the = recipients to do the extra work of checking all those unnecessary signature= s.
    = =C2=A0
    Not every profile will ever have multiple keys in the =E2=80=9Cevents=E2= =80=9D set but there=E2=80=99s absolutely no reason to preclude it.<= u>
    =C2=A0
    =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
    From:=C2=A0Id-event [mailto:id-event-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Dick HardtSent:=C2=A0T= uesday, October 31, 2017 9:52 PM
    To:=C2=A0Mike Jones <Michael.Jones@microsoft.com<= /a>>
    Cc:=C2=A0= Yaron Sheffer <    yaronf.ietf@gmail.com>; Richard Backman, Annabelle = <richan= na@amazon.com>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt = (IDM) <phil.hunt@oracle.com>

    Subject:=C2=A0R= e: [Id-event] Use cases for multiple events per SET?
    =C2=A0
    Pleas= e direct me to a proposal that has a "primary" and "secondar= y" events. I agree that is undesirable. I would also encourage to enga= ge in the discussions so that we can drive clarity and simplicity.
    =C2=A0
    = I think the proposal is that there is one event per SET.
    =C2=A0
    I thin= k having more than one event per SET adds complexity as a receiver must dea= l with receiving correlated events in one SET as well as correlated events = in the same SET.
    =C2=A0
    /Dick
    =C2=A0
    On Tue, Oct 31, 2017 at 9:42= PM, Mike Jones <Michael.Jones@microsoft.com> wrote:<= /div>
    I hear you on the fact that different people have joined the eff= ort at different times.=C2=A0 That=E2=80=99s a normal process as an effort = builds momentum.=C2=A0 I get that not everyone was there when previous cons= ensus calls were taken.
    =C2=A0
    I should note that I have specific technical object= ions to the specific proposed changes being discussed as well.=C2=A0 Curren= tly all events in the set have the same syntax.=C2=A0 The proposals, as I u= nderstand them, revert us to a state where there=E2=80=99s a =E2=80=9Cprima= ry=E2=80=9D and =E2=80=9Csecondary=E2=80=9D events, with different syntax f= or the two classes.=C2=A0 That=E2=80=99s needlessly more complicated, addin= g no actual value.
    =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
    =C2=A0
    From:=C2=A0Dick Hardt [mailto:dick.hardt@gmail.com]=C2=A0
    Sent:=C2=A0Tuesday, October 31, 2017 9:37 PM
    To:=C2=A0    Mike Jones <<= a href=3D"mailto:Michael.Jones@microsoft.com" style=3D"color:purple;text-de= coration:underline" class=3D"m_6337440896153279834m_-3151445958451029318m_7= 476346946956833004cremed m_6337440896153279834cremed" target=3D"_blank">Mic= hael.Jones@microsoft.com>
    Cc:=C2=A0Phil Hunt (IDM) <phil.hunt@oracle.com>; Ya= ron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle <richanna@amazon= .com>; ID Events Mailing List <id-event@ietf.org>
    <= div>

    Subject:=C2=A0Re: [Id-event] Use cases for multiple events per SE= T?
    =C2=A0<= /div>
    Mike
    =C2=A0=
    As you well know, many people in a WG don= 9;t look closely at a specification until last call is made. Additionally, = we are coming up on only the 3rd WG meeting. The WG has not existed for ver= y long. While some of the participants have been working on this for a whil= e, many have not, and we are looking for consensus across the WG.=
    =C2=A0
    Since SecEvent is a framework that we expect to be profiled, I feel it i= s important to ensure that SecEvent specifications are easy for a variety o= f profiles to adopt, and that the semantics make sense. I also think that p= roperties that are specific to a profile should be left to that profile and= not be included in SecEvent.
    =C2= =A0
    Since this is a framework, it i= s expected that as different groups profile it, there will be additional fe= edback.
    =C2=A0
    <= /div>
    Specifically, as a participant in the RISC profile of S= ET, a number of issues in SET have surfaced as the RISC WG has looked at ho= w to use the SET.
    =C2=A0<= /u>
    As for SET being stable for over a year, ther= e have been a number of changes to SET since then. I also don't think t= here was consensus. Before the WG was formed, I and several others had expr= essed concern on the design of SET when Phil presented it at an IIW session= .
    =C2=A0
    <= div>
    As to taking another year, I am hopeful we can resolve the re= maining issues in SET and publish a new draft for last call. I do not think= we will need to wait for another WG meeting to ask for last call.=C2=A0=
    =C2=A0
    =
    We also have a number of other documents that are not in last cal= l, and we don't have a WG adopted draft yet for management. So there ar= e still a number of documents to work through before we have all the bits f= or someone to work with.
    =C2=A0<= /u>
    I do think we have been making good pr= ogress since the last IETF meeting, and I am hopeful we can keep up this mo= mentum and finalize all the documents in a timely manner.
    =C2=A0
    /Dick=
    =C2=A0
    =C2=A0
    On Tue, Oct 31,= 2017 at 12:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:<= u>
    It=E2=80=99s hard for me to even express my level = of frustration with the recent attempts to once again redesign the SecEvent= Token spec.=C2=A0 We=E2=80=99ve been at this for multiple years because pe= ople keep trying to revisit decisions that were long ago made by consensus.= =C2=A0 It=E2=80=99s been stable for over a year and the majority of WGLC re= spondents said some variant of =E2=80=9CWorks for me =E2=80=93 ship it!=E2= =80=9D
    =C2=A0
    There=E2=80=99s not sufficient justification to try to undo consensus= positions that have been debated and affirmed over and over.=C2=A0 Counten= ancing wholesale changes at this late date is counterproductive in the extr= eme!
    =C2=A0
    It=E2=80=99s far better than good enough as-is.=C2=A0 In my experience,= if we start redesigning it, it will result in another year=E2=80=99s delay= .=C2=A0 It does something simple and useful.=C2=A0 Please, let=E2=80=99s ju= st ship it, so people can rely on it.
    = =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke
    From:=C2=A0Phil Hunt (IDM) [mailto:phil.hunt@oracle= .com]=C2=A0
    <= b>Sent:=C2=A0Mon= day, October 30, 2017 2:42 PM
    To:=C2=A0Dick Hardt <dick.hardt@gmail.com>
    Cc:=C2=A0Yaron Sheffe= r <ya= ronf.ietf@gmail.com>; Richard Backman, Annabelle <richanna@amazon.com&g= t;; Mike Jones <Michael.Jones@microsoft.com>; ID Events Mailing Lis= t <id-eve= nt@ietf.org>

    Subject:<= /b>=C2=A0Re: [Id-eve= nt] Use cases for multiple events per SET?
    <= /div>
    =C2=A0
    Inl= ine...

    Phil

    On Oct 30, 2017, at 2:22 PM, Dick Hardt <dick.hardt@gmail.com> wrote:=

    Hi Phil
    Correct me if I am misunde= rstanding, but there is a RISC profile event=C2=A0
    =C2=A0
    "= ;http://schemas.openid.net/secevent/risc/event-type/account-credentia= l-change-required=E2=80=9D
    =C2=A0
    and an SCIM profil= e event
    =C2=A0
    <= /div><= div>
    I'm suggesting that two different events would be sent. E= mbedding one in the other does not make sense.
    <ph>It is a hypothetical example. Jus= t because you disagree on this does not mean others are not valid.=C2=A0=
    =C2=A0
    I just picked overlapping proposals that have different meaning (but no= t the same) to illustrate the difference from issuing a single set with dif= ferent events.=C2=A0
    =C2=A0<= u>

    As I have stated this is ver= y different from asserting multiple distinct events in one SET.=C2=A0

    =C2=A0
    Also, I think it is simpler to have event_type be at the same level as e= vent
    =C2= =A0

    <ph>may be. I wa= s working from Annabelle's proposed format.=C2=A0

    =
    =C2=A0
    {
    =C2=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30"= ;,
    =C2=A0 "iat": 1458496025,
    =C2=A0 "iss": "https://scim.example.com",<= /span>
    =C2=A0 "aud": [<= /div>
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0 =C2= =A0],
    =C2=A0 =C2=A0"event_type": &quo= t;https://example.com/scim/event/passwordResetExt"= ,
    =C2=A0 =C2=A0"event": {=C2=A0=C2=A0=
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"id&quo= t;:"44f6142df96bd6ab61e7521d9",
    = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"resetAttempts":5=
    =C2=A0 =C2=A0 =C2=A0 =C2=A0}
    }
    =C2=A0
    {=
    =C2=A0 "jti": "3d0c3cf797584bd1= 93bd0fb1bd4e7d30",
    =C2=A0 "iat&q= uot;: 1458496025,
    =C2=A0 "iss": "= ;https://sc= im.example.com",
    = =C2=A0 "aud&qu= ot;: [
    =C2=A0 =C2=A0],
    =C2=A0 =C2=A0"event&q= uot;: {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=9Csub= =E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
    =C2= =A0 =C2=A0 =C2=A0 =C2=A0=E2=80=9Ciss=E2=80=9D:"https://idp.example.com/&q= uot;=C2=A0 =C2=A0 =C2=A0 =C2=A0
    =C2=A0 =C2=A0 = =C2=A0 =C2=A0}
    }
    =C2=A0
    =C2= =A0
    =C2=A0
    =C2=A0
    =C2=A0=
    On Mon, Oct 30, 2017 at 12:09 PM, Phil H= unt <p= hil.hunt@oracle.com> wrote:
    Annabelle/Dick,
    =C2=A0
    Thanks for the comment= s. I think we need to examine the consequences of the proposal in JSON.<= /u>
    =C2=A0
    As I stated, what causes most of the issue is the proposed extension me= chanism in the payload (possibly using events in a recursive way). Does it = follow the old format or the new?
    =C2=A0<= u>
    Let=E2=80=99s =C2=A0consider a use = case where we have an identity management system that uses SCIM, but the SC= IM system is also the underlying data store for Connect.=C2=A0 A Password r= eset might generate the following event which has an extension (conveying r= eset count) AND overlapping statement from RISC.=C2=A0 BOTH of which might = be important to a similar receiver using SCIM and OIDC. =C2=A0
    =C2=A0
    = The 03 spec currently would allow:
    =C2=A0
    {<=
/u>
    =C2=A0 "jti": "3d0c3cf797584bd19=
3bd0fb1bd4e7d30",
    =C2=A0 &q=
uot;iat": 1458496025,
    =C2=A0 &qu=
ot;iss": "https://scim.example.com",
    =C2=A0 "aud": [
    =
=C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Fee=
ds/98d52461fa5bbc879593b7754",
    =C2=A0=C2=A0=C2=A0 "https://jhub.example.=
com/Feeds/5d7604516b1d08641d7676ee7"
    =C2=A0=C2=A0 ],
    =C2=A0=
=C2=A0 "events": {
    =C2=A0=
=C2=A0=C2=A0=C2=A0 "urn:ietf:params:scim:event:passwordReset"=
;:
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 { "id":"44f6142df96bd6ab61e7521d9"},=

    =C2=A0=C2=A0=C2=A0=C2=A0 "http=
s://example.com/scim/event/passwordResetExt":
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAt=
tempts":5},
    =C2=A0=C2=A0=C2=A0=C2=A0 "http://schemas.openid.net/secevent/risc/event-type/\
    =C2=A0 =C2=A0 =C2=A0 =C2=A0account-credent=
ial-change-required": {
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,=

    =C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/"
    =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
    =
=C2=A0 }
    }
    =C2=A0
    In the above - each payload is a =E2=80=98p=
eer' and issued without preference by the transmitter. The receiver can=
 assign priority in its own context if that matters.
    =C2=A0
    The new propos=
al:
    =C2=A0
    {
    =
=C2=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",<=
u>
    =C2=A0 "iat": 1458496025,
    =C2=A0 "iss": "https://scim.examp=
le.com",
    =C2=A0 "aud&qu=
ot;: [
    =C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Feeds/98d52461fa5bbc879593b775=
4",
    =C2=A0=C2=A0=C2=A0 "=
;https://jhub.example.com/Feeds/5d7604516b1d08641d=
7676ee7"
    =C2=A0=C2=A0 ],<=
/u>
    =C2=A0=C2=A0 "event": {=

    =C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_typ=
e=E2=80=9D:"urn:ietf:params:scim:event:passwordReset=E2=80=9D,=

    =C2=A0=C2=A0=C2=A0=C2=A0 "id"=
:=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevents=E2=80=9D:{=

    =C2=A0=C2=A0=C2=A0=C2=A0 ->note =E2=80=A6is=
 this the old or new structure? <-
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://example.com/=
scim/event/passwordResetExt":
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAtte=
mpts":5},
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "http://schemas.openid.=
net/secevent/risc/event-type/\
    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=
 =C2=A0account-credential-change-required": {
    =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A65637=
4=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ciss=
=E2=80=9D:"https://idp.example.com/"
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
    =

    =C2=A0=C2=A0=C2=A0=C2=A0 =
}
    =C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0 
    }
    =C2=A0
    In the above, sub-events or extensions have =
a different format. The same complaint about the original stands.=

    =C2=A0
    *OR* (if the rece=
iver cares about RISC more).=C2=A0 Note that this leads to a triple nested =
structure.
    =C2=A0
    {
    =C2=
=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",<=
/u>
    =C2=A0 "iat": 1458496025,
    =C2=A0 "iss": "https://scim.example.c=
om",
    =C2=A0 "aud":=
 [
    =C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754<=
/a>",
    =C2=A0=C2=A0=C2=A0 "<=
a href=3D"https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" style=
=3D"color:purple;text-decoration:underline" class=3D"m_6337440896153279834m=
_-3151445958451029318m_7476346946956833004cremed m_6337440896153279834creme=
d" target=3D"_blank">https://jhub.example.com/Feeds/5d7604516b1d08641d=
7676ee7"
    =C2=A0=C2=A0 ],<=
/u>
    =C2=A0=C2=A0 "event": {=

    =C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_typ=
e=E2=80=9D:"http://schemas.open=
id.net/secevent/risc/event-type/\
    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0account-credential-change-required=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
    =C2=A0=C2=A0=C2=
=A0=C2=A0 =C2=A0=E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C,
    <=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courie=
r New',serif">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 =E2=80=9Cevents=E2=80=9D:{
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 "urn:ietf:params:scim:event:passwordReset":
    =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "id=
":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=E2=80=9Cevents=E2=80=9D:{
    =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://example.com/scim/event/passwordResetExt":
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAttempts":5},<=
span style=3D"font-size:13.5pt">=C2=A0 
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0}=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0}
    =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0=C2=A0 
    =C2=A0=C2=A0=C2=A0}<=
/pre>
    }
    =C2=A0
    In the above,=
 the extension is placed inside the event it extends. It follows the old fo=
rmat (or should it follow the new?)
    *OR* F=
ollowing the top layer pattern of singular event=C2=A0 Note that this leads=
 to a triple nested structure.
    =C2=A0
    {
    =C2=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7<=
wbr>d30",
    =C2=A0 "iat"=
: 1458496025,
    =C2=A0 "iss":=
 "http=
s://scim.example.com",
    =C2=
=A0 "aud": [
    =C2=A0=C2=A0=
=C2=A0 "https://jhub.example.com/Feeds/98d524=
61fa5bbc879593b7754",
    =C2=A0=
=C2=A0=C2=A0 "https://jhub.example.com/Feeds/=
5d7604516b1d08641d7676ee7"
    =
=C2=A0=C2=A0 ],
    =C2=A0=C2=A0 "ev=
ent": {
    =C2=A0=C2=A0=C2=A0=C2=A0=
 =E2=80=9Cevent_type=E2=80=9D:"http:=
//schemas.openid.net/secevent/risc/event-type/\=

    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 =C2=A0account-credential-change-required=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Csub=
=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C,
    =C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent=E2=80=9D:{<=
/pre>
    =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params=
:scim:event:passwordReset=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=
=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 =E2=80=9Cevent=E2=80=9D:{
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_=
type=E2=80=9D:"https://example.com/scim/event/password=
ResetExt=E2=80=9D,
    =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "resetAttempts":5 
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=
=A0=C2=A0 
    =C2=A0=C2=A0=C2=A0}
    }
    =
=C2=A0
    This format follows the proposed singular event format r=
ecursively and is 3 layers deep. Note that the parser has to continue to se=
arch the document for things that aren=E2=80=99t there as it has to stop wh=
en no =E2=80=9Cevent=E2=80=9D attribute is found rather than iterate over a=
n array.
    =C2=A0
    Phil

    Oracle Corporation, Identity Cl= oud Services Architect
    @independentid
    www.independentid.com
    phil.hunt@oracle.com
    =C2=A0
    On Oc= t 30, 2017, at 8:57 AM, Richard Backman, Annabelle <richanna@amazon.com> = wrote:
    =C2=A0
    <= /div>
    Replies inline.
    =
    =C2=A0
    =
    --=C2=A0
    Annabelle Richard Backman<= u>
    Identity Se= rvices
    =C2=A0
    =C2=A0
    From:=C2=A0<= /span>Phil Hunt <phil.hunt@oracle.com>
    Date:=C2=A0Sunday, October 29, 2017 at 5:= 25 PM
    To:=C2= =A0Dick Hardt <dick.hardt@gmail.com>
    Cc:= =C2=A0Yaron Sheffer <yaronf.ietf@gmail.c= om>, Mike Jones <Michael.Jones@= microsoft.com>, "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing Lis= t <id-event@ietf.org>
    Subject:=C2=A0    Re: [Id-= event] Use cases for multiple events per SET?
    =C2=A0
    I hope this answe= rs your question.
    =C2=A0
    My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t= see a reason why not. The question should be, what is the justification to= make =E2=80=9Cevents=E2=80=9D singular?
    [richann= a]The singular =E2=80=9Cevent=E2=80=9D claim has clearer semantics and is e= asier to process. We should opt for easier solutions unless there are use c= ases that require more complexity.[/richanna]
    =C2=A0
    There are many re= asons for multiple events in a SET.=C2=A0 Some are good, some not so good. = Some of the reasons...
    =C2=A0
    1.=C2=A0 Multiple event payloads expressing st= atements about largely the *same*thing. For example, SCIM password reset AN= D RISC password reset.=C2=A0 A RISC Event and an OpenBanking Event. Is one = a complement to the other?=C2=A0 Do they overlap or are they distinct? =C2= =A0
    [richanna]Copy/pasted from my earlier email:<= /span>
    Why is it necessary or appropriate to incl= ude these events in the same SET? They are likely being generated by differ= ent systems at different times on the transmitter=E2=80=99s side, consumed = by different systems on the receiver=E2=80=99s side, and possibly being tra= nsmitted over different event streams. I know the latter would be the case = for us, as a receiver. Even if it=E2=80=99s not, is it burdensome to send t= hese events separately? What value is gained in combining them?
    =C2=A0
    Additionally,= since the signature is over the SET and not the event objects, Receivers i= ndependently route separate events from a single token without either losin= g the ability to verify the authenticity of the event or sharing all inform= ation in the SET with every system handling any event in the token.[/richan= na]
    <= span style=3D"color:rgb(195,70,224)">=C2=A0

    2.=C2=A0 Multipl= e events payloads expressing different statements about the same transactio= n - RISC Password Reset and RISC Session Cancel
    [richanna]Same as above[/richanna]

    3.=C2=A0 A new profile= defines new event attributes to be added on to an existing event type (a p= ure extension)=C2=A0
    [richanna]I h= ave suggested a way to support extensions within an event body, multiple ti= mes now. If you see problems with it, please point them out.[/richanna]
    =C2=A0
    I think it is quite valid to allow 1 and 3. =C2=A02 could be limit= ed by specific profiles like RISC if they want.
    =C2=A0
    I am not in agreement = that making event singular simplifies anything. For one is makes extensions= complex (another nested JSON structure) and potentially conflicting.=C2=A0=
    [richanna]
    Ways that multiple-event SETs are more complicated:
      =
    1. It res= ults in a more complex structure for the single event use case, which I thi= nk we all agree is the majority use case.
    2. Multiple-event SETs h= ave ambiguous semantics. The presence of two events A and B in the same SET= could mean any of:
      1. The= y are related to the same logical event (i.e. the same thing as if they wer= e from different SETs that have a common txn).
      2. A is an extensi= on of B.
      3. B is an extension of A.
      4. They are aliases f= or one another.
      5. They are not actually related to one another in= any way.
    1. Claim semantics become harder to define, as different profiles = may want to use the same claims in different ways.
    <= /div>
    =C2=A0
    <= /div>
    If the WG wants to bl= ock 1 and 2 above, then I believe we have to establish an event registry to= ensure new Event profiles do not overlap to eliminate the need to express = multiple events.
    [richanna]I=E2=80=99m= not sure what you mean by this. Are you referring to event names? Those ar= e already defined by the spec to be URIs.[/richanna]
    P= hil
    =C2=A0
    Oracle Corporation, Identity Cloud Services Architect
    @independenti= d
    =C2=A0
    On Oct 29, 2017, at 4:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
    =C2=A0
    Phil:
    =C2=A0
    In your examples for having a plurality o= f events, you use the word "may", which leads me to question if a= plurality of events is really required in SET.
    <= /div>
    =C2=A0
    =
    You posit that it will be diffic= ult for a distributed system to correlate multiple SETs with the same "= ;txn", but the distributed system will certainly need to correlate eve= nts on the same subject -- correlating events on the same "txn" o= n the same subject seems fairly simple.
    =C2=A0
    I think that a receiver will need to cor= relate multiple SEts on the same subject, so having multiple events in a SE= T is redundant, and adds complexity with no clear benefit that I can see.
    =C2=A0<= /span>
    An imp= lementor may choose to send multiple SETs, or send a single SET with multip= le events, so a receiver will need to support both. I prefer we pick one wa= y and minimize the code paths, and we will need to support correlating acro= ss multiple SETs, so that seems the best mechanism.
    =C2=A0
    Let me know if there is some= thing I missed in my logic.
    =C2=A0
    /Dick
    =C2=A0
    <= div>
    =C2=A0
    <= div>
    On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer=C2=A0<yaronf.ietf@gmail.com>=C2=A0wrote:
    In that ca= se, let's add text to that effect, e.g. we could add to the definition = of the "events" claim:

    Profiling specifications SHOULD def= ine the allowed event statements, and MAY restrict their number. For exampl= e, some profiles may require this claim to contain only a single event stat= ement.

    Thanks,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Yaron

    On 24/10/17 22:10= , Mike Jones wrote:

    I agree with much of Phil=E2=80=99s ration= ale here.

    It=E2=80=99s fine for some profiles to say that the =E2=80= =9Cevents=E2=80=9D set must be a singleton.=C2=A0 That doesn=E2=80=99t have= to be true for all events.=C2=A0 I think things are fine as-is.

    =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0= =C2=A0-- Mike

    *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Phil Hunt
    *= Sent:* Monday, October 23, 2017 8:47 PM
    *To:* Richard Backman, Annabelle= <richanna@amazon.com    >
    *Cc:* ID Even= ts Mailing List <id-event@ietf.org>
    *S= ubject:* Re: [Id-event] Use cases for multiple events per SET?

    Annab= elle,

    I have a number of concerns with this proposal.

    Profili= ng Independence / Keeping Event Payloads Independent

    Indicating that= extensions should be handled by profiles leads to more inter-operability i= ssues and more importantly intrudes on the Event payload space by suggestin= g a sub-schema creates potential limitations and conflicts that may add to = complexity later on. The current format allows a parser to discover and unl= oad one or more JSON payloads which can each have independent structure.
    General extensions

    The proposal also rules out general purpose = extensions not related to any specific event. Given the emergence of items = like GPRD, I would not want to block the ability to add meta-data or other = general purpose items. We can also anticipate some delivery scenarios where= additional data might be required. Even though there is no current planned= use, I see no good reason to rule this out.

    Multiple Events From Di= fferent Families (vs. Multiple Events from a single family like RISC)
    In our RISC session we discussed expressing multiple distinct RISC events= in one SET. The discussion was that only one RISC event at a time. We did = not discuss other event profiles. I don=E2=80=99t see a reason to rule out = multi-events from different families at the SET level. Each profile is expr= essing slightly different things about the same event.

    I can forsee = some cases where it is not clear which is the primary and which is the exte= nsion.=C2=A0 There may not be a clear winner.

    A couple of examples (= these are necessarily real=E2=80=A6just possibilities):

    * It is prob= ably useful to be able to express simlar/overlapping events from different = SET profiles in one SET.=C2=A0 For example a Backchannel Logout & a RIS= C session cancel event.

    * SCIM may want to represent a single transa= ction as causing multiple state changes in an event (e.g. a password change= causes multiple effects). Having to chase down multiple events and correla= te by =E2=80=9Ctxn=E2=80=9D would be challenging in a multi-threaded/multi-= node delivery system.=C2=A0 =C2=A0The SCIM list has not discussed this, but= I would not want to block this capability.=C2=A0 IOW - Just because RISC d= oes not want to express multiple events does not make this true for other p= rofiles.

    * We may wish to indicate a SCIM Password Reset was perform= ed and a Logout/session cancellation is expressed at the same time.=C2=A0 T= he events are related but express different data.

    Avoiding Confusion= From Similar Events Originating from the Same Transaction

    If events= are sent separately, then more tracking of state (e.g. by txn) would be re= quired to ensure similar events are not mistaken or handled as repeats. Whi= le txn provides useful audit analysis capability, I=E2=80=99m not sure it c= an be used in live or near-real time systems given distributed multi-node, = multi-threading architectures.

    Previous Discussion

    I note tha= t I originally raised having an attribute to designate primary event attrib= ute to alleviate your concern, but this was not accepted. See:

    *=C2=A0https://www.ietf.org/mail-archive/web= /id-event/current/msg00406.html

    *=C2=A0https://www.ietf.org/mail-archive/web/id-event/curre= nt/msg00140.html

    The consensus, at least as I interp= reted it is up to the receiver to figure this out based on the definitions = it has for each event URI and the profiles they represent. IOW - RISC is fr= ee to limit that only one RISC event be expressed at a time.

    Phil
    Oracle Corporation, Identity Cloud Services Architect

    @independ= entid

    www.independentid.com=C2=A0<http://www.independentid.co= m>

    phil.hunt@oracle.com= =C2=A0<mai= lto:phil.hunt@oracle.com>

    =C2= =A0 =C2=A0 On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle
    =C2= =A0 =C2=A0 <richanna@amazon.com=C2=A0<mailto:richanna@amazon.com>> wrote:

    =C2= =A0 =C2=A0 The current draft of the SET spec allows for expressing multiple=
    =C2=A0 =C2=A0 events within the same token, which introduces additional= complexity
    =C2=A0 =C2=A0 and room for ambiguous semantics. We=E2=80=99v= e discussed this in the OIDF
    =C2=A0 =C2=A0 RISC working group and the cu= rrent consensus there is that RISC will
    =C2=A0 =C2=A0 require that RISC = events must be the only event in the SET, having
    =C2=A0 =C2=A0 identifie= d ways to clearly and easily support the handful of use
    =C2=A0 =C2=A0 ca= ses for multiple events per token that people have raised. With
    =C2=A0 = =C2=A0 that context in mind, I propose striking the definition of the
    = =C2=A0 =C2=A0 =E2=80=9Cevents=E2=80=9D claim from the Security Event Token = spec, and replacing it
    =C2=A0 =C2=A0 with the following definition for a= n =E2=80=9Cevent=E2=80=9D claim (singular):

    =C2=A0 =C2=A0 event
    <= br>=C2=A0 =C2=A0 A JSON object containing an "event_type" member = whose value is a URI
    =C2=A0 =C2=A0 representing a type of event defined = in a Profiling Specification.
    =C2=A0 =C2=A0 The object MAY otherwise be = empty, or MAY contain additional members
    =C2=A0 =C2=A0 as described by t= he Profiling Specification.

    =C2=A0 =C2=A0 Here is the example SET fr= om section 2.3, rewritten with this change
    =C2=A0 =C2=A0 mind:

    = =C2=A0 =C2=A0=C2=A0<= /span>{

    =C2=A0 =C2=A0 =C2=A0=C2=A0 "jti": "4d3559ec67= 504aaba65d40b0363faad8",

    =C2=A0 =C2=A0 =C2=A0=C2=A0 "= iat": 1458496404,

    =C2=A0 =C2=A0 =C2=A0=C2=A0"iss": &q= uot;https://scim.example.com=C2=A0<htt= ps://scim.example.com/>",

    =C2=A0 =C2=A0 =C2= =A0=C2=A0 "aud": [

    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0= "https://scim.example= .com/Feeds/98d52461fa5bbc879593b7754",

    =C2= =A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0"https://scim.example.com/Feeds/5d7604516b1d08641d767= 6ee7"

    =C2=A0 =C2=A0 =C2=A0=C2=A0 ],

    =C2=A0 = =C2=A0 =C2=A0=C2=A0 "event": {

    =C2=A0 =C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0 "event_type": "urn:ietf:params:scim:event:create",

    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 "ref"= : "https://scim.examp= le.com/Users/44f6142df96bd6ab61e7521d9",

    =C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 "attributes": ["id", &= quot;name", "userName", "password", "emails&q= uot;]

    =C2=A0 =C2=A0 =C2=A0=C2=A0 }

    =C2=A0 =C2=A0 }

    =C2= =A0 =C2=A0 Does anyone in the working group have use cases for SETs that ca= nnot
    =C2=A0 =C2=A0 be met by this proposed text? Within RISC, we identif= ied three use
    =C2=A0 =C2=A0 cases, with solutions outlined below:
    =C2=A0 =C2=A0 **

    =C2=A0 =C2=A0 *Extensions*

    =C2=A0 =C2=A0 Ev= ent extension mechanisms can be defined internal to the event
    =C2=A0 =C2= =A0 object. A simple approach would be to =C2=A0define an =E2=80=9Cextensio= ns=E2=80=9D member
    =C2=A0 =C2=A0 that is a list of event objects (or set= resembling the =E2=80=9Cevents=E2=80=9D
    =C2=A0 =C2=A0 claim as defined = in the current spec). This has the advantage of
    =C2=A0 =C2=A0 making it = clear in the data structure that there is a single primary
    =C2=A0 =C2=A0= event, with zero or more extensions. There is no room for confusion
    =C2= =A0 =C2=A0 over which event is primary, or if there is a primary event at a= ll.
    =C2=A0 =C2=A0 I would be fine with adding something like this to my = proposed text,
    =C2=A0 =C2=A0 if there is consensus that it is broadly us= eful.

    =C2=A0 =C2=A0 *Aliases*

    =C2=A0 =C2=A0 This use case was= brought up in the context of migrating clients
    =C2=A0 =C2=A0 from draft= event names to standardized event names. In this case,
    =C2=A0 =C2=A0 th= e event transmitter can transmit two tokens for the logical event,
    =C2= =A0 =C2=A0 one using the old name and another using the new name.

    = =C2=A0 =C2=A0 *Related Events*

    =C2=A0 =C2=A0 The SET spec defines th= e txn claim as a means of correlating
    =C2=A0 =C2=A0 independent tokens t= hat relate to the same logical event.

    =C2=A0 =C2=A0 --=C2=A0
    =C2=A0 =C2=A0 Ann= abelle Richard Backman

    =C2=A0 =C2=A0 Amazon =E2=80=93 Identity Servi= ces

    =C2=A0 =C2=A0 _____________________________________________= __
    =C2=A0 =C2=A0 Id-event mailing list
    =C2=A0 =C2=A0=C2=A0Id-even= t@ietf.org=C2=A0<mailto:Id-event@ietf.org= >
    =C2=A0 =C2=A0=C2=A0https://urldefense.proofpoint.com/v2= /url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d= =3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&= ;r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Ds5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=3DX8oRSq3IzlF7jiRAeZhXpR3eV<= wbr>I0I58ZFd4eEZfgyoIY&e=3D



    _________________= ______________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.iet= f.org/mailman/listinfo/id-event


    ______________________________= _________________
    Id-event mailing list
    Id-event@iet= f.org
    https://www.ietf.org/mailman/listinfo/id-event


    =C2=A0
    --=C2=A0
    Subscribe to the=C2=A0HARDTWARE=C2=A0mail list t= o learn about projects I am working on!
    =C2=A0
    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    =C2= =A0


    =C2=A0
    --
    = Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I= am working on!


    =C2=A0
    --
    = Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I= am working on!


    =C2=A0
    --
    =C2=A0HARDTWARE=C2=A0mail list to learn about projects= I am working on!


    <= div>
    =C2=A0
    --=C2=A0
    <= div>
    Subscribe to the=C2=A0HARDT= WARE=C2=A0mail l= ist to learn about projects I am working on!
    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCga= WHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPp= uYqPkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa= 0qhlo&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e= =3D


    __________________________________= _____________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org= /mailman/listinfo/id-event



    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf= .org/mailman/listinfo/id-event




    --001a114885820a7284055cf30366-- From nobody Wed Nov 1 15:06:44 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B4B13F6DF for ; Wed, 1 Nov 2017 15:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.987 X-Spam-Level: X-Spam-Status: No, score=-6.987 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poIzHlUHtjUi for ; Wed, 1 Nov 2017 15:06:37 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 2306F13F6A1 for ; Wed, 1 Nov 2017 15:06:37 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA1M6VmT003138 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Nov 2017 22:06:31 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA1M6VE7006214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Nov 2017 22:06:31 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vA1M6Uii006467; Wed, 1 Nov 2017 22:06:30 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 15:06:28 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-8E597DA8-8B5E-4598-A08C-D9E469A70D93 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 1 Nov 2017 15:06:25 -0700 Cc: William Denniss , "Richard Backman, Annabelle" , Yaron Sheffer , Mike Jones , ID Events Mailing List , Dick Hardt Content-Transfer-Encoding: 7bit Message-Id: References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> To: Marius Scurtescu X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 22:06:43 -0000 --Apple-Mail-8E597DA8-8B5E-4598-A08C-D9E469A70D93 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don't see multi variants. I see multiple parts For example you have all the risc events Not to support implicit federation users (which have to be identified by one= or more identifiers), you might define a utility event profile which contai= ns attributes for email, telephone, username etc. If you didn't get both parts of the set as one set it would have different m= eaning or be considered malformed.=20 The advantage in risc is not having to have a tonne of optional id attribute= s in every event.=20 The point here is reasonable flexibility for profilers to decide.=20 Finally i already gave the overlapped risc/scim password reset case.=20 Phil > On Nov 1, 2017, at 2:54 PM, Marius Scurtescu wrote= : >=20 >> On Wed, Nov 1, 2017 at 2:46 PM, William Denniss wro= te: >> Perhaps I can try and explain the original intent of the current design. T= he goal was always that a SET represents a single logical event. However mul= tiple systems may have different representations of the event =E2=80=93 the e= xample given originally was one formatted for RISC, and one for SCIM. >>=20 >> A good analogy is email. You send a single logical email, which may have t= wo representations, HTML and plain text. Systems can consume the version tha= t they understand and ignore the one they don't. >=20 > Yes, and I think this is well understood. >=20 > =20 >>=20 >> I'm starting to regret the plural in "events", it was pluralized due to i= t being an array, not because it represented multiple logical events. >=20 > I don't think this is the main concern or cause for confusion. >=20 > =20 >>=20 >> Annabelle, I understand your concerns regarding confusion of the semantic= s between the JSON syntax and the specification language. Are there other wa= ys to resolve that without removing the ability for multiple representations= of the same event? >=20 > The argument is that multiple representations can be sent as distinct SETs= , if really needed. In practice this will happen quite rare though. Events a= re created for a specific receiver, the receiver either wants the SCIM or th= e RISC flavor, and they should be able to specify that in configuration (the= re is a proposal how to capture that). >=20 > Do we have a compelling use case where a receiver must receive multiple va= riants all at once? >=20 > =20 >>=20 >>> On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu = wrote: >>>> On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt wrote= : >>>> You can=E2=80=99t really have multiple events (at least of the same typ= e). The current spec can only have one instance of a URI (afaik). =20 >>>>=20 >>>> Note that the spec normatively does not support multiple event SETS. I= t currently states: >>>>> events >>>>> The semantics of this claim is to define a set of event statemen= ts >>>>> that each MAY add additional claims to fully describe a single >>>>> logical event that has occurred (e.g. a state change to a >>>>> subject). Multiple event statements of the same type SHALL NOT b= e >>>>> accepted. The "events" claim SHOULD NOT be used to express >>>>> multiple logical events. >>>>=20 >>>> The spec has *always* supported requirements (as stated in the spec) fo= r multiple separate profile statements (from one or more profile familities)= needing to be sent as a single message. It would be INSECURE to force mult= iple SETs because the current delivery mechanism only allows one SET to be d= elivered at a time. There is no way to assure that a single receiver gets al= l of the SETs it needs in a multi-threaded, multi-node environment at scale.= Assembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a common state d= atabase is NOT simple nor cost effective. >>>=20 >>> I totally agree that it is difficult for receivers to receive separate e= vents, in no particular order and correlate based on "txn". But, receivers h= ave to solve this issue regardless of "events" or "event", so it is unrelate= d to this proposal. >>>=20 >>> =20 >>>>=20 >>>> If we accommodate this in the proposed form, we end up with a complex, d= eeply nested JSON structure with the possibility of namespace conflicts. >>>>=20 >>>> IMO The proposal does not simplify, it complicating and limiting. =20 >>>>=20 >>>> The current spec has very clean JSON and avoids namespace conflicts bet= ween profiles. I think we should stay on track with the current draft and ob= serve the normative text if not make it stronger in regards to multi-events (= understood that Mike may disagree). >>>>=20 >>>> Phil >>>>=20 >>>> Oracle Corporation, Identity Cloud Services Architect >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>> On Nov 1, 2017, at 12:18 PM, Richard Backman, Annabelle wrote: >>>>>=20 >>>>> Unless the profile guarantees that such related events will always be i= ncluded in the same SET, then the receiver has to correlate across SETs anyw= ay, and multiple events per SET is just giving the receiver another scenario= that they have to support. >>>>> =20 >>>>> I=E2=80=99ve already provided several other reasons why we should not s= upport multiple tokens per SET that no one has addressed. Here they are agai= n: >>>>> Multiple event support results in a more complex structure for the sin= gle event use case, which I think we all agree is the majority use case. >>>>> Multiple-event SETs have ambiguous semantics. The presence of two even= ts A and B in the same SET could mean any of: >>>>> A and B are related to the same logical event (i.e. the same thing as i= f they were from different SETs that have a common txn). >>>>> A is an extension of B. >>>>> B is an extension of A. >>>>> A is an alias for B, or vice-versa. >>>>> A and B are not actually related to one another in any way, and the tr= ansmitter bundled them together because they were going to the same receiver= . >>>>> Top-level claim semantics become harder to define, as different profil= es may want to use the same claims in different ways. >>>>> Event authenticity cannot be verified without having the entire SET. T= his forces receivers to expose downstream systems to more information necess= ary, if those systems need to be able to verify authenticity. >>>>> =20 >>>>> --=20 >>>>> Annabelle Richard Backman >>>>> Amazon =E2=80=93 Identity Services >>>>> =20 >>>>> =20 >>>>> From: Mike Jones >>>>> Date: Wednesday, November 1, 2017 at 11:21 AM >>>>> To: Dick Hardt >>>>> Cc: Yaron Sheffer , "Richard Backman, Annabelle= " , ID Events Mailing List , "Phil H= unt (IDM)" >>>>> Subject: RE: [Id-event] Use cases for multiple events per SET? >>>>> =20 >>>>> I completely agree on moving complexity to the issuer over the recipie= nt. In my view, it=E2=80=99s more complex for recipients to have to correla= te and process a sequence of multiple SETs providing information about the s= ame logical event, and validate N signatures, than to receive one SET with a= ll the aspects of the logical event as =E2=80=9Cevents=E2=80=9D fields, with= no correlation over time then required. >>>>> =20 >>>>> -- Mike >>>>> =20 >>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >>>>> Sent: Wednesday, November 1, 2017 9:39 AM >>>>> To: Mike Jones >>>>> Cc: Yaron Sheffer ; Richard Backman, Annabelle <= richanna@amazon.com>; ID Events Mailing List ; Phil Hunt (= IDM) >>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>> =20 >>>>> Your comments highlight a couple of points: >>>>> =20 >>>>> 1) The example is how to have a predefined extension point for extensi= ons of a specific event, it is not how to add another event. Myself, I think= this is overly complicated. Events should be comparatively static, and as w= ith many other JSON formats, the receiver should ignore properties it does n= ot understand, which let's new properties be introduced as extensions. There= should not be any conflict as extensions should only be done by the profile= that created the event format to start off with. >>>>> =20 >>>>> 2) Having an lvalue be a URI is much harder to code against. I'm not s= ure why Marius had that in his example. Per the event, the type of the event= is well defined with=20 >>>>> =20 >>>>> "event_type": "https://example.com/scim/event/passwordResetExt", >>>>> =20 >>>>> 3) This thread is about reasons for multiple events to be contained in= one set. Your mention of an issuer not wanting to sign separate events as a= reason to allow multiple events. I think we have decided that given a prefe= rence, we will push effort to the transmitter over the receiver as in many u= se cases there are many more receivers. Given that, it is more complex for a= receiver to have different ways of managing the receipt of multiple events a= s not all issuers will bundle the events, so it is simpler to have only one e= vent per SET. Including the separate events with a URI as an lvalue is chall= enging to implement, speaking from experience. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>> On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones wrote: >>>>>> Marius=E2=80=99 proposed syntax, pasted in below, has exactly this ch= aracteristic. The way I see it, his proposal essentially has a primary pass= wordReset event and a secondary passwordResetExt data structure, which could= have been simply another event value in the current draft. >>>>>> =20 >>>>>> This breaking change makes the data structures more complicated - not= less. And it makes things that used to be possible impossible, reducing fl= exibility to those who would use the spec. >>>>>> =20 >>>>>> These seem like bad tradeoffs to me. >>>>>> =20 >>>>>> { >>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>> "iat": 1458496025, >>>>>> "iss": "https://scim.example.com", >>>>>> "aud": [ >>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>> ], >>>>>> "event_type": "https://example.com/scim/event/passwordResetExt", >>>>>> "event": { =20 >>>>>> "id":"44f6142df96bd6ab61e7521d9", >>>>>> "extensions": { >>>>>> "https://example.com/scim/event/passwordResetExt=E2=80=9D:= { >>>>>> "resetAttempts":5, >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> =20 >>>>>> In particular, it makes it impossible to sign multiple related events= sharing a common claims schema with a single signature by the issuer. It f= orces the issuer to do the extra work of signing each of the related events (= or facets of the same logical event) individually and forces the recipients t= o do the extra work of checking all those unnecessary signatures. >>>>>> =20 >>>>>> Not every profile will ever have multiple keys in the =E2=80=9Cevents= =E2=80=9D set but there=E2=80=99s absolutely no reason to preclude it. >>>>>> =20 >>>>>> -- Mike >>>>>> =20 >>>>>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Dick H= ardt >>>>>> Sent: Tuesday, October 31, 2017 9:52 PM >>>>>> To: Mike Jones >>>>>> Cc: Yaron Sheffer ; Richard Backman, Annabelle= ; ID Events Mailing List ; Phil Hun= t (IDM) >>>>>>=20 >>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>> =20 >>>>>> Please direct me to a proposal that has a "primary" and "secondary" e= vents. I agree that is undesirable. I would also encourage to engage in the d= iscussions so that we can drive clarity and simplicity. >>>>>> =20 >>>>>> I think the proposal is that there is one event per SET. >>>>>> =20 >>>>>> I think having more than one event per SET adds complexity as a recei= ver must deal with receiving correlated events in one SET as well as correla= ted events in the same SET. >>>>>> =20 >>>>>> /Dick >>>>>> =20 >>>>>>> On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones wrote: >>>>>>> I hear you on the fact that different people have joined the effort a= t different times. That=E2=80=99s a normal process as an effort builds mome= ntum. I get that not everyone was there when previous consensus calls were t= aken. >>>>>>> =20 >>>>>>> I should note that I have specific technical objections to the speci= fic proposed changes being discussed as well. Currently all events in the s= et have the same syntax. The proposals, as I understand them, revert us to a= state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and =E2=80=9Csecond= ary=E2=80=9D events, with different syntax for the two classes. That=E2=80=99= s needlessly more complicated, adding no actual value. >>>>>>> =20 >>>>>>> -- M= ike >>>>>>> =20 >>>>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >>>>>>> Sent: Tuesday, October 31, 2017 9:37 PM >>>>>>> To: Mike Jones >>>>>>> Cc: Phil Hunt (IDM) ; Yaron Sheffer ; Richard Backman, Annabelle ; ID Events M= ailing List >>>>>>>=20 >>>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>>> =20 >>>>>>> Mike >>>>>>> =20 >>>>>>> As you well know, many people in a WG don't look closely at a specif= ication until last call is made. Additionally, we are coming up on only the 3= rd WG meeting. The WG has not existed for very long. While some of the parti= cipants have been working on this for a while, many have not, and we are loo= king for consensus across the WG. >>>>>>> =20 >>>>>>> Since SecEvent is a framework that we expect to be profiled, I feel i= t is important to ensure that SecEvent specifications are easy for a variety= of profiles to adopt, and that the semantics make sense. I also think that p= roperties that are specific to a profile should be left to that profile and n= ot be included in SecEvent. >>>>>>> =20 >>>>>>> Since this is a framework, it is expected that as different groups p= rofile it, there will be additional feedback. >>>>>>> =20 >>>>>>> Specifically, as a participant in the RISC profile of SET, a number o= f issues in SET have surfaced as the RISC WG has looked at how to use the SE= T. >>>>>>> =20 >>>>>>> As for SET being stable for over a year, there have been a number of= changes to SET since then. I also don't think there was consensus. Before t= he WG was formed, I and several others had expressed concern on the design o= f SET when Phil presented it at an IIW session. >>>>>>> =20 >>>>>>> As to taking another year, I am hopeful we can resolve the remaining= issues in SET and publish a new draft for last call. I do not think we will= need to wait for another WG meeting to ask for last call.=20 >>>>>>> =20 >>>>>>> We also have a number of other documents that are not in last call, a= nd we don't have a WG adopted draft yet for management. So there are still a= number of documents to work through before we have all the bits for someone= to work with. >>>>>>> =20 >>>>>>> I do think we have been making good progress since the last IETF mee= ting, and I am hopeful we can keep up this momentum and finalize all the doc= uments in a timely manner. >>>>>>> =20 >>>>>>> /Dick >>>>>>> =20 >>>>>>> =20 >>>>>>>> On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones wrote: >>>>>>>> It=E2=80=99s hard for me to even express my level of frustration wi= th the recent attempts to once again redesign the SecEvent Token spec. We=E2= =80=99ve been at this for multiple years because people keep trying to revis= it decisions that were long ago made by consensus. It=E2=80=99s been stable= for over a year and the majority of WGLC respondents said some variant of =E2= =80=9CWorks for me =E2=80=93 ship it!=E2=80=9D >>>>>>>> =20 >>>>>>>> There=E2=80=99s not sufficient justification to try to undo consens= us positions that have been debated and affirmed over and over. Countenanci= ng wholesale changes at this late date is counterproductive in the extreme! >>>>>>>> =20 >>>>>>>> It=E2=80=99s far better than good enough as-is. In my experience, i= f we start redesigning it, it will result in another year=E2=80=99s delay. I= t does something simple and useful. Please, let=E2=80=99s just ship it, so p= eople can rely on it. >>>>>>>> =20 >>>>>>>> -- Mike >>>>>>>> =20 >>>>>>>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20 >>>>>>>> Sent: Monday, October 30, 2017 2:42 PM >>>>>>>> To: Dick Hardt >>>>>>>> Cc: Yaron Sheffer ; Richard Backman, Annabel= le ; Mike Jones ; ID Event= s Mailing List >>>>>>>>=20 >>>>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>>>> =20 >>>>>>>> Inline... >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Oct 30, 2017, at 2:22 PM, Dick Hardt wro= te: >>>>>>>>> Hi Phil >>>>>>>>> =20 >>>>>>>>> Correct me if I am misunderstanding, but there is a RISC profile e= vent=20 >>>>>>>>> =20 >>>>>>>>> "http://schemas.openid.net/secevent/risc/event-type/account-creden= tial-change-required=E2=80=9D >>>>>>>>> =20 >>>>>>>>> and an SCIM profile event >>>>>>>>> =20 >>>>>>>>> "https://example.com/scim/event/passwordResetExt=E2=80=9D >>>>>>>>> =20 >>>>>>>>> I'm suggesting that two different events would be sent. Embedding o= ne in the other does not make sense. >>>>>>>> It is a hypothetical example. Just because you disagree on this= does not mean others are not valid.=20 >>>>>>>> =20 >>>>>>>> I just picked overlapping proposals that have different meaning (bu= t not the same) to illustrate the difference from issuing a single set with d= ifferent events.=20 >>>>>>>> =20 >>>>>>>> As I have stated this is very different from asserting multiple dis= tinct events in one SET.=20 >>>>>>>>=20 >>>>>>>>> =20 >>>>>>>>> Also, I think it is simpler to have event_type be at the same leve= l as event >>>>>>>> =20 >>>>>>>> may be. I was working from Annabelle's proposed format.=20 >>>>>>>>=20 >>>>>>>>> =20 >>>>>>>>> { >>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>> "iat": 1458496025, >>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>> "aud": [ >>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>> ], >>>>>>>>> "event_type": "https://example.com/scim/event/passwordResetExt"= , >>>>>>>>> "event": { =20 >>>>>>>>> "id":"44f6142df96bd6ab61e7521d9", >>>>>>>>> "resetAttempts":5 >>>>>>>>> } >>>>>>>>> } >>>>>>>>> =20 >>>>>>>>> { >>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>> "iat": 1458496025, >>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>> "aud": [ >>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>> ], >>>>>>>>> "event_type": "http://schemas.openid.net/secevent/risc/event-ty= pe/account-credential-change-required", >>>>>>>>> "event": { >>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" =20 >>>>>>>>> } >>>>>>>>> } >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>>> On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt wrote: >>>>>>>>>> Annabelle/Dick, >>>>>>>>>> =20 >>>>>>>>>> Thanks for the comments. I think we need to examine the consequen= ces of the proposal in JSON. >>>>>>>>>> =20 >>>>>>>>>> As I stated, what causes most of the issue is the proposed extens= ion mechanism in the payload (possibly using events in a recursive way). Doe= s it follow the old format or the new? >>>>>>>>>> =20 >>>>>>>>>> Let=E2=80=99s consider a use case where we have an identity mana= gement system that uses SCIM, but the SCIM system is also the underlying dat= a store for Connect. A Password reset might generate the following event wh= ich has an extension (conveying reset count) AND overlapping statement from R= ISC. BOTH of which might be important to a similar receiver using SCIM and O= IDC. =20 >>>>>>>>>> =20 >>>>>>>>>> The 03 spec currently would allow: >>>>>>>>>> =20 >>>>>>>>>> { >>>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>>> "iat": 1458496025, >>>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>>> "aud": [ >>>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>>> ], >>>>>>>>>> "events": { >>>>>>>>>> "urn:ietf:params:scim:event:passwordReset": >>>>>>>>>> { "id":"44f6142df96bd6ab61e7521d9"}, >>>>>>>>>> "https://example.com/scim/event/passwordResetExt": >>>>>>>>>> { "resetAttempts":5}, >>>>>>>>>> "http://schemas.openid.net/secevent/risc/event-type/\ >>>>>>>>>> account-credential-change-required": { >>>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> =20 >>>>>>>>>> In the above - each payload is a =E2=80=98peer' and issued withou= t preference by the transmitter. The receiver can assign priority in its own= context if that matters. >>>>>>>>>> =20 >>>>>>>>>> The new proposal: >>>>>>>>>> =20 >>>>>>>>>> { >>>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>>> "iat": 1458496025, >>>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>>> "aud": [ >>>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>>> ], >>>>>>>>>> "event": { >>>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:pas= swordReset=E2=80=9D, >>>>>>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>>>>>> ->note =E2=80=A6is this the old or new structure? <- >>>>>>>>>> "https://example.com/scim/event/passwordResetExt": >>>>>>>>>> { "resetAttempts":5}, >>>>>>>>>> "http://schemas.openid.net/secevent/risc/event-type/\ >>>>>>>>>> account-credential-change-required": { >>>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> } =20 >>>>>>>>>> } >>>>>>>>>> =20 >>>>>>>>>> In the above, sub-events or extensions have a different format. T= he same complaint about the original stands. >>>>>>>>>> =20 >>>>>>>>>> *OR* (if the receiver cares about RISC more). Note that this lea= ds to a triple nested structure. >>>>>>>>>> =20 >>>>>>>>>> { >>>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>>> "iat": 1458496025, >>>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>>> "aud": [ >>>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>>> ], >>>>>>>>>> "event": { >>>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/sece= vent/risc/event-type/\ >>>>>>>>>> account-credential-change-required=E2=80=9D, >>>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >>>>>>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>>>>>> "urn:ietf:params:scim:event:passwordReset": >>>>>>>>>> {=20 >>>>>>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>>>>>> "https://example.com/scim/event/passwordResetExt": >>>>>>>>>> { "resetAttempts":5}, =20 >>>>>>>>>> } =20 >>>>>>>>>> } >>>>>>>>>> } =20 >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> =20 >>>>>>>>>> In the above, the extension is placed inside the event it extends= . It follows the old format (or should it follow the new?) >>>>>>>>>> *OR* Following the top layer pattern of singular event Note that= this leads to a triple nested structure. >>>>>>>>>> =20 >>>>>>>>>> { >>>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>>> "iat": 1458496025, >>>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>>> "aud": [ >>>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>>> ], >>>>>>>>>> "event": { >>>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/sece= vent/risc/event-type/\ >>>>>>>>>> account-credential-change-required=E2=80=9D, >>>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >>>>>>>>>> =E2=80=9Cevent=E2=80=9D:{ >>>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:= passwordReset=E2=80=9D, >>>>>>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>>>>>> =E2=80=9Cevent=E2=80=9D:{ >>>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/= event/passwordResetExt=E2=80=9D, >>>>>>>>>> "resetAttempts":5=20 >>>>>>>>>> } >>>>>>>>>> } =20 >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> =20 >>>>>>>>>> This format follows the proposed singular event format recursivel= y and is 3 layers deep. Note that the parser has to continue to search the d= ocument for things that aren=E2=80=99t there as it has to stop when no =E2=80= =9Cevent=E2=80=9D attribute is found rather than iterate over an array. >>>>>>>>>> =20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>> =20 >>>>>>>>>>> On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle wrote: >>>>>>>>>>> =20 >>>>>>>>>>> Replies inline. >>>>>>>>>>> =20 >>>>>>>>>>> --=20 >>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>> Identity Services >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>> From: Phil Hunt >>>>>>>>>>> Date: Sunday, October 29, 2017 at 5:25 PM >>>>>>>>>>> To: Dick Hardt >>>>>>>>>>> Cc: Yaron Sheffer , Mike Jones , "Richard Backman, Annabelle" , ID E= vents Mailing List >>>>>>>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>>>>>>> =20 >>>>>>>>>>> I hope this answers your question. >>>>>>>>>>> =20 >>>>>>>>>>> My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reaso= n why not. The question should be, what is the justification to make =E2=80=9C= events=E2=80=9D singular? >>>>>>>>>>> [richanna]The singular =E2=80=9Cevent=E2=80=9D claim has clearer= semantics and is easier to process. We should opt for easier solutions unle= ss there are use cases that require more complexity.[/richanna] >>>>>>>>>>> =20 >>>>>>>>>>> There are many reasons for multiple events in a SET. Some are g= ood, some not so good. Some of the reasons... >>>>>>>>>>> =20 >>>>>>>>>>> 1. Multiple event payloads expressing statements about largely t= he *same*thing. For example, SCIM password reset AND RISC password reset. A= RISC Event and an OpenBanking Event. Is one a complement to the other? Do t= hey overlap or are they distinct? =20 >>>>>>>>>>> [richanna]Copy/pasted from my earlier email: >>>>>>>>>>> Why is it necessary or appropriate to include these events in th= e same SET? They are likely being generated by different systems at differen= t times on the transmitter=E2=80=99s side, consumed by different systems on t= he receiver=E2=80=99s side, and possibly being transmitted over different ev= ent streams. I know the latter would be the case for us, as a receiver. Even= if it=E2=80=99s not, is it burdensome to send these events separately? What= value is gained in combining them? >>>>>>>>>>> =20 >>>>>>>>>>> Additionally, since the signature is over the SET and not the ev= ent objects, Receivers independently route separate events from a single tok= en without either losing the ability to verify the authenticity of the event= or sharing all information in the SET with every system handling any event i= n the token.[/richanna] >>>>>>>>>>> =20 >>>>>>>>>>> 2. Multiple events payloads expressing different statements abo= ut the same transaction - RISC Password Reset and RISC Session Cancel >>>>>>>>>>> [richanna]Same as above[/richanna] >>>>>>>>>>>=20 >>>>>>>>>>> 3. A new profile defines new event attributes to be added on to= an existing event type (a pure extension)=20 >>>>>>>>>>> [richanna]I have suggested a way to support extensions within an= event body, multiple times now. If you see problems with it, please point t= hem out.[/richanna] >>>>>>>>>>> =20 >>>>>>>>>>> I think it is quite valid to allow 1 and 3. 2 could be limited b= y specific profiles like RISC if they want. >>>>>>>>>>> =20 >>>>>>>>>>> I am not in agreement that making event singular simplifies anyt= hing. For one is makes extensions complex (another nested JSON structure) an= d potentially conflicting.=20 >>>>>>>>>>> [richanna] >>>>>>>>>>> Ways that multiple-event SETs are more complicated: >>>>>>>>>>> It results in a more complex structure for the single event use c= ase, which I think we all agree is the majority use case. >>>>>>>>>>> Multiple-event SETs have ambiguous semantics. The presence of tw= o events A and B in the same SET could mean any of: >>>>>>>>>>> They are related to the same logical event (i.e. the same thing a= s if they were from different SETs that have a common txn). >>>>>>>>>>> A is an extension of B. >>>>>>>>>>> B is an extension of A. >>>>>>>>>>> They are aliases for one another. >>>>>>>>>>> They are not actually related to one another in any way. >>>>>>>>>>> Claim semantics become harder to define, as different profiles m= ay want to use the same claims in different ways. >>>>>>>>>>> =20 >>>>>>>>>>> If the WG wants to block 1 and 2 above, then I believe we have t= o establish an event registry to ensure new Event profiles do not overlap to= eliminate the need to express multiple events. >>>>>>>>>>> [richanna]I=E2=80=99m not sure what you mean by this. Are you re= ferring to event names? Those are already defined by the spec to be URIs.[/r= ichanna] >>>>>>>>>>> Phil >>>>>>>>>>> =20 >>>>>>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>>>>>> @independentid >>>>>>>>>>> www.independentid.com >>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>> =20 >>>>>>>>>>>> On Oct 29, 2017, at 4:12 PM, Dick Hardt w= rote: >>>>>>>>>>>> =20 >>>>>>>>>>>> Phil: >>>>>>>>>>>> =20 >>>>>>>>>>>> In your examples for having a plurality of events, you use the w= ord "may", which leads me to question if a plurality of events is really req= uired in SET. >>>>>>>>>>>> =20 >>>>>>>>>>>> You posit that it will be difficult for a distributed system to= correlate multiple SETs with the same "txn", but the distributed system wil= l certainly need to correlate events on the same subject -- correlating even= ts on the same "txn" on the same subject seems fairly simple. >>>>>>>>>>>> =20 >>>>>>>>>>>> I think that a receiver will need to correlate multiple SEts on= the same subject, so having multiple events in a SET is redundant, and adds= complexity with no clear benefit that I can see. >>>>>>>>>>>> =20 >>>>>>>>>>>> An implementor may choose to send multiple SETs, or send a sing= le SET with multiple events, so a receiver will need to support both. I pref= er we pick one way and minimize the code paths, and we will need to support c= orrelating across multiple SETs, so that seems the best mechanism. >>>>>>>>>>>> =20 >>>>>>>>>>>> Let me know if there is something I missed in my logic. >>>>>>>>>>>> =20 >>>>>>>>>>>> /Dick >>>>>>>>>>>> =20 >>>>>>>>>>>> =20 >>>>>>>>>>>>> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer wrote: >>>>>>>>>>>>> In that case, let's add text to that effect, e.g. we could add= to the definition of the "events" claim: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Profiling specifications SHOULD define the allowed event state= ments, and MAY restrict their number. For example, some profiles may require= this claim to contain only a single event statement. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Yaron >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 24/10/17 22:10, Mike Jones wrote: >>>>>>>>>>>>>> I agree with much of Phil=E2=80=99s rationale here. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> It=E2=80=99s fine for some profiles to say that the =E2=80=9C= events=E2=80=9D set must be a singleton. That doesn=E2=80=99t have to be tr= ue for all events. I think things are fine as-is. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> = -- Mike >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behal= f Of *Phil Hunt >>>>>>>>>>>>>> *Sent:* Monday, October 23, 2017 8:47 PM >>>>>>>>>>>>>> *To:* Richard Backman, Annabelle >>>>>>>>>>>>>> *Cc:* ID Events Mailing List >>>>>>>>>>>>>> *Subject:* Re: [Id-event] Use cases for multiple events per S= ET? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Annabelle, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I have a number of concerns with this proposal. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Profiling Independence / Keeping Event Payloads Independent >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Indicating that extensions should be handled by profiles lead= s to more inter-operability issues and more importantly intrudes on the Even= t payload space by suggesting a sub-schema creates potential limitations and= conflicts that may add to complexity later on. The current format allows a p= arser to discover and unload one or more JSON payloads which can each have i= ndependent structure. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> General extensions >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The proposal also rules out general purpose extensions not re= lated to any specific event. Given the emergence of items like GPRD, I would= not want to block the ability to add meta-data or other general purpose ite= ms. We can also anticipate some delivery scenarios where additional data mig= ht be required. Even though there is no current planned use, I see no good r= eason to rule this out. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Multiple Events =46rom Different Families (vs. Multiple Event= s from a single family like RISC) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> In our RISC session we discussed expressing multiple distinct= RISC events in one SET. The discussion was that only one RISC event at a ti= me. We did not discuss other event profiles. I don=E2=80=99t see a reason to= rule out multi-events from different families at the SET level. Each profil= e is expressing slightly different things about the same event. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I can forsee some cases where it is not clear which is the pr= imary and which is the extension. There may not be a clear winner. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> A couple of examples (these are necessarily real=E2=80=A6just= possibilities): >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> * It is probably useful to be able to express simlar/overlapp= ing events from different SET profiles in one SET. For example a Backchanne= l Logout & a RISC session cancel event. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> * SCIM may want to represent a single transaction as causing m= ultiple state changes in an event (e.g. a password change causes multiple ef= fects). Having to chase down multiple events and correlate by =E2=80=9Ctxn=E2= =80=9D would be challenging in a multi-threaded/multi-node delivery system. = The SCIM list has not discussed this, but I would not want to block this c= apability. IOW - Just because RISC does not want to express multiple events= does not make this true for other profiles. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> * We may wish to indicate a SCIM Password Reset was performed= and a Logout/session cancellation is expressed at the same time. The event= s are related but express different data. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Avoiding Confusion =46rom Similar Events Originating from the= Same Transaction >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> If events are sent separately, then more tracking of state (e= .g. by txn) would be required to ensure similar events are not mistaken or h= andled as repeats. While txn provides useful audit analysis capability, I=E2= =80=99m not sure it can be used in live or near-real time systems given dist= ributed multi-node, multi-threading architectures. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Previous Discussion >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I note that I originally raised having an attribute to design= ate primary event attribute to alleviate your concern, but this was not acce= pted. See: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> * https://www.ietf.org/mail-archive/web/id-event/current/msg0= 0406.html >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> * https://www.ietf.org/mail-archive/web/id-event/current/msg0= 0140.html >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The consensus, at least as I interpreted it is up to the rece= iver to figure this out based on the definitions it has for each event URI a= nd the profiles they represent. IOW - RISC is free to limit that only one RI= SC event be expressed at a time. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> @independentid >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> www.independentid.com >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle >>>>>>>>>>>>>> > wrote:= >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The current draft of the SET spec allows for expressing m= ultiple >>>>>>>>>>>>>> events within the same token, which introduces additional= complexity >>>>>>>>>>>>>> and room for ambiguous semantics. We=E2=80=99ve discussed= this in the OIDF >>>>>>>>>>>>>> RISC working group and the current consensus there is tha= t RISC will >>>>>>>>>>>>>> require that RISC events must be the only event in the SE= T, having >>>>>>>>>>>>>> identified ways to clearly and easily support the handful= of use >>>>>>>>>>>>>> cases for multiple events per token that people have rais= ed. With >>>>>>>>>>>>>> that context in mind, I propose striking the definition o= f the >>>>>>>>>>>>>> =E2=80=9Cevents=E2=80=9D claim from the Security Event To= ken spec, and replacing it >>>>>>>>>>>>>> with the following definition for an =E2=80=9Cevent=E2=80= =9D claim (singular): >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> event >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> A JSON object containing an "event_type" member whose val= ue is a URI >>>>>>>>>>>>>> representing a type of event defined in a Profiling Speci= fication. >>>>>>>>>>>>>> The object MAY otherwise be empty, or MAY contain additio= nal members >>>>>>>>>>>>>> as described by the Profiling Specification. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Here is the example SET from section 2.3, rewritten with t= his change >>>>>>>>>>>>>> mind: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> { >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> "jti": "4d3559ec67504aaba65d40b0363faad8", >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> "iat": 1458496404, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> "iss": "https://scim.example.com ", >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> "aud": [ >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> "https://scim.example.com/Feeds/98d52461fa5bbc879593= b7754", >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> "https://scim.example.com/Feeds/5d7604516b1d08641d76= 76ee7" >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> ], >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> "event": { >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> "event_type": "urn:ietf:params:scim:event:create", >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> "ref": "https://scim.example.com/Users/44f6142df96bd= 6ab61e7521d9", >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> "attributes": ["id", "name", "userName", "password",= "emails"] >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> } >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> } >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Does anyone in the working group have use cases for SETs t= hat cannot >>>>>>>>>>>>>> be met by this proposed text? Within RISC, we identified t= hree use >>>>>>>>>>>>>> cases, with solutions outlined below: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> ** >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> *Extensions* >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Event extension mechanisms can be defined internal to the= event >>>>>>>>>>>>>> object. A simple approach would be to define an =E2=80=9C= extensions=E2=80=9D member >>>>>>>>>>>>>> that is a list of event objects (or set resembling the =E2= =80=9Cevents=E2=80=9D >>>>>>>>>>>>>> claim as defined in the current spec). This has the advan= tage of >>>>>>>>>>>>>> making it clear in the data structure that there is a sin= gle primary >>>>>>>>>>>>>> event, with zero or more extensions. There is no room for= confusion >>>>>>>>>>>>>> over which event is primary, or if there is a primary eve= nt at all. >>>>>>>>>>>>>> I would be fine with adding something like this to my pro= posed text, >>>>>>>>>>>>>> if there is consensus that it is broadly useful. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> *Aliases* >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> This use case was brought up in the context of migrating c= lients >>>>>>>>>>>>>> from draft event names to standardized event names. In th= is case, >>>>>>>>>>>>>> the event transmitter can transmit two tokens for the log= ical event, >>>>>>>>>>>>>> one using the old name and another using the new name. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> *Related Events* >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The SET spec defines the txn claim as a means of correlat= ing >>>>>>>>>>>>>> independent tokens that relate to the same logical event.= >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Amazon =E2=80=93 Identity Services >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__ww= w.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQ= cxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Ds5= byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58= ZFd4eEZfgyoIY&e=3D >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> =20 >>>>>>>>>>>> --=20 >>>>>>>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I a= m working on! >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7q= IrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DYBCGlK9m= jjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=3DWrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001= fK02EXs&e=3D >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Id-event mailing list >>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.= org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qI= rMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DU-a5HBND0= HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=3DrvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm= 46QSz0&e=3D >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =20 >>>>>>>>> -- >>>>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am w= orking on! >>>>>>>>> _______________________________________________ >>>>>>>>> Id-event mailing list >>>>>>>>> Id-event@ietf.org >>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.or= g_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrM= UB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DiyVnrZmr9_u= GCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=3DOe0qfLEX83vtXM7Wl2cYBe-Gg1DVPjhXjVJkfhV= Rzwc&e=3D >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> =20 >>>>>>> -- >>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am wo= rking on! >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>> -- >>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am wor= king on! >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Subscribe to the HARDTWARE mail list to learn about projects I am work= ing on! >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65= eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZkt= cmagv5Ea21QEip4HXpEVKRa0qhlo&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0= &e=3D >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>>=20 >>=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI= _JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DuNiWQlyKGTu-9p5qJLR= S1F-3yKXpDAB7KtpkCDc_JCU&s=3DF8_j8RZDlbUP1p-1QfgOEnrZO-3Iag7Yul1NK1xp4Js&e=3D= --Apple-Mail-8E597DA8-8B5E-4598-A08C-D9E469A70D93 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    I don't see multi variants. I see mult= iple parts

    For example you have all the risc events

    Not to support implici= t federation users (which have to be identified by one or more identifiers),= you might define a utility event profile which contains attributes for emai= l, telephone, username etc.

    If you didn't get both parts of the set as one s= et it would have different meaning or be considered malformed. 
    The ad= vantage in risc is not having to have a tonne of optional id attributes in e= very event. 

    The point here is reasonable flexibility for profilers to= decide. 

    Finally i already gave the overlapped risc/scim password res= et case. 

    Phil

    On Nov 1, 2017, at 2:54 PM, Marius S= curtescu <mscurtescu@google.com<= /a>> wrote:

    =
    On Wed, Nov 1, 2017 at= 2:46 PM, William Denniss <wdenniss@google.com> wrote:
    Perhaps I can t= ry and explain the original intent of the current design. The goal was alway= s that a SET represents a single logical event. However multiple systems may= have different representations of the event =E2=80=93 the example given ori= ginally was one formatted for RISC, and one for SCIM.

    A g= ood analogy is email. You send a single logical email, which may have two re= presentations, HTML and plain text. Systems can consume the version that the= y understand and ignore the one they don't.
    Yes, and I think this is well understood.

     

    I'm starting to regret the plural in "events", it was pluralized due t= o it being an array, not because it represented multiple logical events.

    I don't think this is the main conc= ern or cause for confusion.

     

    Annabelle, I underst= and your concerns regarding confusion of the semantics between the JSON synt= ax and the specification language. Are there other ways to resolve that with= out removing the ability for multiple representations of the same event?

    The argument is that multiple repre= sentations can be sent as distinct SETs, if really needed. In practice this w= ill happen quite rare though. Events are created for a specific receiver, th= e receiver either wants the SCIM or the RISC flavor, and they should be able= to specify that in configuration (there is a proposal how to capture that).=

    Do we have a compelling use case where a receiver m= ust receive multiple variants all at once?

     

    On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
    On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
    You can=E2=80=99t really have multiple events (at least of the same type)= .  The current spec can only have one instance of a URI (afaik).  =

    Note that the spec normatively does not support multiple= event SETS.  It currently states:
    events
      The semantics of this claim is to define a set of event statements
      that each MAY add additional claims to fully describe a single
      logical event that has occurred (e.g. a state change to a
      subject).  Multiple event statements of the same type SHALL NOT be
      accepted.  The "events" claim SHOULD NOT be used to express
      multiple logical events.

    The spe= c has *always* supported requirements (as stated in the spec) for multiple s= eparate profile statements (from one or more profile familities) needing to b= e sent as a single message.  It would be INSECURE to force multiple SET= s because the current delivery mechanism only allows one SET to be delivered= at a time. There is no way to assure that a single receiver gets all of the= SETs it needs in a multi-threaded, multi-node environment at scale.  A= ssembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a common state dat= abase is NOT simple nor cost effective.
    =

    I totally agree that it is difficult for receivers to re= ceive separate events, in no particular order and correlate based on "txn". B= ut, receivers have to solve this issue regardless of "events" or "event", so= it is unrelated to this proposal.

     

    If we accommodate this in the proposed form, we end up with a= complex, deeply nested JSON structure with the possibility of namespace con= flicts.

    IMO The proposal does not simplify, it comp= licating and limiting.  

    The current spec has v= ery clean JSON and avoids namespace conflicts between profiles. I think we s= hould stay on track with the current draft and observe the normative text if= not make it stronger in regards to multi-events (understood that Mike may d= isagree).

    Phil
    <= div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-in= dent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:b= reak-word">

    Oracle Corporation, Ide= ntity Cloud Services Architect
    @independentid
    phil.hunt@oracle.com

    On Nov 1, 2017, at 12:18 PM, Richard= Backman, Annabelle <rich= anna@amazon.com> wrote:

    Unless the profile guarantees th= at such related events will always be included in the same SET, then the rec= eiver has to correlate across SETs anyway, and multiple events per SET is ju= st giving the receiver another scenario that they have to support.=
     
    I=E2=80=99ve already p= rovided several other reasons why we should not support multiple tokens per S= ET that no one has addressed. Here they are again:
    1. Multiple event support results in a more complex structure for th= e single event use case, which I think we all agree is the majority use case= .
    2. Multiple-event SETs have ambiguou= s semantics. The presence of two events A and B in the same SET could mean a= ny of:
      1. A and B are related to the same logical= event (i.e. the same thing as if they were from different SETs that have a c= ommon txn).
      2. A is an extension of B.=
      3. B is an extension of A.<= /u>
      4. A is an alias for B, or vice-versa.=
      5. A and B are not actually related to one anot= her in any way, and the transmitter bundled them together because they were g= oing to the same receiver.
    3. Event authenticity cannot be verified without having the enti= re SET. This forces receivers to expose downstream systems to more informati= on necessary, if those systems need to be able to verify authenticity.
     
    -- =
    Annabelle Richard Backman
    Amazon =E2= =80=93 Identity Services
    &nb= sp;
     
    From: Mike J= ones <Michael.Jon= es@microsoft.com>
    Date: <= /b>Wednesday, November 1, 2017 at 11:21 AM
    To:dick.hardt@gmail.com>
    Cc: = ;Yaron Sheffer <yaronf.ietf@gmail.com>, "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events= Mailing List <id-event@iet= f.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
    Subject: 
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif">I completely agree on moving comp= lexity to the issuer over the recipient.  In my view, it=E2=80=99s more= complex for recipients to have to correlate and process a sequence of multi= ple SETs providing information about the same logical event, and validate N s= ignatures, than to receive one SET with all the aspects of the logical event= as =E2=80=9Cevents=E2=80=9D fields, with no correlation over time then requ= ired.
    =  
                &nb= sp;            &= nbsp;           =             &nbs= p;     -- Mike
    =
    From: Dick Hardt [mailto:dick.hardt@gmail.com= ] 
    Sent: Wednesday, November 1, 2017 9:39 AM
    To: Mike Jones <Michael.Jones@microsoft.com>
    Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman,= Annabelle <richanna@amaz= on.com>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt (IDM) <phil.hunt@oracle.com>
    Subject:=  Re: [Id-event] Use cases for mult= iple events per SET?
     
    <= div>
    Your comments highlight a couple of points:<= /div>
     
    1) Th= e example is how to have a predefined extension point for extensions of a sp= ecific event, it is not how to add another event. Myself, I think this is ov= erly complicated. Events should be comparatively static, and as with many ot= her JSON formats, the receiver should ignore properties it does not understa= nd, which let's new properties be introduced as extensions. There should not= be any conflict as extensions should only be done by the profile that creat= ed the event format to start off with.
    2) Having an lvalue be a URI= is much harder to code against. I'm not sure why Marius had that in his exa= mple. Per the event, the type of the event is well defined with =
     
     
    3) This thread is about reasons for multiple events to be contained in on= e set. Your mention of an issuer not wanting to sign separate events as a re= ason to allow multiple events. I think we have decided that given a preferen= ce, we will push effort to the transmitter over the receiver as in many use c= ases there are many more receivers. Given that, it is more complex for a rec= eiver to have different ways of managing the receipt of multiple events as n= ot all issuers will bundle the events, so it is simpler to have only one eve= nt per SET. Including the separate events with a URI as an lvalue is challen= ging to implement, speaking from experience.
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif"> 
     
     
     =
     
     
     <= u>
     
    &nbs= p;
     
     
     
    On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:=
    Marius=E2=80=99 proposed syntax, pasted in below, has exactly th= is characteristic.  The way I see it, his proposal essentially has a pr= imary passwordReset event and a secondary passwordResetExt data structure, w= hich could have been simply another event value in the current draft.=
     
    This breaki= ng change makes the data structures more complicated - not less.  And i= t makes things that used to be possible impossible, reducing flexibility to t= hose who would use the spec.
     
    These seem like bad tradeoffs to me.
     <= /u>
    {
      "jti": "3d0c3cf797584bd193bd0fb1bd4e7<= wbr>d30",
      "iat": 1458496025,<= /u>
      "aud": [
        "<= a href=3D"https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" style=3D= "color:purple;text-decoration:underline" class=3D"m_-3151445958451029318m_74= 76346946956833004cremed cremed" target=3D"_blank">https://jhub.example.com/Fe= eds/5d7604516b1d08641d7676ee7"
    <= span style=3D"font-size:9.5pt;font-family:'Courier New',serif">   = ],
       "event": {  <= u>
             "extensions":= {
            &= nbsp;    "resetAttempts":5,
        &n= bsp;      }
           = ;  }
           }<= u>
     <= u>
    Since SecEvent is a framework that we= expect to be profiled, I feel it is important to ensure that SecEvent speci= fications are easy for a variety of profiles to adopt, and that the semantic= s make sense. I also think that properties that are specific to a profile sh= ould be left to that profile and not be included in SecEvent.<= /div>
     
    Since= this is a framework, it is expected that as different groups profile it, th= ere will be additional feedback.
    &nbs= p;
    Specifically, as a participant in t= he RISC profile of SET, a number of issues in SET have surfaced as the RISC W= G has looked at how to use the SET.
    &= nbsp;
    As for SET being stable for ove= r a year, there have been a number of changes to SET since then. I also don'= t think there was consensus. Before the WG was formed, I and several others h= ad expressed concern on the design of SET when Phil presented it at an IIW s= ession.
     
    As to taking another year, I am hopeful we can resolve the r= emaining issues in SET and publish a new draft for last call. I do not think= we will need to wait for another WG meeting to ask for last call. <= /u>
     
    We also have a number of other documents that are not in last call, an= d we don't have a WG adopted draft yet for management. So there are still a n= umber of documents to work through before we have all the bits for someone t= o work with.
     
    I do think we have been making good progress since the= last IETF meeting, and I am hopeful we can keep up this momentum and finali= ze all the documents in a timely manner.
     
    /Dick
     
     =
    On Tue, Oct 31, 2017 at 12:48 PM, Mike Jon= es <Michael.Jones@microsoft.com> wrot= e:
    It=E2=80=99s hard for me to even express my level of= frustration with the recent attempts to once again redesign the SecEvent To= ken spec.  We=E2=80=99ve been at this for multiple years because people= keep trying to revisit decisions that were long ago made by consensus. = ; It=E2=80=99s been stable for over a year and the majority of WGLC responde= nts said some variant of =E2=80=9CWorks for me =E2=80=93 ship it!=E2=80=9D
     <= /span>
    There=E2= =80=99s not sufficient justification to try to undo consensus positions that= have been debated and affirmed over and over.  Countenancing wholesale= changes at this late date is counterproductive in the extreme!
     
    It=E2=80=99s far b= etter than good enough as-is.  In my experience, if we start redesignin= g it, it will result in another year=E2=80=99s delay.  It does somethin= g simple and useful.  Please, let=E2=80=99s just ship it, so people can= rely on it.
     
               &n= bsp;            =             = ;            &nb= sp;      -- Mike
    From: Phil Hunt (I= DM) [mailto:phil.hunt@oracle.com] 
    Sent: Monday, October 30, 2017 2:42 PM
    To:&nb= sp;Dick Hardt <dick.hardt@gmail.com><= br>Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle &= lt;richanna@amazon.com>; Mike Jones <Michael.Jones@microsoft.com>; ID Events Mailing Li= st <id-event@ietf.org>
    <= div>

    Subject: Re: [= Id-event] Use cases for multiple events per SET?
     
    I= nline...

    Phil

    On Oct 30, 2017, at 2:22 PM, Dick Hardt <dick= .hardt@gmail.com> wrote:

    Hi Phil<= u>
     
    Correct me if I am misunderstanding, but there is a RISC profile event&nb= sp;
     
    "http://schemas.openid.net/secevent/risc=
/event-type/account-credential-change-required=E2=80=9D
     
    and a= n SCIM profile event
     <= /u>
    I'm suggesting that two different events would be= sent. Embedding one in the other does not make sense.
    <ph>It is a hypothetical example= . Just because you disagree on this does not mean others are not valid. = ;
     
    I just picked overlapping proposals that have different meaning (but no= t the same) to illustrate the difference from issuing a single set with diff= erent events. 
     <= /u>

    As I have stated this is very dif= ferent from asserting multiple distinct events in one SET. 

    <= div>
     
    Also, I= think it is simpler to have event_type be at the same level as event=
     

    <ph>may be. I was working from An= nabelle's proposed format. 

     =
    {
      "jti": "3d0c3cf797584bd193bd0fb1bd4= e7d30",
      "iat": 1458496025,
    &= nbsp; "iss": "https://scim.example.com",
      "aud": [
       ],=
      &= nbsp;"event": {  
            &nbs= p;"id":"44f6142df96bd6ab61e7521d9",
        &nb= sp;    "resetAttempts":5
          &n= bsp;}
    }
    &nbs= p;
    {
      "jti": "3d0c3cf797584bd193bd0fb1bd4= e7d30",
      "iat": 1458496025,
    &= nbsp; "iss": "https://scim.example.com",
      "aud": [
       ],=
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif">   "event"= : {
           =E2=80=9Csub=E2=80=9D:=E2=80= =9D7375626A656374=E2=80=9D,
           =E2=80= =9Ciss=E2=80=9D:"https://idp.example.com/" =      
           }<= u>
    }
     
     
     
     
     
    On Mon, O= ct 30, 2017 at 12:09 PM, Phil Hunt <phil.hunt@oracl= e.com> wrote:
    Annabelle/Dick,
     <= u>
    Thanks for the comments. I think we need to e= xamine the consequences of the proposal in JSON.
     
    As I stated, what cause= s most of the issue is the proposed extension mechanism in the payload (poss= ibly using events in a recursive way). Does it follow the old format or the n= ew?
     
    Let=E2=80=99s  consider a use case where we have an identity man= agement system that uses SCIM, but the SCIM system is also the underlying da= ta store for Connect.  A Password reset might generate the following ev= ent which has an extension (conveying reset count) AND overlapping statement= from RISC.  BOTH of which might be important to a similar receiver usi= ng SCIM and OIDC.  
     
    The 03 spec currently would allow:<= u>
     
    = 
    {
      "jti": "3d0c3cf797584bd193bd=
0fb1bd4e7d30",
      "iat": 1458496025,
      "iss": "https://scim.=
example.com",
      "aud": [=

        "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",=

        "https://jhub.example.com/Feeds/5d7604516b1d086=
41d7676ee7"
       ],
       "events": {
     &n=
bsp;   "urn:ietf:params:scim:event:passwordReset":<=
/u>
           { "id":"44f6142df96b=
d6ab61e7521d9"},
         "=
https://example.com/scim/even=
t/passwordResetExt":
       &nbs=
p;   { "resetAttempts":5},
         "h=
ttp://schemas.openid.net/secevent/risc/event-type/\
       =
;    account-credential-change-required": {    <=
/u>
        &n=
bsp;    =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D=
,
     &=
nbsp;       =E2=80=9Ciss=E2=80=9D:"https://idp.example.com=
/"
    &n=
bsp;      }
      }
    }
     <=
/u>
    I=
n the above - each payload is a =E2=80=98peer' and issued without preference=
 by the transmitter. The receiver can assign priority in its own context if t=
hat matters.
     
    The new proposal:
     =

    {
      "jti": "3=
d0c3cf797584bd193bd0fb1bd4e7d30",
      "=
iat": 1458496025,
      "iss": "https://scim.example.com",
      "au=
d": [
        "https://jhub.example.com/Feeds/98d52461fa=
5bbc879593b7754",
        "https://jhub.example.com/Feed<=
wbr>s/5d7604516b1d08641d7676ee7"
     &nbs=
p; ],
       "event": {
         =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:p=
arams:scim:event:passwordReset=E2=80=9D,
    &nb=
sp;    "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,=

         =E2=80=9Cevents=E2=80=
=9D:{
         ->note =E2=80=
=A6is this the old or new structure? <-
    &nbs=
p;      "=
https://example.com/scim/event/passwordResetExt":
             { "resetAttempts=
":5},
     &nbs=
p;     "http://schemas.openid.=
net/secevent/risc/event-type/\
            &=
nbsp;account-credential-change-required": {
    <=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courier New=
',serif">      =
   =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,<=
u>
      &nbs=
p;      =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/"
      =
     }
         }
       }    <=
u>
    }<=
u>
     
    In the above, sub-events or extensions have a=
 different format. The same complaint about the original stands.
     
    *OR* (if the receiver cares about RISC mo=
re).  Note that this leads to a triple nested structure.<=
/u>
     
    {
      "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
      "iat": 1458496025,
      "iss": "https://scim.example.com",=

      "aud": [
     &n=
bsp;  "https://jhub.=
example.com/Feeds/98d52461fa5bbc879593b7754",
        "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
       ],
     &nbs=
p; "event": {
         =E2=80=9C=
event_type=E2=80=9D:"http://schemas.openid.net/secevent/risc/event-type/\
       =
          account-credential-change-=
required=E2=80=9D,<=
u>
       &nb=
sp;  =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,<=
/u>
       &n=
bsp;  =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C,
       =
;   =E2=80=9Cevents=E2=80=9D:{
            "=
urn:ietf:params:scim:event:passwordReset":
          &=
nbsp; { 
        &n=
bsp;     "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=
=80=9D,
          &nb=
sp;   =E2=80=9Cevents=E2=80=9D:{
    &nbs=
p;            "https://example.com/scim/event/pass=
wordResetExt":
        &nbs=
p;          { "resetAttempts":5=
},  
           =
   }      
            }<=
/u>
          }   &=
nbsp; 
     &nb=
sp; }
    }
     
    In the abov=
e, the extension is placed inside the event it extends. It follows the old f=
ormat (or should it follow the new?)
    *OR* Following t=
he top layer pattern of singular event  Note that this leads to a tripl=
e nested structure.
     =

    {
      "jti": "3d0c3cf797=
584bd193bd0fb1bd4e7d30",
      "iat": 145=
8496025,
      "iss": "htt=
ps://scim.example.com",
      "aud": [
        "https://jhub.example.com/Feeds/98d52461fa5bbc879593=
b7754",
        "https://jhub.example.com/Feeds/5d76=
04516b1d08641d7676ee7"
       ],
       "event": {
    "http://schemas.openid.net/secev=
ent/risc/event-type/\
      &n=
bsp;          account-credential-cha=
nge-required=E2=80=9D,<=
/u>
        =
  =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,=

          =E2=80=9Ciss=E2=80=9D:=
"https://idp.exam=
ple.com/=E2=80=9C,
          =E2=80=9Cevent=E2=80=9D:{
      =
;      =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:param=
s:scim:event:passwordReset=E2=80=9D,
            <=
/span>"id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
            =E2=80=9Cevent=E2=80=
=9D:{
           =
;   =E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/event/passwordResetExt=E2=80=
=9D,
           =
   "resetAttempts":5 
           &nbs=
p;}
          } =
;    
       }
    }
     
    This format fo=
llows the proposed singular event format recursively and is 3 layers deep. N=
ote that the parser has to continue to search the document for things that a=
ren=E2=80=99t there as it has to stop when no =E2=80=9Cevent=E2=80=9D attrib=
ute is found rather than iterate over an array.
     
    Phil

    Oracl= e Corporation, Identity Cloud Services Architect
    @independentid
    www.indep= endentid.com
    phil.hunt@oracle.com=
     
    On O= ct 30, 2017, at 8:57 AM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
     =
    Replies inline.=
     =
    -- 
    Annabelle Richard Backman
    Identity Services=
     <= u>
     <= u>
    From: Phil= Hunt <phil.hunt@oracl= e.com>
    Date: Sunday, October 29, 2017 at 5:25 PM
    To: Dick Hardt <dick.hardt@gmail.com>
    Cc: Yaron Sheffer <yaronf.ietf@gmail.com    >, Mike Jones &l= t;Michael.Jones@mi= crosoft.com>, "Richard Backman, Annabelle" <richanna@amazon.com>, ID Ev= ents Mailing List <id-eve= nt@ietf.org>
    Subject:&nb= sp;Re: [Id-event] Use cases for multiple events per SET?
    &nbs= p;
    = I hope this answers your question.
    =
     
    <= div>
    My =E2=80=9Cmay=E2=80=9D was because I c= an=E2=80=99t see a reason why not. The question should be, what is the justi= fication to make =E2=80=9Cevents=E2=80=9D singular?
    = [richanna]The singular =E2=80=9Cevent=E2=80=9D claim has clearer semantics a= nd is easier to process. We should opt for easier solutions unless there are= use cases that require more complexity.[/richanna]
     =
    There are many r= easons for multiple events in a SET.  Some are good, some not so good. S= ome of the reasons...
     
    1.  Multiple event payloads expressing statement= s about largely the *same*thing. For example, SCIM password reset AND RISC p= assword reset.  A RISC Event and an OpenBanking Event. Is one a complem= ent to the other?  Do they overlap or are they distinct?  <= u>
    [richanna]Copy/pasted from my earlier email:<= u>
    Why is it necessary or appropriate to include these events i= n the same SET? They are likely being generated by different systems at diff= erent times on the transmitter=E2=80=99s side, consumed by different systems= on the receiver=E2=80=99s side, and possibly being transmitted over differe= nt event streams. I know the latter would be the case for us, as a receiver.= Even if it=E2=80=99s not, is it burdensome to send these events separately?= What value is gained in combining them?
    &nbs= p;
    Additionally, since the signature is over t= he SET and not the event objects, Receivers independently route separate eve= nts from a single token without either losing the ability to verify the auth= enticity of the event or sharing all information in the SET with every syste= m handling any event in the token.[/richanna]
     

    2.  Multiple events payloads expressing different s= tatements about the same transaction - RISC Password Reset and RISC Session C= ancel
    [richanna]Same as above[/rich= anna]

    3.  A new profile defines new event attributes to be added on t= o an existing event type (a pure extension) 
    [richanna]I have suggested a way to support extensions within= an event body, multiple times now. If you see problems with it, please poin= t them out.[/richanna]
     
    I think it is quite valid to allow 1 and 3. &n= bsp;2 could be limited by specific profiles like RISC if they want.
     
    I am no= t in agreement that making event singular simplifies anything. For one is ma= kes extensions complex (another nested JSON structure) and potentially confl= icting. 
    [richanna]<= /u>
    Ways that multiple-event SETs are more complicated:
    1. I= t results in a more complex structure for the single event use case, which I= think we all agree is the majority use case.
    2. Multiple-event SETs h= ave ambiguous semantics. The presence of two events A and B in the same SET c= ould mean any of:
        <= li class=3D"MsoNormal" style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-= family:Calibri,sans-serif;color:rgb(195,70,224);background-color:white;backg= round-position:initial initial;background-repeat:initial initial">They are r= elated to the same logical event (i.e. the same thing as if they were from d= ifferent SETs that have a common txn).
      1. A is an extension of B.
      2. B is an extension of A.
      3. They are aliases for one another.
      4. They are not actually related to one another in any way.<= /li>
    1. Claim semantics b= ecome harder to define, as different profiles may want to use the same claim= s in different ways.
     
    If the WG wants to block 1 and 2 above, then I believe we= have to establish an event registry to ensure new Event profiles do not ove= rlap to eliminate the need to express multiple events.
    [richanna]I=E2=80=99m not sure what you mean by this. Are you r= eferring to event names? Those are already defined by the spec to be URIs.[/= richanna]
    Phil
     
    Oracle Corporation, Identity Cloud Service= s Architect
    @independentid
    <= /div>
     
    On Oct 29, 2017, at 4:12 PM, Dick Hardt <= dick.hardt@gmail.com> wrote:
     
    Phil:=
     
    In your examples for having a plu= rality of events, you use the word "may", which leads me to question if a pl= urality of events is really required in SET.
     
    <= /div>
    You posit that it will be difficult for a d= istributed system to correlate multiple SETs with the same "txn", but the di= stributed system will certainly need to correlate events on the same subject= -- correlating events on the same "txn" on the same subject seems fairly si= mple.
    &nb= sp;
    I thi= nk that a receiver will need to correlate multiple SEts on the same subject,= so having multiple events in a SET is redundant, and adds complexity with n= o clear benefit that I can see.
    <= div>
     
    An implementor may choose to send multiple SETs, or sen= d a single SET with multiple events, so a receiver will need to support both= . I prefer we pick one way and minimize the code paths, and we will need to s= upport correlating across multiple SETs, so that seems the best mechanism.
     
    = Let me know i= f there is something I missed in my logic.
    <= /div>
     
    /Dick
    =
     
     
    On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
    In that case, let's add text to th= at effect, e.g. we could add to the definition of the "events" claim:
    Profiling specifications SHOULD define the allowed event statements, and MA= Y restrict their number. For example, some profiles may require this claim t= o contain only a single event statement.

    Thanks,
        &nb= sp;   Yaron

    On 24/10= /17 22:10, Mike Jones wrote:

    I agree with much of Phil=E2=80=99s ration= ale here.

    It=E2=80=99s fine for some profiles to say that the =E2=80=9C= events=E2=80=9D set must be a singleton.  That doesn=E2=80=99t have to b= e true for all events.  I think things are fine as-is.

     &nb= sp;            &= nbsp;            = ;           &nbs= p;            &n= bsp;           &= nbsp; -- Mike

    *From:* Id-= event [mailto:id-eve= nt-bounces@ietf.org] *On Behalf Of *Phil Hunt
    *Sent:* Mon= day, October 23, 2017 8:47 PM
    *To:* Richard Backman, Annabelle <richanna@amazon.com&g= t;
    *Cc:* ID Events Mailing List <id-event@ietf.org>
    *Subject:* Re: [Id-event] Use c= ases for multiple events per SET?

    Annabelle,

    I have a number o= f concerns with this proposal.

    Profiling Independence / Keeping Event= Payloads Independent

    Indicating that extensions should be handled by= profiles leads to more inter-operability issues and more importantly intrud= es on the Event payload space by suggesting a sub-schema creates potential l= imitations and conflicts that may add to complexity later on. The current fo= rmat allows a parser to discover and unload one or more JSON payloads which c= an each have independent structure.

    General extensions

    The pro= posal also rules out general purpose extensions not related to any specific e= vent. Given the emergence of items like GPRD, I would not want to block the a= bility to add meta-data or other general purpose items. We can also anticipa= te some delivery scenarios where additional data might be required. Even tho= ugh there is no current planned use, I see no good reason to rule this out.<= br>
    Multiple Events =46rom Different Families (vs. Multiple Events from a= single family like RISC)

    In our RISC session we discussed expressing= multiple distinct RISC events in one SET. The discussion was that only one R= ISC event at a time. We did not discuss other event profiles. I don=E2=80=99= t see a reason to rule out multi-events from different families at the SET l= evel. Each profile is expressing slightly different things about the same ev= ent.

    I can forsee some cases where it is not clear which is the prima= ry and which is the extension.  There may not be a clear winner.
    A couple of examples (these are necessarily real=E2=80=A6just possibilities= ):

    * It is probably useful to be able to express simlar/overlapping e= vents from different SET profiles in one SET.  For example a Backchanne= l Logout & a RISC session cancel event.

    * SCIM may want to repres= ent a single transaction as causing multiple state changes in an event (e.g.= a password change causes multiple effects). Having to chase down multiple e= vents and correlate by =E2=80=9Ctxn=E2=80=9D would be challenging in a multi= -threaded/multi-node delivery system.   The SCIM list has not disc= ussed this, but I would not want to block this capability.  IOW - Just b= ecause RISC does not want to express multiple events does not make this true= for other profiles.

    * We may wish to indicate a SCIM Password Reset w= as performed and a Logout/session cancellation is expressed at the same time= .  The events are related but express different data.

    Avoiding C= onfusion =46rom Similar Events Originating from the Same Transaction

    = If events are sent separately, then more tracking of state (e.g. by txn) wou= ld be required to ensure similar events are not mistaken or handled as repea= ts. While txn provides useful audit analysis capability, I=E2=80=99m not sur= e it can be used in live or near-real time systems given distributed multi-n= ode, multi-threading architectures.

    Previous Discussion

    I note= that I originally raised having an attribute to designate primary event att= ribute to alleviate your concern, but this was not accepted. See:

    *     https://www.ietf.org/mail-archive/= web/id-event/current/msg00406.html

    * https://www.ietf.org/mail-archive/web/id-event/cu= rrent/msg00140.html

    The consensus, at least as I inte= rpreted it is up to the receiver to figure this out based on the definitions= it has for each event URI and the profiles they represent. IOW - RISC is fr= ee to limit that only one RISC event be expressed at a time.

    Phil
    =
    Oracle Corporation, Identity Cloud Services Architect

    @independen= tid

    www.independentid.com <http://= www.independentid.com>

    phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>

        On O= ct 23, 2017, at 7:02 PM, Richard Backman, Annabelle
        <richanna@amazon.com=  <mailto:richanna@amazon.com>> wr= ote:

        The current draft of the SET spec allows for expre= ssing multiple
        events within the same token, which introduc= es additional complexity
        and room for ambiguous semantics. W= e=E2=80=99ve discussed this in the OIDF
        RISC working group a= nd the current consensus there is that RISC will
        require th= at RISC events must be the only event in the SET, having
        id= entified ways to clearly and easily support the handful of use
      &nb= sp; cases for multiple events per token that people have raised. With
    &nb= sp;   that context in mind, I propose striking the definition of the    =E2=80=9Cevents=E2=80=9D claim from the Security Event Token s= pec, and replacing it
        with the following definition for an =E2= =80=9Cevent=E2=80=9D claim (singular):

        event

    &nb= sp;   A JSON object containing an "event_type" member whose value is a U= RI
        representing a type of event defined in a Profiling Spec= ification.
        The object MAY otherwise be empty, or MAY contai= n additional members
        as described by the Profiling Specific= ation.

        Here is the example SET from section 2.3, rewrit= ten with this change
        mind:

        {

           "jti": "4= d3559ec67504aaba65d40b0363faad8",

           "ia= t": 1458496404,

          "iss": "https://scim.example.com <https://scim.example.com/>",

      &nbs= p;    "aud": [

             "= https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",

             "https://scim.example.c= om/Feeds/5d7604516b1d08641d7676ee7"

        &nb= sp;  ],

           "event": {

      &nbs= p;      "event_type": "urn:ietf:params:scim:event:create",

             "ref": "https://sc= im.example.com/Users/44f6142df96bd6ab61e7521d9",

    &nbs= p;        "attributes": ["id", "name", "userName", "= password", "emails"]

           }

       = ; }

        Does anyone in the working group have use cases for= SETs that cannot
        be met by this proposed text? Within RISC= , we identified three use
        cases, with solutions outlined be= low:

        **

        *Extensions*

     =   Event extension mechanisms can be defined internal to the event
    &= nbsp;   object. A simple approach would be to  define an =E2=80=9C= extensions=E2=80=9D member
        that is a list of event objects (= or set resembling the =E2=80=9Cevents=E2=80=9D
        claim as def= ined in the current spec). This has the advantage of
        making= it clear in the data structure that there is a single primary
      &nb= sp; event, with zero or more extensions. There is no room for confusion
    &= nbsp;   over which event is primary, or if there is a primary event at a= ll.
        I would be fine with adding something like this to my p= roposed text,
        if there is consensus that it is broadly usef= ul.

        *Aliases*

        This use case was br= ought up in the context of migrating clients
        from draft eve= nt names to standardized event names. In this case,
        the eve= nt transmitter can transmit two tokens for the logical event,
      &nbs= p; one using the old name and another using the new name.

      &nbs= p; *Related Events*

        The SET spec defines the txn claim a= s a means of correlating
        independent tokens that relate to t= he same logical event.

        -- 
        Annabelle Richard Backman

      &nb= sp; Amazon =E2=80=93 Identity Services

        ________________= _______________________________
        Id-event mailing list<= br>    Id-event@ietf.org <mailto:Id-event@ietf.org>
        https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCg= aWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPE= ivzjWwlNKe4C_lLIGk&m=3Ds5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFS= ibEc&s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D<= /span>



    _____________________________________________= __
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event<= u>


    __________________= _____________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listi= nfo/id-event
    <= div>


     
    =
    -- 
    Subscribe to the HARDTWARE mai= l list to learn about projects I am working on!
     
    _____________= __________________________________
    Id-eve= nt mailing list
    Id-event@= ietf.org
    &= nbsp;


     
    --
    Subsc= ribe to the HARDTWARE mail list to learn about projects I am working on!=


     <= u>
    --
    Subscribe to the HARDTWARE mail list to learn about projects I am workin= g on!


    <= /u>
     
    --
    Subscribe to the HARDTWARE mail list to learn about projects I am w= orking on!
    =

     <= /div>
    -- <= /div>
    Subscribe to the HARDTWARE mail list to= learn about projects I am working on!
    =
    __________________________= _____________________
    Id-event mailing list<= /span>
    Id-ev= ent@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet= f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWH= vlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYq= PkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhl= o&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=3D=


    ______________________________________________= _
    Id-event mailing list
    Id-event@ietf.org
    https://www.= ietf.org/mailman/listinfo/id-event



    _______________________________________________
    Id-event mailing list
    Id-e= vent@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event



    = --Apple-Mail-8E597DA8-8B5E-4598-A08C-D9E469A70D93-- From nobody Wed Nov 1 15:09:07 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410B313F6A1 for ; Wed, 1 Nov 2017 15:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 eAHwUujy8Ovt for ; Wed, 1 Nov 2017 15:08:58 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6156813F6DF for ; Wed, 1 Nov 2017 15:08:56 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id m16so9493618iod.1 for ; Wed, 01 Nov 2017 15:08:56 -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=rqXbCOScwSmXpdsU3KxTiMDZguvNY5RRPtzd4Bi3Shk=; b=TdMOCQiuaY+qjoscjZt2T4CSFAkhFNioroN9ymdQyqyqfNpHgSH2W7flfUV9WsWBGL URIc4omf+0QiYsbC3d6ZE8nauMDW+gWYknwEIz2N2XztzIEdgpbSJP+dr5KkuHOxGzBG a4Ry3Y3x3D7QJiP5cfTfm2nRHP89D03CJZekPgsTIImHCeZbEPeGRJmK8iAuzxuTWgYR iDG733jU9dijkUCcK4FdMNwIN6BJhG9PA6k5btY/70FwqgPMNYlBXi5PQehnJGGJ61tR LFCFtoKAOTouBqq9Gr6RqDGEjG1nHsMb6/DwPO6ZNWNnQeBV45dsTLPP/CPQM6/Pyd7G edfQ== 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=rqXbCOScwSmXpdsU3KxTiMDZguvNY5RRPtzd4Bi3Shk=; b=qUI8NDuF0qmBpRY26q0EYOiLkQIDcq9zibsLiT7LvTaSjkl1a/04g5Gzx5OYW9j/LN +vh9c//ecz020aGIe1znqA/8OZIPn8wAiPCSp8MZt6ORHYYI3PzE6A5hxVQFTdVtGEZW U+MtSw1krK3gOwDTRd/EN2o4zuaOVeHq+3y6et96mlVD3X6kVHlLes1jMBV/7YlPU0Gh pulY6USiSUNcS2Xxt7K4izaloaKabA0fXIfu2H9Mylwn66/tqHYu9vyWGECMF0XPuXBX jc7XI5Tp+2NQyezWVCNpKBWT60a8fQuIs2yRQcRiq4cRUh/bt6AY84jOXSWb7Wv0s0Lq BaYw== X-Gm-Message-State: AMCzsaUtRrgd2gMhoNjAnDNA9br+xKmQcO/c3a7NrakUvunUtlqTd6Cg CdDTyzNwPrDGatEuSHeNJnzdDpANdpWjjwv0JBn2iQ== X-Google-Smtp-Source: ABhQp+QEcBWycdS93zn0vFlpBVVCHrSMhkvg6tXXz9BW4a5JU6oaozqStW53KLH77e0X+t0kwc4f+0OXntswALp/ExI= X-Received: by 10.36.178.85 with SMTP id h21mr2699030iti.118.1509574135034; Wed, 01 Nov 2017 15:08:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.34.9 with HTTP; Wed, 1 Nov 2017 15:08:33 -0700 (PDT) In-Reply-To: References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> From: Marius Scurtescu Date: Wed, 1 Nov 2017 15:08:33 -0700 Message-ID: To: William Denniss Cc: Phil Hunt , Yaron Sheffer , "Richard Backman, Annabelle" , Dick Hardt , Mike Jones , ID Events Mailing List Content-Type: multipart/alternative; boundary="f403045d9a14154592055cf31eb0" Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 22:09:05 -0000 --f403045d9a14154592055cf31eb0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 1, 2017 at 3:00 PM, William Denniss wrote= : > The receiver probably knows which version they want, but does the sender? > Using the email analogy, you may have configured your email client to > accept plain text only. Fortunately, my client sends both =E2=80=93 not k= nowing > what you prefer =E2=80=93 and you are able to view my message. > Two solutions: - since receiver knows what version they want they are going to only consume that and ignore the other - there is a proposal underway so that receivers can tell the sender exactly what they want, no events dropped on the floor > I think it would help if we broke this problem down into two parts. 1/ Ar= e > multi-format SETs desirable? That's been the design since the earliest > version. 2/ What is the best representation of the SET based on what we > decide for #1. > Yes, and #1 above is being challenged. > > My understanding was that the "events" plural (related to #2, the best > representation of a SET) *was* in fact a concern, as people may skip the > text and look directly at the JSON syntax, then jump to conclusions. > > On Wed, Nov 1, 2017 at 2:54 PM, Marius Scurtescu > wrote: > >> On Wed, Nov 1, 2017 at 2:46 PM, William Denniss >> wrote: >> >>> Perhaps I can try and explain the original intent of the current design= . >>> The goal was always that a SET represents a single logical event. Howev= er >>> multiple systems may have different representations of the event =E2=80= =93 the >>> example given originally was one formatted for RISC, and one for SCIM. >>> >>> A good analogy is email. You send a single logical email, which may hav= e >>> two representations, HTML and plain text. Systems can consume the versi= on >>> that they understand and ignore the one they don't. >>> >> >> Yes, and I think this is well understood. >> >> >> >>> >>> I'm starting to regret the plural in "events", it was pluralized due to >>> it being an array, not because it represented multiple logical events. >>> >> >> I don't think this is the main concern or cause for confusion. >> >> >> >>> >>> Annabelle, I understand your concerns regarding confusion of the >>> semantics between the JSON syntax and the specification language. Are t= here >>> other ways to resolve that without removing the ability for multiple >>> representations of the same event? >>> >> >> The argument is that multiple representations can be sent as distinct >> SETs, if really needed. In practice this will happen quite rare though. >> Events are created for a specific receiver, the receiver either wants th= e >> SCIM or the RISC flavor, and they should be able to specify that in >> configuration (there is a proposal how to capture that). >> >> Do we have a compelling use case where a receiver must receive multiple >> variants all at once? >> >> >> >>> >>> On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu >>> wrote: >>> >>>> On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt >>>> wrote: >>>> >>>>> You can=E2=80=99t really have multiple events (at least of the same t= ype). >>>>> The current spec can only have one instance of a URI (afaik). >>>>> >>>>> Note that the spec normatively does not support multiple event SETS. >>>>> It currently states: >>>>> >>>>> events >>>>> *The semantics of this claim is to define a set of event statem= ents >>>>> that each MAY add additional claims to fully describe a single >>>>> logical event* that has occurred (e.g. a state change to a >>>>> subject). Multiple event statements of the same type SHALL NOT= be >>>>> accepted. The "events" claim SHOULD NOT be used to express >>>>> multiple logical events. >>>>> >>>>> >>>>> The spec has *always* supported requirements (as stated in the spec) >>>>> for multiple separate profile statements (from one or more profile >>>>> familities) needing to be sent as a single message. It would be INSE= CURE >>>>> to force multiple SETs because the current delivery mechanism only al= lows >>>>> one SET to be delivered at a time. There is no way to assure that a s= ingle >>>>> receiver gets all of the SETs it needs in a multi-threaded, multi-nod= e >>>>> environment at scale. Assembling multiple SETs to track =E2=80=9Ctxn= =E2=80=9D in a common >>>>> state database is NOT simple nor cost effective. >>>>> >>>> >>>> I totally agree that it is difficult for receivers to receive separate >>>> events, in no particular order and correlate based on "txn". But, rece= ivers >>>> have to solve this issue regardless of "events" or "event", so it is >>>> unrelated to this proposal. >>>> >>>> >>>> >>>>> >>>>> If we accommodate this in the proposed form, we end up with a complex= , >>>>> deeply nested JSON structure with the possibility of namespace confli= cts. >>>>> >>>>> IMO The proposal does not simplify, it complicating and limiting. >>>>> >>>>> The current spec has very clean JSON and avoids namespace conflicts >>>>> between profiles. I think we should stay on track with the current dr= aft >>>>> and observe the normative text if not make it stronger in regards to >>>>> multi-events (understood that Mike may disagree). >>>>> >>>>> Phil >>>>> >>>>> Oracle Corporation, Identity Cloud Services Architect >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> On Nov 1, 2017, at 12:18 PM, Richard Backman, Annabelle < >>>>> richanna@amazon.com> wrote: >>>>> >>>>> Unless the profile guarantees that such related events will always be >>>>> included in the same SET, then the receiver has to correlate across S= ETs >>>>> anyway, and multiple events per SET is just giving the receiver anoth= er >>>>> scenario that they have to support. >>>>> >>>>> I=E2=80=99ve already provided several other reasons why we should not= support >>>>> multiple tokens per SET that no one has addressed. Here they are agai= n: >>>>> >>>>> 1. Multiple event support results in a more complex structure for >>>>> the single event use case, which I think we all agree is the major= ity use >>>>> case. >>>>> 2. Multiple-event SETs have ambiguous semantics. The presence of >>>>> two events A and B in the same SET could mean any of: >>>>> 1. A and B are related to the same logical event (i.e. the same >>>>> thing as if they were from different SETs that have a common tx= n). >>>>> 2. A is an extension of B. >>>>> 3. B is an extension of A. >>>>> 4. A is an alias for B, or vice-versa. >>>>> 5. A and B are not actually related to one another in any way, >>>>> and the transmitter bundled them together because they were goi= ng to the >>>>> same receiver. >>>>> 3. Top-level claim semantics become harder to define, as different >>>>> profiles may want to use the same claims in different ways. >>>>> 4. Event authenticity cannot be verified without having the entire >>>>> SET. This forces receivers to expose downstream systems to more in= formation >>>>> necessary, if those systems need to be able to verify authenticity= . >>>>> >>>>> >>>>> -- >>>>> Annabelle Richard Backman >>>>> Amazon =E2=80=93 Identity Services >>>>> >>>>> >>>>> *From: *Mike Jones >>>>> *Date: *Wednesday, November 1, 2017 at 11:21 AM >>>>> *To: *Dick Hardt >>>>> *Cc: *Yaron Sheffer , "Richard Backman, >>>>> Annabelle" , ID Events Mailing List < >>>>> id-event@ietf.org>, "Phil Hunt (IDM)" >>>>> *Subject: *RE: [Id-event] Use cases for multiple events per SET? >>>>> >>>>> I completely agree on moving complexity to the issuer over the >>>>> recipient. In my view, it=E2=80=99s more complex for recipients to h= ave to >>>>> correlate and process a sequence of multiple SETs providing informati= on >>>>> about the same logical event, and validate N signatures, than to rece= ive >>>>> one SET with all the aspects of the logical event as =E2=80=9Cevents= =E2=80=9D fields, with >>>>> no correlation over time then required. >>>>> >>>>> -- Mike >>>>> >>>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com >>>>> ] >>>>> *Sent:* Wednesday, November 1, 2017 9:39 AM >>>>> *To:* Mike Jones >>>>> *Cc:* Yaron Sheffer ; Richard Backman, >>>>> Annabelle ; ID Events Mailing List < >>>>> id-event@ietf.org>; Phil Hunt (IDM) >>>>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>>>> >>>>> Your comments highlight a couple of points: >>>>> >>>>> 1) The example is how to have a predefined extension point for >>>>> extensions of a specific event, it is not how to add another event. M= yself, >>>>> I think this is overly complicated. Events should be comparatively st= atic, >>>>> and as with many other JSON formats, the receiver should ignore prope= rties >>>>> it does not understand, which let's new properties be introduced as >>>>> extensions. There should not be any conflict as extensions should onl= y be >>>>> done by the profile that created the event format to start off with. >>>>> >>>>> 2) Having an lvalue be a URI is much harder to code against. I'm not >>>>> sure why Marius had that in his example. Per the event, the type of t= he >>>>> event is well defined with >>>>> >>>>> "event_type": "https://example.com/scim/event/passwordResetExt", >>>>> >>>>> 3) This thread is about reasons for multiple events to be contained i= n >>>>> one set. Your mention of an issuer not wanting to sign separate event= s as a >>>>> reason to allow multiple events. I think we have decided that given a >>>>> preference, we will push effort to the transmitter over the receiver = as in >>>>> many use cases there are many more receivers. Given that, it is more >>>>> complex for a receiver to have different ways of managing the receipt= of >>>>> multiple events as not all issuers will bundle the events, so it is s= impler >>>>> to have only one event per SET. Including the separate events with a = URI as >>>>> an lvalue is challenging to implement, speaking from experience. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones < >>>>> Michael.Jones@microsoft.com> wrote: >>>>> >>>>> Marius=E2=80=99 proposed syntax, pasted in below, has exactly this >>>>> characteristic. The way I see it, his proposal essentially has a pri= mary >>>>> passwordReset event and a secondary passwordResetExt data structure, = which >>>>> could have been simply another event value in the current draft. >>>>> >>>>> This breaking change makes the data structures more complicated - not >>>>> less. And it makes things that used to be possible impossible, reduc= ing >>>>> flexibility to those who would use the spec. >>>>> >>>>> These seem like bad tradeoffs to me. >>>>> >>>>> { >>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>> "iat": 1458496025, >>>>> "iss": "https://scim.example.com", >>>>> "aud": [ >>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>> ], >>>>> "event_type": "https://example.com/scim/event/passwordResetExt", >>>>> "event": { >>>>> "id":"44f6142df96bd6ab61e7521d9", >>>>> "extensions": { >>>>> "https://example.com/scim/event/passwordResetExt=E2=80=9D:= { >>>>> "resetAttempts":5, >>>>> } >>>>> } >>>>> } >>>>> } >>>>> >>>>> In particular, it makes it impossible to sign multiple related events >>>>> sharing a common claims schema with a single signature by the issuer.= It >>>>> forces the issuer to do the extra work of signing each of the related >>>>> events (or facets of the same logical event) individually and forces = the >>>>> recipients to do the extra work of checking all those unnecessary >>>>> signatures. >>>>> >>>>> Not every profile will ever have multiple keys in the =E2=80=9Cevents= =E2=80=9D set but >>>>> there=E2=80=99s absolutely no reason to preclude it. >>>>> >>>>> -- Mike >>>>> >>>>> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Di= ck >>>>> Hardt >>>>> *Sent:* Tuesday, October 31, 2017 9:52 PM >>>>> *To:* Mike Jones >>>>> *Cc:* Yaron Sheffer ; Richard Backman, >>>>> Annabelle ; ID Events Mailing List < >>>>> id-event@ietf.org>; Phil Hunt (IDM) >>>>> >>>>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>>>> >>>>> Please direct me to a proposal that has a "primary" and "secondary" >>>>> events. I agree that is undesirable. I would also encourage to engage= in >>>>> the discussions so that we can drive clarity and simplicity. >>>>> >>>>> I think the proposal is that there is one event per SET. >>>>> >>>>> I think having more than one event per SET adds complexity as a >>>>> receiver must deal with receiving correlated events in one SET as wel= l as >>>>> correlated events in the same SET. >>>>> >>>>> /Dick >>>>> >>>>> On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones < >>>>> Michael.Jones@microsoft.com> wrote: >>>>> >>>>> I hear you on the fact that different people have joined the effort a= t >>>>> different times. That=E2=80=99s a normal process as an effort builds= momentum. I >>>>> get that not everyone was there when previous consensus calls were ta= ken. >>>>> >>>>> I should note that I have specific technical objections to the >>>>> specific proposed changes being discussed as well. Currently all eve= nts in >>>>> the set have the same syntax. The proposals, as I understand them, r= evert >>>>> us to a state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and = =E2=80=9Csecondary=E2=80=9D events, with >>>>> different syntax for the two classes. That=E2=80=99s needlessly more= complicated, >>>>> adding no actual value. >>>>> >>>>> -- >>>>> Mike >>>>> >>>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>>>> *Sent:* Tuesday, October 31, 2017 9:37 PM >>>>> *To:* Mike Jones >>>>> *Cc:* Phil Hunt (IDM) ; Yaron Sheffer < >>>>> yaronf.ietf@gmail.com>; Richard Backman, Annabelle < >>>>> richanna@amazon.com>; ID Events Mailing List >>>>> >>>>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>>>> >>>>> Mike >>>>> >>>>> As you well know, many people in a WG don't look closely at a >>>>> specification until last call is made. Additionally, we are coming up= on >>>>> only the 3rd WG meeting. The WG has not existed for very long. While = some >>>>> of the participants have been working on this for a while, many have = not, >>>>> and we are looking for consensus across the WG. >>>>> >>>>> Since SecEvent is a framework that we expect to be profiled, I feel i= t >>>>> is important to ensure that SecEvent specifications are easy for a va= riety >>>>> of profiles to adopt, and that the semantics make sense. I also think= that >>>>> properties that are specific to a profile should be left to that prof= ile >>>>> and not be included in SecEvent. >>>>> >>>>> Since this is a framework, it is expected that as different groups >>>>> profile it, there will be additional feedback. >>>>> >>>>> Specifically, as a participant in the RISC profile of SET, a number o= f >>>>> issues in SET have surfaced as the RISC WG has looked at how to use t= he SET. >>>>> >>>>> As for SET being stable for over a year, there have been a number of >>>>> changes to SET since then. I also don't think there was consensus. Be= fore >>>>> the WG was formed, I and several others had expressed concern on the = design >>>>> of SET when Phil presented it at an IIW session. >>>>> >>>>> As to taking another year, I am hopeful we can resolve the remaining >>>>> issues in SET and publish a new draft for last call. I do not think w= e will >>>>> need to wait for another WG meeting to ask for last call. >>>>> >>>>> We also have a number of other documents that are not in last call, >>>>> and we don't have a WG adopted draft yet for management. So there are= still >>>>> a number of documents to work through before we have all the bits for >>>>> someone to work with. >>>>> >>>>> I do think we have been making good progress since the last IETF >>>>> meeting, and I am hopeful we can keep up this momentum and finalize a= ll the >>>>> documents in a timely manner. >>>>> >>>>> /Dick >>>>> >>>>> >>>>> On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones < >>>>> Michael.Jones@microsoft.com> wrote: >>>>> >>>>> It=E2=80=99s hard for me to even express my level of frustration with= the >>>>> recent attempts to once again redesign the SecEvent Token spec. We= =E2=80=99ve been >>>>> at this for multiple years because people keep trying to revisit deci= sions >>>>> that were long ago made by consensus. It=E2=80=99s been stable for o= ver a year and >>>>> the majority of WGLC respondents said some variant of =E2=80=9CWorks = for me =E2=80=93 ship >>>>> it!=E2=80=9D >>>>> >>>>> There=E2=80=99s not sufficient justification to try to undo consensus >>>>> positions that have been debated and affirmed over and over. Counten= ancing >>>>> wholesale changes at this late date is counterproductive in the extre= me! >>>>> >>>>> It=E2=80=99s far better than good enough as-is. In my experience, if= we start >>>>> redesigning it, it will result in another year=E2=80=99s delay. It d= oes something >>>>> simple and useful. Please, let=E2=80=99s just ship it, so people can= rely on it. >>>>> >>>>> -- Mike >>>>> >>>>> *From:* Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] >>>>> *Sent:* Monday, October 30, 2017 2:42 PM >>>>> *To:* Dick Hardt >>>>> *Cc:* Yaron Sheffer ; Richard Backman, >>>>> Annabelle ; Mike Jones < >>>>> Michael.Jones@microsoft.com>; ID Events Mailing List < >>>>> id-event@ietf.org> >>>>> >>>>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>>>> >>>>> Inline... >>>>> >>>>> Phil >>>>> >>>>> >>>>> On Oct 30, 2017, at 2:22 PM, Dick Hardt wrote: >>>>> >>>>> Hi Phil >>>>> >>>>> Correct me if I am misunderstanding, but there is a RISC profile even= t >>>>> >>>>> >>>>> >>>>> "http://schemas.openid.net/secevent/risc/event-type/ a= ccount-credential-change-required=E2=80=9D >>>>> >>>>> >>>>> >>>>> and an SCIM profile event >>>>> >>>>> >>>>> "https://example.com/scim/event/passwordResetExt=E2=80=9D >>>>> >>>>> >>>>> >>>>> I'm suggesting that two different events would be sent. Embedding one >>>>> in the other does not make sense. >>>>> >>>>> It is a hypothetical example. Just because you disagree on this >>>>> does not mean others are not valid. >>>>> >>>>> I just picked overlapping proposals that have different meaning (but >>>>> not the same) to illustrate the difference from issuing a single set = with >>>>> different events. >>>>> >>>>> >>>>> As I have stated this is very different from asserting multiple >>>>> distinct events in one SET. >>>>> >>>>> >>>>> Also, I think it is simpler to have event_type be at the same level a= s >>>>> event >>>>> >>>>> >>>>> >>>>> may be. I was working from Annabelle's proposed format. >>>>> >>>>> >>>>> { >>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>> "iat": 1458496025, >>>>> "iss": "https://scim.example.com", >>>>> "aud": [ >>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>> ], >>>>> "event_type": "https://example.com/scim/event/passwordResetExt", >>>>> "event": { >>>>> "id":"44f6142df96bd6ab61e7521d9", >>>>> "resetAttempts":5 >>>>> } >>>>> } >>>>> >>>>> { >>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>> "iat": 1458496025, >>>>> "iss": "https://scim.example.com", >>>>> "aud": [ >>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>> ], >>>>> "event_type": "http://schemas.openid.net/sec >>>>> event/risc/event-type/account-credential-change-required >>>>> >>>>> ", >>>>> "event": { >>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>>>> } >>>>> } >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt >>>>> wrote: >>>>> >>>>> Annabelle/Dick, >>>>> >>>>> Thanks for the comments. I think we need to examine the consequences >>>>> of the proposal in JSON. >>>>> >>>>> As I stated, what causes most of the issue is the proposed extension >>>>> mechanism in the payload (possibly using events in a recursive way). = Does >>>>> it follow the old format or the new? >>>>> >>>>> Let=E2=80=99s consider a use case where we have an identity manageme= nt system >>>>> that uses SCIM, but the SCIM system is also the underlying data store= for >>>>> Connect. A Password reset might generate the following event which h= as an >>>>> extension (conveying reset count) AND overlapping statement from RISC= . >>>>> BOTH of which might be important to a similar receiver using SCIM and= OIDC. >>>>> >>>>> >>>>> *The 03 spec currently would allow:* >>>>> >>>>> >>>>> { >>>>> >>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>> >>>>> "iat": 1458496025, >>>>> >>>>> "iss": "https://scim.example.com", >>>>> >>>>> "aud": [ >>>>> >>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>> >>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>> >>>>> ], >>>>> >>>>> "events": { >>>>> >>>>> "urn:ietf:params:scim:event:passwordReset": >>>>> >>>>> { "id":"44f6142df96bd6ab61e7521d9"}, >>>>> >>>>> "https://example.com/scim/event/passwordResetExt": >>>>> >>>>> { "resetAttempts":5}, >>>>> >>>>> "http://schemas.openid.net/secevent/risc/event-type/\ >>>>> account-credential-change-required": { >>>>> >>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>> >>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> In the above - each payload is a =E2=80=98peer' and issued without pr= eference by the transmitter. The receiver can assign priority in its own co= ntext if that matters. >>>>> >>>>> >>>>> >>>>> *The new proposal:* >>>>> >>>>> >>>>> >>>>> { >>>>> >>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>> >>>>> "iat": 1458496025, >>>>> >>>>> "iss": "https://scim.example.com", >>>>> >>>>> "aud": [ >>>>> >>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>> >>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>> >>>>> ], >>>>> >>>>> "event": { >>>>> >>>>> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passwor= dReset=E2=80=9D, >>>>> >>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>> >>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>> >>>>> ->note =E2=80=A6is this the old or new structure? <- >>>>> >>>>> "https://example.com/scim/event/passwordResetExt": >>>>> >>>>> { "resetAttempts":5}, >>>>> >>>>> "http://schemas.openid.net/secevent/risc/event-type/\ >>>>> account-credential-change-required": { >>>>> >>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>> >>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> In the above, sub-events or extensions have a different format. The s= ame complaint about the original stands. >>>>> >>>>> >>>>> >>>>> **OR* (if the receiver cares about RISC more). Note that this leads = to a triple nested structure.* >>>>> >>>>> >>>>> >>>>> { >>>>> >>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>> >>>>> "iat": 1458496025, >>>>> >>>>> "iss": "https://scim.example.com", >>>>> >>>>> "aud": [ >>>>> >>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>> >>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>> >>>>> ], >>>>> >>>>> "event": { >>>>> >>>>> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent= /risc/event-type/\ >>>>> >>>>> account-credential-change-required=E2=80=9D, >>>>> >>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>> >>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >>>>> >>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>> >>>>> "urn:ietf:params:scim:event:passwordReset": >>>>> >>>>> { >>>>> >>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>> >>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>> >>>>> "https://example.com/scim/event/passwordResetExt": >>>>> >>>>> { "resetAttempts":5}, >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> In the above, the extension is placed inside the event it extends. It= follows the old format (or should it follow the new?) >>>>> >>>>> **OR* Following the top layer pattern of singular event Note that th= is leads to a triple nested structure.* >>>>> >>>>> >>>>> >>>>> { >>>>> >>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>> >>>>> "iat": 1458496025, >>>>> >>>>> "iss": "https://scim.example.com", >>>>> >>>>> "aud": [ >>>>> >>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>> >>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>> >>>>> ], >>>>> >>>>> "event": { >>>>> >>>>> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent= /risc/event-type/\ >>>>> >>>>> account-credential-change-required=E2=80=9D, >>>>> >>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>> >>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C, >>>>> >>>>> =E2=80=9Cevent=E2=80=9D:{ >>>>> >>>>> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:pass= wordReset=E2=80=9D, >>>>> >>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>> >>>>> =E2=80=9Cevent=E2=80=9D:{ >>>>> >>>>> =E2=80=9Cevent_type=E2=80=9D:"https://example.com/scim/even= t/passwordResetExt=E2=80=9D, >>>>> >>>>> "resetAttempts":5 >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> This format follows the proposed singular event format recursively an= d is 3 layers deep. Note that the parser has to continue to search the docu= ment for things that aren=E2=80=99t there as it has to stop when no =E2=80= =9Cevent=E2=80=9D attribute is found rather than iterate over an array. >>>>> >>>>> >>>>> >>>>> Phil >>>>> >>>>> Oracle Corporation, Identity Cloud Services Architect >>>>> @independentid >>>>> www.independentid.com >>>>> >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle < >>>>> richanna@amazon.com> wrote: >>>>> >>>>> Replies inline. >>>>> >>>>> -- >>>>> Annabelle Richard Backman >>>>> Identity Services >>>>> >>>>> >>>>> *From: *Phil Hunt >>>>> *Date: *Sunday, October 29, 2017 at 5:25 PM >>>>> *To: *Dick Hardt >>>>> *Cc: *Yaron Sheffer , Mike Jones < >>>>> Michael.Jones@microsoft.com>, "Richard Backman, Annabelle" < >>>>> richanna@amazon.com>, ID Events Mailing List >>>>> *Subject: *Re: [Id-event] Use cases for multiple events per SET? >>>>> >>>>> I hope this answers your question. >>>>> >>>>> My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reason why= not. The question should >>>>> be, what is the justification to make =E2=80=9Cevents=E2=80=9D singul= ar? >>>>> [richanna]The singular =E2=80=9Cevent=E2=80=9D claim has clearer sema= ntics and is >>>>> easier to process. We should opt for easier solutions unless there ar= e use >>>>> cases that require more complexity.[/richanna] >>>>> >>>>> There are many reasons for multiple events in a SET. Some are good, >>>>> some not so good. Some of the reasons... >>>>> >>>>> 1. Multiple event payloads expressing statements about largely the >>>>> *same*thing. For example, SCIM password reset AND RISC password reset= . A >>>>> RISC Event and an OpenBanking Event. Is one a complement to the other= ? Do >>>>> they overlap or are they distinct? >>>>> [richanna]Copy/pasted from my earlier email: >>>>> Why is it necessary or appropriate to include these events in the sam= e >>>>> SET? They are likely being generated by different systems at differen= t >>>>> times on the transmitter=E2=80=99s side, consumed by different system= s on the >>>>> receiver=E2=80=99s side, and possibly being transmitted over differen= t event >>>>> streams. I know the latter would be the case for us, as a receiver. E= ven if >>>>> it=E2=80=99s not, is it burdensome to send these events separately? W= hat value is >>>>> gained in combining them? >>>>> >>>>> Additionally, since the signature is over the SET and not the event >>>>> objects, Receivers independently route separate events from a single = token >>>>> without either losing the ability to verify the authenticity of the e= vent >>>>> or sharing all information in the SET with every system handling any = event >>>>> in the token.[/richanna] >>>>> >>>>> >>>>> 2. Multiple events payloads expressing different statements about th= e >>>>> same transaction - RISC Password Reset and RISC Session Cancel >>>>> [richanna]Same as above[/richanna] >>>>> 3. A new profile defines new event attributes to be added on to an >>>>> existing event type (a pure extension) >>>>> [richanna]I have suggested a way to support extensions within an even= t >>>>> body, multiple times now. If you see problems with it, please point t= hem >>>>> out.[/richanna] >>>>> >>>>> I think it is quite valid to allow 1 and 3. 2 could be limited by >>>>> specific profiles like RISC if they want. >>>>> >>>>> I am not in agreement that making event singular simplifies anything. >>>>> For one is makes extensions complex (another nested JSON structure) a= nd >>>>> potentially conflicting. >>>>> [richanna] >>>>> Ways that multiple-event SETs are more complicated: >>>>> >>>>> 1. It results in a more complex structure for the single event use >>>>> case, which I think we all agree is the majority use case. >>>>> 2. Multiple-event SETs have ambiguous semantics. The presence of >>>>> two events A and B in the same SET could mean any of: >>>>> >>>>> >>>>> 1. They are related to the same logical event (i.e. the same thing >>>>> as if they were from different SETs that have a common txn). >>>>> 2. A is an extension of B. >>>>> 3. B is an extension of A. >>>>> 4. They are aliases for one another. >>>>> 5. They are not actually related to one another in any way. >>>>> >>>>> >>>>> 1. Claim semantics become harder to define, as different profiles >>>>> may want to use the same claims in different ways. >>>>> >>>>> >>>>> If the WG wants to block 1 and 2 above, then I believe we have to >>>>> establish an event registry to ensure new Event profiles do not overl= ap to >>>>> eliminate the need to express multiple events. >>>>> [richanna]I=E2=80=99m not sure what you mean by this. Are you referri= ng to >>>>> event names? Those are already defined by the spec to be URIs.[/richa= nna] >>>>> Phil >>>>> >>>>> Oracle Corporation, Identity Cloud Services Architect >>>>> @independentid >>>>> www.independentid.com >>>>> >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> On Oct 29, 2017, at 4:12 PM, Dick Hardt wrote: >>>>> >>>>> Phil: >>>>> >>>>> In your examples for having a plurality of events, you use the word >>>>> "may", which leads me to question if a plurality of events is really >>>>> required in SET. >>>>> >>>>> You posit that it will be difficult for a distributed system to >>>>> correlate multiple SETs with the same "txn", but the distributed syst= em >>>>> will certainly need to correlate events on the same subject -- correl= ating >>>>> events on the same "txn" on the same subject seems fairly simple. >>>>> >>>>> I think that a receiver will need to correlate multiple SEts on the >>>>> same subject, so having multiple events in a SET is redundant, and ad= ds >>>>> complexity with no clear benefit that I can see. >>>>> >>>>> An implementor may choose to send multiple SETs, or send a single SET >>>>> with multiple events, so a receiver will need to support both. I pref= er we >>>>> pick one way and minimize the code paths, and we will need to support >>>>> correlating across multiple SETs, so that seems the best mechanism. >>>>> >>>>> Let me know if there is something I missed in my logic. >>>>> >>>>> /Dick >>>>> >>>>> >>>>> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer >>>> > wrote: >>>>> >>>>> In that case, let's add text to that effect, e.g. we could add to the >>>>> definition of the "events" claim: >>>>> >>>>> Profiling specifications SHOULD define the allowed event statements, >>>>> and MAY restrict their number. For example, some profiles may require= this >>>>> claim to contain only a single event statement. >>>>> >>>>> Thanks, >>>>> Yaron >>>>> >>>>> On 24/10/17 22:10, Mike Jones wrote: >>>>> >>>>> I agree with much of Phil=E2=80=99s rationale here. >>>>> >>>>> It=E2=80=99s fine for some profiles to say that the =E2=80=9Cevents= =E2=80=9D set must be a >>>>> singleton. That doesn=E2=80=99t have to be true for all events. I t= hink things >>>>> are fine as-is. >>>>> >>>>> -- >>>>> Mike >>>>> >>>>> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of >>>>> *Phil Hunt >>>>> *Sent:* Monday, October 23, 2017 8:47 PM >>>>> *To:* Richard Backman, Annabelle >>>>> *Cc:* ID Events Mailing List >>>>> *Subject:* Re: [Id-event] Use cases for multiple events per SET? >>>>> >>>>> Annabelle, >>>>> >>>>> I have a number of concerns with this proposal. >>>>> >>>>> Profiling Independence / Keeping Event Payloads Independent >>>>> >>>>> Indicating that extensions should be handled by profiles leads to mor= e >>>>> inter-operability issues and more importantly intrudes on the Event p= ayload >>>>> space by suggesting a sub-schema creates potential limitations and >>>>> conflicts that may add to complexity later on. The current format all= ows a >>>>> parser to discover and unload one or more JSON payloads which can eac= h have >>>>> independent structure. >>>>> >>>>> General extensions >>>>> >>>>> The proposal also rules out general purpose extensions not related to >>>>> any specific event. Given the emergence of items like GPRD, I would n= ot >>>>> want to block the ability to add meta-data or other general purpose i= tems. >>>>> We can also anticipate some delivery scenarios where additional data = might >>>>> be required. Even though there is no current planned use, I see no go= od >>>>> reason to rule this out. >>>>> >>>>> Multiple Events From Different Families (vs. Multiple Events from a >>>>> single family like RISC) >>>>> >>>>> In our RISC session we discussed expressing multiple distinct RISC >>>>> events in one SET. The discussion was that only one RISC event at a t= ime. >>>>> We did not discuss other event profiles. I don=E2=80=99t see a reason= to rule out >>>>> multi-events from different families at the SET level. Each profile i= s >>>>> expressing slightly different things about the same event. >>>>> >>>>> I can forsee some cases where it is not clear which is the primary an= d >>>>> which is the extension. There may not be a clear winner. >>>>> >>>>> A couple of examples (these are necessarily real=E2=80=A6just possibi= lities): >>>>> >>>>> * It is probably useful to be able to express simlar/overlapping >>>>> events from different SET profiles in one SET. For example a Backcha= nnel >>>>> Logout & a RISC session cancel event. >>>>> >>>>> * SCIM may want to represent a single transaction as causing multiple >>>>> state changes in an event (e.g. a password change causes multiple eff= ects). >>>>> Having to chase down multiple events and correlate by =E2=80=9Ctxn=E2= =80=9D would be >>>>> challenging in a multi-threaded/multi-node delivery system. The SCI= M list >>>>> has not discussed this, but I would not want to block this capability= . IOW >>>>> - Just because RISC does not want to express multiple events does not= make >>>>> this true for other profiles. >>>>> >>>>> * We may wish to indicate a SCIM Password Reset was performed and a >>>>> Logout/session cancellation is expressed at the same time. The event= s are >>>>> related but express different data. >>>>> >>>>> Avoiding Confusion From Similar Events Originating from the Same >>>>> Transaction >>>>> >>>>> If events are sent separately, then more tracking of state (e.g. by >>>>> txn) would be required to ensure similar events are not mistaken or h= andled >>>>> as repeats. While txn provides useful audit analysis capability, I=E2= =80=99m not >>>>> sure it can be used in live or near-real time systems given distribut= ed >>>>> multi-node, multi-threading architectures. >>>>> >>>>> Previous Discussion >>>>> >>>>> I note that I originally raised having an attribute to designate >>>>> primary event attribute to alleviate your concern, but this was not >>>>> accepted. See: >>>>> >>>>> * https://www.ietf.org/mail-archive/web/id-event/current/msg00406.htm= l >>>>> >>>>> >>>>> * https://www.ietf.org/mail-archive/web/id-event/current/msg00140.htm= l >>>>> >>>>> >>>>> The consensus, at least as I interpreted it is up to the receiver to >>>>> figure this out based on the definitions it has for each event URI an= d the >>>>> profiles they represent. IOW - RISC is free to limit that only one RI= SC >>>>> event be expressed at a time. >>>>> >>>>> Phil >>>>> >>>>> Oracle Corporation, Identity Cloud Services Architect >>>>> >>>>> @independentid >>>>> >>>>> www.independentid.com >>>>> >>>>> >>>> >>>>> > >>>>> >>>>> phil.hunt@oracle.com >>>>> >>>>> On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle >>>>> > wrote: >>>>> >>>>> The current draft of the SET spec allows for expressing multiple >>>>> events within the same token, which introduces additional >>>>> complexity >>>>> and room for ambiguous semantics. We=E2=80=99ve discussed this in= the OIDF >>>>> RISC working group and the current consensus there is that RISC >>>>> will >>>>> require that RISC events must be the only event in the SET, havin= g >>>>> identified ways to clearly and easily support the handful of use >>>>> cases for multiple events per token that people have raised. With >>>>> that context in mind, I propose striking the definition of the >>>>> =E2=80=9Cevents=E2=80=9D claim from the Security Event Token spec= , and replacing it >>>>> with the following definition for an =E2=80=9Cevent=E2=80=9D clai= m (singular): >>>>> >>>>> event >>>>> >>>>> A JSON object containing an "event_type" member whose value is a >>>>> URI >>>>> representing a type of event defined in a Profiling Specification= . >>>>> The object MAY otherwise be empty, or MAY contain additional >>>>> members >>>>> as described by the Profiling Specification. >>>>> >>>>> Here is the example SET from section 2.3, rewritten with this >>>>> change >>>>> mind: >>>>> >>>>> { >>>>> >>>>> "jti": "4d3559ec67504aaba65d40b0363faad8", >>>>> >>>>> "iat": 1458496404, >>>>> >>>>> "iss": "https://scim.example.com ", >>>>> >>>>> "aud": [ >>>>> >>>>> "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>> >>>>> "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>> >>>>> ], >>>>> >>>>> "event": { >>>>> >>>>> "event_type": "urn:ietf:params:scim:event:create", >>>>> >>>>> "ref": "https://scim.example.com/User >>>>> s/44f6142df96bd6ab61e7521d9", >>>>> >>>>> "attributes": ["id", "name", "userName", "password", "emails= "] >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> Does anyone in the working group have use cases for SETs that >>>>> cannot >>>>> be met by this proposed text? Within RISC, we identified three us= e >>>>> cases, with solutions outlined below: >>>>> >>>>> ** >>>>> >>>>> *Extensions* >>>>> >>>>> Event extension mechanisms can be defined internal to the event >>>>> object. A simple approach would be to define an =E2=80=9Cextensi= ons=E2=80=9D >>>>> member >>>>> that is a list of event objects (or set resembling the =E2=80=9Ce= vents=E2=80=9D >>>>> claim as defined in the current spec). This has the advantage of >>>>> making it clear in the data structure that there is a single >>>>> primary >>>>> event, with zero or more extensions. There is no room for confusi= on >>>>> over which event is primary, or if there is a primary event at al= l. >>>>> I would be fine with adding something like this to my proposed >>>>> text, >>>>> if there is consensus that it is broadly useful. >>>>> >>>>> *Aliases* >>>>> >>>>> This use case was brought up in the context of migrating clients >>>>> from draft event names to standardized event names. In this case, >>>>> the event transmitter can transmit two tokens for the logical >>>>> event, >>>>> one using the old name and another using the new name. >>>>> >>>>> *Related Events* >>>>> >>>>> The SET spec defines the txn claim as a means of correlating >>>>> independent tokens that relate to the same logical event. >>>>> >>>>> -- >>>>> Annabelle Richard Backman >>>>> >>>>> Amazon =E2=80=93 Identity Services >>>>> >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.i >>>>> etf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaW >>>>> HvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEiv >>>>> zjWwlNKe4C_lLIGk&m=3Ds5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSib >>>>> Ec&s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Subscribe to the HARDTWARE >>>>> >>>>> mail list to learn about projects I am working on! >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>>>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqP >>>>> kAI1aLcLN4KZNA&m=3DYBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw >>>>> &s=3DWrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW001fK02EXs&e=3D >>>>> >>>>> >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>>>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqP >>>>> kAI1aLcLN4KZNA&m=3DU-a5HBND0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec >>>>> &s=3DrvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2nm46QSz0&e=3D >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Subscribe to the HARDTWARE >>>>> >>>>> mail list to learn about projects I am working on! >>>>> >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>>>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqP >>>>> kAI1aLcLN4KZNA&m=3DiyVnrZmr9_uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w >>>>> &s=3DOe0qfLEX83vtXM7Wl2cYBe-Gg1DVPjhXjVJkfhVRzwc&e=3D >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Subscribe to the HARDTWARE >>>>> >>>>> mail list to learn about projects I am working on! >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Subscribe to the HARDTWARE >>>>> >>>>> mail list to learn about projects I am working on! >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Subscribe to the HARDTWARE >>>>> >>>>> mail list to learn about projects I am working on! >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>>>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqP >>>>> kAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo >>>>> &s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=3D >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>> >>>> >>> >> > --f403045d9a14154592055cf31eb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On W= ed, Nov 1, 2017 at 3:00 PM, William Denniss <wdenniss= @google.com> wrote:
    The receiver probably knows which version they want, but does the= sender? Using the email analogy, you may have configured your email client= to accept plain text only. Fortunately, my client sends both =E2=80=93 not= knowing what you prefer =E2=80=93 and you are able to view my message.

    Two solutions:
    - since receive= r knows what version they want they are going to only consume that and igno= re the other
    - there is a proposal underway so that receivers can= tell the sender exactly what they want, no events dropped on the floor



    I think it would help if we broke this problem dow= n into two parts. 1/ Are multi-format SETs desirable? That's been the d= esign since the earliest version. 2/ What is the best representation of the= SET based on what we decide for #1.

    Yes, and #1 above is being challenged.

    =C2= =A0

    My understanding was that the "events" plural (related to #2, t= he best representation of a SET) was in fact=C2=A0a concern, as peop= le may skip the text and look directly at the JSON syntax, then jump to con= clusions.

    On= Wed, Nov 1, 2017 at 2:54 PM, Marius Scurtescu <mscur= tescu@google.com> wrote:
    On Wed= , Nov 1, 2017 at 2:46 PM, William Denniss <wdenniss@google.com> wr= ote:
    Perhaps I can try a= nd explain the original intent of the current design. The goal was always t= hat a SET represents a single logical event. However multiple systems may h= ave different representations of the event =E2=80=93 the example given orig= inally was one formatted for RISC, and one for SCIM.

    A g= ood analogy is email. You send a single logical email, which may have two r= epresentations, HTML and plain text. Systems can consume the version that t= hey understand and ignore the one they don't.
    <= div>
    Yes, and I think this is well understood.

    =
    =C2=A0

    I'm starting to regret the plural in "events"= , it was pluralized due to it being an array, not because it represented mu= ltiple logical events.

    I don= 9;t think this is the main concern or cause for confusion.

    =C2=A0
    <= br>
    Annabelle, I understand your concerns regarding confusion of = the semantics between the JSON syntax and the specification language. Are t= here other ways to resolve that without removing the ability for multiple r= epresentations of the same event?

    The argument is that multiple representations can be sent as distinct SE= Ts, if really needed. In practice this will happen quite rare though. Event= s are created for a specific receiver, the receiver either wants the SCIM o= r the RISC flavor, and they should be able to specify that in configuration= (there is a proposal how to capture that).

    Do we = have a compelling use case where a receiver must receive multiple variants = all at once?

    =C2=A0

    On Wed, Nov= 1, 2017 at 2:37 PM, Marius Scurtescu <mscurtescu@google.com> wr= ote:
    On Wed, Nov 1, 2017 at 12:45 PM, Phil Hu= nt <phil.hunt@oracle.com> wrote:
    You can=E2=80=99t r= eally have multiple events (at least of the same type).=C2=A0 The current s= pec can only have one instance of a URI (afaik). =C2=A0

    = Note that the spec normatively does not support multiple event SETS.=C2=A0 = It currently states:
    events
      The semantics of this claim is to define a set of event statements
      that each MAY add additional claims to fully describe a single
      logical event that has occurred (e.g. a state change to a
      subject).  Multiple event statements of the same type SHALL NOT be
      accepted.  The "events" claim SHOULD NOT be used to express
      multiple logical events.

    The sp= ec has *always* supported requirements (as stated in the spec) for multiple= separate profile statements (from one or more profile familities) needing = to be sent as a single message.=C2=A0 It would be INSECURE to force multipl= e SETs because the current delivery mechanism only allows one SET to be del= ivered at a time. There is no way to assure that a single receiver gets all= of the SETs it needs in a multi-threaded, multi-node environment at scale.= =C2=A0 Assembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a common = state database is NOT simple nor cost effective.

    I totally agree that it is difficult for rece= ivers to receive separate events, in no particular order and correlate base= d on "txn". But, receivers have to solve this issue regardless of= "events" or "event", so it is unrelated to this propos= al.

    =C2=A0

    If we accomm= odate this in the proposed form, we end up with a complex, deeply nested JS= ON structure with the possibility of namespace conflicts.

    IMO The proposal does not simplify, it complicating and limiting. = =C2=A0

    The current spec has very clean JSON and av= oids namespace conflicts between profiles. I think we should stay on track = with the current draft and observe the normative text if not make it strong= er in regards to multi-events (understood that Mike may disagree).

    Phil
    <= div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-i= ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap= :break-word">

    Oracle Corporation, Identity Cloud Servic= es Architect
    @independentid
    phil.hunt@oracle.com

    On Nov 1, 2017, at 12:18 PM, Richar= d Backman, Annabelle <richanna@amazon.com> wrote:

    Unless the profile guarantees that such related events will always = be included in the same SET, then the receiver has to correlate across SETs= anyway, and multiple events per SET is just giving the receiver another sc= enario that they have to support.
    =C2= =A0
    I=E2=80=99ve already provided several other reaso= ns why we should not support multiple tokens per SET that no one has addres= sed. Here they are again:
    1. Multiple event support results in a more c= omplex structure for the single event use case, which I think we all agree = is the majority use case.
    2. Multiple-event SETs have ambiguous sem= antics. The presence of two events A and B in the same SET could mean any o= f:
      1. A and B are related to the same logical event (i.e. the same thing as i= f they were from different SETs that have a common txn).
        2. =
      2. A is an= extension of B.
      3. B is an extension of A.
      4. A is an alia= s for B, or vice-versa.
      5. A and B are not actually related to one = another in any way, and the transmitter bundled them together because they = were going to the same receiver.
    3. Top-level claim seman= tics become harder to define, as different profiles may want to use the sam= e claims in different ways.
    4. Event authenticity cannot be verifie= d without having the entire SET. This forces receivers to expose downstream= systems to more information necessary, if those systems need to be able to= verify authenticity.
    =C2=A0=
    --=C2=A0
    Annabelle= Richard Backman
    Amazon =E2=80=93 Ident= ity Services
    =C2=A0=
    =C2=A0
    From:=C2=A0= Mike Jones <Michael.Jones@microsoft.c= om>
    Date:=C2=A0Wednesday, November 1, 2017 at 11:21 AMTo:=C2=A0Dick Hardt <dick.hardt@gmail.com>
    Cc:=C2=A0<= /b>Yaron Sheffer <yaronf.ietf@gmail.com>, "Richard Backman, Annabe= lle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org&g= t;, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
    Subject:=C2=A0RE: [Id-event] Use cases for multiple events per SET?
    =C2=A0
    I completely agree on moving complexit= y to the issuer over the recipient.=C2=A0 In my view, it=E2=80=99s more com= plex for recipients to have to correlate and process a sequence of multiple= SETs providing information about the same logical event, and validate N si= gnatures, than to receive one SET with all the aspects of the logical event= as =E2=80=9Cevents=E2=80=9D fields, with no correlation over time then req= uired.
    =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
    =C2=A0
    From:=C2=A0Dick Hardt [mailto:dick.hardt@gmail.com]=C2=A0
    Sent:=C2=A0Wednesday, November 1, 2017 9:39 AM
    To:=C2= =A0Mike Jones <Michael.Jones@microsoft.com>
    Cc:<= span class=3D"m_-1329852460247035742m_6337440896153279834m_-315144595845102= 9318m_7476346946956833004m_5683402937781561080Apple-converted-space">=C2=A0= Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabell= e <ri= channa@amazon.com>; ID Events Mailing List <id-event@ietf.org>; Phil= Hunt (IDM) <phil.hunt@oracle.com>
    Subject:=C2=A0Re: [Id-eve= nt] Use cases for multiple events per SET?
    =C2= =A0
    Your comments highlight a couple= of points:
    =C2=A0
    1) The example is how to have a predefined extensio= n point for extensions of a specific event, it is not how to add another ev= ent. Myself, I think this is overly complicated. Events should be comparati= vely static, and as with many other JSON formats, the receiver should ignor= e properties it does not understand, which let's new properties be intr= oduced as extensions. There should not be any conflict as extensions should= only be done by the profile that created the event format to start off wit= h.
    =C2=A0
    =
    2) Having an lvalue be a URI is much harder to code against.= I'm not sure why Marius had that in his example. Per the event, the ty= pe of the event is well defined with=C2=A0
    =C2=A0
    =C2=A0
    3) This thread is abou= t reasons for multiple events to be contained in one set. Your mention of a= n issuer not wanting to sign separate events as a reason to allow multiple = events. I think we have decided that given a preference, we will push effor= t to the transmitter over the receiver as in many use cases there are many = more receivers. Given that, it is more complex for a receiver to have diffe= rent ways of managing the receipt of multiple events as not all issuers wil= l bundle the events, so it is simpler to have only one event per SET. Inclu= ding the separate events with a URI as an lvalue is challenging to implemen= t, speaking from experience.
    =C2=A0=
    =C2=A0
    =C2=A0
    =C2=A0
    =C2=A0
    =
    =C2=A0
    =C2=A0
    =C2=A0
    =C2= =A0
    =C2=A0
    =
    =C2=A0
    =C2=A0
    On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones &= lt;Michael.Jones@microsoft= .com> wrote:
    =
    Marius=E2=80=99 proposed synta= x, pasted in below, has exactly this characteristic.=C2=A0 The way I see it= , his proposal essentially has a primary passwordReset event and a secondar= y passwordResetExt data structure, which could have been simply another eve= nt value in the current draft.
    =C2=A0
    This breaking change makes the data structure= s more complicated - not less.=C2=A0 And it makes things that used to be po= ssible impossible, reducing flexibility to those who would use the spec.
    =C2=A0=
    The= se seem like bad tradeoffs to me.
    =C2=A0
    = {
    =C2=A0 "jti": "3d0c3cf797584= bd193bd0fb1bd4e7d30",
    =C2=A0 &qu= ot;iat": 1458496025,
    =C2=A0 "i= ss": "https://scim.exampl= e.com",
    =C2=A0 "aud": [=
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0 =C2=A0 "https://jhub.example.com/Feeds/5d7604516b1d0864= 1d7676ee7"
    =C2=A0 =C2=A0],=
    =C2=A0 =C2=A0"event": {=C2=A0=C2=A0
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"id":"44f6142df96b= d6ab61e7521d9",
    =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0"extensions": {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"https://example.com/scim/event/p= asswordResetExt=E2=80=9D: {
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"resetAttempts":5,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<= u>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}=
    =C2=A0 =C2=A0 =C2=A0 =C2=A0}
    =
    }
    =C2=A0
    In particular, it makes it impossible to sign multiple related even= ts sharing a common claims schema with a single signature by the issuer.=C2= =A0 It forces the issuer to do the extra work of signing each of the relate= d events (or facets of the same logical event) individually and forces the = recipients to do the extra work of checking all those unnecessary signature= s.
    = =C2=A0
    Not every profile will ever have multiple keys in the =E2=80=9Cevents=E2= =80=9D set but there=E2=80=99s absolutely no reason to preclude it.<= u>
    =C2=A0
    =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
    From:=C2=A0Id-event [mailto:id-event-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Dick Hardt
    Sent:=C2=A0Tuesday, Octo= ber 31, 2017 9:52 PM
    To:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
    Cc= := =C2=A0Yaron Sheffer <y= aronf.ietf@gmail.com>; Richard Backman, Annabelle <richanna@amazon.com>; ID Events Mailing L= ist <id-event@ietf.org>; P= hil Hunt (IDM) <phil.hunt@orac= le.com>

    Subject:=C2=A0<= /span>Re: [Id-event] Use cases for multiple events per SET?
    =C2=A0
    =C2=A0
    I think the proposal is that there is one event per SET.=
    =C2=A0
    = I think having more than one event per SET adds complexity as a receiver mu= st deal with receiving correlated events in one SET as well as correlated e= vents in the same SET.
    =C2=A0
    /Dick
    =C2=A0
    On Tue, Oct 31, 2017 a= t 9:42 PM, Mike Jones <= Michael.Jones@microsoft.com> wrote:
    I hear = you on the fact that different people have joined the effort at different t= imes.=C2=A0 That=E2=80=99s a normal process as an effort builds momentum.= =C2=A0 I get that not everyone was there when previous consensus calls were= taken.
    =C2=A0
    I should note that I have specific technical objections to the speci= fic proposed changes being discussed as well.=C2=A0 Currently all events in= the set have the same syntax.=C2=A0 The proposals, as I understand them, r= evert us to a state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and = =E2=80=9Csecondary=E2=80=9D events, with different syntax for the two class= es.=C2=A0 That=E2=80=99s needlessly more complicated, adding no actual valu= e.
    = =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 -- Mike
    =C2=A0
    From:= = =C2=A0Dick Hardt [mailto:d= ick.hardt@gmail.com]=C2=A0
    Sent:=C2=A0Tuesday, October 31= , 2017 9:37 PM
    To:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
    Cc:<= span class=3D"m_-1329852460247035742m_6337440896153279834m_-315144595845102= 9318m_7476346946956833004m_5683402937781561080Apple-converted-space">=C2=A0= Phil Hunt (IDM) <phil.h= unt@oracle.com>; Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle <<= a href=3D"mailto:richanna@amazon.com" style=3D"color:purple;text-decoration= :underline" class=3D"m_-1329852460247035742m_6337440896153279834m_-31514459= 58451029318m_7476346946956833004cremed m_-1329852460247035742m_633744089615= 3279834cremed cremed" target=3D"_blank">richanna@amazon.com>; ID Eve= nts Mailing List <id-event@ietf.o= rg>

    Subject:=C2=A0Re: [Id-event] Use cases for multiple events per SET?
    =
    =C2=A0
    = Mike
    =C2=A0
    As you well know, many people in a WG don't look closely at = a specification until last call is made. Additionally, we are coming up on = only the 3rd WG meeting. The WG has not existed for very long. While some o= f the participants have been working on this for a while, many have not, an= d we are looking for consensus across the WG.
    =C2=A0
    Since SecEvent is= a framework that we expect to be profiled, I feel it is important to ensur= e that SecEvent specifications are easy for a variety of profiles to adopt,= and that the semantics make sense. I also think that properties that are s= pecific to a profile should be left to that profile and not be included in = SecEvent.
    =C2=A0
    Since this is a framework, it is expected that as dif= ferent groups profile it, there will be additional feedback.<= /div>
    =C2=A0
    = Specifically, as a participant in the RISC profile of SET, a number of issu= es in SET have surfaced as the RISC WG has looked at how to use the SET.=
    =C2=A0
    =
    As for SET being stable for over a year, there have been a number= of changes to SET since then. I also don't think there was consensus. = Before the WG was formed, I and several others had expressed concern on the= design of SET when Phil presented it at an IIW session.
    =C2=A0
    As to = taking another year, I am hopeful we can resolve the remaining issues in SE= T and publish a new draft for last call. I do not think we will need to wai= t for another WG meeting to ask for last call.=C2=A0
    =C2=A0
    We also ha= ve a number of other documents that are not in last call, and we don't = have a WG adopted draft yet for management. So there are still a number of = documents to work through before we have all the bits for someone to work w= ith.
    =C2=A0
    I do think we have been making good progress since the las= t IETF meeting, and I am hopeful we can keep up this momentum and finalize = all the documents in a timely manner.
    =C2=A0
    /Dick
    =
    =C2=A0
    = =C2=A0
    On Tue, Oct 31, 2017 at 12:48 PM, = Mike Jones <Michael.Jon= es@microsoft.com> wrote:
    It=E2=80=99s hard = for me to even express my level of frustration with the recent attempts to = once again redesign the SecEvent Token spec.=C2=A0 We=E2=80=99ve been at th= is for multiple years because people keep trying to revisit decisions that = were long ago made by consensus.=C2=A0 It=E2=80=99s been stable for over a = year and the majority of WGLC respondents said some variant of =E2=80=9CWor= ks for me =E2=80=93 ship it!=E2=80=9D
    = =C2=A0
    There=E2=80=99s not sufficient justif= ication to try to undo consensus positions that have been debated and affir= med over and over.=C2=A0 Countenancing wholesale changes at this late date = is counterproductive in the extreme!
    = =C2=A0
    It=E2=80=99s far better than good eno= ugh as-is.=C2=A0 In my experience, if we start redesigning it, it will resu= lt in another year=E2=80=99s delay.=C2=A0 It does something simple and usef= ul.=C2=A0 Please, let=E2=80=99s just ship it, so people can rely on it.
    =C2=A0<= /span>
    =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
    =C2=A0<= u>
    From:=C2=A0Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=C2=A0
    Sent:=C2=A0Mon= day, October 30, 2017 2:42 PM
    To:=C2=A0Dick Hardt <dick.hardt@gmail.com>
    Cc:=C2= =A0Yaron Sheffer <yar= onf.ietf@gmail.com>; Richard Backman, Annabelle <richanna@amazon.com>; Mike Jones <Michael.Jones@microsoft.com&= gt;; ID Events Mailing List <id-= event@ietf.org>

    Subjec= t:=C2=A0Re: [Id-event] Use cases for multiple events per SET?<= u>
    =C2=A0
    Inline...

    Phil
    <= p class=3D"MsoNormal" style=3D"margin:0in 0in 12pt;font-size:11pt;font-fami= ly:Calibri,sans-serif">
    On Oct 30, 2017, at 2:22 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    Hi Phil
    =C2=A0
    Correct me if I am misund= erstanding, but there is a RISC profile event=C2=A0
    =C2=A0
    &quo= t;http://schemas.openid= .net/secevent/risc/event-type/account-credential-change-required=E2=80=9D
    =C2=A0=

    <ph>may be. I was working from Annabelle's proposed format.= =C2=A0

    =
    {
    =C2=A0 "jti": "3d0c3cf797584b= d193bd0fb1bd4e7d30",
    =C2=A0 "iat= ": 1458496025,
    =C2=A0 "aud": [<= /u>
    =C2=A0 =C2=A0 "https:= //jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"=
    =C2=A0 =C2=A0],
    =C2=A0 =C2=A0 =C2=A0 =C2=A0}=
    }
    =C2=A0
    =C2=A0
    =C2=A0
    =C2=A0<= /div>
    =C2=A0
    = On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
    Annabelle/Dick,
    =C2=A0
    Thanks= for the comments. I think we need to examine the consequences of the propo= sal in JSON.
    =C2=A0
    As I stated, what causes most of the issue is the propo= sed extension mechanism in the payload (possibly using events in a recursiv= e way). Does it follow the old format or the new?
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0
    Let=E2=80=99s =C2= =A0consider a use case where we have an identity management system that use= s SCIM, but the SCIM system is also the underlying data store for Connect.= =C2=A0 A Password reset might generate the following event which has an ext= ension (conveying reset count) AND overlapping statement from RISC.=C2=A0 B= OTH of which might be important to a similar receiver using SCIM and OIDC. = =C2=A0
    =C2=A0
    The 03 spec currently would allow:<= /div>
    =C2=A0
    {
    =C2=A0 "jti": &q=
uot;3d0c3cf797584bd193bd0fb1bd4e7d30",
    =C2=A0 "iat": 1458496025,
    =C2=A0 "iss": "https://scim.example.com",
    =C2=A0 "aud": [
    =C2=A0=
=C2=A0=C2=A0 "https://jhub.example.com/Feeds/98d52461fa5bbc879593b775=
4",
    =C2=A0=C2=A0=C2=A0 "=
;htt=
ps://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"=

    =C2=A0=C2=A0 ],
    =C2=A0=C2=A0 "events": {
    =C2=A0=C2=A0=C2=A0=C2=A0 "urn:ietf:params:scim:event:pas=
swordReset":
    =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 { "id":"44f6142df96bd6ab61e7521d9&qu=
ot;},
    =C2=A0=C2=A0=C2=A0=C2=A0 "=
https://examp=
le.com/scim/event/passwordResetExt":
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAttempts&qu=
ot;:5},
    =C2=A0=C2=A0=C2=A0=C2=A0 "http://schemas.openid.net/secevent/risc/event-type/\=C2=A0 =C2=A0 =C2=A0 =C2=A0account-credential-change-required":=
 {
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Csub=E2=80=9D:=
=E2=80=9D7375626A656374=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=
"
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
    =C2=A0 }
    }
    =C2=A0
    =
In the above - each payloa=
d is a =E2=80=98peer' and issued without preference by the transmitter.=
 The receiver can assign priority in its own context if that matters.
    =C2=A0
    The new proposal:
    =C2=A0
    {
    =C2=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7= d30",
    =C2=A0 "iat"=
;: 1458496025,
    =C2=A0 "iss"=
: "https://scim.example.com",
    =C2=A0 "aud": [=

    =C2=A0=C2=A0=C2=A0 "https://jhub.examp=
le.com/Feeds/98d52461fa5bbc879593b7754",
    <= pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courie= r New',serif">=C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Feeds/= 5d7604516b1d08641d7676ee7"
    =
=C2=A0=C2=A0 ],
    =C2=A0=C2=A0 "ev=
ent": {
    =C2=A0=C2=A0=C2=A0=C2=A0=
 =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:passwor=
dReset=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=
=C2=A0 "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,<=
/u>
    =C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevents=
=E2=80=9D:{
    =C2=A0=C2=A0=C2=A0=C2=A0 =
->note =E2=80=A6is this the old or new structure? <-
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://example.com/sci=
m/event/passwordResetExt":
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAttempts&=
quot;:5},
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "http://schemas.openid.net/secevent/risc/event-=
type/\
    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0account-credential-cha=
nge-required": {
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
    =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ciss=E2=80=9D:"https:=
//idp.example.com/"
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
    =
=C2=A0=C2=A0=C2=A0=C2=A0 }
    =C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0 =

    }<=
/u>
    =C2=A0
    In the above, sub-eve=
nts or extensions have a different format. The same complaint about the ori=
ginal stands.
    =C2=A0=

    *OR* (if the receiver cares about RISC more).=C2=A0 Note that this le=
ads to a triple nested structure.
    =C2=A0
    {
    =

    =C2=A0 "jti": "3d0c3cf797584bd193bd0fb1bd=
4e7d30",
    =C2=A0 "iat&q=
uot;: 1458496025,
    =C2=A0 "iss&qu=
ot;: "https://scim.example.com=
",
    =C2=A0 "aud": [=

    =C2=A0=C2=A0=C2=A0 "https://jhub.ex=
ample.com/Feeds/98d52461fa5bbc879593b7754",
    =C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
    =C2=A0=C2=A0 "=
event": {
    =C2=A0=C2=A0=C2=A0=C2=
=A0 =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid=
.net/secevent/risc/event-type/\
    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0account-credential-change-required=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
    =C2=A0=C2=A0=C2=
=A0=C2=A0 =C2=A0=E2=80=9Ciss=E2=80=9D:"https://idp.example.=
com/=E2=80=9C,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevents=E2=
=80=9D:{
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "urn:ietf:params:=
scim:event:passwordReset":
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 {=C2=A0
    =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "id":=E2=80=9D44f6142d=
f96bd6ab61e7521d9=E2=80=9D,
    =C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevents=E2=80=
=9D:{
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://example.com/scim/event/pas=
swordResetExt":
    =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { =
"resetAttempts":5},=C2=A0 
    =C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 
    =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0=C2=A0 <=
u>
    =C2=A0=C2=A0=
=C2=A0}
    }
    =C2=A0<=
u>
    In the above, the extension is placed inside the event it e=
xtends. It follows the old format (or should it follow the new?)<=
/u>
    *OR* Following the top layer pattern of singular eve=
nt=C2=A0 Note that this leads to a triple nested structure.
    =C2=A0
    {
    =C2=A0 "jti": "3=
d0c3cf797584bd193bd0fb1bd4e7d30",
    =C2=A0 "iat": 1458496025,
    =C2=A0 "iss": "https://scim.example.com",
    =C2=A0 "aud": [
    =C2=A0=
=C2=A0=C2=A0 "https://jhub.example.com/Feeds/98d52461fa5bbc879593b775=
4",
    =C2=A0=C2=A0=C2=A0 "=
;htt=
ps://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"=

    =C2=A0=C2=A0 ],
    =C2=A0=C2=A0 "event": {
    =C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/risc/event-type/\
    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0account-credential-change-required=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ciss=E2=80=
=9D:"https://idp.example.com/=E2=80=9C,<=
/u>
    =C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 =E2=80=9Cevent=E2=80=9D:{
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:e=
vent:passwordReset=E2=80=9D,
    <=
span style=3D"font-size:12pt">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 =E2=80=9Cevent=E2=80=9D:{
    =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:=
"https:/=
/example.com/scim/event/passwordResetExt=E2=80=9D,<=
/u>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 "resetAttempts":5 
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0}
    =C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0=C2=A0 
    =C2=A0=C2=A0=C2=A0}=

    }=

    =C2=A0
    This format follo=
ws the proposed singular event format recursively and is 3 layers deep. Not=
e that the parser has to continue to search the document for things that ar=
en=E2=80=99t there as it has to stop when no =E2=80=9Cevent=E2=80=9D attrib=
ute is found rather than iterate over an array.
    <=
/div>
    =C2=A0
    Phil=

    Oracle Corporation, Identity Cloud Services Architect
    @independe= ntid
    www.independentid.com
    phil.hunt@oracle.com
    =C2=A0
    On Oct 30, 201= 7, at 8:57 AM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
    =C2=A0
    Replies i= nline.
    =C2=A0
    Annabelle Richard Backman
    Identity Services
    =C2=A0
    =C2=A0
    From:=C2=A0Phil Hunt <phil.hunt@oracle.com>
    = Date:=C2=A0Sunday, October 29, 2017 at 5:25 PM
    To:= =C2=A0Dick Hardt <<= span style=3D"color:purple">dick.hardt@gmail.com>
    Cc:= =C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>, Mike = Jones <Michael.Jones@microsoft.com>, "Richard Back= man, Annabelle" <richanna@amazon.com>, ID Events Mailing L= ist <id-event@ietf.org>
    Subject:=C2=A0Re: [Id-= event] Use cases for multiple events per SET?
    =C2=A0
    I hope this answe= rs your question.
    =C2=A0
    My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t= see a reason why not. The question should be, what is the justification to= make =E2=80=9Cevents=E2=80=9D singular?
    [richann= a]The singular =E2=80=9Cevent=E2=80=9D claim has clearer semantics and is e= asier to process. We should opt for easier solutions unless there are use c= ases that require more complexity.[/richanna]
    =C2=A0
    There are many re= asons for multiple events in a SET.=C2=A0 Some are good, some not so good. = Some of the reasons...
    =C2=A0
    1.=C2=A0 Multiple event payloads expressing st= atements about largely the *same*thing. For example, SCIM password reset AN= D RISC password reset.=C2=A0 A RISC Event and an OpenBanking Event. Is one = a complement to the other?=C2=A0 Do they overlap or are they distinct? =C2= =A0
    [richanna]Copy/pasted from my earlier email:<= /span>
    Why is it necessary or appropriate to incl= ude these events in the same SET? They are likely being generated by differ= ent systems at different times on the transmitter=E2=80=99s side, consumed = by different systems on the receiver=E2=80=99s side, and possibly being tra= nsmitted over different event streams. I know the latter would be the case = for us, as a receiver. Even if it=E2=80=99s not, is it burdensome to send t= hese events separately? What value is gained in combining them?
    =C2=A0
    Additionally,= since the signature is over the SET and not the event objects, Receivers i= ndependently route separate events from a single token without either losin= g the ability to verify the authenticity of the event or sharing all inform= ation in the SET with every system handling any event in the token.[/richan= na]
    <= span style=3D"color:rgb(195,70,224)">=C2=A0

    2.=C2=A0 Multipl= e events payloads expressing different statements about the same transactio= n - RISC Password Reset and RISC Session Cancel
    [richanna]Same as above[/richanna]

    3.=C2=A0 A new profile= defines new event attributes to be added on to an existing event type (a p= ure extension)=C2=A0
    [richanna]I h= ave suggested a way to support extensions within an event body, multiple ti= mes now. If you see problems with it, please point them out.[/richanna]
    =C2=A0
    I think it is quite valid to allow 1 and 3. =C2=A02 could be limit= ed by specific profiles like RISC if they want.
    =C2=A0
    I am not in agreement = that making event singular simplifies anything. For one is makes extensions= complex (another nested JSON structure) and potentially conflicting.=C2=A0=
    [richanna]
    Ways that multiple-event SETs are more complicated:
      =
    1. It res= ults in a more complex structure for the single event use case, which I thi= nk we all agree is the majority use case.
    2. Multiple-event SETs h= ave ambiguous semantics. The presence of two events A and B in the same SET= could mean any of:
      1. The= y are related to the same logical event (i.e. the same thing as if they wer= e from different SETs that have a common txn).
      2. A is an extensi= on of B.
      3. B is an extension of A.
      4. They are aliases f= or one another.
      5. They are not actually related to one another in= any way.
    1. Claim semantics become harder to define, as different profiles = may want to use the same claims in different ways.
    <= /div>
    =C2=A0
    <= /div>
    If the WG wants to bl= ock 1 and 2 above, then I believe we have to establish an event registry to= ensure new Event profiles do not overlap to eliminate the need to express = multiple events.
    [richanna]I=E2=80=99m= not sure what you mean by this. Are you referring to event names? Those ar= e already defined by the spec to be URIs.[/richanna]
    P= hil
    =C2=A0
    Oracle Corporation, Identity Cloud Services Architect
    @independenti= d
    =C2=A0
    <= /div>
    On Oct 29, 2017, at 4:12 PM,= Dick Hardt <dick.hardt@gmail.com> wrote:
    <= /div>
    =C2=A0
    =
    Phil:
    <= /div>
    =C2=A0
    =
    In your examples for having a pluralit= y of events, you use the word "may", which leads me to question i= f a plurality of events is really required in SET.
    =C2=A0
    You posit that it will be dif= ficult for a distributed system to correlate multiple SETs with the same &q= uot;txn", but the distributed system will certainly need to correlate = events on the same subject -- correlating events on the same "txn"= ; on the same subject seems fairly simple.
    =
    =C2=A0
    I think that a receiver will need to = correlate multiple SEts on the same subject, so having multiple events in a= SET is redundant, and adds complexity with no clear benefit that I can see= .
    =C2= =A0
    An= implementor may choose to send multiple SETs, or send a single SET with mu= ltiple events, so a receiver will need to support both. I prefer we pick on= e way and minimize the code paths, and we will need to support correlating = across multiple SETs, so that seems the best mechanism.
    =C2=A0=
    Let me know if there i= s something I missed in my logic.
    =C2=A0
    /Dick
    =C2=A0
    <= /div>
    =C2=A0
    =
    On Sun, Oct 29, 2017 at 11:28 AM, Yaron Shef= fer=C2=A0<yaronf.ietf@gmail.com>=C2=A0= wrote:
    In that case, let's add text to that effect, e.g. we co= uld add to the definition of the "events" claim:

    Profiling= specifications SHOULD define the allowed event statements, and MAY restric= t their number. For example, some profiles may require this claim to contai= n only a single event statement.

    Thanks,
    =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0Yaron

    On 24/10/17 22:10, Mike Jones wrote:    <= u>

    I agree with much of Phil=E2=80=99s rationale here.

    It=E2=80= =99s fine for some profiles to say that the =E2=80=9Cevents=E2=80=9D set mu= st be a singleton.=C2=A0 That doesn=E2=80=99t have to be true for all event= s.=C2=A0 I think things are fine as-is.

    =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0-- Mike

    *From:* Id-event [mailto:id-event-bounces@ietf.<= wbr>org] *On Behalf Of *Phil Hunt
    *Sent:* Monday, October 23,= 2017 8:47 PM
    *To:* Richard Backman, Annabelle <richanna@amazon.com= >
    *Cc:* ID Events Mailing List <id-event@ietf.org>
    *= Subject:* Re: [Id-event] Use cases for multiple events per SET?

    Anna= belle,

    I have a number of concerns with this proposal.

    Profil= ing Independence / Keeping Event Payloads Independent

    Indicating tha= t extensions should be handled by profiles leads to more inter-operability = issues and more importantly intrudes on the Event payload space by suggesti= ng a sub-schema creates potential limitations and conflicts that may add to= complexity later on. The current format allows a parser to discover and un= load one or more JSON payloads which can each have independent structure.
    General extensions

    The proposal also rules out general purpose= extensions not related to any specific event. Given the emergence of items= like GPRD, I would not want to block the ability to add meta-data or other= general purpose items. We can also anticipate some delivery scenarios wher= e additional data might be required. Even though there is no current planne= d use, I see no good reason to rule this out.

    Multiple Events From D= ifferent Families (vs. Multiple Events from a single family like RISC)
    <= br>In our RISC session we discussed expressing multiple distinct RISC event= s in one SET. The discussion was that only one RISC event at a time. We did= not discuss other event profiles. I don=E2=80=99t see a reason to rule out= multi-events from different families at the SET level. Each profile is exp= ressing slightly different things about the same event.

    I can forsee= some cases where it is not clear which is the primary and which is the ext= ension.=C2=A0 There may not be a clear winner.

    A couple of examples = (these are necessarily real=E2=80=A6just possibilities):

    * It is pro= bably useful to be able to express simlar/overlapping events from different= SET profiles in one SET.=C2=A0 For example a Backchannel Logout & a RI= SC session cancel event.

    * SCIM may want to represent a single trans= action as causing multiple state changes in an event (e.g. a password chang= e causes multiple effects). Having to chase down multiple events and correl= ate by =E2=80=9Ctxn=E2=80=9D would be challenging in a multi-threaded/multi= -node delivery system.=C2=A0 =C2=A0The SCIM list has not discussed this, bu= t I would not want to block this capability.=C2=A0 IOW - Just because RISC = does not want to express multiple events does not make this true for other = profiles.

    * We may wish to indicate a SCIM Password Reset was perfor= med and a Logout/session cancellation is expressed at the same time.=C2=A0 = The events are related but express different data.

    Avoiding Confusio= n From Similar Events Originating from the Same Transaction

    If event= s are sent separately, then more tracking of state (e.g. by txn) would be r= equired to ensure similar events are not mistaken or handled as repeats. Wh= ile txn provides useful audit analysis capability, I=E2=80=99m not sure it = can be used in live or near-real time systems given distributed multi-node,= multi-threading architectures.

    Previous Discussion

    I note th= at I originally raised having an attribute to designate primary event attri= bute to alleviate your concern, but this was not accepted. See:

    *= =C2=A0    https://www.ietf.org/mail-archive/= web/id-event/current/msg00406.html

    *=C2=A0<= a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mail-2Darchive_web_id-2Devent_current_msg00140.html&d=3DDwMFaQ&c= =3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4Dpc= tyXPpuYqPkAI1aLcLN4KZNA&m=3DYBCGlK9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw= &s=3DGy9gyRoIIta-cShV7bN161ay4yE6r9G1_Aa_NeBnylg&e=3D" style=3D"col= or:purple;text-decoration:underline" class=3D"m_-1329852460247035742m_63374= 40896153279834m_-3151445958451029318m_7476346946956833004cremed m_-13298524= 60247035742m_6337440896153279834cremed cremed" target=3D"_blank">https://www.ietf.org/mail-archive/web/id-event/curr= ent/msg00140.html

    The consensus, at least as I inter= preted it is up to the receiver to figure this out based on the definitions= it has for each event URI and the profiles they represent. IOW - RISC is f= ree to limit that only one RISC event be expressed at a time.

    Phil
    Oracle Corporation, Identity Cloud Services Architect

    @indepen= dentid

    www.indepe= ndentid.com=C2=A0<http://www.independentid.com>

    = phil= .hunt@oracle.com=C2=A0<mailto:phil.hunt@oracle.com<= /span>>

    =C2=A0 =C2=A0 On Oct 23, 2017, at 7:02 PM, Richard Ba= ckman, Annabelle
    =C2=A0 =C2=A0 <richanna@amazon.com=C2=A0<mailto:richanna@amazon.com>> wrote:

    =C2=A0 = =C2=A0 The current draft of the SET spec allows for expressing multiple
    = =C2=A0 =C2=A0 events within the same token, which introduces additional com= plexity
    =C2=A0 =C2=A0 and room for ambiguous semantics. We=E2=80=99ve di= scussed this in the OIDF
    =C2=A0 =C2=A0 RISC working group and the curren= t consensus there is that RISC will
    =C2=A0 =C2=A0 require that RISC even= ts must be the only event in the SET, having
    =C2=A0 =C2=A0 identified wa= ys to clearly and easily support the handful of use
    =C2=A0 =C2=A0 cases = for multiple events per token that people have raised. With
    =C2=A0 =C2= =A0 that context in mind, I propose striking the definition of the
    =C2= =A0 =C2=A0 =E2=80=9Cevents=E2=80=9D claim from the Security Event Token spe= c, and replacing it
    =C2=A0 =C2=A0 with the following definition for an = =E2=80=9Cevent=E2=80=9D claim (singular):

    =C2=A0 =C2=A0 event
    =C2=A0 =C2=A0 A JSON object containing an "event_type" member wh= ose value is a URI
    =C2=A0 =C2=A0 representing a type of event defined in= a Profiling Specification.
    =C2=A0 =C2=A0 The object MAY otherwise be em= pty, or MAY contain additional members
    =C2=A0 =C2=A0 as described by the= Profiling Specification.

    =C2=A0 =C2=A0 Here is the example SET from= section 2.3, rewritten with this change
    =C2=A0 =C2=A0 mind:

    =C2= =A0 =C2=A0=C2=A0{

    =C2=A0 =C2=A0 =C2=A0=C2=A0 "jti"= ;: "4d3559ec67504aaba65d40b0363faad8",

    =C2=A0 =C2=A0 = =C2=A0=C2=A0 "iat": 1458496404,

    =C2=A0 =C2=A0 =C2=A0=C2=A0= "iss": "https://scim.example.com=C2=A0<http= s://scim.example.com/>",

    =C2=A0 =C2=A0 =C2=A0=C2= =A0 "aud": [

    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0"= https://scim.example.com/Feeds/98d52461fa5bb= c879593b7754    ",

    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0=C2=A0"https://scim.example.com/Feed= s/5d7604516b1d08641d7676ee7"

    =C2=A0 =C2=A0 =C2=A0=C2= =A0 ],

    =C2=A0 =C2=A0 =C2=A0=C2=A0 "event": {

    =C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 "event_type": "urn:ietf:par= ams:scim:event:create",

    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0 "ref": "https://scim.example= .com/Users/44f6142df96bd6ab61e7521d9",

    =C2=A0 = =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 "attributes": ["id", &q= uot;name", "userName", "password", "emails&qu= ot;]

    =C2=A0 =C2=A0 =C2=A0=C2=A0 }

    =C2=A0 =C2=A0 }

    =C2= =A0 =C2=A0 Does anyone in the working group have use cases for SETs that ca= nnot
    =C2=A0 =C2=A0 be met by this proposed text? Within RISC, we identif= ied three use
    =C2=A0 =C2=A0 cases, with solutions outlined below:
    =C2=A0 =C2=A0 **

    =C2=A0 =C2=A0 *Extensions*

    =C2=A0 =C2=A0 Ev= ent extension mechanisms can be defined internal to the event
    =C2=A0 =C2= =A0 object. A simple approach would be to =C2=A0define an =E2=80=9Cextensio= ns=E2=80=9D member
    =C2=A0 =C2=A0 that is a list of event objects (or set= resembling the =E2=80=9Cevents=E2=80=9D
    =C2=A0 =C2=A0 claim as defined = in the current spec). This has the advantage of
    =C2=A0 =C2=A0 making it = clear in the data structure that there is a single primary
    =C2=A0 =C2=A0= event, with zero or more extensions. There is no room for confusion
    =C2= =A0 =C2=A0 over which event is primary, or if there is a primary event at a= ll.
    =C2=A0 =C2=A0 I would be fine with adding something like this to my = proposed text,
    =C2=A0 =C2=A0 if there is consensus that it is broadly us= eful.

    =C2=A0 =C2=A0 *Aliases*

    =C2=A0 =C2=A0 This use case was= brought up in the context of migrating clients
    =C2=A0 =C2=A0 from draft= event names to standardized event names. In this case,
    =C2=A0 =C2=A0 th= e event transmitter can transmit two tokens for the logical event,
    =C2= =A0 =C2=A0 one using the old name and another using the new name.

    = =C2=A0 =C2=A0 *Related Events*

    =C2=A0 =C2=A0 The SET spec defines th= e txn claim as a means of correlating
    =C2=A0 =C2=A0 independent tokens t= hat relate to the same logical event.

    =C2=A0 =C2=A0 --=C2=A0
    =C2=A0 =C2=A0 Annabelle Richard Backman

    =C2=A0 =C2=A0 Amazon = =E2=80=93 Identity Services

    =C2=A0 =C2=A0 __________________________= _____________________
    =C2=A0 =C2=A0 Id-event mailing list
    =C2=A0= =C2=A0=C2=A0Id-event@ietf.org=C2=A0<mailto:Id-event= @ietf.org>
    =C2=A0 =C2=A0=C2=A0https://urldefense.proo= fpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-= 2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkK= Y057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&= ;m=3Ds5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=3DX8oRSq3I= zlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D


    _______________________________________________
    Id-event mailing l= ist
    = Id-event@ietf.org
    <= span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/id-e= vent


    _______________________________________________
    Id-event ma= iling list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listi= nfo/id-event
    =


    =
    =C2=A0
    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    =
    =C2=A0


    =C2=A0<= /u>
    --
    <= div>
    Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I am working on!
    =
    <= /div>


    =C2=A0
    --
    Subscr= ibe to the=C2=A0HARDTWARE=C2=A0mail list to learn ab= out projects I am working on!

    =C2=A0
    <= /div>
    = --
    Subscribe to = the= =C2=A0HARDTWARE=C2=A0mail list to learn about p= rojects I am working on!
    <= /div>


    =C2=A0
    --=C2=A0
    Subscribe to the=C2=A0HARDTWARE=C2=A0mail list= to learn about projects I am working on!
    ___________________________________________= ____
    Id-event mailing list
    Id-event@ietf.org
    https://urldefense.proofpo= int.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2De= vent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m= =3DsIGz8gur4wNqZktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=3DgdNrs7UDAt= tpabjM5ndOXwWKmZuKaXEbT5wu9rcORV0&e=3D


    _______________________________________________
    Id-event mailing list
    Id-event@i= etf.org
    https://www.ietf.org/mailman/listinfo/i= d-event



    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event





    --f403045d9a14154592055cf31eb0-- From nobody Wed Nov 1 15:12:31 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CEB13F6A1 for ; Wed, 1 Nov 2017 15:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.997 X-Spam-Level: X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNzRMJHCHtss for ; Wed, 1 Nov 2017 15:12:24 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 1C0F213F752 for ; Wed, 1 Nov 2017 15:12:19 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA1MCCTl007962 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Nov 2017 22:12:12 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vA1MCBdB000872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Nov 2017 22:12:11 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA1MCB2X019117; Wed, 1 Nov 2017 22:12:11 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 15:12:08 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-34D4AE84-4988-483D-8237-1FF0FCD453BD Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 1 Nov 2017 15:11:59 -0700 Cc: William Denniss , "Richard Backman, Annabelle" , Yaron Sheffer , Mike Jones , ID Events Mailing List , Dick Hardt Content-Transfer-Encoding: 7bit Message-Id: <3D3EBCF1-48EE-4813-9242-BD0C5B5E8699@oracle.com> References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> To: Marius Scurtescu X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 22:12:30 -0000 --Apple-Mail-34D4AE84-4988-483D-8237-1FF0FCD453BD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The two control plane proposals don't actually support composite events. The= y only indicate a primary event. The txr is free to attach composite extensi= ons as it thinks needed.=20 We may still have to address that.=20 Phil > On Nov 1, 2017, at 3:08 PM, Marius Scurtescu wrote= : >=20 >> On Wed, Nov 1, 2017 at 3:00 PM, William Denniss wro= te: >> The receiver probably knows which version they want, but does the sender?= Using the email analogy, you may have configured your email client to accep= t plain text only. Fortunately, my client sends both =E2=80=93 not knowing w= hat you prefer =E2=80=93 and you are able to view my message. >=20 > Two solutions: > - since receiver knows what version they want they are going to only consu= me that and ignore the other > - there is a proposal underway so that receivers can tell the sender exact= ly what they want, no events dropped on the floor >=20 >=20 >>=20 >> I think it would help if we broke this problem down into two parts. 1/ Ar= e multi-format SETs desirable? That's been the design since the earliest ver= sion. 2/ What is the best representation of the SET based on what we decide f= or #1. >=20 > Yes, and #1 above is being challenged. >=20 > =20 >>=20 >> My understanding was that the "events" plural (related to #2, the best re= presentation of a SET) was in fact a concern, as people may skip the text an= d look directly at the JSON syntax, then jump to conclusions. >>=20 >>> On Wed, Nov 1, 2017 at 2:54 PM, Marius Scurtescu = wrote: >>>> On Wed, Nov 1, 2017 at 2:46 PM, William Denniss w= rote: >>>> Perhaps I can try and explain the original intent of the current design= . The goal was always that a SET represents a single logical event. However m= ultiple systems may have different representations of the event =E2=80=93 th= e example given originally was one formatted for RISC, and one for SCIM. >>>>=20 >>>> A good analogy is email. You send a single logical email, which may hav= e two representations, HTML and plain text. Systems can consume the version t= hat they understand and ignore the one they don't. >>>=20 >>> Yes, and I think this is well understood. >>>=20 >>> =20 >>>>=20 >>>> I'm starting to regret the plural in "events", it was pluralized due to= it being an array, not because it represented multiple logical events. >>>=20 >>> I don't think this is the main concern or cause for confusion. >>>=20 >>> =20 >>>>=20 >>>> Annabelle, I understand your concerns regarding confusion of the semant= ics between the JSON syntax and the specification language. Are there other w= ays to resolve that without removing the ability for multiple representation= s of the same event? >>>=20 >>> The argument is that multiple representations can be sent as distinct SE= Ts, if really needed. In practice this will happen quite rare though. Events= are created for a specific receiver, the receiver either wants the SCIM or t= he RISC flavor, and they should be able to specify that in configuration (th= ere is a proposal how to capture that). >>>=20 >>> Do we have a compelling use case where a receiver must receive multiple v= ariants all at once? >>>=20 >>> =20 >>>>=20 >>>>> On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu wrote: >>>>>> On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt wro= te: >>>>>> You can=E2=80=99t really have multiple events (at least of the same t= ype). The current spec can only have one instance of a URI (afaik). =20 >>>>>>=20 >>>>>> Note that the spec normatively does not support multiple event SETS. = It currently states: >>>>>>> events >>>>>>> The semantics of this claim is to define a set of event statem= ents >>>>>>> that each MAY add additional claims to fully describe a single= >>>>>>> logical event that has occurred (e.g. a state change to a >>>>>>> subject). Multiple event statements of the same type SHALL NO= T be >>>>>>> accepted. The "events" claim SHOULD NOT be used to express >>>>>>> multiple logical events. >>>>>>=20 >>>>>> The spec has *always* supported requirements (as stated in the spec) f= or multiple separate profile statements (from one or more profile familities= ) needing to be sent as a single message. It would be INSECURE to force mul= tiple SETs because the current delivery mechanism only allows one SET to be d= elivered at a time. There is no way to assure that a single receiver gets al= l of the SETs it needs in a multi-threaded, multi-node environment at scale.= Assembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a common state d= atabase is NOT simple nor cost effective. >>>>>=20 >>>>> I totally agree that it is difficult for receivers to receive separate= events, in no particular order and correlate based on "txn". But, receivers= have to solve this issue regardless of "events" or "event", so it is unrela= ted to this proposal. >>>>>=20 >>>>> =20 >>>>>>=20 >>>>>> If we accommodate this in the proposed form, we end up with a complex= , deeply nested JSON structure with the possibility of namespace conflicts. >>>>>>=20 >>>>>> IMO The proposal does not simplify, it complicating and limiting. =20= >>>>>>=20 >>>>>> The current spec has very clean JSON and avoids namespace conflicts b= etween profiles. I think we should stay on track with the current draft and o= bserve the normative text if not make it stronger in regards to multi-events= (understood that Mike may disagree). >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>> On Nov 1, 2017, at 12:18 PM, Richard Backman, Annabelle wrote: >>>>>>>=20 >>>>>>> Unless the profile guarantees that such related events will always b= e included in the same SET, then the receiver has to correlate across SETs a= nyway, and multiple events per SET is just giving the receiver another scena= rio that they have to support. >>>>>>> =20 >>>>>>> I=E2=80=99ve already provided several other reasons why we should no= t support multiple tokens per SET that no one has addressed. Here they are a= gain: >>>>>>> Multiple event support results in a more complex structure for the s= ingle event use case, which I think we all agree is the majority use case. >>>>>>> Multiple-event SETs have ambiguous semantics. The presence of two ev= ents A and B in the same SET could mean any of: >>>>>>> A and B are related to the same logical event (i.e. the same thing a= s if they were from different SETs that have a common txn). >>>>>>> A is an extension of B. >>>>>>> B is an extension of A. >>>>>>> A is an alias for B, or vice-versa. >>>>>>> A and B are not actually related to one another in any way, and the t= ransmitter bundled them together because they were going to the same receive= r. >>>>>>> Top-level claim semantics become harder to define, as different prof= iles may want to use the same claims in different ways. >>>>>>> Event authenticity cannot be verified without having the entire SET.= This forces receivers to expose downstream systems to more information nece= ssary, if those systems need to be able to verify authenticity. >>>>>>> =20 >>>>>>> --=20 >>>>>>> Annabelle Richard Backman >>>>>>> Amazon =E2=80=93 Identity Services >>>>>>> =20 >>>>>>> =20 >>>>>>> From: Mike Jones >>>>>>> Date: Wednesday, November 1, 2017 at 11:21 AM >>>>>>> To: Dick Hardt >>>>>>> Cc: Yaron Sheffer , "Richard Backman, Annabel= le" , ID Events Mailing List , "Phil= Hunt (IDM)" >>>>>>> Subject: RE: [Id-event] Use cases for multiple events per SET? >>>>>>> =20 >>>>>>> I completely agree on moving complexity to the issuer over the recip= ient. In my view, it=E2=80=99s more complex for recipients to have to corre= late and process a sequence of multiple SETs providing information about the= same logical event, and validate N signatures, than to receive one SET with= all the aspects of the logical event as =E2=80=9Cevents=E2=80=9D fields, wi= th no correlation over time then required. >>>>>>> =20 >>>>>>> -- Mike >>>>>>> =20 >>>>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >>>>>>> Sent: Wednesday, November 1, 2017 9:39 AM >>>>>>> To: Mike Jones >>>>>>> Cc: Yaron Sheffer ; Richard Backman, Annabell= e ; ID Events Mailing List ; Phil Hu= nt (IDM) >>>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>>> =20 >>>>>>> Your comments highlight a couple of points: >>>>>>> =20 >>>>>>> 1) The example is how to have a predefined extension point for exten= sions of a specific event, it is not how to add another event. Myself, I thi= nk this is overly complicated. Events should be comparatively static, and as= with many other JSON formats, the receiver should ignore properties it does= not understand, which let's new properties be introduced as extensions. The= re should not be any conflict as extensions should only be done by the profi= le that created the event format to start off with. >>>>>>> =20 >>>>>>> 2) Having an lvalue be a URI is much harder to code against. I'm not= sure why Marius had that in his example. Per the event, the type of the eve= nt is well defined with=20 >>>>>>> =20 >>>>>>> "event_type": "https://example.com/scim/event/passwordResetExt", >>>>>>> =20 >>>>>>> 3) This thread is about reasons for multiple events to be contained i= n one set. Your mention of an issuer not wanting to sign separate events as a= reason to allow multiple events. I think we have decided that given a prefe= rence, we will push effort to the transmitter over the receiver as in many u= se cases there are many more receivers. Given that, it is more complex for a= receiver to have different ways of managing the receipt of multiple events a= s not all issuers will bundle the events, so it is simpler to have only one e= vent per SET. Including the separate events with a URI as an lvalue is chall= enging to implement, speaking from experience. >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>> On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones wrote: >>>>>>>> Marius=E2=80=99 proposed syntax, pasted in below, has exactly this c= haracteristic. The way I see it, his proposal essentially has a primary pas= swordReset event and a secondary passwordResetExt data structure, which coul= d have been simply another event value in the current draft. >>>>>>>> =20 >>>>>>>> This breaking change makes the data structures more complicated - n= ot less. And it makes things that used to be possible impossible, reducing f= lexibility to those who would use the spec. >>>>>>>> =20 >>>>>>>> These seem like bad tradeoffs to me. >>>>>>>> =20 >>>>>>>> { >>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>> "iat": 1458496025, >>>>>>>> "iss": "https://scim.example.com", >>>>>>>> "aud": [ >>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>> ], >>>>>>>> "event_type": "https://example.com/scim/event/passwordResetExt",= >>>>>>>> "event": { =20 >>>>>>>> "id":"44f6142df96bd6ab61e7521d9", >>>>>>>> "extensions": { >>>>>>>> "https://example.com/scim/event/passwordResetExt=E2=80=9D= : { >>>>>>>> "resetAttempts":5, >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> =20 >>>>>>>> In particular, it makes it impossible to sign multiple related even= ts sharing a common claims schema with a single signature by the issuer. It= forces the issuer to do the extra work of signing each of the related event= s (or facets of the same logical event) individually and forces the recipien= ts to do the extra work of checking all those unnecessary signatures. >>>>>>>> =20 >>>>>>>> Not every profile will ever have multiple keys in the =E2=80=9Ceven= ts=E2=80=9D set but there=E2=80=99s absolutely no reason to preclude it. >>>>>>>> =20 >>>>>>>> -- Mike >>>>>>>> =20 >>>>>>>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Dick= Hardt >>>>>>>> Sent: Tuesday, October 31, 2017 9:52 PM >>>>>>>> To: Mike Jones >>>>>>>> Cc: Yaron Sheffer ; Richard Backman, Annabel= le ; ID Events Mailing List ; Phil H= unt (IDM) >>>>>>>>=20 >>>>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>>>> =20 >>>>>>>> Please direct me to a proposal that has a "primary" and "secondary"= events. I agree that is undesirable. I would also encourage to engage in th= e discussions so that we can drive clarity and simplicity. >>>>>>>> =20 >>>>>>>> I think the proposal is that there is one event per SET. >>>>>>>> =20 >>>>>>>> I think having more than one event per SET adds complexity as a rec= eiver must deal with receiving correlated events in one SET as well as corre= lated events in the same SET. >>>>>>>> =20 >>>>>>>> /Dick >>>>>>>> =20 >>>>>>>>> On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones wrote: >>>>>>>>> I hear you on the fact that different people have joined the effor= t at different times. That=E2=80=99s a normal process as an effort builds m= omentum. I get that not everyone was there when previous consensus calls we= re taken. >>>>>>>>> =20 >>>>>>>>> I should note that I have specific technical objections to the spe= cific proposed changes being discussed as well. Currently all events in the= set have the same syntax. The proposals, as I understand them, revert us t= o a state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and =E2=80=9Csec= ondary=E2=80=9D events, with different syntax for the two classes. That=E2=80= =99s needlessly more complicated, adding no actual value. >>>>>>>>> =20 >>>>>>>>> --= Mike >>>>>>>>> =20 >>>>>>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >>>>>>>>> Sent: Tuesday, October 31, 2017 9:37 PM >>>>>>>>> To: Mike Jones >>>>>>>>> Cc: Phil Hunt (IDM) ; Yaron Sheffer ; Richard Backman, Annabelle ; ID Events= Mailing List >>>>>>>>>=20 >>>>>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>>>>> =20 >>>>>>>>> Mike >>>>>>>>> =20 >>>>>>>>> As you well know, many people in a WG don't look closely at a spec= ification until last call is made. Additionally, we are coming up on only th= e 3rd WG meeting. The WG has not existed for very long. While some of the pa= rticipants have been working on this for a while, many have not, and we are l= ooking for consensus across the WG. >>>>>>>>> =20 >>>>>>>>> Since SecEvent is a framework that we expect to be profiled, I fee= l it is important to ensure that SecEvent specifications are easy for a vari= ety of profiles to adopt, and that the semantics make sense. I also think th= at properties that are specific to a profile should be left to that profile a= nd not be included in SecEvent. >>>>>>>>> =20 >>>>>>>>> Since this is a framework, it is expected that as different groups= profile it, there will be additional feedback. >>>>>>>>> =20 >>>>>>>>> Specifically, as a participant in the RISC profile of SET, a numbe= r of issues in SET have surfaced as the RISC WG has looked at how to use the= SET. >>>>>>>>> =20 >>>>>>>>> As for SET being stable for over a year, there have been a number o= f changes to SET since then. I also don't think there was consensus. Before t= he WG was formed, I and several others had expressed concern on the design o= f SET when Phil presented it at an IIW session. >>>>>>>>> =20 >>>>>>>>> As to taking another year, I am hopeful we can resolve the remaini= ng issues in SET and publish a new draft for last call. I do not think we wi= ll need to wait for another WG meeting to ask for last call.=20 >>>>>>>>> =20 >>>>>>>>> We also have a number of other documents that are not in last call= , and we don't have a WG adopted draft yet for management. So there are stil= l a number of documents to work through before we have all the bits for some= one to work with. >>>>>>>>> =20 >>>>>>>>> I do think we have been making good progress since the last IETF m= eeting, and I am hopeful we can keep up this momentum and finalize all the d= ocuments in a timely manner. >>>>>>>>> =20 >>>>>>>>> /Dick >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>>> On Tue, Oct 31, 2017 at 12:48 PM, Mike Jones wrote: >>>>>>>>>> It=E2=80=99s hard for me to even express my level of frustration w= ith the recent attempts to once again redesign the SecEvent Token spec. We=E2= =80=99ve been at this for multiple years because people keep trying to revis= it decisions that were long ago made by consensus. It=E2=80=99s been stable= for over a year and the majority of WGLC respondents said some variant of =E2= =80=9CWorks for me =E2=80=93 ship it!=E2=80=9D >>>>>>>>>> =20 >>>>>>>>>> There=E2=80=99s not sufficient justification to try to undo conse= nsus positions that have been debated and affirmed over and over. Countenan= cing wholesale changes at this late date is counterproductive in the extreme= ! >>>>>>>>>> =20 >>>>>>>>>> It=E2=80=99s far better than good enough as-is. In my experience= , if we start redesigning it, it will result in another year=E2=80=99s delay= . It does something simple and useful. Please, let=E2=80=99s just ship it,= so people can rely on it. >>>>>>>>>> =20 >>>>>>>>>> -- Mike >>>>>>>>>> =20 >>>>>>>>>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20 >>>>>>>>>> Sent: Monday, October 30, 2017 2:42 PM >>>>>>>>>> To: Dick Hardt >>>>>>>>>> Cc: Yaron Sheffer ; Richard Backman, Annab= elle ; Mike Jones ; ID Eve= nts Mailing List >>>>>>>>>>=20 >>>>>>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET? >>>>>>>>>> =20 >>>>>>>>>> Inline... >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On Oct 30, 2017, at 2:22 PM, Dick Hardt w= rote: >>>>>>>>>>> Hi Phil >>>>>>>>>>> =20 >>>>>>>>>>> Correct me if I am misunderstanding, but there is a RISC profile= event=20 >>>>>>>>>>> =20 >>>>>>>>>>> "http://schemas.openid.net/secevent/risc/event-type/account-cred= ential-change-required=E2=80=9D >>>>>>>>>>> =20 >>>>>>>>>>> and an SCIM profile event >>>>>>>>>>> =20 >>>>>>>>>>> "https://example.com/scim/event/passwordResetExt=E2=80=9D >>>>>>>>>>> =20 >>>>>>>>>>> I'm suggesting that two different events would be sent. Embeddin= g one in the other does not make sense. >>>>>>>>>> It is a hypothetical example. Just because you disagree on th= is does not mean others are not valid.=20 >>>>>>>>>> =20 >>>>>>>>>> I just picked overlapping proposals that have different meaning (= but not the same) to illustrate the difference from issuing a single set wit= h different events.=20 >>>>>>>>>> =20 >>>>>>>>>> As I have stated this is very different from asserting multiple d= istinct events in one SET.=20 >>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> Also, I think it is simpler to have event_type be at the same le= vel as event >>>>>>>>>> =20 >>>>>>>>>> may be. I was working from Annabelle's proposed format.=20 >>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> { >>>>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>>>> "iat": 1458496025, >>>>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>>>> "aud": [ >>>>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>>>> ], >>>>>>>>>>> "event_type": "https://example.com/scim/event/passwordResetEx= t", >>>>>>>>>>> "event": { =20 >>>>>>>>>>> "id":"44f6142df96bd6ab61e7521d9", >>>>>>>>>>> "resetAttempts":5 >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> =20 >>>>>>>>>>> { >>>>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>>>> "iat": 1458496025, >>>>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>>>> "aud": [ >>>>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >>>>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>>>> ], >>>>>>>>>>> "event_type": "http://schemas.openid.net/secevent/risc/event-= type/account-credential-change-required", >>>>>>>>>>> "event": { >>>>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" =20= >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>>> On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt wrote: >>>>>>>>>>>> Annabelle/Dick, >>>>>>>>>>>> =20 >>>>>>>>>>>> Thanks for the comments. I think we need to examine the consequ= ences of the proposal in JSON. >>>>>>>>>>>> =20 >>>>>>>>>>>> As I stated, what causes most of the issue is the proposed exte= nsion mechanism in the payload (possibly using events in a recursive way). D= oes it follow the old format or the new? >>>>>>>>>>>> =20 >>>>>>>>>>>> Let=E2=80=99s consider a use case where we have an identity ma= nagement system that uses SCIM, but the SCIM system is also the underlying d= ata store for Connect. A Password reset might generate the following event w= hich has an extension (conveying reset count) AND overlapping statement from= RISC. BOTH of which might be important to a similar receiver using SCIM an= d OIDC. =20 >>>>>>>>>>>> =20 >>>>>>>>>>>> The 03 spec currently would allow: >>>>>>>>>>>> =20 >>>>>>>>>>>> { >>>>>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>>>>> "iat": 1458496025, >>>>>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>>>>> "aud": [ >>>>>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",= >>>>>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>>>>> ], >>>>>>>>>>>> "events": { >>>>>>>>>>>> "urn:ietf:params:scim:event:passwordReset": >>>>>>>>>>>> { "id":"44f6142df96bd6ab61e7521d9"}, >>>>>>>>>>>> "https://example.com/scim/event/passwordResetExt": >>>>>>>>>>>> { "resetAttempts":5}, >>>>>>>>>>>> "http://schemas.openid.net/secevent/risc/event-type/\ >>>>>>>>>>>> account-credential-change-required": { >>>>>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D= , >>>>>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> =20 >>>>>>>>>>>> In the above - each payload is a =E2=80=98peer' and issued with= out preference by the transmitter. The receiver can assign priority in its o= wn context if that matters. >>>>>>>>>>>> =20 >>>>>>>>>>>> The new proposal: >>>>>>>>>>>> =20 >>>>>>>>>>>> { >>>>>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>>>>> "iat": 1458496025, >>>>>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>>>>> "aud": [ >>>>>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",= >>>>>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>>>>> ], >>>>>>>>>>>> "event": { >>>>>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:p= asswordReset=E2=80=9D, >>>>>>>>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>>>>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>>>>>>>> ->note =E2=80=A6is this the old or new structure? <- >>>>>>>>>>>> "https://example.com/scim/event/passwordResetExt": >>>>>>>>>>>> { "resetAttempts":5}, >>>>>>>>>>>> "http://schemas.openid.net/secevent/risc/event-type/\ >>>>>>>>>>>> account-credential-change-required": { >>>>>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D= , >>>>>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/" >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> } =20 >>>>>>>>>>>> } >>>>>>>>>>>> =20 >>>>>>>>>>>> In the above, sub-events or extensions have a different format.= The same complaint about the original stands. >>>>>>>>>>>> =20 >>>>>>>>>>>> *OR* (if the receiver cares about RISC more). Note that this l= eads to a triple nested structure. >>>>>>>>>>>> =20 >>>>>>>>>>>> { >>>>>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>>>>> "iat": 1458496025, >>>>>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>>>>> "aud": [ >>>>>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",= >>>>>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>>>>> ], >>>>>>>>>>>> "event": { >>>>>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/se= cevent/risc/event-type/\ >>>>>>>>>>>> account-credential-change-required=E2=80=9D, >>>>>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C,= >>>>>>>>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>>>>>>>> "urn:ietf:params:scim:event:passwordReset": >>>>>>>>>>>> {=20 >>>>>>>>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>>>>>>>> =E2=80=9Cevents=E2=80=9D:{ >>>>>>>>>>>> "https://example.com/scim/event/passwordResetExt":= >>>>>>>>>>>> { "resetAttempts":5}, =20 >>>>>>>>>>>> } =20 >>>>>>>>>>>> } >>>>>>>>>>>> } =20 >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> =20 >>>>>>>>>>>> In the above, the extension is placed inside the event it exten= ds. It follows the old format (or should it follow the new?) >>>>>>>>>>>> *OR* Following the top layer pattern of singular event Note th= at this leads to a triple nested structure. >>>>>>>>>>>> =20 >>>>>>>>>>>> { >>>>>>>>>>>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>>>>>>>>>>> "iat": 1458496025, >>>>>>>>>>>> "iss": "https://scim.example.com", >>>>>>>>>>>> "aud": [ >>>>>>>>>>>> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",= >>>>>>>>>>>> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >>>>>>>>>>>> ], >>>>>>>>>>>> "event": { >>>>>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/se= cevent/risc/event-type/\ >>>>>>>>>>>> account-credential-change-required=E2=80=9D, >>>>>>>>>>>> =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D, >>>>>>>>>>>> =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=9C,= >>>>>>>>>>>> =E2=80=9Cevent=E2=80=9D:{ >>>>>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:even= t:passwordReset=E2=80=9D, >>>>>>>>>>>> "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D, >>>>>>>>>>>> =E2=80=9Cevent=E2=80=9D:{ >>>>>>>>>>>> =E2=80=9Cevent_type=E2=80=9D:"https://example.com/sci= m/event/passwordResetExt=E2=80=9D, >>>>>>>>>>>> "resetAttempts":5=20 >>>>>>>>>>>> } >>>>>>>>>>>> } =20 >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> =20 >>>>>>>>>>>> This format follows the proposed singular event format recursiv= ely and is 3 layers deep. Note that the parser has to continue to search the= document for things that aren=E2=80=99t there as it has to stop when no =E2= =80=9Cevent=E2=80=9D attribute is found rather than iterate over an array. >>>>>>>>>>>> =20 >>>>>>>>>>>> Phil >>>>>>>>>>>>=20 >>>>>>>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>>>>>>> @independentid >>>>>>>>>>>> www.independentid.com >>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>> =20 >>>>>>>>>>>>> On Oct 30, 2017, at 8:57 AM, Richard Backman, Annabelle wrote: >>>>>>>>>>>>> =20 >>>>>>>>>>>>> Replies inline. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>>>> Identity Services >>>>>>>>>>>>> =20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> From: Phil Hunt >>>>>>>>>>>>> Date: Sunday, October 29, 2017 at 5:25 PM >>>>>>>>>>>>> To: Dick Hardt >>>>>>>>>>>>> Cc: Yaron Sheffer , Mike Jones , "Richard Backman, Annabelle" , I= D Events Mailing List >>>>>>>>>>>>> Subject: Re: [Id-event] Use cases for multiple events per SET?= >>>>>>>>>>>>> =20 >>>>>>>>>>>>> I hope this answers your question. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a rea= son why not. The question should be, what is the justification to make =E2=80= =9Cevents=E2=80=9D singular? >>>>>>>>>>>>> [richanna]The singular =E2=80=9Cevent=E2=80=9D claim has clear= er semantics and is easier to process. We should opt for easier solutions un= less there are use cases that require more complexity.[/richanna] >>>>>>>>>>>>> =20 >>>>>>>>>>>>> There are many reasons for multiple events in a SET. Some are= good, some not so good. Some of the reasons... >>>>>>>>>>>>> =20 >>>>>>>>>>>>> 1. Multiple event payloads expressing statements about largel= y the *same*thing. For example, SCIM password reset AND RISC password reset.= A RISC Event and an OpenBanking Event. Is one a complement to the other? D= o they overlap or are they distinct? =20 >>>>>>>>>>>>> [richanna]Copy/pasted from my earlier email: >>>>>>>>>>>>> Why is it necessary or appropriate to include these events in t= he same SET? They are likely being generated by different systems at differe= nt times on the transmitter=E2=80=99s side, consumed by different systems on= the receiver=E2=80=99s side, and possibly being transmitted over different e= vent streams. I know the latter would be the case for us, as a receiver. Eve= n if it=E2=80=99s not, is it burdensome to send these events separately? Wha= t value is gained in combining them? >>>>>>>>>>>>> =20 >>>>>>>>>>>>> Additionally, since the signature is over the SET and not the e= vent objects, Receivers independently route separate events from a single to= ken without either losing the ability to verify the authenticity of the even= t or sharing all information in the SET with every system handling any event= in the token.[/richanna] >>>>>>>>>>>>> =20 >>>>>>>>>>>>> 2. Multiple events payloads expressing different statements a= bout the same transaction - RISC Password Reset and RISC Session Cancel >>>>>>>>>>>>> [richanna]Same as above[/richanna] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 3. A new profile defines new event attributes to be added on t= o an existing event type (a pure extension)=20 >>>>>>>>>>>>> [richanna]I have suggested a way to support extensions within a= n event body, multiple times now. If you see problems with it, please point t= hem out.[/richanna] >>>>>>>>>>>>> =20 >>>>>>>>>>>>> I think it is quite valid to allow 1 and 3. 2 could be limite= d by specific profiles like RISC if they want. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> I am not in agreement that making event singular simplifies an= ything. For one is makes extensions complex (another nested JSON structure) a= nd potentially conflicting.=20 >>>>>>>>>>>>> [richanna] >>>>>>>>>>>>> Ways that multiple-event SETs are more complicated: >>>>>>>>>>>>> It results in a more complex structure for the single event us= e case, which I think we all agree is the majority use case. >>>>>>>>>>>>> Multiple-event SETs have ambiguous semantics. The presence of t= wo events A and B in the same SET could mean any of: >>>>>>>>>>>>> They are related to the same logical event (i.e. the same thin= g as if they were from different SETs that have a common txn). >>>>>>>>>>>>> A is an extension of B. >>>>>>>>>>>>> B is an extension of A. >>>>>>>>>>>>> They are aliases for one another. >>>>>>>>>>>>> They are not actually related to one another in any way. >>>>>>>>>>>>> Claim semantics become harder to define, as different profiles= may want to use the same claims in different ways. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> If the WG wants to block 1 and 2 above, then I believe we have= to establish an event registry to ensure new Event profiles do not overlap t= o eliminate the need to express multiple events. >>>>>>>>>>>>> [richanna]I=E2=80=99m not sure what you mean by this. Are you r= eferring to event names? Those are already defined by the spec to be URIs.[/= richanna] >>>>>>>>>>>>> Phil >>>>>>>>>>>>> =20 >>>>>>>>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>>>>>>>> @independentid >>>>>>>>>>>>> www.independentid.com >>>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>> =20 >>>>>>>>>>>>>> On Oct 29, 2017, at 4:12 PM, Dick Hardt wrote: >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> Phil: >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> In your examples for having a plurality of events, you use th= e word "may", which leads me to question if a plurality of events is really r= equired in SET. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> You posit that it will be difficult for a distributed system t= o correlate multiple SETs with the same "txn", but the distributed system wi= ll certainly need to correlate events on the same subject -- correlating eve= nts on the same "txn" on the same subject seems fairly simple. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> I think that a receiver will need to correlate multiple SEts o= n the same subject, so having multiple events in a SET is redundant, and add= s complexity with no clear benefit that I can see. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> An implementor may choose to send multiple SETs, or send a si= ngle SET with multiple events, so a receiver will need to support both. I pr= efer we pick one way and minimize the code paths, and we will need to suppor= t correlating across multiple SETs, so that seems the best mechanism. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> Let me know if there is something I missed in my logic. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> /Dick >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer wrote: >>>>>>>>>>>>>>> In that case, let's add text to that effect, e.g. we could a= dd to the definition of the "events" claim: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Profiling specifications SHOULD define the allowed event sta= tements, and MAY restrict their number. For example, some profiles may requi= re this claim to contain only a single event statement. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Yaron >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 24/10/17 22:10, Mike Jones wrote: >>>>>>>>>>>>>>>> I agree with much of Phil=E2=80=99s rationale here. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> It=E2=80=99s fine for some profiles to say that the =E2=80=9C= events=E2=80=9D set must be a singleton. That doesn=E2=80=99t have to be tr= ue for all events. I think things are fine as-is. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> = -- Mike >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Beh= alf Of *Phil Hunt >>>>>>>>>>>>>>>> *Sent:* Monday, October 23, 2017 8:47 PM >>>>>>>>>>>>>>>> *To:* Richard Backman, Annabelle >>>>>>>>>>>>>>>> *Cc:* ID Events Mailing List >>>>>>>>>>>>>>>> *Subject:* Re: [Id-event] Use cases for multiple events per= SET? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Annabelle, >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I have a number of concerns with this proposal. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Profiling Independence / Keeping Event Payloads Independent= >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Indicating that extensions should be handled by profiles le= ads to more inter-operability issues and more importantly intrudes on the Ev= ent payload space by suggesting a sub-schema creates potential limitations a= nd conflicts that may add to complexity later on. The current format allows a= parser to discover and unload one or more JSON payloads which can each have= independent structure. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> General extensions >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The proposal also rules out general purpose extensions not r= elated to any specific event. Given the emergence of items like GPRD, I woul= d not want to block the ability to add meta-data or other general purpose it= ems. We can also anticipate some delivery scenarios where additional data mi= ght be required. Even though there is no current planned use, I see no good r= eason to rule this out. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Multiple Events =46rom Different Families (vs. Multiple Eve= nts from a single family like RISC) >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> In our RISC session we discussed expressing multiple distin= ct RISC events in one SET. The discussion was that only one RISC event at a t= ime. We did not discuss other event profiles. I don=E2=80=99t see a reason t= o rule out multi-events from different families at the SET level. Each profi= le is expressing slightly different things about the same event. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I can forsee some cases where it is not clear which is the p= rimary and which is the extension. There may not be a clear winner. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> A couple of examples (these are necessarily real=E2=80=A6ju= st possibilities): >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> * It is probably useful to be able to express simlar/overla= pping events from different SET profiles in one SET. For example a Backchan= nel Logout & a RISC session cancel event. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> * SCIM may want to represent a single transaction as causin= g multiple state changes in an event (e.g. a password change causes multiple= effects). Having to chase down multiple events and correlate by =E2=80=9Ctx= n=E2=80=9D would be challenging in a multi-threaded/multi-node delivery syst= em. The SCIM list has not discussed this, but I would not want to block th= is capability. IOW - Just because RISC does not want to express multiple ev= ents does not make this true for other profiles. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> * We may wish to indicate a SCIM Password Reset was perform= ed and a Logout/session cancellation is expressed at the same time. The eve= nts are related but express different data. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Avoiding Confusion =46rom Similar Events Originating from t= he Same Transaction >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> If events are sent separately, then more tracking of state (= e.g. by txn) would be required to ensure similar events are not mistaken or h= andled as repeats. While txn provides useful audit analysis capability, I=E2= =80=99m not sure it can be used in live or near-real time systems given dist= ributed multi-node, multi-threading architectures. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Previous Discussion >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I note that I originally raised having an attribute to desi= gnate primary event attribute to alleviate your concern, but this was not ac= cepted. See: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> * https://www.ietf.org/mail-archive/web/id-event/current/ms= g00406.html >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> * https://www.ietf.org/mail-archive/web/id-event/current/ms= g00140.html >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The consensus, at least as I interpreted it is up to the re= ceiver to figure this out based on the definitions it has for each event URI= and the profiles they represent. IOW - RISC is free to limit that only one R= ISC event be expressed at a time. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> @independentid >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> www.independentid.com >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle= >>>>>>>>>>>>>>>> > wrot= e: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The current draft of the SET spec allows for expressing= multiple >>>>>>>>>>>>>>>> events within the same token, which introduces addition= al complexity >>>>>>>>>>>>>>>> and room for ambiguous semantics. We=E2=80=99ve discuss= ed this in the OIDF >>>>>>>>>>>>>>>> RISC working group and the current consensus there is t= hat RISC will >>>>>>>>>>>>>>>> require that RISC events must be the only event in the S= ET, having >>>>>>>>>>>>>>>> identified ways to clearly and easily support the handf= ul of use >>>>>>>>>>>>>>>> cases for multiple events per token that people have ra= ised. With >>>>>>>>>>>>>>>> that context in mind, I propose striking the definition= of the >>>>>>>>>>>>>>>> =E2=80=9Cevents=E2=80=9D claim from the Security Event T= oken spec, and replacing it >>>>>>>>>>>>>>>> with the following definition for an =E2=80=9Cevent=E2=80= =9D claim (singular): >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> event >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> A JSON object containing an "event_type" member whose v= alue is a URI >>>>>>>>>>>>>>>> representing a type of event defined in a Profiling Spe= cification. >>>>>>>>>>>>>>>> The object MAY otherwise be empty, or MAY contain addit= ional members >>>>>>>>>>>>>>>> as described by the Profiling Specification. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Here is the example SET from section 2.3, rewritten wit= h this change >>>>>>>>>>>>>>>> mind: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> "jti": "4d3559ec67504aaba65d40b0363faad8", >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> "iat": 1458496404, >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> "iss": "https://scim.example.com ", >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> "aud": [ >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> "https://scim.example.com/Feeds/98d52461fa5bbc8795= 93b7754", >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> "https://scim.example.com/Feeds/5d7604516b1d08641d= 7676ee7" >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> ], >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> "event": { >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> "event_type": "urn:ietf:params:scim:event:create",= >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> "ref": "https://scim.example.com/Users/44f6142df96= bd6ab61e7521d9", >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> "attributes": ["id", "name", "userName", "password= ", "emails"] >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Does anyone in the working group have use cases for SET= s that cannot >>>>>>>>>>>>>>>> be met by this proposed text? Within RISC, we identifie= d three use >>>>>>>>>>>>>>>> cases, with solutions outlined below: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> ** >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> *Extensions* >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Event extension mechanisms can be defined internal to t= he event >>>>>>>>>>>>>>>> object. A simple approach would be to define an =E2=80= =9Cextensions=E2=80=9D member >>>>>>>>>>>>>>>> that is a list of event objects (or set resembling the =E2= =80=9Cevents=E2=80=9D >>>>>>>>>>>>>>>> claim as defined in the current spec). This has the adv= antage of >>>>>>>>>>>>>>>> making it clear in the data structure that there is a s= ingle primary >>>>>>>>>>>>>>>> event, with zero or more extensions. There is no room f= or confusion >>>>>>>>>>>>>>>> over which event is primary, or if there is a primary e= vent at all. >>>>>>>>>>>>>>>> I would be fine with adding something like this to my p= roposed text, >>>>>>>>>>>>>>>> if there is consensus that it is broadly useful. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> *Aliases* >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> This use case was brought up in the context of migratin= g clients >>>>>>>>>>>>>>>> from draft event names to standardized event names. In t= his case, >>>>>>>>>>>>>>>> the event transmitter can transmit two tokens for the l= ogical event, >>>>>>>>>>>>>>>> one using the old name and another using the new name. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> *Related Events* >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The SET spec defines the txn claim as a means of correl= ating >>>>>>>>>>>>>>>> independent tokens that relate to the same logical even= t. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Amazon =E2=80=93 Identity Services >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8= PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D= s5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I= 58ZFd4eEZfgyoIY&e=3D >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I= am working on! >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ie= tf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv= 7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DYBCGlK= 9mjjhcFsj-2tDkn31Auxuruib9KATkRlQG1iw&s=3DWrMuQRwLV802iMQ4wYB1f2rFUGu4zbhcW0= 01fK02EXs&e=3D >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet= f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7= qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DU-a5HBN= D0HaTX4anNZfzX7pDsfK5f0h9mZ9CZkkGiec&s=3DrvdrtI7rYNRAnqZDltCwBAZVHKp-MJ20ui2= nm46QSz0&e=3D >>>>>>>>>>>>=20 >>>>>>>>>>>> =20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> -- >>>>>>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I a= m working on! >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Id-event mailing list >>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.= org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qI= rMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DiyVnrZmr9= _uGCQ6MD0zF2ymRQS6lK67yF_8u8_qSC_w&s=3DOe0qfLEX83vtXM7Wl2cYBe-Gg1DVPjhXjVJkf= hVRzwc&e=3D >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =20 >>>>>>>>> -- >>>>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am w= orking on! >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> -- >>>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am w= orking on! >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> =20 >>>>>>> --=20 >>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am wo= rking on! >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB= 65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZ= ktcmagv5Ea21QEip4HXpEVKRa0qhlo&s=3DgdNrs7UDAttpabjM5ndOXwWKmZuKaXEbT5wu9rcOR= V0&e=3D >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI= _JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DWgSxaGY2szLNY2pvZLI= U-OmBFEkwrzR3P4pC1N0D-t8&s=3DDyaPmvYSTL3a3Yicb4AoEgJGAaNNxz8jsrgcbZaOsdc&e=3D= --Apple-Mail-34D4AE84-4988-483D-8237-1FF0FCD453BD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    The two control plane proposals don't a= ctually support composite events. They only indicate a primary event. The tx= r is free to attach composite extensions as it thinks needed. 

    We may s= till have to address that. 

    Phil

    On Nov 1, 2017, a= t 3:08 PM, Marius Scurtescu <msc= urtescu@google.com> wrote:

    On W= ed, Nov 1, 2017 at 3:00 PM, William Denniss <wdenniss@goo= gle.com> wrote:
    The receiver probably knows which version they want, but does the sender= ? Using the email analogy, you may have configured your email client to acce= pt plain text only. Fortunately, my client sends both =E2=80=93 not knowing w= hat you prefer =E2=80=93 and you are able to view my message.

    Two solutions:
    - since receiver knows what= version they want they are going to only consume that and ignore the other<= /div>
    - there is a proposal underway so that receivers can tell the send= er exactly what they want, no events dropped on the floor



    I think it would help if we broke this problem down into two parts. 1= / Are multi-format SETs desirable? That's been the design since the earliest= version. 2/ What is the best representation of the SET based on what we dec= ide for #1.

    Yes, and #1 above is= being challenged.

     

    My understanding was that the= "events" plural (related to #2, the best representation of a SET) was in fact a concern, as people may skip the text and look directly at t= he JSON syntax, then jump to conclusions.
    On Wed, Nov 1, 2017 at 2:54 PM, Marius Scurtesc= u <mscurtescu@google.com> wrote:
    On Wed, Nov 1, 2017 at 2:46 PM, William Denniss <wdenniss@googl= e.com> wrote:
    Perhaps I can try and explain the original intent of the current design. T= he goal was always that a SET represents a single logical event. However mul= tiple systems may have different representations of the event =E2=80=93 the e= xample given originally was one formatted for RISC, and one for SCIM.
    A good analogy is email. You send a single logical email, which= may have two representations, HTML and plain text. Systems can consume the v= ersion that they understand and ignore the one they don't.

    Yes, and I think this is well understood.

     

    I'm starting to regret the plural in "events", it was p= luralized due to it being an array, not because it represented multiple logi= cal events.

    I don't think this i= s the main concern or cause for confusion.

     

    Annab= elle, I understand your concerns regarding confusion of the semantics betwee= n the JSON syntax and the specification language. Are there other ways to re= solve that without removing the ability for multiple representations of the s= ame event?

    The argument is that m= ultiple representations can be sent as distinct SETs, if really needed. In p= ractice this will happen quite rare though. Events are created for a specifi= c receiver, the receiver either wants the SCIM or the RISC flavor, and they s= hould be able to specify that in configuration (there is a proposal how to c= apture that).

    Do we have a compelling use case wher= e a receiver must receive multiple variants all at once?

     
    <= br>
    On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtes= cu <m= scurtescu@google.com> wrote:
    =
    On We= d, Nov 1, 2017 at 12:45 PM, Phil Hunt <phil.hunt@oracle.com&g= t; wrote:
    You can=E2=80=99t really have multiple events (at least of the same= type).  The current spec can only have one instance of a URI (afaik). &= nbsp;

    Note that the spec normatively does not support mul= tiple event SETS.  It currently states:
    <= pre class=3D"m_-1329852460247035742m_6337440896153279834m_-31514459584510293= 18m_7476346946956833004m_5683402937781561080newpage" style=3D"font-size:13.3= 33333015441895px;margin-top:0px;margin-bottom:0px">events The semantics of this claim is to define a set of event statements that each MAY add additional claims to fully describe a single logical event that has occurred (e.g. a state change to a subject). Multiple event statements of the same type SHALL NOT be accepted. The "events" claim SHOULD NOT be used to express multiple logical events.

    The spe= c has *always* supported requirements (as stated in the spec) for multiple s= eparate profile statements (from one or more profile familities) needing to b= e sent as a single message.  It would be INSECURE to force multiple SET= s because the current delivery mechanism only allows one SET to be delivered= at a time. There is no way to assure that a single receiver gets all of the= SETs it needs in a multi-threaded, multi-node environment at scale.  A= ssembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a common state dat= abase is NOT simple nor cost effective.
    =

    I totally agree that it is difficult for receivers to re= ceive separate events, in no particular order and correlate based on "txn". B= ut, receivers have to solve this issue regardless of "events" or "event", so= it is unrelated to this proposal.

     

    If we accommodate this in the proposed form, we end up with a= complex, deeply nested JSON structure with the possibility of namespace con= flicts.

    IMO The proposal does not simplify, it comp= licating and limiting.  

    The current spec has v= ery clean JSON and avoids namespace conflicts between profiles. I think we s= hould stay on track with the current draft and observe the normative text if= not make it stronger in regards to multi-events (understood that Mike may d= isagree).

    Phil
    <= div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-in= dent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:b= reak-word">

    Oracle Corporation, Identity Cloud Services Architect<= /div>
    @independentid
    phil.hunt@oracle.com

    On Nov 1, 2017, at 12:18 PM, Richard= Backman, Annabelle <richanna@amazon.com> wrote:

    Unles= s the profile guarantees that such related events will always be included in= the same SET, then the receiver has to correlate across SETs anyway, and mu= ltiple events per SET is just giving the receiver another scenario that they= have to support.
     
    I=E2=80=99ve already provided several other reasons why we should not s= upport multiple tokens per SET that no one has addressed. Here they are agai= n:
    1. Multiple event support results in a more complex structure for the sin= gle event use case, which I think we all agree is the majority use case.<= /u>
    2. Multiple-event SETs have ambiguous semantics. The presence of two event= s A and B in the same SET could mean any of:
      1. A and B are related to the same lo= gical event (i.e. the same thing as if they were from different SETs that ha= ve a common txn).
      2. A is an extension of B.
      3. B is an extension o= f A.
      4. A is an alias for B, or vice-versa.
      5. A and B are not act= ually related to one another in any way, and the transmitter bundled them to= gether because they were going to the same receiver.
      =
    3. Top-l= evel claim semantics become harder to define, as different profiles may want= to use the same claims in different ways.
    4. Event authenticity cannot= be verified without having the entire SET. This forces receivers to expose d= ownstream systems to more information necessary, if those systems need to be= able to verify authenticity.
     <= u>
    -- 
    Annabelle Richard Backma= n
    Amazon =E2=80=93 Identity Services=
     
     =
    From: = Mike Jones <Michael.Jones@microsoft.com>
    Date: Wednesd= ay, November 1, 2017 at 11:21 AM
    To: Dick Hardt <dick.hardt@gmail.com= >
    Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, "Richard= Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
    Subject: RE: [I= d-event] Use cases for multiple events per SET?
     
    I completely agree on moving complexity to the issuer over= the recipient.  In my view, it=E2=80=99s more complex for recipients t= o have to correlate and process a sequence of multiple SETs providing inform= ation about the same logical event, and validate N signatures, than to recei= ve one SET with all the aspects of the logical event as =E2=80=9Cevents=E2=80= =9D fields, with no correlation over time then required.
     
        =             &nbs= p;            &n= bsp;           &= nbsp;            = ; -- Mike
    From: Dick Hardt [= mailto:dic= k.hardt@gmail.com] 
    Sent: Wednesday, November 1, 201= 7 9:39 AM
    To: Mike Jones <Michael.Jones@microsoft.com>=
    Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman,= Annabelle <richanna@amazon.com>; ID Events Mailing List <id-event@ietf.org>; Ph= il Hunt (IDM) <phil.hunt@oracle.com>
    Subject: Re: [Id-event] U= se cases for multiple events per SET?
     <= /u>
    Your comments highlight a couple of point= s:
     
    1) The example is how to have a predefined extension point for e= xtensions of a specific event, it is not how to add another event. Myself, I= think this is overly complicated. Events should be comparatively static, an= d as with many other JSON formats, the receiver should ignore properties it d= oes not understand, which let's new properties be introduced as extensions. T= here should not be any conflict as extensions should only be done by the pro= file that created the event format to start off with.
     
    2) Having an l= value be a URI is much harder to code against. I'm not sure why Marius had t= hat in his example. Per the event, the type of the event is well defined wit= h 
     
     <= /u>
    3) This thread is about reasons for multip= le events to be contained in one set. Your mention of an issuer not wanting t= o sign separate events as a reason to allow multiple events. I think we have= decided that given a preference, we will push effort to the transmitter ove= r the receiver as in many use cases there are many more receivers. Given tha= t, it is more complex for a receiver to have different ways of managing the r= eceipt of multiple events as not all issuers will bundle the events, so it i= s simpler to have only one event per SET. Including the separate events with= a URI as an lvalue is challenging to implement, speaking from experience.
     
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif"> 
     
     
    =  
     
     
     <= u>
     
     =
     
    <= div>
     
    On Tue, Oct 31, 2017 at= 11:05 PM, Mike Jones <Mich= ael.Jones@microsoft.com> wrote:
    Marius=E2=80=99 pr= oposed syntax, pasted in below, has exactly this characteristic.  The w= ay I see it, his proposal essentially has a primary passwordReset event and a= secondary passwordResetExt data structure, which could have been simply ano= ther event value in the current draft.
     
    This breaking change makes the data structure= s more complicated - not less.  And it makes things that used to be pos= sible impossible, reducing flexibility to those who would use the spec.
     
    These see= m like bad tradeoffs to me.
     
    {
    &= nbsp; "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
      "iat": 1458496025,
      "aud": [
       "event_type": "<= a href=3D"https://example.com/scim/event/passwordResetExt" style=3D"color:pu= rple;text-decoration:underline" class=3D"m_-1329852460247035742m_63374408961= 53279834m_-3151445958451029318m_7476346946956833004cremed m_-132985246024703= 5742m_6337440896153279834cremed cremed" target=3D"_blank">https://example.co= m/scim/event/passwordResetExt",
    =    = ;"event": {  
            &= nbsp;"id":"44f6142df96bd6ab61e7521d9",
      &n= bsp;      "extensions": {
    =    = ;        "https://example.com/scim/event/passwordResetExt=E2=80=9D= : {
                 "= resetAttempts":5,
              &= nbsp;}
             }<= /u>
           }
    }=
     
    In particular,= it makes it impossible to sign multiple related events sharing a common cla= ims schema with a single signature by the issuer.  It forces the issuer= to do the extra work of signing each of the related events (or facets of th= e same logical event) individually and forces the recipients to do the extra= work of checking all those unnecessary signatures.
     
    Not every profile will ever h= ave multiple keys in the =E2=80=9Cevents=E2=80=9D set but there=E2=80=99s ab= solutely no reason to preclude it.
     
            =             &nbs= p;           &nb= sp;            &= nbsp;         -- Mike<= u>
    From: Id-event [mai= lto:id-event-bounces@ietf.o= rg]=  On Behalf Of Dick Hardt
    Sent: Tuesday,= October 31, 2017 9:52 PM
    To: Mike Jones <Michael.Jones@microsoft.com>
    Cc:<= /b>&nbs= p;Yaron Sheffer <yaronf.ie= tf@gmail.com>; Richard Backman, Annabelle <richanna@amazon.com>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt (IDM) &l= t;phil.hunt@oracle.com>=

    Subject: Re: [Id-event] Use c= ases for multiple events per SET?
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif"> 
    Please direct me to a propos= al that has a "primary" and "secondary" events. I agree that is undesirable.= I would also encourage to engage in the discussions so that we can drive cl= arity and simplicity.
     <= /div>
    I think the proposal is that there is one event per= SET.
     
    I think having more than one event per SET adds complexity as= a receiver must deal with receiving correlated events in one SET as well as= correlated events in the same SET.
    &= nbsp;
    /Dick
    =
     
    On Tue, Oct 31, 2= 017 at 9:42 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
    I hear you o= n the fact that different people have joined the effort at different times.&= nbsp; That=E2=80=99s a normal process as an effort builds momentum.  I g= et that not everyone was there when previous consensus calls were taken.
     
    I should= note that I have specific technical objections to the specific proposed cha= nges being discussed as well.  Currently all events in the set have the= same syntax.  The proposals, as I understand them, revert us to a stat= e where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and =E2=80=9Csecondary=E2= =80=9D events, with different syntax for the two classes.  That=E2=80=99= s needlessly more complicated, adding no actual value.<= /div>
     =
        &n= bsp;            =             &nbs= p;           &nb= sp;            &= nbsp;         -- Mike=
     
    From: Dick Hardt [mailto:dick.hardt@gmail.com] 
    Sent: Tuesday, October 31, 2017 9:37 PM
    To: Mike Jones <Michael.Jones@microsoft.com>= ;
    Cc: Phil Hunt (IDM) <phil.hunt@oracle.com>; Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabelle &l= t;richanna@amazon.com>; ID Even= ts Mailing List <id-event@ietf.org>
    I do think we have been making good progress since the last IETF= meeting, and I am hopeful we can keep up this momentum and finalize all the= documents in a timely manner.
    It=E2=80=99s hard for me to even express my l= evel of frustration with the recent attempts to once again redesign the SecE= vent Token spec.  We=E2=80=99ve been at this for multiple years because= people keep trying to revisit decisions that were long ago made by consensu= s.  It=E2=80=99s been stable for over a year and the majority of WGLC r= espondents said some variant of =E2=80=9CWorks for me =E2=80=93 ship it!=E2=80= =9D
    &n= bsp;
    T= here=E2=80=99s not sufficient justification to try to undo consensus positio= ns that have been debated and affirmed over and over.  Countenancing wh= olesale changes at this late date is counterproductive in the extreme!
     
    It=E2=80=99= s far better than good enough as-is.  In my experience, if we start red= esigning it, it will result in another year=E2=80=99s delay.  It does s= omething simple and useful.  Please, let=E2=80=99s just ship it, so peo= ple can rely on it.
     
              &n= bsp;            =             = ;            &nb= sp;       -- Mike
     =
    From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 
    Sent: Monday, Octobe= r 30, 2017 2:42 PM
    To: Dick Hardt <dick.hardt@gmail.com>
    Cc: Yaron Sheffe= r <yaronf.ietf@gmail.com>;= Richard Backman, Annabelle <richan= na@amazon.com>; Mike Jones <Michael.Jones@microsoft.com>; ID Events Mailing List <id-event@ietf.org>

    Subject: Re: [Id-event] Use cases for mu= ltiple events per SET?
    =
     
    Inline...

    Phil


    On Oct 30, 2017, at 2= :22 PM, Dick Hardt <dick.hardt@gma= il.com> wrote:

    Hi Phil=
     
    Correc= t me if I am misunderstanding, but there is a RISC profile event 
     =

    "http://schemas.openid.net/secev=
ent/risc/event-type/account-credential-change-required=E2=80=9D
     
    and an SCIM profile event
     =
    I'm suggesting that t= wo different events would be sent. Embedding one in the other does not make s= ense.
    <ph>I= t is a hypothetical example. Just because you disagree on this does not mean= others are not valid. 
     <= u>
    I just picked overlapping proposals that hav= e different meaning (but not the same) to illustrate the difference from iss= uing a single set with different events. 
     

    As I hav= e stated this is very different from asserting multiple distinct events in o= ne SET. 

     
    Also, I think it is simpler to have event_type be at the s= ame level as event
     

    <ph>may b= e. I was working from Annabelle's proposed format. 

     
    {
      "jti": "3d0= c3cf797584bd193bd0fb1bd4e7d30",
      "iat": 1458496= 025,
    <= span style=3D"font-family:'Courier New',serif">  "aud": [=
       ],
    &nbs= p;  "event_type": "https://example.com/scim/event/passwordResetExt",<= /u>
       "event": {  
    =
        &= nbsp;    "id":"44f6142df96bd6ab61e7521d9",
    =          "resetAttempts":5
     =      }
    }
    <= div>
     
    {
      "jti": "3d0c3cf797= 584bd193bd0fb1bd4e7d30",
    =   "iat": 1458496025,
      "aud": [=
       ],
      &nbs= p;"event": {
           =E2=80=9Csub=E2=80= =9D:=E2=80=9D7375626A656374=E2=80=9D,
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans= -serif">     =  =E2=80=9Ciss=E2=80=9D:"https://id= p.example.com/"       
     =      }
    }
    <= /div>
     
     
     
     
     
    On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
    Annabelle/Dick,=
     
    Thanks for the comments. I think we need to examine the consequences of t= he proposal in JSON.
     <= /u>
    As I stated, what causes most of the issue is the pr= oposed extension mechanism in the payload (possibly using events in a recurs= ive way). Does it follow the old format or the new?
    =
     
    Let=E2=80=99s  c= onsider a use case where we have an identity management system that uses SCI= M, but the SCIM system is also the underlying data store for Connect.  A= Password reset might generate the following event which has an extension (c= onveying reset count) AND overlapping statement from RISC.  BOTH of whi= ch might be important to a similar receiver using SCIM and OIDC.  
     
    The 03 spec currently would allow:
     
    {
      "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",<=
/u>
      "iat": 1458496025,
    &nb=
sp; "iss": "https://scim.example.com",
      "aud": [
    https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754<=
/a>",
        "https://jhub.example.com/Feed=
s/5d7604516b1d08641d7676ee7"
     &nb=
sp; ],
       "events": {
         "urn:ietf:params:scim:event:pass=
wordReset":
          =
; { "id":"44f6142df96bd6ab61e7521d9"},
    &nb=
sp;    "https://example.com/scim/event/passwordResetExt":
           { "resetAttempts":5},=

      &nb=
sp;  "http://schemas.openi=
d.net/secevent/risc/event-type/\
           acco=
unt-credential-change-required": {
    =
       &nb=
sp; =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,=

        &=
nbsp;    =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=
"
    &nb=
sp;      }
      }
    }
     
    In=
 the above - each payload is a =E2=80=98peer' and issued without preference b=
y the transmitter. The receiver can assign priority in its own context if th=
at matters.
     
    =
The new proposal:
     <=
u>
    {
      "jti": "3=
d0c3cf797584bd193bd0fb1bd4e7d30",
      "=
iat": 1458496025,
      "iss": "https://scim.example.com",
      "aud": [
        "https://jhub=
.example.com/Feeds/98d52461fa5bbc879593b7754",
    <=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courier New=
',serif">    "https://jhub.example.com/Feeds/5d7604516b1d08641d7=
676ee7"
       ],
    = 
       "event": {
      &=
nbsp;  =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event:pa=
sswordReset=E2=80=9D,
         "=
id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
         =E2=80=9Cevents=E2=80=9D:{
         ->note =E2=80=A6is this the old or ne=
w structure? <-
        &nbs=
p;  "https://e=
xample.com/scim/event/passwordResetExt":
             { "resetAttempts":5},=

       =
    "http://sche=
mas.openid.net/secevent/risc/event-type/\
         &n=
bsp;   account-credential-change-required": {
        =
     =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=
=9D,
    &nbs=
p;        =E2=80=9Ciss=E2=80=9D:"<=
span style=3D"font-size:13.5pt">https://i=
dp.example.com/"
           }=

         }
      =
; }    
    }
     
    In the above, su=
b-events or extensions have a different format. The same complaint about the=
 original stands.
     
    *OR* (if t=
he receiver cares about RISC more).  Note that this leads to a triple n=
ested structure.
     =

    {
      "jti": "3d0c3cf797584b=
d193bd0fb1bd4e7d30",
      "iat": 1458496=
025,
      "iss": "https://scim.example.com",
      "=
aud": [
        "https://jhub.example.com/Fe=
eds/98d52461fa5bbc879593b7754",
     =
   "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"<=
/u>
       ],
     =
;  "event": {
         =E2=
=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/secevent/risc/ev=
ent-type/\
                 acc=
ount-credential-change-required=E2=
=80=9D,
          =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A65637=
4=E2=80=9D,
          =E2=80=9Ciss=E2=80=9D:"https://idp.ex=
ample.com/=E2=80=9C,
          =E2=80=9Cevents=E2=80=9D=
:{
     =
       "urn:ietf:params:scim:event:passwo=
rdReset":
            { 
              "id":=E2=80=
=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
    &nb=
sp;         =E2=80=9Cevents=E2=80=9D=
:{
           &n=
bsp;     "https://example.com/scim/event/passwordResetExt":
            &nb=
sp;      { "resetAttempts":5},  
              }      
     &=
nbsp;      }
       }
    }
     
    In the above, the extension is pla=
ced inside the event it extends. It follows the old format (or should it fol=
low the new?)
    *OR* Following the top layer pattern of s=
ingular event  Note that this leads to a triple nested structure.
     
    {<=
/u>
      "jti": "3d0c3cf797584bd193bd0fb1bd4e7d=
30",
      "iat": 1458496025,
      "iss": "https://sci=
m.example.com",
      "aud": [
        "https://jhub.example.com/Feeds/98d52461fa=
5bbc879593b7754",
        "https://jhub.=
example.com/Feeds/5d7604516b1d08641d7676ee7"
       ],
       "event": {<=
u>
         =E2=80=9Cevent_type=E2=
=80=9D:"http://schemas.openid.net/secevent/risc/event-type/\<=
/span>
            &n=
bsp;    account-credential-change-required=E2=80=9D,
          =E2=80=9Csub=E2=80=9D:=E2=80=
=9D7375626A656374=E2=80=9D,
      =
    =E2=80=9Ciss=E2=80=9D:"https://idp.example.com/=E2=80=
=9C,
    =
      =E2=80=9Cevent=E2=80=9D:{
        &nbs=
p;   =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:scim:event=
:passwordReset=E2=80=9D,
            "id":=E2=80=
=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
    &nb=
sp;       =E2=80=9Cevent=E2=80=9D:{<=
/u>
              =E2=
=80=9Cevent_type=E2=80=9D:"https://example.com/scim/event/passwordResetExt=E2=80=
=9D,
           =
   "resetAttempts":5 
           &nbs=
p;}
          } =
;    
       }
    }
     
    This format fo=
llows the proposed singular event format recursively and is 3 layers deep. N=
ote that the parser has to continue to search the document for things that a=
ren=E2=80=99t there as it has to stop when no =E2=80=9Cevent=E2=80=9D attrib=
ute is found rather than iterate over an array.
     
    Phil

    Oracl=
e Corporation, Identity Cloud Services Architect
    @independentid
    www.independentid.com
    p=
hil.hunt@oracle.com
     
    On Oct 30, 2017, at 8:57 AM, Richard Backman, A=
nnabelle <richanna@amazon.com&g=
t; wrote:
     
    =

    Replies inline.
     
    <=
div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans=
-serif;background-color:white">-- 
    Annabelle Richard Backman
    Identity Services
    <=
/div>
     
     
    From: Phil Hunt <phil.hunt@oracle.com>
    Date: Sunday, October 29, 2017 at 5:25 PM
    To: Dick Hardt=
 <dic=
k.hardt@gmail.com>
    Cc: Yaron Sheffer <=
yaronf.=
ietf@gmail.com>, Mike Jones <Michael.Jones@microsoft.com>, "Richard Backman, Annabelle" <richanna@amazon.com>, ID E=
vents Mailing List <id-event@ietf.org>
    Subject: R=
e: [Id-event] Use cases for multiple events per SET?
     
    I hope this ans=
wers your question.
     
    My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a=
 reason why not. The question should be, what is the justification to make =E2=
=80=9Cevents=E2=80=9D singular?
    [richanna]The singul=
ar =E2=80=9Cevent=E2=80=9D claim has clearer semantics and is easier to proc=
ess. We should opt for easier solutions unless there are use cases that requ=
ire more complexity.[/richanna]
    <=
div>
     
    There are many reasons for multiple e=
vents in a SET.  Some are good, some not so good. Some of the reasons..=
.
    &=
nbsp;
    1.  Multiple event payloads expressing statements about largely the *=
same*thing. For example, SCIM password reset AND RISC password reset.  A=
 RISC Event and an OpenBanking Event. Is one a complement to the other? =
; Do they overlap or are they distinct?  
    [rich=
anna]Copy/pasted from my earlier email:
    Why i=
s it necessary or appropriate to include these events in the same SET? They a=
re likely being generated by different systems at different times on the tra=
nsmitter=E2=80=99s side, consumed by different systems on the receiver=E2=80=
=99s side, and possibly being transmitted over different event streams. I kn=
ow the latter would be the case for us, as a receiver. Even if it=E2=80=99s n=
ot, is it burdensome to send these events separately? What value is gained i=
n combining them?
     =

    Additionally, since the signature is over the SET and not the eve=
nt objects, Receivers independently route separate events from a single toke=
n without either losing the ability to verify the authenticity of the event o=
r sharing all information in the SET with every system handling any event in=
 the token.[/richanna]
     

    2.&n= bsp; Multiple events payloads expressing different statements about the same= transaction - RISC Password Reset and RISC Session Cancel
    [richanna]Same as above[/richanna]<= /u>

    3.  A new p= rofile defines new event attributes to be added on to an existing event type= (a pure extension) 
    [richanna= ]I have suggested a way to support extensions within an event body, multiple= times now. If you see problems with it, please point them out.[/richanna]
     
    I think it is quite valid to allow 1 and 3.  2 could be limited b= y specific profiles like RISC if they want.
    <= div>
     
    I am not in agreement that maki= ng event singular simplifies anything. For one is makes extensions complex (= another nested JSON structure) and potentially conflicting. 
    [richanna]
    Way= s that multiple-event SETs are more complicated:
    <= /div>
    1. It results in a more comp= lex structure for the single event use case, which I think we all agree is t= he majority use case.
    2. Multiple-event SETs have ambiguous semantics.= The presence of two events A and B in the same SET could mean any of:
    1. They are related to the same logic= al event (i.e. the same thing as if they were from different SETs that have a= common txn).
    2. A is an extension of B.
    3. B is an extension of A= .
    4. They are aliases for one another.
    5. They are not actually r= elated to one another in any way.
    1. Claim semantics become harder to define, as d= ifferent profiles may want to use the same claims in different ways.<= u>
     
    If the W= G wants to block 1 and 2 above, then I believe we have to establish an event= registry to ensure new Event profiles do not overlap to eliminate the need t= o express multiple events.
    [richanna]I=E2= =80=99m not sure what you mean by this. Are you referring to event names? Th= ose are already defined by the spec to be URIs.[/richanna]<= /u>
    =
    Phil
     
    Oracle Corporation, Identity Cloud Services Architect
    @independentid
     
    On Oct 29, 2017, at 4:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
     
    Phil:
     <= /span>
    In your e= xamples for having a plurality of events, you use the word "may", which lead= s me to question if a plurality of events is really required in SET.<= u>
     =
    You posit that it w= ill be difficult for a distributed system to correlate multiple SETs with th= e same "txn", but the distributed system will certainly need to correlate ev= ents on the same subject -- correlating events on the same "txn" on the same= subject seems fairly simple.
     
    =
    I think that a receiver will need to correlate multiple S= Ets on the same subject, so having multiple events in a SET is redundant, an= d adds complexity with no clear benefit that I can see.=
     
    An implementor may choose to se= nd multiple SETs, or send a single SET with multiple events, so a receiver w= ill need to support both. I prefer we pick one way and minimize the code pat= hs, and we will need to support correlating across multiple SETs, so that se= ems the best mechanism.
     
    Let me know if there is something I missed in my logic.<= u>
     =
    /Dick
     <= u>
     <= /u>
    On Sun, Oct 29, 2017 at 11:= 28 AM, Yaron Sheffer <<= span style=3D"color:purple">yaronf.ietf@gmail.com> wrote:
    In that case, let's add text to that effect, e.g. we could a= dd to the definition of the "events" claim:

    Profiling specifications S= HOULD define the allowed event statements, and MAY restrict their number. Fo= r example, some profiles may require this claim to contain only a single eve= nt statement.

    Thanks,
            Yaron=

    On 24/10/17 22:10, Mike Jones wrote:

    I agree with much of Phil=E2= =80=99s rationale here.

    It=E2=80=99s fine for some profiles to say th= at the =E2=80=9Cevents=E2=80=9D set must be a singleton.  That doesn=E2= =80=99t have to be true for all events.  I think things are fine as-is.=

               &n= bsp;            =             = ;            &nb= sp;           &n= bsp;    -- Mike

    *From:* Id-event [mailto:id-ev= ent-bounces@ietf.org] *On Behalf Of *Phil Hunt
    *Sent:* Mo= nday, October 23, 2017 8:47 PM
    *To:* Richard Backman, Annabelle <richanna@amazo= n.com>
    *Cc:* ID Events Mailing List <id-event@ietf.org&g= t;
    *Subject:* Re: [Id-event] Use cases for multiple events per SET?
    Annabelle,

    I have a number of concerns with this proposal.

    P= rofiling Independence / Keeping Event Payloads Independent

    Indicating= that extensions should be handled by profiles leads to more inter-operabili= ty issues and more importantly intrudes on the Event payload space by sugges= ting a sub-schema creates potential limitations and conflicts that may add t= o complexity later on. The current format allows a parser to discover and un= load one or more JSON payloads which can each have independent structure.
    General extensions

    The proposal also rules out general purpose e= xtensions not related to any specific event. Given the emergence of items li= ke GPRD, I would not want to block the ability to add meta-data or other gen= eral purpose items. We can also anticipate some delivery scenarios where add= itional data might be required. Even though there is no current planned use,= I see no good reason to rule this out.

    Multiple Events =46rom Differ= ent Families (vs. Multiple Events from a single family like RISC)

    In o= ur RISC session we discussed expressing multiple distinct RISC events in one= SET. The discussion was that only one RISC event at a time. We did not disc= uss other event profiles. I don=E2=80=99t see a reason to rule out multi-eve= nts from different families at the SET level. Each profile is expressing sli= ghtly different things about the same event.

    I can forsee some cases w= here it is not clear which is the primary and which is the extension.  T= here may not be a clear winner.

    A couple of examples (these are neces= sarily real=E2=80=A6just possibilities):

    * It is probably useful to b= e able to express simlar/overlapping events from different SET profiles in o= ne SET.  For example a Backchannel Logout & a RISC session cancel e= vent.

    * SCIM may want to represent a single transaction as causing mu= ltiple state changes in an event (e.g. a password change causes multiple eff= ects). Having to chase down multiple events and correlate by =E2=80=9Ctxn=E2= =80=9D would be challenging in a multi-threaded/multi-node delivery system.&= nbsp;  The SCIM list has not discussed this, but I would not want to bl= ock this capability.  IOW - Just because RISC does not want to express m= ultiple events does not make this true for other profiles.

    * We may w= ish to indicate a SCIM Password Reset was performed and a Logout/session can= cellation is expressed at the same time.  The events are related but ex= press different data.

    Avoiding Confusion =46rom Similar Events Origin= ating from the Same Transaction

    If events are sent separately, then m= ore tracking of state (e.g. by txn) would be required to ensure similar even= ts are not mistaken or handled as repeats. While txn provides useful audit a= nalysis capability, I=E2=80=99m not sure it can be used in live or near-real= time systems given distributed multi-node, multi-threading architectures.
    Previous Discussion

    I note that I originally raised having an a= ttribute to designate primary event attribute to alleviate your concern, but= this was not accepted. See:

    * https://www.iet= f.org/mail-archive/web/id-event/current/msg00406.html
    * https://www.ietf.org/mail-archive/web/id-= event/current/msg00140.html

    The consensus, at least a= s I interpreted it is up to the receiver to figure this out based on the def= initions it has for each event URI and the profiles they represent. IOW - RI= SC is free to limit that only one RISC event be expressed at a time.

    = Phil

    Oracle Corporation, Identity Cloud Services Architect

    @in= dependentid

    www.independe= ntid.com <http://www.independentid.com>

    phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>

      &= nbsp; On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle
      &nbs= p; <ri= channa@amazon.com <mailto:richanna@amazon.com    >> wrote:

        The current draft of the SET spec allo= ws for expressing multiple
        events within the same token, wh= ich introduces additional complexity
        and room for ambiguous= semantics. We=E2=80=99ve discussed this in the OIDF
        RISC w= orking group and the current consensus there is that RISC will
      &nb= sp; require that RISC events must be the only event in the SET, having
    &n= bsp;   identified ways to clearly and easily support the handful of use=
        cases for multiple events per token that people have raise= d. With
        that context in mind, I propose striking the defini= tion of the
        =E2=80=9Cevents=E2=80=9D claim from the Securit= y Event Token spec, and replacing it
        with the following def= inition for an =E2=80=9Cevent=E2=80=9D claim (singular):

       = ; event

        A JSON object containing an "event_type" member= whose value is a URI
        representing a type of event defined i= n a Profiling Specification.
        The object MAY otherwise be em= pty, or MAY contain additional members
        as described by the P= rofiling Specification.

        Here is the example SET from se= ction 2.3, rewritten with this change
        mind:

      &= nbsp; {

           "jti": "4d3559ec67504aa= ba65d40b0363faad8",

           "iat": 1458496404= ,

          "iss": "    https://scim.example.com <ht= tps://scim.example.com/>",

         &nb= sp; "aud": [

             "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",

             "    https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
           ],

           "event= ": {

             "event_type": "urn:ietf:p= arams:scim:event:create",

            = "ref": "https://scim.example.com/Users/44f6142df9= 6bd6ab61e7521d9",

             "= attributes": ["id", "name", "userName", "password", "emails"]

      &= nbsp;    }

        }

        Does anyone= in the working group have use cases for SETs that cannot
        b= e met by this proposed text? Within RISC, we identified three use
      &= nbsp; cases, with solutions outlined below:

        **

    &= nbsp;   *Extensions*

        Event extension mechanisms ca= n be defined internal to the event
        object. A simple approac= h would be to  define an =E2=80=9Cextensions=E2=80=9D member
      &= nbsp; that is a list of event objects (or set resembling the =E2=80=9Cevents= =E2=80=9D
        claim as defined in the current spec). This has t= he advantage of
        making it clear in the data structure that t= here is a single primary
        event, with zero or more extension= s. There is no room for confusion
        over which event is prima= ry, or if there is a primary event at all.
        I would be fine w= ith adding something like this to my proposed text,
        if ther= e is consensus that it is broadly useful.

        *Aliases*
    =
        This use case was brought up in the context of migrating c= lients
        from draft event names to standardized event names. I= n this case,
        the event transmitter can transmit two tokens f= or the logical event,
        one using the old name and another us= ing the new name.

        *Related Events*

       = The SET spec defines the txn claim as a means of correlating
      &nbs= p; independent tokens that relate to the same logical event.

      &= nbsp; -- 
        Annabelle Richard Backman

     = ;   Amazon =E2=80=93 Identity Services

        ___________= ____________________________________
        Id-event mailing l= ist
        Id-event@ietf.org <mailto:Id-event@ie= tf.org>
        https://urldefense.proofpoint.com= /v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&= ;d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&am= p;r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3Ds5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D



    ___________________= ____________________________
    Id-event mailing list
    Id-event@ietf.org<= /a>
    https= ://www.ietf.org/mailman/listinfo/id-event


    _____________________________= __________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.or= g/mailman/listinfo/id-event
    =


    <= /u>
     =
    -- 
    Subscribe= to the HARDTWARE= &= nbsp;mail list to learn about projects I am working on!=
     
    _________________________________= ______________
    Id-event mailing list    Id-event@ietf.o= rg
     


     
    --
    Subscribe to the HARDTWARE mail list to learn a= bout projects I am working on!


     <= u>
    --
    Subscribe to the HARDTWARE mail list to le= arn about projects I am working on!

    =
     
    --
    Subscribe to the <= a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__hardtware.co= m_&d=3DDwMGaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D= na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DsIGz8gur4wNqZktcmagv5Ea2= 1QEip4HXpEVKRa0qhlo&s=3DV9gyTTX9qujrC2VliwLPy0-KvxS9pYKJ_-kyDapwO8k&= e=3D" style=3D"color:purple;text-decoration:underline" class=3D"m_-132985246= 0247035742m_6337440896153279834m_-3151445958451029318m_7476346946956833004cr= emed m_-1329852460247035742m_6337440896153279834cremed cremed" target=3D"_bl= ank">HARDTWARE mail list to learn about projects I am working on!


     

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.= ietf.org/mailman/listinfo/id-event





    = --Apple-Mail-34D4AE84-4988-483D-8237-1FF0FCD453BD-- From nobody Wed Nov 1 15:52:56 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D6713FF17 for ; Wed, 1 Nov 2017 15:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.798 X-Spam-Level: X-Spam-Status: No, score=-11.798 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 jMbpzTRnGKHk for ; Wed, 1 Nov 2017 15:52:48 -0700 (PDT) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED72313FF09 for ; Wed, 1 Nov 2017 15:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1509576768; x=1541112768; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BYKpErDw1Ufc/YkfxsZfJCxy9QZBBpu7ooEkrZmeDkg=; b=lje6Hn5Ik+ytdxpBrNG5NUJ8k6YWowHqkHzwhrBu4g7/fVyZWcy8xAt+ WOjxqc7cWND9Hn1IKWQjYXLsfbpBtEYeYHq6TcmwZKFHmYfr+qG6K/8uI tCqDOx4Yh73Y879L+zKIosNbTB0Sd/Q9QYP7iU3glQvumnbN+gpK4XnAq c=; X-IronPort-AV: E=Sophos;i="5.44,331,1505779200"; d="scan'208,217";a="698129221" Received: from sea3-co-svc-lb6-vlan2.sea.amazon.com (HELO email-inbound-relay-2c-5f221cf9.us-west-2.amazon.com) ([10.47.22.34]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2017 22:52:42 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2c-5f221cf9.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id vA1MqgRL125997 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2017 22:52:42 GMT Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 1 Nov 2017 22:52:42 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 1 Nov 2017 22:52:41 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Wed, 1 Nov 2017 22:52:41 +0000 From: "Richard Backman, Annabelle" To: William Denniss , Marius Scurtescu CC: Yaron Sheffer , Mike Jones , Phil Hunt , "ID Events Mailing List" , Dick Hardt Thread-Topic: [Id-event] Use cases for multiple events per SET? Thread-Index: AQHTTGwev6cV0D/tE06azbqzz7my9aLyXLkAgAEBjXCAB9BnAIAAT1IAgAAUagCAAQQ9AIAANauAgAAlNACAAAV2gIABcZJQgACUvYCAAADCcIAAA1kAgAASxcCAALLVgIAAG18AgAARHoCAAAeDAIAAH3gAgAACjICAAAIzgIAAAb6AgAAOcoA= Date: Wed, 1 Nov 2017 22:52:41 +0000 Message-ID: <07169FA7-6542-4EBB-987F-5D39190B214A@amazon.com> References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.131] Content-Type: multipart/alternative; boundary="_000_07169FA765424EBB987F5D39190B214Aamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 22:52:54 -0000 --_000_07169FA765424EBB987F5D39190B214Aamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBhbmFsb2d5IGlzIGZ1bmRhbWVudGFsbHkgZmxhd2VkLiBXaXRoIGVtYWlsLCBib3RoIHRo ZSB0ZXh0IGFuZCBIVE1MIGJvZGllcyBhcmUgZGlmZmVyZW50IHJlcHJlc2VudGF0aW9ucyBvZiB0 aGUgZXhhY3Qgc2FtZSBtZXNzYWdlLCB3aXRoIHRoZSBleGFjdCBzYW1lIHNlbWFudGljcy4gQSBy ZWFkZXIgaXMgZ2VuZXJhbGx5IGFzc3VtZWQgdG8gaW50ZXJwcmV0IGFuZCByZWFjdCB0byBhIG1l c3NhZ2UgdGhlIHNhbWUgd2F5LCB3aGV0aGVyIHRoZXkgcmVhZCBpdCBpbiB0ZXh0IG9yIEhUTUwu IFRoaXMgaXMgbm90IHRoZSBjYXNlIGZvciB0aGUgZXZlbnRzIHdpdGhpbiBTRVRzLiBUaGUgT0lE QyBCYWNrY2hhbm5lbCBMb2dvdXQgZXZlbnQsIGEgU0NJTSBMb2dvdXQgZXZlbnQsIGFuZCBhIGh5 cG90aGV0aWNhbCBSSVNDIExvZ291dCBldmVudCBhbGwgY29udmV5IGRpZmZlcmVudCBpbmZvcm1h dGlvbiBhbmQgYXJlIHNlbnQgdW5kZXIgZGlmZmVyZW50IGNpcmN1bXN0YW5jZXMsIGFuZCBpdCBp cyBleHBlY3RlZCB0aGF0IHJlY2VpdmVycyBtYXkgcmVhY3QgZGlmZmVyZW50bHkgdG8gZWFjaCBl dmVudC4gVGhleSBtYXkgZXZlbiBiZSByZWNlaXZlZCBieSBkaWZmZXJlbnQgZW5kcG9pbnRzIOKA kyBzb21lIGdvaW5nIHRvIHRoZSByZWNlaXZlcuKAmXMgc2Vzc2lvbiBtYW5hZ2VtZW50IHN5c3Rl bSB3aGlsZSBvdGhlcnMgZ28gdG8gdGhlaXIgcmlzayBtYW5hZ2VtZW50IHN5c3RlbSAod2hpY2gg Y291bGQgZXZlbiBiZSBhIHRoaXJkIHBhcnR5KS4gU2luY2UgZWFjaCBldmVudCB0eXBlIGNvbnRh aW5zIGRpZmZlcmVudCBpbmZvcm1hdGlvbiwgaXQgbWF5IGV2ZW4gYmUgaW1wb3J0YW50IGZyb20g YSBkYXRhIGV4cG9zdXJlIHN0YW5kcG9pbnQgdG8gdGhlIHJlY2VpdmVyIHRoYXQgdGhlc2UgZXZl bnRzIG5vdCBhbGwgcGFzcyB0aHJvdWdoIHRoZSBzYW1lIHN5c3RlbXMgb24gdGhlaXIgc2lkZSwg b3IgZm9yIHRoZSByZWNlaXZlciB0byBvbmx5IHJlY2VpdmUgb25lIG9mIHRob3NlIHR5cGVzIG9m IGV2ZW50cywgYW5kIG5vdCB0aGUgb3RoZXIuIFRoaXMgaXMgdGhlIGNhc2UgZm9yIEFtYXpvbjsg d2Ugd2FudCBSSVNDIGV2ZW50cywgYW5kIG5vIG90aGVyczsgd2UgZG9u4oCZdCB3YW50IHRvIHJl Y2VpdmUgYW55IG1vcmUgaW5mb3JtYXRpb24gZnJvbSB0cmFuc21pdHRlcnMgdGhhbiBpcyBuZWNl c3NhcnkuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpJZGVudGl0eSBTZXJ2aWNl cw0KDQoNCkZyb206IElkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhh bGYgb2YgV2lsbGlhbSBEZW5uaXNzIDx3ZGVubmlzc0Bnb29nbGUuY29tPg0KRGF0ZTogV2VkbmVz ZGF5LCBOb3ZlbWJlciAxLCAyMDE3IGF0IDM6MDIgUE0NClRvOiBNYXJpdXMgU2N1cnRlc2N1IDxt c2N1cnRlc2N1QGdvb2dsZS5jb20+DQpDYzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8 cmljaGFubmFAYW1hem9uLmNvbT4sIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNv bT4sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4sIFBoaWwgSHVudCA8 cGhpbC5odW50QG9yYWNsZS5jb20+LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBp ZXRmLm9yZz4sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPg0KU3ViamVjdDogUmU6 IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD8NCg0KVGhl IHJlY2VpdmVyIHByb2JhYmx5IGtub3dzIHdoaWNoIHZlcnNpb24gdGhleSB3YW50LCBidXQgZG9l cyB0aGUgc2VuZGVyPyBVc2luZyB0aGUgZW1haWwgYW5hbG9neSwgeW91IG1heSBoYXZlIGNvbmZp Z3VyZWQgeW91ciBlbWFpbCBjbGllbnQgdG8gYWNjZXB0IHBsYWluIHRleHQgb25seS4gRm9ydHVu YXRlbHksIG15IGNsaWVudCBzZW5kcyBib3RoIOKAkyBub3Qga25vd2luZyB3aGF0IHlvdSBwcmVm ZXIg4oCTIGFuZCB5b3UgYXJlIGFibGUgdG8gdmlldyBteSBtZXNzYWdlLg0KDQpJIHRoaW5rIGl0 IHdvdWxkIGhlbHAgaWYgd2UgYnJva2UgdGhpcyBwcm9ibGVtIGRvd24gaW50byB0d28gcGFydHMu IDEvIEFyZSBtdWx0aS1mb3JtYXQgU0VUcyBkZXNpcmFibGU/IFRoYXQncyBiZWVuIHRoZSBkZXNp Z24gc2luY2UgdGhlIGVhcmxpZXN0IHZlcnNpb24uIDIvIFdoYXQgaXMgdGhlIGJlc3QgcmVwcmVz ZW50YXRpb24gb2YgdGhlIFNFVCBiYXNlZCBvbiB3aGF0IHdlIGRlY2lkZSBmb3IgIzEuDQoNCk15 IHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQgdGhlICJldmVudHMiIHBsdXJhbCAocmVsYXRlZCB0byAj MiwgdGhlIGJlc3QgcmVwcmVzZW50YXRpb24gb2YgYSBTRVQpIHdhcyBpbiBmYWN0IGEgY29uY2Vy biwgYXMgcGVvcGxlIG1heSBza2lwIHRoZSB0ZXh0IGFuZCBsb29rIGRpcmVjdGx5IGF0IHRoZSBK U09OIHN5bnRheCwgdGhlbiBqdW1wIHRvIGNvbmNsdXNpb25zLg0KDQpPbiBXZWQsIE5vdiAxLCAy MDE3IGF0IDI6NTQgUE0sIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxt YWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4gd3JvdGU6DQpPbiBXZWQsIE5vdiAxLCAyMDE3 IGF0IDI6NDYgUE0sIFdpbGxpYW0gRGVubmlzcyA8d2Rlbm5pc3NAZ29vZ2xlLmNvbTxtYWlsdG86 d2Rlbm5pc3NAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KUGVyaGFwcyBJIGNhbiB0cnkgYW5kIGV4cGxh aW4gdGhlIG9yaWdpbmFsIGludGVudCBvZiB0aGUgY3VycmVudCBkZXNpZ24uIFRoZSBnb2FsIHdh cyBhbHdheXMgdGhhdCBhIFNFVCByZXByZXNlbnRzIGEgc2luZ2xlIGxvZ2ljYWwgZXZlbnQuIEhv d2V2ZXIgbXVsdGlwbGUgc3lzdGVtcyBtYXkgaGF2ZSBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25z IG9mIHRoZSBldmVudCDigJMgdGhlIGV4YW1wbGUgZ2l2ZW4gb3JpZ2luYWxseSB3YXMgb25lIGZv cm1hdHRlZCBmb3IgUklTQywgYW5kIG9uZSBmb3IgU0NJTS4NCg0KQSBnb29kIGFuYWxvZ3kgaXMg ZW1haWwuIFlvdSBzZW5kIGEgc2luZ2xlIGxvZ2ljYWwgZW1haWwsIHdoaWNoIG1heSBoYXZlIHR3 byByZXByZXNlbnRhdGlvbnMsIEhUTUwgYW5kIHBsYWluIHRleHQuIFN5c3RlbXMgY2FuIGNvbnN1 bWUgdGhlIHZlcnNpb24gdGhhdCB0aGV5IHVuZGVyc3RhbmQgYW5kIGlnbm9yZSB0aGUgb25lIHRo ZXkgZG9uJ3QuDQoNClllcywgYW5kIEkgdGhpbmsgdGhpcyBpcyB3ZWxsIHVuZGVyc3Rvb2QuDQoN Cg0KDQpJJ20gc3RhcnRpbmcgdG8gcmVncmV0IHRoZSBwbHVyYWwgaW4gImV2ZW50cyIsIGl0IHdh cyBwbHVyYWxpemVkIGR1ZSB0byBpdCBiZWluZyBhbiBhcnJheSwgbm90IGJlY2F1c2UgaXQgcmVw cmVzZW50ZWQgbXVsdGlwbGUgbG9naWNhbCBldmVudHMuDQoNCkkgZG9uJ3QgdGhpbmsgdGhpcyBp cyB0aGUgbWFpbiBjb25jZXJuIG9yIGNhdXNlIGZvciBjb25mdXNpb24uDQoNCg0KDQpBbm5hYmVs bGUsIEkgdW5kZXJzdGFuZCB5b3VyIGNvbmNlcm5zIHJlZ2FyZGluZyBjb25mdXNpb24gb2YgdGhl IHNlbWFudGljcyBiZXR3ZWVuIHRoZSBKU09OIHN5bnRheCBhbmQgdGhlIHNwZWNpZmljYXRpb24g bGFuZ3VhZ2UuIEFyZSB0aGVyZSBvdGhlciB3YXlzIHRvIHJlc29sdmUgdGhhdCB3aXRob3V0IHJl bW92aW5nIHRoZSBhYmlsaXR5IGZvciBtdWx0aXBsZSByZXByZXNlbnRhdGlvbnMgb2YgdGhlIHNh bWUgZXZlbnQ/DQoNClRoZSBhcmd1bWVudCBpcyB0aGF0IG11bHRpcGxlIHJlcHJlc2VudGF0aW9u cyBjYW4gYmUgc2VudCBhcyBkaXN0aW5jdCBTRVRzLCBpZiByZWFsbHkgbmVlZGVkLiBJbiBwcmFj dGljZSB0aGlzIHdpbGwgaGFwcGVuIHF1aXRlIHJhcmUgdGhvdWdoLiBFdmVudHMgYXJlIGNyZWF0 ZWQgZm9yIGEgc3BlY2lmaWMgcmVjZWl2ZXIsIHRoZSByZWNlaXZlciBlaXRoZXIgd2FudHMgdGhl IFNDSU0gb3IgdGhlIFJJU0MgZmxhdm9yLCBhbmQgdGhleSBzaG91bGQgYmUgYWJsZSB0byBzcGVj aWZ5IHRoYXQgaW4gY29uZmlndXJhdGlvbiAodGhlcmUgaXMgYSBwcm9wb3NhbCBob3cgdG8gY2Fw dHVyZSB0aGF0KS4NCg0KRG8gd2UgaGF2ZSBhIGNvbXBlbGxpbmcgdXNlIGNhc2Ugd2hlcmUgYSBy ZWNlaXZlciBtdXN0IHJlY2VpdmUgbXVsdGlwbGUgdmFyaWFudHMgYWxsIGF0IG9uY2U/DQoNCg0K DQpPbiBXZWQsIE5vdiAxLCAyMDE3IGF0IDI6MzcgUE0sIE1hcml1cyBTY3VydGVzY3UgPG1zY3Vy dGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4gd3JvdGU6DQpP biBXZWQsIE5vdiAxLCAyMDE3IGF0IDEyOjQ1IFBNLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFj bGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KWW91IGNhbuKAmXQg cmVhbGx5IGhhdmUgbXVsdGlwbGUgZXZlbnRzIChhdCBsZWFzdCBvZiB0aGUgc2FtZSB0eXBlKS4g IFRoZSBjdXJyZW50IHNwZWMgY2FuIG9ubHkgaGF2ZSBvbmUgaW5zdGFuY2Ugb2YgYSBVUkkgKGFm YWlrKS4NCg0KTm90ZSB0aGF0IHRoZSBzcGVjIG5vcm1hdGl2ZWx5IGRvZXMgbm90IHN1cHBvcnQg bXVsdGlwbGUgZXZlbnQgU0VUUy4gIEl0IGN1cnJlbnRseSBzdGF0ZXM6DQoNCmV2ZW50cw0KDQog ICAgICBUaGUgc2VtYW50aWNzIG9mIHRoaXMgY2xhaW0gaXMgdG8gZGVmaW5lIGEgc2V0IG9mIGV2 ZW50IHN0YXRlbWVudHMNCg0KICAgICAgdGhhdCBlYWNoIE1BWSBhZGQgYWRkaXRpb25hbCBjbGFp bXMgdG8gZnVsbHkgZGVzY3JpYmUgYSBzaW5nbGUNCg0KICAgICAgbG9naWNhbCBldmVudCB0aGF0 IGhhcyBvY2N1cnJlZCAoZS5nLiBhIHN0YXRlIGNoYW5nZSB0byBhDQoNCiAgICAgIHN1YmplY3Qp LiAgTXVsdGlwbGUgZXZlbnQgc3RhdGVtZW50cyBvZiB0aGUgc2FtZSB0eXBlIFNIQUxMIE5PVCBi ZQ0KDQogICAgICBhY2NlcHRlZC4gIFRoZSAiZXZlbnRzIiBjbGFpbSBTSE9VTEQgTk9UIGJlIHVz ZWQgdG8gZXhwcmVzcw0KDQogICAgICBtdWx0aXBsZSBsb2dpY2FsIGV2ZW50cy4NCg0KVGhlIHNw ZWMgaGFzICphbHdheXMqIHN1cHBvcnRlZCByZXF1aXJlbWVudHMgKGFzIHN0YXRlZCBpbiB0aGUg c3BlYykgZm9yIG11bHRpcGxlIHNlcGFyYXRlIHByb2ZpbGUgc3RhdGVtZW50cyAoZnJvbSBvbmUg b3IgbW9yZSBwcm9maWxlIGZhbWlsaXRpZXMpIG5lZWRpbmcgdG8gYmUgc2VudCBhcyBhIHNpbmds ZSBtZXNzYWdlLiAgSXQgd291bGQgYmUgSU5TRUNVUkUgdG8gZm9yY2UgbXVsdGlwbGUgU0VUcyBi ZWNhdXNlIHRoZSBjdXJyZW50IGRlbGl2ZXJ5IG1lY2hhbmlzbSBvbmx5IGFsbG93cyBvbmUgU0VU IHRvIGJlIGRlbGl2ZXJlZCBhdCBhIHRpbWUuIFRoZXJlIGlzIG5vIHdheSB0byBhc3N1cmUgdGhh dCBhIHNpbmdsZSByZWNlaXZlciBnZXRzIGFsbCBvZiB0aGUgU0VUcyBpdCBuZWVkcyBpbiBhIG11 bHRpLXRocmVhZGVkLCBtdWx0aS1ub2RlIGVudmlyb25tZW50IGF0IHNjYWxlLiAgQXNzZW1ibGlu ZyBtdWx0aXBsZSBTRVRzIHRvIHRyYWNrIOKAnHR4buKAnSBpbiBhIGNvbW1vbiBzdGF0ZSBkYXRh YmFzZSBpcyBOT1Qgc2ltcGxlIG5vciBjb3N0IGVmZmVjdGl2ZS4NCg0KSSB0b3RhbGx5IGFncmVl IHRoYXQgaXQgaXMgZGlmZmljdWx0IGZvciByZWNlaXZlcnMgdG8gcmVjZWl2ZSBzZXBhcmF0ZSBl dmVudHMsIGluIG5vIHBhcnRpY3VsYXIgb3JkZXIgYW5kIGNvcnJlbGF0ZSBiYXNlZCBvbiAidHhu Ii4gQnV0LCByZWNlaXZlcnMgaGF2ZSB0byBzb2x2ZSB0aGlzIGlzc3VlIHJlZ2FyZGxlc3Mgb2Yg ImV2ZW50cyIgb3IgImV2ZW50Iiwgc28gaXQgaXMgdW5yZWxhdGVkIHRvIHRoaXMgcHJvcG9zYWwu DQoNCg0KDQpJZiB3ZSBhY2NvbW1vZGF0ZSB0aGlzIGluIHRoZSBwcm9wb3NlZCBmb3JtLCB3ZSBl bmQgdXAgd2l0aCBhIGNvbXBsZXgsIGRlZXBseSBuZXN0ZWQgSlNPTiBzdHJ1Y3R1cmUgd2l0aCB0 aGUgcG9zc2liaWxpdHkgb2YgbmFtZXNwYWNlIGNvbmZsaWN0cy4NCg0KSU1PIFRoZSBwcm9wb3Nh bCBkb2VzIG5vdCBzaW1wbGlmeSwgaXQgY29tcGxpY2F0aW5nIGFuZCBsaW1pdGluZy4NCg0KVGhl IGN1cnJlbnQgc3BlYyBoYXMgdmVyeSBjbGVhbiBKU09OIGFuZCBhdm9pZHMgbmFtZXNwYWNlIGNv bmZsaWN0cyBiZXR3ZWVuIHByb2ZpbGVzLiBJIHRoaW5rIHdlIHNob3VsZCBzdGF5IG9uIHRyYWNr IHdpdGggdGhlIGN1cnJlbnQgZHJhZnQgYW5kIG9ic2VydmUgdGhlIG5vcm1hdGl2ZSB0ZXh0IGlm IG5vdCBtYWtlIGl0IHN0cm9uZ2VyIGluIHJlZ2FyZHMgdG8gbXVsdGktZXZlbnRzICh1bmRlcnN0 b29kIHRoYXQgTWlrZSBtYXkgZGlzYWdyZWUpLg0KDQpQaGlsDQoNCk9yYWNsZSBDb3Jwb3JhdGlv biwgSWRlbnRpdHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0DQpAaW5kZXBlbmRlbnRpZA0Kd3d3 LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1 bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCk9uIE5vdiAxLCAy MDE3LCBhdCAxMjoxOCBQTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFt YXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiB3cm90ZToNCg0KVW5sZXNzIHRo ZSBwcm9maWxlIGd1YXJhbnRlZXMgdGhhdCBzdWNoIHJlbGF0ZWQgZXZlbnRzIHdpbGwgYWx3YXlz IGJlIGluY2x1ZGVkIGluIHRoZSBzYW1lIFNFVCwgdGhlbiB0aGUgcmVjZWl2ZXIgaGFzIHRvIGNv cnJlbGF0ZSBhY3Jvc3MgU0VUcyBhbnl3YXksIGFuZCBtdWx0aXBsZSBldmVudHMgcGVyIFNFVCBp cyBqdXN0IGdpdmluZyB0aGUgcmVjZWl2ZXIgYW5vdGhlciBzY2VuYXJpbyB0aGF0IHRoZXkgaGF2 ZSB0byBzdXBwb3J0Lg0KDQpJ4oCZdmUgYWxyZWFkeSBwcm92aWRlZCBzZXZlcmFsIG90aGVyIHJl YXNvbnMgd2h5IHdlIHNob3VsZCBub3Qgc3VwcG9ydCBtdWx0aXBsZSB0b2tlbnMgcGVyIFNFVCB0 aGF0IG5vIG9uZSBoYXMgYWRkcmVzc2VkLiBIZXJlIHRoZXkgYXJlIGFnYWluOg0KDQogIDEuICBN dWx0aXBsZSBldmVudCBzdXBwb3J0IHJlc3VsdHMgaW4gYSBtb3JlIGNvbXBsZXggc3RydWN0dXJl IGZvciB0aGUgc2luZ2xlIGV2ZW50IHVzZSBjYXNlLCB3aGljaCBJIHRoaW5rIHdlIGFsbCBhZ3Jl ZSBpcyB0aGUgbWFqb3JpdHkgdXNlIGNhc2UuDQogIDIuICBNdWx0aXBsZS1ldmVudCBTRVRzIGhh dmUgYW1iaWd1b3VzIHNlbWFudGljcy4gVGhlIHByZXNlbmNlIG9mIHR3byBldmVudHMgQSBhbmQg QiBpbiB0aGUgc2FtZSBTRVQgY291bGQgbWVhbiBhbnkgb2Y6DQoNCiAgICAgKiAgIEEgYW5kIEIg YXJlIHJlbGF0ZWQgdG8gdGhlIHNhbWUgbG9naWNhbCBldmVudCAoaS5lLiB0aGUgc2FtZSB0aGlu ZyBhcyBpZiB0aGV5IHdlcmUgZnJvbSBkaWZmZXJlbnQgU0VUcyB0aGF0IGhhdmUgYSBjb21tb24g dHhuKS4NCiAgICAgKiAgIEEgaXMgYW4gZXh0ZW5zaW9uIG9mIEIuDQogICAgICogICBCIGlzIGFu IGV4dGVuc2lvbiBvZiBBLg0KICAgICAqICAgQSBpcyBhbiBhbGlhcyBmb3IgQiwgb3IgdmljZS12 ZXJzYS4NCiAgICAgKiAgIEEgYW5kIEIgYXJlIG5vdCBhY3R1YWxseSByZWxhdGVkIHRvIG9uZSBh bm90aGVyIGluIGFueSB3YXksIGFuZCB0aGUgdHJhbnNtaXR0ZXIgYnVuZGxlZCB0aGVtIHRvZ2V0 aGVyIGJlY2F1c2UgdGhleSB3ZXJlIGdvaW5nIHRvIHRoZSBzYW1lIHJlY2VpdmVyLg0KDQogIDEu ICBUb3AtbGV2ZWwgY2xhaW0gc2VtYW50aWNzIGJlY29tZSBoYXJkZXIgdG8gZGVmaW5lLCBhcyBk aWZmZXJlbnQgcHJvZmlsZXMgbWF5IHdhbnQgdG8gdXNlIHRoZSBzYW1lIGNsYWltcyBpbiBkaWZm ZXJlbnQgd2F5cy4NCiAgMi4gIEV2ZW50IGF1dGhlbnRpY2l0eSBjYW5ub3QgYmUgdmVyaWZpZWQg d2l0aG91dCBoYXZpbmcgdGhlIGVudGlyZSBTRVQuIFRoaXMgZm9yY2VzIHJlY2VpdmVycyB0byBl eHBvc2UgZG93bnN0cmVhbSBzeXN0ZW1zIHRvIG1vcmUgaW5mb3JtYXRpb24gbmVjZXNzYXJ5LCBp ZiB0aG9zZSBzeXN0ZW1zIG5lZWQgdG8gYmUgYWJsZSB0byB2ZXJpZnkgYXV0aGVudGljaXR5Lg0K DQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2 aWNlcw0KDQoNCkZyb206IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxt YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgTm92 ZW1iZXIgMSwgMjAxNyBhdCAxMToyMSBBTQ0KVG86IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21h aWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQpDYzogWWFyb24gU2hlZmZlciA8 eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PiwgIlJp Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmlj aGFubmFAYW1hem9uLmNvbT4+LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRm Lm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+PiwgIlBoaWwgSHVudCAoSURNKSIgPHBoaWwu aHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpTdWJqZWN0OiBS RTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPw0KDQpJ IGNvbXBsZXRlbHkgYWdyZWUgb24gbW92aW5nIGNvbXBsZXhpdHkgdG8gdGhlIGlzc3VlciBvdmVy IHRoZSByZWNpcGllbnQuICBJbiBteSB2aWV3LCBpdOKAmXMgbW9yZSBjb21wbGV4IGZvciByZWNp cGllbnRzIHRvIGhhdmUgdG8gY29ycmVsYXRlIGFuZCBwcm9jZXNzIGEgc2VxdWVuY2Ugb2YgbXVs dGlwbGUgU0VUcyBwcm92aWRpbmcgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNhbWUgbG9naWNhbCBl dmVudCwgYW5kIHZhbGlkYXRlIE4gc2lnbmF0dXJlcywgdGhhbiB0byByZWNlaXZlIG9uZSBTRVQg d2l0aCBhbGwgdGhlIGFzcGVjdHMgb2YgdGhlIGxvZ2ljYWwgZXZlbnQgYXMg4oCcZXZlbnRz4oCd IGZpZWxkcywgd2l0aCBubyBjb3JyZWxhdGlvbiBvdmVyIHRpbWUgdGhlbiByZXF1aXJlZC4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCg0KRnJvbTogRGljayBIYXJkdCBbbWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tXQ0K U2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxLCAyMDE3IDk6MzkgQU0NClRvOiBNaWtlIEpvbmVz IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbT4+DQpDYzogWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0 bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PjsgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJp Y2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PjsgSUQgRXZlbnRz IE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3Jn Pj47IFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tPj4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVs dGlwbGUgZXZlbnRzIHBlciBTRVQ/DQoNCllvdXIgY29tbWVudHMgaGlnaGxpZ2h0IGEgY291cGxl IG9mIHBvaW50czoNCg0KMSkgVGhlIGV4YW1wbGUgaXMgaG93IHRvIGhhdmUgYSBwcmVkZWZpbmVk IGV4dGVuc2lvbiBwb2ludCBmb3IgZXh0ZW5zaW9ucyBvZiBhIHNwZWNpZmljIGV2ZW50LCBpdCBp cyBub3QgaG93IHRvIGFkZCBhbm90aGVyIGV2ZW50LiBNeXNlbGYsIEkgdGhpbmsgdGhpcyBpcyBv dmVybHkgY29tcGxpY2F0ZWQuIEV2ZW50cyBzaG91bGQgYmUgY29tcGFyYXRpdmVseSBzdGF0aWMs IGFuZCBhcyB3aXRoIG1hbnkgb3RoZXIgSlNPTiBmb3JtYXRzLCB0aGUgcmVjZWl2ZXIgc2hvdWxk IGlnbm9yZSBwcm9wZXJ0aWVzIGl0IGRvZXMgbm90IHVuZGVyc3RhbmQsIHdoaWNoIGxldCdzIG5l dyBwcm9wZXJ0aWVzIGJlIGludHJvZHVjZWQgYXMgZXh0ZW5zaW9ucy4gVGhlcmUgc2hvdWxkIG5v dCBiZSBhbnkgY29uZmxpY3QgYXMgZXh0ZW5zaW9ucyBzaG91bGQgb25seSBiZSBkb25lIGJ5IHRo ZSBwcm9maWxlIHRoYXQgY3JlYXRlZCB0aGUgZXZlbnQgZm9ybWF0IHRvIHN0YXJ0IG9mZiB3aXRo Lg0KDQoyKSBIYXZpbmcgYW4gbHZhbHVlIGJlIGEgVVJJIGlzIG11Y2ggaGFyZGVyIHRvIGNvZGUg YWdhaW5zdC4gSSdtIG5vdCBzdXJlIHdoeSBNYXJpdXMgaGFkIHRoYXQgaW4gaGlzIGV4YW1wbGUu IFBlciB0aGUgZXZlbnQsIHRoZSB0eXBlIG9mIHRoZSBldmVudCBpcyB3ZWxsIGRlZmluZWQgd2l0 aA0KDQoiZXZlbnRfdHlwZSI6ICJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dv cmRSZXNldEV4dCIsDQoNCjMpIFRoaXMgdGhyZWFkIGlzIGFib3V0IHJlYXNvbnMgZm9yIG11bHRp cGxlIGV2ZW50cyB0byBiZSBjb250YWluZWQgaW4gb25lIHNldC4gWW91ciBtZW50aW9uIG9mIGFu IGlzc3VlciBub3Qgd2FudGluZyB0byBzaWduIHNlcGFyYXRlIGV2ZW50cyBhcyBhIHJlYXNvbiB0 byBhbGxvdyBtdWx0aXBsZSBldmVudHMuIEkgdGhpbmsgd2UgaGF2ZSBkZWNpZGVkIHRoYXQgZ2l2 ZW4gYSBwcmVmZXJlbmNlLCB3ZSB3aWxsIHB1c2ggZWZmb3J0IHRvIHRoZSB0cmFuc21pdHRlciBv dmVyIHRoZSByZWNlaXZlciBhcyBpbiBtYW55IHVzZSBjYXNlcyB0aGVyZSBhcmUgbWFueSBtb3Jl IHJlY2VpdmVycy4gR2l2ZW4gdGhhdCwgaXQgaXMgbW9yZSBjb21wbGV4IGZvciBhIHJlY2VpdmVy IHRvIGhhdmUgZGlmZmVyZW50IHdheXMgb2YgbWFuYWdpbmcgdGhlIHJlY2VpcHQgb2YgbXVsdGlw bGUgZXZlbnRzIGFzIG5vdCBhbGwgaXNzdWVycyB3aWxsIGJ1bmRsZSB0aGUgZXZlbnRzLCBzbyBp dCBpcyBzaW1wbGVyIHRvIGhhdmUgb25seSBvbmUgZXZlbnQgcGVyIFNFVC4gSW5jbHVkaW5nIHRo ZSBzZXBhcmF0ZSBldmVudHMgd2l0aCBhIFVSSSBhcyBhbiBsdmFsdWUgaXMgY2hhbGxlbmdpbmcg dG8gaW1wbGVtZW50LCBzcGVha2luZyBmcm9tIGV4cGVyaWVuY2UuDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpPbiBUdWUsIE9jdCAzMSwgMjAxNyBhdCAxMTowNSBQTSwgTWlrZSBKb25lcyA8TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b20+PiB3cm90ZToNCk1hcml1c+KAmSBwcm9wb3NlZCBzeW50YXgsIHBhc3RlZCBpbiBiZWxvdywg aGFzIGV4YWN0bHkgdGhpcyBjaGFyYWN0ZXJpc3RpYy4gIFRoZSB3YXkgSSBzZWUgaXQsIGhpcyBw cm9wb3NhbCBlc3NlbnRpYWxseSBoYXMgYSBwcmltYXJ5IHBhc3N3b3JkUmVzZXQgZXZlbnQgYW5k IGEgc2Vjb25kYXJ5IHBhc3N3b3JkUmVzZXRFeHQgZGF0YSBzdHJ1Y3R1cmUsIHdoaWNoIGNvdWxk IGhhdmUgYmVlbiBzaW1wbHkgYW5vdGhlciBldmVudCB2YWx1ZSBpbiB0aGUgY3VycmVudCBkcmFm dC4NCg0KVGhpcyBicmVha2luZyBjaGFuZ2UgbWFrZXMgdGhlIGRhdGEgc3RydWN0dXJlcyBtb3Jl IGNvbXBsaWNhdGVkIC0gbm90IGxlc3MuICBBbmQgaXQgbWFrZXMgdGhpbmdzIHRoYXQgdXNlZCB0 byBiZSBwb3NzaWJsZSBpbXBvc3NpYmxlLCByZWR1Y2luZyBmbGV4aWJpbGl0eSB0byB0aG9zZSB3 aG8gd291bGQgdXNlIHRoZSBzcGVjLg0KDQpUaGVzZSBzZWVtIGxpa2UgYmFkIHRyYWRlb2ZmcyB0 byBtZS4NCg0Kew0KICAianRpIjogIjNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwIiwN CiAgImlhdCI6IDE0NTg0OTYwMjUsDQogICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29t PGh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8+IiwNCiAgImF1ZCI6IFsNCiAgICAiaHR0cHM6Ly9q aHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLA0KICAgICJo dHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyIN CiAgIF0sDQogICAiZXZlbnRfdHlwZSI6ICJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQv cGFzc3dvcmRSZXNldEV4dCIsDQogICAiZXZlbnQiOiB7DQogICAgICAgICAiaWQiOiI0NGY2MTQy ZGY5NmJkNmFiNjFlNzUyMWQ5IiwNCiAgICAgICAgICJleHRlbnNpb25zIjogew0KICAgICAgICAg ICAiaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHTigJ06IHsN CiAgICAgICAgICAgICAicmVzZXRBdHRlbXB0cyI6NSwNCiAgICAgICAgICAgfQ0KICAgICAgICAg fQ0KICAgICAgIH0NCn0NCg0KSW4gcGFydGljdWxhciwgaXQgbWFrZXMgaXQgaW1wb3NzaWJsZSB0 byBzaWduIG11bHRpcGxlIHJlbGF0ZWQgZXZlbnRzIHNoYXJpbmcgYSBjb21tb24gY2xhaW1zIHNj aGVtYSB3aXRoIGEgc2luZ2xlIHNpZ25hdHVyZSBieSB0aGUgaXNzdWVyLiAgSXQgZm9yY2VzIHRo ZSBpc3N1ZXIgdG8gZG8gdGhlIGV4dHJhIHdvcmsgb2Ygc2lnbmluZyBlYWNoIG9mIHRoZSByZWxh dGVkIGV2ZW50cyAob3IgZmFjZXRzIG9mIHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQpIGluZGl2aWR1 YWxseSBhbmQgZm9yY2VzIHRoZSByZWNpcGllbnRzIHRvIGRvIHRoZSBleHRyYSB3b3JrIG9mIGNo ZWNraW5nIGFsbCB0aG9zZSB1bm5lY2Vzc2FyeSBzaWduYXR1cmVzLg0KDQpOb3QgZXZlcnkgcHJv ZmlsZSB3aWxsIGV2ZXIgaGF2ZSBtdWx0aXBsZSBrZXlzIGluIHRoZSDigJxldmVudHPigJ0gc2V0 IGJ1dCB0aGVyZeKAmXMgYWJzb2x1dGVseSBubyByZWFzb24gdG8gcHJlY2x1ZGUgaXQuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCkZyb206IElkLWV2ZW50IFttYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBEaWNrIEhhcmR0 DQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMxLCAyMDE3IDk6NTIgUE0NClRvOiBNaWtlIEpvbmVz IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbT4+DQpDYzogWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0 bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PjsgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJp Y2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PjsgSUQgRXZlbnRz IE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3Jn Pj47IFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tPj4NCg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBt dWx0aXBsZSBldmVudHMgcGVyIFNFVD8NCg0KUGxlYXNlIGRpcmVjdCBtZSB0byBhIHByb3Bvc2Fs IHRoYXQgaGFzIGEgInByaW1hcnkiIGFuZCAic2Vjb25kYXJ5IiBldmVudHMuIEkgYWdyZWUgdGhh dCBpcyB1bmRlc2lyYWJsZS4gSSB3b3VsZCBhbHNvIGVuY291cmFnZSB0byBlbmdhZ2UgaW4gdGhl IGRpc2N1c3Npb25zIHNvIHRoYXQgd2UgY2FuIGRyaXZlIGNsYXJpdHkgYW5kIHNpbXBsaWNpdHku DQoNCkkgdGhpbmsgdGhlIHByb3Bvc2FsIGlzIHRoYXQgdGhlcmUgaXMgb25lIGV2ZW50IHBlciBT RVQuDQoNCkkgdGhpbmsgaGF2aW5nIG1vcmUgdGhhbiBvbmUgZXZlbnQgcGVyIFNFVCBhZGRzIGNv bXBsZXhpdHkgYXMgYSByZWNlaXZlciBtdXN0IGRlYWwgd2l0aCByZWNlaXZpbmcgY29ycmVsYXRl ZCBldmVudHMgaW4gb25lIFNFVCBhcyB3ZWxsIGFzIGNvcnJlbGF0ZWQgZXZlbnRzIGluIHRoZSBz YW1lIFNFVC4NCg0KL0RpY2sNCg0KT24gVHVlLCBPY3QgMzEsIDIwMTcgYXQgOTo0MiBQTSwgTWlr ZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkkgaGVhciB5b3Ugb24gdGhlIGZhY3QgdGhhdCBkaWZm ZXJlbnQgcGVvcGxlIGhhdmUgam9pbmVkIHRoZSBlZmZvcnQgYXQgZGlmZmVyZW50IHRpbWVzLiAg VGhhdOKAmXMgYSBub3JtYWwgcHJvY2VzcyBhcyBhbiBlZmZvcnQgYnVpbGRzIG1vbWVudHVtLiAg SSBnZXQgdGhhdCBub3QgZXZlcnlvbmUgd2FzIHRoZXJlIHdoZW4gcHJldmlvdXMgY29uc2Vuc3Vz IGNhbGxzIHdlcmUgdGFrZW4uDQoNCkkgc2hvdWxkIG5vdGUgdGhhdCBJIGhhdmUgc3BlY2lmaWMg dGVjaG5pY2FsIG9iamVjdGlvbnMgdG8gdGhlIHNwZWNpZmljIHByb3Bvc2VkIGNoYW5nZXMgYmVp bmcgZGlzY3Vzc2VkIGFzIHdlbGwuICBDdXJyZW50bHkgYWxsIGV2ZW50cyBpbiB0aGUgc2V0IGhh dmUgdGhlIHNhbWUgc3ludGF4LiAgVGhlIHByb3Bvc2FscywgYXMgSSB1bmRlcnN0YW5kIHRoZW0s IHJldmVydCB1cyB0byBhIHN0YXRlIHdoZXJlIHRoZXJl4oCZcyBhIOKAnHByaW1hcnnigJ0gYW5k IOKAnHNlY29uZGFyeeKAnSBldmVudHMsIHdpdGggZGlmZmVyZW50IHN5bnRheCBmb3IgdGhlIHR3 byBjbGFzc2VzLiAgVGhhdOKAmXMgbmVlZGxlc3NseSBtb3JlIGNvbXBsaWNhdGVkLCBhZGRpbmcg bm8gYWN0dWFsIHZhbHVlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBEaWNrIEhhcmR0IFtt YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPl0N ClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMzEsIDIwMTcgOTozNyBQTQ0KVG86IE1pa2UgSm9uZXMg PE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPj4NCkNjOiBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+OyBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFp bC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+OyBSaWNoYXJkIEJhY2ttYW4sIEFu bmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+ OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZl bnRAaWV0Zi5vcmc+Pg0KDQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11 bHRpcGxlIGV2ZW50cyBwZXIgU0VUPw0KDQpNaWtlDQoNCkFzIHlvdSB3ZWxsIGtub3csIG1hbnkg cGVvcGxlIGluIGEgV0cgZG9uJ3QgbG9vayBjbG9zZWx5IGF0IGEgc3BlY2lmaWNhdGlvbiB1bnRp bCBsYXN0IGNhbGwgaXMgbWFkZS4gQWRkaXRpb25hbGx5LCB3ZSBhcmUgY29taW5nIHVwIG9uIG9u bHkgdGhlIDNyZCBXRyBtZWV0aW5nLiBUaGUgV0cgaGFzIG5vdCBleGlzdGVkIGZvciB2ZXJ5IGxv bmcuIFdoaWxlIHNvbWUgb2YgdGhlIHBhcnRpY2lwYW50cyBoYXZlIGJlZW4gd29ya2luZyBvbiB0 aGlzIGZvciBhIHdoaWxlLCBtYW55IGhhdmUgbm90LCBhbmQgd2UgYXJlIGxvb2tpbmcgZm9yIGNv bnNlbnN1cyBhY3Jvc3MgdGhlIFdHLg0KDQpTaW5jZSBTZWNFdmVudCBpcyBhIGZyYW1ld29yayB0 aGF0IHdlIGV4cGVjdCB0byBiZSBwcm9maWxlZCwgSSBmZWVsIGl0IGlzIGltcG9ydGFudCB0byBl bnN1cmUgdGhhdCBTZWNFdmVudCBzcGVjaWZpY2F0aW9ucyBhcmUgZWFzeSBmb3IgYSB2YXJpZXR5 IG9mIHByb2ZpbGVzIHRvIGFkb3B0LCBhbmQgdGhhdCB0aGUgc2VtYW50aWNzIG1ha2Ugc2Vuc2Uu IEkgYWxzbyB0aGluayB0aGF0IHByb3BlcnRpZXMgdGhhdCBhcmUgc3BlY2lmaWMgdG8gYSBwcm9m aWxlIHNob3VsZCBiZSBsZWZ0IHRvIHRoYXQgcHJvZmlsZSBhbmQgbm90IGJlIGluY2x1ZGVkIGlu IFNlY0V2ZW50Lg0KDQpTaW5jZSB0aGlzIGlzIGEgZnJhbWV3b3JrLCBpdCBpcyBleHBlY3RlZCB0 aGF0IGFzIGRpZmZlcmVudCBncm91cHMgcHJvZmlsZSBpdCwgdGhlcmUgd2lsbCBiZSBhZGRpdGlv bmFsIGZlZWRiYWNrLg0KDQpTcGVjaWZpY2FsbHksIGFzIGEgcGFydGljaXBhbnQgaW4gdGhlIFJJ U0MgcHJvZmlsZSBvZiBTRVQsIGEgbnVtYmVyIG9mIGlzc3VlcyBpbiBTRVQgaGF2ZSBzdXJmYWNl ZCBhcyB0aGUgUklTQyBXRyBoYXMgbG9va2VkIGF0IGhvdyB0byB1c2UgdGhlIFNFVC4NCg0KQXMg Zm9yIFNFVCBiZWluZyBzdGFibGUgZm9yIG92ZXIgYSB5ZWFyLCB0aGVyZSBoYXZlIGJlZW4gYSBu dW1iZXIgb2YgY2hhbmdlcyB0byBTRVQgc2luY2UgdGhlbi4gSSBhbHNvIGRvbid0IHRoaW5rIHRo ZXJlIHdhcyBjb25zZW5zdXMuIEJlZm9yZSB0aGUgV0cgd2FzIGZvcm1lZCwgSSBhbmQgc2V2ZXJh bCBvdGhlcnMgaGFkIGV4cHJlc3NlZCBjb25jZXJuIG9uIHRoZSBkZXNpZ24gb2YgU0VUIHdoZW4g UGhpbCBwcmVzZW50ZWQgaXQgYXQgYW4gSUlXIHNlc3Npb24uDQoNCkFzIHRvIHRha2luZyBhbm90 aGVyIHllYXIsIEkgYW0gaG9wZWZ1bCB3ZSBjYW4gcmVzb2x2ZSB0aGUgcmVtYWluaW5nIGlzc3Vl cyBpbiBTRVQgYW5kIHB1Ymxpc2ggYSBuZXcgZHJhZnQgZm9yIGxhc3QgY2FsbC4gSSBkbyBub3Qg dGhpbmsgd2Ugd2lsbCBuZWVkIHRvIHdhaXQgZm9yIGFub3RoZXIgV0cgbWVldGluZyB0byBhc2sg Zm9yIGxhc3QgY2FsbC4NCg0KV2UgYWxzbyBoYXZlIGEgbnVtYmVyIG9mIG90aGVyIGRvY3VtZW50 cyB0aGF0IGFyZSBub3QgaW4gbGFzdCBjYWxsLCBhbmQgd2UgZG9uJ3QgaGF2ZSBhIFdHIGFkb3B0 ZWQgZHJhZnQgeWV0IGZvciBtYW5hZ2VtZW50LiBTbyB0aGVyZSBhcmUgc3RpbGwgYSBudW1iZXIg b2YgZG9jdW1lbnRzIHRvIHdvcmsgdGhyb3VnaCBiZWZvcmUgd2UgaGF2ZSBhbGwgdGhlIGJpdHMg Zm9yIHNvbWVvbmUgdG8gd29yayB3aXRoLg0KDQpJIGRvIHRoaW5rIHdlIGhhdmUgYmVlbiBtYWtp bmcgZ29vZCBwcm9ncmVzcyBzaW5jZSB0aGUgbGFzdCBJRVRGIG1lZXRpbmcsIGFuZCBJIGFtIGhv cGVmdWwgd2UgY2FuIGtlZXAgdXAgdGhpcyBtb21lbnR1bSBhbmQgZmluYWxpemUgYWxsIHRoZSBk b2N1bWVudHMgaW4gYSB0aW1lbHkgbWFubmVyLg0KDQovRGljaw0KDQoNCk9uIFR1ZSwgT2N0IDMx LCAyMDE3IGF0IDEyOjQ4IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSXTigJlzIGhh cmQgZm9yIG1lIHRvIGV2ZW4gZXhwcmVzcyBteSBsZXZlbCBvZiBmcnVzdHJhdGlvbiB3aXRoIHRo ZSByZWNlbnQgYXR0ZW1wdHMgdG8gb25jZSBhZ2FpbiByZWRlc2lnbiB0aGUgU2VjRXZlbnQgVG9r ZW4gc3BlYy4gIFdl4oCZdmUgYmVlbiBhdCB0aGlzIGZvciBtdWx0aXBsZSB5ZWFycyBiZWNhdXNl IHBlb3BsZSBrZWVwIHRyeWluZyB0byByZXZpc2l0IGRlY2lzaW9ucyB0aGF0IHdlcmUgbG9uZyBh Z28gbWFkZSBieSBjb25zZW5zdXMuICBJdOKAmXMgYmVlbiBzdGFibGUgZm9yIG92ZXIgYSB5ZWFy IGFuZCB0aGUgbWFqb3JpdHkgb2YgV0dMQyByZXNwb25kZW50cyBzYWlkIHNvbWUgdmFyaWFudCBv ZiDigJxXb3JrcyBmb3IgbWUg4oCTIHNoaXAgaXQh4oCdDQoNClRoZXJl4oCZcyBub3Qgc3VmZmlj aWVudCBqdXN0aWZpY2F0aW9uIHRvIHRyeSB0byB1bmRvIGNvbnNlbnN1cyBwb3NpdGlvbnMgdGhh dCBoYXZlIGJlZW4gZGViYXRlZCBhbmQgYWZmaXJtZWQgb3ZlciBhbmQgb3Zlci4gIENvdW50ZW5h bmNpbmcgd2hvbGVzYWxlIGNoYW5nZXMgYXQgdGhpcyBsYXRlIGRhdGUgaXMgY291bnRlcnByb2R1 Y3RpdmUgaW4gdGhlIGV4dHJlbWUhDQoNCkl04oCZcyBmYXIgYmV0dGVyIHRoYW4gZ29vZCBlbm91 Z2ggYXMtaXMuICBJbiBteSBleHBlcmllbmNlLCBpZiB3ZSBzdGFydCByZWRlc2lnbmluZyBpdCwg aXQgd2lsbCByZXN1bHQgaW4gYW5vdGhlciB5ZWFy4oCZcyBkZWxheS4gIEl0IGRvZXMgc29tZXRo aW5nIHNpbXBsZSBhbmQgdXNlZnVsLiAgUGxlYXNlLCBsZXTigJlzIGp1c3Qgc2hpcCBpdCwgc28g cGVvcGxlIGNhbiByZWx5IG9uIGl0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBQaGlsIEh1bnQgKElETSkg W21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+ XQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDMwLCAyMDE3IDI6NDIgUE0NClRvOiBEaWNrIEhhcmR0 IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0KQ2M6 IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZA Z21haWwuY29tPj47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24u Y29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj47IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47IElE IEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBp ZXRmLm9yZz4+DQoNClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlw bGUgZXZlbnRzIHBlciBTRVQ/DQoNCklubGluZS4uLg0KDQpQaGlsDQoNCk9uIE9jdCAzMCwgMjAx NywgYXQgMjoyMiBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRp Y2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBQaGlsDQoNCkNvcnJlY3QgbWUgaWYgSSBh bSBtaXN1bmRlcnN0YW5kaW5nLCBidXQgdGhlcmUgaXMgYSBSSVNDIHByb2ZpbGUgZXZlbnQNCg0K DQoNCiJodHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS88 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVt YXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV8tMjU1QyZkPUR3TUZhUSZj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdt YW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09aXlWbnJabXI5X3VHQ1E2TUQwekYy eW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZzPTI1bDA5c0g4WVY0Mnh6Z1UtQ1hTZzh4SDl0dnlESno0 MHRDUmpGYWxoa3cmZT0+YWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZOKAnQ0KDQoN CmFuZCBhbiBTQ0lNIHByb2ZpbGUgZXZlbnQNCg0KDQoiaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2lt L2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHTigJ0NCg0KDQpJJ20gc3VnZ2VzdGluZyB0aGF0IHR3byBk aWZmZXJlbnQgZXZlbnRzIHdvdWxkIGJlIHNlbnQuIEVtYmVkZGluZyBvbmUgaW4gdGhlIG90aGVy IGRvZXMgbm90IG1ha2Ugc2Vuc2UuDQo8cGg+SXQgaXMgYSBoeXBvdGhldGljYWwgZXhhbXBsZS4g SnVzdCBiZWNhdXNlIHlvdSBkaXNhZ3JlZSBvbiB0aGlzIGRvZXMgbm90IG1lYW4gb3RoZXJzIGFy ZSBub3QgdmFsaWQuDQoNCkkganVzdCBwaWNrZWQgb3ZlcmxhcHBpbmcgcHJvcG9zYWxzIHRoYXQg aGF2ZSBkaWZmZXJlbnQgbWVhbmluZyAoYnV0IG5vdCB0aGUgc2FtZSkgdG8gaWxsdXN0cmF0ZSB0 aGUgZGlmZmVyZW5jZSBmcm9tIGlzc3VpbmcgYSBzaW5nbGUgc2V0IHdpdGggZGlmZmVyZW50IGV2 ZW50cy4NCg0KQXMgSSBoYXZlIHN0YXRlZCB0aGlzIGlzIHZlcnkgZGlmZmVyZW50IGZyb20gYXNz ZXJ0aW5nIG11bHRpcGxlIGRpc3RpbmN0IGV2ZW50cyBpbiBvbmUgU0VULg0KDQpBbHNvLCBJIHRo aW5rIGl0IGlzIHNpbXBsZXIgdG8gaGF2ZSBldmVudF90eXBlIGJlIGF0IHRoZSBzYW1lIGxldmVs IGFzIGV2ZW50DQoNCjxwaD5tYXkgYmUuIEkgd2FzIHdvcmtpbmcgZnJvbSBBbm5hYmVsbGUncyBw cm9wb3NlZCBmb3JtYXQuDQoNCnsNCiAgImp0aSI6ICIzZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFi ZDRlN2QzMCIsDQogICJpYXQiOiAxNDU4NDk2MDI1LA0KICAiaXNzIjogImh0dHBzOi8vc2NpbS5l eGFtcGxlLmNvbTxodHRwczovL3NjaW0uZXhhbXBsZS5jb20vPiIsDQogICJhdWQiOiBbDQogICAg Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0 IiwNCiAgICAiaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQx ZDc2NzZlZTciDQogICBdLA0KICAgImV2ZW50X3R5cGUiOiAiaHR0cHM6Ly9leGFtcGxlLmNvbS9z Y2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiLA0KICAgImV2ZW50Ijogew0KICAgICAgICAgImlk IjoiNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsDQogICAgICAgICAicmVzZXRBdHRlbXB0cyI6 NQ0KICAgICAgIH0NCn0NCg0Kew0KICAianRpIjogIjNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJk NGU3ZDMwIiwNCiAgImlhdCI6IDE0NTg0OTYwMjUsDQogICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4 YW1wbGUuY29tPGh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8+IiwNCiAgImF1ZCI6IFsNCiAgICAi aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQi LA0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFk NzY3NmVlNyINCiAgIF0sDQogICAiZXZlbnRfdHlwZSI6ICJodHRwOi8vc2NoZW1hcy5vcGVuaWQu bmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS9hY2NvdW50LWNyZWRlbnRpYWwtY2hhbmdlLXJl cXVpcmVkPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNB X19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZlbnRfcmlzY19ldmVudC0yRHR5cGVfYWNjb3VudC0y RGNyZWRlbnRpYWwtMkRjaGFuZ2UtMkRyZXF1aXJlZCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBw dVlxUGtBSTFhTGNMTjRLWk5BJm09aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1 OF9xU0NfdyZzPW5ReTllelBSakRHZHZSVENhaUR0aTRPSGVsSDNES2dVQ1RLakYyR1Etc28mZT0+ IiwNCiAgICJldmVudCI6IHsNCiAgICAgICDigJxzdWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0s DQogICAgICAg4oCcaXNz4oCdOiJodHRwczovL2lkcC5leGFtcGxlLmNvbS8iDQogICAgICAgfQ0K fQ0KDQoNCg0KDQoNCk9uIE1vbiwgT2N0IDMwLCAyMDE3IGF0IDEyOjA5IFBNLCBQaGlsIEh1bnQg PHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3Rl Og0KQW5uYWJlbGxlL0RpY2ssDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBJIHRoaW5rIHdl IG5lZWQgdG8gZXhhbWluZSB0aGUgY29uc2VxdWVuY2VzIG9mIHRoZSBwcm9wb3NhbCBpbiBKU09O Lg0KDQpBcyBJIHN0YXRlZCwgd2hhdCBjYXVzZXMgbW9zdCBvZiB0aGUgaXNzdWUgaXMgdGhlIHBy b3Bvc2VkIGV4dGVuc2lvbiBtZWNoYW5pc20gaW4gdGhlIHBheWxvYWQgKHBvc3NpYmx5IHVzaW5n IGV2ZW50cyBpbiBhIHJlY3Vyc2l2ZSB3YXkpLiBEb2VzIGl0IGZvbGxvdyB0aGUgb2xkIGZvcm1h dCBvciB0aGUgbmV3Pw0KDQpMZXTigJlzICBjb25zaWRlciBhIHVzZSBjYXNlIHdoZXJlIHdlIGhh dmUgYW4gaWRlbnRpdHkgbWFuYWdlbWVudCBzeXN0ZW0gdGhhdCB1c2VzIFNDSU0sIGJ1dCB0aGUg U0NJTSBzeXN0ZW0gaXMgYWxzbyB0aGUgdW5kZXJseWluZyBkYXRhIHN0b3JlIGZvciBDb25uZWN0 LiAgQSBQYXNzd29yZCByZXNldCBtaWdodCBnZW5lcmF0ZSB0aGUgZm9sbG93aW5nIGV2ZW50IHdo aWNoIGhhcyBhbiBleHRlbnNpb24gKGNvbnZleWluZyByZXNldCBjb3VudCkgQU5EIG92ZXJsYXBw aW5nIHN0YXRlbWVudCBmcm9tIFJJU0MuICBCT1RIIG9mIHdoaWNoIG1pZ2h0IGJlIGltcG9ydGFu dCB0byBhIHNpbWlsYXIgcmVjZWl2ZXIgdXNpbmcgU0NJTSBhbmQgT0lEQy4NCg0KVGhlIDAzIHNw ZWMgY3VycmVudGx5IHdvdWxkIGFsbG93Og0KDQoNCnsNCg0KICAianRpIjogIjNkMGMzY2Y3OTc1 ODRiZDE5M2JkMGZiMWJkNGU3ZDMwIiwNCg0KICAiaWF0IjogMTQ1ODQ5NjAyNSwNCg0KICAiaXNz IjogImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbTxodHRwczovL3NjaW0uZXhhbXBsZS5jb20vPiIs DQoNCiAgImF1ZCI6IFsNCg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThk NTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsDQoNCiAgICAiaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29t L0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciDQoNCiAgIF0sDQoNCiAgICJldmVudHMi OiB7DQoNCiAgICAgInVybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3JkUmVzZXQiOg0K DQogICAgICAgeyAiaWQiOiI0NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5In0sDQoNCiAgICAgImh0 dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0IjoNCg0KICAgICAg IHsgInJlc2V0QXR0ZW1wdHMiOjV9LA0KDQogICAgICJodHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0 L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS9cPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZlbnRfcmlzY19l dmVudC0yRHR5cGVfLTI1NUMmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdx SXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40 S1pOQSZtPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmcz0yNWww OXNIOFlWNDJ4emdVLUNYU2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmU9Pg0KICAgICAgIGFjY291 bnQtY3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWQiOiB7DQoNCiAgICAgICAgIOKAnHN1YuKAnTri gJ03Mzc1NjI2QTY1NjM3NOKAnSwNCg0KICAgICAgICAg4oCcaXNz4oCdOiJodHRwczovL2lkcC5l eGFtcGxlLmNvbS8iDQoNCiAgICAgICB9DQoNCiAgfQ0KDQp9DQoNCg0KDQpJbiB0aGUgYWJvdmUg LSBlYWNoIHBheWxvYWQgaXMgYSDigJhwZWVyJyBhbmQgaXNzdWVkIHdpdGhvdXQgcHJlZmVyZW5j ZSBieSB0aGUgdHJhbnNtaXR0ZXIuIFRoZSByZWNlaXZlciBjYW4gYXNzaWduIHByaW9yaXR5IGlu IGl0cyBvd24gY29udGV4dCBpZiB0aGF0IG1hdHRlcnMuDQoNCg0KDQpUaGUgbmV3IHByb3Bvc2Fs Og0KDQoNCg0Kew0KDQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAi LA0KDQogICJpYXQiOiAxNDU4NDk2MDI1LA0KDQogICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1w bGUuY29tPGh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8+IiwNCg0KICAiYXVkIjogWw0KDQogICAg Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0 IiwNCg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2 NDFkNzY3NmVlNyINCg0KICAgXSwNCg0KICAgImV2ZW50Ijogew0KDQogICAgIOKAnGV2ZW50X3R5 cGXigJ06InVybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3JkUmVzZXTigJ0sDQoNCiAg ICAgImlkIjrigJ00NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ54oCdLA0KDQogICAgIOKAnGV2ZW50 c+KAnTp7DQoNCiAgICAgLT5ub3RlIOKApmlzIHRoaXMgdGhlIG9sZCBvciBuZXcgc3RydWN0dXJl PyA8LQ0KDQogICAgICAgImh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJl c2V0RXh0IjoNCg0KICAgICAgICAgeyAicmVzZXRBdHRlbXB0cyI6NX0sDQoNCiAgICAgICAiaHR0 cDovL3NjaGVtYXMub3BlbmlkLm5ldC9zZWNldmVudC9yaXNjL2V2ZW50LXR5cGUvXDxodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVu aWQubmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlXy0yNTVDJmQ9RHdNRmFRJmM9Um9QMVl1 bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0 RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZs SzY3eUZfOHU4X3FTQ193JnM9MjVsMDlzSDhZVjQyeHpnVS1DWFNnOHhIOXR2eURKejQwdENSakZh bGhrdyZlPT4NCiAgICAgICAgIGFjY291bnQtY3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWQiOiB7 DQoNCiAgICAgICAgIOKAnHN1YuKAnTrigJ03Mzc1NjI2QTY1NjM3NOKAnSwNCg0KICAgICAgICAg 4oCcaXNz4oCdOiJodHRwczovL2lkcC5leGFtcGxlLmNvbS8iDQoNCiAgICAgICB9DQoNCiAgICAg fQ0KDQogICB9DQoNCn0NCg0KDQoNCkluIHRoZSBhYm92ZSwgc3ViLWV2ZW50cyBvciBleHRlbnNp b25zIGhhdmUgYSBkaWZmZXJlbnQgZm9ybWF0LiBUaGUgc2FtZSBjb21wbGFpbnQgYWJvdXQgdGhl IG9yaWdpbmFsIHN0YW5kcy4NCg0KDQoNCipPUiogKGlmIHRoZSByZWNlaXZlciBjYXJlcyBhYm91 dCBSSVNDIG1vcmUpLiAgTm90ZSB0aGF0IHRoaXMgbGVhZHMgdG8gYSB0cmlwbGUgbmVzdGVkIHN0 cnVjdHVyZS4NCg0KDQoNCnsNCg0KICAianRpIjogIjNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJk NGU3ZDMwIiwNCg0KICAiaWF0IjogMTQ1ODQ5NjAyNSwNCg0KICAiaXNzIjogImh0dHBzOi8vc2Np bS5leGFtcGxlLmNvbTxodHRwczovL3NjaW0uZXhhbXBsZS5jb20vPiIsDQoNCiAgImF1ZCI6IFsN Cg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1 OTNiNzc1NCIsDQoNCiAgICAiaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUx NmIxZDA4NjQxZDc2NzZlZTciDQoNCiAgIF0sDQoNCiAgICJldmVudCI6IHsNCg0KICAgICDigJxl dmVudF90eXBl4oCdOiJodHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZl bnQtdHlwZS9cPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw LTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZlbnRfcmlzY19ldmVudC0yRHR5cGVfLTI1NUMm ZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9 bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPWl5Vm5yWm1yOV91 R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmcz0yNWwwOXNIOFlWNDJ4emdVLUNYU2c4 eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmU9Pg0KDQogICAgICAgICAgICAgYWNjb3VudC1jcmVkZW50 aWFsLWNoYW5nZS1yZXF1aXJlZOKAnSwNCg0KICAgICAg4oCcc3Vi4oCdOuKAnTczNzU2MjZBNjU2 Mzc04oCdLA0KDQogICAgICDigJxpc3PigJ06Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tL+KAnDxo dHRwczovL2lkcC5leGFtcGxlLmNvbS8lRTIlODAlOUM+LA0KDQogICAgICDigJxldmVudHPigJ06 ew0KDQogICAgICAgICJ1cm46aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpwYXNzd29yZFJlc2V0IjoN Cg0KICAgICAgICB7DQoNCiAgICAgICAgICAiaWQiOuKAnTQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIx ZDnigJ0sDQoNCiAgICAgICAgICDigJxldmVudHPigJ06ew0KDQogICAgICAgICAgICAgImh0dHBz Oi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0IjoNCg0KICAgICAgICAg ICAgICAgeyAicmVzZXRBdHRlbXB0cyI6NX0sDQoNCiAgICAgICAgICB9DQoNCiAgICAgICAgfQ0K DQogICAgICB9DQoNCiAgIH0NCg0KfQ0KDQoNCg0KSW4gdGhlIGFib3ZlLCB0aGUgZXh0ZW5zaW9u IGlzIHBsYWNlZCBpbnNpZGUgdGhlIGV2ZW50IGl0IGV4dGVuZHMuIEl0IGZvbGxvd3MgdGhlIG9s ZCBmb3JtYXQgKG9yIHNob3VsZCBpdCBmb2xsb3cgdGhlIG5ldz8pDQoNCipPUiogRm9sbG93aW5n IHRoZSB0b3AgbGF5ZXIgcGF0dGVybiBvZiBzaW5ndWxhciBldmVudCAgTm90ZSB0aGF0IHRoaXMg bGVhZHMgdG8gYSB0cmlwbGUgbmVzdGVkIHN0cnVjdHVyZS4NCg0KDQoNCnsNCg0KICAianRpIjog IjNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwIiwNCg0KICAiaWF0IjogMTQ1ODQ5NjAy NSwNCg0KICAiaXNzIjogImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbTxodHRwczovL3NjaW0uZXhh bXBsZS5jb20vPiIsDQoNCiAgImF1ZCI6IFsNCg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5j b20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsDQoNCiAgICAiaHR0cHM6Ly9qaHVi LmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciDQoNCiAgIF0sDQoN CiAgICJldmVudCI6IHsNCg0KICAgICDigJxldmVudF90eXBl4oCdOiJodHRwOi8vc2NoZW1hcy5v cGVuaWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS9cPGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZl bnRfcmlzY19ldmVudC0yRHR5cGVfLTI1NUMmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBr QUkxYUxjTE40S1pOQSZtPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVND X3cmcz0yNWwwOXNIOFlWNDJ4emdVLUNYU2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmU9Pg0KDQog ICAgICAgICAgICAgYWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZOKAnSwNCg0KICAg ICAg4oCcc3Vi4oCdOuKAnTczNzU2MjZBNjU2Mzc04oCdLA0KDQogICAgICDigJxpc3PigJ06Imh0 dHBzOi8vaWRwLmV4YW1wbGUuY29tL+KAnDxodHRwczovL2lkcC5leGFtcGxlLmNvbS8lRTIlODAl OUM+LA0KDQogICAgICDigJxldmVudOKAnTp7DQoNCiAgICAgICAg4oCcZXZlbnRfdHlwZeKAnToi dXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldOKAnSwNCg0KICAgICAgICAi aWQiOuKAnTQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDnigJ0sDQoNCiAgICAgICAg4oCcZXZlbnTi gJ06ew0KDQogICAgICAgICAg4oCcZXZlbnRfdHlwZeKAnToiaHR0cHM6Ly9leGFtcGxlLmNvbS9z Y2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHTigJ0sDQoNCiAgICAgICAgICAicmVzZXRBdHRlbXB0 cyI6NQ0KDQogICAgICAgIH0NCg0KICAgICAgfQ0KDQogICB9DQoNCn0NCg0KDQoNClRoaXMgZm9y bWF0IGZvbGxvd3MgdGhlIHByb3Bvc2VkIHNpbmd1bGFyIGV2ZW50IGZvcm1hdCByZWN1cnNpdmVs eSBhbmQgaXMgMyBsYXllcnMgZGVlcC4gTm90ZSB0aGF0IHRoZSBwYXJzZXIgaGFzIHRvIGNvbnRp bnVlIHRvIHNlYXJjaCB0aGUgZG9jdW1lbnQgZm9yIHRoaW5ncyB0aGF0IGFyZW7igJl0IHRoZXJl IGFzIGl0IGhhcyB0byBzdG9wIHdoZW4gbm8g4oCcZXZlbnTigJ0gYXR0cmlidXRlIGlzIGZvdW5k IHJhdGhlciB0aGFuIGl0ZXJhdGUgb3ZlciBhbiBhcnJheS4NCg0KDQpQaGlsDQoNCk9yYWNsZSBD b3Jwb3JhdGlvbiwgSWRlbnRpdHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0DQpAaW5kZXBlbmRl bnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5jb20mZD1Ed01GYVEmYz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFu cVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnlt UlFTNmxLNjd5Rl84dThfcVNDX3cmcz05c1loZ3BFemI3eFBsUUZtQ0NYTm1IbzZmUU45SUJ1LVNI SmFtZ19CNEhzJmU9Pg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tPg0KDQpPbiBPY3QgMzAsIDIwMTcsIGF0IDg6NTcgQU0sIFJpY2hhcmQgQmFja21hbiwg QW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29t Pj4gd3JvdGU6DQoNClJlcGxpZXMgaW5saW5lLg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFj a21hbg0KSWRlbnRpdHkgU2VydmljZXMNCg0KDQpGcm9tOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBv cmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpEYXRlOiBTdW5kYXksIE9j dG9iZXIgMjksIDIwMTcgYXQgNToyNSBQTQ0KVG86IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21h aWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQpDYzogWWFyb24gU2hlZmZlciA8 eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PiwgTWlr ZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20+PiwgIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFA YW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+LCBJRCBFdmVudHMgTWFpbGlu ZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNF VD8NCg0KSSBob3BlIHRoaXMgYW5zd2VycyB5b3VyIHF1ZXN0aW9uLg0KDQpNeSDigJxtYXnigJ0g d2FzIGJlY2F1c2UgSSBjYW7igJl0IHNlZSBhIHJlYXNvbiB3aHkgbm90LiBUaGUgcXVlc3Rpb24g c2hvdWxkIGJlLCB3aGF0IGlzIHRoZSBqdXN0aWZpY2F0aW9uIHRvIG1ha2Ug4oCcZXZlbnRz4oCd IHNpbmd1bGFyPw0KW3JpY2hhbm5hXVRoZSBzaW5ndWxhciDigJxldmVudOKAnSBjbGFpbSBoYXMg Y2xlYXJlciBzZW1hbnRpY3MgYW5kIGlzIGVhc2llciB0byBwcm9jZXNzLiBXZSBzaG91bGQgb3B0 IGZvciBlYXNpZXIgc29sdXRpb25zIHVubGVzcyB0aGVyZSBhcmUgdXNlIGNhc2VzIHRoYXQgcmVx dWlyZSBtb3JlIGNvbXBsZXhpdHkuWy9yaWNoYW5uYV0NCg0KVGhlcmUgYXJlIG1hbnkgcmVhc29u cyBmb3IgbXVsdGlwbGUgZXZlbnRzIGluIGEgU0VULiAgU29tZSBhcmUgZ29vZCwgc29tZSBub3Qg c28gZ29vZC4gU29tZSBvZiB0aGUgcmVhc29ucy4uLg0KDQoxLiAgTXVsdGlwbGUgZXZlbnQgcGF5 bG9hZHMgZXhwcmVzc2luZyBzdGF0ZW1lbnRzIGFib3V0IGxhcmdlbHkgdGhlICpzYW1lKnRoaW5n LiBGb3IgZXhhbXBsZSwgU0NJTSBwYXNzd29yZCByZXNldCBBTkQgUklTQyBwYXNzd29yZCByZXNl dC4gIEEgUklTQyBFdmVudCBhbmQgYW4gT3BlbkJhbmtpbmcgRXZlbnQuIElzIG9uZSBhIGNvbXBs ZW1lbnQgdG8gdGhlIG90aGVyPyAgRG8gdGhleSBvdmVybGFwIG9yIGFyZSB0aGV5IGRpc3RpbmN0 Pw0KW3JpY2hhbm5hXUNvcHkvcGFzdGVkIGZyb20gbXkgZWFybGllciBlbWFpbDoNCldoeSBpcyBp dCBuZWNlc3Nhcnkgb3IgYXBwcm9wcmlhdGUgdG8gaW5jbHVkZSB0aGVzZSBldmVudHMgaW4gdGhl IHNhbWUgU0VUPyBUaGV5IGFyZSBsaWtlbHkgYmVpbmcgZ2VuZXJhdGVkIGJ5IGRpZmZlcmVudCBz eXN0ZW1zIGF0IGRpZmZlcmVudCB0aW1lcyBvbiB0aGUgdHJhbnNtaXR0ZXLigJlzIHNpZGUsIGNv bnN1bWVkIGJ5IGRpZmZlcmVudCBzeXN0ZW1zIG9uIHRoZSByZWNlaXZlcuKAmXMgc2lkZSwgYW5k IHBvc3NpYmx5IGJlaW5nIHRyYW5zbWl0dGVkIG92ZXIgZGlmZmVyZW50IGV2ZW50IHN0cmVhbXMu IEkga25vdyB0aGUgbGF0dGVyIHdvdWxkIGJlIHRoZSBjYXNlIGZvciB1cywgYXMgYSByZWNlaXZl ci4gRXZlbiBpZiBpdOKAmXMgbm90LCBpcyBpdCBidXJkZW5zb21lIHRvIHNlbmQgdGhlc2UgZXZl bnRzIHNlcGFyYXRlbHk/IFdoYXQgdmFsdWUgaXMgZ2FpbmVkIGluIGNvbWJpbmluZyB0aGVtPw0K DQpBZGRpdGlvbmFsbHksIHNpbmNlIHRoZSBzaWduYXR1cmUgaXMgb3ZlciB0aGUgU0VUIGFuZCBu b3QgdGhlIGV2ZW50IG9iamVjdHMsIFJlY2VpdmVycyBpbmRlcGVuZGVudGx5IHJvdXRlIHNlcGFy YXRlIGV2ZW50cyBmcm9tIGEgc2luZ2xlIHRva2VuIHdpdGhvdXQgZWl0aGVyIGxvc2luZyB0aGUg YWJpbGl0eSB0byB2ZXJpZnkgdGhlIGF1dGhlbnRpY2l0eSBvZiB0aGUgZXZlbnQgb3Igc2hhcmlu ZyBhbGwgaW5mb3JtYXRpb24gaW4gdGhlIFNFVCB3aXRoIGV2ZXJ5IHN5c3RlbSBoYW5kbGluZyBh bnkgZXZlbnQgaW4gdGhlIHRva2VuLlsvcmljaGFubmFdDQoNCjIuICBNdWx0aXBsZSBldmVudHMg cGF5bG9hZHMgZXhwcmVzc2luZyBkaWZmZXJlbnQgc3RhdGVtZW50cyBhYm91dCB0aGUgc2FtZSB0 cmFuc2FjdGlvbiAtIFJJU0MgUGFzc3dvcmQgUmVzZXQgYW5kIFJJU0MgU2Vzc2lvbiBDYW5jZWwN CltyaWNoYW5uYV1TYW1lIGFzIGFib3ZlWy9yaWNoYW5uYV0NCjMuICBBIG5ldyBwcm9maWxlIGRl ZmluZXMgbmV3IGV2ZW50IGF0dHJpYnV0ZXMgdG8gYmUgYWRkZWQgb24gdG8gYW4gZXhpc3Rpbmcg ZXZlbnQgdHlwZSAoYSBwdXJlIGV4dGVuc2lvbikNCltyaWNoYW5uYV1JIGhhdmUgc3VnZ2VzdGVk IGEgd2F5IHRvIHN1cHBvcnQgZXh0ZW5zaW9ucyB3aXRoaW4gYW4gZXZlbnQgYm9keSwgbXVsdGlw bGUgdGltZXMgbm93LiBJZiB5b3Ugc2VlIHByb2JsZW1zIHdpdGggaXQsIHBsZWFzZSBwb2ludCB0 aGVtIG91dC5bL3JpY2hhbm5hXQ0KDQpJIHRoaW5rIGl0IGlzIHF1aXRlIHZhbGlkIHRvIGFsbG93 IDEgYW5kIDMuICAyIGNvdWxkIGJlIGxpbWl0ZWQgYnkgc3BlY2lmaWMgcHJvZmlsZXMgbGlrZSBS SVNDIGlmIHRoZXkgd2FudC4NCg0KSSBhbSBub3QgaW4gYWdyZWVtZW50IHRoYXQgbWFraW5nIGV2 ZW50IHNpbmd1bGFyIHNpbXBsaWZpZXMgYW55dGhpbmcuIEZvciBvbmUgaXMgbWFrZXMgZXh0ZW5z aW9ucyBjb21wbGV4IChhbm90aGVyIG5lc3RlZCBKU09OIHN0cnVjdHVyZSkgYW5kIHBvdGVudGlh bGx5IGNvbmZsaWN0aW5nLg0KW3JpY2hhbm5hXQ0KV2F5cyB0aGF0IG11bHRpcGxlLWV2ZW50IFNF VHMgYXJlIG1vcmUgY29tcGxpY2F0ZWQ6DQoNCiAgMS4gIEl0IHJlc3VsdHMgaW4gYSBtb3JlIGNv bXBsZXggc3RydWN0dXJlIGZvciB0aGUgc2luZ2xlIGV2ZW50IHVzZSBjYXNlLCB3aGljaCBJIHRo aW5rIHdlIGFsbCBhZ3JlZSBpcyB0aGUgbWFqb3JpdHkgdXNlIGNhc2UuDQogIDIuICBNdWx0aXBs ZS1ldmVudCBTRVRzIGhhdmUgYW1iaWd1b3VzIHNlbWFudGljcy4gVGhlIHByZXNlbmNlIG9mIHR3 byBldmVudHMgQSBhbmQgQiBpbiB0aGUgc2FtZSBTRVQgY291bGQgbWVhbiBhbnkgb2Y6DQoNCiAg ICAgKiAgIFRoZXkgYXJlIHJlbGF0ZWQgdG8gdGhlIHNhbWUgbG9naWNhbCBldmVudCAoaS5lLiB0 aGUgc2FtZSB0aGluZyBhcyBpZiB0aGV5IHdlcmUgZnJvbSBkaWZmZXJlbnQgU0VUcyB0aGF0IGhh dmUgYSBjb21tb24gdHhuKS4NCiAgICAgKiAgIEEgaXMgYW4gZXh0ZW5zaW9uIG9mIEIuDQogICAg ICogICBCIGlzIGFuIGV4dGVuc2lvbiBvZiBBLg0KICAgICAqICAgVGhleSBhcmUgYWxpYXNlcyBm b3Igb25lIGFub3RoZXIuDQogICAgICogICBUaGV5IGFyZSBub3QgYWN0dWFsbHkgcmVsYXRlZCB0 byBvbmUgYW5vdGhlciBpbiBhbnkgd2F5Lg0KDQogIDEuICBDbGFpbSBzZW1hbnRpY3MgYmVjb21l IGhhcmRlciB0byBkZWZpbmUsIGFzIGRpZmZlcmVudCBwcm9maWxlcyBtYXkgd2FudCB0byB1c2Ug dGhlIHNhbWUgY2xhaW1zIGluIGRpZmZlcmVudCB3YXlzLg0KDQpJZiB0aGUgV0cgd2FudHMgdG8g YmxvY2sgMSBhbmQgMiBhYm92ZSwgdGhlbiBJIGJlbGlldmUgd2UgaGF2ZSB0byBlc3RhYmxpc2gg YW4gZXZlbnQgcmVnaXN0cnkgdG8gZW5zdXJlIG5ldyBFdmVudCBwcm9maWxlcyBkbyBub3Qgb3Zl cmxhcCB0byBlbGltaW5hdGUgdGhlIG5lZWQgdG8gZXhwcmVzcyBtdWx0aXBsZSBldmVudHMuDQpb cmljaGFubmFdSeKAmW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSB0aGlzLiBBcmUgeW91IHJl ZmVycmluZyB0byBldmVudCBuYW1lcz8gVGhvc2UgYXJlIGFscmVhZHkgZGVmaW5lZCBieSB0aGUg c3BlYyB0byBiZSBVUklzLlsvcmljaGFubmFdDQpQaGlsDQoNCk9yYWNsZSBDb3Jwb3JhdGlvbiwg SWRlbnRpdHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0DQpAaW5kZXBlbmRlbnRpZA0Kd3d3Lmlu ZGVwZW5kZW50aWQuY29tPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5jb20mZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQ cHVZcVBrQUkxYUxjTE40S1pOQSZtPVUtYTVIQk5EMEhhVFg0YW5OWmZ6WDdwRHNmSzVmMGg5bVo5 Q1pra0dpZWMmcz1LQndLUEZucVlfUTk1Q1RBX19XR0NZR1R4ckQ3QUdDeHVlb1BYbktFVVQwJmU9 Pg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQpP biBPY3QgMjksIDIwMTcsIGF0IDQ6MTIgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwu Y29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpQaGlsOg0KDQpJbiB5 b3VyIGV4YW1wbGVzIGZvciBoYXZpbmcgYSBwbHVyYWxpdHkgb2YgZXZlbnRzLCB5b3UgdXNlIHRo ZSB3b3JkICJtYXkiLCB3aGljaCBsZWFkcyBtZSB0byBxdWVzdGlvbiBpZiBhIHBsdXJhbGl0eSBv ZiBldmVudHMgaXMgcmVhbGx5IHJlcXVpcmVkIGluIFNFVC4NCg0KWW91IHBvc2l0IHRoYXQgaXQg d2lsbCBiZSBkaWZmaWN1bHQgZm9yIGEgZGlzdHJpYnV0ZWQgc3lzdGVtIHRvIGNvcnJlbGF0ZSBt dWx0aXBsZSBTRVRzIHdpdGggdGhlIHNhbWUgInR4biIsIGJ1dCB0aGUgZGlzdHJpYnV0ZWQgc3lz dGVtIHdpbGwgY2VydGFpbmx5IG5lZWQgdG8gY29ycmVsYXRlIGV2ZW50cyBvbiB0aGUgc2FtZSBz dWJqZWN0IC0tIGNvcnJlbGF0aW5nIGV2ZW50cyBvbiB0aGUgc2FtZSAidHhuIiBvbiB0aGUgc2Ft ZSBzdWJqZWN0IHNlZW1zIGZhaXJseSBzaW1wbGUuDQoNCkkgdGhpbmsgdGhhdCBhIHJlY2VpdmVy IHdpbGwgbmVlZCB0byBjb3JyZWxhdGUgbXVsdGlwbGUgU0V0cyBvbiB0aGUgc2FtZSBzdWJqZWN0 LCBzbyBoYXZpbmcgbXVsdGlwbGUgZXZlbnRzIGluIGEgU0VUIGlzIHJlZHVuZGFudCwgYW5kIGFk ZHMgY29tcGxleGl0eSB3aXRoIG5vIGNsZWFyIGJlbmVmaXQgdGhhdCBJIGNhbiBzZWUuDQoNCkFu IGltcGxlbWVudG9yIG1heSBjaG9vc2UgdG8gc2VuZCBtdWx0aXBsZSBTRVRzLCBvciBzZW5kIGEg c2luZ2xlIFNFVCB3aXRoIG11bHRpcGxlIGV2ZW50cywgc28gYSByZWNlaXZlciB3aWxsIG5lZWQg dG8gc3VwcG9ydCBib3RoLiBJIHByZWZlciB3ZSBwaWNrIG9uZSB3YXkgYW5kIG1pbmltaXplIHRo ZSBjb2RlIHBhdGhzLCBhbmQgd2Ugd2lsbCBuZWVkIHRvIHN1cHBvcnQgY29ycmVsYXRpbmcgYWNy b3NzIG11bHRpcGxlIFNFVHMsIHNvIHRoYXQgc2VlbXMgdGhlIGJlc3QgbWVjaGFuaXNtLg0KDQpM ZXQgbWUga25vdyBpZiB0aGVyZSBpcyBzb21ldGhpbmcgSSBtaXNzZWQgaW4gbXkgbG9naWMuDQoN Ci9EaWNrDQoNCg0KT24gU3VuLCBPY3QgMjksIDIwMTcgYXQgMTE6MjggQU0sIFlhcm9uIFNoZWZm ZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4g d3JvdGU6DQpJbiB0aGF0IGNhc2UsIGxldCdzIGFkZCB0ZXh0IHRvIHRoYXQgZWZmZWN0LCBlLmcu IHdlIGNvdWxkIGFkZCB0byB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgImV2ZW50cyIgY2xhaW06DQoN ClByb2ZpbGluZyBzcGVjaWZpY2F0aW9ucyBTSE9VTEQgZGVmaW5lIHRoZSBhbGxvd2VkIGV2ZW50 IHN0YXRlbWVudHMsIGFuZCBNQVkgcmVzdHJpY3QgdGhlaXIgbnVtYmVyLiBGb3IgZXhhbXBsZSwg c29tZSBwcm9maWxlcyBtYXkgcmVxdWlyZSB0aGlzIGNsYWltIHRvIGNvbnRhaW4gb25seSBhIHNp bmdsZSBldmVudCBzdGF0ZW1lbnQuDQoNClRoYW5rcywNCiAgICAgICAgWWFyb24NCg0KT24gMjQv MTAvMTcgMjI6MTAsIE1pa2UgSm9uZXMgd3JvdGU6DQpJIGFncmVlIHdpdGggbXVjaCBvZiBQaGls 4oCZcyByYXRpb25hbGUgaGVyZS4NCg0KSXTigJlzIGZpbmUgZm9yIHNvbWUgcHJvZmlsZXMgdG8g c2F5IHRoYXQgdGhlIOKAnGV2ZW50c+KAnSBzZXQgbXVzdCBiZSBhIHNpbmdsZXRvbi4gIFRoYXQg ZG9lc27igJl0IGhhdmUgdG8gYmUgdHJ1ZSBmb3IgYWxsIGV2ZW50cy4gIEkgdGhpbmsgdGhpbmdz IGFyZSBmaW5lIGFzLWlzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KKkZyb206KiBJZC1ldmVudCBb bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNA aWV0Zi5vcmc+XSAqT24gQmVoYWxmIE9mICpQaGlsIEh1bnQNCipTZW50OiogTW9uZGF5LCBPY3Rv YmVyIDIzLCAyMDE3IDg6NDcgUE0NCipUbzoqIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxy aWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4NCipDYzoqIElE IEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBp ZXRmLm9yZz4+DQoqU3ViamVjdDoqIFJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlw bGUgZXZlbnRzIHBlciBTRVQ/DQoNCkFubmFiZWxsZSwNCg0KSSBoYXZlIGEgbnVtYmVyIG9mIGNv bmNlcm5zIHdpdGggdGhpcyBwcm9wb3NhbC4NCg0KUHJvZmlsaW5nIEluZGVwZW5kZW5jZSAvIEtl ZXBpbmcgRXZlbnQgUGF5bG9hZHMgSW5kZXBlbmRlbnQNCg0KSW5kaWNhdGluZyB0aGF0IGV4dGVu c2lvbnMgc2hvdWxkIGJlIGhhbmRsZWQgYnkgcHJvZmlsZXMgbGVhZHMgdG8gbW9yZSBpbnRlci1v cGVyYWJpbGl0eSBpc3N1ZXMgYW5kIG1vcmUgaW1wb3J0YW50bHkgaW50cnVkZXMgb24gdGhlIEV2 ZW50IHBheWxvYWQgc3BhY2UgYnkgc3VnZ2VzdGluZyBhIHN1Yi1zY2hlbWEgY3JlYXRlcyBwb3Rl bnRpYWwgbGltaXRhdGlvbnMgYW5kIGNvbmZsaWN0cyB0aGF0IG1heSBhZGQgdG8gY29tcGxleGl0 eSBsYXRlciBvbi4gVGhlIGN1cnJlbnQgZm9ybWF0IGFsbG93cyBhIHBhcnNlciB0byBkaXNjb3Zl ciBhbmQgdW5sb2FkIG9uZSBvciBtb3JlIEpTT04gcGF5bG9hZHMgd2hpY2ggY2FuIGVhY2ggaGF2 ZSBpbmRlcGVuZGVudCBzdHJ1Y3R1cmUuDQoNCkdlbmVyYWwgZXh0ZW5zaW9ucw0KDQpUaGUgcHJv cG9zYWwgYWxzbyBydWxlcyBvdXQgZ2VuZXJhbCBwdXJwb3NlIGV4dGVuc2lvbnMgbm90IHJlbGF0 ZWQgdG8gYW55IHNwZWNpZmljIGV2ZW50LiBHaXZlbiB0aGUgZW1lcmdlbmNlIG9mIGl0ZW1zIGxp a2UgR1BSRCwgSSB3b3VsZCBub3Qgd2FudCB0byBibG9jayB0aGUgYWJpbGl0eSB0byBhZGQgbWV0 YS1kYXRhIG9yIG90aGVyIGdlbmVyYWwgcHVycG9zZSBpdGVtcy4gV2UgY2FuIGFsc28gYW50aWNp cGF0ZSBzb21lIGRlbGl2ZXJ5IHNjZW5hcmlvcyB3aGVyZSBhZGRpdGlvbmFsIGRhdGEgbWlnaHQg YmUgcmVxdWlyZWQuIEV2ZW4gdGhvdWdoIHRoZXJlIGlzIG5vIGN1cnJlbnQgcGxhbm5lZCB1c2Us IEkgc2VlIG5vIGdvb2QgcmVhc29uIHRvIHJ1bGUgdGhpcyBvdXQuDQoNCk11bHRpcGxlIEV2ZW50 cyBGcm9tIERpZmZlcmVudCBGYW1pbGllcyAodnMuIE11bHRpcGxlIEV2ZW50cyBmcm9tIGEgc2lu Z2xlIGZhbWlseSBsaWtlIFJJU0MpDQoNCkluIG91ciBSSVNDIHNlc3Npb24gd2UgZGlzY3Vzc2Vk IGV4cHJlc3NpbmcgbXVsdGlwbGUgZGlzdGluY3QgUklTQyBldmVudHMgaW4gb25lIFNFVC4gVGhl IGRpc2N1c3Npb24gd2FzIHRoYXQgb25seSBvbmUgUklTQyBldmVudCBhdCBhIHRpbWUuIFdlIGRp ZCBub3QgZGlzY3VzcyBvdGhlciBldmVudCBwcm9maWxlcy4gSSBkb27igJl0IHNlZSBhIHJlYXNv biB0byBydWxlIG91dCBtdWx0aS1ldmVudHMgZnJvbSBkaWZmZXJlbnQgZmFtaWxpZXMgYXQgdGhl IFNFVCBsZXZlbC4gRWFjaCBwcm9maWxlIGlzIGV4cHJlc3Npbmcgc2xpZ2h0bHkgZGlmZmVyZW50 IHRoaW5ncyBhYm91dCB0aGUgc2FtZSBldmVudC4NCg0KSSBjYW4gZm9yc2VlIHNvbWUgY2FzZXMg d2hlcmUgaXQgaXMgbm90IGNsZWFyIHdoaWNoIGlzIHRoZSBwcmltYXJ5IGFuZCB3aGljaCBpcyB0 aGUgZXh0ZW5zaW9uLiAgVGhlcmUgbWF5IG5vdCBiZSBhIGNsZWFyIHdpbm5lci4NCg0KQSBjb3Vw bGUgb2YgZXhhbXBsZXMgKHRoZXNlIGFyZSBuZWNlc3NhcmlseSByZWFs4oCmanVzdCBwb3NzaWJp bGl0aWVzKToNCg0KKiBJdCBpcyBwcm9iYWJseSB1c2VmdWwgdG8gYmUgYWJsZSB0byBleHByZXNz IHNpbWxhci9vdmVybGFwcGluZyBldmVudHMgZnJvbSBkaWZmZXJlbnQgU0VUIHByb2ZpbGVzIGlu IG9uZSBTRVQuICBGb3IgZXhhbXBsZSBhIEJhY2tjaGFubmVsIExvZ291dCAmIGEgUklTQyBzZXNz aW9uIGNhbmNlbCBldmVudC4NCg0KKiBTQ0lNIG1heSB3YW50IHRvIHJlcHJlc2VudCBhIHNpbmds ZSB0cmFuc2FjdGlvbiBhcyBjYXVzaW5nIG11bHRpcGxlIHN0YXRlIGNoYW5nZXMgaW4gYW4gZXZl bnQgKGUuZy4gYSBwYXNzd29yZCBjaGFuZ2UgY2F1c2VzIG11bHRpcGxlIGVmZmVjdHMpLiBIYXZp bmcgdG8gY2hhc2UgZG93biBtdWx0aXBsZSBldmVudHMgYW5kIGNvcnJlbGF0ZSBieSDigJx0eG7i gJ0gd291bGQgYmUgY2hhbGxlbmdpbmcgaW4gYSBtdWx0aS10aHJlYWRlZC9tdWx0aS1ub2RlIGRl bGl2ZXJ5IHN5c3RlbS4gICBUaGUgU0NJTSBsaXN0IGhhcyBub3QgZGlzY3Vzc2VkIHRoaXMsIGJ1 dCBJIHdvdWxkIG5vdCB3YW50IHRvIGJsb2NrIHRoaXMgY2FwYWJpbGl0eS4gIElPVyAtIEp1c3Qg YmVjYXVzZSBSSVNDIGRvZXMgbm90IHdhbnQgdG8gZXhwcmVzcyBtdWx0aXBsZSBldmVudHMgZG9l cyBub3QgbWFrZSB0aGlzIHRydWUgZm9yIG90aGVyIHByb2ZpbGVzLg0KDQoqIFdlIG1heSB3aXNo IHRvIGluZGljYXRlIGEgU0NJTSBQYXNzd29yZCBSZXNldCB3YXMgcGVyZm9ybWVkIGFuZCBhIExv Z291dC9zZXNzaW9uIGNhbmNlbGxhdGlvbiBpcyBleHByZXNzZWQgYXQgdGhlIHNhbWUgdGltZS4g IFRoZSBldmVudHMgYXJlIHJlbGF0ZWQgYnV0IGV4cHJlc3MgZGlmZmVyZW50IGRhdGEuDQoNCkF2 b2lkaW5nIENvbmZ1c2lvbiBGcm9tIFNpbWlsYXIgRXZlbnRzIE9yaWdpbmF0aW5nIGZyb20gdGhl IFNhbWUgVHJhbnNhY3Rpb24NCg0KSWYgZXZlbnRzIGFyZSBzZW50IHNlcGFyYXRlbHksIHRoZW4g bW9yZSB0cmFja2luZyBvZiBzdGF0ZSAoZS5nLiBieSB0eG4pIHdvdWxkIGJlIHJlcXVpcmVkIHRv IGVuc3VyZSBzaW1pbGFyIGV2ZW50cyBhcmUgbm90IG1pc3Rha2VuIG9yIGhhbmRsZWQgYXMgcmVw ZWF0cy4gV2hpbGUgdHhuIHByb3ZpZGVzIHVzZWZ1bCBhdWRpdCBhbmFseXNpcyBjYXBhYmlsaXR5 LCBJ4oCZbSBub3Qgc3VyZSBpdCBjYW4gYmUgdXNlZCBpbiBsaXZlIG9yIG5lYXItcmVhbCB0aW1l IHN5c3RlbXMgZ2l2ZW4gZGlzdHJpYnV0ZWQgbXVsdGktbm9kZSwgbXVsdGktdGhyZWFkaW5nIGFy Y2hpdGVjdHVyZXMuDQoNClByZXZpb3VzIERpc2N1c3Npb24NCg0KSSBub3RlIHRoYXQgSSBvcmln aW5hbGx5IHJhaXNlZCBoYXZpbmcgYW4gYXR0cmlidXRlIHRvIGRlc2lnbmF0ZSBwcmltYXJ5IGV2 ZW50IGF0dHJpYnV0ZSB0byBhbGxldmlhdGUgeW91ciBjb25jZXJuLCBidXQgdGhpcyB3YXMgbm90 IGFjY2VwdGVkLiBTZWU6DQoNCiogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9pZC1ldmVudC9jdXJyZW50L21zZzAwNDA2Lmh0bWw8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbC0yRGFyY2hpdmVf d2ViX2lkLTJEZXZlbnRfY3VycmVudF9tc2cwMDQwNi5odG1sJmQ9RHdNRmFRJmM9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBj dHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWli OUtBVGtSbFFHMWl3JnM9UzNzTVZpcU12RWdud0diSndPUU55Y3JPeXI3U2VmcHFfTW9GT0tjRWVD RSZlPT4NCg0KKiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkLWV2ZW50 L2N1cnJlbnQvbXNnMDAxNDAuaHRtbDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfaWQtMkRl dmVudF9jdXJyZW50X21zZzAwMTQwLmh0bWwmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBr QUkxYUxjTE40S1pOQSZtPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcx aXcmcz1HeTlneVJvSUl0YS1jU2hWN2JOMTYxYXk0eUU2cjlHMV9BYV9OZUJueWxnJmU9Pg0KDQpU aGUgY29uc2Vuc3VzLCBhdCBsZWFzdCBhcyBJIGludGVycHJldGVkIGl0IGlzIHVwIHRvIHRoZSBy ZWNlaXZlciB0byBmaWd1cmUgdGhpcyBvdXQgYmFzZWQgb24gdGhlIGRlZmluaXRpb25zIGl0IGhh cyBmb3IgZWFjaCBldmVudCBVUkkgYW5kIHRoZSBwcm9maWxlcyB0aGV5IHJlcHJlc2VudC4gSU9X IC0gUklTQyBpcyBmcmVlIHRvIGxpbWl0IHRoYXQgb25seSBvbmUgUklTQyBldmVudCBiZSBleHBy ZXNzZWQgYXQgYSB0aW1lLg0KDQpQaGlsDQoNCk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkg Q2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0DQoNCkBpbmRlcGVuZGVudGlkDQoNCnd3dy5pbmRlcGVu ZGVudGlkLmNvbTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cC0zQV9fd3d3LmluZGVwZW5kZW50aWQuY29tJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZ UjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQ a0FJMWFMY0xONEtaTkEmbT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFH MWl3JnM9OU5QNW5hbWc2cklWend1bjljLTFxMHdoc3lYd1N2dEhCMGYyZEtrZkNYOCZlPT4gPGh0 dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNvbSZkPUR3TUZhUSZjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5x V055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFB dXh1cnVpYjlLQVRrUmxRRzFpdyZzPTlOUDVuYW1nNnJJVnp3dW45Yy0xcTB3aHN5WHdTdnRIQjBm MmRLa2ZDWDgmZT0+Pg0KDQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20+IDxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tPj4NCg0KICAgIE9uIE9jdCAyMywgMjAxNywgYXQgNzowMiBQTSwgUmljaGFyZCBC YWNrbWFuLCBBbm5hYmVsbGUNCiAgICA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFu bmFAYW1hem9uLmNvbT4gPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5u YUBhbWF6b24uY29tPj4+IHdyb3RlOg0KDQogICAgVGhlIGN1cnJlbnQgZHJhZnQgb2YgdGhlIFNF VCBzcGVjIGFsbG93cyBmb3IgZXhwcmVzc2luZyBtdWx0aXBsZQ0KICAgIGV2ZW50cyB3aXRoaW4g dGhlIHNhbWUgdG9rZW4sIHdoaWNoIGludHJvZHVjZXMgYWRkaXRpb25hbCBjb21wbGV4aXR5DQog ICAgYW5kIHJvb20gZm9yIGFtYmlndW91cyBzZW1hbnRpY3MuIFdl4oCZdmUgZGlzY3Vzc2VkIHRo aXMgaW4gdGhlIE9JREYNCiAgICBSSVNDIHdvcmtpbmcgZ3JvdXAgYW5kIHRoZSBjdXJyZW50IGNv bnNlbnN1cyB0aGVyZSBpcyB0aGF0IFJJU0Mgd2lsbA0KICAgIHJlcXVpcmUgdGhhdCBSSVNDIGV2 ZW50cyBtdXN0IGJlIHRoZSBvbmx5IGV2ZW50IGluIHRoZSBTRVQsIGhhdmluZw0KICAgIGlkZW50 aWZpZWQgd2F5cyB0byBjbGVhcmx5IGFuZCBlYXNpbHkgc3VwcG9ydCB0aGUgaGFuZGZ1bCBvZiB1 c2UNCiAgICBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciB0b2tlbiB0aGF0IHBlb3BsZSBo YXZlIHJhaXNlZC4gV2l0aA0KICAgIHRoYXQgY29udGV4dCBpbiBtaW5kLCBJIHByb3Bvc2Ugc3Ry aWtpbmcgdGhlIGRlZmluaXRpb24gb2YgdGhlDQogICAg4oCcZXZlbnRz4oCdIGNsYWltIGZyb20g dGhlIFNlY3VyaXR5IEV2ZW50IFRva2VuIHNwZWMsIGFuZCByZXBsYWNpbmcgaXQNCiAgICB3aXRo IHRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbiBmb3IgYW4g4oCcZXZlbnTigJ0gY2xhaW0gKHNpbmd1 bGFyKToNCg0KICAgIGV2ZW50DQoNCiAgICBBIEpTT04gb2JqZWN0IGNvbnRhaW5pbmcgYW4gImV2 ZW50X3R5cGUiIG1lbWJlciB3aG9zZSB2YWx1ZSBpcyBhIFVSSQ0KICAgIHJlcHJlc2VudGluZyBh IHR5cGUgb2YgZXZlbnQgZGVmaW5lZCBpbiBhIFByb2ZpbGluZyBTcGVjaWZpY2F0aW9uLg0KICAg IFRoZSBvYmplY3QgTUFZIG90aGVyd2lzZSBiZSBlbXB0eSwgb3IgTUFZIGNvbnRhaW4gYWRkaXRp b25hbCBtZW1iZXJzDQogICAgYXMgZGVzY3JpYmVkIGJ5IHRoZSBQcm9maWxpbmcgU3BlY2lmaWNh dGlvbi4NCg0KICAgIEhlcmUgaXMgdGhlIGV4YW1wbGUgU0VUIGZyb20gc2VjdGlvbiAyLjMsIHJl d3JpdHRlbiB3aXRoIHRoaXMgY2hhbmdlDQogICAgbWluZDoNCg0KICAgIHsNCg0KICAgICAgICJq dGkiOiAiNGQzNTU5ZWM2NzUwNGFhYmE2NWQ0MGIwMzYzZmFhZDgiLA0KDQogICAgICAgImlhdCI6 IDE0NTg0OTY0MDQsDQoNCiAgICAgICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPGh0 dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8+IDxodHRwczovL3NjaW0uZXhhbXBsZS5jb20vPiIsDQoN CiAgICAgICAiYXVkIjogWw0KDQogICAgICAgICAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0Zl ZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLA0KDQogICAgICAgICAiaHR0cHM6Ly9zY2lt LmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciDQoNCiAgICAgICBd LA0KDQogICAgICAgImV2ZW50Ijogew0KDQogICAgICAgICAiZXZlbnRfdHlwZSI6ICJ1cm46aWV0 ZjpwYXJhbXM6c2NpbTpldmVudDpjcmVhdGUiLA0KDQogICAgICAgICAicmVmIjogImh0dHBzOi8v c2NpbS5leGFtcGxlLmNvbS9Vc2Vycy80NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5IiwNCg0KICAg ICAgICAgImF0dHJpYnV0ZXMiOiBbImlkIiwgIm5hbWUiLCAidXNlck5hbWUiLCAicGFzc3dvcmQi LCAiZW1haWxzIl0NCg0KICAgICAgIH0NCg0KICAgIH0NCg0KICAgIERvZXMgYW55b25lIGluIHRo ZSB3b3JraW5nIGdyb3VwIGhhdmUgdXNlIGNhc2VzIGZvciBTRVRzIHRoYXQgY2Fubm90DQogICAg YmUgbWV0IGJ5IHRoaXMgcHJvcG9zZWQgdGV4dD8gV2l0aGluIFJJU0MsIHdlIGlkZW50aWZpZWQg dGhyZWUgdXNlDQogICAgY2FzZXMsIHdpdGggc29sdXRpb25zIG91dGxpbmVkIGJlbG93Og0KDQog ICAgKioNCg0KICAgICpFeHRlbnNpb25zKg0KDQogICAgRXZlbnQgZXh0ZW5zaW9uIG1lY2hhbmlz bXMgY2FuIGJlIGRlZmluZWQgaW50ZXJuYWwgdG8gdGhlIGV2ZW50DQogICAgb2JqZWN0LiBBIHNp bXBsZSBhcHByb2FjaCB3b3VsZCBiZSB0byAgZGVmaW5lIGFuIOKAnGV4dGVuc2lvbnPigJ0gbWVt YmVyDQogICAgdGhhdCBpcyBhIGxpc3Qgb2YgZXZlbnQgb2JqZWN0cyAob3Igc2V0IHJlc2VtYmxp bmcgdGhlIOKAnGV2ZW50c+KAnQ0KICAgIGNsYWltIGFzIGRlZmluZWQgaW4gdGhlIGN1cnJlbnQg c3BlYykuIFRoaXMgaGFzIHRoZSBhZHZhbnRhZ2Ugb2YNCiAgICBtYWtpbmcgaXQgY2xlYXIgaW4g dGhlIGRhdGEgc3RydWN0dXJlIHRoYXQgdGhlcmUgaXMgYSBzaW5nbGUgcHJpbWFyeQ0KICAgIGV2 ZW50LCB3aXRoIHplcm8gb3IgbW9yZSBleHRlbnNpb25zLiBUaGVyZSBpcyBubyByb29tIGZvciBj b25mdXNpb24NCiAgICBvdmVyIHdoaWNoIGV2ZW50IGlzIHByaW1hcnksIG9yIGlmIHRoZXJlIGlz IGEgcHJpbWFyeSBldmVudCBhdCBhbGwuDQogICAgSSB3b3VsZCBiZSBmaW5lIHdpdGggYWRkaW5n IHNvbWV0aGluZyBsaWtlIHRoaXMgdG8gbXkgcHJvcG9zZWQgdGV4dCwNCiAgICBpZiB0aGVyZSBp cyBjb25zZW5zdXMgdGhhdCBpdCBpcyBicm9hZGx5IHVzZWZ1bC4NCg0KICAgICpBbGlhc2VzKg0K DQogICAgVGhpcyB1c2UgY2FzZSB3YXMgYnJvdWdodCB1cCBpbiB0aGUgY29udGV4dCBvZiBtaWdy YXRpbmcgY2xpZW50cw0KICAgIGZyb20gZHJhZnQgZXZlbnQgbmFtZXMgdG8gc3RhbmRhcmRpemVk IGV2ZW50IG5hbWVzLiBJbiB0aGlzIGNhc2UsDQogICAgdGhlIGV2ZW50IHRyYW5zbWl0dGVyIGNh biB0cmFuc21pdCB0d28gdG9rZW5zIGZvciB0aGUgbG9naWNhbCBldmVudCwNCiAgICBvbmUgdXNp bmcgdGhlIG9sZCBuYW1lIGFuZCBhbm90aGVyIHVzaW5nIHRoZSBuZXcgbmFtZS4NCg0KICAgICpS ZWxhdGVkIEV2ZW50cyoNCg0KICAgIFRoZSBTRVQgc3BlYyBkZWZpbmVzIHRoZSB0eG4gY2xhaW0g YXMgYSBtZWFucyBvZiBjb3JyZWxhdGluZw0KICAgIGluZGVwZW5kZW50IHRva2VucyB0aGF0IHJl bGF0ZSB0byB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50Lg0KDQogICAgLS0NCiAgICBBbm5hYmVsbGUg UmljaGFyZCBCYWNrbWFuDQoNCiAgICBBbWF6b24g4oCTIElkZW50aXR5IFNlcnZpY2VzDQoNCiAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIElk LWV2ZW50IG1haWxpbmcgbGlzdA0KICAgIElkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZz4gPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0 Zi5vcmc+Pg0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNB ZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlS ckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09czVieUJlNUtBTm5HVnVBYjFt QXVwRUdvSm44WEc1SklVVXdXR0ZTaWJFYyZzPVg4b1JTcTNJemxGN2ppUkFlWmhYcFIzZVZJMEk1 OFpGZDRlRVpmZ3lvSVkmZT0NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3Jn PG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9 RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5h NUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1ZQkNHbEs5bWpqaGNG c2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JnM9V3JNdVFSd0xWODAyaU1RNHdZQjFmMnJG VUd1NHpiaGNXMDAxZkswMkVYcyZlPT4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5v cmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZC1ldmVudDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQm ZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9 bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPVlCQ0dsSzltampo Y0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmcz1Xck11UVJ3TFY4MDJpTVE0d1lCMWYy ckZVR3U0emJoY1cwMDFmSzAyRVhzJmU9Pg0KDQoNCg0KLS0NClN1YnNjcmliZSB0byB0aGUgSEFS RFRXQVJFPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNB X19oYXJkdHdhcmUuY29tXyZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJ ck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRL Wk5BJm09WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZzPUxZTjcy R2dLVmhIc1Q2dEFxQmUtZU1vV012eV83ZGZGbjF1WjBISzZZdVEmZT0+IG1haWwgbGlzdCB0byBs ZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1l dmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu X2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhC djdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxj TE40S1pOQSZtPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmcz1X ck11UVJ3TFY4MDJpTVE0d1lCMWYyckZVR3U0emJoY1cwMDFmSzAyRVhzJmU9DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5n IGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBw dVlxUGtBSTFhTGNMTjRLWk5BJm09VS1hNUhCTkQwSGFUWDRhbk5aZnpYN3BEc2ZLNWYwaDltWjlD WmtrR2llYyZzPXJ2ZHJ0STdyWU5SQW5xWkRsdEN3QkFaVkhLcC1NSjIwdWkybm00NlFTejAmZT0N Cg0KDQoNCg0KLS0NClN1YnNjcmliZSB0byB0aGUgSEFSRFRXQVJFPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZkPUR3TUZh USZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpC VFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09aXlWbnJabXI5X3VHQ1E2TUQw ekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZzPXd0Z0QzTnAwdnloTGRwRXdVaXFzZjRJdGl3QTNP bTdHcm9iNzBMeDByM2smZT0+IG1haWwgbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFt IHdvcmtpbmcgb24hDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQt ZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1E d0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1 RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPWl5Vm5yWm1yOV91R0NR Nk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmcz1PZTBxZkxFWDgzdnRYTTdXbDJjWUJlLUdn MURWUGpoWGpWSmtmaFZSendjJmU9DQoNCg0KDQotLQ0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdB UkU8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hh cmR0d2FyZS5jb21fJmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVC NjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEm bT1zSUd6OGd1cjR3TnFaa3RjbWFndjVFYTIxUUVpcDRIWHBFVktSYTBxaGxvJnM9VjlneVRUWDlx dWpyQzJWbGl3TFB5MC1LdnhTOXBZS0pfLWt5RGFwd084ayZlPT4gbWFpbCBsaXN0IHRvIGxlYXJu IGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCg0KDQoNCi0tDQpTdWJzY3JpYmUgdG8g dGhlIEhBUkRUV0FSRTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBa aDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkx YUxjTE40S1pOQSZtPXNJR3o4Z3VyNHdOcVprdGNtYWd2NUVhMjFRRWlwNEhYcEVWS1JhMHFobG8m cz1WOWd5VFRYOXF1anJDMlZsaXdMUHkwLUt2eFM5cFlLSl8ta3lEYXB3TzhrJmU9PiBtYWlsIGxp c3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0KDQoNCg0KLS0NClN1 YnNjcmliZSB0byB0aGUgSEFSRFRXQVJFPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZkPUR3TUdhUSZjPVJvUDFZdW1DWENn YVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5 WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09c0lHejhndXI0d05xWmt0Y21hZ3Y1RWEyMVFFaXA0SFhw RVZLUmEwcWhsbyZzPVY5Z3lUVFg5cXVqckMyVmxpd0xQeTAtS3Z4UzlwWUtKXy1reURhcHdPOGsm ZT0+IG1haWwgbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQg bWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+ DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lDQWcmYz1Sb1AxWXVt Q1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTRE cGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPXNJR3o4Z3VyNHdOcVprdGNtYWd2NUVhMjFRRWlw NEhYcEVWS1JhMHFobG8mcz1nZE5yczdVREF0dHBhYmpNNW5kT1h3V0ttWnVLYVhFYlQ1d3U5cmNP UlYwJmU9DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2 ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1l dmVudA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZl bnQNCg0KDQoNCg== --_000_07169FA765424EBB987F5D39190B214Aamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCXBh bm9zZS0xOjIgNyAzIDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi Q2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseToiQ291cmllciIsc2VyaWY7fQ0Kc3Bhbi5tNjMzNzQ0MDg5NjE1MzI3OTgzNG0tMzE1 MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBh cHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOm1fNjMzNzQ0MDg5NjE1MzI3OTgzNG1f LTMxNTE0NDU5NTg0NTEwMjkzMThtXzc0NzYzNDY5NDY5NTY4MzMwMDRtXzU2ODM0MDI5Mzc3ODE1 NjEwODBhcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4ubTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0 NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBw bGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOm1fNjMzNzQ0MDg5NjE1MzI3OTgz NG1fLTMxNTE0NDU5NTg0NTEwMjkzMThtXzc0NzYzNDY5NDY5NTY4MzMwMDRtXzU2ODM0MDI5Mzc3 ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5tNjMzNzQ0MDg5NjE1MzI3OTgz NG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1 NjEwODBtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4 MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21z by1zdHlsZS1uYW1lOm1fNjMzNzQ0MDg5NjE1MzI3OTgzNG1fLTMxNTE0NDU5NTg0NTEwMjkzMTht Xzc0NzYzNDY5NDY5NTY4MzMwMDRtXzU2ODM0MDI5Mzc3ODE1NjEwODBtLTQzNzc3ODc3NTU4NzMy MDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2 MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4ubTYzMzc0NDA4OTYxNTMyNzk4 MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNGhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTptXzYzMzc0NDA4OTYxNTMyNzk4MzRtXy0zMTUxNDQ1OTU4NDUxMDI5MzE4bV83 NDc2MzQ2OTQ2OTU2ODMzMDA0aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIyNDQ0NjcwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMjc1MDkzMTU4O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMQ0KCXttc28tbGlzdC1pZDo2NTI3NDU2MTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTEzNDE4NTIxNjY7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDozOw0K CW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTY0NTYy MzA0ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4NjU4NjUwNjt9DQpAbGlzdCBsMjpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MjA5OTcxNzIzNjsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6MTAyOTc1NjY5NDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkg Ymdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGFu YWxvZ3kgaXMgZnVuZGFtZW50YWxseSBmbGF3ZWQuIFdpdGggZW1haWwsIGJvdGggdGhlIHRleHQg YW5kIEhUTUwgYm9kaWVzIGFyZSBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zIG9mIHRoZSBleGFj dCBzYW1lIG1lc3NhZ2UsIHdpdGggdGhlIGV4YWN0IHNhbWUgc2VtYW50aWNzLiBBIHJlYWRlciBp cyBnZW5lcmFsbHkgYXNzdW1lZCB0byBpbnRlcnByZXQgYW5kIHJlYWN0IHRvIGEgbWVzc2FnZSB0 aGUNCiBzYW1lIHdheSwgd2hldGhlciB0aGV5IHJlYWQgaXQgaW4gdGV4dCBvciBIVE1MLiBUaGlz IGlzIG5vdCB0aGUgY2FzZSBmb3IgdGhlIGV2ZW50cyB3aXRoaW4gU0VUcy4gVGhlIE9JREMgQmFj a2NoYW5uZWwgTG9nb3V0IGV2ZW50LCBhIFNDSU0gTG9nb3V0IGV2ZW50LCBhbmQgYSBoeXBvdGhl dGljYWwgUklTQyBMb2dvdXQgZXZlbnQgYWxsIGNvbnZleSBkaWZmZXJlbnQgaW5mb3JtYXRpb24g YW5kIGFyZSBzZW50IHVuZGVyIGRpZmZlcmVudCBjaXJjdW1zdGFuY2VzLA0KIGFuZCBpdCBpcyBl eHBlY3RlZCB0aGF0IHJlY2VpdmVycyBtYXkgcmVhY3QgZGlmZmVyZW50bHkgdG8gZWFjaCBldmVu dC4gVGhleSBtYXkgZXZlbiBiZSByZWNlaXZlZCBieSBkaWZmZXJlbnQgZW5kcG9pbnRzIOKAkyBz b21lIGdvaW5nIHRvIHRoZSByZWNlaXZlcuKAmXMgc2Vzc2lvbiBtYW5hZ2VtZW50IHN5c3RlbSB3 aGlsZSBvdGhlcnMgZ28gdG8gdGhlaXIgcmlzayBtYW5hZ2VtZW50IHN5c3RlbSAod2hpY2ggY291 bGQgZXZlbiBiZSBhIHRoaXJkIHBhcnR5KS4NCiBTaW5jZSBlYWNoIGV2ZW50IHR5cGUgY29udGFp bnMgZGlmZmVyZW50IGluZm9ybWF0aW9uLCBpdCBtYXkgZXZlbiBiZSBpbXBvcnRhbnQgZnJvbSBh IGRhdGEgZXhwb3N1cmUgc3RhbmRwb2ludCB0byB0aGUgcmVjZWl2ZXIgdGhhdCB0aGVzZSBldmVu dHMgbm90IGFsbCBwYXNzIHRocm91Z2ggdGhlIHNhbWUgc3lzdGVtcyBvbiB0aGVpciBzaWRlLCBv ciBmb3IgdGhlIHJlY2VpdmVyIHRvIG9ubHkgcmVjZWl2ZSBvbmUgb2YgdGhvc2UgdHlwZXMgb2YN CiBldmVudHMsIGFuZCBub3QgdGhlIG90aGVyLiBUaGlzIGlzIHRoZSBjYXNlIGZvciBBbWF6b247 IHdlIHdhbnQgUklTQyBldmVudHMsIGFuZCBubyBvdGhlcnM7IHdlIGRvbuKAmXQgd2FudCB0byBy ZWNlaXZlIGFueSBtb3JlIGluZm9ybWF0aW9uIGZyb20gdHJhbnNtaXR0ZXJzIHRoYW4gaXMgbmVj ZXNzYXJ5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm Ij4tLSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+SWRlbnRp dHkgU2VydmljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJv bTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ SWQtZXZlbnQgJmx0O2lkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBX aWxsaWFtIERlbm5pc3MgJmx0O3dkZW5uaXNzQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPldlZG5lc2RheSwgTm92ZW1iZXIgMSwgMjAxNyBhdCAzOjAyIFBNPGJyPg0KPGI+VG86IDwv Yj5NYXJpdXMgU2N1cnRlc2N1ICZsdDttc2N1cnRlc2N1QGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+ Q2M6IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFu bmFAYW1hem9uLmNvbSZndDssIFlhcm9uIFNoZWZmZXIgJmx0O3lhcm9uZi5pZXRmQGdtYWlsLmNv bSZndDssIE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDssIFBo aWwgSHVudCAmbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7LCBJRCBFdmVudHMgTWFpbGluZyBM aXN0ICZsdDtpZC1ldmVudEBpZXRmLm9yZyZndDssIERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRA Z21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0lkLWV2ZW50XSBVc2UgY2Fz ZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJlY2VpdmVyIHByb2JhYmx5 IGtub3dzIHdoaWNoIHZlcnNpb24gdGhleSB3YW50LCBidXQgZG9lcyB0aGUgc2VuZGVyPyBVc2lu ZyB0aGUgZW1haWwgYW5hbG9neSwgeW91IG1heSBoYXZlIGNvbmZpZ3VyZWQgeW91ciBlbWFpbCBj bGllbnQgdG8gYWNjZXB0IHBsYWluIHRleHQgb25seS4gRm9ydHVuYXRlbHksIG15IGNsaWVudCBz ZW5kcyBib3RoIOKAkyBub3Qga25vd2luZyB3aGF0IHlvdSBwcmVmZXIg4oCTIGFuZA0KIHlvdSBh cmUgYWJsZSB0byB2aWV3IG15IG1lc3NhZ2UuIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBpdCB3b3VsZCBoZWxwIGlmIHdlIGJyb2tlIHRoaXMg cHJvYmxlbSBkb3duIGludG8gdHdvIHBhcnRzLiAxLyBBcmUgbXVsdGktZm9ybWF0IFNFVHMgZGVz aXJhYmxlPyBUaGF0J3MgYmVlbiB0aGUgZGVzaWduIHNpbmNlIHRoZSBlYXJsaWVzdCB2ZXJzaW9u LiAyLyBXaGF0IGlzIHRoZSBiZXN0IHJlcHJlc2VudGF0aW9uIG9mIHRoZSBTRVQgYmFzZWQgb24g d2hhdCB3ZSBkZWNpZGUgZm9yICMxLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IHRoZSAmcXVvdDtl dmVudHMmcXVvdDsgcGx1cmFsIChyZWxhdGVkIHRvICMyLCB0aGUgYmVzdCByZXByZXNlbnRhdGlv biBvZiBhIFNFVCkNCjxpPndhczwvaT4gaW4gZmFjdCZuYnNwO2EgY29uY2VybiwgYXMgcGVvcGxl IG1heSBza2lwIHRoZSB0ZXh0IGFuZCBsb29rIGRpcmVjdGx5IGF0IHRoZSBKU09OIHN5bnRheCwg dGhlbiBqdW1wIHRvIGNvbmNsdXNpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gV2VkLCBOb3YgMSwgMjAxNyBhdCAyOjU0IFBNLCBNYXJpdXMgU2N1 cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gV2VkLCBOb3YgMSwgMjAxNyBhdCAyOjQ2IFBNLCBXaWxsaWFtIERlbm5pc3MgJmx0Ozxh IGhyZWY9Im1haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2Rlbm5p c3NAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXJoYXBzIEkgY2FuIHRyeSBhbmQgZXhwbGFp biB0aGUgb3JpZ2luYWwgaW50ZW50IG9mIHRoZSBjdXJyZW50IGRlc2lnbi4gVGhlIGdvYWwgd2Fz IGFsd2F5cyB0aGF0IGEgU0VUIHJlcHJlc2VudHMgYSBzaW5nbGUgbG9naWNhbCBldmVudC4gSG93 ZXZlciBtdWx0aXBsZSBzeXN0ZW1zIG1heSBoYXZlIGRpZmZlcmVudCByZXByZXNlbnRhdGlvbnMg b2YgdGhlIGV2ZW50IOKAkyB0aGUgZXhhbXBsZSBnaXZlbiBvcmlnaW5hbGx5DQogd2FzIG9uZSBm b3JtYXR0ZWQgZm9yIFJJU0MsIGFuZCBvbmUgZm9yIFNDSU0uIDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBnb29kIGFuYWxvZ3kgaXMgZW1haWwuIFlvdSBz ZW5kIGEgc2luZ2xlIGxvZ2ljYWwgZW1haWwsIHdoaWNoIG1heSBoYXZlIHR3byByZXByZXNlbnRh dGlvbnMsIEhUTUwgYW5kIHBsYWluIHRleHQuIFN5c3RlbXMgY2FuIGNvbnN1bWUgdGhlIHZlcnNp b24gdGhhdCB0aGV5IHVuZGVyc3RhbmQgYW5kIGlnbm9yZSB0aGUgb25lIHRoZXkgZG9uJ3QuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBhbmQgSSB0aGluayB0aGlzIGlzIHdlbGwgdW5kZXJzdG9v ZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIHN0YXJ0aW5nIHRvIHJlZ3JldCB0aGUgcGx1cmFs IGluICZxdW90O2V2ZW50cyZxdW90OywgaXQgd2FzIHBsdXJhbGl6ZWQgZHVlIHRvIGl0IGJlaW5n IGFuIGFycmF5LCBub3QgYmVjYXVzZSBpdCByZXByZXNlbnRlZCBtdWx0aXBsZSBsb2dpY2FsIGV2 ZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0IHRoaW5rIHRoaXMgaXMgdGhlIG1haW4g Y29uY2VybiBvciBjYXVzZSBmb3IgY29uZnVzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbm5h YmVsbGUsIEkgdW5kZXJzdGFuZCB5b3VyIGNvbmNlcm5zIHJlZ2FyZGluZyBjb25mdXNpb24gb2Yg dGhlIHNlbWFudGljcyBiZXR3ZWVuIHRoZSBKU09OIHN5bnRheCBhbmQgdGhlIHNwZWNpZmljYXRp b24gbGFuZ3VhZ2UuIEFyZSB0aGVyZSBvdGhlciB3YXlzIHRvIHJlc29sdmUgdGhhdCB3aXRob3V0 IHJlbW92aW5nIHRoZSBhYmlsaXR5IGZvciBtdWx0aXBsZSByZXByZXNlbnRhdGlvbnMgb2YgdGhl IHNhbWUNCiBldmVudD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYXJndW1lbnQgaXMgdGhhdCBt dWx0aXBsZSByZXByZXNlbnRhdGlvbnMgY2FuIGJlIHNlbnQgYXMgZGlzdGluY3QgU0VUcywgaWYg cmVhbGx5IG5lZWRlZC4gSW4gcHJhY3RpY2UgdGhpcyB3aWxsIGhhcHBlbiBxdWl0ZSByYXJlIHRo b3VnaC4gRXZlbnRzIGFyZSBjcmVhdGVkIGZvciBhIHNwZWNpZmljIHJlY2VpdmVyLCB0aGUgcmVj ZWl2ZXIgZWl0aGVyIHdhbnRzIHRoZSBTQ0lNIG9yIHRoZSBSSVNDIGZsYXZvciwNCiBhbmQgdGhl eSBzaG91bGQgYmUgYWJsZSB0byBzcGVjaWZ5IHRoYXQgaW4gY29uZmlndXJhdGlvbiAodGhlcmUg aXMgYSBwcm9wb3NhbCBob3cgdG8gY2FwdHVyZSB0aGF0KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8gd2UgaGF2ZSBhIGNvbXBlbGxpbmcg dXNlIGNhc2Ugd2hlcmUgYSByZWNlaXZlciBtdXN0IHJlY2VpdmUgbXVsdGlwbGUgdmFyaWFudHMg YWxsIGF0IG9uY2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTm92IDEsIDIwMTcgYXQgMjozNyBQTSwgTWFyaXVz IFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFdlZCwgTm92IDEsIDIwMTcgYXQgMTI6NDUgUE0sIFBoaWwgSHVudCAmbHQ7PGEg aHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5o dW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGNhbuKAmXQgcmVhbGx5IGhhdmUgbXVs dGlwbGUgZXZlbnRzIChhdCBsZWFzdCBvZiB0aGUgc2FtZSB0eXBlKS4mbmJzcDsgVGhlIGN1cnJl bnQgc3BlYyBjYW4gb25seSBoYXZlIG9uZSBpbnN0YW5jZSBvZiBhIFVSSSAoYWZhaWspLiAmbmJz cDsNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90ZSB0 aGF0IHRoZSBzcGVjIG5vcm1hdGl2ZWx5IGRvZXMgbm90IHN1cHBvcnQgbXVsdGlwbGUgZXZlbnQg U0VUUy4mbmJzcDsgSXQgY3VycmVudGx5IHN0YXRlczoNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHByZT5ldmVudHM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPGI+VGhlIHNlbWFudGljcyBvZiB0aGlzIGNsYWltIGlzIHRvIGRlZmluZSBh IHNldCBvZiBldmVudCBzdGF0ZW1lbnRzPG86cD48L286cD48L2I+PC9wcmU+DQo8cHJlPjxiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGF0IGVhY2ggTUFZIGFkZCBhZGRpdGlvbmFs IGNsYWltcyB0byBmdWxseSBkZXNjcmliZSBhIHNpbmdsZTxvOnA+PC9vOnA+PC9iPjwvcHJlPg0K PHByZT48Yj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbG9naWNhbCBldmVudDwvYj4g dGhhdCBoYXMgb2NjdXJyZWQgKGUuZy4gYSBzdGF0ZSBjaGFuZ2UgdG8gYTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdWJqZWN0KS4mbmJzcDsg TXVsdGlwbGUgZXZlbnQgc3RhdGVtZW50cyBvZiB0aGUgc2FtZSB0eXBlIFNIQUxMIE5PVCBiZTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhY2Nl cHRlZC4mbmJzcDsgVGhlICZxdW90O2V2ZW50cyZxdW90OyBjbGFpbSBTSE9VTEQgTk9UIGJlIHVz ZWQgdG8gZXhwcmVzczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBtdWx0aXBsZSBsb2dpY2FsIGV2ZW50cy48bzpwPjwvbzpwPjwvcHJlPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNwZWMgaGFzICph bHdheXMqIHN1cHBvcnRlZCByZXF1aXJlbWVudHMgKGFzIHN0YXRlZCBpbiB0aGUgc3BlYykgZm9y IG11bHRpcGxlIHNlcGFyYXRlIHByb2ZpbGUgc3RhdGVtZW50cyAoZnJvbSBvbmUgb3IgbW9yZSBw cm9maWxlIGZhbWlsaXRpZXMpIG5lZWRpbmcgdG8gYmUgc2VudCBhcyBhIHNpbmdsZSBtZXNzYWdl LiZuYnNwOyBJdCB3b3VsZCBiZSBJTlNFQ1VSRSB0byBmb3JjZSBtdWx0aXBsZSBTRVRzIGJlY2F1 c2UNCiB0aGUgY3VycmVudCBkZWxpdmVyeSBtZWNoYW5pc20gb25seSBhbGxvd3Mgb25lIFNFVCB0 byBiZSBkZWxpdmVyZWQgYXQgYSB0aW1lLiBUaGVyZSBpcyBubyB3YXkgdG8gYXNzdXJlIHRoYXQg YSBzaW5nbGUgcmVjZWl2ZXIgZ2V0cyBhbGwgb2YgdGhlIFNFVHMgaXQgbmVlZHMgaW4gYSBtdWx0 aS10aHJlYWRlZCwgbXVsdGktbm9kZSBlbnZpcm9ubWVudCBhdCBzY2FsZS4mbmJzcDsgQXNzZW1i bGluZyBtdWx0aXBsZSBTRVRzIHRvIHRyYWNrIOKAnHR4buKAnSBpbiBhDQogY29tbW9uIHN0YXRl IGRhdGFiYXNlIGlzIE5PVCBzaW1wbGUgbm9yIGNvc3QgZWZmZWN0aXZlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRvdGFsbHkgYWdyZWUgdGhhdCBpdCBpcyBkaWZmaWN1 bHQgZm9yIHJlY2VpdmVycyB0byByZWNlaXZlIHNlcGFyYXRlIGV2ZW50cywgaW4gbm8gcGFydGlj dWxhciBvcmRlciBhbmQgY29ycmVsYXRlIGJhc2VkIG9uICZxdW90O3R4biZxdW90Oy4gQnV0LCBy ZWNlaXZlcnMgaGF2ZSB0byBzb2x2ZSB0aGlzIGlzc3VlIHJlZ2FyZGxlc3Mgb2YgJnF1b3Q7ZXZl bnRzJnF1b3Q7IG9yICZxdW90O2V2ZW50JnF1b3Q7LCBzbyBpdCBpcyB1bnJlbGF0ZWQgdG8gdGhp cyBwcm9wb3NhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSBhY2Nv bW1vZGF0ZSB0aGlzIGluIHRoZSBwcm9wb3NlZCBmb3JtLCB3ZSBlbmQgdXAgd2l0aCBhIGNvbXBs ZXgsIGRlZXBseSBuZXN0ZWQgSlNPTiBzdHJ1Y3R1cmUgd2l0aCB0aGUgcG9zc2liaWxpdHkgb2Yg bmFtZXNwYWNlIGNvbmZsaWN0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SU1PIFRoZSBwcm9wb3NhbCBkb2VzIG5vdCBzaW1wbGlmeSwgaXQg Y29tcGxpY2F0aW5nIGFuZCBsaW1pdGluZy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjdXJyZW50IHNwZWMgaGFzIHZlcnkg Y2xlYW4gSlNPTiBhbmQgYXZvaWRzIG5hbWVzcGFjZSBjb25mbGljdHMgYmV0d2VlbiBwcm9maWxl cy4gSSB0aGluayB3ZSBzaG91bGQgc3RheSBvbiB0cmFjayB3aXRoIHRoZSBjdXJyZW50IGRyYWZ0 IGFuZCBvYnNlcnZlIHRoZSBub3JtYXRpdmUgdGV4dCBpZiBub3QgbWFrZSBpdCBzdHJvbmdlciBp biByZWdhcmRzIHRvIG11bHRpLWV2ZW50cyAodW5kZXJzdG9vZCB0aGF0DQogTWlrZSBtYXkgZGlz YWdyZWUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5QaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5PcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2Vz IEFyY2hpdGVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRp ZC5jb20iIHRhcmdldD0iX2JsYW5rIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTm92IDEsIDIwMTcsIGF0 IDEyOjE4IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYUBhbWF6b24uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlVubGVzcyB0aGUgcHJvZmlsZSBn dWFyYW50ZWVzIHRoYXQgc3VjaCByZWxhdGVkIGV2ZW50cyB3aWxsIGFsd2F5cyBiZSBpbmNsdWRl ZCBpbiB0aGUgc2FtZSBTRVQsIHRoZW4gdGhlIHJlY2VpdmVyIGhhcyB0byBjb3JyZWxhdGUgYWNy b3NzIFNFVHMgYW55d2F5LCBhbmQgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQgaXMganVzdCBnaXZp bmcgdGhlIHJlY2VpdmVyIGFub3RoZXINCiBzY2VuYXJpbyB0aGF0IHRoZXkgaGF2ZSB0byBzdXBw b3J0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPknigJl2 ZSBhbHJlYWR5IHByb3ZpZGVkIHNldmVyYWwgb3RoZXIgcmVhc29ucyB3aHkgd2Ugc2hvdWxkIG5v dCBzdXBwb3J0IG11bHRpcGxlIHRva2VucyBwZXIgU0VUIHRoYXQgbm8gb25lIGhhcyBhZGRyZXNz ZWQuIEhlcmUgdGhleSBhcmUgYWdhaW46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxvbCBzdHls ZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm8xO2JhY2tn cm91bmQ6d2hpdGUiPg0KTXVsdGlwbGUgZXZlbnQgc3VwcG9ydCByZXN1bHRzIGluIGEgbW9yZSBj b21wbGV4IHN0cnVjdHVyZSBmb3IgdGhlIHNpbmdsZSBldmVudCB1c2UgY2FzZSwgd2hpY2ggSSB0 aGluayB3ZSBhbGwgYWdyZWUgaXMgdGhlIG1ham9yaXR5IHVzZSBjYXNlLjxvOnA+PC9vOnA+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MiBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4NCk11bHRpcGxlLWV2ZW50IFNFVHMgaGF2 ZSBhbWJpZ3VvdXMgc2VtYW50aWNzLiBUaGUgcHJlc2VuY2Ugb2YgdHdvIGV2ZW50cyBBIGFuZCBC IGluIHRoZSBzYW1lIFNFVCBjb3VsZCBtZWFuIGFueSBvZjoNCjxvOnA+PC9vOnA+PC9saT48L29s Pg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjIiIHR5cGU9IjEiPg0KPG9sIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzE7YmFj a2dyb3VuZDp3aGl0ZSI+DQpBIGFuZCBCIGFyZSByZWxhdGVkIHRvIHRoZSBzYW1lIGxvZ2ljYWwg ZXZlbnQgKGkuZS4gdGhlIHNhbWUgdGhpbmcgYXMgaWYgdGhleSB3ZXJlIGZyb20gZGlmZmVyZW50 IFNFVHMgdGhhdCBoYXZlIGEgY29tbW9uIHR4bikuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMiBsZm8x O2JhY2tncm91bmQ6d2hpdGUiPg0KQSBpcyBhbiBleHRlbnNpb24gb2YgQi48bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6 bDIgbGV2ZWwyIGxmbzE7YmFja2dyb3VuZDp3aGl0ZSI+DQpCIGlzIGFuIGV4dGVuc2lvbiBvZiBB LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMiBsZXZlbDIgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4NCkEgaXMgYW4g YWxpYXMgZm9yIEIsIG9yIHZpY2UtdmVyc2EuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMiBsZm8xO2Jh Y2tncm91bmQ6d2hpdGUiPg0KQSBhbmQgQiBhcmUgbm90IGFjdHVhbGx5IHJlbGF0ZWQgdG8gb25l IGFub3RoZXIgaW4gYW55IHdheSwgYW5kIHRoZSB0cmFuc21pdHRlciBidW5kbGVkIHRoZW0gdG9n ZXRoZXIgYmVjYXVzZSB0aGV5IHdlcmUgZ29pbmcgdG8gdGhlIHNhbWUgcmVjZWl2ZXIuPG86cD48 L286cD48L2xpPjwvb2w+DQo8L29sPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9 IjMiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZSI+DQpUb3AtbGV2ZWwg Y2xhaW0gc2VtYW50aWNzIGJlY29tZSBoYXJkZXIgdG8gZGVmaW5lLCBhcyBkaWZmZXJlbnQgcHJv ZmlsZXMgbWF5IHdhbnQgdG8gdXNlIHRoZSBzYW1lIGNsYWltcyBpbiBkaWZmZXJlbnQgd2F5cy48 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZSI+DQpFdmVudCBhdXRo ZW50aWNpdHkgY2Fubm90IGJlIHZlcmlmaWVkIHdpdGhvdXQgaGF2aW5nIHRoZSBlbnRpcmUgU0VU LiBUaGlzIGZvcmNlcyByZWNlaXZlcnMgdG8gZXhwb3NlIGRvd25zdHJlYW0gc3lzdGVtcyB0byBt b3JlIGluZm9ybWF0aW9uIG5lY2Vzc2FyeSwgaWYgdGhvc2Ugc3lzdGVtcyBuZWVkIHRvIGJlIGFi bGUgdG8gdmVyaWZ5IGF1dGhlbnRpY2l0eS48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFy ZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+ QW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij5Gcm9tOjxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0tMzE1MTQ0NTk1 ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5NaWtlDQogSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNwYW4gY2xhc3M9Im02MzM3NDQwODk2MTUzMjc5 ODM0bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4 MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5XZWRuZXNkYXks IE5vdmVtYmVyIDEsIDIwMTcgYXQgMTE6MjEgQU08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0ibTYz Mzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAw NG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9iPkRpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8 c3BhbiBjbGFzcz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3 NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9iPllhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJv bmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208 L2E+Jmd0OywgJnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsNCiAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWNoYW5u YUBhbWF6b24uY29tPC9hPiZndDssIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9 Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYu b3JnPC9hPiZndDssICZxdW90O1BoaWwgSHVudCAoSURNKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNs ZS5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PHNwYW4gY2xhc3M9Im02MzM3NDQwODk2MTUz Mjc5ODM0bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkz Nzc4MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SRTogW0lk LWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGNvbXBsZXRlbHkgYWdyZWUg b24gbW92aW5nIGNvbXBsZXhpdHkgdG8gdGhlIGlzc3VlciBvdmVyIHRoZSByZWNpcGllbnQuJm5i c3A7IEluIG15IHZpZXcsIGl04oCZcyBtb3JlIGNvbXBsZXggZm9yIHJlY2lwaWVudHMgdG8gaGF2 ZSB0byBjb3JyZWxhdGUgYW5kIHByb2Nlc3MgYSBzZXF1ZW5jZSBvZiBtdWx0aXBsZSBTRVRzIHBy b3ZpZGluZw0KIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQsIGFuZCB2 YWxpZGF0ZSBOIHNpZ25hdHVyZXMsIHRoYW4gdG8gcmVjZWl2ZSBvbmUgU0VUIHdpdGggYWxsIHRo ZSBhc3BlY3RzIG9mIHRoZSBsb2dpY2FsIGV2ZW50IGFzIOKAnGV2ZW50c+KAnSBmaWVsZHMsIHdp dGggbm8gY29ycmVsYXRpb24gb3ZlciB0aW1lIHRoZW4gcmVxdWlyZWQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PGI+RnJvbTo8L2I+PHNwYW4gY2xhc3M9Im02MzM3NDQwODk2MTUzMjc5ODM0 bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2 MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkRpY2sgSGFyZHQgWzxhIGhy ZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpk aWNrLmhhcmR0QGdtYWlsLmNvbTwvYT5dPHNwYW4gY2xhc3M9Im02MzM3NDQwODk2MTUzMjc5ODM0 bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2 MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9i PjxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03 NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5XZWRuZXNkYXksIE5vdmVtYmVyIDEsIDIwMTcgOTozOSBBTTxicj4N CjxiPlRvOjwvYj48c3BhbiBjbGFzcz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0 NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJtNjMz NzQ0MDg5NjE1MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0 bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Z YXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+eWFyb25mLmlldGZAZ21haWwuY29tPC9hPiZndDs7IFJpY2hhcmQgQmFj a21hbiwgQW5uYWJlbGxlDQogJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29t IiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7OyBJRCBFdmVudHMg TWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7OyBQaGlsIEh1bnQgKElETSkgJmx0 OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBo aWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFz cz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1 NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+UmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNF VD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPllvdXIgY29tbWVudHMgaGlnaGxpZ2h0IGEgY291cGxlIG9mIHBvaW50czo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4xKSBUaGUgZXhhbXBsZSBpcyBob3cgdG8gaGF2ZSBhIHByZWRlZmluZWQg ZXh0ZW5zaW9uIHBvaW50IGZvciBleHRlbnNpb25zIG9mIGEgc3BlY2lmaWMgZXZlbnQsIGl0IGlz IG5vdCBob3cgdG8gYWRkIGFub3RoZXIgZXZlbnQuIE15c2VsZiwgSSB0aGluayB0aGlzIGlzIG92 ZXJseSBjb21wbGljYXRlZC4gRXZlbnRzIHNob3VsZCBiZSBjb21wYXJhdGl2ZWx5IHN0YXRpYywN CiBhbmQgYXMgd2l0aCBtYW55IG90aGVyIEpTT04gZm9ybWF0cywgdGhlIHJlY2VpdmVyIHNob3Vs ZCBpZ25vcmUgcHJvcGVydGllcyBpdCBkb2VzIG5vdCB1bmRlcnN0YW5kLCB3aGljaCBsZXQncyBu ZXcgcHJvcGVydGllcyBiZSBpbnRyb2R1Y2VkIGFzIGV4dGVuc2lvbnMuIFRoZXJlIHNob3VsZCBu b3QgYmUgYW55IGNvbmZsaWN0IGFzIGV4dGVuc2lvbnMgc2hvdWxkIG9ubHkgYmUgZG9uZSBieSB0 aGUgcHJvZmlsZSB0aGF0IGNyZWF0ZWQgdGhlIGV2ZW50DQogZm9ybWF0IHRvIHN0YXJ0IG9mZiB3 aXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjIpIEhhdmluZyBhbiBsdmFsdWUgYmUgYSBVUkkgaXMg bXVjaCBoYXJkZXIgdG8gY29kZSBhZ2FpbnN0LiBJJ20gbm90IHN1cmUgd2h5IE1hcml1cyBoYWQg dGhhdCBpbiBoaXMgZXhhbXBsZS4gUGVyIHRoZSBldmVudCwgdGhlIHR5cGUgb2YgdGhlIGV2ZW50 IGlzIHdlbGwgZGVmaW5lZCB3aXRoJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZjtjb2xvcjojNTAwMDUwIj4mcXVvdDtldmVudF90eXBlJnF1b3Q7OiAmcXVvdDs8L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly9leGFt cGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQ8L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWY7Y29sb3I6IzUwMDA1MCI+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+MykgVGhpcyB0aHJlYWQgaXMgYWJvdXQgcmVhc29ucyBmb3IgbXVsdGlwbGUgZXZlbnRzIHRv IGJlIGNvbnRhaW5lZCBpbiBvbmUgc2V0LiBZb3VyIG1lbnRpb24gb2YgYW4gaXNzdWVyIG5vdCB3 YW50aW5nIHRvIHNpZ24gc2VwYXJhdGUgZXZlbnRzIGFzIGEgcmVhc29uIHRvIGFsbG93IG11bHRp cGxlIGV2ZW50cy4gSSB0aGluayB3ZSBoYXZlIGRlY2lkZWQgdGhhdCBnaXZlbg0KIGEgcHJlZmVy ZW5jZSwgd2Ugd2lsbCBwdXNoIGVmZm9ydCB0byB0aGUgdHJhbnNtaXR0ZXIgb3ZlciB0aGUgcmVj ZWl2ZXIgYXMgaW4gbWFueSB1c2UgY2FzZXMgdGhlcmUgYXJlIG1hbnkgbW9yZSByZWNlaXZlcnMu IEdpdmVuIHRoYXQsIGl0IGlzIG1vcmUgY29tcGxleCBmb3IgYSByZWNlaXZlciB0byBoYXZlIGRp ZmZlcmVudCB3YXlzIG9mIG1hbmFnaW5nIHRoZSByZWNlaXB0IG9mIG11bHRpcGxlIGV2ZW50cyBh cyBub3QgYWxsIGlzc3VlcnMgd2lsbA0KIGJ1bmRsZSB0aGUgZXZlbnRzLCBzbyBpdCBpcyBzaW1w bGVyIHRvIGhhdmUgb25seSBvbmUgZXZlbnQgcGVyIFNFVC4gSW5jbHVkaW5nIHRoZSBzZXBhcmF0 ZSBldmVudHMgd2l0aCBhIFVSSSBhcyBhbiBsdmFsdWUgaXMgY2hhbGxlbmdpbmcgdG8gaW1wbGVt ZW50LCBzcGVha2luZyBmcm9tIGV4cGVyaWVuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5PbiBUdWUs IE9jdCAzMSwgMjAxNyBhdCAxMTowNSBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPk1hcml1c+KAmSBwcm9wb3NlZCBzeW50YXgsIHBhc3RlZCBpbiBiZWxvdywgaGFzIGV4 YWN0bHkgdGhpcyBjaGFyYWN0ZXJpc3RpYy4mbmJzcDsgVGhlIHdheSBJIHNlZSBpdCwgaGlzIHBy b3Bvc2FsIGVzc2VudGlhbGx5IGhhcyBhIHByaW1hcnkgcGFzc3dvcmRSZXNldCBldmVudCBhbmQg YSBzZWNvbmRhcnkgcGFzc3dvcmRSZXNldEV4dA0KIGRhdGEgc3RydWN0dXJlLCB3aGljaCBjb3Vs ZCBoYXZlIGJlZW4gc2ltcGx5IGFub3RoZXIgZXZlbnQgdmFsdWUgaW4gdGhlIGN1cnJlbnQgZHJh ZnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPlRoaXMgYnJlYWtpbmcgY2hhbmdlIG1ha2VzIHRoZSBkYXRhIHN0cnVjdHVyZXMgbW9y ZSBjb21wbGljYXRlZCAtIG5vdCBsZXNzLiZuYnNwOyBBbmQgaXQgbWFrZXMgdGhpbmdzIHRoYXQg dXNlZCB0byBiZSBwb3NzaWJsZSBpbXBvc3NpYmxlLCByZWR1Y2luZyBmbGV4aWJpbGl0eSB0byB0 aG9zZSB3aG8gd291bGQgdXNlIHRoZSBzcGVjLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGVzZSBzZWVtIGxpa2UgYmFkIHRyYWRl b2ZmcyB0byBtZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij57PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmcXVv dDtqdGkmcXVvdDs6ICZxdW90OzNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwJnF1b3Q7 LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7 aWF0JnF1b3Q7OiAxNDU4NDk2MDI1LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmIj4mbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3Nj aW0uZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPC9zcGFuPjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmcXVvdDthdWQmcXVvdDs6IFs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAm cXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTVi YmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0 PC9zcGFuPjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29t L0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0 NTE2YjFkMDg2NDFkNzY3NmVlNzwvc3Bhbj48L2E+JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDtdLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7JnF1b3Q7ZXZlbnRfdHlwZSZxdW90 OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3Jk UmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRw czovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwvc3Bhbj48L2E+JnF1 b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5i c3A7JnF1b3Q7ZXZlbnQmcXVvdDs6IHsmbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZx dW90O2lkJnF1b3Q7OiZxdW90OzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkmcXVvdDssPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmcXVvdDtleHRlbnNpb25zJnF1b3Q7OiB7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bh c3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwvc3Bhbj48 L2E+4oCdOg0KIHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7cmVzZXRB dHRlbXB0cyZxdW90Ozo1LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO308L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmIj59PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPkluIHBhcnRpY3VsYXIsIGl0IG1ha2VzIGl0IGltcG9zc2libGUgdG8gc2ln biBtdWx0aXBsZSByZWxhdGVkIGV2ZW50cyBzaGFyaW5nIGEgY29tbW9uIGNsYWltcyBzY2hlbWEg d2l0aCBhIHNpbmdsZSBzaWduYXR1cmUgYnkgdGhlIGlzc3Vlci4mbmJzcDsgSXQgZm9yY2VzIHRo ZSBpc3N1ZXIgdG8gZG8gdGhlIGV4dHJhIHdvcmsNCiBvZiBzaWduaW5nIGVhY2ggb2YgdGhlIHJl bGF0ZWQgZXZlbnRzIChvciBmYWNldHMgb2YgdGhlIHNhbWUgbG9naWNhbCBldmVudCkgaW5kaXZp ZHVhbGx5IGFuZCBmb3JjZXMgdGhlIHJlY2lwaWVudHMgdG8gZG8gdGhlIGV4dHJhIHdvcmsgb2Yg Y2hlY2tpbmcgYWxsIHRob3NlIHVubmVjZXNzYXJ5IHNpZ25hdHVyZXMuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPk5vdCBldmVyeSBw cm9maWxlIHdpbGwgZXZlciBoYXZlIG11bHRpcGxlIGtleXMgaW4gdGhlIOKAnGV2ZW50c+KAnSBz ZXQgYnV0IHRoZXJl4oCZcyBhYnNvbHV0ZWx5IG5vIHJlYXNvbiB0byBwcmVjbHVkZSBpdC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj5Gcm9tOjwvYj48c3BhbiBjbGFzcz0ibTYzMzc0NDA4 OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01Njgz NDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SWQtZXZl bnQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50LWJvdW5jZXNA aWV0Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMx NTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgw YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24NCiBCZWhhbGYgT2Y8c3Bh biBjbGFzcz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0 Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PC9iPkRpY2sgSGFyZHQ8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0i bTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1Njgz MzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+VHVlc2RheSwgT2N0b2JlciAzMSwgMjAxNyA5OjUyIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFu IGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2 OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5NaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9i PjxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03 NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5ZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25m LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+eWFyb25mLmlldGZAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7Ow0KIFJpY2hhcmQgQmFja21h biwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5j b208L3NwYW4+PC9hPiZndDs7IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1h aWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7Ow0KIFBoaWwgSHVudCAo SURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3Nw YW4+PC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxicj4NCjxiPlN1 YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1 MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11 bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5QbGVhc2Ug ZGlyZWN0IG1lIHRvIGEgcHJvcG9zYWwgdGhhdCBoYXMgYSAmcXVvdDtwcmltYXJ5JnF1b3Q7IGFu ZCAmcXVvdDtzZWNvbmRhcnkmcXVvdDsgZXZlbnRzLiBJIGFncmVlIHRoYXQgaXMgdW5kZXNpcmFi bGUuIEkgd291bGQgYWxzbyBlbmNvdXJhZ2UgdG8gZW5nYWdlIGluIHRoZSBkaXNjdXNzaW9ucyBz byB0aGF0IHdlIGNhbiBkcml2ZSBjbGFyaXR5IGFuZCBzaW1wbGljaXR5LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5J IHRoaW5rIHRoZSBwcm9wb3NhbCBpcyB0aGF0IHRoZXJlIGlzIG9uZSBldmVudCBwZXIgU0VULjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPkkgdGhpbmsgaGF2aW5nIG1vcmUgdGhhbiBvbmUgZXZlbnQgcGVy IFNFVCBhZGRzIGNvbXBsZXhpdHkgYXMgYSByZWNlaXZlciBtdXN0IGRlYWwgd2l0aCByZWNlaXZp bmcgY29ycmVsYXRlZCBldmVudHMgaW4gb25lIFNFVCBhcyB3ZWxsIGFzIGNvcnJlbGF0ZWQgZXZl bnRzIGluIHRoZSBzYW1lIFNFVC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4vRGljazxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPk9uIFR1ZSwgT2N0IDMxLCAyMDE3IGF0IDk6NDIgUE0sIE1pa2UgSm9uZXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGhlYXIgeW91IG9uIHRoZSBmYWN0IHRoYXQgZGlmZmVy ZW50IHBlb3BsZSBoYXZlIGpvaW5lZCB0aGUgZWZmb3J0IGF0IGRpZmZlcmVudCB0aW1lcy4mbmJz cDsgVGhhdOKAmXMgYSBub3JtYWwgcHJvY2VzcyBhcyBhbiBlZmZvcnQgYnVpbGRzIG1vbWVudHVt LiZuYnNwOyBJIGdldCB0aGF0IG5vdCBldmVyeW9uZSB3YXMgdGhlcmUgd2hlbg0KIHByZXZpb3Vz IGNvbnNlbnN1cyBjYWxscyB3ZXJlIHRha2VuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIHNob3VsZCBub3RlIHRoYXQgSSBoYXZl IHNwZWNpZmljIHRlY2huaWNhbCBvYmplY3Rpb25zIHRvIHRoZSBzcGVjaWZpYyBwcm9wb3NlZCBj aGFuZ2VzIGJlaW5nIGRpc2N1c3NlZCBhcyB3ZWxsLiZuYnNwOyBDdXJyZW50bHkgYWxsIGV2ZW50 cyBpbiB0aGUgc2V0IGhhdmUgdGhlIHNhbWUgc3ludGF4LiZuYnNwOyBUaGUgcHJvcG9zYWxzLA0K IGFzIEkgdW5kZXJzdGFuZCB0aGVtLCByZXZlcnQgdXMgdG8gYSBzdGF0ZSB3aGVyZSB0aGVyZeKA mXMgYSDigJxwcmltYXJ54oCdIGFuZCDigJxzZWNvbmRhcnnigJ0gZXZlbnRzLCB3aXRoIGRpZmZl cmVudCBzeW50YXggZm9yIHRoZSB0d28gY2xhc3Nlcy4mbmJzcDsgVGhhdOKAmXMgbmVlZGxlc3Ns eSBtb3JlIGNvbXBsaWNhdGVkLCBhZGRpbmcgbm8gYWN0dWFsIHZhbHVlLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxiPkZyb206PC9iPjxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0t MzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEw ODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5EaWNrIEhhcmR0IFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZGljay5oYXJkdEBnbWFpbC5jb208L3NwYW4+PC9hPl08 c3BhbiBjbGFzcz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3 NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9Im02MzM3NDQwODk2 MTUzMjc5ODM0bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQw MjkzNzc4MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXks IE9jdG9iZXIgMzEsIDIwMTcgOTozNyBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0ibTYz Mzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAw NG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ TWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFz cz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1 NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+UGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1 bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0OzsNCiBZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVm PSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+eWFyb25mLmlldGZAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7OyBS aWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFt YXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yaWNo YW5uYUBhbWF6b24uY29tPC9zcGFuPjwvYT4mZ3Q7Ow0KIElEIEV2ZW50cyBNYWlsaW5nIExpc3Qg Jmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj48 c3BhbiBjbGFzcz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3 NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+UmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVu dHMgcGVyIFNFVD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+TWlrZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5B cyB5b3Ugd2VsbCBrbm93LCBtYW55IHBlb3BsZSBpbiBhIFdHIGRvbid0IGxvb2sgY2xvc2VseSBh dCBhIHNwZWNpZmljYXRpb24gdW50aWwgbGFzdCBjYWxsIGlzIG1hZGUuIEFkZGl0aW9uYWxseSwg d2UgYXJlIGNvbWluZyB1cCBvbiBvbmx5IHRoZSAzcmQgV0cgbWVldGluZy4gVGhlIFdHIGhhcyBu b3QgZXhpc3RlZCBmb3IgdmVyeSBsb25nLiBXaGlsZSBzb21lIG9mDQogdGhlIHBhcnRpY2lwYW50 cyBoYXZlIGJlZW4gd29ya2luZyBvbiB0aGlzIGZvciBhIHdoaWxlLCBtYW55IGhhdmUgbm90LCBh bmQgd2UgYXJlIGxvb2tpbmcgZm9yIGNvbnNlbnN1cyBhY3Jvc3MgdGhlIFdHLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPlNpbmNlIFNlY0V2ZW50IGlzIGEgZnJhbWV3b3JrIHRoYXQgd2UgZXhwZWN0IHRv IGJlIHByb2ZpbGVkLCBJIGZlZWwgaXQgaXMgaW1wb3J0YW50IHRvIGVuc3VyZSB0aGF0IFNlY0V2 ZW50IHNwZWNpZmljYXRpb25zIGFyZSBlYXN5IGZvciBhIHZhcmlldHkgb2YgcHJvZmlsZXMgdG8g YWRvcHQsIGFuZCB0aGF0IHRoZSBzZW1hbnRpY3MgbWFrZSBzZW5zZS4gSSBhbHNvIHRoaW5rDQog dGhhdCBwcm9wZXJ0aWVzIHRoYXQgYXJlIHNwZWNpZmljIHRvIGEgcHJvZmlsZSBzaG91bGQgYmUg bGVmdCB0byB0aGF0IHByb2ZpbGUgYW5kIG5vdCBiZSBpbmNsdWRlZCBpbiBTZWNFdmVudC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj5TaW5jZSB0aGlzIGlzIGEgZnJhbWV3b3JrLCBpdCBpcyBleHBlY3Rl ZCB0aGF0IGFzIGRpZmZlcmVudCBncm91cHMgcHJvZmlsZSBpdCwgdGhlcmUgd2lsbCBiZSBhZGRp dGlvbmFsIGZlZWRiYWNrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlNwZWNpZmljYWxseSwgYXMgYSBw YXJ0aWNpcGFudCBpbiB0aGUgUklTQyBwcm9maWxlIG9mIFNFVCwgYSBudW1iZXIgb2YgaXNzdWVz IGluIFNFVCBoYXZlIHN1cmZhY2VkIGFzIHRoZSBSSVNDIFdHIGhhcyBsb29rZWQgYXQgaG93IHRv IHVzZSB0aGUgU0VULjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkFzIGZvciBTRVQgYmVpbmcgc3RhYmxl IGZvciBvdmVyIGEgeWVhciwgdGhlcmUgaGF2ZSBiZWVuIGEgbnVtYmVyIG9mIGNoYW5nZXMgdG8g U0VUIHNpbmNlIHRoZW4uIEkgYWxzbyBkb24ndCB0aGluayB0aGVyZSB3YXMgY29uc2Vuc3VzLiBC ZWZvcmUgdGhlIFdHIHdhcyBmb3JtZWQsIEkgYW5kIHNldmVyYWwgb3RoZXJzIGhhZCBleHByZXNz ZWQgY29uY2VybiBvbiB0aGUNCiBkZXNpZ24gb2YgU0VUIHdoZW4gUGhpbCBwcmVzZW50ZWQgaXQg YXQgYW4gSUlXIHNlc3Npb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+QXMgdG8gdGFraW5nIGFub3Ro ZXIgeWVhciwgSSBhbSBob3BlZnVsIHdlIGNhbiByZXNvbHZlIHRoZSByZW1haW5pbmcgaXNzdWVz IGluIFNFVCBhbmQgcHVibGlzaCBhIG5ldyBkcmFmdCBmb3IgbGFzdCBjYWxsLiBJIGRvIG5vdCB0 aGluayB3ZSB3aWxsIG5lZWQgdG8gd2FpdCBmb3IgYW5vdGhlciBXRyBtZWV0aW5nIHRvIGFzayBm b3IgbGFzdCBjYWxsLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPldlIGFsc28gaGF2ZSBhIG51 bWJlciBvZiBvdGhlciBkb2N1bWVudHMgdGhhdCBhcmUgbm90IGluIGxhc3QgY2FsbCwgYW5kIHdl IGRvbid0IGhhdmUgYSBXRyBhZG9wdGVkIGRyYWZ0IHlldCBmb3IgbWFuYWdlbWVudC4gU28gdGhl cmUgYXJlIHN0aWxsIGEgbnVtYmVyIG9mIGRvY3VtZW50cyB0byB3b3JrIHRocm91Z2ggYmVmb3Jl IHdlIGhhdmUgYWxsIHRoZSBiaXRzIGZvcg0KIHNvbWVvbmUgdG8gd29yayB3aXRoLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPkkgZG8gdGhpbmsgd2UgaGF2ZSBiZWVuIG1ha2luZyBnb29kIHByb2dyZXNz IHNpbmNlIHRoZSBsYXN0IElFVEYgbWVldGluZywgYW5kIEkgYW0gaG9wZWZ1bCB3ZSBjYW4ga2Vl cCB1cCB0aGlzIG1vbWVudHVtIGFuZCBmaW5hbGl6ZSBhbGwgdGhlIGRvY3VtZW50cyBpbiBhIHRp bWVseSBtYW5uZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+L0RpY2s8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5PbiBUdWUsIE9jdCAz MSwgMjAxNyBhdCAxMjo0OCBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi Pkl04oCZcyBoYXJkIGZvciBtZSB0byBldmVuIGV4cHJlc3MgbXkgbGV2ZWwgb2YgZnJ1c3RyYXRp b24gd2l0aCB0aGUgcmVjZW50IGF0dGVtcHRzIHRvIG9uY2UgYWdhaW4gcmVkZXNpZ24gdGhlIFNl Y0V2ZW50IFRva2VuIHNwZWMuJm5ic3A7IFdl4oCZdmUgYmVlbiBhdCB0aGlzIGZvciBtdWx0aXBs ZSB5ZWFycyBiZWNhdXNlIHBlb3BsZQ0KIGtlZXAgdHJ5aW5nIHRvIHJldmlzaXQgZGVjaXNpb25z IHRoYXQgd2VyZSBsb25nIGFnbyBtYWRlIGJ5IGNvbnNlbnN1cy4mbmJzcDsgSXTigJlzIGJlZW4g c3RhYmxlIGZvciBvdmVyIGEgeWVhciBhbmQgdGhlIG1ham9yaXR5IG9mIFdHTEMgcmVzcG9uZGVu dHMgc2FpZCBzb21lIHZhcmlhbnQgb2Yg4oCcV29ya3MgZm9yIG1lIOKAkyBzaGlwIGl0IeKAnTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij5UaGVyZeKAmXMgbm90IHN1ZmZpY2llbnQganVzdGlmaWNhdGlvbiB0byB0cnkgdG8gdW5kbyBj b25zZW5zdXMgcG9zaXRpb25zIHRoYXQgaGF2ZSBiZWVuIGRlYmF0ZWQgYW5kIGFmZmlybWVkIG92 ZXIgYW5kIG92ZXIuJm5ic3A7IENvdW50ZW5hbmNpbmcgd2hvbGVzYWxlIGNoYW5nZXMgYXQgdGhp cyBsYXRlIGRhdGUgaXMgY291bnRlcnByb2R1Y3RpdmUNCiBpbiB0aGUgZXh0cmVtZSE8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SXTi gJlzIGZhciBiZXR0ZXIgdGhhbiBnb29kIGVub3VnaCBhcy1pcy4mbmJzcDsgSW4gbXkgZXhwZXJp ZW5jZSwgaWYgd2Ugc3RhcnQgcmVkZXNpZ25pbmcgaXQsIGl0IHdpbGwgcmVzdWx0IGluIGFub3Ro ZXIgeWVhcuKAmXMgZGVsYXkuJm5ic3A7IEl0IGRvZXMgc29tZXRoaW5nIHNpbXBsZSBhbmQgdXNl ZnVsLiZuYnNwOyBQbGVhc2UsIGxldOKAmXMganVzdA0KIHNoaXAgaXQsIHNvIHBlb3BsZSBjYW4g cmVseSBvbiBpdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0t IE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEgbmFtZT0ibV82MzM3NDQwODk2MTUz Mjc5ODM0X21fLTMxNTE0NDU5NTg0NTEwMiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZu YnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxiPkZyb206PC9iPjxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgz NG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1 NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5QaGlsIEh1bnQgKElETSkg W21haWx0bzo8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bh bj48L2E+XTxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1MTAy OTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0ibTYz Mzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAw NG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ TW9uZGF5LCBPY3RvYmVyIDMwLCAyMDE3IDI6NDIgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xh c3M9Im02MzM3NDQwODk2MTUzMjc5ODM0bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5 NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPkRpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRpY2suaGFyZHRA Z21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJtNjMz NzQ0MDg5NjE1MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0 bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Z YXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+eWFyb25mLmlldGZAZ21h aWwuY29tPC9zcGFuPjwvYT4mZ3Q7Ow0KIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8 YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPiZndDs7 IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDs7DQogSUQgRXZlbnRzIE1haWxpbmcgTGlz dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZn dDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxicj4NCjxiPlN1YmplY3Q6PC9i PjxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03 NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5SZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2 ZW50cyBwZXIgU0VUPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ SW5saW5lLi4uPGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7 YmFja2dyb3VuZDp3aGl0ZSI+PGJyPg0KT24gT2N0IDMwLCAyMDE3LCBhdCAyOjIyIFBNLCBEaWNr IEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwv c3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ SGkgUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj5Db3JyZWN0IG1lIGlmIEkgYW0gbWlzdW5kZXJzdGFuZGluZywg YnV0IHRoZXJlIGlzIGEgUklTQyBwcm9maWxlIGV2ZW50Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7d2hpdGUt c3BhY2U6cHJlLXdyYXAiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdCI+JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50 LTJEdHlwZV8tMjU1QyZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4 QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtB STFhTGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThf cVNDX3cmYW1wO3M9MjVsMDlzSDhZVjQyeHpnVS1DWFNnOHhIOXR2eURKejQwdENSakZhbGhrdyZh bXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8v c2NoZW1hcy5vcGVuaWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS88L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPmFjY291bnQtY3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWQ8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlO3doaXRlLXNwYWNlOnByZS13cmFwIj4mbmJzcDs8bzpwPjwvbzpw PjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj5hbmQgYW4gU0NJTSBwcm9maWxlIGV2ZW50PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7d2hpdGUtc3BhY2U6cHJl LXdyYXAiPiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNz d29yZFJlc2V0RXh0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQ8L3NwYW4+PC9h PuKAnTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlO3doaXRl LXNwYWNlOnByZS13cmFwIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JJ20g c3VnZ2VzdGluZyB0aGF0IHR3byBkaWZmZXJlbnQgZXZlbnRzIHdvdWxkIGJlIHNlbnQuIEVtYmVk ZGluZyBvbmUgaW4gdGhlIG90aGVyIGRvZXMgbm90IG1ha2Ugc2Vuc2UuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jmx0O3BoJmd0O0l0 IGlzIGEgaHlwb3RoZXRpY2FsIGV4YW1wbGUuIEp1c3QgYmVjYXVzZSB5b3UgZGlzYWdyZWUgb24g dGhpcyBkb2VzIG5vdCBtZWFuIG90aGVycyBhcmUgbm90IHZhbGlkLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij5JIGp1c3QgcGlja2VkIG92ZXJsYXBwaW5nIHByb3Bvc2FscyB0aGF0IGhhdmUgZGlmZmVyZW50 IG1lYW5pbmcgKGJ1dCBub3QgdGhlIHNhbWUpIHRvIGlsbHVzdHJhdGUgdGhlIGRpZmZlcmVuY2Ug ZnJvbSBpc3N1aW5nIGEgc2luZ2xlIHNldCB3aXRoIGRpZmZlcmVudCBldmVudHMuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj5BcyBJIGhhdmUgc3RhdGVkIHRoaXMgaXMg dmVyeSBkaWZmZXJlbnQgZnJvbSBhc3NlcnRpbmcgbXVsdGlwbGUgZGlzdGluY3QgZXZlbnRzIGlu IG9uZSBTRVQuJm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+QWxzbywgSSB0aGluayBpdCBpcyBz aW1wbGVyIHRvIGhhdmUgZXZlbnRfdHlwZSBiZSBhdCB0aGUgc2FtZSBsZXZlbCBhcyBldmVudDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+ Jmx0O3BoJmd0O21heSBiZS4gSSB3YXMgd29ya2luZyBmcm9tIEFubmFiZWxsZSdzIHByb3Bvc2Vk IGZvcm1hdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj57PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZxdW90O2p0aSZxdW90OzogJnF1b3Q7 M2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZxdW90O2lhdCZxdW90OzogMTQ1ODQ5NjAy NSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7 aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9zY2ltLmV4YW1w bGUuY29tPC9zcGFuPjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyxzZXJpZiI+Jm5ic3A7ICZxdW90O2F1ZCZxdW90OzogWzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9q aHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2podWIuZXhhbXBsZS5j b20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NDwvc3Bhbj48L2E+JnF1b3Q7LDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7 PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQx ZDc2NzZlZTciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRw czovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNzwvc3Bh bj48L2E+JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5i c3A7ICZuYnNwO10sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5i c3A7ICZuYnNwOyZxdW90O2V2ZW50X3R5cGUmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8v ZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0IiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50 L3Bhc3N3b3JkUmVzZXRFeHQ8L3NwYW4+PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7JnF1b3Q7ZXZlbnQmcXVvdDs6IHsmbmJz cDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7aWQmcXVvdDs6JnF1b3Q7NDRmNjE0MmRm OTZiZDZhYjYxZTc1MjFkOSZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7cmVzZXRBdHRl bXB0cyZxdW90Ozo1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssc2VyaWYiPn08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj57PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZxdW90O2p0aSZxdW90OzogJnF1b3Q7M2Qw YzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZxdW90O2lhdCZxdW90OzogMTQ1ODQ5NjAyNSw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7aXNz JnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUu Y29tPC9zcGFuPjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZiI+Jm5ic3A7ICZxdW90O2F1ZCZxdW90OzogWzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9qaHVi LmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2podWIuZXhhbXBsZS5jb20v RmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NDwvc3Bhbj48L2E+JnF1b3Q7LDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7PGEg aHJlZj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2 NzZlZTciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczov L2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNzwvc3Bhbj48 L2E+JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7 ICZuYnNwO10sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7 ICZuYnNwOyZxdW90O2V2ZW50X3R5cGUmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5u ZXRfc2VjZXZlbnRfcmlzY19ldmVudC0yRHR5cGVfYWNjb3VudC0yRGNyZWRlbnRpYWwtMkRjaGFu Z2UtMkRyZXF1aXJlZCZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4 QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtB STFhTGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThf cVNDX3cmYW1wO3M9blF5OWV6UFJqREdkdlJUQ2FpRHRpNE9IZWxIM0RLZ1VDVEtqRjJHUS1zbyZh bXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8v c2NoZW1hcy5vcGVuaWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS9hY2NvdW50LWNyZWRl bnRpYWwtY2hhbmdlLXJlcXVpcmVkPC9zcGFuPjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyZxdW90O2V2ZW50JnF1b3Q7OiB7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A74oCcc3Vi4oCdOuKAnTczNzU2MjZBNjU2Mzc04oCdLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO+KA nGlzc+KAnTomcXVvdDs8YSBocmVmPSJodHRwczovL2lkcC5leGFtcGxlLmNvbS8iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2lkcC5leGFtcGxlLmNv bS88L3NwYW4+PC9hPiZxdW90OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O308L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj59PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+T24gTW9uLCBPY3QgMzAsIDIwMTcgYXQgMTI6MDkgUE0sIFBo aWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208 L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkFubmFiZWxs ZS9EaWNrLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBJIHRo aW5rIHdlIG5lZWQgdG8gZXhhbWluZSB0aGUgY29uc2VxdWVuY2VzIG9mIHRoZSBwcm9wb3NhbCBp biBKU09OLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+QXMgSSBzdGF0ZWQsIHdoYXQgY2F1c2VzIG1vc3Qgb2YgdGhl IGlzc3VlIGlzIHRoZSBwcm9wb3NlZCBleHRlbnNpb24gbWVjaGFuaXNtIGluIHRoZSBwYXlsb2Fk IChwb3NzaWJseSB1c2luZyBldmVudHMgaW4gYSByZWN1cnNpdmUgd2F5KS4gRG9lcyBpdCBmb2xs b3cgdGhlIG9sZCBmb3JtYXQgb3IgdGhlIG5ldz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+TGV04oCZcyAmbmJzcDtj b25zaWRlciBhIHVzZSBjYXNlIHdoZXJlIHdlIGhhdmUgYW4gaWRlbnRpdHkgbWFuYWdlbWVudCBz eXN0ZW0gdGhhdCB1c2VzIFNDSU0sIGJ1dCB0aGUgU0NJTSBzeXN0ZW0gaXMgYWxzbyB0aGUgdW5k ZXJseWluZyBkYXRhIHN0b3JlIGZvciBDb25uZWN0LiZuYnNwOyBBIFBhc3N3b3JkIHJlc2V0IG1p Z2h0IGdlbmVyYXRlIHRoZSBmb2xsb3dpbmcgZXZlbnQgd2hpY2gNCiBoYXMgYW4gZXh0ZW5zaW9u IChjb252ZXlpbmcgcmVzZXQgY291bnQpIEFORCBvdmVybGFwcGluZyBzdGF0ZW1lbnQgZnJvbSBS SVNDLiZuYnNwOyBCT1RIIG9mIHdoaWNoIG1pZ2h0IGJlIGltcG9ydGFudCB0byBhIHNpbWlsYXIg cmVjZWl2ZXIgdXNpbmcgU0NJTSBhbmQgT0lEQy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PGI+VGhlIDAzIHNwZWMgY3VycmVudGx5IHdvdWxkIGFsbG93OjwvYj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ezxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7anRpJnF1b3Q7OiAm cXVvdDszZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90Oyw8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7ICZxdW90O2lhdCZxdW90 OzogMTQ1ODQ5NjAyNSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+Jm5ic3A7ICZxdW90O2lzcyZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zY2lt LmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pmh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbTwvc3Bhbj48L2E+JnF1b3Q7LDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7 OiBbPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNw OyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVl ZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZh NWJiYzg3OTU5M2I3NzU0PC9zcGFuPjwvYT4mcXVvdDssPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVm PSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVl NyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1 Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3PC9zcGFuPjwvYT4m cXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5i c3A7Jm5ic3A7IF0sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPiZuYnNwOyZuYnNwOyAmcXVvdDtldmVudHMmcXVvdDs6IHs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90O3VybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3JkUmVzZXQmcXVvdDs6PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB7ICZxdW90O2lkJnF1b3Q7OiZxdW90OzQ0ZjYxNDJkZjk2 YmQ2YWI2MWU3NTIxZDkmcXVvdDt9LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0 cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2V4YW1wbGUuY29tL3NjaW0v ZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwvc3Bhbj48L2E+JnF1b3Q7OjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgeyAmcXVvdDtyZXNldEF0dGVtcHRzJnF1b3Q7OjV9LDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5p ZC5uZXRfc2VjZXZlbnRfcmlzY19ldmVudC0yRHR5cGVfLTI1NUMmYW1wO2Q9RHdNRmFRJmFtcDtj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6 QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1peVZuclptcjlfdUdD UTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JmFtcDtzPTI1bDA5c0g4WVY0Mnh6Z1UtQ1hT Zzh4SDl0dnlESno0MHRDUmpGYWxoa3cmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL3NjaGVtYXMub3BlbmlkLm5ldC9zZWNldmVudC9yaXNj L2V2ZW50LXR5cGUvXDwvc3Bhbj48L2E+PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Fj Y291bnQtY3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWQmcXVvdDs6IHs8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsg4oCcc3Vi4oCdOuKAnTczNzU2MjZBNjU2Mzc04oCdLDwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyDigJxpc3PigJ06JnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij48 YSBocmVmPSJodHRwczovL2lkcC5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2lkcC5leGFtcGxlLmNvbS88L3NwYW4+PC9hPiZx dW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7IH08L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij59PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JbiB0aGUgYWJvdmUgLSBlYWNoIHBheWxvYWQgaXMg YSDigJhwZWVyJyBhbmQgaXNzdWVkIHdpdGhvdXQgcHJlZmVyZW5jZSBieSB0aGUgdHJhbnNtaXR0 ZXIuIFRoZSByZWNlaXZlciBjYW4gYXNzaWduIHByaW9yaXR5IGluIGl0cyBvd24gY29udGV4dCBp ZiB0aGF0IG1hdHRlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRp dj4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIG5ldyBwcm9wb3NhbDo8 L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+ezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj4mbmJzcDsgJnF1b3Q7anRpJnF1b3Q7OiAmcXVvdDszZDBjM2NmNzk3NTg0YmQxOTNi ZDBmYjFiZDRlN2QzMCZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jm5ic3A7ICZxdW90O2lhdCZxdW90OzogMTQ1ODQ5NjAyNSw8bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7ICZxdW90O2lzcyZx dW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vc2NpbS5leGFtcGxlLmNv bTwvc3Bhbj48L2E+JnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiBbPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBo cmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNi Nzc1NCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8v amh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0PC9zcGFuPjwv YT4mcXVvdDssPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5j b20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2 MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3PC9zcGFuPjwvYT4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7IF0sPG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyAmcXVvdDtl dmVudCZxdW90OzogezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXZlbnRfdHlwZeKAnTomcXVvdDt1cm46 aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpwYXNzd29yZFJlc2V04oCdLDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JnF1b3Q7aWQmcXVvdDs64oCdNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOeKAnSw8bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IOKAnGV2ZW50c+KAnTp7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtJmd0O25vdGUg4oCmaXMgdGhp cyB0aGUgb2xkIG9yIG5ldyBzdHJ1Y3R1cmU/ICZsdDstPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dv cmRSZXNldEV4dCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0 dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0PC9zcGFuPjwvYT4m cXVvdDs6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB7ICZxdW90O3Jl c2V0QXR0ZW1wdHMmcXVvdDs6NX0sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNl dmVudF9yaXNjX2V2ZW50LTJEdHlwZV8tMjU1QyZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055 NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnlt UlFTNmxLNjd5Rl84dThfcVNDX3cmYW1wO3M9MjVsMDlzSDhZVjQyeHpnVS1DWFNnOHhIOXR2eURK ejQwdENSakZhbGhrdyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5odHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlw ZS9cPC9zcGFuPjwvYT48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 YWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZCZxdW90Ozogezwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyDigJxzdWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0sPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IOKAnGlzc+KAnTomcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQi PjxhIGhyZWY9Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLzwvc3Bhbj48L2E+ JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNw OyB9PC9zcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPn08L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkluIHRo ZSBhYm92ZSwgc3ViLWV2ZW50cyBvciBleHRlbnNpb25zIGhhdmUgYSBkaWZmZXJlbnQgZm9ybWF0 LiBUaGUgc2FtZSBjb21wbGFpbnQgYWJvdXQgdGhlIG9yaWdpbmFsIHN0YW5kcy48L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPipPUiogKGlm IHRoZSByZWNlaXZlciBjYXJlcyBhYm91dCBSSVNDIG1vcmUpLiZuYnNwOyBOb3RlIHRoYXQgdGhp cyBsZWFkcyB0byBhIHRyaXBsZSBuZXN0ZWQgc3RydWN0dXJlLjwvc3Bhbj48L2I+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj57PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDtqdGkmcXVvdDs6ICZx dW90OzNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwJnF1b3Q7LDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7 OiAxNDU4NDk2MDI1LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0u ZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPC9zcGFuPjwvYT4mcXVvdDssPG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDthdWQmcXVvdDs6 IFs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVk cy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1 YmJjODc5NTkzYjc3NTQ8L3NwYW4+PC9hPiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9 Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3 IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9qaHVi LmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTc8L3NwYW4+PC9hPiZx dW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDsmbmJzcDsgXSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7Jm5ic3A7ICZxdW90O2V2ZW50JnF1b3Q7OiB7PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxl dmVudF90eXBl4oCdOjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij4mcXVvdDs8YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2No ZW1hcy5vcGVuaWQubmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlXy0yNTVDJmFtcDtkPUR3 TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFt cDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209aXlW bnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZhbXA7cz0yNWwwOXNIOFlW NDJ4emdVLUNYU2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2Vj ZXZlbnQvcmlzYy9ldmVudC10eXBlL1w8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7YWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+4oCdLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41 cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxzdWLigJ064oCdNzM3NTYyNkE2 NTYzNzTigJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A74oCcaXNz4oCdOiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vJUUyJTgwJTlDIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9pZHAuZXhhbXBs ZS5jb20v4oCcPC9zcGFuPjwvYT4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGV2ZW50c+KAnTp7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90O3VybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3JkUmVzZXQmcXVvdDs6PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmcXVvdDtpZCZxdW90OzrigJ00NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5 4oCdLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXZl bnRz4oCdOns8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9l dmVudC9wYXNzd29yZFJlc2V0RXh0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQ8 L3NwYW4+PC9hPiZxdW90Ozo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHsgJnF1b3Q7cmVzZXRBdHRlbXB0 cyZxdW90Ozo1fSw8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+Jm5ic3A7IDwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308L3NwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTxv OnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPn08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cHJlIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2 Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JbiB0aGUgYWJvdmUsIHRoZSBleHRl bnNpb24gaXMgcGxhY2VkIGluc2lkZSB0aGUgZXZlbnQgaXQgZXh0ZW5kcy4gSXQgZm9sbG93cyB0 aGUgb2xkIGZvcm1hdCAob3Igc2hvdWxkIGl0IGZvbGxvdyB0aGUgbmV3Pyk8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Kk9SKiBGb2xsb3dpbmcgdGhlIHRvcCBsYXllciBwYXR0ZXJuIG9mIHNpbmd1bGFyIGV2 ZW50Jm5ic3A7IE5vdGUgdGhhdCB0aGlzIGxlYWRzIHRvIGEgdHJpcGxlIG5lc3RlZCBzdHJ1Y3R1 cmUuPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPns8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5i c3A7ICZxdW90O2p0aSZxdW90OzogJnF1b3Q7M2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdk MzAmcXVvdDssPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PiZuYnNwOyAmcXVvdDtpYXQmcXVvdDs6IDE0NTg0OTYwMjUsPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDtpc3MmcXVvdDs6ICZxdW90 OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NjaW0uZXhhbXBsZS5jb208L3NwYW4+PC9h PiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ Jm5ic3A7ICZxdW90O2F1ZCZxdW90OzogWzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6 Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2podWIuZXhhbXBs ZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NDwvc3Bhbj48L2E+JnF1b3Q7LDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJz cDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVk NzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5odHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2 NDFkNzY3NmVlNzwvc3Bhbj48L2E+JnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyBdLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsgJnF1b3Q7ZXZlbnQmcXVvdDs6 IHs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGV2ZW50X3R5cGXigJ06PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQiPiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZlbnRfcmlzY19ldmVu dC0yRHR5cGVfLTI1NUMmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpo OEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBr QUkxYUxjTE40S1pOQSZhbXA7bT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4 X3FTQ193JmFtcDtzPTI1bDA5c0g4WVY0Mnh6Z1UtQ1hTZzh4SDl0dnlESno0MHRDUmpGYWxoa3cm YW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDov L3NjaGVtYXMub3BlbmlkLm5ldC9zZWNldmVudC9yaXNjL2V2ZW50LXR5cGUvXDwvc3Bhbj48L2E+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDthY2NvdW50LWNyZWRlbnRpYWwtY2hhbmdlLXJlcXVpcmVkPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPuKAnSw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcc3Vi4oCdOuKAnTczNzU2MjZBNjU2Mzc04oCdLDwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGlzc+KAnTomcXVvdDs8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vJUUyJTgwJTlD IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9pZHAu ZXhhbXBsZS5jb20v4oCcPC9zcGFuPjwvYT4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGV2ZW504oCdOns8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsg4oCcZXZlbnRfdHlwZeKAnTomcXVvdDt1cm46aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpwYXNz d29yZFJlc2V04oCdLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+JnF1b3Q7aWQmcXVvdDs64oCdNDRm NjE0MmRmOTZiZDZhYjYxZTc1MjFkOeKAnSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IOKAnGV2ZW504oCdOns8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IOKAnGV2ZW50X3R5cGXigJ06JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNv bS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRS ZXNldEV4dDwvc3Bhbj48L2E+4oCdLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJnF1b3Q7cmVzZXRBdHRlbXB0cyZxdW90Ozo1PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQiPiA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cHJlIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDt9PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDt9PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBmb3JtYXQgZm9sbG93cyB0aGUgcHJvcG9z ZWQgc2luZ3VsYXIgZXZlbnQgZm9ybWF0IHJlY3Vyc2l2ZWx5IGFuZCBpcyAzIGxheWVycyBkZWVw LiBOb3RlIHRoYXQgdGhlIHBhcnNlciBoYXMgdG8gY29udGludWUgdG8gc2VhcmNoIHRoZSBkb2N1 bWVudCBmb3IgdGhpbmdzIHRoYXQgYXJlbuKAmXQgdGhlcmUgYXMgaXQgaGFzIHRvIHN0b3Agd2hl biBubyDigJxldmVudOKAnSBhdHRyaWJ1dGUgaXMgZm91bmQgcmF0aGVyIHRoYW4gaXRlcmF0ZSBv dmVyIGFuIGFycmF5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8cHJlIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5Q aGlsPGJyPg0KPGJyPg0KT3JhY2xlIENvcnBvcmF0aW9uLCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNl cyBBcmNoaXRlY3Q8YnI+DQpAaW5kZXBlbmRlbnRpZDxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRp ZC5jb20mYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1V QjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40 S1pOQSZhbXA7bT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JmFt cDtzPTlzWWhncEV6Yjd4UGxRRm1DQ1hObUhvNmZRTjlJQnUtU0hKYW1nX0I0SHMmYW1wO2U9IiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+d3d3LmluZGVwZW5kZW50 aWQuY29tPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5PbiBPY3Qg MzAsIDIwMTcsIGF0IDg6NTcgQU0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBo cmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iY29sb3I6I0MzNDZFMCI+UmVwbGllcyBpbmxpbmUuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJl bGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPklkZW50aXR5IFNlcnZpY2VzPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPkZyb206PHNwYW4gY2xhc3M9Im02MzM3NDQwODk2MTUzMjc5ODM0bS0zMTUxNDQ1 OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3 Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAz bTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5QaGlsDQogSHVudCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPiZn dDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0tMzE1MTQ0 NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBtLTQz Nzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcw M200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9iPlN1bmRheSwgT2N0b2JlciAyOSwgMjAxNyBhdCA1OjI1IFBNPGJyPg0KPGI+VG86PHNwYW4g Y2xhc3M9Im02MzM3NDQwODk2MTUzMjc5ODM0bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5 NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAx Mzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+RGljayBIYXJkdCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+ZGljay5oYXJkdEBnbWFpbC5jb208L3NwYW4+PC9hPiZndDs8 YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0 NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwbS00Mzc3Nzg3 NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAy NjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Z YXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+eWFyb25mLmlldGZAZ21h aWwuY29tPC9zcGFuPjwvYT4mZ3Q7LA0KIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDss ICZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPiZndDssDQogSUQgRXZlbnRz IE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8 L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1 MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5 Mzc3ODE1NjEwODBtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1 ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9iPlJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUN CiBldmVudHMgcGVyIFNFVD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+SSBob3BlIHRoaXMgYW5zd2VycyB5b3VyIHF1ZXN0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk15IOKAnG1heeKA nSB3YXMgYmVjYXVzZSBJIGNhbuKAmXQgc2VlIGEgcmVhc29uIHdoeSBub3QuIFRoZSBxdWVzdGlv biBzaG91bGQgYmUsIHdoYXQgaXMgdGhlIGp1c3RpZmljYXRpb24gdG8gbWFrZSDigJxldmVudHPi gJ0gc2luZ3VsYXI/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOiNDMzQ2RTAiPltyaWNoYW5uYV1UaGUgc2luZ3VsYXIg4oCcZXZlbnTigJ0gY2xh aW0gaGFzIGNsZWFyZXIgc2VtYW50aWNzIGFuZCBpcyBlYXNpZXIgdG8gcHJvY2Vzcy4gV2Ugc2hv dWxkIG9wdCBmb3IgZWFzaWVyIHNvbHV0aW9ucyB1bmxlc3MgdGhlcmUgYXJlIHVzZSBjYXNlcyB0 aGF0IHJlcXVpcmUgbW9yZSBjb21wbGV4aXR5LlsvcmljaGFubmFdPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRoZXJlIGFyZSBtYW55IHJl YXNvbnMgZm9yIG11bHRpcGxlIGV2ZW50cyBpbiBhIFNFVC4mbmJzcDsgU29tZSBhcmUgZ29vZCwg c29tZSBub3Qgc28gZ29vZC4gU29tZSBvZiB0aGUgcmVhc29ucy4uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjEuJm5ic3A7IE11bHRpcGxlIGV2ZW50 IHBheWxvYWRzIGV4cHJlc3Npbmcgc3RhdGVtZW50cyBhYm91dCBsYXJnZWx5IHRoZSAqc2FtZSp0 aGluZy4gRm9yIGV4YW1wbGUsIFNDSU0gcGFzc3dvcmQgcmVzZXQgQU5EIFJJU0MgcGFzc3dvcmQg cmVzZXQuJm5ic3A7IEEgUklTQyBFdmVudCBhbmQgYW4gT3BlbkJhbmtpbmcgRXZlbnQuIElzIG9u ZSBhIGNvbXBsZW1lbnQgdG8gdGhlIG90aGVyPyZuYnNwOw0KIERvIHRoZXkgb3ZlcmxhcCBvciBh cmUgdGhleSBkaXN0aW5jdD8gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPltyaWNoYW5uYV1Db3B5L3Bhc3RlZCBmcm9t IG15IGVhcmxpZXIgZW1haWw6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojQzM0NkUwIj5XaHkgaXMgaXQgbmVjZXNzYXJ5IG9yIGFw cHJvcHJpYXRlIHRvIGluY2x1ZGUgdGhlc2UgZXZlbnRzIGluIHRoZSBzYW1lIFNFVD8gVGhleSBh cmUgbGlrZWx5IGJlaW5nIGdlbmVyYXRlZCBieSBkaWZmZXJlbnQgc3lzdGVtcyBhdCBkaWZmZXJl bnQgdGltZXMgb24gdGhlIHRyYW5zbWl0dGVy4oCZcyBzaWRlLCBjb25zdW1lZA0KIGJ5IGRpZmZl cmVudCBzeXN0ZW1zIG9uIHRoZSByZWNlaXZlcuKAmXMgc2lkZSwgYW5kIHBvc3NpYmx5IGJlaW5n IHRyYW5zbWl0dGVkIG92ZXIgZGlmZmVyZW50IGV2ZW50IHN0cmVhbXMuIEkga25vdyB0aGUgbGF0 dGVyIHdvdWxkIGJlIHRoZSBjYXNlIGZvciB1cywgYXMgYSByZWNlaXZlci4gRXZlbiBpZiBpdOKA mXMgbm90LCBpcyBpdCBidXJkZW5zb21lIHRvIHNlbmQgdGhlc2UgZXZlbnRzIHNlcGFyYXRlbHk/ IFdoYXQgdmFsdWUgaXMgZ2FpbmVkIGluDQogY29tYmluaW5nIHRoZW0/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojQzM0NkUwIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOiNDMzQ2RTAiPkFkZGl0aW9uYWxseSwgc2luY2UgdGhlIHNpZ25hdHVyZSBpcyBv dmVyIHRoZSBTRVQgYW5kIG5vdCB0aGUgZXZlbnQgb2JqZWN0cywgUmVjZWl2ZXJzIGluZGVwZW5k ZW50bHkgcm91dGUgc2VwYXJhdGUgZXZlbnRzIGZyb20gYSBzaW5nbGUgdG9rZW4gd2l0aG91dCBl aXRoZXIgbG9zaW5nIHRoZSBhYmlsaXR5IHRvIHZlcmlmeQ0KIHRoZSBhdXRoZW50aWNpdHkgb2Yg dGhlIGV2ZW50IG9yIHNoYXJpbmcgYWxsIGluZm9ybWF0aW9uIGluIHRoZSBTRVQgd2l0aCBldmVy eSBzeXN0ZW0gaGFuZGxpbmcgYW55IGV2ZW50IGluIHRoZSB0b2tlbi5bL3JpY2hhbm5hXTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6 I0MzNDZFMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwg aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KMi4mbmJzcDsgTXVs dGlwbGUgZXZlbnRzIHBheWxvYWRzIGV4cHJlc3NpbmcgZGlmZmVyZW50IHN0YXRlbWVudHMgYWJv dXQgdGhlIHNhbWUgdHJhbnNhY3Rpb24gLSBSSVNDIFBhc3N3b3JkIFJlc2V0IGFuZCBSSVNDIFNl c3Npb24gQ2FuY2VsPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPltyaWNoYW5uYV1T YW1lIGFzIGFib3ZlWy9yaWNoYW5uYV08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjMuJm5ic3A7IEEgbmV3IHByb2ZpbGUgZGVmaW5lcyBuZXcgZXZlbnQg YXR0cmlidXRlcyB0byBiZSBhZGRlZCBvbiB0byBhbiBleGlzdGluZyBldmVudCB0eXBlIChhIHB1 cmUgZXh0ZW5zaW9uKSZuYnNwOzxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojQzM0NkUwIj5bcmlj aGFubmFdSSBoYXZlIHN1Z2dlc3RlZCBhIHdheSB0byBzdXBwb3J0IGV4dGVuc2lvbnMgd2l0aGlu IGFuIGV2ZW50IGJvZHksIG11bHRpcGxlIHRpbWVzIG5vdy4gSWYgeW91IHNlZSBwcm9ibGVtcyB3 aXRoIGl0LCBwbGVhc2UgcG9pbnQgdGhlbSBvdXQuWy9yaWNoYW5uYV08L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SSB0aGluayBpdCBpcyBx dWl0ZSB2YWxpZCB0byBhbGxvdyAxIGFuZCAzLiAmbmJzcDsyIGNvdWxkIGJlIGxpbWl0ZWQgYnkg c3BlY2lmaWMgcHJvZmlsZXMgbGlrZSBSSVNDIGlmIHRoZXkgd2FudC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JIGFtIG5vdCBpbiBhZ3JlZW1lbnQg dGhhdCBtYWtpbmcgZXZlbnQgc2luZ3VsYXIgc2ltcGxpZmllcyBhbnl0aGluZy4gRm9yIG9uZSBp cyBtYWtlcyBleHRlbnNpb25zIGNvbXBsZXggKGFub3RoZXIgbmVzdGVkIEpTT04gc3RydWN0dXJl KSBhbmQgcG90ZW50aWFsbHkgY29uZmxpY3RpbmcuJm5ic3A7PGJyPg0KPHNwYW4gc3R5bGU9ImNv bG9yOiNDMzQ2RTAiPltyaWNoYW5uYV08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPldheXMgdGhhdCBtdWx0aXBsZS1l dmVudCBTRVRzIGFyZSBtb3JlIGNvbXBsaWNhdGVkOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0i MSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiNDMzQ2RTA7bWFyZ2luLWxl ZnQ6MGluO21zby1saXN0OmwzIGxldmVsMSBsZm8yO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3Vu ZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0 aWFsIj4NCkl0IHJlc3VsdHMgaW4gYSBtb3JlIGNvbXBsZXggc3RydWN0dXJlIGZvciB0aGUgc2lu Z2xlIGV2ZW50IHVzZSBjYXNlLCB3aGljaCBJIHRoaW5rIHdlIGFsbCBhZ3JlZSBpcyB0aGUgbWFq b3JpdHkgdXNlIGNhc2UuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY29sb3I6I0MzNDZFMDttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzI7 YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNr Z3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KTXVsdGlwbGUtZXZlbnQgU0VUcyBoYXZl IGFtYmlndW91cyBzZW1hbnRpY3MuIFRoZSBwcmVzZW5jZSBvZiB0d28gZXZlbnRzIEEgYW5kIEIg aW4gdGhlIHNhbWUgU0VUIGNvdWxkIG1lYW4gYW55IG9mOjxvOnA+PC9vOnA+PC9saT48L29sPg0K PG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjIiIHR5cGU9IjEiPg0KPG9sIHN0eWxl PSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjojQzM0NkUwO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZl bDIgbGZvMztiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0 aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQpUaGV5IGFyZSByZWxhdGVk IHRvIHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQgKGkuZS4gdGhlIHNhbWUgdGhpbmcgYXMgaWYgdGhl eSB3ZXJlIGZyb20gZGlmZmVyZW50IFNFVHMgdGhhdCBoYXZlIGEgY29tbW9uIHR4bikuPG86cD48 L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6I0MzNDZFMDttYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzM7YmFja2dyb3VuZDp3aGl0ZTtiYWNr Z3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFs IGluaXRpYWwiPg0KQSBpcyBhbiBleHRlbnNpb24gb2YgQi48bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojQzM0NkUwO21hcmdpbi1sZWZ0OjBpbjttc28t bGlzdDpsMCBsZXZlbDIgbGZvMztiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246 aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQpCIGlz IGFuIGV4dGVuc2lvbiBvZiBBLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImNvbG9yOiNDMzQ2RTA7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMiBs Zm8zO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7 YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NClRoZXkgYXJlIGFsaWFzZXMgZm9y IG9uZSBhbm90aGVyLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNvbG9yOiNDMzQ2RTA7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMiBsZm8zO2Jh Y2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dy b3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NClRoZXkgYXJlIG5vdCBhY3R1YWxseSByZWxh dGVkIHRvIG9uZSBhbm90aGVyIGluIGFueSB3YXkuPG86cD48L286cD48L2xpPjwvb2w+DQo8L29s Pg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjMiIHR5cGU9IjEiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojQzM0NkUwO21hcmdpbi1sZWZ0OjBpbjttc28t bGlzdDpsMSBsZXZlbDEgbGZvNDtiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246 aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQpDbGFp bSBzZW1hbnRpY3MgYmVjb21lIGhhcmRlciB0byBkZWZpbmUsIGFzIGRpZmZlcmVudCBwcm9maWxl cyBtYXkgd2FudCB0byB1c2UgdGhlIHNhbWUgY2xhaW1zIGluIGRpZmZlcmVudCB3YXlzLjxvOnA+ PC9vOnA+PC9saT48L29sPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SWYgdGhlIFdHIHdhbnRzIHRvIGJs b2NrIDEgYW5kIDIgYWJvdmUsIHRoZW4gSSBiZWxpZXZlIHdlIGhhdmUgdG8gZXN0YWJsaXNoIGFu IGV2ZW50IHJlZ2lzdHJ5IHRvIGVuc3VyZSBuZXcgRXZlbnQgcHJvZmlsZXMgZG8gbm90IG92ZXJs YXAgdG8gZWxpbWluYXRlIHRoZSBuZWVkIHRvIGV4cHJlc3MgbXVsdGlwbGUgZXZlbnRzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJjb2xvcjojQzM0NkUwIj5bcmljaGFubmFdSeKAmW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBi eSB0aGlzLiBBcmUgeW91IHJlZmVycmluZyB0byBldmVudCBuYW1lcz8gVGhvc2UgYXJlIGFscmVh ZHkgZGVmaW5lZCBieSB0aGUgc3BlYyB0byBiZSBVUklzLlsvcmljaGFubmFdPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PlBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5P cmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkBpbmRlcGVuZGVu dGlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEg aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0Ff X3d3dy5pbmRlcGVuZGVudGlkLmNvbSZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5 WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPVUtYTVIQk5EMEhhVFg0YW5OWmZ6WDdwRHNmSzVm MGg5bVo5Q1pra0dpZWMmYW1wO3M9S0J3S1BGbnFZX1E5NUNUQV9fV0dDWUdUeHJEN0FHQ3h1ZW9Q WG5LRVVUMCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij53d3cuaW5kZXBlbmRlbnRpZC5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEgaHJlZj0ibWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+T24gT2N0IDI5LCAyMDE3LCBhdCA0OjEyIFBNLCBEaWNrIEhh cmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvc3Bh bj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+UGhpbDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5JbiB5b3VyIGV4YW1wbGVzIGZvciBoYXZpbmcgYSBwbHVyYWxpdHkgb2YgZXZlbnRzLCB5 b3UgdXNlIHRoZSB3b3JkICZxdW90O21heSZxdW90Oywgd2hpY2ggbGVhZHMgbWUgdG8gcXVlc3Rp b24gaWYgYSBwbHVyYWxpdHkgb2YgZXZlbnRzIGlzIHJlYWxseSByZXF1aXJlZA0KIGluIFNFVC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPllvdSBwb3NpdCB0aGF0 IGl0IHdpbGwgYmUgZGlmZmljdWx0IGZvciBhIGRpc3RyaWJ1dGVkIHN5c3RlbSB0byBjb3JyZWxh dGUgbXVsdGlwbGUgU0VUcyB3aXRoIHRoZSBzYW1lICZxdW90O3R4biZxdW90OywgYnV0IHRoZSBk aXN0cmlidXRlZCBzeXN0ZW0gd2lsbCBjZXJ0YWlubHkNCiBuZWVkIHRvIGNvcnJlbGF0ZSBldmVu dHMgb24gdGhlIHNhbWUgc3ViamVjdCAtLSBjb3JyZWxhdGluZyBldmVudHMgb24gdGhlIHNhbWUg JnF1b3Q7dHhuJnF1b3Q7IG9uIHRoZSBzYW1lIHN1YmplY3Qgc2VlbXMgZmFpcmx5IHNpbXBsZS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgdGhpbmsgdGhhdCBh IHJlY2VpdmVyIHdpbGwgbmVlZCB0byBjb3JyZWxhdGUgbXVsdGlwbGUgU0V0cyBvbiB0aGUgc2Ft ZSBzdWJqZWN0LCBzbyBoYXZpbmcgbXVsdGlwbGUgZXZlbnRzIGluIGEgU0VUIGlzIHJlZHVuZGFu dCwgYW5kIGFkZHMgY29tcGxleGl0eQ0KIHdpdGggbm8gY2xlYXIgYmVuZWZpdCB0aGF0IEkgY2Fu IHNlZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFuIGltcGxl bWVudG9yIG1heSBjaG9vc2UgdG8gc2VuZCBtdWx0aXBsZSBTRVRzLCBvciBzZW5kIGEgc2luZ2xl IFNFVCB3aXRoIG11bHRpcGxlIGV2ZW50cywgc28gYSByZWNlaXZlciB3aWxsIG5lZWQgdG8gc3Vw cG9ydCBib3RoLiBJIHByZWZlciB3ZSBwaWNrDQogb25lIHdheSBhbmQgbWluaW1pemUgdGhlIGNv ZGUgcGF0aHMsIGFuZCB3ZSB3aWxsIG5lZWQgdG8gc3VwcG9ydCBjb3JyZWxhdGluZyBhY3Jvc3Mg bXVsdGlwbGUgU0VUcywgc28gdGhhdCBzZWVtcyB0aGUgYmVzdCBtZWNoYW5pc20uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5MZXQgbWUga25vdyBpZiB0aGVyZSBp cyBzb21ldGhpbmcgSSBtaXNzZWQgaW4gbXkgbG9naWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4vRGljazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIFN1biwgT2N0IDI5LCAyMDE3 IGF0IDExOjI4IEFNLCBZYXJvbiBTaGVmZmVyPHNwYW4gY2xhc3M9Im02MzM3NDQwODk2MTUzMjc5 ODM0bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4 MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2 OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnlhcm9uZi5pZXRmQGdtYWls LmNvbTwvc3Bhbj48L2E+Jmd0OzxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0tMzE1 MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBt LTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2 MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+d3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+SW4gdGhhdCBjYXNlLCBsZXQncyBhZGQgdGV4dCB0byB0aGF0IGVmZmVjdCwgZS5nLiB3 ZSBjb3VsZCBhZGQgdG8gdGhlIGRlZmluaXRpb24gb2YgdGhlICZxdW90O2V2ZW50cyZxdW90OyBj bGFpbTo8YnI+DQo8YnI+DQpQcm9maWxpbmcgc3BlY2lmaWNhdGlvbnMgU0hPVUxEIGRlZmluZSB0 aGUgYWxsb3dlZCBldmVudCBzdGF0ZW1lbnRzLCBhbmQgTUFZIHJlc3RyaWN0IHRoZWlyIG51bWJl ci4gRm9yIGV4YW1wbGUsIHNvbWUgcHJvZmlsZXMgbWF5IHJlcXVpcmUgdGhpcyBjbGFpbSB0byBj b250YWluIG9ubHkgYSBzaW5nbGUgZXZlbnQgc3RhdGVtZW50Ljxicj4NCjxicj4NClRoYW5rcyw8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0ibTYzMzc0NDA4OTYx NTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAy OTM3NzgxNTYxMDgwbS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5 NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPllhcm9uPGJyPg0KPGJyPg0KT24gMjQvMTAvMTcgMjI6MTAsIE1pa2Ug Sm9uZXMgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGU7YmFj a2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlh bCBpbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYWdyZWUgd2l0aCBtdWNoIG9mIFBoaWzi gJlzIHJhdGlvbmFsZSBoZXJlLjxicj4NCjxicj4NCkl04oCZcyBmaW5lIGZvciBzb21lIHByb2Zp bGVzIHRvIHNheSB0aGF0IHRoZSDigJxldmVudHPigJ0gc2V0IG11c3QgYmUgYSBzaW5nbGV0b24u Jm5ic3A7IFRoYXQgZG9lc27igJl0IGhhdmUgdG8gYmUgdHJ1ZSBmb3IgYWxsIGV2ZW50cy4mbmJz cDsgSSB0aGluayB0aGluZ3MgYXJlIGZpbmUgYXMtaXMuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9Im02MzM3NDQwODk2MTUz Mjc5ODM0bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkz Nzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4 Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj4tLQ0KIE1pa2U8YnI+DQo8YnI+DQoqRnJvbToqIElkLWV2ZW50IFttYWls dG86PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3Jn PC9zcGFuPjwvYT5dICpPbiBCZWhhbGYgT2YgKlBoaWwgSHVudDxicj4NCipTZW50OiogTW9uZGF5 LCBPY3RvYmVyIDIzLCAyMDE3IDg6NDcgUE08YnI+DQoqVG86KiBSaWNoYXJkIEJhY2ttYW4sIEFu bmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yaWNoYW5uYUBhbWF6b24uY29tPC9z cGFuPjwvYT4mZ3Q7PGJyPg0KKkNjOiogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQoqU3Vi amVjdDoqIFJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBT RVQ/PGJyPg0KPGJyPg0KQW5uYWJlbGxlLDxicj4NCjxicj4NCkkgaGF2ZSBhIG51bWJlciBvZiBj b25jZXJucyB3aXRoIHRoaXMgcHJvcG9zYWwuPGJyPg0KPGJyPg0KUHJvZmlsaW5nIEluZGVwZW5k ZW5jZSAvIEtlZXBpbmcgRXZlbnQgUGF5bG9hZHMgSW5kZXBlbmRlbnQ8YnI+DQo8YnI+DQpJbmRp Y2F0aW5nIHRoYXQgZXh0ZW5zaW9ucyBzaG91bGQgYmUgaGFuZGxlZCBieSBwcm9maWxlcyBsZWFk cyB0byBtb3JlIGludGVyLW9wZXJhYmlsaXR5IGlzc3VlcyBhbmQgbW9yZSBpbXBvcnRhbnRseSBp bnRydWRlcyBvbiB0aGUgRXZlbnQgcGF5bG9hZCBzcGFjZSBieSBzdWdnZXN0aW5nIGEgc3ViLXNj aGVtYSBjcmVhdGVzIHBvdGVudGlhbCBsaW1pdGF0aW9ucyBhbmQgY29uZmxpY3RzIHRoYXQgbWF5 IGFkZCB0byBjb21wbGV4aXR5IGxhdGVyDQogb24uIFRoZSBjdXJyZW50IGZvcm1hdCBhbGxvd3Mg YSBwYXJzZXIgdG8gZGlzY292ZXIgYW5kIHVubG9hZCBvbmUgb3IgbW9yZSBKU09OIHBheWxvYWRz IHdoaWNoIGNhbiBlYWNoIGhhdmUgaW5kZXBlbmRlbnQgc3RydWN0dXJlLjxicj4NCjxicj4NCkdl bmVyYWwgZXh0ZW5zaW9uczxicj4NCjxicj4NClRoZSBwcm9wb3NhbCBhbHNvIHJ1bGVzIG91dCBn ZW5lcmFsIHB1cnBvc2UgZXh0ZW5zaW9ucyBub3QgcmVsYXRlZCB0byBhbnkgc3BlY2lmaWMgZXZl bnQuIEdpdmVuIHRoZSBlbWVyZ2VuY2Ugb2YgaXRlbXMgbGlrZSBHUFJELCBJIHdvdWxkIG5vdCB3 YW50IHRvIGJsb2NrIHRoZSBhYmlsaXR5IHRvIGFkZCBtZXRhLWRhdGEgb3Igb3RoZXIgZ2VuZXJh bCBwdXJwb3NlIGl0ZW1zLiBXZSBjYW4gYWxzbyBhbnRpY2lwYXRlIHNvbWUgZGVsaXZlcnkgc2Nl bmFyaW9zDQogd2hlcmUgYWRkaXRpb25hbCBkYXRhIG1pZ2h0IGJlIHJlcXVpcmVkLiBFdmVuIHRo b3VnaCB0aGVyZSBpcyBubyBjdXJyZW50IHBsYW5uZWQgdXNlLCBJIHNlZSBubyBnb29kIHJlYXNv biB0byBydWxlIHRoaXMgb3V0Ljxicj4NCjxicj4NCk11bHRpcGxlIEV2ZW50cyBGcm9tIERpZmZl cmVudCBGYW1pbGllcyAodnMuIE11bHRpcGxlIEV2ZW50cyBmcm9tIGEgc2luZ2xlIGZhbWlseSBs aWtlIFJJU0MpPGJyPg0KPGJyPg0KSW4gb3VyIFJJU0Mgc2Vzc2lvbiB3ZSBkaXNjdXNzZWQgZXhw cmVzc2luZyBtdWx0aXBsZSBkaXN0aW5jdCBSSVNDIGV2ZW50cyBpbiBvbmUgU0VULiBUaGUgZGlz Y3Vzc2lvbiB3YXMgdGhhdCBvbmx5IG9uZSBSSVNDIGV2ZW50IGF0IGEgdGltZS4gV2UgZGlkIG5v dCBkaXNjdXNzIG90aGVyIGV2ZW50IHByb2ZpbGVzLiBJIGRvbuKAmXQgc2VlIGEgcmVhc29uIHRv IHJ1bGUgb3V0IG11bHRpLWV2ZW50cyBmcm9tIGRpZmZlcmVudCBmYW1pbGllcyBhdCB0aGUNCiBT RVQgbGV2ZWwuIEVhY2ggcHJvZmlsZSBpcyBleHByZXNzaW5nIHNsaWdodGx5IGRpZmZlcmVudCB0 aGluZ3MgYWJvdXQgdGhlIHNhbWUgZXZlbnQuPGJyPg0KPGJyPg0KSSBjYW4gZm9yc2VlIHNvbWUg Y2FzZXMgd2hlcmUgaXQgaXMgbm90IGNsZWFyIHdoaWNoIGlzIHRoZSBwcmltYXJ5IGFuZCB3aGlj aCBpcyB0aGUgZXh0ZW5zaW9uLiZuYnNwOyBUaGVyZSBtYXkgbm90IGJlIGEgY2xlYXIgd2lubmVy Ljxicj4NCjxicj4NCkEgY291cGxlIG9mIGV4YW1wbGVzICh0aGVzZSBhcmUgbmVjZXNzYXJpbHkg cmVhbOKApmp1c3QgcG9zc2liaWxpdGllcyk6PGJyPg0KPGJyPg0KKiBJdCBpcyBwcm9iYWJseSB1 c2VmdWwgdG8gYmUgYWJsZSB0byBleHByZXNzIHNpbWxhci9vdmVybGFwcGluZyBldmVudHMgZnJv bSBkaWZmZXJlbnQgU0VUIHByb2ZpbGVzIGluIG9uZSBTRVQuJm5ic3A7IEZvciBleGFtcGxlIGEg QmFja2NoYW5uZWwgTG9nb3V0ICZhbXA7IGEgUklTQyBzZXNzaW9uIGNhbmNlbCBldmVudC48YnI+ DQo8YnI+DQoqIFNDSU0gbWF5IHdhbnQgdG8gcmVwcmVzZW50IGEgc2luZ2xlIHRyYW5zYWN0aW9u IGFzIGNhdXNpbmcgbXVsdGlwbGUgc3RhdGUgY2hhbmdlcyBpbiBhbiBldmVudCAoZS5nLiBhIHBh c3N3b3JkIGNoYW5nZSBjYXVzZXMgbXVsdGlwbGUgZWZmZWN0cykuIEhhdmluZyB0byBjaGFzZSBk b3duIG11bHRpcGxlIGV2ZW50cyBhbmQgY29ycmVsYXRlIGJ5IOKAnHR4buKAnSB3b3VsZCBiZSBj aGFsbGVuZ2luZyBpbiBhIG11bHRpLXRocmVhZGVkL211bHRpLW5vZGUNCiBkZWxpdmVyeSBzeXN0 ZW0uJm5ic3A7ICZuYnNwO1RoZSBTQ0lNIGxpc3QgaGFzIG5vdCBkaXNjdXNzZWQgdGhpcywgYnV0 IEkgd291bGQgbm90IHdhbnQgdG8gYmxvY2sgdGhpcyBjYXBhYmlsaXR5LiZuYnNwOyBJT1cgLSBK dXN0IGJlY2F1c2UgUklTQyBkb2VzIG5vdCB3YW50IHRvIGV4cHJlc3MgbXVsdGlwbGUgZXZlbnRz IGRvZXMgbm90IG1ha2UgdGhpcyB0cnVlIGZvciBvdGhlciBwcm9maWxlcy48YnI+DQo8YnI+DQoq IFdlIG1heSB3aXNoIHRvIGluZGljYXRlIGEgU0NJTSBQYXNzd29yZCBSZXNldCB3YXMgcGVyZm9y bWVkIGFuZCBhIExvZ291dC9zZXNzaW9uIGNhbmNlbGxhdGlvbiBpcyBleHByZXNzZWQgYXQgdGhl IHNhbWUgdGltZS4mbmJzcDsgVGhlIGV2ZW50cyBhcmUgcmVsYXRlZCBidXQgZXhwcmVzcyBkaWZm ZXJlbnQgZGF0YS48YnI+DQo8YnI+DQpBdm9pZGluZyBDb25mdXNpb24gRnJvbSBTaW1pbGFyIEV2 ZW50cyBPcmlnaW5hdGluZyBmcm9tIHRoZSBTYW1lIFRyYW5zYWN0aW9uPGJyPg0KPGJyPg0KSWYg ZXZlbnRzIGFyZSBzZW50IHNlcGFyYXRlbHksIHRoZW4gbW9yZSB0cmFja2luZyBvZiBzdGF0ZSAo ZS5nLiBieSB0eG4pIHdvdWxkIGJlIHJlcXVpcmVkIHRvIGVuc3VyZSBzaW1pbGFyIGV2ZW50cyBh cmUgbm90IG1pc3Rha2VuIG9yIGhhbmRsZWQgYXMgcmVwZWF0cy4gV2hpbGUgdHhuIHByb3ZpZGVz IHVzZWZ1bCBhdWRpdCBhbmFseXNpcyBjYXBhYmlsaXR5LCBJ4oCZbSBub3Qgc3VyZSBpdCBjYW4g YmUgdXNlZCBpbiBsaXZlIG9yIG5lYXItcmVhbA0KIHRpbWUgc3lzdGVtcyBnaXZlbiBkaXN0cmli dXRlZCBtdWx0aS1ub2RlLCBtdWx0aS10aHJlYWRpbmcgYXJjaGl0ZWN0dXJlcy48YnI+DQo8YnI+ DQpQcmV2aW91cyBEaXNjdXNzaW9uPGJyPg0KPGJyPg0KSSBub3RlIHRoYXQgSSBvcmlnaW5hbGx5 IHJhaXNlZCBoYXZpbmcgYW4gYXR0cmlidXRlIHRvIGRlc2lnbmF0ZSBwcmltYXJ5IGV2ZW50IGF0 dHJpYnV0ZSB0byBhbGxldmlhdGUgeW91ciBjb25jZXJuLCBidXQgdGhpcyB3YXMgbm90IGFjY2Vw dGVkLiBTZWU6PGJyPg0KPGJyPg0KKjxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0t MzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEw ODBtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0 NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbC0yRGFyY2hpdmVfd2ViX2lkLTJEZXZlbnRfY3Vy cmVudF9tc2cwMDQwNi5odG1sJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1 WXFQa0FJMWFMY0xONEtaTkEmYW1wO209WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlL QVRrUmxRRzFpdyZhbXA7cz1TM3NNVmlxTXZFZ253R2JKd09RTnljck95cjdTZWZwcV9Nb0ZPS2NF ZUNFJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3VycmVudC9tc2cw MDQwNi5odG1sPC9zcGFuPjwvYT48YnI+DQo8YnI+DQoqPHNwYW4gY2xhc3M9Im02MzM3NDQwODk2 MTUzMjc5ODM0bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQw MjkzNzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02 OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfaWQt MkRldmVudF9jdXJyZW50X21zZzAwMTQwLmh0bWwmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdO eTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1ZQkNHbEs5bWpqaGNGc2otMnREa24z MUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtzPUd5OWd5Um9JSXRhLWNTaFY3Yk4xNjFheTR5RTZy OUcxX0FhX05lQm55bGcmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pZC1ldmVudC9j dXJyZW50L21zZzAwMTQwLmh0bWw8L3NwYW4+PC9hPjxicj4NCjxicj4NClRoZSBjb25zZW5zdXMs IGF0IGxlYXN0IGFzIEkgaW50ZXJwcmV0ZWQgaXQgaXMgdXAgdG8gdGhlIHJlY2VpdmVyIHRvIGZp Z3VyZSB0aGlzIG91dCBiYXNlZCBvbiB0aGUgZGVmaW5pdGlvbnMgaXQgaGFzIGZvciBlYWNoIGV2 ZW50IFVSSSBhbmQgdGhlIHByb2ZpbGVzIHRoZXkgcmVwcmVzZW50LiBJT1cgLSBSSVNDIGlzIGZy ZWUgdG8gbGltaXQgdGhhdCBvbmx5IG9uZSBSSVNDIGV2ZW50IGJlIGV4cHJlc3NlZCBhdCBhIHRp bWUuPGJyPg0KPGJyPg0KUGhpbDxicj4NCjxicj4NCk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRp dHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0PGJyPg0KPGJyPg0KQGluZGVwZW5kZW50aWQ8YnI+ DQo8YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cC0zQV9fd3d3LmluZGVwZW5kZW50aWQuY29tJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1Ax WXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21h bnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209WUJDR2xLOW1qamhjRnNqLTJ0 RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZhbXA7cz05TlA1bmFtZzZySVZ6d3VuOWMtMXEwd2hz eVh3U3Z0SEIwZjJkS2tmQ1g4JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9 Im02MzM3NDQwODk2MTUzMjc5ODM0bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4 MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2 MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNv bSZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVl YXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5B JmFtcDttPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmYW1wO3M9 OU5QNW5hbWc2cklWend1bjljLTFxMHdoc3lYd1N2dEhCMGYyZEtrZkNYOCZhbXA7ZT0iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vd3d3LmluZGVwZW5k ZW50aWQuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGJyPg0KPGEgaHJlZj0ibWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5 NjE1MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0 MDI5Mzc3ODE1NjEwODBtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFt Njk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGls Lmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg T24gT2N0IDIzLCAyMDE3LCBhdCA3OjAyIFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZTxi cj4NCiZuYnNwOyAmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29t IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cmljaGFubmFAYW1h em9uLmNvbTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9Im02MzM3NDQwODk2MTUzMjc5ODM0bS0zMTUx NDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0t NDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYw NzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cmljaGFubmFAYW1hem9uLmNvbTwv c3Bhbj48L2E+Jmd0OyZndDsNCiB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoZSBj dXJyZW50IGRyYWZ0IG9mIHRoZSBTRVQgc3BlYyBhbGxvd3MgZm9yIGV4cHJlc3NpbmcgbXVsdGlw bGU8YnI+DQombmJzcDsgJm5ic3A7IGV2ZW50cyB3aXRoaW4gdGhlIHNhbWUgdG9rZW4sIHdoaWNo IGludHJvZHVjZXMgYWRkaXRpb25hbCBjb21wbGV4aXR5PGJyPg0KJm5ic3A7ICZuYnNwOyBhbmQg cm9vbSBmb3IgYW1iaWd1b3VzIHNlbWFudGljcy4gV2XigJl2ZSBkaXNjdXNzZWQgdGhpcyBpbiB0 aGUgT0lERjxicj4NCiZuYnNwOyAmbmJzcDsgUklTQyB3b3JraW5nIGdyb3VwIGFuZCB0aGUgY3Vy cmVudCBjb25zZW5zdXMgdGhlcmUgaXMgdGhhdCBSSVNDIHdpbGw8YnI+DQombmJzcDsgJm5ic3A7 IHJlcXVpcmUgdGhhdCBSSVNDIGV2ZW50cyBtdXN0IGJlIHRoZSBvbmx5IGV2ZW50IGluIHRoZSBT RVQsIGhhdmluZzxicj4NCiZuYnNwOyAmbmJzcDsgaWRlbnRpZmllZCB3YXlzIHRvIGNsZWFybHkg YW5kIGVhc2lseSBzdXBwb3J0IHRoZSBoYW5kZnVsIG9mIHVzZTxicj4NCiZuYnNwOyAmbmJzcDsg Y2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgdG9rZW4gdGhhdCBwZW9wbGUgaGF2ZSByYWlz ZWQuIFdpdGg8YnI+DQombmJzcDsgJm5ic3A7IHRoYXQgY29udGV4dCBpbiBtaW5kLCBJIHByb3Bv c2Ugc3RyaWtpbmcgdGhlIGRlZmluaXRpb24gb2YgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyDigJxl dmVudHPigJ0gY2xhaW0gZnJvbSB0aGUgU2VjdXJpdHkgRXZlbnQgVG9rZW4gc3BlYywgYW5kIHJl cGxhY2luZyBpdDxicj4NCiZuYnNwOyAmbmJzcDsgd2l0aCB0aGUgZm9sbG93aW5nIGRlZmluaXRp b24gZm9yIGFuIOKAnGV2ZW504oCdIGNsYWltIChzaW5ndWxhcik6PGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyBldmVudDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgQSBKU09OIG9iamVjdCBjb250 YWluaW5nIGFuICZxdW90O2V2ZW50X3R5cGUmcXVvdDsgbWVtYmVyIHdob3NlIHZhbHVlIGlzIGEg VVJJPGJyPg0KJm5ic3A7ICZuYnNwOyByZXByZXNlbnRpbmcgYSB0eXBlIG9mIGV2ZW50IGRlZmlu ZWQgaW4gYSBQcm9maWxpbmcgU3BlY2lmaWNhdGlvbi48YnI+DQombmJzcDsgJm5ic3A7IFRoZSBv YmplY3QgTUFZIG90aGVyd2lzZSBiZSBlbXB0eSwgb3IgTUFZIGNvbnRhaW4gYWRkaXRpb25hbCBt ZW1iZXJzPGJyPg0KJm5ic3A7ICZuYnNwOyBhcyBkZXNjcmliZWQgYnkgdGhlIFByb2ZpbGluZyBT cGVjaWZpY2F0aW9uLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSGVyZSBpcyB0aGUgZXhhbXBs ZSBTRVQgZnJvbSBzZWN0aW9uIDIuMywgcmV3cml0dGVuIHdpdGggdGhpcyBjaGFuZ2U8YnI+DQom bmJzcDsgJm5ic3A7IG1pbmQ6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJt NjMzNzQ0MDg5NjE1MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMz MDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0 MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ezxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7Jm5ic3A7ICZxdW90O2p0aSZxdW90OzogJnF1b3Q7NGQzNTU5ZWM2NzUwNGFhYmE2NWQ0MGIw MzYzZmFhZDgmcXVvdDssPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJnF1 b3Q7aWF0JnF1b3Q7OiAxNDU4NDk2NDA0LDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 Jm5ic3A7JnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBs ZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6 Ly9zY2ltLmV4YW1wbGUuY29tPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ibTYzMzc0NDA4OTYxNTMy Nzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3 NzgxNTYxMDgwbS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3 NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPiZsdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9zY2ltLmV4YW1w bGUuY29tLzwvc3Bhbj48L2E+Jmd0OyZxdW90Oyw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyZuYnNwOyAmcXVvdDthdWQmcXVvdDs6IFs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBs ZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85 OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0PC9zcGFuPjwvYT4mcXVvdDssPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7JnF1b3Q7PGEgaHJlZj0iaHR0cHM6 Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NjaW0uZXhhbXBs ZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNzwvc3Bhbj48L2E+JnF1b3Q7PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgXSw8YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyZuYnNwOyAmcXVvdDtldmVudCZxdW90Ozogezxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2V2ZW50X3R5cGUmcXVvdDs6 ICZxdW90O3VybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OmNyZWF0ZSZxdW90Oyw8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtyZWYmcXVvdDs6 ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9Vc2Vycy80NGY2MTQyZGY5 NmJkNmFiNjFlNzUyMWQ5IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL1VzZXJzLzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIx ZDk8L3NwYW4+PC9hPiZxdW90Oyw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmcXVvdDthdHRyaWJ1dGVzJnF1b3Q7OiBbJnF1b3Q7aWQmcXVvdDssICZx dW90O25hbWUmcXVvdDssICZxdW90O3VzZXJOYW1lJnF1b3Q7LCAmcXVvdDtwYXNzd29yZCZxdW90 OywgJnF1b3Q7ZW1haWxzJnF1b3Q7XTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5i c3A7IH08YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IH08YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 IERvZXMgYW55b25lIGluIHRoZSB3b3JraW5nIGdyb3VwIGhhdmUgdXNlIGNhc2VzIGZvciBTRVRz IHRoYXQgY2Fubm90PGJyPg0KJm5ic3A7ICZuYnNwOyBiZSBtZXQgYnkgdGhpcyBwcm9wb3NlZCB0 ZXh0PyBXaXRoaW4gUklTQywgd2UgaWRlbnRpZmllZCB0aHJlZSB1c2U8YnI+DQombmJzcDsgJm5i c3A7IGNhc2VzLCB3aXRoIHNvbHV0aW9ucyBvdXRsaW5lZCBiZWxvdzo8YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICoqPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAqRXh0ZW5zaW9ucyo8YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7IEV2ZW50IGV4dGVuc2lvbiBtZWNoYW5pc21zIGNhbiBiZSBkZWZp bmVkIGludGVybmFsIHRvIHRoZSBldmVudDxicj4NCiZuYnNwOyAmbmJzcDsgb2JqZWN0LiBBIHNp bXBsZSBhcHByb2FjaCB3b3VsZCBiZSB0byAmbmJzcDtkZWZpbmUgYW4g4oCcZXh0ZW5zaW9uc+KA nSBtZW1iZXI8YnI+DQombmJzcDsgJm5ic3A7IHRoYXQgaXMgYSBsaXN0IG9mIGV2ZW50IG9iamVj dHMgKG9yIHNldCByZXNlbWJsaW5nIHRoZSDigJxldmVudHPigJ08YnI+DQombmJzcDsgJm5ic3A7 IGNsYWltIGFzIGRlZmluZWQgaW4gdGhlIGN1cnJlbnQgc3BlYykuIFRoaXMgaGFzIHRoZSBhZHZh bnRhZ2Ugb2Y8YnI+DQombmJzcDsgJm5ic3A7IG1ha2luZyBpdCBjbGVhciBpbiB0aGUgZGF0YSBz dHJ1Y3R1cmUgdGhhdCB0aGVyZSBpcyBhIHNpbmdsZSBwcmltYXJ5PGJyPg0KJm5ic3A7ICZuYnNw OyBldmVudCwgd2l0aCB6ZXJvIG9yIG1vcmUgZXh0ZW5zaW9ucy4gVGhlcmUgaXMgbm8gcm9vbSBm b3IgY29uZnVzaW9uPGJyPg0KJm5ic3A7ICZuYnNwOyBvdmVyIHdoaWNoIGV2ZW50IGlzIHByaW1h cnksIG9yIGlmIHRoZXJlIGlzIGEgcHJpbWFyeSBldmVudCBhdCBhbGwuPGJyPg0KJm5ic3A7ICZu YnNwOyBJIHdvdWxkIGJlIGZpbmUgd2l0aCBhZGRpbmcgc29tZXRoaW5nIGxpa2UgdGhpcyB0byBt eSBwcm9wb3NlZCB0ZXh0LDxicj4NCiZuYnNwOyAmbmJzcDsgaWYgdGhlcmUgaXMgY29uc2Vuc3Vz IHRoYXQgaXQgaXMgYnJvYWRseSB1c2VmdWwuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAqQWxp YXNlcyo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoaXMgdXNlIGNhc2Ugd2FzIGJyb3VnaHQg dXAgaW4gdGhlIGNvbnRleHQgb2YgbWlncmF0aW5nIGNsaWVudHM8YnI+DQombmJzcDsgJm5ic3A7 IGZyb20gZHJhZnQgZXZlbnQgbmFtZXMgdG8gc3RhbmRhcmRpemVkIGV2ZW50IG5hbWVzLiBJbiB0 aGlzIGNhc2UsPGJyPg0KJm5ic3A7ICZuYnNwOyB0aGUgZXZlbnQgdHJhbnNtaXR0ZXIgY2FuIHRy YW5zbWl0IHR3byB0b2tlbnMgZm9yIHRoZSBsb2dpY2FsIGV2ZW50LDxicj4NCiZuYnNwOyAmbmJz cDsgb25lIHVzaW5nIHRoZSBvbGQgbmFtZSBhbmQgYW5vdGhlciB1c2luZyB0aGUgbmV3IG5hbWUu PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAqUmVsYXRlZCBFdmVudHMqPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyBUaGUgU0VUIHNwZWMgZGVmaW5lcyB0aGUgdHhuIGNsYWltIGFzIGEgbWVhbnMg b2YgY29ycmVsYXRpbmc8YnI+DQombmJzcDsgJm5ic3A7IGluZGVwZW5kZW50IHRva2VucyB0aGF0 IHJlbGF0ZSB0byB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgLS08c3BhbiBjbGFzcz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkz MThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwbS00Mzc3Nzg3NzU1ODcz MjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1 NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZuYnNw OyAmbmJzcDsgQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgQW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlczxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJz cDsgJm5ic3A7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDs8c3BhbiBj bGFzcz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0 Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwbS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEz ODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklk LWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ibTYzMzc0NDA4OTYxNTMyNzk4 MzRtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3Nzgx NTYxMDgwbS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5 ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5v cmc8L3NwYW4+PC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9Im02MzM3NDQw ODk2MTUzMjc5ODM0bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4 MzQwMjkzNzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMw MW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lk LTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1 WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0 Q19sTElHayZhbXA7bT1zNWJ5QmU1S0FObkdWdUFiMW1BdXBFR29KbjhYRzVKSVVVd1dHRlNpYkVj JmFtcDtzPVg4b1JTcTNJemxGN2ppUkFlWmhYcFIzZVZJMEk1OFpGZDRlRVpmZ3lvSVkmYW1wO2U9 IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNl R0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209czVieUJlNUtBTm5HVnVBYjFtQXVwRUdvSm44 WEc1SklVVXdXR0ZTaWJFYyZhbXA7cz1YOG9SU3EzSXpsRjdqaVJBZVpoWHBSM2VWSTBJNThaRmQ0 ZUVaZmd5b0lZJmFtcDtlPTwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwv c3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2 ZW50JmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2 NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEta TkEmYW1wO209WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZhbXA7 cz1Xck11UVJ3TFY4MDJpTVE0d1lCMWYyckZVR3U0emJoY1cwMDFmSzAyRVhzJmFtcDtlPSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3Nw YW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVu dCZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVl YXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5B JmFtcDttPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmYW1wO3M9 V3JNdVFSd0xWODAyaU1RNHdZQjFmMnJGVUd1NHpiaGNXMDAxZkswMkVYcyZhbXA7ZT0iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPi0tPHNwYW4gY2xhc3M9Im02MzM3NDQwODk2MTUzMjc5ODM0bS0zMTUxNDQ1OTU4NDUxMDI5 MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3 MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0 NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U3Vic2NyaWJlIHRvIHRoZTxzcGFu IGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2 OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUw MTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0 YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmFt cDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElf Sm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1w O209WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZhbXA7cz1MWU43 MkdnS1ZoSHNUNnRBcUJlLWVNb1dNdnlfN2RmRm4xdVowSEs2WXVRJmFtcDtlPSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkhBUkRUV0FSRTwvc3Bhbj48L2E+PHNw YW4gY2xhc3M9Im02MzM3NDQwODk2MTUzMjc5ODM0bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYz NDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0t NTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2 NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5tYWlsDQogbGlzdCB0byBsZWFy biBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+ DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBj dHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1 cnVpYjlLQVRrUmxRRzFpdyZhbXA7cz1Xck11UVJ3TFY4MDJpTVE0d1lCMWYyckZVR3U0emJoY1cw MDFmSzAyRVhzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 cHVycGxlIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0Fn JmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9 bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1ZQkNHbEs5 bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtzPVdyTXVRUndMVjgwMmlN UTR3WUIxZjJyRlVHdTR6YmhjVzAwMWZLMDJFWHMmYW1wO2U9PC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtiYWNrZ3JvdW5kOndoaXRlIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8c3BhbiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SWQtZXZlbnQgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4N Cjwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj5JZC1ldmVu dEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lD QWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7 cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPVUtYTVI Qk5EMEhhVFg0YW5OWmZ6WDdwRHNmSzVmMGg5bVo5Q1pra0dpZWMmYW1wO3M9cnZkcnRJN3JZTlJB bnFaRGx0Q3dCQVpWSEtwLU1KMjB1aTJubTQ2UVN6MCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj5odHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENn YVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTRE cGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1VLWE1SEJORDBIYVRYNGFuTlpmelg3cERz Zks1ZjBoOW1aOUNaa2tHaWVjJmFtcDtzPXJ2ZHJ0STdyWU5SQW5xWkRsdEN3QkFaVkhLcC1NSjIw dWkybm00NlFTejAmYW1wO2U9PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0K PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+LS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj5TdWJzY3JpYmUgdG8gdGhlPHNwYW4gY2xhc3M9Im02MzM3NDQwODk2MTUz Mjc5ODM0bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkz Nzc4MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdh cmUuY29tXyZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUly TVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNM TjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cm YW1wO3M9d3RnRDNOcDB2eWhMZHBFd1VpcXNmNEl0aXdBM09tN0dyb2I3MEx4MHIzayZhbXA7ZT0i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5IQVJEVFdBUkU8L3Nw YW4+PC9hPjxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1MTAy OTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5tYWlsDQogbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0 cyBJIGFtIHdvcmtpbmcgb24hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2 ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5 WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxL Njd5Rl84dThfcVNDX3cmYW1wO3M9T2UwcWZMRVg4M3Z0WE03V2wyY1lCZS1HZzFEVlBqaFhqVkpr ZmhWUnp3YyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6 QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1peVZuclptcjlfdUdD UTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JmFtcDtzPU9lMHFmTEVYODN2dFhNN1dsMmNZ QmUtR2cxRFZQamhYalZKa2ZoVlJ6d2MmYW1wO2U9PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4N CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPi0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+U3Vic2NyaWJlIHRvIHRoZTxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1 MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5 Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3 YXJlLmNvbV8mYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJ ck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxj TE40S1pOQSZhbXA7bT1zSUd6OGd1cjR3TnFaa3RjbWFndjVFYTIxUUVpcDRIWHBFVktSYTBxaGxv JmFtcDtzPVY5Z3lUVFg5cXVqckMyVmxpd0xQeTAtS3Z4UzlwWUtKXy1reURhcHdPOGsmYW1wO2U9 IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SEFSRFRXQVJFPC9z cGFuPjwvYT48c3BhbiBjbGFzcz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEw MjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+bWFpbA0KIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVj dHMgSSBhbSB3b3JraW5nIG9uITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxicj4NCjxiciBjbGVhcj0iYWxs Ij4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iY29sb3I6Izg4ODg4OCI+U3Vic2NyaWJlIHRvIHRoZTxzcGFuIGNsYXNzPSJtNjMz NzQ0MDg5NjE1MzI3OTgzNG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0 bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0z QV9faGFyZHR3YXJlLmNvbV8mYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4 UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZ cVBrQUkxYUxjTE40S1pOQSZhbXA7bT1zSUd6OGd1cjR3TnFaa3RjbWFndjVFYTIxUUVpcDRIWHBF VktSYTBxaGxvJmFtcDtzPVY5Z3lUVFg5cXVqckMyVmxpd0xQeTAtS3Z4UzlwWUtKXy1reURhcHdP OGsmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SEFS RFRXQVJFPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0 NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+bWFpbA0KIGxpc3QgdG8gbGVhcm4gYWJv dXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9y OiM4ODg4ODgiPi0tPHNwYW4gY2xhc3M9Im02MzM3NDQwODk2MTUzMjc5ODM0bS0zMTUxNDQ1OTU4 NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29s b3I6Izg4ODg4OCI+U3Vic2NyaWJlIHRvIHRoZTxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3 OTgzNG0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3 ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJl LmNvbV8mYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1V QjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40 S1pOQSZhbXA7bT1zSUd6OGd1cjR3TnFaa3RjbWFndjVFYTIxUUVpcDRIWHBFVktSYTBxaGxvJmFt cDtzPVY5Z3lUVFg5cXVqckMyVmxpd0xQeTAtS3Z4UzlwWUtKXy1reURhcHdPOGsmYW1wO2U9IiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SEFSRFRXQVJFPC9zcGFu PjwvYT48c3BhbiBjbGFzcz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0NTEwMjkz MThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+bWFpbA0KIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMg SSBhbSB3b3JraW5nIG9uITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0tMzE1 MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0aG9lbnpiIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM4ODg4ODg7YmFja2dyb3VuZDp3aGl0ZSI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9Im02MzM3NDQwODk2MTUzMjc5ODM0bS0z MTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRob2VuemIiPjxzcGFuIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj5JZC1ldmVudCBtYWlsaW5nIGxpc3Q8L3NwYW4+PC9zcGFuPjxi cj4NCjwvc3Bhbj48c3BhbiBjbGFzcz0ibTYzMzc0NDA4OTYxNTMyNzk4MzRtLTMxNTE0NDU5NTg0 NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNGhvZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlO2JhY2tncm91bmQ6d2hpdGUiPklkLWV2ZW50 QGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 Izg4ODg4OCI+PGJyPg0KPC9zcGFuPjxzcGFuIGNsYXNzPSJtNjMzNzQ0MDg5NjE1MzI3OTgzNG0t MzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0aG9lbnpiIj48c3BhbiBzdHls ZT0iY29sb3I6Izg4ODg4OCI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0y RGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJN VUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xO NEtaTkEmYW1wO209c0lHejhndXI0d05xWmt0Y21hZ3Y1RWEyMVFFaXA0SFhwRVZLUmEwcWhsbyZh bXA7cz1nZE5yczdVREF0dHBhYmpNNW5kT1h3V0ttWnVLYVhFYlQ1d3U5cmNPUlYwJmFtcDtlPSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlO2JhY2tncm91bmQ6 d2hpdGUiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6cHVycGxlO2JhY2tncm91bmQ6d2hpdGUiPi48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpwdXJwbGU7YmFja2dyb3VuZDp3aGl0ZSI+Y29tL3YyL3VybD91PWh0dHBzLTNBX193 d3cuaWU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGU7YmFja2dyb3VuZDp3aGl0 ZSI+dDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRl Ij5mLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj52PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6cHVycGxlO2JhY2tncm91bmQ6d2hpdGUiPmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1 bUNYQ2dhV0g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGU7YmFja2dyb3VuZDp3 aGl0ZSI+djwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndo aXRlIj5sWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpwdXJwbGU7YmFja2dyb3VuZDp3aGl0ZSI+cjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj49bmE1RlZ6QlRXbWFucVdOeTREcGN0 eVhQcHVZcTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndo aXRlIj5QPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlO2JhY2tncm91bmQ6d2hp dGUiPmtBSTFhTGNMTjRLWk5BJmFtcDttPXNJR3o4Z3VyNHdOcTwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj5aPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6cHVycGxlO2JhY2tncm91bmQ6d2hpdGUiPmt0Y21hZ3Y1RWEyMVFFaXA0SFhwRVZL UmEwcWhsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlO2JhY2tncm91bmQ6d2hp dGUiPm88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGU7YmFja2dyb3VuZDp3aGl0 ZSI+JmFtcDtzPWdkTnJzN1VEQXR0cGFiak01bmRPWHdXS21aPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6cHVycGxlO2JhY2tncm91bmQ6d2hpdGUiPnU8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpwdXJwbGU7YmFja2dyb3VuZDp3aGl0ZSI+S2FYRWJUNXd1OXJjT1JWMCZhbXA7ZT08 L3NwYW4+PC9hPjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVu dEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1l dmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk LWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_07169FA765424EBB987F5D39190B214Aamazoncom_-- From nobody Wed Nov 1 15:55:13 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2788613F6A4 for ; Wed, 1 Nov 2017 15:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.818 X-Spam-Level: X-Spam-Status: No, score=-11.818 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 OLKSK5pHhosG for ; Wed, 1 Nov 2017 15:55:06 -0700 (PDT) Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63A713FF09 for ; Wed, 1 Nov 2017 15:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1509576905; x=1541112905; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NfHfZ/Wcc9Oj2/N1uUMnWUGowqNJmcuZPTCzGp9y96c=; b=rMztUylpHAKYYN0Tgk4fsjLSYhejldBGNNmbyOf15c6auPiJGQsAr7dy rsUHIbSktooDJb4jETFdYuSL5VPZRU2oC+euBr8J530gCfIvO6Zn8OhxC sWLCY2oreK2aruyUizPM4UCWhdvuthsbRjGLlc0S6znM6gKVZ/Y5BNEn2 8=; X-IronPort-AV: E=Sophos;i="5.44,331,1505779200"; d="scan'208,217";a="314528982" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2a-1c1b5cdd.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2017 22:54:55 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2a-1c1b5cdd.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id vA1Msq1R088028 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2017 22:54:52 GMT Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 1 Nov 2017 22:54:50 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 1 Nov 2017 22:54:50 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Wed, 1 Nov 2017 22:54:49 +0000 From: "Richard Backman, Annabelle" To: "Phil Hunt (IDM)" , Marius Scurtescu CC: William Denniss , Yaron Sheffer , Mike Jones , "ID Events Mailing List" , Dick Hardt Thread-Topic: [Id-event] Use cases for multiple events per SET? Thread-Index: AQHTTGwev6cV0D/tE06azbqzz7my9aLyXLkAgAEBjXCAB9BnAIAAT1IAgAAUagCAAQQ9AIAANauAgAAlNACAAAV2gIABcZJQgACUvYCAAADCcIAAA1kAgAASxcCAALLVgIAAG18AgAARHoCAAAeDAIAAH3gAgAACjICAAAIzgIAAA0OAgAANhAA= Date: Wed, 1 Nov 2017 22:54:49 +0000 Message-ID: <8B223079-B4DF-492A-8082-90732DCF2C52@amazon.com> References: <2FF066DE-A1EB-4656-AC23-74FC11104FFA@amazon.com> <48EAF13C-5A37-4D22-A649-8257A49F8EC7@oracle.com> <57447694-2AA9-4987-BB99-9E5FD358F562@oracle.com> <65C74B5D-9BDE-4FEA-9D02-0F041DC11A0F@amazon.com> <541716DB-A028-4A1C-A9A8-A8EC9EE3A76A@oracle.com> <26D99BCD-3647-452A-90BA-8F13761A1362@oracle.com> <6DF29D13-F11E-4140-BB39-A88A4FD0B335@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.16] Content-Type: multipart/alternative; boundary="_000_8B223079B4DF492A808290732DCF2C52amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] Use cases for multiple events per SET? X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 22:55:12 -0000 --_000_8B223079B4DF492A808290732DCF2C52amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGhpbCwgSSBkb27igJl0IGZvbGxvdyB3aGF0IHlvdeKAmXJlIGRlc2NyaWJpbmcgaW4gdGhpcyBz Y2VuYXJpby4gQ2FuIHlvdSBwcm92aWRlIGFuIGV4YW1wbGU/DQoNCi0tDQpBbm5hYmVsbGUgUmlj aGFyZCBCYWNrbWFuDQpJZGVudGl0eSBTZXJ2aWNlcw0KDQoNCkZyb206ICJQaGlsIEh1bnQgKElE TSkiIDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgTm92ZW1iZXIgMSwg MjAxNyBhdCAzOjA3IFBNDQpUbzogTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUu Y29tPg0KQ2M6IFdpbGxpYW0gRGVubmlzcyA8d2Rlbm5pc3NAZ29vZ2xlLmNvbT4sICJSaWNoYXJk IEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb20+LCBZYXJvbiBTaGVmZmVy IDx5YXJvbmYuaWV0ZkBnbWFpbC5jb20+LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20+LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZz4sIERp Y2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0g VXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD8NCg0KSSBkb24ndCBzZWUgbXVs dGkgdmFyaWFudHMuIEkgc2VlIG11bHRpcGxlIHBhcnRzDQoNCkZvciBleGFtcGxlIHlvdSBoYXZl IGFsbCB0aGUgcmlzYyBldmVudHMNCg0KTm90IHRvIHN1cHBvcnQgaW1wbGljaXQgZmVkZXJhdGlv biB1c2VycyAod2hpY2ggaGF2ZSB0byBiZSBpZGVudGlmaWVkIGJ5IG9uZSBvciBtb3JlIGlkZW50 aWZpZXJzKSwgeW91IG1pZ2h0IGRlZmluZSBhIHV0aWxpdHkgZXZlbnQgcHJvZmlsZSB3aGljaCBj b250YWlucyBhdHRyaWJ1dGVzIGZvciBlbWFpbCwgdGVsZXBob25lLCB1c2VybmFtZSBldGMuDQoN CklmIHlvdSBkaWRuJ3QgZ2V0IGJvdGggcGFydHMgb2YgdGhlIHNldCBhcyBvbmUgc2V0IGl0IHdv dWxkIGhhdmUgZGlmZmVyZW50IG1lYW5pbmcgb3IgYmUgY29uc2lkZXJlZCBtYWxmb3JtZWQuDQoN ClRoZSBhZHZhbnRhZ2UgaW4gcmlzYyBpcyBub3QgaGF2aW5nIHRvIGhhdmUgYSB0b25uZSBvZiBv cHRpb25hbCBpZCBhdHRyaWJ1dGVzIGluIGV2ZXJ5IGV2ZW50Lg0KDQpUaGUgcG9pbnQgaGVyZSBp cyByZWFzb25hYmxlIGZsZXhpYmlsaXR5IGZvciBwcm9maWxlcnMgdG8gZGVjaWRlLg0KDQpGaW5h bGx5IGkgYWxyZWFkeSBnYXZlIHRoZSBvdmVybGFwcGVkIHJpc2Mvc2NpbSBwYXNzd29yZCByZXNl dCBjYXNlLg0KDQpQaGlsDQoNCk9uIE5vdiAxLCAyMDE3LCBhdCAyOjU0IFBNLCBNYXJpdXMgU2N1 cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNv bT4+IHdyb3RlOg0KT24gV2VkLCBOb3YgMSwgMjAxNyBhdCAyOjQ2IFBNLCBXaWxsaWFtIERlbm5p c3MgPHdkZW5uaXNzQGdvb2dsZS5jb208bWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20+PiB3cm90 ZToNClBlcmhhcHMgSSBjYW4gdHJ5IGFuZCBleHBsYWluIHRoZSBvcmlnaW5hbCBpbnRlbnQgb2Yg dGhlIGN1cnJlbnQgZGVzaWduLiBUaGUgZ29hbCB3YXMgYWx3YXlzIHRoYXQgYSBTRVQgcmVwcmVz ZW50cyBhIHNpbmdsZSBsb2dpY2FsIGV2ZW50LiBIb3dldmVyIG11bHRpcGxlIHN5c3RlbXMgbWF5 IGhhdmUgZGlmZmVyZW50IHJlcHJlc2VudGF0aW9ucyBvZiB0aGUgZXZlbnQg4oCTIHRoZSBleGFt cGxlIGdpdmVuIG9yaWdpbmFsbHkgd2FzIG9uZSBmb3JtYXR0ZWQgZm9yIFJJU0MsIGFuZCBvbmUg Zm9yIFNDSU0uDQoNCkEgZ29vZCBhbmFsb2d5IGlzIGVtYWlsLiBZb3Ugc2VuZCBhIHNpbmdsZSBs b2dpY2FsIGVtYWlsLCB3aGljaCBtYXkgaGF2ZSB0d28gcmVwcmVzZW50YXRpb25zLCBIVE1MIGFu ZCBwbGFpbiB0ZXh0LiBTeXN0ZW1zIGNhbiBjb25zdW1lIHRoZSB2ZXJzaW9uIHRoYXQgdGhleSB1 bmRlcnN0YW5kIGFuZCBpZ25vcmUgdGhlIG9uZSB0aGV5IGRvbid0Lg0KDQpZZXMsIGFuZCBJIHRo aW5rIHRoaXMgaXMgd2VsbCB1bmRlcnN0b29kLg0KDQoNCg0KSSdtIHN0YXJ0aW5nIHRvIHJlZ3Jl dCB0aGUgcGx1cmFsIGluICJldmVudHMiLCBpdCB3YXMgcGx1cmFsaXplZCBkdWUgdG8gaXQgYmVp bmcgYW4gYXJyYXksIG5vdCBiZWNhdXNlIGl0IHJlcHJlc2VudGVkIG11bHRpcGxlIGxvZ2ljYWwg ZXZlbnRzLg0KDQpJIGRvbid0IHRoaW5rIHRoaXMgaXMgdGhlIG1haW4gY29uY2VybiBvciBjYXVz ZSBmb3IgY29uZnVzaW9uLg0KDQoNCg0KQW5uYWJlbGxlLCBJIHVuZGVyc3RhbmQgeW91ciBjb25j ZXJucyByZWdhcmRpbmcgY29uZnVzaW9uIG9mIHRoZSBzZW1hbnRpY3MgYmV0d2VlbiB0aGUgSlNP TiBzeW50YXggYW5kIHRoZSBzcGVjaWZpY2F0aW9uIGxhbmd1YWdlLiBBcmUgdGhlcmUgb3RoZXIg d2F5cyB0byByZXNvbHZlIHRoYXQgd2l0aG91dCByZW1vdmluZyB0aGUgYWJpbGl0eSBmb3IgbXVs dGlwbGUgcmVwcmVzZW50YXRpb25zIG9mIHRoZSBzYW1lIGV2ZW50Pw0KDQpUaGUgYXJndW1lbnQg aXMgdGhhdCBtdWx0aXBsZSByZXByZXNlbnRhdGlvbnMgY2FuIGJlIHNlbnQgYXMgZGlzdGluY3Qg U0VUcywgaWYgcmVhbGx5IG5lZWRlZC4gSW4gcHJhY3RpY2UgdGhpcyB3aWxsIGhhcHBlbiBxdWl0 ZSByYXJlIHRob3VnaC4gRXZlbnRzIGFyZSBjcmVhdGVkIGZvciBhIHNwZWNpZmljIHJlY2VpdmVy LCB0aGUgcmVjZWl2ZXIgZWl0aGVyIHdhbnRzIHRoZSBTQ0lNIG9yIHRoZSBSSVNDIGZsYXZvciwg YW5kIHRoZXkgc2hvdWxkIGJlIGFibGUgdG8gc3BlY2lmeSB0aGF0IGluIGNvbmZpZ3VyYXRpb24g KHRoZXJlIGlzIGEgcHJvcG9zYWwgaG93IHRvIGNhcHR1cmUgdGhhdCkuDQoNCkRvIHdlIGhhdmUg YSBjb21wZWxsaW5nIHVzZSBjYXNlIHdoZXJlIGEgcmVjZWl2ZXIgbXVzdCByZWNlaXZlIG11bHRp cGxlIHZhcmlhbnRzIGFsbCBhdCBvbmNlPw0KDQoNCg0KT24gV2VkLCBOb3YgMSwgMjAxNyBhdCAy OjM3IFBNLCBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1z Y3VydGVzY3VAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KT24gV2VkLCBOb3YgMSwgMjAxNyBhdCAxMjo0 NSBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20+PiB3cm90ZToNCllvdSBjYW7igJl0IHJlYWxseSBoYXZlIG11bHRpcGxlIGV2ZW50 cyAoYXQgbGVhc3Qgb2YgdGhlIHNhbWUgdHlwZSkuICBUaGUgY3VycmVudCBzcGVjIGNhbiBvbmx5 IGhhdmUgb25lIGluc3RhbmNlIG9mIGEgVVJJIChhZmFpaykuDQoNCk5vdGUgdGhhdCB0aGUgc3Bl YyBub3JtYXRpdmVseSBkb2VzIG5vdCBzdXBwb3J0IG11bHRpcGxlIGV2ZW50IFNFVFMuICBJdCBj dXJyZW50bHkgc3RhdGVzOg0KDQpldmVudHMNCg0KICAgICAgVGhlIHNlbWFudGljcyBvZiB0aGlz IGNsYWltIGlzIHRvIGRlZmluZSBhIHNldCBvZiBldmVudCBzdGF0ZW1lbnRzDQoNCiAgICAgIHRo YXQgZWFjaCBNQVkgYWRkIGFkZGl0aW9uYWwgY2xhaW1zIHRvIGZ1bGx5IGRlc2NyaWJlIGEgc2lu Z2xlDQoNCiAgICAgIGxvZ2ljYWwgZXZlbnQgdGhhdCBoYXMgb2NjdXJyZWQgKGUuZy4gYSBzdGF0 ZSBjaGFuZ2UgdG8gYQ0KDQogICAgICBzdWJqZWN0KS4gIE11bHRpcGxlIGV2ZW50IHN0YXRlbWVu dHMgb2YgdGhlIHNhbWUgdHlwZSBTSEFMTCBOT1QgYmUNCg0KICAgICAgYWNjZXB0ZWQuICBUaGUg ImV2ZW50cyIgY2xhaW0gU0hPVUxEIE5PVCBiZSB1c2VkIHRvIGV4cHJlc3MNCg0KICAgICAgbXVs dGlwbGUgbG9naWNhbCBldmVudHMuDQoNClRoZSBzcGVjIGhhcyAqYWx3YXlzKiBzdXBwb3J0ZWQg cmVxdWlyZW1lbnRzIChhcyBzdGF0ZWQgaW4gdGhlIHNwZWMpIGZvciBtdWx0aXBsZSBzZXBhcmF0 ZSBwcm9maWxlIHN0YXRlbWVudHMgKGZyb20gb25lIG9yIG1vcmUgcHJvZmlsZSBmYW1pbGl0aWVz KSBuZWVkaW5nIHRvIGJlIHNlbnQgYXMgYSBzaW5nbGUgbWVzc2FnZS4gIEl0IHdvdWxkIGJlIElO U0VDVVJFIHRvIGZvcmNlIG11bHRpcGxlIFNFVHMgYmVjYXVzZSB0aGUgY3VycmVudCBkZWxpdmVy eSBtZWNoYW5pc20gb25seSBhbGxvd3Mgb25lIFNFVCB0byBiZSBkZWxpdmVyZWQgYXQgYSB0aW1l LiBUaGVyZSBpcyBubyB3YXkgdG8gYXNzdXJlIHRoYXQgYSBzaW5nbGUgcmVjZWl2ZXIgZ2V0cyBh bGwgb2YgdGhlIFNFVHMgaXQgbmVlZHMgaW4gYSBtdWx0aS10aHJlYWRlZCwgbXVsdGktbm9kZSBl bnZpcm9ubWVudCBhdCBzY2FsZS4gIEFzc2VtYmxpbmcgbXVsdGlwbGUgU0VUcyB0byB0cmFjayDi gJx0eG7igJ0gaW4gYSBjb21tb24gc3RhdGUgZGF0YWJhc2UgaXMgTk9UIHNpbXBsZSBub3IgY29z dCBlZmZlY3RpdmUuDQoNCkkgdG90YWxseSBhZ3JlZSB0aGF0IGl0IGlzIGRpZmZpY3VsdCBmb3Ig cmVjZWl2ZXJzIHRvIHJlY2VpdmUgc2VwYXJhdGUgZXZlbnRzLCBpbiBubyBwYXJ0aWN1bGFyIG9y ZGVyIGFuZCBjb3JyZWxhdGUgYmFzZWQgb24gInR4biIuIEJ1dCwgcmVjZWl2ZXJzIGhhdmUgdG8g c29sdmUgdGhpcyBpc3N1ZSByZWdhcmRsZXNzIG9mICJldmVudHMiIG9yICJldmVudCIsIHNvIGl0 IGlzIHVucmVsYXRlZCB0byB0aGlzIHByb3Bvc2FsLg0KDQoNCg0KSWYgd2UgYWNjb21tb2RhdGUg dGhpcyBpbiB0aGUgcHJvcG9zZWQgZm9ybSwgd2UgZW5kIHVwIHdpdGggYSBjb21wbGV4LCBkZWVw bHkgbmVzdGVkIEpTT04gc3RydWN0dXJlIHdpdGggdGhlIHBvc3NpYmlsaXR5IG9mIG5hbWVzcGFj ZSBjb25mbGljdHMuDQoNCklNTyBUaGUgcHJvcG9zYWwgZG9lcyBub3Qgc2ltcGxpZnksIGl0IGNv bXBsaWNhdGluZyBhbmQgbGltaXRpbmcuDQoNClRoZSBjdXJyZW50IHNwZWMgaGFzIHZlcnkgY2xl YW4gSlNPTiBhbmQgYXZvaWRzIG5hbWVzcGFjZSBjb25mbGljdHMgYmV0d2VlbiBwcm9maWxlcy4g SSB0aGluayB3ZSBzaG91bGQgc3RheSBvbiB0cmFjayB3aXRoIHRoZSBjdXJyZW50IGRyYWZ0IGFu ZCBvYnNlcnZlIHRoZSBub3JtYXRpdmUgdGV4dCBpZiBub3QgbWFrZSBpdCBzdHJvbmdlciBpbiBy ZWdhcmRzIHRvIG11bHRpLWV2ZW50cyAodW5kZXJzdG9vZCB0aGF0IE1pa2UgbWF5IGRpc2FncmVl KS4NCg0KUGhpbA0KDQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2Vz IEFyY2hpdGVjdA0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fd3d3LmluZGVwZW5k ZW50aWQuY29tJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVl YXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT11 TmlXUWx5S0dUdS05cDVxSkxSUzFGLTN5S1hwREFCN0t0cGtDRGNfSkNVJnM9bHJjV3RMbzZaQV8y cG9ZWndteW1paWljTmx3eWt5UUpvazNHZWNjR0FZWSZlPT4NCnBoaWwuaHVudEBvcmFjbGUuY29t PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KT24gTm92IDEsIDIwMTcsIGF0IDEyOjE4 IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWls dG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KDQpVbmxlc3MgdGhlIHByb2ZpbGUgZ3Vh cmFudGVlcyB0aGF0IHN1Y2ggcmVsYXRlZCBldmVudHMgd2lsbCBhbHdheXMgYmUgaW5jbHVkZWQg aW4gdGhlIHNhbWUgU0VULCB0aGVuIHRoZSByZWNlaXZlciBoYXMgdG8gY29ycmVsYXRlIGFjcm9z cyBTRVRzIGFueXdheSwgYW5kIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUIGlzIGp1c3QgZ2l2aW5n IHRoZSByZWNlaXZlciBhbm90aGVyIHNjZW5hcmlvIHRoYXQgdGhleSBoYXZlIHRvIHN1cHBvcnQu DQoNCknigJl2ZSBhbHJlYWR5IHByb3ZpZGVkIHNldmVyYWwgb3RoZXIgcmVhc29ucyB3aHkgd2Ug c2hvdWxkIG5vdCBzdXBwb3J0IG11bHRpcGxlIHRva2VucyBwZXIgU0VUIHRoYXQgbm8gb25lIGhh cyBhZGRyZXNzZWQuIEhlcmUgdGhleSBhcmUgYWdhaW46DQoNCiAgMS4gIE11bHRpcGxlIGV2ZW50 IHN1cHBvcnQgcmVzdWx0cyBpbiBhIG1vcmUgY29tcGxleCBzdHJ1Y3R1cmUgZm9yIHRoZSBzaW5n bGUgZXZlbnQgdXNlIGNhc2UsIHdoaWNoIEkgdGhpbmsgd2UgYWxsIGFncmVlIGlzIHRoZSBtYWpv cml0eSB1c2UgY2FzZS4NCiAgMi4gIE11bHRpcGxlLWV2ZW50IFNFVHMgaGF2ZSBhbWJpZ3VvdXMg c2VtYW50aWNzLiBUaGUgcHJlc2VuY2Ugb2YgdHdvIGV2ZW50cyBBIGFuZCBCIGluIHRoZSBzYW1l IFNFVCBjb3VsZCBtZWFuIGFueSBvZjoNCg0KICAgICAqICAgQSBhbmQgQiBhcmUgcmVsYXRlZCB0 byB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50IChpLmUuIHRoZSBzYW1lIHRoaW5nIGFzIGlmIHRoZXkg d2VyZSBmcm9tIGRpZmZlcmVudCBTRVRzIHRoYXQgaGF2ZSBhIGNvbW1vbiB0eG4pLg0KICAgICAq ICAgQSBpcyBhbiBleHRlbnNpb24gb2YgQi4NCiAgICAgKiAgIEIgaXMgYW4gZXh0ZW5zaW9uIG9m IEEuDQogICAgICogICBBIGlzIGFuIGFsaWFzIGZvciBCLCBvciB2aWNlLXZlcnNhLg0KICAgICAq ICAgQSBhbmQgQiBhcmUgbm90IGFjdHVhbGx5IHJlbGF0ZWQgdG8gb25lIGFub3RoZXIgaW4gYW55 IHdheSwgYW5kIHRoZSB0cmFuc21pdHRlciBidW5kbGVkIHRoZW0gdG9nZXRoZXIgYmVjYXVzZSB0 aGV5IHdlcmUgZ29pbmcgdG8gdGhlIHNhbWUgcmVjZWl2ZXIuDQoNCiAgMS4gIFRvcC1sZXZlbCBj bGFpbSBzZW1hbnRpY3MgYmVjb21lIGhhcmRlciB0byBkZWZpbmUsIGFzIGRpZmZlcmVudCBwcm9m aWxlcyBtYXkgd2FudCB0byB1c2UgdGhlIHNhbWUgY2xhaW1zIGluIGRpZmZlcmVudCB3YXlzLg0K ICAyLiAgRXZlbnQgYXV0aGVudGljaXR5IGNhbm5vdCBiZSB2ZXJpZmllZCB3aXRob3V0IGhhdmlu ZyB0aGUgZW50aXJlIFNFVC4gVGhpcyBmb3JjZXMgcmVjZWl2ZXJzIHRvIGV4cG9zZSBkb3duc3Ry ZWFtIHN5c3RlbXMgdG8gbW9yZSBpbmZvcm1hdGlvbiBuZWNlc3NhcnksIGlmIHRob3NlIHN5c3Rl bXMgbmVlZCB0byBiZSBhYmxlIHRvIHZlcmlmeSBhdXRoZW50aWNpdHkuDQoNCi0tDQpBbm5hYmVs bGUgUmljaGFyZCBCYWNrbWFuDQpBbWF6b24g4oCTIElkZW50aXR5IFNlcnZpY2VzDQoNCg0KRnJv bTogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBOb3ZlbWJlciAxLCAyMDE3 IGF0IDExOjIxIEFNDQpUbzogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkNjOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBn bWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+LCAiUmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24u Y29tPj4sIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzpp ZC1ldmVudEBpZXRmLm9yZz4+LCAiUGhpbCBIdW50IChJRE0pIiA8cGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NClN1YmplY3Q6IFJFOiBbSWQtZXZlbnRd IFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQ/DQoNCkkgY29tcGxldGVseSBh Z3JlZSBvbiBtb3ZpbmcgY29tcGxleGl0eSB0byB0aGUgaXNzdWVyIG92ZXIgdGhlIHJlY2lwaWVu dC4gIEluIG15IHZpZXcsIGl04oCZcyBtb3JlIGNvbXBsZXggZm9yIHJlY2lwaWVudHMgdG8gaGF2 ZSB0byBjb3JyZWxhdGUgYW5kIHByb2Nlc3MgYSBzZXF1ZW5jZSBvZiBtdWx0aXBsZSBTRVRzIHBy b3ZpZGluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50LCBhbmQgdmFs aWRhdGUgTiBzaWduYXR1cmVzLCB0aGFuIHRvIHJlY2VpdmUgb25lIFNFVCB3aXRoIGFsbCB0aGUg YXNwZWN0cyBvZiB0aGUgbG9naWNhbCBldmVudCBhcyDigJxldmVudHPigJ0gZmllbGRzLCB3aXRo IG5vIGNvcnJlbGF0aW9uIG92ZXIgdGltZSB0aGVuIHJlcXVpcmVkLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9t OiBEaWNrIEhhcmR0IFttYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb21dDQpTZW50OiBXZWRuZXNk YXksIE5vdmVtYmVyIDEsIDIwMTcgOTozOSBBTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCkNj OiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRm QGdtYWlsLmNvbT4+OyBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9u LmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0 IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+PjsgUGhpbCBIdW50 IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+ Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMg cGVyIFNFVD8NCg0KWW91ciBjb21tZW50cyBoaWdobGlnaHQgYSBjb3VwbGUgb2YgcG9pbnRzOg0K DQoxKSBUaGUgZXhhbXBsZSBpcyBob3cgdG8gaGF2ZSBhIHByZWRlZmluZWQgZXh0ZW5zaW9uIHBv aW50IGZvciBleHRlbnNpb25zIG9mIGEgc3BlY2lmaWMgZXZlbnQsIGl0IGlzIG5vdCBob3cgdG8g YWRkIGFub3RoZXIgZXZlbnQuIE15c2VsZiwgSSB0aGluayB0aGlzIGlzIG92ZXJseSBjb21wbGlj YXRlZC4gRXZlbnRzIHNob3VsZCBiZSBjb21wYXJhdGl2ZWx5IHN0YXRpYywgYW5kIGFzIHdpdGgg bWFueSBvdGhlciBKU09OIGZvcm1hdHMsIHRoZSByZWNlaXZlciBzaG91bGQgaWdub3JlIHByb3Bl cnRpZXMgaXQgZG9lcyBub3QgdW5kZXJzdGFuZCwgd2hpY2ggbGV0J3MgbmV3IHByb3BlcnRpZXMg YmUgaW50cm9kdWNlZCBhcyBleHRlbnNpb25zLiBUaGVyZSBzaG91bGQgbm90IGJlIGFueSBjb25m bGljdCBhcyBleHRlbnNpb25zIHNob3VsZCBvbmx5IGJlIGRvbmUgYnkgdGhlIHByb2ZpbGUgdGhh dCBjcmVhdGVkIHRoZSBldmVudCBmb3JtYXQgdG8gc3RhcnQgb2ZmIHdpdGguDQoNCjIpIEhhdmlu ZyBhbiBsdmFsdWUgYmUgYSBVUkkgaXMgbXVjaCBoYXJkZXIgdG8gY29kZSBhZ2FpbnN0LiBJJ20g bm90IHN1cmUgd2h5IE1hcml1cyBoYWQgdGhhdCBpbiBoaXMgZXhhbXBsZS4gUGVyIHRoZSBldmVu dCwgdGhlIHR5cGUgb2YgdGhlIGV2ZW50IGlzIHdlbGwgZGVmaW5lZCB3aXRoDQoNCiJldmVudF90 eXBlIjogImh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0RXh0IiwN Cg0KMykgVGhpcyB0aHJlYWQgaXMgYWJvdXQgcmVhc29ucyBmb3IgbXVsdGlwbGUgZXZlbnRzIHRv IGJlIGNvbnRhaW5lZCBpbiBvbmUgc2V0LiBZb3VyIG1lbnRpb24gb2YgYW4gaXNzdWVyIG5vdCB3 YW50aW5nIHRvIHNpZ24gc2VwYXJhdGUgZXZlbnRzIGFzIGEgcmVhc29uIHRvIGFsbG93IG11bHRp cGxlIGV2ZW50cy4gSSB0aGluayB3ZSBoYXZlIGRlY2lkZWQgdGhhdCBnaXZlbiBhIHByZWZlcmVu Y2UsIHdlIHdpbGwgcHVzaCBlZmZvcnQgdG8gdGhlIHRyYW5zbWl0dGVyIG92ZXIgdGhlIHJlY2Vp dmVyIGFzIGluIG1hbnkgdXNlIGNhc2VzIHRoZXJlIGFyZSBtYW55IG1vcmUgcmVjZWl2ZXJzLiBH aXZlbiB0aGF0LCBpdCBpcyBtb3JlIGNvbXBsZXggZm9yIGEgcmVjZWl2ZXIgdG8gaGF2ZSBkaWZm ZXJlbnQgd2F5cyBvZiBtYW5hZ2luZyB0aGUgcmVjZWlwdCBvZiBtdWx0aXBsZSBldmVudHMgYXMg bm90IGFsbCBpc3N1ZXJzIHdpbGwgYnVuZGxlIHRoZSBldmVudHMsIHNvIGl0IGlzIHNpbXBsZXIg dG8gaGF2ZSBvbmx5IG9uZSBldmVudCBwZXIgU0VULiBJbmNsdWRpbmcgdGhlIHNlcGFyYXRlIGV2 ZW50cyB3aXRoIGEgVVJJIGFzIGFuIGx2YWx1ZSBpcyBjaGFsbGVuZ2luZyB0byBpbXBsZW1lbnQs IHNwZWFraW5nIGZyb20gZXhwZXJpZW5jZS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCk9uIFR1 ZSwgT2N0IDMxLCAyMDE3IGF0IDExOjA1IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0K TWFyaXVz4oCZIHByb3Bvc2VkIHN5bnRheCwgcGFzdGVkIGluIGJlbG93LCBoYXMgZXhhY3RseSB0 aGlzIGNoYXJhY3RlcmlzdGljLiAgVGhlIHdheSBJIHNlZSBpdCwgaGlzIHByb3Bvc2FsIGVzc2Vu dGlhbGx5IGhhcyBhIHByaW1hcnkgcGFzc3dvcmRSZXNldCBldmVudCBhbmQgYSBzZWNvbmRhcnkg cGFzc3dvcmRSZXNldEV4dCBkYXRhIHN0cnVjdHVyZSwgd2hpY2ggY291bGQgaGF2ZSBiZWVuIHNp bXBseSBhbm90aGVyIGV2ZW50IHZhbHVlIGluIHRoZSBjdXJyZW50IGRyYWZ0Lg0KDQpUaGlzIGJy ZWFraW5nIGNoYW5nZSBtYWtlcyB0aGUgZGF0YSBzdHJ1Y3R1cmVzIG1vcmUgY29tcGxpY2F0ZWQg LSBub3QgbGVzcy4gIEFuZCBpdCBtYWtlcyB0aGluZ3MgdGhhdCB1c2VkIHRvIGJlIHBvc3NpYmxl IGltcG9zc2libGUsIHJlZHVjaW5nIGZsZXhpYmlsaXR5IHRvIHRob3NlIHdobyB3b3VsZCB1c2Ug dGhlIHNwZWMuDQoNClRoZXNlIHNlZW0gbGlrZSBiYWQgdHJhZGVvZmZzIHRvIG1lLg0KDQp7DQog ICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KICAiaWF0IjogMTQ1 ODQ5NjAyNSwNCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5jb208aHR0cHM6Ly9zY2lt LmV4YW1wbGUuY29tLz4iLA0KICAiYXVkIjogWw0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5j b20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsDQogICAgImh0dHBzOi8vamh1Yi5l eGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Ig0KICAgXSwNCiAgICJl dmVudF90eXBlIjogImh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0 RXh0IiwNCiAgICJldmVudCI6IHsNCiAgICAgICAgICJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3 NTIxZDkiLA0KICAgICAgICAgImV4dGVuc2lvbnMiOiB7DQogICAgICAgICAgICJodHRwczovL2V4 YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dOKAnTogew0KICAgICAgICAgICAg ICJyZXNldEF0dGVtcHRzIjo1LA0KICAgICAgICAgICB9DQogICAgICAgICB9DQogICAgICAgfQ0K fQ0KDQpJbiBwYXJ0aWN1bGFyLCBpdCBtYWtlcyBpdCBpbXBvc3NpYmxlIHRvIHNpZ24gbXVsdGlw bGUgcmVsYXRlZCBldmVudHMgc2hhcmluZyBhIGNvbW1vbiBjbGFpbXMgc2NoZW1hIHdpdGggYSBz aW5nbGUgc2lnbmF0dXJlIGJ5IHRoZSBpc3N1ZXIuICBJdCBmb3JjZXMgdGhlIGlzc3VlciB0byBk byB0aGUgZXh0cmEgd29yayBvZiBzaWduaW5nIGVhY2ggb2YgdGhlIHJlbGF0ZWQgZXZlbnRzIChv ciBmYWNldHMgb2YgdGhlIHNhbWUgbG9naWNhbCBldmVudCkgaW5kaXZpZHVhbGx5IGFuZCBmb3Jj ZXMgdGhlIHJlY2lwaWVudHMgdG8gZG8gdGhlIGV4dHJhIHdvcmsgb2YgY2hlY2tpbmcgYWxsIHRo b3NlIHVubmVjZXNzYXJ5IHNpZ25hdHVyZXMuDQoNCk5vdCBldmVyeSBwcm9maWxlIHdpbGwgZXZl ciBoYXZlIG11bHRpcGxlIGtleXMgaW4gdGhlIOKAnGV2ZW50c+KAnSBzZXQgYnV0IHRoZXJl4oCZ cyBhYnNvbHV0ZWx5IG5vIHJlYXNvbiB0byBwcmVjbHVkZSBpdC4NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTog SWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1ldmVu dC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIERpY2sgSGFyZHQNClNlbnQ6IFR1ZXNk YXksIE9jdG9iZXIgMzEsIDIwMTcgOTo1MiBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCkNj OiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRm QGdtYWlsLmNvbT4+OyBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9u LmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0 IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+PjsgUGhpbCBIdW50 IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+ Pg0KDQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50 cyBwZXIgU0VUPw0KDQpQbGVhc2UgZGlyZWN0IG1lIHRvIGEgcHJvcG9zYWwgdGhhdCBoYXMgYSAi cHJpbWFyeSIgYW5kICJzZWNvbmRhcnkiIGV2ZW50cy4gSSBhZ3JlZSB0aGF0IGlzIHVuZGVzaXJh YmxlLiBJIHdvdWxkIGFsc28gZW5jb3VyYWdlIHRvIGVuZ2FnZSBpbiB0aGUgZGlzY3Vzc2lvbnMg c28gdGhhdCB3ZSBjYW4gZHJpdmUgY2xhcml0eSBhbmQgc2ltcGxpY2l0eS4NCg0KSSB0aGluayB0 aGUgcHJvcG9zYWwgaXMgdGhhdCB0aGVyZSBpcyBvbmUgZXZlbnQgcGVyIFNFVC4NCg0KSSB0aGlu ayBoYXZpbmcgbW9yZSB0aGFuIG9uZSBldmVudCBwZXIgU0VUIGFkZHMgY29tcGxleGl0eSBhcyBh IHJlY2VpdmVyIG11c3QgZGVhbCB3aXRoIHJlY2VpdmluZyBjb3JyZWxhdGVkIGV2ZW50cyBpbiBv bmUgU0VUIGFzIHdlbGwgYXMgY29ycmVsYXRlZCBldmVudHMgaW4gdGhlIHNhbWUgU0VULg0KDQov RGljaw0KDQpPbiBUdWUsIE9jdCAzMSwgMjAxNyBhdCA5OjQyIFBNLCBNaWtlIEpvbmVzIDxNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bT4+IHdyb3RlOg0KSSBoZWFyIHlvdSBvbiB0aGUgZmFjdCB0aGF0IGRpZmZlcmVudCBwZW9wbGUg aGF2ZSBqb2luZWQgdGhlIGVmZm9ydCBhdCBkaWZmZXJlbnQgdGltZXMuICBUaGF04oCZcyBhIG5v cm1hbCBwcm9jZXNzIGFzIGFuIGVmZm9ydCBidWlsZHMgbW9tZW50dW0uICBJIGdldCB0aGF0IG5v dCBldmVyeW9uZSB3YXMgdGhlcmUgd2hlbiBwcmV2aW91cyBjb25zZW5zdXMgY2FsbHMgd2VyZSB0 YWtlbi4NCg0KSSBzaG91bGQgbm90ZSB0aGF0IEkgaGF2ZSBzcGVjaWZpYyB0ZWNobmljYWwgb2Jq ZWN0aW9ucyB0byB0aGUgc3BlY2lmaWMgcHJvcG9zZWQgY2hhbmdlcyBiZWluZyBkaXNjdXNzZWQg YXMgd2VsbC4gIEN1cnJlbnRseSBhbGwgZXZlbnRzIGluIHRoZSBzZXQgaGF2ZSB0aGUgc2FtZSBz eW50YXguICBUaGUgcHJvcG9zYWxzLCBhcyBJIHVuZGVyc3RhbmQgdGhlbSwgcmV2ZXJ0IHVzIHRv IGEgc3RhdGUgd2hlcmUgdGhlcmXigJlzIGEg4oCccHJpbWFyeeKAnSBhbmQg4oCcc2Vjb25kYXJ5 4oCdIGV2ZW50cywgd2l0aCBkaWZmZXJlbnQgc3ludGF4IGZvciB0aGUgdHdvIGNsYXNzZXMuICBU aGF04oCZcyBuZWVkbGVzc2x5IG1vcmUgY29tcGxpY2F0ZWQsIGFkZGluZyBubyBhY3R1YWwgdmFs dWUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IERpY2sgSGFyZHQgW21haWx0bzpkaWNrLmhh cmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+XQ0KU2VudDogVHVlc2Rh eSwgT2N0b2JlciAzMSwgMjAxNyA5OjM3IFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KQ2M6 IFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tPj47IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86 eWFyb25mLmlldGZAZ21haWwuY29tPj47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNo YW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj47IElEIEV2ZW50cyBN YWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+ DQoNClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIFVzZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRz IHBlciBTRVQ/DQoNCk1pa2UNCg0KQXMgeW91IHdlbGwga25vdywgbWFueSBwZW9wbGUgaW4gYSBX RyBkb24ndCBsb29rIGNsb3NlbHkgYXQgYSBzcGVjaWZpY2F0aW9uIHVudGlsIGxhc3QgY2FsbCBp cyBtYWRlLiBBZGRpdGlvbmFsbHksIHdlIGFyZSBjb21pbmcgdXAgb24gb25seSB0aGUgM3JkIFdH IG1lZXRpbmcuIFRoZSBXRyBoYXMgbm90IGV4aXN0ZWQgZm9yIHZlcnkgbG9uZy4gV2hpbGUgc29t ZSBvZiB0aGUgcGFydGljaXBhbnRzIGhhdmUgYmVlbiB3b3JraW5nIG9uIHRoaXMgZm9yIGEgd2hp bGUsIG1hbnkgaGF2ZSBub3QsIGFuZCB3ZSBhcmUgbG9va2luZyBmb3IgY29uc2Vuc3VzIGFjcm9z cyB0aGUgV0cuDQoNClNpbmNlIFNlY0V2ZW50IGlzIGEgZnJhbWV3b3JrIHRoYXQgd2UgZXhwZWN0 IHRvIGJlIHByb2ZpbGVkLCBJIGZlZWwgaXQgaXMgaW1wb3J0YW50IHRvIGVuc3VyZSB0aGF0IFNl Y0V2ZW50IHNwZWNpZmljYXRpb25zIGFyZSBlYXN5IGZvciBhIHZhcmlldHkgb2YgcHJvZmlsZXMg dG8gYWRvcHQsIGFuZCB0aGF0IHRoZSBzZW1hbnRpY3MgbWFrZSBzZW5zZS4gSSBhbHNvIHRoaW5r IHRoYXQgcHJvcGVydGllcyB0aGF0IGFyZSBzcGVjaWZpYyB0byBhIHByb2ZpbGUgc2hvdWxkIGJl IGxlZnQgdG8gdGhhdCBwcm9maWxlIGFuZCBub3QgYmUgaW5jbHVkZWQgaW4gU2VjRXZlbnQuDQoN ClNpbmNlIHRoaXMgaXMgYSBmcmFtZXdvcmssIGl0IGlzIGV4cGVjdGVkIHRoYXQgYXMgZGlmZmVy ZW50IGdyb3VwcyBwcm9maWxlIGl0LCB0aGVyZSB3aWxsIGJlIGFkZGl0aW9uYWwgZmVlZGJhY2su DQoNClNwZWNpZmljYWxseSwgYXMgYSBwYXJ0aWNpcGFudCBpbiB0aGUgUklTQyBwcm9maWxlIG9m IFNFVCwgYSBudW1iZXIgb2YgaXNzdWVzIGluIFNFVCBoYXZlIHN1cmZhY2VkIGFzIHRoZSBSSVND IFdHIGhhcyBsb29rZWQgYXQgaG93IHRvIHVzZSB0aGUgU0VULg0KDQpBcyBmb3IgU0VUIGJlaW5n IHN0YWJsZSBmb3Igb3ZlciBhIHllYXIsIHRoZXJlIGhhdmUgYmVlbiBhIG51bWJlciBvZiBjaGFu Z2VzIHRvIFNFVCBzaW5jZSB0aGVuLiBJIGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgd2FzIGNvbnNl bnN1cy4gQmVmb3JlIHRoZSBXRyB3YXMgZm9ybWVkLCBJIGFuZCBzZXZlcmFsIG90aGVycyBoYWQg ZXhwcmVzc2VkIGNvbmNlcm4gb24gdGhlIGRlc2lnbiBvZiBTRVQgd2hlbiBQaGlsIHByZXNlbnRl ZCBpdCBhdCBhbiBJSVcgc2Vzc2lvbi4NCg0KQXMgdG8gdGFraW5nIGFub3RoZXIgeWVhciwgSSBh bSBob3BlZnVsIHdlIGNhbiByZXNvbHZlIHRoZSByZW1haW5pbmcgaXNzdWVzIGluIFNFVCBhbmQg cHVibGlzaCBhIG5ldyBkcmFmdCBmb3IgbGFzdCBjYWxsLiBJIGRvIG5vdCB0aGluayB3ZSB3aWxs IG5lZWQgdG8gd2FpdCBmb3IgYW5vdGhlciBXRyBtZWV0aW5nIHRvIGFzayBmb3IgbGFzdCBjYWxs Lg0KDQpXZSBhbHNvIGhhdmUgYSBudW1iZXIgb2Ygb3RoZXIgZG9jdW1lbnRzIHRoYXQgYXJlIG5v dCBpbiBsYXN0IGNhbGwsIGFuZCB3ZSBkb24ndCBoYXZlIGEgV0cgYWRvcHRlZCBkcmFmdCB5ZXQg Zm9yIG1hbmFnZW1lbnQuIFNvIHRoZXJlIGFyZSBzdGlsbCBhIG51bWJlciBvZiBkb2N1bWVudHMg dG8gd29yayB0aHJvdWdoIGJlZm9yZSB3ZSBoYXZlIGFsbCB0aGUgYml0cyBmb3Igc29tZW9uZSB0 byB3b3JrIHdpdGguDQoNCkkgZG8gdGhpbmsgd2UgaGF2ZSBiZWVuIG1ha2luZyBnb29kIHByb2dy ZXNzIHNpbmNlIHRoZSBsYXN0IElFVEYgbWVldGluZywgYW5kIEkgYW0gaG9wZWZ1bCB3ZSBjYW4g a2VlcCB1cCB0aGlzIG1vbWVudHVtIGFuZCBmaW5hbGl6ZSBhbGwgdGhlIGRvY3VtZW50cyBpbiBh IHRpbWVseSBtYW5uZXIuDQoNCi9EaWNrDQoNCg0KT24gVHVlLCBPY3QgMzEsIDIwMTcgYXQgMTI6 NDggUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpJdOKAmXMgaGFyZCBmb3IgbWUgdG8g ZXZlbiBleHByZXNzIG15IGxldmVsIG9mIGZydXN0cmF0aW9uIHdpdGggdGhlIHJlY2VudCBhdHRl bXB0cyB0byBvbmNlIGFnYWluIHJlZGVzaWduIHRoZSBTZWNFdmVudCBUb2tlbiBzcGVjLiAgV2Xi gJl2ZSBiZWVuIGF0IHRoaXMgZm9yIG11bHRpcGxlIHllYXJzIGJlY2F1c2UgcGVvcGxlIGtlZXAg dHJ5aW5nIHRvIHJldmlzaXQgZGVjaXNpb25zIHRoYXQgd2VyZSBsb25nIGFnbyBtYWRlIGJ5IGNv bnNlbnN1cy4gIEl04oCZcyBiZWVuIHN0YWJsZSBmb3Igb3ZlciBhIHllYXIgYW5kIHRoZSBtYWpv cml0eSBvZiBXR0xDIHJlc3BvbmRlbnRzIHNhaWQgc29tZSB2YXJpYW50IG9mIOKAnFdvcmtzIGZv ciBtZSDigJMgc2hpcCBpdCHigJ0NCg0KVGhlcmXigJlzIG5vdCBzdWZmaWNpZW50IGp1c3RpZmlj YXRpb24gdG8gdHJ5IHRvIHVuZG8gY29uc2Vuc3VzIHBvc2l0aW9ucyB0aGF0IGhhdmUgYmVlbiBk ZWJhdGVkIGFuZCBhZmZpcm1lZCBvdmVyIGFuZCBvdmVyLiAgQ291bnRlbmFuY2luZyB3aG9sZXNh bGUgY2hhbmdlcyBhdCB0aGlzIGxhdGUgZGF0ZSBpcyBjb3VudGVycHJvZHVjdGl2ZSBpbiB0aGUg ZXh0cmVtZSENCg0KSXTigJlzIGZhciBiZXR0ZXIgdGhhbiBnb29kIGVub3VnaCBhcy1pcy4gIElu IG15IGV4cGVyaWVuY2UsIGlmIHdlIHN0YXJ0IHJlZGVzaWduaW5nIGl0LCBpdCB3aWxsIHJlc3Vs dCBpbiBhbm90aGVyIHllYXLigJlzIGRlbGF5LiAgSXQgZG9lcyBzb21ldGhpbmcgc2ltcGxlIGFu ZCB1c2VmdWwuICBQbGVhc2UsIGxldOKAmXMganVzdCBzaGlwIGl0LCBzbyBwZW9wbGUgY2FuIHJl bHkgb24gaXQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFBoaWwgSHVudCAoSURNKSBbbWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT5dDQpTZW50OiBNb25k YXksIE9jdG9iZXIgMzAsIDIwMTcgMjo0MiBQTQ0KVG86IERpY2sgSGFyZHQgPGRpY2suaGFyZHRA Z21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQpDYzogWWFyb24gU2hlZmZl ciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+Pjsg UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJp Y2hhbm5hQGFtYXpvbi5jb20+PjsgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PjsgSUQgRXZlbnRzIE1haWxp bmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj4NCg0K U3ViamVjdDogUmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVy IFNFVD8NCg0KSW5saW5lLi4uDQoNClBoaWwNCg0KT24gT2N0IDMwLCAyMDE3LCBhdCAyOjIyIFBN LCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFp bC5jb20+PiB3cm90ZToNCkhpIFBoaWwNCg0KQ29ycmVjdCBtZSBpZiBJIGFtIG1pc3VuZGVyc3Rh bmRpbmcsIGJ1dCB0aGVyZSBpcyBhIFJJU0MgcHJvZmlsZSBldmVudA0KDQoNCg0KImh0dHA6Ly9z Y2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlLzxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVuaWQubmV0 X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0eXBlXy0yNTVDJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dh V0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlY UHB1WXFQa0FJMWFMY0xONEtaTkEmbT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZf OHU4X3FTQ193JnM9MjVsMDlzSDhZVjQyeHpnVS1DWFNnOHhIOXR2eURKejQwdENSakZhbGhrdyZl PT5hY2NvdW50LWNyZWRlbnRpYWwtY2hhbmdlLXJlcXVpcmVk4oCdDQoNCg0KYW5kIGFuIFNDSU0g cHJvZmlsZSBldmVudA0KDQoNCiJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dv cmRSZXNldEV4dOKAnQ0KDQoNCkknbSBzdWdnZXN0aW5nIHRoYXQgdHdvIGRpZmZlcmVudCBldmVu dHMgd291bGQgYmUgc2VudC4gRW1iZWRkaW5nIG9uZSBpbiB0aGUgb3RoZXIgZG9lcyBub3QgbWFr ZSBzZW5zZS4NCjxwaD5JdCBpcyBhIGh5cG90aGV0aWNhbCBleGFtcGxlLiBKdXN0IGJlY2F1c2Ug eW91IGRpc2FncmVlIG9uIHRoaXMgZG9lcyBub3QgbWVhbiBvdGhlcnMgYXJlIG5vdCB2YWxpZC4N Cg0KSSBqdXN0IHBpY2tlZCBvdmVybGFwcGluZyBwcm9wb3NhbHMgdGhhdCBoYXZlIGRpZmZlcmVu dCBtZWFuaW5nIChidXQgbm90IHRoZSBzYW1lKSB0byBpbGx1c3RyYXRlIHRoZSBkaWZmZXJlbmNl IGZyb20gaXNzdWluZyBhIHNpbmdsZSBzZXQgd2l0aCBkaWZmZXJlbnQgZXZlbnRzLg0KDQpBcyBJ IGhhdmUgc3RhdGVkIHRoaXMgaXMgdmVyeSBkaWZmZXJlbnQgZnJvbSBhc3NlcnRpbmcgbXVsdGlw bGUgZGlzdGluY3QgZXZlbnRzIGluIG9uZSBTRVQuDQoNCkFsc28sIEkgdGhpbmsgaXQgaXMgc2lt cGxlciB0byBoYXZlIGV2ZW50X3R5cGUgYmUgYXQgdGhlIHNhbWUgbGV2ZWwgYXMgZXZlbnQNCg0K PHBoPm1heSBiZS4gSSB3YXMgd29ya2luZyBmcm9tIEFubmFiZWxsZSdzIHByb3Bvc2VkIGZvcm1h dC4NCg0Kew0KICAianRpIjogIjNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwIiwNCiAg ImlhdCI6IDE0NTg0OTYwMjUsDQogICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPGh0 dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8+IiwNCiAgImF1ZCI6IFsNCiAgICAiaHR0cHM6Ly9qaHVi LmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLA0KICAgICJodHRw czovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyINCiAg IF0sDQogICAiZXZlbnRfdHlwZSI6ICJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFz c3dvcmRSZXNldEV4dCIsDQogICAiZXZlbnQiOiB7DQogICAgICAgICAiaWQiOiI0NGY2MTQyZGY5 NmJkNmFiNjFlNzUyMWQ5IiwNCiAgICAgICAgICJyZXNldEF0dGVtcHRzIjo1DQogICAgICAgfQ0K fQ0KDQp7DQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KICAi aWF0IjogMTQ1ODQ5NjAyNSwNCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5jb208aHR0 cHM6Ly9zY2ltLmV4YW1wbGUuY29tLz4iLA0KICAiYXVkIjogWw0KICAgICJodHRwczovL2podWIu ZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsDQogICAgImh0dHBz Oi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Ig0KICAg XSwNCiAgICJldmVudF90eXBlIjogImh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQv cmlzYy9ldmVudC10eXBlL2FjY291bnQtY3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWQ8aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3Bl bmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV9hY2NvdW50LTJEY3JlZGVudGlhbC0y RGNoYW5nZS0yRHJlcXVpcmVkJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3 cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xO NEtaTkEmbT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JnM9blF5 OWV6UFJqREdkdlJUQ2FpRHRpNE9IZWxIM0RLZ1VDVEtqRjJHUS1zbyZlPT4iLA0KICAgImV2ZW50 Ijogew0KICAgICAgIOKAnHN1YuKAnTrigJ03Mzc1NjI2QTY1NjM3NOKAnSwNCiAgICAgICDigJxp c3PigJ06Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLyINCiAgICAgICB9DQp9DQoNCg0KDQoNCg0K T24gTW9uLCBPY3QgMzAsIDIwMTcgYXQgMTI6MDkgUE0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9y YWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQpBbm5hYmVsbGUv RGljaywNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMuIEkgdGhpbmsgd2UgbmVlZCB0byBleGFt aW5lIHRoZSBjb25zZXF1ZW5jZXMgb2YgdGhlIHByb3Bvc2FsIGluIEpTT04uDQoNCkFzIEkgc3Rh dGVkLCB3aGF0IGNhdXNlcyBtb3N0IG9mIHRoZSBpc3N1ZSBpcyB0aGUgcHJvcG9zZWQgZXh0ZW5z aW9uIG1lY2hhbmlzbSBpbiB0aGUgcGF5bG9hZCAocG9zc2libHkgdXNpbmcgZXZlbnRzIGluIGEg cmVjdXJzaXZlIHdheSkuIERvZXMgaXQgZm9sbG93IHRoZSBvbGQgZm9ybWF0IG9yIHRoZSBuZXc/ DQoNCkxldOKAmXMgIGNvbnNpZGVyIGEgdXNlIGNhc2Ugd2hlcmUgd2UgaGF2ZSBhbiBpZGVudGl0 eSBtYW5hZ2VtZW50IHN5c3RlbSB0aGF0IHVzZXMgU0NJTSwgYnV0IHRoZSBTQ0lNIHN5c3RlbSBp cyBhbHNvIHRoZSB1bmRlcmx5aW5nIGRhdGEgc3RvcmUgZm9yIENvbm5lY3QuICBBIFBhc3N3b3Jk IHJlc2V0IG1pZ2h0IGdlbmVyYXRlIHRoZSBmb2xsb3dpbmcgZXZlbnQgd2hpY2ggaGFzIGFuIGV4 dGVuc2lvbiAoY29udmV5aW5nIHJlc2V0IGNvdW50KSBBTkQgb3ZlcmxhcHBpbmcgc3RhdGVtZW50 IGZyb20gUklTQy4gIEJPVEggb2Ygd2hpY2ggbWlnaHQgYmUgaW1wb3J0YW50IHRvIGEgc2ltaWxh ciByZWNlaXZlciB1c2luZyBTQ0lNIGFuZCBPSURDLg0KDQpUaGUgMDMgc3BlYyBjdXJyZW50bHkg d291bGQgYWxsb3c6DQoNCg0Kew0KDQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIx YmQ0ZTdkMzAiLA0KDQogICJpYXQiOiAxNDU4NDk2MDI1LA0KDQogICJpc3MiOiAiaHR0cHM6Ly9z Y2ltLmV4YW1wbGUuY29tPGh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8+IiwNCg0KICAiYXVkIjog Ww0KDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3 OTU5M2I3NzU0IiwNCg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0 NTE2YjFkMDg2NDFkNzY3NmVlNyINCg0KICAgXSwNCg0KICAgImV2ZW50cyI6IHsNCg0KICAgICAi dXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldCI6DQoNCiAgICAgICB7ICJp ZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkifSwNCg0KICAgICAiaHR0cHM6Ly9leGFtcGxl LmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiOg0KDQogICAgICAgeyAicmVzZXRBdHRl bXB0cyI6NX0sDQoNCiAgICAgImh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlz Yy9ldmVudC10eXBlL1w8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV8t MjU1QyZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9K bkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09aXlWbnJa bXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZzPTI1bDA5c0g4WVY0Mnh6Z1Ut Q1hTZzh4SDl0dnlESno0MHRDUmpGYWxoa3cmZT0+DQogICAgICAgYWNjb3VudC1jcmVkZW50aWFs LWNoYW5nZS1yZXF1aXJlZCI6IHsNCg0KICAgICAgICAg4oCcc3Vi4oCdOuKAnTczNzU2MjZBNjU2 Mzc04oCdLA0KDQogICAgICAgICDigJxpc3PigJ06Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLyIN Cg0KICAgICAgIH0NCg0KICB9DQoNCn0NCg0KDQoNCkluIHRoZSBhYm92ZSAtIGVhY2ggcGF5bG9h ZCBpcyBhIOKAmHBlZXInIGFuZCBpc3N1ZWQgd2l0aG91dCBwcmVmZXJlbmNlIGJ5IHRoZSB0cmFu c21pdHRlci4gVGhlIHJlY2VpdmVyIGNhbiBhc3NpZ24gcHJpb3JpdHkgaW4gaXRzIG93biBjb250 ZXh0IGlmIHRoYXQgbWF0dGVycy4NCg0KDQoNClRoZSBuZXcgcHJvcG9zYWw6DQoNCg0KDQp7DQoN CiAgImp0aSI6ICIzZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCIsDQoNCiAgImlhdCI6 IDE0NTg0OTYwMjUsDQoNCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5jb208aHR0cHM6 Ly9zY2ltLmV4YW1wbGUuY29tLz4iLA0KDQogICJhdWQiOiBbDQoNCiAgICAiaHR0cHM6Ly9qaHVi LmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLA0KDQogICAgImh0 dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Ig0K DQogICBdLA0KDQogICAiZXZlbnQiOiB7DQoNCiAgICAg4oCcZXZlbnRfdHlwZeKAnToidXJuOmll dGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldOKAnSwNCg0KICAgICAiaWQiOuKAnTQ0 ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDnigJ0sDQoNCiAgICAg4oCcZXZlbnRz4oCdOnsNCg0KICAg ICAtPm5vdGUg4oCmaXMgdGhpcyB0aGUgb2xkIG9yIG5ldyBzdHJ1Y3R1cmU/IDwtDQoNCiAgICAg ICAiaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiOg0KDQog ICAgICAgICB7ICJyZXNldEF0dGVtcHRzIjo1fSwNCg0KICAgICAgICJodHRwOi8vc2NoZW1hcy5v cGVuaWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS9cPGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfc2VjZXZl bnRfcmlzY19ldmVudC0yRHR5cGVfLTI1NUMmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBr QUkxYUxjTE40S1pOQSZtPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVND X3cmcz0yNWwwOXNIOFlWNDJ4emdVLUNYU2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmU9Pg0KICAg ICAgICAgYWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZCI6IHsNCg0KICAgICAgICAg 4oCcc3Vi4oCdOuKAnTczNzU2MjZBNjU2Mzc04oCdLA0KDQogICAgICAgICDigJxpc3PigJ06Imh0 dHBzOi8vaWRwLmV4YW1wbGUuY29tLyINCg0KICAgICAgIH0NCg0KICAgICB9DQoNCiAgIH0NCg0K fQ0KDQoNCg0KSW4gdGhlIGFib3ZlLCBzdWItZXZlbnRzIG9yIGV4dGVuc2lvbnMgaGF2ZSBhIGRp ZmZlcmVudCBmb3JtYXQuIFRoZSBzYW1lIGNvbXBsYWludCBhYm91dCB0aGUgb3JpZ2luYWwgc3Rh bmRzLg0KDQoNCg0KKk9SKiAoaWYgdGhlIHJlY2VpdmVyIGNhcmVzIGFib3V0IFJJU0MgbW9yZSku ICBOb3RlIHRoYXQgdGhpcyBsZWFkcyB0byBhIHRyaXBsZSBuZXN0ZWQgc3RydWN0dXJlLg0KDQoN Cg0Kew0KDQogICJqdGkiOiAiM2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KDQog ICJpYXQiOiAxNDU4NDk2MDI1LA0KDQogICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29t PGh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8+IiwNCg0KICAiYXVkIjogWw0KDQogICAgImh0dHBz Oi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiwNCg0K ICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3 NmVlNyINCg0KICAgXSwNCg0KICAgImV2ZW50Ijogew0KDQogICAgIOKAnGV2ZW50X3R5cGXigJ06 Imh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL1w8aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMu b3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV8tMjU1QyZkPUR3TUZhUSZjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5x V055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1S UVM2bEs2N3lGXzh1OF9xU0NfdyZzPTI1bDA5c0g4WVY0Mnh6Z1UtQ1hTZzh4SDl0dnlESno0MHRD UmpGYWxoa3cmZT0+DQoNCiAgICAgICAgICAgICBhY2NvdW50LWNyZWRlbnRpYWwtY2hhbmdlLXJl cXVpcmVk4oCdLA0KDQogICAgICDigJxzdWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0sDQoNCiAg ICAgIOKAnGlzc+KAnToiaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20v4oCcPGh0dHBzOi8vaWRwLmV4 YW1wbGUuY29tLyVFMiU4MCU5Qz4sDQoNCiAgICAgIOKAnGV2ZW50c+KAnTp7DQoNCiAgICAgICAg InVybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3JkUmVzZXQiOg0KDQogICAgICAgIHsN Cg0KICAgICAgICAgICJpZCI64oCdNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOeKAnSwNCg0KICAg ICAgICAgIOKAnGV2ZW50c+KAnTp7DQoNCiAgICAgICAgICAgICAiaHR0cHM6Ly9leGFtcGxlLmNv bS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiOg0KDQogICAgICAgICAgICAgICB7ICJyZXNl dEF0dGVtcHRzIjo1fSwNCg0KICAgICAgICAgIH0NCg0KICAgICAgICB9DQoNCiAgICAgIH0NCg0K ICAgfQ0KDQp9DQoNCg0KDQpJbiB0aGUgYWJvdmUsIHRoZSBleHRlbnNpb24gaXMgcGxhY2VkIGlu c2lkZSB0aGUgZXZlbnQgaXQgZXh0ZW5kcy4gSXQgZm9sbG93cyB0aGUgb2xkIGZvcm1hdCAob3Ig c2hvdWxkIGl0IGZvbGxvdyB0aGUgbmV3PykNCg0KKk9SKiBGb2xsb3dpbmcgdGhlIHRvcCBsYXll ciBwYXR0ZXJuIG9mIHNpbmd1bGFyIGV2ZW50ICBOb3RlIHRoYXQgdGhpcyBsZWFkcyB0byBhIHRy aXBsZSBuZXN0ZWQgc3RydWN0dXJlLg0KDQoNCg0Kew0KDQogICJqdGkiOiAiM2QwYzNjZjc5NzU4 NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KDQogICJpYXQiOiAxNDU4NDk2MDI1LA0KDQogICJpc3Mi OiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPGh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8+IiwN Cg0KICAiYXVkIjogWw0KDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1 MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiwNCg0KICAgICJodHRwczovL2podWIuZXhhbXBsZS5jb20v RmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyINCg0KICAgXSwNCg0KICAgImV2ZW50Ijog ew0KDQogICAgIOKAnGV2ZW50X3R5cGXigJ06Imh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2Vj ZXZlbnQvcmlzYy9ldmVudC10eXBlL1w8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50 LTJEdHlwZV8tMjU1QyZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1V QjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5B Jm09aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0NfdyZzPTI1bDA5c0g4 WVY0Mnh6Z1UtQ1hTZzh4SDl0dnlESno0MHRDUmpGYWxoa3cmZT0+DQoNCiAgICAgICAgICAgICBh Y2NvdW50LWNyZWRlbnRpYWwtY2hhbmdlLXJlcXVpcmVk4oCdLA0KDQogICAgICDigJxzdWLigJ06 4oCdNzM3NTYyNkE2NTYzNzTigJ0sDQoNCiAgICAgIOKAnGlzc+KAnToiaHR0cHM6Ly9pZHAuZXhh bXBsZS5jb20v4oCcPGh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLyVFMiU4MCU5Qz4sDQoNCiAgICAg IOKAnGV2ZW504oCdOnsNCg0KICAgICAgICDigJxldmVudF90eXBl4oCdOiJ1cm46aWV0ZjpwYXJh bXM6c2NpbTpldmVudDpwYXNzd29yZFJlc2V04oCdLA0KDQogICAgICAgICJpZCI64oCdNDRmNjE0 MmRmOTZiZDZhYjYxZTc1MjFkOeKAnSwNCg0KICAgICAgICDigJxldmVudOKAnTp7DQoNCiAgICAg ICAgICDigJxldmVudF90eXBl4oCdOiJodHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFz c3dvcmRSZXNldEV4dOKAnSwNCg0KICAgICAgICAgICJyZXNldEF0dGVtcHRzIjo1DQoNCiAgICAg ICAgfQ0KDQogICAgICB9DQoNCiAgIH0NCg0KfQ0KDQoNCg0KVGhpcyBmb3JtYXQgZm9sbG93cyB0 aGUgcHJvcG9zZWQgc2luZ3VsYXIgZXZlbnQgZm9ybWF0IHJlY3Vyc2l2ZWx5IGFuZCBpcyAzIGxh eWVycyBkZWVwLiBOb3RlIHRoYXQgdGhlIHBhcnNlciBoYXMgdG8gY29udGludWUgdG8gc2VhcmNo IHRoZSBkb2N1bWVudCBmb3IgdGhpbmdzIHRoYXQgYXJlbuKAmXQgdGhlcmUgYXMgaXQgaGFzIHRv IHN0b3Agd2hlbiBubyDigJxldmVudOKAnSBhdHRyaWJ1dGUgaXMgZm91bmQgcmF0aGVyIHRoYW4g aXRlcmF0ZSBvdmVyIGFuIGFycmF5Lg0KDQoNClBoaWwNCg0KT3JhY2xlIENvcnBvcmF0aW9uLCBJ ZGVudGl0eSBDbG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3QNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5k ZXBlbmRlbnRpZC5jb208aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNvbSZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBw dVlxUGtBSTFhTGNMTjRLWk5BJm09aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1 OF9xU0NfdyZzPTlzWWhncEV6Yjd4UGxRRm1DQ1hObUhvNmZRTjlJQnUtU0hKYW1nX0I0SHMmZT0+ DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCk9u IE9jdCAzMCwgMjAxNywgYXQgODo1NyBBTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJp Y2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiB3cm90ZToNCg0K UmVwbGllcyBpbmxpbmUuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpJZGVudGl0 eSBTZXJ2aWNlcw0KDQoNCkZyb206IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCkRhdGU6IFN1bmRheSwgT2N0b2JlciAyOSwgMjAx NyBhdCA1OjI1IFBNDQpUbzogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkNjOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBn bWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+LCBNaWtlIEpvbmVzIDxNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bT4+LCAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPG1h aWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4sIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2 ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0lk LWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPw0KDQpJIGhvcGUg dGhpcyBhbnN3ZXJzIHlvdXIgcXVlc3Rpb24uDQoNCk15IOKAnG1heeKAnSB3YXMgYmVjYXVzZSBJ IGNhbuKAmXQgc2VlIGEgcmVhc29uIHdoeSBub3QuIFRoZSBxdWVzdGlvbiBzaG91bGQgYmUsIHdo YXQgaXMgdGhlIGp1c3RpZmljYXRpb24gdG8gbWFrZSDigJxldmVudHPigJ0gc2luZ3VsYXI/DQpb cmljaGFubmFdVGhlIHNpbmd1bGFyIOKAnGV2ZW504oCdIGNsYWltIGhhcyBjbGVhcmVyIHNlbWFu dGljcyBhbmQgaXMgZWFzaWVyIHRvIHByb2Nlc3MuIFdlIHNob3VsZCBvcHQgZm9yIGVhc2llciBz b2x1dGlvbnMgdW5sZXNzIHRoZXJlIGFyZSB1c2UgY2FzZXMgdGhhdCByZXF1aXJlIG1vcmUgY29t cGxleGl0eS5bL3JpY2hhbm5hXQ0KDQpUaGVyZSBhcmUgbWFueSByZWFzb25zIGZvciBtdWx0aXBs ZSBldmVudHMgaW4gYSBTRVQuICBTb21lIGFyZSBnb29kLCBzb21lIG5vdCBzbyBnb29kLiBTb21l IG9mIHRoZSByZWFzb25zLi4uDQoNCjEuICBNdWx0aXBsZSBldmVudCBwYXlsb2FkcyBleHByZXNz aW5nIHN0YXRlbWVudHMgYWJvdXQgbGFyZ2VseSB0aGUgKnNhbWUqdGhpbmcuIEZvciBleGFtcGxl LCBTQ0lNIHBhc3N3b3JkIHJlc2V0IEFORCBSSVNDIHBhc3N3b3JkIHJlc2V0LiAgQSBSSVNDIEV2 ZW50IGFuZCBhbiBPcGVuQmFua2luZyBFdmVudC4gSXMgb25lIGEgY29tcGxlbWVudCB0byB0aGUg b3RoZXI/ICBEbyB0aGV5IG92ZXJsYXAgb3IgYXJlIHRoZXkgZGlzdGluY3Q/DQpbcmljaGFubmFd Q29weS9wYXN0ZWQgZnJvbSBteSBlYXJsaWVyIGVtYWlsOg0KV2h5IGlzIGl0IG5lY2Vzc2FyeSBv ciBhcHByb3ByaWF0ZSB0byBpbmNsdWRlIHRoZXNlIGV2ZW50cyBpbiB0aGUgc2FtZSBTRVQ/IFRo ZXkgYXJlIGxpa2VseSBiZWluZyBnZW5lcmF0ZWQgYnkgZGlmZmVyZW50IHN5c3RlbXMgYXQgZGlm ZmVyZW50IHRpbWVzIG9uIHRoZSB0cmFuc21pdHRlcuKAmXMgc2lkZSwgY29uc3VtZWQgYnkgZGlm ZmVyZW50IHN5c3RlbXMgb24gdGhlIHJlY2VpdmVy4oCZcyBzaWRlLCBhbmQgcG9zc2libHkgYmVp bmcgdHJhbnNtaXR0ZWQgb3ZlciBkaWZmZXJlbnQgZXZlbnQgc3RyZWFtcy4gSSBrbm93IHRoZSBs YXR0ZXIgd291bGQgYmUgdGhlIGNhc2UgZm9yIHVzLCBhcyBhIHJlY2VpdmVyLiBFdmVuIGlmIGl0 4oCZcyBub3QsIGlzIGl0IGJ1cmRlbnNvbWUgdG8gc2VuZCB0aGVzZSBldmVudHMgc2VwYXJhdGVs eT8gV2hhdCB2YWx1ZSBpcyBnYWluZWQgaW4gY29tYmluaW5nIHRoZW0/DQoNCkFkZGl0aW9uYWxs eSwgc2luY2UgdGhlIHNpZ25hdHVyZSBpcyBvdmVyIHRoZSBTRVQgYW5kIG5vdCB0aGUgZXZlbnQg b2JqZWN0cywgUmVjZWl2ZXJzIGluZGVwZW5kZW50bHkgcm91dGUgc2VwYXJhdGUgZXZlbnRzIGZy b20gYSBzaW5nbGUgdG9rZW4gd2l0aG91dCBlaXRoZXIgbG9zaW5nIHRoZSBhYmlsaXR5IHRvIHZl cmlmeSB0aGUgYXV0aGVudGljaXR5IG9mIHRoZSBldmVudCBvciBzaGFyaW5nIGFsbCBpbmZvcm1h dGlvbiBpbiB0aGUgU0VUIHdpdGggZXZlcnkgc3lzdGVtIGhhbmRsaW5nIGFueSBldmVudCBpbiB0 aGUgdG9rZW4uWy9yaWNoYW5uYV0NCg0KMi4gIE11bHRpcGxlIGV2ZW50cyBwYXlsb2FkcyBleHBy ZXNzaW5nIGRpZmZlcmVudCBzdGF0ZW1lbnRzIGFib3V0IHRoZSBzYW1lIHRyYW5zYWN0aW9uIC0g UklTQyBQYXNzd29yZCBSZXNldCBhbmQgUklTQyBTZXNzaW9uIENhbmNlbA0KW3JpY2hhbm5hXVNh bWUgYXMgYWJvdmVbL3JpY2hhbm5hXQ0KMy4gIEEgbmV3IHByb2ZpbGUgZGVmaW5lcyBuZXcgZXZl bnQgYXR0cmlidXRlcyB0byBiZSBhZGRlZCBvbiB0byBhbiBleGlzdGluZyBldmVudCB0eXBlIChh IHB1cmUgZXh0ZW5zaW9uKQ0KW3JpY2hhbm5hXUkgaGF2ZSBzdWdnZXN0ZWQgYSB3YXkgdG8gc3Vw cG9ydCBleHRlbnNpb25zIHdpdGhpbiBhbiBldmVudCBib2R5LCBtdWx0aXBsZSB0aW1lcyBub3cu IElmIHlvdSBzZWUgcHJvYmxlbXMgd2l0aCBpdCwgcGxlYXNlIHBvaW50IHRoZW0gb3V0Llsvcmlj aGFubmFdDQoNCkkgdGhpbmsgaXQgaXMgcXVpdGUgdmFsaWQgdG8gYWxsb3cgMSBhbmQgMy4gIDIg Y291bGQgYmUgbGltaXRlZCBieSBzcGVjaWZpYyBwcm9maWxlcyBsaWtlIFJJU0MgaWYgdGhleSB3 YW50Lg0KDQpJIGFtIG5vdCBpbiBhZ3JlZW1lbnQgdGhhdCBtYWtpbmcgZXZlbnQgc2luZ3VsYXIg c2ltcGxpZmllcyBhbnl0aGluZy4gRm9yIG9uZSBpcyBtYWtlcyBleHRlbnNpb25zIGNvbXBsZXgg KGFub3RoZXIgbmVzdGVkIEpTT04gc3RydWN0dXJlKSBhbmQgcG90ZW50aWFsbHkgY29uZmxpY3Rp bmcuDQpbcmljaGFubmFdDQpXYXlzIHRoYXQgbXVsdGlwbGUtZXZlbnQgU0VUcyBhcmUgbW9yZSBj b21wbGljYXRlZDoNCg0KICAxLiAgSXQgcmVzdWx0cyBpbiBhIG1vcmUgY29tcGxleCBzdHJ1Y3R1 cmUgZm9yIHRoZSBzaW5nbGUgZXZlbnQgdXNlIGNhc2UsIHdoaWNoIEkgdGhpbmsgd2UgYWxsIGFn cmVlIGlzIHRoZSBtYWpvcml0eSB1c2UgY2FzZS4NCiAgMi4gIE11bHRpcGxlLWV2ZW50IFNFVHMg aGF2ZSBhbWJpZ3VvdXMgc2VtYW50aWNzLiBUaGUgcHJlc2VuY2Ugb2YgdHdvIGV2ZW50cyBBIGFu ZCBCIGluIHRoZSBzYW1lIFNFVCBjb3VsZCBtZWFuIGFueSBvZjoNCg0KICAgICAqICAgVGhleSBh cmUgcmVsYXRlZCB0byB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50IChpLmUuIHRoZSBzYW1lIHRoaW5n IGFzIGlmIHRoZXkgd2VyZSBmcm9tIGRpZmZlcmVudCBTRVRzIHRoYXQgaGF2ZSBhIGNvbW1vbiB0 eG4pLg0KICAgICAqICAgQSBpcyBhbiBleHRlbnNpb24gb2YgQi4NCiAgICAgKiAgIEIgaXMgYW4g ZXh0ZW5zaW9uIG9mIEEuDQogICAgICogICBUaGV5IGFyZSBhbGlhc2VzIGZvciBvbmUgYW5vdGhl ci4NCiAgICAgKiAgIFRoZXkgYXJlIG5vdCBhY3R1YWxseSByZWxhdGVkIHRvIG9uZSBhbm90aGVy IGluIGFueSB3YXkuDQoNCiAgMS4gIENsYWltIHNlbWFudGljcyBiZWNvbWUgaGFyZGVyIHRvIGRl ZmluZSwgYXMgZGlmZmVyZW50IHByb2ZpbGVzIG1heSB3YW50IHRvIHVzZSB0aGUgc2FtZSBjbGFp bXMgaW4gZGlmZmVyZW50IHdheXMuDQoNCklmIHRoZSBXRyB3YW50cyB0byBibG9jayAxIGFuZCAy IGFib3ZlLCB0aGVuIEkgYmVsaWV2ZSB3ZSBoYXZlIHRvIGVzdGFibGlzaCBhbiBldmVudCByZWdp c3RyeSB0byBlbnN1cmUgbmV3IEV2ZW50IHByb2ZpbGVzIGRvIG5vdCBvdmVybGFwIHRvIGVsaW1p bmF0ZSB0aGUgbmVlZCB0byBleHByZXNzIG11bHRpcGxlIGV2ZW50cy4NCltyaWNoYW5uYV1J4oCZ bSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IHRoaXMuIEFyZSB5b3UgcmVmZXJyaW5nIHRvIGV2 ZW50IG5hbWVzPyBUaG9zZSBhcmUgYWxyZWFkeSBkZWZpbmVkIGJ5IHRoZSBzcGVjIHRvIGJlIFVS SXMuWy9yaWNoYW5uYV0NClBoaWwNCg0KT3JhY2xlIENvcnBvcmF0aW9uLCBJZGVudGl0eSBDbG91 ZCBTZXJ2aWNlcyBBcmNoaXRlY3QNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5j b208aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3 dy5pbmRlcGVuZGVudGlkLmNvbSZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2 N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNM TjRLWk5BJm09VS1hNUhCTkQwSGFUWDRhbk5aZnpYN3BEc2ZLNWYwaDltWjlDWmtrR2llYyZzPUtC d0tQRm5xWV9ROTVDVEFfX1dHQ1lHVHhyRDdBR0N4dWVvUFhuS0VVVDAmZT0+DQpwaGlsLmh1bnRA b3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCk9uIE9jdCAyOSwgMjAx NywgYXQgNDoxMiBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRp Y2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQoNClBoaWw6DQoNCkluIHlvdXIgZXhhbXBsZXMg Zm9yIGhhdmluZyBhIHBsdXJhbGl0eSBvZiBldmVudHMsIHlvdSB1c2UgdGhlIHdvcmQgIm1heSIs IHdoaWNoIGxlYWRzIG1lIHRvIHF1ZXN0aW9uIGlmIGEgcGx1cmFsaXR5IG9mIGV2ZW50cyBpcyBy ZWFsbHkgcmVxdWlyZWQgaW4gU0VULg0KDQpZb3UgcG9zaXQgdGhhdCBpdCB3aWxsIGJlIGRpZmZp Y3VsdCBmb3IgYSBkaXN0cmlidXRlZCBzeXN0ZW0gdG8gY29ycmVsYXRlIG11bHRpcGxlIFNFVHMg d2l0aCB0aGUgc2FtZSAidHhuIiwgYnV0IHRoZSBkaXN0cmlidXRlZCBzeXN0ZW0gd2lsbCBjZXJ0 YWlubHkgbmVlZCB0byBjb3JyZWxhdGUgZXZlbnRzIG9uIHRoZSBzYW1lIHN1YmplY3QgLS0gY29y cmVsYXRpbmcgZXZlbnRzIG9uIHRoZSBzYW1lICJ0eG4iIG9uIHRoZSBzYW1lIHN1YmplY3Qgc2Vl bXMgZmFpcmx5IHNpbXBsZS4NCg0KSSB0aGluayB0aGF0IGEgcmVjZWl2ZXIgd2lsbCBuZWVkIHRv IGNvcnJlbGF0ZSBtdWx0aXBsZSBTRXRzIG9uIHRoZSBzYW1lIHN1YmplY3QsIHNvIGhhdmluZyBt dWx0aXBsZSBldmVudHMgaW4gYSBTRVQgaXMgcmVkdW5kYW50LCBhbmQgYWRkcyBjb21wbGV4aXR5 IHdpdGggbm8gY2xlYXIgYmVuZWZpdCB0aGF0IEkgY2FuIHNlZS4NCg0KQW4gaW1wbGVtZW50b3Ig bWF5IGNob29zZSB0byBzZW5kIG11bHRpcGxlIFNFVHMsIG9yIHNlbmQgYSBzaW5nbGUgU0VUIHdp dGggbXVsdGlwbGUgZXZlbnRzLCBzbyBhIHJlY2VpdmVyIHdpbGwgbmVlZCB0byBzdXBwb3J0IGJv dGguIEkgcHJlZmVyIHdlIHBpY2sgb25lIHdheSBhbmQgbWluaW1pemUgdGhlIGNvZGUgcGF0aHMs IGFuZCB3ZSB3aWxsIG5lZWQgdG8gc3VwcG9ydCBjb3JyZWxhdGluZyBhY3Jvc3MgbXVsdGlwbGUg U0VUcywgc28gdGhhdCBzZWVtcyB0aGUgYmVzdCBtZWNoYW5pc20uDQoNCkxldCBtZSBrbm93IGlm IHRoZXJlIGlzIHNvbWV0aGluZyBJIG1pc3NlZCBpbiBteSBsb2dpYy4NCg0KL0RpY2sNCg0KDQpP biBTdW4sIE9jdCAyOSwgMjAxNyBhdCAxMToyOCBBTSwgWWFyb24gU2hlZmZlciA8eWFyb25mLmll dGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkluIHRo YXQgY2FzZSwgbGV0J3MgYWRkIHRleHQgdG8gdGhhdCBlZmZlY3QsIGUuZy4gd2UgY291bGQgYWRk IHRvIHRoZSBkZWZpbml0aW9uIG9mIHRoZSAiZXZlbnRzIiBjbGFpbToNCg0KUHJvZmlsaW5nIHNw ZWNpZmljYXRpb25zIFNIT1VMRCBkZWZpbmUgdGhlIGFsbG93ZWQgZXZlbnQgc3RhdGVtZW50cywg YW5kIE1BWSByZXN0cmljdCB0aGVpciBudW1iZXIuIEZvciBleGFtcGxlLCBzb21lIHByb2ZpbGVz IG1heSByZXF1aXJlIHRoaXMgY2xhaW0gdG8gY29udGFpbiBvbmx5IGEgc2luZ2xlIGV2ZW50IHN0 YXRlbWVudC4NCg0KVGhhbmtzLA0KICAgICAgICBZYXJvbg0KDQpPbiAyNC8xMC8xNyAyMjoxMCwg TWlrZSBKb25lcyB3cm90ZToNCkkgYWdyZWUgd2l0aCBtdWNoIG9mIFBoaWzigJlzIHJhdGlvbmFs ZSBoZXJlLg0KDQpJdOKAmXMgZmluZSBmb3Igc29tZSBwcm9maWxlcyB0byBzYXkgdGhhdCB0aGUg 4oCcZXZlbnRz4oCdIHNldCBtdXN0IGJlIGEgc2luZ2xldG9uLiAgVGhhdCBkb2VzbuKAmXQgaGF2 ZSB0byBiZSB0cnVlIGZvciBhbGwgZXZlbnRzLiAgSSB0aGluayB0aGluZ3MgYXJlIGZpbmUgYXMt aXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQoqRnJvbToqIElkLWV2ZW50IFttYWlsdG86aWQtZXZl bnQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZz5dICpP biBCZWhhbGYgT2YgKlBoaWwgSHVudA0KKlNlbnQ6KiBNb25kYXksIE9jdG9iZXIgMjMsIDIwMTcg ODo0NyBQTQ0KKlRvOiogUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpv bi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+Pg0KKkNjOiogSUQgRXZlbnRzIE1haWxp bmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj4NCipT dWJqZWN0OiogUmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVy IFNFVD8NCg0KQW5uYWJlbGxlLA0KDQpJIGhhdmUgYSBudW1iZXIgb2YgY29uY2VybnMgd2l0aCB0 aGlzIHByb3Bvc2FsLg0KDQpQcm9maWxpbmcgSW5kZXBlbmRlbmNlIC8gS2VlcGluZyBFdmVudCBQ YXlsb2FkcyBJbmRlcGVuZGVudA0KDQpJbmRpY2F0aW5nIHRoYXQgZXh0ZW5zaW9ucyBzaG91bGQg YmUgaGFuZGxlZCBieSBwcm9maWxlcyBsZWFkcyB0byBtb3JlIGludGVyLW9wZXJhYmlsaXR5IGlz c3VlcyBhbmQgbW9yZSBpbXBvcnRhbnRseSBpbnRydWRlcyBvbiB0aGUgRXZlbnQgcGF5bG9hZCBz cGFjZSBieSBzdWdnZXN0aW5nIGEgc3ViLXNjaGVtYSBjcmVhdGVzIHBvdGVudGlhbCBsaW1pdGF0 aW9ucyBhbmQgY29uZmxpY3RzIHRoYXQgbWF5IGFkZCB0byBjb21wbGV4aXR5IGxhdGVyIG9uLiBU aGUgY3VycmVudCBmb3JtYXQgYWxsb3dzIGEgcGFyc2VyIHRvIGRpc2NvdmVyIGFuZCB1bmxvYWQg b25lIG9yIG1vcmUgSlNPTiBwYXlsb2FkcyB3aGljaCBjYW4gZWFjaCBoYXZlIGluZGVwZW5kZW50 IHN0cnVjdHVyZS4NCg0KR2VuZXJhbCBleHRlbnNpb25zDQoNClRoZSBwcm9wb3NhbCBhbHNvIHJ1 bGVzIG91dCBnZW5lcmFsIHB1cnBvc2UgZXh0ZW5zaW9ucyBub3QgcmVsYXRlZCB0byBhbnkgc3Bl Y2lmaWMgZXZlbnQuIEdpdmVuIHRoZSBlbWVyZ2VuY2Ugb2YgaXRlbXMgbGlrZSBHUFJELCBJIHdv dWxkIG5vdCB3YW50IHRvIGJsb2NrIHRoZSBhYmlsaXR5IHRvIGFkZCBtZXRhLWRhdGEgb3Igb3Ro ZXIgZ2VuZXJhbCBwdXJwb3NlIGl0ZW1zLiBXZSBjYW4gYWxzbyBhbnRpY2lwYXRlIHNvbWUgZGVs aXZlcnkgc2NlbmFyaW9zIHdoZXJlIGFkZGl0aW9uYWwgZGF0YSBtaWdodCBiZSByZXF1aXJlZC4g RXZlbiB0aG91Z2ggdGhlcmUgaXMgbm8gY3VycmVudCBwbGFubmVkIHVzZSwgSSBzZWUgbm8gZ29v ZCByZWFzb24gdG8gcnVsZSB0aGlzIG91dC4NCg0KTXVsdGlwbGUgRXZlbnRzIEZyb20gRGlmZmVy ZW50IEZhbWlsaWVzICh2cy4gTXVsdGlwbGUgRXZlbnRzIGZyb20gYSBzaW5nbGUgZmFtaWx5IGxp a2UgUklTQykNCg0KSW4gb3VyIFJJU0Mgc2Vzc2lvbiB3ZSBkaXNjdXNzZWQgZXhwcmVzc2luZyBt dWx0aXBsZSBkaXN0aW5jdCBSSVNDIGV2ZW50cyBpbiBvbmUgU0VULiBUaGUgZGlzY3Vzc2lvbiB3 YXMgdGhhdCBvbmx5IG9uZSBSSVNDIGV2ZW50IGF0IGEgdGltZS4gV2UgZGlkIG5vdCBkaXNjdXNz IG90aGVyIGV2ZW50IHByb2ZpbGVzLiBJIGRvbuKAmXQgc2VlIGEgcmVhc29uIHRvIHJ1bGUgb3V0 IG11bHRpLWV2ZW50cyBmcm9tIGRpZmZlcmVudCBmYW1pbGllcyBhdCB0aGUgU0VUIGxldmVsLiBF YWNoIHByb2ZpbGUgaXMgZXhwcmVzc2luZyBzbGlnaHRseSBkaWZmZXJlbnQgdGhpbmdzIGFib3V0 IHRoZSBzYW1lIGV2ZW50Lg0KDQpJIGNhbiBmb3JzZWUgc29tZSBjYXNlcyB3aGVyZSBpdCBpcyBu b3QgY2xlYXIgd2hpY2ggaXMgdGhlIHByaW1hcnkgYW5kIHdoaWNoIGlzIHRoZSBleHRlbnNpb24u ICBUaGVyZSBtYXkgbm90IGJlIGEgY2xlYXIgd2lubmVyLg0KDQpBIGNvdXBsZSBvZiBleGFtcGxl cyAodGhlc2UgYXJlIG5lY2Vzc2FyaWx5IHJlYWzigKZqdXN0IHBvc3NpYmlsaXRpZXMpOg0KDQoq IEl0IGlzIHByb2JhYmx5IHVzZWZ1bCB0byBiZSBhYmxlIHRvIGV4cHJlc3Mgc2ltbGFyL292ZXJs YXBwaW5nIGV2ZW50cyBmcm9tIGRpZmZlcmVudCBTRVQgcHJvZmlsZXMgaW4gb25lIFNFVC4gIEZv ciBleGFtcGxlIGEgQmFja2NoYW5uZWwgTG9nb3V0ICYgYSBSSVNDIHNlc3Npb24gY2FuY2VsIGV2 ZW50Lg0KDQoqIFNDSU0gbWF5IHdhbnQgdG8gcmVwcmVzZW50IGEgc2luZ2xlIHRyYW5zYWN0aW9u IGFzIGNhdXNpbmcgbXVsdGlwbGUgc3RhdGUgY2hhbmdlcyBpbiBhbiBldmVudCAoZS5nLiBhIHBh c3N3b3JkIGNoYW5nZSBjYXVzZXMgbXVsdGlwbGUgZWZmZWN0cykuIEhhdmluZyB0byBjaGFzZSBk b3duIG11bHRpcGxlIGV2ZW50cyBhbmQgY29ycmVsYXRlIGJ5IOKAnHR4buKAnSB3b3VsZCBiZSBj aGFsbGVuZ2luZyBpbiBhIG11bHRpLXRocmVhZGVkL211bHRpLW5vZGUgZGVsaXZlcnkgc3lzdGVt LiAgIFRoZSBTQ0lNIGxpc3QgaGFzIG5vdCBkaXNjdXNzZWQgdGhpcywgYnV0IEkgd291bGQgbm90 IHdhbnQgdG8gYmxvY2sgdGhpcyBjYXBhYmlsaXR5LiAgSU9XIC0gSnVzdCBiZWNhdXNlIFJJU0Mg ZG9lcyBub3Qgd2FudCB0byBleHByZXNzIG11bHRpcGxlIGV2ZW50cyBkb2VzIG5vdCBtYWtlIHRo aXMgdHJ1ZSBmb3Igb3RoZXIgcHJvZmlsZXMuDQoNCiogV2UgbWF5IHdpc2ggdG8gaW5kaWNhdGUg YSBTQ0lNIFBhc3N3b3JkIFJlc2V0IHdhcyBwZXJmb3JtZWQgYW5kIGEgTG9nb3V0L3Nlc3Npb24g Y2FuY2VsbGF0aW9uIGlzIGV4cHJlc3NlZCBhdCB0aGUgc2FtZSB0aW1lLiAgVGhlIGV2ZW50cyBh cmUgcmVsYXRlZCBidXQgZXhwcmVzcyBkaWZmZXJlbnQgZGF0YS4NCg0KQXZvaWRpbmcgQ29uZnVz aW9uIEZyb20gU2ltaWxhciBFdmVudHMgT3JpZ2luYXRpbmcgZnJvbSB0aGUgU2FtZSBUcmFuc2Fj dGlvbg0KDQpJZiBldmVudHMgYXJlIHNlbnQgc2VwYXJhdGVseSwgdGhlbiBtb3JlIHRyYWNraW5n IG9mIHN0YXRlIChlLmcuIGJ5IHR4bikgd291bGQgYmUgcmVxdWlyZWQgdG8gZW5zdXJlIHNpbWls YXIgZXZlbnRzIGFyZSBub3QgbWlzdGFrZW4gb3IgaGFuZGxlZCBhcyByZXBlYXRzLiBXaGlsZSB0 eG4gcHJvdmlkZXMgdXNlZnVsIGF1ZGl0IGFuYWx5c2lzIGNhcGFiaWxpdHksIEnigJltIG5vdCBz dXJlIGl0IGNhbiBiZSB1c2VkIGluIGxpdmUgb3IgbmVhci1yZWFsIHRpbWUgc3lzdGVtcyBnaXZl biBkaXN0cmlidXRlZCBtdWx0aS1ub2RlLCBtdWx0aS10aHJlYWRpbmcgYXJjaGl0ZWN0dXJlcy4N Cg0KUHJldmlvdXMgRGlzY3Vzc2lvbg0KDQpJIG5vdGUgdGhhdCBJIG9yaWdpbmFsbHkgcmFpc2Vk IGhhdmluZyBhbiBhdHRyaWJ1dGUgdG8gZGVzaWduYXRlIHByaW1hcnkgZXZlbnQgYXR0cmlidXRl IHRvIGFsbGV2aWF0ZSB5b3VyIGNvbmNlcm4sIGJ1dCB0aGlzIHdhcyBub3QgYWNjZXB0ZWQuIFNl ZToNCg0KKiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkLWV2ZW50L2N1 cnJlbnQvbXNnMDA0MDYuaHRtbDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfaWQtMkRldmVu dF9jdXJyZW50X21zZzAwNDA2Lmh0bWwmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBa aDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkx YUxjTE40S1pOQSZtPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcm cz1TM3NNVmlxTXZFZ253R2JKd09RTnljck95cjdTZWZwcV9Nb0ZPS2NFZUNFJmU9Pg0KDQoqIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3VycmVudC9tc2cw MDE0MC5odG1sPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRf bXNnMDAxNDAuaHRtbCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1V QjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5B Jm09WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZzPUd5OWd5Um9J SXRhLWNTaFY3Yk4xNjFheTR5RTZyOUcxX0FhX05lQm55bGcmZT0+DQoNClRoZSBjb25zZW5zdXMs IGF0IGxlYXN0IGFzIEkgaW50ZXJwcmV0ZWQgaXQgaXMgdXAgdG8gdGhlIHJlY2VpdmVyIHRvIGZp Z3VyZSB0aGlzIG91dCBiYXNlZCBvbiB0aGUgZGVmaW5pdGlvbnMgaXQgaGFzIGZvciBlYWNoIGV2 ZW50IFVSSSBhbmQgdGhlIHByb2ZpbGVzIHRoZXkgcmVwcmVzZW50LiBJT1cgLSBSSVNDIGlzIGZy ZWUgdG8gbGltaXQgdGhhdCBvbmx5IG9uZSBSSVNDIGV2ZW50IGJlIGV4cHJlc3NlZCBhdCBhIHRp bWUuDQoNClBoaWwNCg0KT3JhY2xlIENvcnBvcmF0aW9uLCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNl cyBBcmNoaXRlY3QNCg0KQGluZGVwZW5kZW50aWQNCg0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5k ZXBlbmRlbnRpZC5jb20mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJN VUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pO QSZtPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmcz05TlA1bmFt ZzZySVZ6d3VuOWMtMXEwd2hzeVh3U3Z0SEIwZjJkS2tmQ1g4JmU9PiA8aHR0cDovL3d3dy5pbmRl cGVuZGVudGlkLmNvbTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cC0zQV9fd3d3LmluZGVwZW5kZW50aWQuY29tJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1 WXFQa0FJMWFMY0xONEtaTkEmbT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtS bFFHMWl3JnM9OU5QNW5hbWc2cklWend1bjljLTFxMHdoc3lYd1N2dEhCMGYyZEtrZkNYOCZlPT4+ DQoNCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4gPG1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pg0K DQogICAgT24gT2N0IDIzLCAyMDE3LCBhdCA3OjAyIFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFi ZWxsZQ0KICAgIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29t PiA8bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+ Pj4gd3JvdGU6DQoNCiAgICBUaGUgY3VycmVudCBkcmFmdCBvZiB0aGUgU0VUIHNwZWMgYWxsb3dz IGZvciBleHByZXNzaW5nIG11bHRpcGxlDQogICAgZXZlbnRzIHdpdGhpbiB0aGUgc2FtZSB0b2tl biwgd2hpY2ggaW50cm9kdWNlcyBhZGRpdGlvbmFsIGNvbXBsZXhpdHkNCiAgICBhbmQgcm9vbSBm b3IgYW1iaWd1b3VzIHNlbWFudGljcy4gV2XigJl2ZSBkaXNjdXNzZWQgdGhpcyBpbiB0aGUgT0lE Rg0KICAgIFJJU0Mgd29ya2luZyBncm91cCBhbmQgdGhlIGN1cnJlbnQgY29uc2Vuc3VzIHRoZXJl IGlzIHRoYXQgUklTQyB3aWxsDQogICAgcmVxdWlyZSB0aGF0IFJJU0MgZXZlbnRzIG11c3QgYmUg dGhlIG9ubHkgZXZlbnQgaW4gdGhlIFNFVCwgaGF2aW5nDQogICAgaWRlbnRpZmllZCB3YXlzIHRv IGNsZWFybHkgYW5kIGVhc2lseSBzdXBwb3J0IHRoZSBoYW5kZnVsIG9mIHVzZQ0KICAgIGNhc2Vz IGZvciBtdWx0aXBsZSBldmVudHMgcGVyIHRva2VuIHRoYXQgcGVvcGxlIGhhdmUgcmFpc2VkLiBX aXRoDQogICAgdGhhdCBjb250ZXh0IGluIG1pbmQsIEkgcHJvcG9zZSBzdHJpa2luZyB0aGUgZGVm aW5pdGlvbiBvZiB0aGUNCiAgICDigJxldmVudHPigJ0gY2xhaW0gZnJvbSB0aGUgU2VjdXJpdHkg RXZlbnQgVG9rZW4gc3BlYywgYW5kIHJlcGxhY2luZyBpdA0KICAgIHdpdGggdGhlIGZvbGxvd2lu ZyBkZWZpbml0aW9uIGZvciBhbiDigJxldmVudOKAnSBjbGFpbSAoc2luZ3VsYXIpOg0KDQogICAg ZXZlbnQNCg0KICAgIEEgSlNPTiBvYmplY3QgY29udGFpbmluZyBhbiAiZXZlbnRfdHlwZSIgbWVt YmVyIHdob3NlIHZhbHVlIGlzIGEgVVJJDQogICAgcmVwcmVzZW50aW5nIGEgdHlwZSBvZiBldmVu dCBkZWZpbmVkIGluIGEgUHJvZmlsaW5nIFNwZWNpZmljYXRpb24uDQogICAgVGhlIG9iamVjdCBN QVkgb3RoZXJ3aXNlIGJlIGVtcHR5LCBvciBNQVkgY29udGFpbiBhZGRpdGlvbmFsIG1lbWJlcnMN CiAgICBhcyBkZXNjcmliZWQgYnkgdGhlIFByb2ZpbGluZyBTcGVjaWZpY2F0aW9uLg0KDQogICAg SGVyZSBpcyB0aGUgZXhhbXBsZSBTRVQgZnJvbSBzZWN0aW9uIDIuMywgcmV3cml0dGVuIHdpdGgg dGhpcyBjaGFuZ2UNCiAgICBtaW5kOg0KDQogICAgew0KDQogICAgICAgImp0aSI6ICI0ZDM1NTll YzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsDQoNCiAgICAgICAiaWF0IjogMTQ1ODQ5NjQwNCwN Cg0KICAgICAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5jb208aHR0cHM6Ly9zY2ltLmV4 YW1wbGUuY29tLz4gPGh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8+IiwNCg0KICAgICAgICJhdWQi OiBbDQoNCiAgICAgICAgICJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFm YTViYmM4Nzk1OTNiNzc1NCIsDQoNCiAgICAgICAgICJodHRwczovL3NjaW0uZXhhbXBsZS5jb20v RmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyINCg0KICAgICAgIF0sDQoNCiAgICAgICAi ZXZlbnQiOiB7DQoNCiAgICAgICAgICJldmVudF90eXBlIjogInVybjppZXRmOnBhcmFtczpzY2lt OmV2ZW50OmNyZWF0ZSIsDQoNCiAgICAgICAgICJyZWYiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUu Y29tL1VzZXJzLzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLA0KDQogICAgICAgICAiYXR0cmli dXRlcyI6IFsiaWQiLCAibmFtZSIsICJ1c2VyTmFtZSIsICJwYXNzd29yZCIsICJlbWFpbHMiXQ0K DQogICAgICAgfQ0KDQogICAgfQ0KDQogICAgRG9lcyBhbnlvbmUgaW4gdGhlIHdvcmtpbmcgZ3Jv dXAgaGF2ZSB1c2UgY2FzZXMgZm9yIFNFVHMgdGhhdCBjYW5ub3QNCiAgICBiZSBtZXQgYnkgdGhp cyBwcm9wb3NlZCB0ZXh0PyBXaXRoaW4gUklTQywgd2UgaWRlbnRpZmllZCB0aHJlZSB1c2UNCiAg ICBjYXNlcywgd2l0aCBzb2x1dGlvbnMgb3V0bGluZWQgYmVsb3c6DQoNCiAgICAqKg0KDQogICAg KkV4dGVuc2lvbnMqDQoNCiAgICBFdmVudCBleHRlbnNpb24gbWVjaGFuaXNtcyBjYW4gYmUgZGVm aW5lZCBpbnRlcm5hbCB0byB0aGUgZXZlbnQNCiAgICBvYmplY3QuIEEgc2ltcGxlIGFwcHJvYWNo IHdvdWxkIGJlIHRvICBkZWZpbmUgYW4g4oCcZXh0ZW5zaW9uc+KAnSBtZW1iZXINCiAgICB0aGF0 IGlzIGEgbGlzdCBvZiBldmVudCBvYmplY3RzIChvciBzZXQgcmVzZW1ibGluZyB0aGUg4oCcZXZl bnRz4oCdDQogICAgY2xhaW0gYXMgZGVmaW5lZCBpbiB0aGUgY3VycmVudCBzcGVjKS4gVGhpcyBo YXMgdGhlIGFkdmFudGFnZSBvZg0KICAgIG1ha2luZyBpdCBjbGVhciBpbiB0aGUgZGF0YSBzdHJ1 Y3R1cmUgdGhhdCB0aGVyZSBpcyBhIHNpbmdsZSBwcmltYXJ5DQogICAgZXZlbnQsIHdpdGggemVy byBvciBtb3JlIGV4dGVuc2lvbnMuIFRoZXJlIGlzIG5vIHJvb20gZm9yIGNvbmZ1c2lvbg0KICAg IG92ZXIgd2hpY2ggZXZlbnQgaXMgcHJpbWFyeSwgb3IgaWYgdGhlcmUgaXMgYSBwcmltYXJ5IGV2 ZW50IGF0IGFsbC4NCiAgICBJIHdvdWxkIGJlIGZpbmUgd2l0aCBhZGRpbmcgc29tZXRoaW5nIGxp a2UgdGhpcyB0byBteSBwcm9wb3NlZCB0ZXh0LA0KICAgIGlmIHRoZXJlIGlzIGNvbnNlbnN1cyB0 aGF0IGl0IGlzIGJyb2FkbHkgdXNlZnVsLg0KDQogICAgKkFsaWFzZXMqDQoNCiAgICBUaGlzIHVz ZSBjYXNlIHdhcyBicm91Z2h0IHVwIGluIHRoZSBjb250ZXh0IG9mIG1pZ3JhdGluZyBjbGllbnRz DQogICAgZnJvbSBkcmFmdCBldmVudCBuYW1lcyB0byBzdGFuZGFyZGl6ZWQgZXZlbnQgbmFtZXMu IEluIHRoaXMgY2FzZSwNCiAgICB0aGUgZXZlbnQgdHJhbnNtaXR0ZXIgY2FuIHRyYW5zbWl0IHR3 byB0b2tlbnMgZm9yIHRoZSBsb2dpY2FsIGV2ZW50LA0KICAgIG9uZSB1c2luZyB0aGUgb2xkIG5h bWUgYW5kIGFub3RoZXIgdXNpbmcgdGhlIG5ldyBuYW1lLg0KDQogICAgKlJlbGF0ZWQgRXZlbnRz Kg0KDQogICAgVGhlIFNFVCBzcGVjIGRlZmluZXMgdGhlIHR4biBjbGFpbSBhcyBhIG1lYW5zIG9m IGNvcnJlbGF0aW5nDQogICAgaW5kZXBlbmRlbnQgdG9rZW5zIHRoYXQgcmVsYXRlIHRvIHRoZSBz YW1lIGxvZ2ljYWwgZXZlbnQuDQoNCiAgICAtLQ0KICAgIEFubmFiZWxsZSBSaWNoYXJkIEJhY2tt YW4NCg0KICAgIEFtYXpvbiDigJMgSWRlbnRpdHkgU2VydmljZXMNCg0KICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgSWQtZXZlbnQgbWFpbGlu ZyBsaXN0DQogICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPiA8 bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4+DQogICAg aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNl R0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1zNWJ5QmU1S0FObkdWdUFiMW1BdXBFR29KbjhYRzVK SVVVd1dHRlNpYkVjJnM9WDhvUlNxM0l6bEY3amlSQWVaaFhwUjNlVkkwSTU4WkZkNGVFWmZneW9J WSZlPQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2 ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1l dmVudDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01GYVEmYz1Sb1Ax WXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdO eTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPVlCQ0dsSzltampoY0Zzai0ydERrbjMxQXV4 dXJ1aWI5S0FUa1JsUUcxaXcmcz1Xck11UVJ3TFY4MDJpTVE0d1lCMWYyckZVR3U0emJoY1cwMDFm SzAyRVhzJmU9Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQt ZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk LWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUZhUSZjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5x V055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFB dXh1cnVpYjlLQVRrUmxRRzFpdyZzPVdyTXVRUndMVjgwMmlNUTR3WUIxZjJyRlVHdTR6YmhjVzAw MWZLMDJFWHMmZT0+DQoNCg0KDQotLQ0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkU8aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5j b21fJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0pu RSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1ZQkNHbEs5 bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JnM9TFlONzJHZ0tWaEhzVDZ0QXFC ZS1lTW9XTXZ5XzdkZkZuMXVaMEhLNll1USZlPT4gbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHBy b2plY3RzIEkgYW0gd29ya2luZyBvbiENCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3Jn PG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQt MkRldmVudCZkPUR3SUNBZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFw SV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09WUJD R2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZzPVdyTXVRUndMVjgwMmlN UTR3WUIxZjJyRlVHdTR6YmhjVzAwMWZLMDJFWHMmZT0NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZl bnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3 cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xO NEtaTkEmbT1VLWE1SEJORDBIYVRYNGFuTlpmelg3cERzZks1ZjBoOW1aOUNaa2tHaWVjJnM9cnZk cnRJN3JZTlJBbnFaRGx0Q3dCQVpWSEtwLU1KMjB1aTJubTQ2UVN6MCZlPQ0KDQoNCg0KDQotLQ0K U3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkU8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmQ9RHdNRmFRJmM9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBj dHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1peVZuclptcjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3 eUZfOHU4X3FTQ193JnM9d3RnRDNOcDB2eWhMZHBFd1VpcXNmNEl0aXdBM09tN0dyb2I3MEx4MHIz ayZlPT4gbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiEN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVu dCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9y Zz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZjPVJvUDFZ dW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055 NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2 bEs2N3lGXzh1OF9xU0NfdyZzPU9lMHFmTEVYODN2dFhNN1dsMmNZQmUtR2cxRFZQamhYalZKa2Zo VlJ6d2MmZT0NCg0KDQoNCi0tDQpTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRTxodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8m ZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9 bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPXNJR3o4Z3VyNHdO cVprdGNtYWd2NUVhMjFRRWlwNEhYcEVWS1JhMHFobG8mcz1WOWd5VFRYOXF1anJDMlZsaXdMUHkw LUt2eFM5cFlLSl8ta3lEYXB3TzhrJmU9PiBtYWlsIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVj dHMgSSBhbSB3b3JraW5nIG9uIQ0KDQoNCg0KLS0NClN1YnNjcmliZSB0byB0aGUgSEFSRFRXQVJF PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJk dHdhcmUuY29tXyZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1 ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09 c0lHejhndXI0d05xWmt0Y21hZ3Y1RWEyMVFFaXA0SFhwRVZLUmEwcWhsbyZzPVY5Z3lUVFg5cXVq ckMyVmxpd0xQeTAtS3Z4UzlwWUtKXy1reURhcHdPOGsmZT0+IG1haWwgbGlzdCB0byBsZWFybiBh Ym91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hDQoNCg0KDQotLQ0KU3Vic2NyaWJlIHRvIHRo ZSBIQVJEVFdBUkU8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHAtM0FfX2hhcmR0d2FyZS5jb21fJmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4 QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFM Y0xONEtaTkEmbT1zSUd6OGd1cjR3TnFaa3RjbWFndjVFYTIxUUVpcDRIWHBFVktSYTBxaGxvJnM9 VjlneVRUWDlxdWpyQzJWbGl3TFB5MC1LdnhTOXBZS0pfLWt5RGFwd084ayZlPT4gbWFpbCBsaXN0 IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QN CklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4 UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtB STFhTGNMTjRLWk5BJm09c0lHejhndXI0d05xWmt0Y21hZ3Y1RWEyMVFFaXA0SFhwRVZLUmEwcWhs byZzPWdkTnJzN1VEQXR0cGFiak01bmRPWHdXS21adUthWEViVDV3dTlyY09SVjAmZT0NCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQg bWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlx UGtBSTFhTGNMTjRLWk5BJm09dU5pV1FseUtHVHUtOXA1cUpMUlMxRi0zeUtYcERBQjdLdHBrQ0Rj X0pDVSZzPUY4X2o4UlpEbGJVUDFwLTFRZmdPRW5yWk8tM0lhZzdZdWwxTksxeHA0SnMmZT0+DQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2 ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDxodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQ cHVZcVBrQUkxYUxjTE40S1pOQSZtPXVOaVdRbHlLR1R1LTlwNXFKTFJTMUYtM3lLWHBEQUI3S3Rw a0NEY19KQ1Umcz1GOF9qOFJaRGxiVVAxcC0xUWZnT0VuclpPLTNJYWc3WXVsMU5LMXhwNEpzJmU9 Pg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJ ZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdt YW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09dU5pV1FseUtHVHUtOXA1cUpMUlMx Ri0zeUtYcERBQjdLdHBrQ0RjX0pDVSZzPUY4X2o4UlpEbGJVUDFwLTFRZmdPRW5yWk8tM0lhZzdZ dWwxTksxeHA0SnMmZT0NCg== --_000_8B223079B4DF492A808290732DCF2C52amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <654132858BBF8A4FAE51BBA591CBD58F@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCXBh bm9zZS0xOjIgNyAzIDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi Q2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCnNwYW4uSFRNTFByZWZv cm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIixzZXJpZjt9DQpzcGFuLm0tMzE1MTQ0NTk1ODQ1 MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1zdHls ZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOm1fLTMxNTE0NDU5NTg0NTEwMjkzMThtXzc0NzYzNDY5 NDY5NTY4MzMwMDRtXzU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4u bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2 MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTptXy0zMTUxNDQ1OTU4 NDUxMDI5MzE4bV83NDc2MzQ2OTQ2OTU2ODMzMDA0bV81NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUt Y29udmVydGVkLXNwYWNlO30NCnNwYW4ubS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5 NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1 NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6bV8tMzE1MTQ0NTk1ODQ1MTAyOTMx OG1fNzQ3NjM0Njk0Njk1NjgzMzAwNG1fNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3 MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0 NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5tLTMxNTE0NDU5NTg0NTEw MjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNGhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTptXy0zMTUx NDQ1OTU4NDUxMDI5MzE4bV83NDc2MzQ2OTQ2OTU2ODMzMDA0aG9lbnpiO30NCnNwYW4uRW1haWxT dHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQ2MDgwOTM3NzsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIwNDI4ODI2MjA7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3Qt aWQ6NTU0NTg2NDUzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTA5OTkzNzI5MDt9DQpAbGlz dCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3Qt aWQ6MTA2MTQ4OTUxMzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTg0ODE1MjQ4MDt9DQpAbGlz dCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTUwOTU1ODY5 NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEyODY3MjI3NzY7fQ0KQGxpc3QgbDM6bGV2ZWwx DQoJe21zby1sZXZlbC1zdGFydC1hdDozOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UGhpbCwgSSBkb27igJl0IGZvbGxvdyB3aGF0IHlvdeKAmXJlIGRlc2Ny aWJpbmcgaW4gdGhpcyBzY2VuYXJpby4gQ2FuIHlvdSBwcm92aWRlIGFuIGV4YW1wbGU/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5JZGVudGl0eSBTZXJ2aWNlczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mcXVvdDtQaGlsIEh1 bnQgKElETSkmcXVvdDsgJmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5XZWRuZXNkYXksIE5vdmVtYmVyIDEsIDIwMTcgYXQgMzowNyBQTTxicj4NCjxiPlRvOiA8 L2I+TWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7bXNjdXJ0ZXNjdUBnb29nbGUuY29tJmd0Ozxicj4NCjxi PkNjOiA8L2I+V2lsbGlhbSBEZW5uaXNzICZsdDt3ZGVubmlzc0Bnb29nbGUuY29tJmd0OywgJnF1 b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hQGFtYXpvbi5j b20mZ3Q7LCBZYXJvbiBTaGVmZmVyICZsdDt5YXJvbmYuaWV0ZkBnbWFpbC5jb20mZ3Q7LCBNaWtl IEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7LCBJRCBFdmVudHMgTWFp bGluZyBMaXN0ICZsdDtpZC1ldmVudEBpZXRmLm9yZyZndDssIERpY2sgSGFyZHQgJmx0O2RpY2su aGFyZHRAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0lkLWV2ZW50XSBV c2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCBzZWUgbXVs dGkgdmFyaWFudHMuIEkgc2VlIG11bHRpcGxlIHBhcnRzPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBleGFtcGxlIHlvdSBoYXZlIGFsbCB0aGUgcmlzYyBl dmVudHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJl Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IHRv IHN1cHBvcnQgaW1wbGljaXQgZmVkZXJhdGlvbiB1c2VycyAod2hpY2ggaGF2ZSB0byBiZSBpZGVu dGlmaWVkIGJ5IG9uZSBvciBtb3JlIGlkZW50aWZpZXJzKSwgeW91IG1pZ2h0IGRlZmluZSBhIHV0 aWxpdHkgZXZlbnQgcHJvZmlsZSB3aGljaCBjb250YWlucyBhdHRyaWJ1dGVzIGZvciBlbWFpbCwg dGVsZXBob25lLCB1c2VybmFtZSBldGMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPklmIHlvdSBkaWRuJ3QgZ2V0IGJvdGggcGFydHMgb2YgdGhlIHNldCBhcyBv bmUgc2V0IGl0IHdvdWxkIGhhdmUgZGlmZmVyZW50IG1lYW5pbmcgb3IgYmUgY29uc2lkZXJlZCBt YWxmb3JtZWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFp bFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBhZHZhbnRhZ2UgaW4gcmlzYyBpcyBub3QgaGF2aW5nIHRvIGhhdmUgYSB0b25uZSBv ZiBvcHRpb25hbCBpZCBhdHRyaWJ1dGVzIGluIGV2ZXJ5IGV2ZW50LiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFp bFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcG9pbnQgaGVyZSBpcyByZWFz b25hYmxlIGZsZXhpYmlsaXR5IGZvciBwcm9maWxlcnMgdG8gZGVjaWRlLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxl TWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GaW5hbGx5IGkgYWxyZWFkeSBn YXZlIHRoZSBvdmVybGFwcGVkIHJpc2Mvc2NpbSBwYXNzd29yZCByZXNldCBjYXNlLiZuYnNwOzxi cj4NCjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gTm92IDEsIDIw MTcsIGF0IDI6NTQgUE0sIE1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1 cnRlc2N1QGdvb2dsZS5jb20iPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE5vdiAxLCAyMDE3IGF0IDI6NDYgUE0sIFdpbGxpYW0g RGVubmlzcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20iIHRhcmdldD0i X2JsYW5rIj53ZGVubmlzc0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBlcmhhcHMgSSBjYW4g dHJ5IGFuZCBleHBsYWluIHRoZSBvcmlnaW5hbCBpbnRlbnQgb2YgdGhlIGN1cnJlbnQgZGVzaWdu LiBUaGUgZ29hbCB3YXMgYWx3YXlzIHRoYXQgYSBTRVQgcmVwcmVzZW50cyBhIHNpbmdsZSBsb2dp Y2FsIGV2ZW50LiBIb3dldmVyIG11bHRpcGxlIHN5c3RlbXMgbWF5IGhhdmUgZGlmZmVyZW50IHJl cHJlc2VudGF0aW9ucyBvZiB0aGUgZXZlbnQg4oCTIHRoZSBleGFtcGxlIGdpdmVuIG9yaWdpbmFs bHkNCiB3YXMgb25lIGZvcm1hdHRlZCBmb3IgUklTQywgYW5kIG9uZSBmb3IgU0NJTS4gPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGdvb2QgYW5hbG9neSBp cyBlbWFpbC4gWW91IHNlbmQgYSBzaW5nbGUgbG9naWNhbCBlbWFpbCwgd2hpY2ggbWF5IGhhdmUg dHdvIHJlcHJlc2VudGF0aW9ucywgSFRNTCBhbmQgcGxhaW4gdGV4dC4gU3lzdGVtcyBjYW4gY29u c3VtZSB0aGUgdmVyc2lvbiB0aGF0IHRoZXkgdW5kZXJzdGFuZCBhbmQgaWdub3JlIHRoZSBvbmUg dGhleSBkb24ndC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIGFuZCBJIHRoaW5rIHRoaXMgaXMg d2VsbCB1bmRlcnN0b29kLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gc3RhcnRpbmcgdG8gcmVn cmV0IHRoZSBwbHVyYWwgaW4gJnF1b3Q7ZXZlbnRzJnF1b3Q7LCBpdCB3YXMgcGx1cmFsaXplZCBk dWUgdG8gaXQgYmVpbmcgYW4gYXJyYXksIG5vdCBiZWNhdXNlIGl0IHJlcHJlc2VudGVkIG11bHRp cGxlIGxvZ2ljYWwgZXZlbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgdGhp cyBpcyB0aGUgbWFpbiBjb25jZXJuIG9yIGNhdXNlIGZvciBjb25mdXNpb24uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFubmFiZWxsZSwgSSB1bmRlcnN0YW5kIHlvdXIgY29uY2VybnMgcmVnYXJkaW5n IGNvbmZ1c2lvbiBvZiB0aGUgc2VtYW50aWNzIGJldHdlZW4gdGhlIEpTT04gc3ludGF4IGFuZCB0 aGUgc3BlY2lmaWNhdGlvbiBsYW5ndWFnZS4gQXJlIHRoZXJlIG90aGVyIHdheXMgdG8gcmVzb2x2 ZSB0aGF0IHdpdGhvdXQgcmVtb3ZpbmcgdGhlIGFiaWxpdHkgZm9yIG11bHRpcGxlIHJlcHJlc2Vu dGF0aW9ucyBvZiB0aGUgc2FtZQ0KIGV2ZW50PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBhcmd1 bWVudCBpcyB0aGF0IG11bHRpcGxlIHJlcHJlc2VudGF0aW9ucyBjYW4gYmUgc2VudCBhcyBkaXN0 aW5jdCBTRVRzLCBpZiByZWFsbHkgbmVlZGVkLiBJbiBwcmFjdGljZSB0aGlzIHdpbGwgaGFwcGVu IHF1aXRlIHJhcmUgdGhvdWdoLiBFdmVudHMgYXJlIGNyZWF0ZWQgZm9yIGEgc3BlY2lmaWMgcmVj ZWl2ZXIsIHRoZSByZWNlaXZlciBlaXRoZXIgd2FudHMgdGhlIFNDSU0gb3IgdGhlIFJJU0MgZmxh dm9yLA0KIGFuZCB0aGV5IHNob3VsZCBiZSBhYmxlIHRvIHNwZWNpZnkgdGhhdCBpbiBjb25maWd1 cmF0aW9uICh0aGVyZSBpcyBhIHByb3Bvc2FsIGhvdyB0byBjYXB0dXJlIHRoYXQpLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB3ZSBoYXZl IGEgY29tcGVsbGluZyB1c2UgY2FzZSB3aGVyZSBhIHJlY2VpdmVyIG11c3QgcmVjZWl2ZSBtdWx0 aXBsZSB2YXJpYW50cyBhbGwgYXQgb25jZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBOb3YgMSwgMjAxNyBhdCAy OjM3IFBNLCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBn b29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBOb3YgMSwgMjAxNyBhdCAxMjo0NSBQTSwgUGhp bCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgY2Fu4oCZdCBy ZWFsbHkgaGF2ZSBtdWx0aXBsZSBldmVudHMgKGF0IGxlYXN0IG9mIHRoZSBzYW1lIHR5cGUpLiZu YnNwOyBUaGUgY3VycmVudCBzcGVjIGNhbiBvbmx5IGhhdmUgb25lIGluc3RhbmNlIG9mIGEgVVJJ IChhZmFpaykuICZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Ob3RlIHRoYXQgdGhlIHNwZWMgbm9ybWF0aXZlbHkgZG9lcyBub3Qgc3VwcG9ydCBt dWx0aXBsZSBldmVudCBTRVRTLiZuYnNwOyBJdCBjdXJyZW50bHkgc3RhdGVzOg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cHJlPmV2ZW50czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8Yj5UaGUgc2VtYW50aWNzIG9mIHRoaXMgY2xhaW0g aXMgdG8gZGVmaW5lIGEgc2V0IG9mIGV2ZW50IHN0YXRlbWVudHM8bzpwPjwvbzpwPjwvYj48L3By ZT4NCjxwcmU+PGI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgZWFjaCBNQVkg YWRkIGFkZGl0aW9uYWwgY2xhaW1zIHRvIGZ1bGx5IGRlc2NyaWJlIGEgc2luZ2xlPG86cD48L286 cD48L2I+PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsb2dp Y2FsIGV2ZW50PC9iPiB0aGF0IGhhcyBvY2N1cnJlZCAoZS5nLiBhIHN0YXRlIGNoYW5nZSB0byBh PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1 YmplY3QpLiZuYnNwOyBNdWx0aXBsZSBldmVudCBzdGF0ZW1lbnRzIG9mIHRoZSBzYW1lIHR5cGUg U0hBTEwgTk9UIGJlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGFjY2VwdGVkLiZuYnNwOyBUaGUgJnF1b3Q7ZXZlbnRzJnF1b3Q7IGNsYWltIFNI T1VMRCBOT1QgYmUgdXNlZCB0byBleHByZXNzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG11bHRpcGxlIGxvZ2ljYWwgZXZlbnRzLjxvOnA+PC9v OnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgc3BlYyBoYXMgKmFsd2F5cyogc3VwcG9ydGVkIHJlcXVpcmVtZW50cyAoYXMgc3RhdGVkIGlu IHRoZSBzcGVjKSBmb3IgbXVsdGlwbGUgc2VwYXJhdGUgcHJvZmlsZSBzdGF0ZW1lbnRzIChmcm9t IG9uZSBvciBtb3JlIHByb2ZpbGUgZmFtaWxpdGllcykgbmVlZGluZyB0byBiZSBzZW50IGFzIGEg c2luZ2xlIG1lc3NhZ2UuJm5ic3A7IEl0IHdvdWxkIGJlIElOU0VDVVJFIHRvIGZvcmNlIG11bHRp cGxlIFNFVHMgYmVjYXVzZQ0KIHRoZSBjdXJyZW50IGRlbGl2ZXJ5IG1lY2hhbmlzbSBvbmx5IGFs bG93cyBvbmUgU0VUIHRvIGJlIGRlbGl2ZXJlZCBhdCBhIHRpbWUuIFRoZXJlIGlzIG5vIHdheSB0 byBhc3N1cmUgdGhhdCBhIHNpbmdsZSByZWNlaXZlciBnZXRzIGFsbCBvZiB0aGUgU0VUcyBpdCBu ZWVkcyBpbiBhIG11bHRpLXRocmVhZGVkLCBtdWx0aS1ub2RlIGVudmlyb25tZW50IGF0IHNjYWxl LiZuYnNwOyBBc3NlbWJsaW5nIG11bHRpcGxlIFNFVHMgdG8gdHJhY2sg4oCcdHhu4oCdIGluIGEN CiBjb21tb24gc3RhdGUgZGF0YWJhc2UgaXMgTk9UIHNpbXBsZSBub3IgY29zdCBlZmZlY3RpdmUu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdG90YWxseSBhZ3JlZSB0aGF0 IGl0IGlzIGRpZmZpY3VsdCBmb3IgcmVjZWl2ZXJzIHRvIHJlY2VpdmUgc2VwYXJhdGUgZXZlbnRz LCBpbiBubyBwYXJ0aWN1bGFyIG9yZGVyIGFuZCBjb3JyZWxhdGUgYmFzZWQgb24gJnF1b3Q7dHhu JnF1b3Q7LiBCdXQsIHJlY2VpdmVycyBoYXZlIHRvIHNvbHZlIHRoaXMgaXNzdWUgcmVnYXJkbGVz cyBvZiAmcXVvdDtldmVudHMmcXVvdDsgb3IgJnF1b3Q7ZXZlbnQmcXVvdDssIHNvIGl0IGlzIHVu cmVsYXRlZCB0byB0aGlzIHByb3Bvc2FsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPklmIHdlIGFjY29tbW9kYXRlIHRoaXMgaW4gdGhlIHByb3Bvc2VkIGZvcm0sIHdlIGVuZCB1 cCB3aXRoIGEgY29tcGxleCwgZGVlcGx5IG5lc3RlZCBKU09OIHN0cnVjdHVyZSB3aXRoIHRoZSBw b3NzaWJpbGl0eSBvZiBuYW1lc3BhY2UgY29uZmxpY3RzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTU8gVGhlIHByb3Bvc2FsIGRvZXMgbm90 IHNpbXBsaWZ5LCBpdCBjb21wbGljYXRpbmcgYW5kIGxpbWl0aW5nLiAmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGN1cnJlbnQg c3BlYyBoYXMgdmVyeSBjbGVhbiBKU09OIGFuZCBhdm9pZHMgbmFtZXNwYWNlIGNvbmZsaWN0cyBi ZXR3ZWVuIHByb2ZpbGVzLiBJIHRoaW5rIHdlIHNob3VsZCBzdGF5IG9uIHRyYWNrIHdpdGggdGhl IGN1cnJlbnQgZHJhZnQgYW5kIG9ic2VydmUgdGhlIG5vcm1hdGl2ZSB0ZXh0IGlmIG5vdCBtYWtl IGl0IHN0cm9uZ2VyIGluIHJlZ2FyZHMgdG8gbXVsdGktZXZlbnRzICh1bmRlcnN0b29kIHRoYXQN CiBNaWtlIG1heSBkaXNhZ3JlZSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkg Q2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5AaW5k ZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVu dGlkLmNvbSZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUly TVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNM TjRLWk5BJmFtcDttPXVOaVdRbHlLR1R1LTlwNXFKTFJTMUYtM3lLWHBEQUI3S3Rwa0NEY19KQ1Um YW1wO3M9bHJjV3RMbzZaQV8ycG9ZWndteW1paWljTmx3eWt5UUpvazNHZWNjR0FZWSZhbXA7ZT0i IHRhcmdldD0iX2JsYW5rIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTm92IDEsIDIwMTcsIGF0IDEyOjE4 IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hh bm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlVubGVzcyB0aGUgcHJvZmlsZSBndWFyYW50 ZWVzIHRoYXQgc3VjaCByZWxhdGVkIGV2ZW50cyB3aWxsIGFsd2F5cyBiZSBpbmNsdWRlZCBpbiB0 aGUgc2FtZSBTRVQsIHRoZW4gdGhlIHJlY2VpdmVyIGhhcyB0byBjb3JyZWxhdGUgYWNyb3NzIFNF VHMgYW55d2F5LCBhbmQgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQgaXMganVzdCBnaXZpbmcgdGhl IHJlY2VpdmVyIGFub3RoZXINCiBzY2VuYXJpbyB0aGF0IHRoZXkgaGF2ZSB0byBzdXBwb3J0Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPknigJl2ZSBhbHJl YWR5IHByb3ZpZGVkIHNldmVyYWwgb3RoZXIgcmVhc29ucyB3aHkgd2Ugc2hvdWxkIG5vdCBzdXBw b3J0IG11bHRpcGxlIHRva2VucyBwZXIgU0VUIHRoYXQgbm8gb25lIGhhcyBhZGRyZXNzZWQuIEhl cmUgdGhleSBhcmUgYWdhaW46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxvbCBzdHlsZT0ibWFy Z2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm8xO2JhY2tncm91bmQ6 d2hpdGUiPg0KTXVsdGlwbGUgZXZlbnQgc3VwcG9ydCByZXN1bHRzIGluIGEgbW9yZSBjb21wbGV4 IHN0cnVjdHVyZSBmb3IgdGhlIHNpbmdsZSBldmVudCB1c2UgY2FzZSwgd2hpY2ggSSB0aGluayB3 ZSBhbGwgYWdyZWUgaXMgdGhlIG1ham9yaXR5IHVzZSBjYXNlLjxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZl bDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4NCk11bHRpcGxlLWV2ZW50IFNFVHMgaGF2ZSBhbWJp Z3VvdXMgc2VtYW50aWNzLiBUaGUgcHJlc2VuY2Ugb2YgdHdvIGV2ZW50cyBBIGFuZCBCIGluIHRo ZSBzYW1lIFNFVCBjb3VsZCBtZWFuIGFueSBvZjoNCjxvOnA+PC9vOnA+PC9saT48L29sPg0KPG9s IHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjIiIHR5cGU9IjEiPg0KPG9sIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzE7YmFja2dyb3Vu ZDp3aGl0ZSI+DQpBIGFuZCBCIGFyZSByZWxhdGVkIHRvIHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQg KGkuZS4gdGhlIHNhbWUgdGhpbmcgYXMgaWYgdGhleSB3ZXJlIGZyb20gZGlmZmVyZW50IFNFVHMg dGhhdCBoYXZlIGEgY29tbW9uIHR4bikuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMiBsZm8xO2JhY2tn cm91bmQ6d2hpdGUiPg0KQSBpcyBhbiBleHRlbnNpb24gb2YgQi48bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2 ZWwyIGxmbzE7YmFja2dyb3VuZDp3aGl0ZSI+DQpCIGlzIGFuIGV4dGVuc2lvbiBvZiBBLjxvOnA+ PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMiBsZXZlbDIgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4NCkEgaXMgYW4gYWxpYXMg Zm9yIEIsIG9yIHZpY2UtdmVyc2EuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMiBsZm8xO2JhY2tncm91 bmQ6d2hpdGUiPg0KQSBhbmQgQiBhcmUgbm90IGFjdHVhbGx5IHJlbGF0ZWQgdG8gb25lIGFub3Ro ZXIgaW4gYW55IHdheSwgYW5kIHRoZSB0cmFuc21pdHRlciBidW5kbGVkIHRoZW0gdG9nZXRoZXIg YmVjYXVzZSB0aGV5IHdlcmUgZ29pbmcgdG8gdGhlIHNhbWUgcmVjZWl2ZXIuPG86cD48L286cD48 L2xpPjwvb2w+DQo8L29sPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjMiIHR5 cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDIgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZSI+DQpUb3AtbGV2ZWwgY2xhaW0g c2VtYW50aWNzIGJlY29tZSBoYXJkZXIgdG8gZGVmaW5lLCBhcyBkaWZmZXJlbnQgcHJvZmlsZXMg bWF5IHdhbnQgdG8gdXNlIHRoZSBzYW1lIGNsYWltcyBpbiBkaWZmZXJlbnQgd2F5cy48bzpwPjwv bzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDIgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZSI+DQpFdmVudCBhdXRoZW50aWNp dHkgY2Fubm90IGJlIHZlcmlmaWVkIHdpdGhvdXQgaGF2aW5nIHRoZSBlbnRpcmUgU0VULiBUaGlz IGZvcmNlcyByZWNlaXZlcnMgdG8gZXhwb3NlIGRvd25zdHJlYW0gc3lzdGVtcyB0byBtb3JlIGlu Zm9ybWF0aW9uIG5lY2Vzc2FyeSwgaWYgdGhvc2Ugc3lzdGVtcyBuZWVkIHRvIGJlIGFibGUgdG8g dmVyaWZ5IGF1dGhlbnRpY2l0eS48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNr bWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW1hem9u IOKAkyBJZGVudGl0eSBTZXJ2aWNlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5Gcm9tOjxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1Njgz MzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+TWlrZSBKb25lcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8 c3BhbiBjbGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4 MzQwMjkzNzc4MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5X ZWRuZXNkYXksIE5vdmVtYmVyIDEsIDIwMTcgYXQgMTE6MjEgQU08YnI+DQo8Yj5Ubzo8c3BhbiBj bGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkz Nzc4MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5EaWNrIEhh cmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PHNwYW4gY2xhc3M9 Im0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1 NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+WWFyb24gU2hlZmZl ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7LCAmcXVvdDtSaWNoYXJkIEJhY2ttYW4s IEFubmFiZWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20i IHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDssDQogSUQgRXZlbnRz IE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7UGhpbCBIdW50IChJ RE0pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 c3BhbiBjbGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4 MzQwMjkzNzc4MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5S RTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGNvbXBsZXRlbHkg YWdyZWUgb24gbW92aW5nIGNvbXBsZXhpdHkgdG8gdGhlIGlzc3VlciBvdmVyIHRoZSByZWNpcGll bnQuJm5ic3A7IEluIG15IHZpZXcsIGl04oCZcyBtb3JlIGNvbXBsZXggZm9yIHJlY2lwaWVudHMg dG8gaGF2ZSB0byBjb3JyZWxhdGUgYW5kIHByb2Nlc3MgYSBzZXF1ZW5jZSBvZiBtdWx0aXBsZSBT RVRzIHByb3ZpZGluZw0KIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQs IGFuZCB2YWxpZGF0ZSBOIHNpZ25hdHVyZXMsIHRoYW4gdG8gcmVjZWl2ZSBvbmUgU0VUIHdpdGgg YWxsIHRoZSBhc3BlY3RzIG9mIHRoZSBsb2dpY2FsIGV2ZW50IGFzIOKAnGV2ZW50c+KAnSBmaWVs ZHMsIHdpdGggbm8gY29ycmVsYXRpb24gb3ZlciB0aW1lIHRoZW4gcmVxdWlyZWQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PGI+RnJvbTo8L2I+PHNwYW4gY2xhc3M9Im0tMzE1MTQ0NTk1ODQ1 MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5EaWNrIEhhcmR0IFs8YSBocmVmPSJtYWlsdG86ZGlj ay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86ZGljay5oYXJkdEBnbWFp bC5jb208L2E+XTxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1 NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9Im0tMzE1MTQ0NTk1ODQ1MTAyOTMx OG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWRuZXNkYXksIE5vdmVtYmVyIDEsIDIwMTcgOTozOSBBTTxi cj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5 NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPk1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4 bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPllhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJv bmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208 L2E+Jmd0OzsgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpy aWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwv YT4mZ3Q7Ow0KIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1l dmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDs7 IFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1 NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+UmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNF VD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPllvdXIgY29tbWVudHMgaGlnaGxpZ2h0IGEgY291cGxlIG9mIHBvaW50czo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4xKSBUaGUgZXhhbXBsZSBpcyBob3cgdG8gaGF2ZSBhIHByZWRlZmluZWQg ZXh0ZW5zaW9uIHBvaW50IGZvciBleHRlbnNpb25zIG9mIGEgc3BlY2lmaWMgZXZlbnQsIGl0IGlz IG5vdCBob3cgdG8gYWRkIGFub3RoZXIgZXZlbnQuIE15c2VsZiwgSSB0aGluayB0aGlzIGlzIG92 ZXJseSBjb21wbGljYXRlZC4gRXZlbnRzIHNob3VsZCBiZSBjb21wYXJhdGl2ZWx5IHN0YXRpYywN CiBhbmQgYXMgd2l0aCBtYW55IG90aGVyIEpTT04gZm9ybWF0cywgdGhlIHJlY2VpdmVyIHNob3Vs ZCBpZ25vcmUgcHJvcGVydGllcyBpdCBkb2VzIG5vdCB1bmRlcnN0YW5kLCB3aGljaCBsZXQncyBu ZXcgcHJvcGVydGllcyBiZSBpbnRyb2R1Y2VkIGFzIGV4dGVuc2lvbnMuIFRoZXJlIHNob3VsZCBu b3QgYmUgYW55IGNvbmZsaWN0IGFzIGV4dGVuc2lvbnMgc2hvdWxkIG9ubHkgYmUgZG9uZSBieSB0 aGUgcHJvZmlsZSB0aGF0IGNyZWF0ZWQgdGhlIGV2ZW50DQogZm9ybWF0IHRvIHN0YXJ0IG9mZiB3 aXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjIpIEhhdmluZyBhbiBsdmFsdWUgYmUgYSBVUkkgaXMg bXVjaCBoYXJkZXIgdG8gY29kZSBhZ2FpbnN0LiBJJ20gbm90IHN1cmUgd2h5IE1hcml1cyBoYWQg dGhhdCBpbiBoaXMgZXhhbXBsZS4gUGVyIHRoZSBldmVudCwgdGhlIHR5cGUgb2YgdGhlIGV2ZW50 IGlzIHdlbGwgZGVmaW5lZCB3aXRoJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZjtjb2xvcjojNTAwMDUwIj4mcXVvdDtldmVudF90eXBlJnF1b3Q7OiAmcXVvdDs8L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly9leGFt cGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQ8L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWY7Y29sb3I6IzUwMDA1MCI+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+MykgVGhpcyB0aHJlYWQgaXMgYWJvdXQgcmVhc29ucyBmb3IgbXVsdGlwbGUgZXZlbnRzIHRv IGJlIGNvbnRhaW5lZCBpbiBvbmUgc2V0LiBZb3VyIG1lbnRpb24gb2YgYW4gaXNzdWVyIG5vdCB3 YW50aW5nIHRvIHNpZ24gc2VwYXJhdGUgZXZlbnRzIGFzIGEgcmVhc29uIHRvIGFsbG93IG11bHRp cGxlIGV2ZW50cy4gSSB0aGluayB3ZSBoYXZlIGRlY2lkZWQgdGhhdCBnaXZlbg0KIGEgcHJlZmVy ZW5jZSwgd2Ugd2lsbCBwdXNoIGVmZm9ydCB0byB0aGUgdHJhbnNtaXR0ZXIgb3ZlciB0aGUgcmVj ZWl2ZXIgYXMgaW4gbWFueSB1c2UgY2FzZXMgdGhlcmUgYXJlIG1hbnkgbW9yZSByZWNlaXZlcnMu IEdpdmVuIHRoYXQsIGl0IGlzIG1vcmUgY29tcGxleCBmb3IgYSByZWNlaXZlciB0byBoYXZlIGRp ZmZlcmVudCB3YXlzIG9mIG1hbmFnaW5nIHRoZSByZWNlaXB0IG9mIG11bHRpcGxlIGV2ZW50cyBh cyBub3QgYWxsIGlzc3VlcnMgd2lsbA0KIGJ1bmRsZSB0aGUgZXZlbnRzLCBzbyBpdCBpcyBzaW1w bGVyIHRvIGhhdmUgb25seSBvbmUgZXZlbnQgcGVyIFNFVC4gSW5jbHVkaW5nIHRoZSBzZXBhcmF0 ZSBldmVudHMgd2l0aCBhIFVSSSBhcyBhbiBsdmFsdWUgaXMgY2hhbGxlbmdpbmcgdG8gaW1wbGVt ZW50LCBzcGVha2luZyBmcm9tIGV4cGVyaWVuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5PbiBUdWUs IE9jdCAzMSwgMjAxNyBhdCAxMTowNSBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPk1hcml1c+KAmSBwcm9wb3NlZCBzeW50YXgsIHBhc3RlZCBpbiBiZWxvdywgaGFzIGV4 YWN0bHkgdGhpcyBjaGFyYWN0ZXJpc3RpYy4mbmJzcDsgVGhlIHdheSBJIHNlZSBpdCwgaGlzIHBy b3Bvc2FsIGVzc2VudGlhbGx5IGhhcyBhIHByaW1hcnkgcGFzc3dvcmRSZXNldCBldmVudCBhbmQg YSBzZWNvbmRhcnkgcGFzc3dvcmRSZXNldEV4dA0KIGRhdGEgc3RydWN0dXJlLCB3aGljaCBjb3Vs ZCBoYXZlIGJlZW4gc2ltcGx5IGFub3RoZXIgZXZlbnQgdmFsdWUgaW4gdGhlIGN1cnJlbnQgZHJh ZnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPlRoaXMgYnJlYWtpbmcgY2hhbmdlIG1ha2VzIHRoZSBkYXRhIHN0cnVjdHVyZXMgbW9y ZSBjb21wbGljYXRlZCAtIG5vdCBsZXNzLiZuYnNwOyBBbmQgaXQgbWFrZXMgdGhpbmdzIHRoYXQg dXNlZCB0byBiZSBwb3NzaWJsZSBpbXBvc3NpYmxlLCByZWR1Y2luZyBmbGV4aWJpbGl0eSB0byB0 aG9zZSB3aG8gd291bGQgdXNlIHRoZSBzcGVjLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGVzZSBzZWVtIGxpa2UgYmFkIHRyYWRl b2ZmcyB0byBtZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij57PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmcXVv dDtqdGkmcXVvdDs6ICZxdW90OzNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwJnF1b3Q7 LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7 aWF0JnF1b3Q7OiAxNDU4NDk2MDI1LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmIj4mbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3Nj aW0uZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPC9zcGFuPjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmcXVvdDthdWQmcXVvdDs6IFs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAm cXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTVi YmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0 PC9zcGFuPjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29t L0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0 NTE2YjFkMDg2NDFkNzY3NmVlNzwvc3Bhbj48L2E+JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDtdLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7JnF1b3Q7ZXZlbnRfdHlwZSZxdW90 OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3Jk UmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRw czovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwvc3Bhbj48L2E+JnF1 b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5i c3A7JnF1b3Q7ZXZlbnQmcXVvdDs6IHsmbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZx dW90O2lkJnF1b3Q7OiZxdW90OzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkmcXVvdDssPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmcXVvdDtleHRlbnNpb25zJnF1b3Q7OiB7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bh c3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwvc3Bhbj48 L2E+4oCdOg0KIHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7cmVzZXRB dHRlbXB0cyZxdW90Ozo1LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO308L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmIj59PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPkluIHBhcnRpY3VsYXIsIGl0IG1ha2VzIGl0IGltcG9zc2libGUgdG8gc2ln biBtdWx0aXBsZSByZWxhdGVkIGV2ZW50cyBzaGFyaW5nIGEgY29tbW9uIGNsYWltcyBzY2hlbWEg d2l0aCBhIHNpbmdsZSBzaWduYXR1cmUgYnkgdGhlIGlzc3Vlci4mbmJzcDsgSXQgZm9yY2VzIHRo ZSBpc3N1ZXIgdG8gZG8gdGhlIGV4dHJhIHdvcmsNCiBvZiBzaWduaW5nIGVhY2ggb2YgdGhlIHJl bGF0ZWQgZXZlbnRzIChvciBmYWNldHMgb2YgdGhlIHNhbWUgbG9naWNhbCBldmVudCkgaW5kaXZp ZHVhbGx5IGFuZCBmb3JjZXMgdGhlIHJlY2lwaWVudHMgdG8gZG8gdGhlIGV4dHJhIHdvcmsgb2Yg Y2hlY2tpbmcgYWxsIHRob3NlIHVubmVjZXNzYXJ5IHNpZ25hdHVyZXMuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPk5vdCBldmVyeSBw cm9maWxlIHdpbGwgZXZlciBoYXZlIG11bHRpcGxlIGtleXMgaW4gdGhlIOKAnGV2ZW50c+KAnSBz ZXQgYnV0IHRoZXJl4oCZcyBhYnNvbHV0ZWx5IG5vIHJlYXNvbiB0byBwcmVjbHVkZSBpdC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj5Gcm9tOjwvYj48c3BhbiBjbGFzcz0ibS0zMTUxNDQ1 OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MGFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPklkLWV2ZW50IFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5d PHNwYW4gY2xhc3M9Im0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2 ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5P bg0KIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0 Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9iPkRpY2sgSGFyZHQ8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0ibS0z MTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4 MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIE9jdG9iZXIgMzEs IDIwMTcgOTo1MiBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0ibS0zMTUxNDQ1OTU4NDUx MDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MGFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9Im0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2 OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5ZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+eWFy b25mLmlldGZAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7OyBSaWNoYXJkIEJhY2ttYW4sDQogQW5u YWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5jb208L3Nw YW4+PC9hPiZndDs7IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzpp ZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7Ow0KIFBoaWwgSHVudCAoSURNKSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9h PiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxicj4NCjxiPlN1YmplY3Q6 PC9iPjxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAw NG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ UmU6IFtJZC1ldmVudF0gVXNlIGNhc2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+UGxlYXNlIGRpcmVjdCBtZSB0byBhIHByb3Bvc2FsIHRo YXQgaGFzIGEgJnF1b3Q7cHJpbWFyeSZxdW90OyBhbmQgJnF1b3Q7c2Vjb25kYXJ5JnF1b3Q7IGV2 ZW50cy4gSSBhZ3JlZSB0aGF0IGlzIHVuZGVzaXJhYmxlLiBJIHdvdWxkIGFsc28gZW5jb3VyYWdl IHRvIGVuZ2FnZSBpbiB0aGUgZGlzY3Vzc2lvbnMgc28gdGhhdCB3ZSBjYW4gZHJpdmUgY2xhcml0 eSBhbmQgc2ltcGxpY2l0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SSB0aGluayB0aGUgcHJvcG9zYWwgaXMgdGhh dCB0aGVyZSBpcyBvbmUgZXZlbnQgcGVyIFNFVC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JIHRoaW5r IGhhdmluZyBtb3JlIHRoYW4gb25lIGV2ZW50IHBlciBTRVQgYWRkcyBjb21wbGV4aXR5IGFzIGEg cmVjZWl2ZXIgbXVzdCBkZWFsIHdpdGggcmVjZWl2aW5nIGNvcnJlbGF0ZWQgZXZlbnRzIGluIG9u ZSBTRVQgYXMgd2VsbCBhcyBjb3JyZWxhdGVkIGV2ZW50cyBpbiB0aGUgc2FtZSBTRVQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+L0RpY2s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5PbiBUdWUsIE9jdCAzMSwg MjAxNyBhdCA5OjQyIFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSBo ZWFyIHlvdSBvbiB0aGUgZmFjdCB0aGF0IGRpZmZlcmVudCBwZW9wbGUgaGF2ZSBqb2luZWQgdGhl IGVmZm9ydCBhdCBkaWZmZXJlbnQgdGltZXMuJm5ic3A7IFRoYXTigJlzIGEgbm9ybWFsIHByb2Nl c3MgYXMgYW4gZWZmb3J0IGJ1aWxkcyBtb21lbnR1bS4mbmJzcDsgSSBnZXQgdGhhdCBub3QgZXZl cnlvbmUgd2FzIHRoZXJlIHdoZW4NCiBwcmV2aW91cyBjb25zZW5zdXMgY2FsbHMgd2VyZSB0YWtl bi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+SSBzaG91bGQgbm90ZSB0aGF0IEkgaGF2ZSBzcGVjaWZpYyB0ZWNobmljYWwgb2JqZWN0 aW9ucyB0byB0aGUgc3BlY2lmaWMgcHJvcG9zZWQgY2hhbmdlcyBiZWluZyBkaXNjdXNzZWQgYXMg d2VsbC4mbmJzcDsgQ3VycmVudGx5IGFsbCBldmVudHMgaW4gdGhlIHNldCBoYXZlIHRoZSBzYW1l IHN5bnRheC4mbmJzcDsgVGhlIHByb3Bvc2FscywNCiBhcyBJIHVuZGVyc3RhbmQgdGhlbSwgcmV2 ZXJ0IHVzIHRvIGEgc3RhdGUgd2hlcmUgdGhlcmXigJlzIGEg4oCccHJpbWFyeeKAnSBhbmQg4oCc c2Vjb25kYXJ54oCdIGV2ZW50cywgd2l0aCBkaWZmZXJlbnQgc3ludGF4IGZvciB0aGUgdHdvIGNs YXNzZXMuJm5ic3A7IFRoYXTigJlzIG5lZWRsZXNzbHkgbW9yZSBjb21wbGljYXRlZCwgYWRkaW5n IG5vIGFjdHVhbCB2YWx1ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj5Gcm9tOjwvYj48c3Bh biBjbGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQw MjkzNzc4MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkRpY2sgSGFy ZHQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwv c3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1 NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9Im0tMzE1MTQ0NTk1ODQ1MTAyOTMx OG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBPY3RvYmVyIDMxLCAyMDE3IDk6MzcgUE08YnI+ DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9Im0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2 OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5NaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxz cGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01Njgz NDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UGhpbCBI dW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNv bTwvc3Bhbj48L2E+Jmd0OzsgWWFyb24gU2hlZmZlcg0KICZsdDs8YSBocmVmPSJtYWlsdG86eWFy b25mLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+eWFyb25mLmlldGZAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7OyBSaWNoYXJkIEJhY2tt YW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yaWNoYW5uYUBhbWF6b24u Y29tPC9zcGFuPjwvYT4mZ3Q7Ow0KIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9 Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0i bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2 MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbSWQtZXZlbnRdIFVz ZSBjYXNlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIHBlciBTRVQ/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPk1pa2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+QXMgeW91IHdlbGwga25vdywgbWFueSBwZW9wbGUgaW4g YSBXRyBkb24ndCBsb29rIGNsb3NlbHkgYXQgYSBzcGVjaWZpY2F0aW9uIHVudGlsIGxhc3QgY2Fs bCBpcyBtYWRlLiBBZGRpdGlvbmFsbHksIHdlIGFyZSBjb21pbmcgdXAgb24gb25seSB0aGUgM3Jk IFdHIG1lZXRpbmcuIFRoZSBXRyBoYXMgbm90IGV4aXN0ZWQgZm9yIHZlcnkgbG9uZy4gV2hpbGUg c29tZSBvZg0KIHRoZSBwYXJ0aWNpcGFudHMgaGF2ZSBiZWVuIHdvcmtpbmcgb24gdGhpcyBmb3Ig YSB3aGlsZSwgbWFueSBoYXZlIG5vdCwgYW5kIHdlIGFyZSBsb29raW5nIGZvciBjb25zZW5zdXMg YWNyb3NzIHRoZSBXRy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5TaW5jZSBTZWNFdmVudCBpcyBhIGZy YW1ld29yayB0aGF0IHdlIGV4cGVjdCB0byBiZSBwcm9maWxlZCwgSSBmZWVsIGl0IGlzIGltcG9y dGFudCB0byBlbnN1cmUgdGhhdCBTZWNFdmVudCBzcGVjaWZpY2F0aW9ucyBhcmUgZWFzeSBmb3Ig YSB2YXJpZXR5IG9mIHByb2ZpbGVzIHRvIGFkb3B0LCBhbmQgdGhhdCB0aGUgc2VtYW50aWNzIG1h a2Ugc2Vuc2UuIEkgYWxzbyB0aGluaw0KIHRoYXQgcHJvcGVydGllcyB0aGF0IGFyZSBzcGVjaWZp YyB0byBhIHByb2ZpbGUgc2hvdWxkIGJlIGxlZnQgdG8gdGhhdCBwcm9maWxlIGFuZCBub3QgYmUg aW5jbHVkZWQgaW4gU2VjRXZlbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+U2luY2UgdGhpcyBpcyBh IGZyYW1ld29yaywgaXQgaXMgZXhwZWN0ZWQgdGhhdCBhcyBkaWZmZXJlbnQgZ3JvdXBzIHByb2Zp bGUgaXQsIHRoZXJlIHdpbGwgYmUgYWRkaXRpb25hbCBmZWVkYmFjay48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj5TcGVjaWZpY2FsbHksIGFzIGEgcGFydGljaXBhbnQgaW4gdGhlIFJJU0MgcHJvZmlsZSBv ZiBTRVQsIGEgbnVtYmVyIG9mIGlzc3VlcyBpbiBTRVQgaGF2ZSBzdXJmYWNlZCBhcyB0aGUgUklT QyBXRyBoYXMgbG9va2VkIGF0IGhvdyB0byB1c2UgdGhlIFNFVC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij5BcyBmb3IgU0VUIGJlaW5nIHN0YWJsZSBmb3Igb3ZlciBhIHllYXIsIHRoZXJlIGhhdmUgYmVl biBhIG51bWJlciBvZiBjaGFuZ2VzIHRvIFNFVCBzaW5jZSB0aGVuLiBJIGFsc28gZG9uJ3QgdGhp bmsgdGhlcmUgd2FzIGNvbnNlbnN1cy4gQmVmb3JlIHRoZSBXRyB3YXMgZm9ybWVkLCBJIGFuZCBz ZXZlcmFsIG90aGVycyBoYWQgZXhwcmVzc2VkIGNvbmNlcm4gb24gdGhlDQogZGVzaWduIG9mIFNF VCB3aGVuIFBoaWwgcHJlc2VudGVkIGl0IGF0IGFuIElJVyBzZXNzaW9uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPkFzIHRvIHRha2luZyBhbm90aGVyIHllYXIsIEkgYW0gaG9wZWZ1bCB3ZSBjYW4gcmVz b2x2ZSB0aGUgcmVtYWluaW5nIGlzc3VlcyBpbiBTRVQgYW5kIHB1Ymxpc2ggYSBuZXcgZHJhZnQg Zm9yIGxhc3QgY2FsbC4gSSBkbyBub3QgdGhpbmsgd2Ugd2lsbCBuZWVkIHRvIHdhaXQgZm9yIGFu b3RoZXIgV0cgbWVldGluZyB0byBhc2sgZm9yIGxhc3QgY2FsbC4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj5XZSBhbHNvIGhhdmUgYSBudW1iZXIgb2Ygb3RoZXIgZG9jdW1lbnRzIHRoYXQgYXJl IG5vdCBpbiBsYXN0IGNhbGwsIGFuZCB3ZSBkb24ndCBoYXZlIGEgV0cgYWRvcHRlZCBkcmFmdCB5 ZXQgZm9yIG1hbmFnZW1lbnQuIFNvIHRoZXJlIGFyZSBzdGlsbCBhIG51bWJlciBvZiBkb2N1bWVu dHMgdG8gd29yayB0aHJvdWdoIGJlZm9yZSB3ZSBoYXZlIGFsbCB0aGUgYml0cyBmb3INCiBzb21l b25lIHRvIHdvcmsgd2l0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JIGRvIHRoaW5rIHdlIGhhdmUg YmVlbiBtYWtpbmcgZ29vZCBwcm9ncmVzcyBzaW5jZSB0aGUgbGFzdCBJRVRGIG1lZXRpbmcsIGFu ZCBJIGFtIGhvcGVmdWwgd2UgY2FuIGtlZXAgdXAgdGhpcyBtb21lbnR1bSBhbmQgZmluYWxpemUg YWxsIHRoZSBkb2N1bWVudHMgaW4gYSB0aW1lbHkgbWFubmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi Pi9EaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+T24gVHVlLCBPY3QgMzEsIDIwMTcgYXQgMTI6NDggUE0sIE1pa2UgSm9uZXMg Jmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JdOKAmXMgaGFyZCBmb3IgbWUgdG8gZXZlbiBleHBy ZXNzIG15IGxldmVsIG9mIGZydXN0cmF0aW9uIHdpdGggdGhlIHJlY2VudCBhdHRlbXB0cyB0byBv bmNlIGFnYWluIHJlZGVzaWduIHRoZSBTZWNFdmVudCBUb2tlbiBzcGVjLiZuYnNwOyBXZeKAmXZl IGJlZW4gYXQgdGhpcyBmb3IgbXVsdGlwbGUgeWVhcnMgYmVjYXVzZSBwZW9wbGUNCiBrZWVwIHRy eWluZyB0byByZXZpc2l0IGRlY2lzaW9ucyB0aGF0IHdlcmUgbG9uZyBhZ28gbWFkZSBieSBjb25z ZW5zdXMuJm5ic3A7IEl04oCZcyBiZWVuIHN0YWJsZSBmb3Igb3ZlciBhIHllYXIgYW5kIHRoZSBt YWpvcml0eSBvZiBXR0xDIHJlc3BvbmRlbnRzIHNhaWQgc29tZSB2YXJpYW50IG9mIOKAnFdvcmtz IGZvciBtZSDigJMgc2hpcCBpdCHigJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhlcmXigJlzIG5vdCBzdWZmaWNpZW50IGp1c3Rp ZmljYXRpb24gdG8gdHJ5IHRvIHVuZG8gY29uc2Vuc3VzIHBvc2l0aW9ucyB0aGF0IGhhdmUgYmVl biBkZWJhdGVkIGFuZCBhZmZpcm1lZCBvdmVyIGFuZCBvdmVyLiZuYnNwOyBDb3VudGVuYW5jaW5n IHdob2xlc2FsZSBjaGFuZ2VzIGF0IHRoaXMgbGF0ZSBkYXRlIGlzIGNvdW50ZXJwcm9kdWN0aXZl DQogaW4gdGhlIGV4dHJlbWUhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPkl04oCZcyBmYXIgYmV0dGVyIHRoYW4gZ29vZCBlbm91Z2gg YXMtaXMuJm5ic3A7IEluIG15IGV4cGVyaWVuY2UsIGlmIHdlIHN0YXJ0IHJlZGVzaWduaW5nIGl0 LCBpdCB3aWxsIHJlc3VsdCBpbiBhbm90aGVyIHllYXLigJlzIGRlbGF5LiZuYnNwOyBJdCBkb2Vz IHNvbWV0aGluZyBzaW1wbGUgYW5kIHVzZWZ1bC4mbmJzcDsgUGxlYXNlLCBsZXTigJlzIGp1c3QN CiBzaGlwIGl0LCBzbyBwZW9wbGUgY2FuIHJlbHkgb24gaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxhIG5hbWU9Im1fLTMxNTE0NDU5NTg0NTEwMjkzMThfbV83NDc2MzQ2OTQ2OTU2ODMiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj5Gcm9tOjwvYj48c3BhbiBj bGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkz Nzc4MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlBoaWwgSHVudCAo SURNKSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29t PC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9Im0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2 OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5 MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MGFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1vbmRheSwgT2N0b2JlciAzMCwgMjAxNyAyOjQyIFBNPGJy Pg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0 Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+RGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZGljay5oYXJk dEBnbWFpbC5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9Im0t MzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEw ODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5ZYXJvbiBTaGVmZmVyICZsdDs8 YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+eWFyb25mLmlldGZAZ21haWwuY29tPC9zcGFuPjwvYT4m Z3Q7OyBSaWNoYXJkIEJhY2ttYW4sDQogQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmlj aGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPnJpY2hhbm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPiZndDs7IE1pa2UgSm9uZXMgJmx0Ozxh IGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 L3NwYW4+PC9hPiZndDs7DQogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJtLTMx NTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgw YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtJZC1ldmVudF0gVXNlIGNh c2VzIGZvciBtdWx0aXBsZSBldmVudHMgcGVyIFNFVD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPklubGluZS4uLjxicj4NCjxicj4NClBoaWw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPk9uIE9jdCAzMCwgMjAxNywgYXQgMjoyMiBQTSwgRGljayBIYXJkdCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+ZGljay5oYXJkdEBnbWFpbC5jb208L3NwYW4+PC9hPiZndDsN CiB3cm90ZTogPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5IaSBQ aGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPkNvcnJlY3QgbWUgaWYgSSBhbSBtaXN1bmRlcnN0YW5kaW5nLCBidXQg dGhlcmUgaXMgYSBSSVNDIHByb2ZpbGUgZXZlbnQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTt3aGl0ZS1zcGFj ZTpwcmUtd3JhcCI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu NXB0Ij4mcXVvdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVuaWQubmV0X3NlY2V2ZW50X3Jpc2NfZXZlbnQtMkR0 eXBlXy0yNTVDJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdx SXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFM Y0xONEtaTkEmYW1wO209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0Nf dyZhbXA7cz0yNWwwOXNIOFlWNDJ4emdVLUNYU2c4eEg5dHZ5REp6NDB0Q1JqRmFsaGt3JmFtcDtl PSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9zY2hl bWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlLzwvc3Bhbj48L2E+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+YWNjb3VudC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj7igJ08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOzxvOnA+PC9vOnA+PC9w cmU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPmFuZCBhbiBTQ0lNIHByb2ZpbGUgZXZlbnQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTt3aGl0ZS1zcGFjZTpwcmUtd3Jh cCI+JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3Jk UmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRw czovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwvc3Bhbj48L2E+4oCd PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7d2hpdGUtc3Bh Y2U6cHJlLXdyYXAiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkknbSBzdWdn ZXN0aW5nIHRoYXQgdHdvIGRpZmZlcmVudCBldmVudHMgd291bGQgYmUgc2VudC4gRW1iZWRkaW5n IG9uZSBpbiB0aGUgb3RoZXIgZG9lcyBub3QgbWFrZSBzZW5zZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbHQ7cGgmZ3Q7SXQgaXMg YSBoeXBvdGhldGljYWwgZXhhbXBsZS4gSnVzdCBiZWNhdXNlIHlvdSBkaXNhZ3JlZSBvbiB0aGlz IGRvZXMgbm90IG1lYW4gb3RoZXJzIGFyZSBub3QgdmFsaWQuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkkg anVzdCBwaWNrZWQgb3ZlcmxhcHBpbmcgcHJvcG9zYWxzIHRoYXQgaGF2ZSBkaWZmZXJlbnQgbWVh bmluZyAoYnV0IG5vdCB0aGUgc2FtZSkgdG8gaWxsdXN0cmF0ZSB0aGUgZGlmZmVyZW5jZSBmcm9t IGlzc3VpbmcgYSBzaW5nbGUgc2V0IHdpdGggZGlmZmVyZW50IGV2ZW50cy4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPkFzIEkgaGF2ZSBzdGF0ZWQgdGhpcyBpcyB2ZXJ5 IGRpZmZlcmVudCBmcm9tIGFzc2VydGluZyBtdWx0aXBsZSBkaXN0aW5jdCBldmVudHMgaW4gb25l IFNFVC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5BbHNvLCBJIHRoaW5rIGl0IGlzIHNpbXBs ZXIgdG8gaGF2ZSBldmVudF90eXBlIGJlIGF0IHRoZSBzYW1lIGxldmVsIGFzIGV2ZW50PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4mbHQ7 cGgmZ3Q7bWF5IGJlLiBJIHdhcyB3b3JraW5nIGZyb20gQW5uYWJlbGxlJ3MgcHJvcG9zZWQgZm9y bWF0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPns8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7anRpJnF1b3Q7OiAmcXVvdDszZDBj M2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OiAxNDU4NDk2MDI1LDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmcXVvdDtpc3Mm cXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NjaW0uZXhhbXBsZS5j b208L3NwYW4+PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmIj4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiBbPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIu ZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9G ZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0PC9zcGFuPjwvYT4mcXVvdDssPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmcXVvdDs8YSBo cmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3 NmVlNyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8v amh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3PC9zcGFuPjwv YT4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsg Jm5ic3A7XSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsg Jm5ic3A7JnF1b3Q7ZXZlbnRfdHlwZSZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFt cGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFz c3dvcmRSZXNldEV4dDwvc3Bhbj48L2E+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsmcXVvdDtldmVudCZxdW90OzogeyZuYnNwOyZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtpZCZxdW90OzomcXVvdDs0NGY2MTQyZGY5NmJk NmFiNjFlNzUyMWQ5JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtyZXNldEF0dGVtcHRz JnF1b3Q7OjU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZiI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPns8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7anRpJnF1b3Q7OiAmcXVvdDszZDBjM2Nm Nzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OiAxNDU4NDk2MDI1LDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyAmcXVvdDtpc3MmcXVv dDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NjaW0uZXhhbXBsZS5jb208 L3NwYW4+PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij4mbmJzcDsgJnF1b3Q7YXVkJnF1b3Q7OiBbPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhh bXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVk cy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0PC9zcGFuPjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmcXVvdDs8YSBocmVm PSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVl NyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1 Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3PC9zcGFuPjwvYT4m cXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5i c3A7XSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5i c3A7JnF1b3Q7ZXZlbnRfdHlwZSZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9z ZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV9hY2NvdW50LTJEY3JlZGVudGlhbC0yRGNoYW5nZS0y RHJlcXVpcmVkJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdx SXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFM Y0xONEtaTkEmYW1wO209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2bEs2N3lGXzh1OF9xU0Nf dyZhbXA7cz1uUXk5ZXpQUmpER2R2UlRDYWlEdGk0T0hlbEgzREtnVUNUS2pGMkdRLXNvJmFtcDtl PSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9zY2hl bWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL2FjY291bnQtY3JlZGVudGlh bC1jaGFuZ2UtcmVxdWlyZWQ8L3NwYW4+PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7JnF1b3Q7ZXZlbnQmcXVvdDs6IHs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDvigJxzdWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0sPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A74oCcaXNz 4oCdOiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLzwv c3Bhbj48L2E+JnF1b3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPn08L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj5PbiBNb24sIE9jdCAzMCwgMjAxNyBhdCAxMjowOSBQTSwgUGhpbCBI dW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bh bj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+QW5uYWJlbGxlL0Rp Y2ssPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+VGhhbmtzIGZvciB0aGUgY29tbWVudHMuIEkgdGhpbmsg d2UgbmVlZCB0byBleGFtaW5lIHRoZSBjb25zZXF1ZW5jZXMgb2YgdGhlIHByb3Bvc2FsIGluIEpT T04uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj5BcyBJIHN0YXRlZCwgd2hhdCBjYXVzZXMgbW9zdCBvZiB0aGUgaXNz dWUgaXMgdGhlIHByb3Bvc2VkIGV4dGVuc2lvbiBtZWNoYW5pc20gaW4gdGhlIHBheWxvYWQgKHBv c3NpYmx5IHVzaW5nIGV2ZW50cyBpbiBhIHJlY3Vyc2l2ZSB3YXkpLiBEb2VzIGl0IGZvbGxvdyB0 aGUgb2xkIGZvcm1hdCBvciB0aGUgbmV3PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5MZXTigJlzICZuYnNwO2NvbnNp ZGVyIGEgdXNlIGNhc2Ugd2hlcmUgd2UgaGF2ZSBhbiBpZGVudGl0eSBtYW5hZ2VtZW50IHN5c3Rl bSB0aGF0IHVzZXMgU0NJTSwgYnV0IHRoZSBTQ0lNIHN5c3RlbSBpcyBhbHNvIHRoZSB1bmRlcmx5 aW5nIGRhdGEgc3RvcmUgZm9yIENvbm5lY3QuJm5ic3A7IEEgUGFzc3dvcmQgcmVzZXQgbWlnaHQg Z2VuZXJhdGUgdGhlIGZvbGxvd2luZyBldmVudCB3aGljaA0KIGhhcyBhbiBleHRlbnNpb24gKGNv bnZleWluZyByZXNldCBjb3VudCkgQU5EIG92ZXJsYXBwaW5nIHN0YXRlbWVudCBmcm9tIFJJU0Mu Jm5ic3A7IEJPVEggb2Ygd2hpY2ggbWlnaHQgYmUgaW1wb3J0YW50IHRvIGEgc2ltaWxhciByZWNl aXZlciB1c2luZyBTQ0lNIGFuZCBPSURDLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj5U aGUgMDMgc3BlYyBjdXJyZW50bHkgd291bGQgYWxsb3c6PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj57PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDtqdGkmcXVvdDs6ICZxdW90 OzNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwJnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OiAx NDU4NDk2MDI1LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhh bXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0 cHM6Ly9zY2ltLmV4YW1wbGUuY29tPC9zcGFuPjwvYT4mcXVvdDssPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDthdWQmcXVvdDs6IFs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85 OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJj ODc5NTkzYjc3NTQ8L3NwYW4+PC9hPiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0 dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3IiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9qaHViLmV4 YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTc8L3NwYW4+PC9hPiZxdW90 OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsm bmJzcDsgXSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ Jm5ic3A7Jm5ic3A7ICZxdW90O2V2ZW50cyZxdW90OzogezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7 dXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldCZxdW90Ozo8bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHsgJnF1b3Q7aWQmcXVvdDs6JnF1b3Q7NDRmNjE0MmRmOTZiZDZh YjYxZTc1MjFkOSZxdW90O30sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczov L2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dCIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVu dC9wYXNzd29yZFJlc2V0RXh0PC9zcGFuPjwvYT4mcXVvdDs6PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB7ICZxdW90O3Jlc2V0QXR0ZW1wdHMmcXVvdDs6NX0sPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5l dF9zZWNldmVudF9yaXNjX2V2ZW50LTJEdHlwZV8tMjU1QyZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdt YW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NRNk1E MHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmYW1wO3M9MjVsMDlzSDhZVjQyeHpnVS1DWFNnOHhI OXR2eURKejQwdENSakZhbGhrdyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5odHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZl bnQtdHlwZS9cPC9zcGFuPjwvYT48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWNjb3Vu dC1jcmVkZW50aWFsLWNoYW5nZS1yZXF1aXJlZCZxdW90Ozogezwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyDigJxzdWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKA nGlzc+KAnTomcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPjxhIGhy ZWY9Imh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vaWRwLmV4YW1wbGUuY29tLzwvc3Bhbj48L2E+JnF1b3Q7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsgfTwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPn08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkluIHRoZSBhYm92ZSAtIGVhY2ggcGF5bG9hZCBpcyBhIOKA mHBlZXInIGFuZCBpc3N1ZWQgd2l0aG91dCBwcmVmZXJlbmNlIGJ5IHRoZSB0cmFuc21pdHRlci4g VGhlIHJlY2VpdmVyIGNhbiBhc3NpZ24gcHJpb3JpdHkgaW4gaXRzIG93biBjb250ZXh0IGlmIHRo YXQgbWF0dGVycy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cHJlIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0K PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgbmV3IHByb3Bvc2FsOjwvc3Bh bj48L2I+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj57PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPiZuYnNwOyAmcXVvdDtqdGkmcXVvdDs6ICZxdW90OzNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZi MWJkNGU3ZDMwJnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj4mbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OiAxNDU4NDk2MDI1LDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsgJnF1b3Q7aXNzJnF1b3Q7 OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPC9z cGFuPjwvYT4mcXVvdDssPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPiZuYnNwOyAmcXVvdDthdWQmcXVvdDs6IFs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9 Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0 IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9qaHVi LmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQ8L3NwYW4+PC9hPiZx dW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9G ZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUx NmIxZDA4NjQxZDc2NzZlZTc8L3NwYW4+PC9hPiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsgXSw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7ICZxdW90O2V2ZW50 JnF1b3Q7OiB7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxldmVudF90eXBl4oCdOiZxdW90O3VybjppZXRm OnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3JkUmVzZXTigJ0sPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVv dDtpZCZxdW90OzrigJ00NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ54oCdLDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsg4oCcZXZlbnRz4oCdOns8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0mZ3Q7bm90ZSDigKZpcyB0aGlzIHRo ZSBvbGQgb3IgbmV3IHN0cnVjdHVyZT8gJmx0Oy08bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJl c2V0RXh0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6 Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeHQ8L3NwYW4+PC9hPiZxdW90 Ozo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHsgJnF1b3Q7cmVzZXRB dHRlbXB0cyZxdW90Ozo1fSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2NoZW1hcy5vcGVuaWQubmV0X3NlY2V2ZW50 X3Jpc2NfZXZlbnQtMkR0eXBlXy0yNTVDJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBj dHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1SUVM2 bEs2N3lGXzh1OF9xU0NfdyZhbXA7cz0yNWwwOXNIOFlWNDJ4emdVLUNYU2c4eEg5dHZ5REp6NDB0 Q1JqRmFsaGt3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPmh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL1w8 L3NwYW4+PC9hPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDthY2Nv dW50LWNyZWRlbnRpYWwtY2hhbmdlLXJlcXVpcmVkJnF1b3Q7OiB7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IOKAnHN1YuKAnTrigJ03Mzc1NjI2QTY1NjM3NOKAnSw8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg 4oCcaXNz4oCdOiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+PGEg aHJlZj0iaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vPC9zcGFuPjwvYT4mcXVv dDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IH08 L3NwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+fTwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gdGhlIGFi b3ZlLCBzdWItZXZlbnRzIG9yIGV4dGVuc2lvbnMgaGF2ZSBhIGRpZmZlcmVudCBmb3JtYXQuIFRo ZSBzYW1lIGNvbXBsYWludCBhYm91dCB0aGUgb3JpZ2luYWwgc3RhbmRzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Kk9SKiAoaWYgdGhl IHJlY2VpdmVyIGNhcmVzIGFib3V0IFJJU0MgbW9yZSkuJm5ic3A7IE5vdGUgdGhhdCB0aGlzIGxl YWRzIHRvIGEgdHJpcGxlIG5lc3RlZCBzdHJ1Y3R1cmUuPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPns8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7ICZxdW90O2p0aSZxdW90OzogJnF1b3Q7 M2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAmcXVvdDssPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmcXVvdDtpYXQmcXVvdDs6IDE0 NTg0OTYwMjUsPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PiZuYnNwOyAmcXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFt cGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRw czovL3NjaW0uZXhhbXBsZS5jb208L3NwYW4+PC9hPiZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7ICZxdW90O2F1ZCZxdW90OzogWzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJz cDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4 ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5odHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4 Nzk1OTNiNzc1NDwvc3Bhbj48L2E+JnF1b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0 cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2podWIuZXhh bXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNzwvc3Bhbj48L2E+JnF1b3Q7 PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZu YnNwOyBdLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m bmJzcDsmbmJzcDsgJnF1b3Q7ZXZlbnQmcXVvdDs6IHs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnGV2ZW50 X3R5cGXigJ06PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPiZxdW90OzxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFz Lm9wZW5pZC5uZXRfc2VjZXZlbnRfcmlzY19ldmVudC0yRHR5cGVfLTI1NUMmYW1wO2Q9RHdNRmFR JmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9 bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1peVZuclpt cjlfdUdDUTZNRDB6RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JmFtcDtzPTI1bDA5c0g4WVY0Mnh6 Z1UtQ1hTZzh4SDl0dnlESno0MHRDUmpGYWxoa3cmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL3NjaGVtYXMub3BlbmlkLm5ldC9zZWNldmVu dC9yaXNjL2V2ZW50LXR5cGUvXDwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDthY2NvdW50LWNyZWRlbnRpYWwtY2hhbmdlLXJlcXVpcmVkPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnHN1YuKAnTrigJ03Mzc1NjI2QTY1NjM3 NOKAnSw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDvigJxpc3PigJ06JnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij48YSBocmVmPSJodHRwczovL2lkcC5leGFtcGxlLmNvbS8lRTIlODAlOUMiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2lkcC5leGFtcGxlLmNv bS/igJw8L3NwYW4+PC9hPiw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXZlbnRz4oCdOns8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7 dXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldCZxdW90Ozo8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgeyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90O2lkJnF1b3Q7OuKAnTQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDnigJ0s PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxldmVudHPi gJ06ezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50 L3Bhc3N3b3JkUmVzZXRFeHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5odHRwczovL2V4YW1wbGUuY29tL3NjaW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dDwvc3Bh bj48L2E+JnF1b3Q7OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeyAmcXVvdDtyZXNldEF0dGVtcHRzJnF1 b3Q7OjV9LDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ij4mbmJzcDsgPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTwvc3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt9PG86cD48 L286cD48L3ByZT4NCjwvZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDt9PC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8 cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkluIHRoZSBhYm92ZSwgdGhlIGV4dGVuc2lv biBpcyBwbGFjZWQgaW5zaWRlIHRoZSBldmVudCBpdCBleHRlbmRzLiBJdCBmb2xsb3dzIHRoZSBv bGQgZm9ybWF0IChvciBzaG91bGQgaXQgZm9sbG93IHRoZSBuZXc/KTwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4qT1IqIEZvbGxvd2luZyB0aGUgdG9wIGxheWVyIHBhdHRlcm4gb2Ygc2luZ3VsYXIgZXZlbnQm bmJzcDsgTm90ZSB0aGF0IHRoaXMgbGVhZHMgdG8gYSB0cmlwbGUgbmVzdGVkIHN0cnVjdHVyZS48 L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ ezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsg JnF1b3Q7anRpJnF1b3Q7OiAmcXVvdDszZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCZx dW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5i c3A7ICZxdW90O2lhdCZxdW90OzogMTQ1ODQ5NjAyNSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7ICZxdW90O2lzcyZxdW90OzogJnF1b3Q7PGEg aHJlZj0iaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbTwvc3Bhbj48L2E+JnF1 b3Q7LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDsgJnF1b3Q7YXVkJnF1b3Q7OiBbPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2po dWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNv bS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0PC9zcGFuPjwvYT4mcXVvdDssPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZu YnNwOyAmcXVvdDs8YSBocmVmPSJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0 NTE2YjFkMDg2NDFkNzY3NmVlNyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3 Njc2ZWU3PC9zcGFuPjwvYT4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7IF0sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyAmcXVvdDtldmVudCZxdW90Ozogezxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsg4oCcZXZlbnRfdHlwZeKAnTo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEz LjVwdCI+JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9zZWNldmVudF9yaXNjX2V2ZW50LTJE dHlwZV8tMjU1QyZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3 cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFh TGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVND X3cmYW1wO3M9MjVsMDlzSDhZVjQyeHpnVS1DWFNnOHhIOXR2eURKejQwdENSakZhbGhrdyZhbXA7 ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vc2No ZW1hcy5vcGVuaWQubmV0L3NlY2V2ZW50L3Jpc2MvZXZlbnQtdHlwZS9cPC9zcGFuPjwvYT48L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNw OyAmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw O2FjY291bnQtY3JlZGVudGlhbC1jaGFuZ2UtcmVxdWlyZWQ8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+4oCdLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyDigJxzdWLigJ064oCdNzM3NTYyNkE2NTYzNzTigJ0sPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcaXNz4oCdOiZxdW90OzxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2lkcC5leGFtcGxlLmNvbS8lRTIlODAlOUMiIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2lkcC5leGFt cGxlLmNvbS/igJw8L3NwYW4+PC9hPiw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcZXZlbnTigJ06ezwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDi gJxldmVudF90eXBl4oCdOiZxdW90O3VybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3Jk UmVzZXTigJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4mcXVvdDtpZCZxdW90OzrigJ00NGY2MTQy ZGY5NmJkNmFiNjFlNzUyMWQ54oCdLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg 4oCcZXZlbnTigJ06ezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsg4oCcZXZlbnRfdHlwZeKAnTomcXVvdDs8YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL3Nj aW0vZXZlbnQvcGFzc3dvcmRSZXNldEV4dCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmh0dHBzOi8vZXhhbXBsZS5jb20vc2NpbS9ldmVudC9wYXNzd29yZFJlc2V0 RXh0PC9zcGFuPjwvYT7igJ0sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmcXVvdDtyZXNldEF0dGVtcHRzJnF1b3Q7OjU8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdCI+IDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO308bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwO308L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij59PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGZvcm1hdCBmb2xsb3dzIHRoZSBwcm9wb3NlZCBz aW5ndWxhciBldmVudCBmb3JtYXQgcmVjdXJzaXZlbHkgYW5kIGlzIDMgbGF5ZXJzIGRlZXAuIE5v dGUgdGhhdCB0aGUgcGFyc2VyIGhhcyB0byBjb250aW51ZSB0byBzZWFyY2ggdGhlIGRvY3VtZW50 IGZvciB0aGluZ3MgdGhhdCBhcmVu4oCZdCB0aGVyZSBhcyBpdCBoYXMgdG8gc3RvcCB3aGVuIG5v IOKAnGV2ZW504oCdIGF0dHJpYnV0ZSBpcyBmb3VuZCByYXRoZXIgdGhhbiBpdGVyYXRlIG92ZXIg YW4gYXJyYXkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlBoaWw8 YnI+DQo8YnI+DQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFy Y2hpdGVjdDxicj4NCkBpbmRlcGVuZGVudGlkPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNv bSZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVl YXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5B JmFtcDttPWl5Vm5yWm1yOV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmYW1wO3M9 OXNZaGdwRXpiN3hQbFFGbUNDWE5tSG82ZlFOOUlCdS1TSEphbWdfQjRIcyZhbXA7ZT0iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53d3cuaW5kZXBlbmRlbnRpZC5j b208L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFj bGUuY29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9uIE9jdCAzMCwg MjAxNywgYXQgODo1NyBBTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9 Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+cmljaGFubmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJjb2xvcjojQzM0NkUwIj5SZXBsaWVzIGlubGluZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUg UmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZiI+SWRlbnRpdHkgU2VydmljZXM8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+RnJvbTo8c3BhbiBjbGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5 NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1 NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5QaGlsDQogSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNs YXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3 NzgxNTYxMDgwbS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3 NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvYj5TdW5kYXksIE9jdG9iZXIgMjksIDIwMTcgYXQgNToyNSBQTTxicj4N CjxiPlRvOjxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1Njgz MzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwbS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYx NDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5EaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJt YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxi PkNjOjxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAw NG01NjgzNDAyOTM3NzgxNTYxMDgwbS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEw MjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5ZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJt YWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+eWFyb25mLmlldGZAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7LA0KIE1p a2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDssICZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5u YWJlbGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5j b208L3NwYW4+PC9hPiZndDssDQogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OjxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAw NG01NjgzNDAyOTM3NzgxNTYxMDgwbS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEw MjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SZTogW0lkLWV2ZW50XSBVc2UgY2FzZXMgZm9y IG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JIGhvcGUgdGhpcyBhbnN3ZXJzIHlvdXIgcXVlc3Rp b24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+TXkg 4oCcbWF54oCdIHdhcyBiZWNhdXNlIEkgY2Fu4oCZdCBzZWUgYSByZWFzb24gd2h5IG5vdC4gVGhl IHF1ZXN0aW9uIHNob3VsZCBiZSwgd2hhdCBpcyB0aGUganVzdGlmaWNhdGlvbiB0byBtYWtlIOKA nGV2ZW50c+KAnSBzaW5ndWxhcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iY29sb3I6I0MzNDZFMCI+W3JpY2hhbm5hXVRoZSBzaW5ndWxhciDigJxldmVu dOKAnSBjbGFpbSBoYXMgY2xlYXJlciBzZW1hbnRpY3MgYW5kIGlzIGVhc2llciB0byBwcm9jZXNz LiBXZSBzaG91bGQgb3B0IGZvciBlYXNpZXIgc29sdXRpb25zIHVubGVzcyB0aGVyZSBhcmUgdXNl IGNhc2VzIHRoYXQgcmVxdWlyZSBtb3JlIGNvbXBsZXhpdHkuWy9yaWNoYW5uYV08L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+VGhlcmUgYXJl IG1hbnkgcmVhc29ucyBmb3IgbXVsdGlwbGUgZXZlbnRzIGluIGEgU0VULiZuYnNwOyBTb21lIGFy ZSBnb29kLCBzb21lIG5vdCBzbyBnb29kLiBTb21lIG9mIHRoZSByZWFzb25zLi4uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+MS4mbmJzcDsgTXVsdGlw bGUgZXZlbnQgcGF5bG9hZHMgZXhwcmVzc2luZyBzdGF0ZW1lbnRzIGFib3V0IGxhcmdlbHkgdGhl ICpzYW1lKnRoaW5nLiBGb3IgZXhhbXBsZSwgU0NJTSBwYXNzd29yZCByZXNldCBBTkQgUklTQyBw YXNzd29yZCByZXNldC4mbmJzcDsgQSBSSVNDIEV2ZW50IGFuZCBhbiBPcGVuQmFua2luZyBFdmVu dC4gSXMgb25lIGEgY29tcGxlbWVudCB0byB0aGUgb3RoZXI/Jm5ic3A7DQogRG8gdGhleSBvdmVy bGFwIG9yIGFyZSB0aGV5IGRpc3RpbmN0PyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6I0MzNDZFMCI+W3JpY2hhbm5hXUNvcHkvcGFz dGVkIGZyb20gbXkgZWFybGllciBlbWFpbDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPldoeSBpcyBpdCBuZWNlc3Nh cnkgb3IgYXBwcm9wcmlhdGUgdG8gaW5jbHVkZSB0aGVzZSBldmVudHMgaW4gdGhlIHNhbWUgU0VU PyBUaGV5IGFyZSBsaWtlbHkgYmVpbmcgZ2VuZXJhdGVkIGJ5IGRpZmZlcmVudCBzeXN0ZW1zIGF0 IGRpZmZlcmVudCB0aW1lcyBvbiB0aGUgdHJhbnNtaXR0ZXLigJlzIHNpZGUsIGNvbnN1bWVkDQog YnkgZGlmZmVyZW50IHN5c3RlbXMgb24gdGhlIHJlY2VpdmVy4oCZcyBzaWRlLCBhbmQgcG9zc2li bHkgYmVpbmcgdHJhbnNtaXR0ZWQgb3ZlciBkaWZmZXJlbnQgZXZlbnQgc3RyZWFtcy4gSSBrbm93 IHRoZSBsYXR0ZXIgd291bGQgYmUgdGhlIGNhc2UgZm9yIHVzLCBhcyBhIHJlY2VpdmVyLiBFdmVu IGlmIGl04oCZcyBub3QsIGlzIGl0IGJ1cmRlbnNvbWUgdG8gc2VuZCB0aGVzZSBldmVudHMgc2Vw YXJhdGVseT8gV2hhdCB2YWx1ZSBpcyBnYWluZWQgaW4NCiBjb21iaW5pbmcgdGhlbT88L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiND MzQ2RTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iY29sb3I6I0MzNDZFMCI+QWRkaXRpb25hbGx5LCBzaW5jZSB0aGUgc2lnbmF0 dXJlIGlzIG92ZXIgdGhlIFNFVCBhbmQgbm90IHRoZSBldmVudCBvYmplY3RzLCBSZWNlaXZlcnMg aW5kZXBlbmRlbnRseSByb3V0ZSBzZXBhcmF0ZSBldmVudHMgZnJvbSBhIHNpbmdsZSB0b2tlbiB3 aXRob3V0IGVpdGhlciBsb3NpbmcgdGhlIGFiaWxpdHkgdG8gdmVyaWZ5DQogdGhlIGF1dGhlbnRp Y2l0eSBvZiB0aGUgZXZlbnQgb3Igc2hhcmluZyBhbGwgaW5mb3JtYXRpb24gaW4gdGhlIFNFVCB3 aXRoIGV2ZXJ5IHN5c3RlbSBoYW5kbGluZyBhbnkgZXZlbnQgaW4gdGhlIHRva2VuLlsvcmljaGFu bmFdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJjb2xvcjojQzM0NkUwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246 aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQoyLiZu YnNwOyBNdWx0aXBsZSBldmVudHMgcGF5bG9hZHMgZXhwcmVzc2luZyBkaWZmZXJlbnQgc3RhdGVt ZW50cyBhYm91dCB0aGUgc2FtZSB0cmFuc2FjdGlvbiAtIFJJU0MgUGFzc3dvcmQgUmVzZXQgYW5k IFJJU0MgU2Vzc2lvbiBDYW5jZWw8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6I0MzNDZFMCI+W3Jp Y2hhbm5hXVNhbWUgYXMgYWJvdmVbL3JpY2hhbm5hXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+My4mbmJzcDsgQSBuZXcgcHJvZmlsZSBkZWZpbmVzIG5l dyBldmVudCBhdHRyaWJ1dGVzIHRvIGJlIGFkZGVkIG9uIHRvIGFuIGV4aXN0aW5nIGV2ZW50IHR5 cGUgKGEgcHVyZSBleHRlbnNpb24pJm5ic3A7PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiNDMzQ2 RTAiPltyaWNoYW5uYV1JIGhhdmUgc3VnZ2VzdGVkIGEgd2F5IHRvIHN1cHBvcnQgZXh0ZW5zaW9u cyB3aXRoaW4gYW4gZXZlbnQgYm9keSwgbXVsdGlwbGUgdGltZXMgbm93LiBJZiB5b3Ugc2VlIHBy b2JsZW1zIHdpdGggaXQsIHBsZWFzZSBwb2ludCB0aGVtIG91dC5bL3JpY2hhbm5hXTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JIHRoaW5r IGl0IGlzIHF1aXRlIHZhbGlkIHRvIGFsbG93IDEgYW5kIDMuICZuYnNwOzIgY291bGQgYmUgbGlt aXRlZCBieSBzcGVjaWZpYyBwcm9maWxlcyBsaWtlIFJJU0MgaWYgdGhleSB3YW50LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkkgYW0gbm90IGluIGFn cmVlbWVudCB0aGF0IG1ha2luZyBldmVudCBzaW5ndWxhciBzaW1wbGlmaWVzIGFueXRoaW5nLiBG b3Igb25lIGlzIG1ha2VzIGV4dGVuc2lvbnMgY29tcGxleCAoYW5vdGhlciBuZXN0ZWQgSlNPTiBz dHJ1Y3R1cmUpIGFuZCBwb3RlbnRpYWxseSBjb25mbGljdGluZy4mbmJzcDs8YnI+DQo8c3BhbiBz dHlsZT0iY29sb3I6I0MzNDZFMCI+W3JpY2hhbm5hXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6I0MzNDZFMCI+V2F5cyB0aGF0IG11 bHRpcGxlLWV2ZW50IFNFVHMgYXJlIG1vcmUgY29tcGxpY2F0ZWQ6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIx IiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6I0MzNDZFMDtt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZTti YWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0 aWFsIGluaXRpYWwiPg0KSXQgcmVzdWx0cyBpbiBhIG1vcmUgY29tcGxleCBzdHJ1Y3R1cmUgZm9y IHRoZSBzaW5nbGUgZXZlbnQgdXNlIGNhc2UsIHdoaWNoIEkgdGhpbmsgd2UgYWxsIGFncmVlIGlz IHRoZSBtYWpvcml0eSB1c2UgY2FzZS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjojQzM0NkUwO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMjtiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0 aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQpNdWx0aXBsZS1ldmVudCBT RVRzIGhhdmUgYW1iaWd1b3VzIHNlbWFudGljcy4gVGhlIHByZXNlbmNlIG9mIHR3byBldmVudHMg QSBhbmQgQiBpbiB0aGUgc2FtZSBTRVQgY291bGQgbWVhbiBhbnkgb2Y6PG86cD48L286cD48L2xp Pjwvb2w+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMiIgdHlwZT0iMSI+DQo8 b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiNDMzQ2RTA7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0 OmwxIGxldmVsMiBsZm8zO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0 aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NClRoZXkgYXJl IHJlbGF0ZWQgdG8gdGhlIHNhbWUgbG9naWNhbCBldmVudCAoaS5lLiB0aGUgc2FtZSB0aGluZyBh cyBpZiB0aGV5IHdlcmUgZnJvbSBkaWZmZXJlbnQgU0VUcyB0aGF0IGhhdmUgYSBjb21tb24gdHhu KS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojQzM0 NkUwO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDIgbGZvMztiYWNrZ3JvdW5kOndo aXRlO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0 OmluaXRpYWwgaW5pdGlhbCI+DQpBIGlzIGFuIGV4dGVuc2lvbiBvZiBCLjxvOnA+PC9vOnA+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiNDMzQ2RTA7bWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwxIGxldmVsMiBsZm8zO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1w b3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFs Ij4NCkIgaXMgYW4gZXh0ZW5zaW9uIG9mIEEuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY29sb3I6I0MzNDZFMDttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEg bGV2ZWwyIGxmbzM7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwg aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KVGhleSBhcmUgYWxp YXNlcyBmb3Igb25lIGFub3RoZXIuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iY29sb3I6I0MzNDZFMDttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwy IGxmbzM7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlh bDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KVGhleSBhcmUgbm90IGFjdHVh bGx5IHJlbGF0ZWQgdG8gb25lIGFub3RoZXIgaW4gYW55IHdheS48bzpwPjwvbzpwPjwvbGk+PC9v bD4NCjwvb2w+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMyIgdHlwZT0iMSI+ DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiNDMzQ2RTA7bWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwzIGxldmVsMSBsZm80O2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1w b3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFs Ij4NCkNsYWltIHNlbWFudGljcyBiZWNvbWUgaGFyZGVyIHRvIGRlZmluZSwgYXMgZGlmZmVyZW50 IHByb2ZpbGVzIG1heSB3YW50IHRvIHVzZSB0aGUgc2FtZSBjbGFpbXMgaW4gZGlmZmVyZW50IHdh eXMuPG86cD48L286cD48L2xpPjwvb2w+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JZiB0aGUgV0cgd2Fu dHMgdG8gYmxvY2sgMSBhbmQgMiBhYm92ZSwgdGhlbiBJIGJlbGlldmUgd2UgaGF2ZSB0byBlc3Rh Ymxpc2ggYW4gZXZlbnQgcmVnaXN0cnkgdG8gZW5zdXJlIG5ldyBFdmVudCBwcm9maWxlcyBkbyBu b3Qgb3ZlcmxhcCB0byBlbGltaW5hdGUgdGhlIG5lZWQgdG8gZXhwcmVzcyBtdWx0aXBsZSBldmVu dHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImNvbG9yOiNDMzQ2RTAiPltyaWNoYW5uYV1J4oCZbSBub3Qgc3VyZSB3aGF0IHlv dSBtZWFuIGJ5IHRoaXMuIEFyZSB5b3UgcmVmZXJyaW5nIHRvIGV2ZW50IG5hbWVzPyBUaG9zZSBh cmUgYWxyZWFkeSBkZWZpbmVkIGJ5IHRoZSBzcGVjIHRvIGJlIFVSSXMuWy9yaWNoYW5uYV08L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0 ZWN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+QGlu ZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cC0zQV9fd3d3LmluZGVwZW5kZW50aWQuY29tJmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVt Q1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFX Tnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209VS1hNUhCTkQwSGFUWDRhbk5aZnpY N3BEc2ZLNWYwaDltWjlDWmtrR2llYyZhbXA7cz1LQndLUEZucVlfUTk1Q1RBX19XR0NZR1R4ckQ3 QUdDeHVlb1BYbktFVVQwJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBo cmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5PbiBPY3QgMjksIDIwMTcsIGF0IDQ6MTIgUE0s IERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRpY2suaGFyZHRAZ21haWwu Y29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5QaGlsOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPkluIHlvdXIgZXhhbXBsZXMgZm9yIGhhdmluZyBhIHBsdXJhbGl0eSBvZiBl dmVudHMsIHlvdSB1c2UgdGhlIHdvcmQgJnF1b3Q7bWF5JnF1b3Q7LCB3aGljaCBsZWFkcyBtZSB0 byBxdWVzdGlvbiBpZiBhIHBsdXJhbGl0eSBvZiBldmVudHMgaXMgcmVhbGx5IHJlcXVpcmVkDQog aW4gU0VULjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+WW91IHBv c2l0IHRoYXQgaXQgd2lsbCBiZSBkaWZmaWN1bHQgZm9yIGEgZGlzdHJpYnV0ZWQgc3lzdGVtIHRv IGNvcnJlbGF0ZSBtdWx0aXBsZSBTRVRzIHdpdGggdGhlIHNhbWUgJnF1b3Q7dHhuJnF1b3Q7LCBi dXQgdGhlIGRpc3RyaWJ1dGVkIHN5c3RlbSB3aWxsIGNlcnRhaW5seQ0KIG5lZWQgdG8gY29ycmVs YXRlIGV2ZW50cyBvbiB0aGUgc2FtZSBzdWJqZWN0IC0tIGNvcnJlbGF0aW5nIGV2ZW50cyBvbiB0 aGUgc2FtZSAmcXVvdDt0eG4mcXVvdDsgb24gdGhlIHNhbWUgc3ViamVjdCBzZWVtcyBmYWlybHkg c2ltcGxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSB0aGlu ayB0aGF0IGEgcmVjZWl2ZXIgd2lsbCBuZWVkIHRvIGNvcnJlbGF0ZSBtdWx0aXBsZSBTRXRzIG9u IHRoZSBzYW1lIHN1YmplY3QsIHNvIGhhdmluZyBtdWx0aXBsZSBldmVudHMgaW4gYSBTRVQgaXMg cmVkdW5kYW50LCBhbmQgYWRkcyBjb21wbGV4aXR5DQogd2l0aCBubyBjbGVhciBiZW5lZml0IHRo YXQgSSBjYW4gc2VlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ QW4gaW1wbGVtZW50b3IgbWF5IGNob29zZSB0byBzZW5kIG11bHRpcGxlIFNFVHMsIG9yIHNlbmQg YSBzaW5nbGUgU0VUIHdpdGggbXVsdGlwbGUgZXZlbnRzLCBzbyBhIHJlY2VpdmVyIHdpbGwgbmVl ZCB0byBzdXBwb3J0IGJvdGguIEkgcHJlZmVyIHdlIHBpY2sNCiBvbmUgd2F5IGFuZCBtaW5pbWl6 ZSB0aGUgY29kZSBwYXRocywgYW5kIHdlIHdpbGwgbmVlZCB0byBzdXBwb3J0IGNvcnJlbGF0aW5n IGFjcm9zcyBtdWx0aXBsZSBTRVRzLCBzbyB0aGF0IHNlZW1zIHRoZSBiZXN0IG1lY2hhbmlzbS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkxldCBtZSBrbm93IGlm IHRoZXJlIGlzIHNvbWV0aGluZyBJIG1pc3NlZCBpbiBteSBsb2dpYy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPi9EaWNrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gU3VuLCBPY3Qg MjksIDIwMTcgYXQgMTE6MjggQU0sIFlhcm9uIFNoZWZmZXI8c3BhbiBjbGFzcz0ibS0zMTUxNDQ1 OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3 Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAz bTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4m bHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48 L2E+Jmd0OzxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1Njgz MzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwbS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYx NDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkluIHRoYXQgY2FzZSwgbGV0J3MgYWRkIHRl eHQgdG8gdGhhdCBlZmZlY3QsIGUuZy4gd2UgY291bGQgYWRkIHRvIHRoZSBkZWZpbml0aW9uIG9m IHRoZSAmcXVvdDtldmVudHMmcXVvdDsgY2xhaW06PGJyPg0KPGJyPg0KUHJvZmlsaW5nIHNwZWNp ZmljYXRpb25zIFNIT1VMRCBkZWZpbmUgdGhlIGFsbG93ZWQgZXZlbnQgc3RhdGVtZW50cywgYW5k IE1BWSByZXN0cmljdCB0aGVpciBudW1iZXIuIEZvciBleGFtcGxlLCBzb21lIHByb2ZpbGVzIG1h eSByZXF1aXJlIHRoaXMgY2xhaW0gdG8gY29udGFpbiBvbmx5IGEgc2luZ2xlIGV2ZW50IHN0YXRl bWVudC48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PHNwYW4gY2xhc3M9Im0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2 ODM0MDI5Mzc3ODE1NjEwODBtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUz MDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+WWFyb248YnI+DQo8YnI+DQpPbiAyNC8xMC8xNyAyMjoxMCwg TWlrZSBKb25lcyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0 ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDpp bml0aWFsIGluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBhZ3JlZSB3aXRoIG11Y2ggb2Yg UGhpbOKAmXMgcmF0aW9uYWxlIGhlcmUuPGJyPg0KPGJyPg0KSXTigJlzIGZpbmUgZm9yIHNvbWUg cHJvZmlsZXMgdG8gc2F5IHRoYXQgdGhlIOKAnGV2ZW50c+KAnSBzZXQgbXVzdCBiZSBhIHNpbmds ZXRvbi4mbmJzcDsgVGhhdCBkb2VzbuKAmXQgaGF2ZSB0byBiZSB0cnVlIGZvciBhbGwgZXZlbnRz LiZuYnNwOyBJIHRoaW5rIHRoaW5ncyBhcmUgZmluZSBhcy1pcy48YnI+DQo8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ibS0zMTUxNDQ1 OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3 Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAz bTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4t LSBNaWtlPGJyPg0KPGJyPg0KKkZyb206KiBJZC1ldmVudCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSAqT24g QmVoYWxmIE9mICpQaGlsIEh1bnQ8YnI+DQoqU2VudDoqIE1vbmRheSwgT2N0b2JlciAyMywgMjAx NyA4OjQ3IFBNPGJyPg0KKlRvOiogUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhy ZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+cmljaGFubmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4N CipDYzoqIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVu dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlk LWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KKlN1YmplY3Q6KiBSZTogW0lkLWV2 ZW50XSBVc2UgY2FzZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgU0VUPzxicj4NCjxicj4NCkFu bmFiZWxsZSw8YnI+DQo8YnI+DQpJIGhhdmUgYSBudW1iZXIgb2YgY29uY2VybnMgd2l0aCB0aGlz IHByb3Bvc2FsLjxicj4NCjxicj4NClByb2ZpbGluZyBJbmRlcGVuZGVuY2UgLyBLZWVwaW5nIEV2 ZW50IFBheWxvYWRzIEluZGVwZW5kZW50PGJyPg0KPGJyPg0KSW5kaWNhdGluZyB0aGF0IGV4dGVu c2lvbnMgc2hvdWxkIGJlIGhhbmRsZWQgYnkgcHJvZmlsZXMgbGVhZHMgdG8gbW9yZSBpbnRlci1v cGVyYWJpbGl0eSBpc3N1ZXMgYW5kIG1vcmUgaW1wb3J0YW50bHkgaW50cnVkZXMgb24gdGhlIEV2 ZW50IHBheWxvYWQgc3BhY2UgYnkgc3VnZ2VzdGluZyBhIHN1Yi1zY2hlbWEgY3JlYXRlcyBwb3Rl bnRpYWwgbGltaXRhdGlvbnMgYW5kIGNvbmZsaWN0cyB0aGF0IG1heSBhZGQgdG8gY29tcGxleGl0 eSBsYXRlcg0KIG9uLiBUaGUgY3VycmVudCBmb3JtYXQgYWxsb3dzIGEgcGFyc2VyIHRvIGRpc2Nv dmVyIGFuZCB1bmxvYWQgb25lIG9yIG1vcmUgSlNPTiBwYXlsb2FkcyB3aGljaCBjYW4gZWFjaCBo YXZlIGluZGVwZW5kZW50IHN0cnVjdHVyZS48YnI+DQo8YnI+DQpHZW5lcmFsIGV4dGVuc2lvbnM8 YnI+DQo8YnI+DQpUaGUgcHJvcG9zYWwgYWxzbyBydWxlcyBvdXQgZ2VuZXJhbCBwdXJwb3NlIGV4 dGVuc2lvbnMgbm90IHJlbGF0ZWQgdG8gYW55IHNwZWNpZmljIGV2ZW50LiBHaXZlbiB0aGUgZW1l cmdlbmNlIG9mIGl0ZW1zIGxpa2UgR1BSRCwgSSB3b3VsZCBub3Qgd2FudCB0byBibG9jayB0aGUg YWJpbGl0eSB0byBhZGQgbWV0YS1kYXRhIG9yIG90aGVyIGdlbmVyYWwgcHVycG9zZSBpdGVtcy4g V2UgY2FuIGFsc28gYW50aWNpcGF0ZSBzb21lIGRlbGl2ZXJ5IHNjZW5hcmlvcw0KIHdoZXJlIGFk ZGl0aW9uYWwgZGF0YSBtaWdodCBiZSByZXF1aXJlZC4gRXZlbiB0aG91Z2ggdGhlcmUgaXMgbm8g Y3VycmVudCBwbGFubmVkIHVzZSwgSSBzZWUgbm8gZ29vZCByZWFzb24gdG8gcnVsZSB0aGlzIG91 dC48YnI+DQo8YnI+DQpNdWx0aXBsZSBFdmVudHMgRnJvbSBEaWZmZXJlbnQgRmFtaWxpZXMgKHZz LiBNdWx0aXBsZSBFdmVudHMgZnJvbSBhIHNpbmdsZSBmYW1pbHkgbGlrZSBSSVNDKTxicj4NCjxi cj4NCkluIG91ciBSSVNDIHNlc3Npb24gd2UgZGlzY3Vzc2VkIGV4cHJlc3NpbmcgbXVsdGlwbGUg ZGlzdGluY3QgUklTQyBldmVudHMgaW4gb25lIFNFVC4gVGhlIGRpc2N1c3Npb24gd2FzIHRoYXQg b25seSBvbmUgUklTQyBldmVudCBhdCBhIHRpbWUuIFdlIGRpZCBub3QgZGlzY3VzcyBvdGhlciBl dmVudCBwcm9maWxlcy4gSSBkb27igJl0IHNlZSBhIHJlYXNvbiB0byBydWxlIG91dCBtdWx0aS1l dmVudHMgZnJvbSBkaWZmZXJlbnQgZmFtaWxpZXMgYXQgdGhlDQogU0VUIGxldmVsLiBFYWNoIHBy b2ZpbGUgaXMgZXhwcmVzc2luZyBzbGlnaHRseSBkaWZmZXJlbnQgdGhpbmdzIGFib3V0IHRoZSBz YW1lIGV2ZW50Ljxicj4NCjxicj4NCkkgY2FuIGZvcnNlZSBzb21lIGNhc2VzIHdoZXJlIGl0IGlz IG5vdCBjbGVhciB3aGljaCBpcyB0aGUgcHJpbWFyeSBhbmQgd2hpY2ggaXMgdGhlIGV4dGVuc2lv bi4mbmJzcDsgVGhlcmUgbWF5IG5vdCBiZSBhIGNsZWFyIHdpbm5lci48YnI+DQo8YnI+DQpBIGNv dXBsZSBvZiBleGFtcGxlcyAodGhlc2UgYXJlIG5lY2Vzc2FyaWx5IHJlYWzigKZqdXN0IHBvc3Np YmlsaXRpZXMpOjxicj4NCjxicj4NCiogSXQgaXMgcHJvYmFibHkgdXNlZnVsIHRvIGJlIGFibGUg dG8gZXhwcmVzcyBzaW1sYXIvb3ZlcmxhcHBpbmcgZXZlbnRzIGZyb20gZGlmZmVyZW50IFNFVCBw cm9maWxlcyBpbiBvbmUgU0VULiZuYnNwOyBGb3IgZXhhbXBsZSBhIEJhY2tjaGFubmVsIExvZ291 dCAmYW1wOyBhIFJJU0Mgc2Vzc2lvbiBjYW5jZWwgZXZlbnQuPGJyPg0KPGJyPg0KKiBTQ0lNIG1h eSB3YW50IHRvIHJlcHJlc2VudCBhIHNpbmdsZSB0cmFuc2FjdGlvbiBhcyBjYXVzaW5nIG11bHRp cGxlIHN0YXRlIGNoYW5nZXMgaW4gYW4gZXZlbnQgKGUuZy4gYSBwYXNzd29yZCBjaGFuZ2UgY2F1 c2VzIG11bHRpcGxlIGVmZmVjdHMpLiBIYXZpbmcgdG8gY2hhc2UgZG93biBtdWx0aXBsZSBldmVu dHMgYW5kIGNvcnJlbGF0ZSBieSDigJx0eG7igJ0gd291bGQgYmUgY2hhbGxlbmdpbmcgaW4gYSBt dWx0aS10aHJlYWRlZC9tdWx0aS1ub2RlDQogZGVsaXZlcnkgc3lzdGVtLiZuYnNwOyAmbmJzcDtU aGUgU0NJTSBsaXN0IGhhcyBub3QgZGlzY3Vzc2VkIHRoaXMsIGJ1dCBJIHdvdWxkIG5vdCB3YW50 IHRvIGJsb2NrIHRoaXMgY2FwYWJpbGl0eS4mbmJzcDsgSU9XIC0gSnVzdCBiZWNhdXNlIFJJU0Mg ZG9lcyBub3Qgd2FudCB0byBleHByZXNzIG11bHRpcGxlIGV2ZW50cyBkb2VzIG5vdCBtYWtlIHRo aXMgdHJ1ZSBmb3Igb3RoZXIgcHJvZmlsZXMuPGJyPg0KPGJyPg0KKiBXZSBtYXkgd2lzaCB0byBp bmRpY2F0ZSBhIFNDSU0gUGFzc3dvcmQgUmVzZXQgd2FzIHBlcmZvcm1lZCBhbmQgYSBMb2dvdXQv c2Vzc2lvbiBjYW5jZWxsYXRpb24gaXMgZXhwcmVzc2VkIGF0IHRoZSBzYW1lIHRpbWUuJm5ic3A7 IFRoZSBldmVudHMgYXJlIHJlbGF0ZWQgYnV0IGV4cHJlc3MgZGlmZmVyZW50IGRhdGEuPGJyPg0K PGJyPg0KQXZvaWRpbmcgQ29uZnVzaW9uIEZyb20gU2ltaWxhciBFdmVudHMgT3JpZ2luYXRpbmcg ZnJvbSB0aGUgU2FtZSBUcmFuc2FjdGlvbjxicj4NCjxicj4NCklmIGV2ZW50cyBhcmUgc2VudCBz ZXBhcmF0ZWx5LCB0aGVuIG1vcmUgdHJhY2tpbmcgb2Ygc3RhdGUgKGUuZy4gYnkgdHhuKSB3b3Vs ZCBiZSByZXF1aXJlZCB0byBlbnN1cmUgc2ltaWxhciBldmVudHMgYXJlIG5vdCBtaXN0YWtlbiBv ciBoYW5kbGVkIGFzIHJlcGVhdHMuIFdoaWxlIHR4biBwcm92aWRlcyB1c2VmdWwgYXVkaXQgYW5h bHlzaXMgY2FwYWJpbGl0eSwgSeKAmW0gbm90IHN1cmUgaXQgY2FuIGJlIHVzZWQgaW4gbGl2ZSBv ciBuZWFyLXJlYWwNCiB0aW1lIHN5c3RlbXMgZ2l2ZW4gZGlzdHJpYnV0ZWQgbXVsdGktbm9kZSwg bXVsdGktdGhyZWFkaW5nIGFyY2hpdGVjdHVyZXMuPGJyPg0KPGJyPg0KUHJldmlvdXMgRGlzY3Vz c2lvbjxicj4NCjxicj4NCkkgbm90ZSB0aGF0IEkgb3JpZ2luYWxseSByYWlzZWQgaGF2aW5nIGFu IGF0dHJpYnV0ZSB0byBkZXNpZ25hdGUgcHJpbWFyeSBldmVudCBhdHRyaWJ1dGUgdG8gYWxsZXZp YXRlIHlvdXIgY29uY2VybiwgYnV0IHRoaXMgd2FzIG5vdCBhY2NlcHRlZC4gU2VlOjxicj4NCjxi cj4NCio8c3BhbiBjbGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMw MDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQx MDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2 ZV93ZWJfaWQtMkRldmVudF9jdXJyZW50X21zZzAwNDA2Lmh0bWwmYW1wO2Q9RHdNRmFRJmFtcDtj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6 QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1ZQkNHbEs5bWpqaGNG c2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtzPVMzc01WaXFNdkVnbndHYkp3T1FO eWNyT3lyN1NlZnBxX01vRk9LY0VlQ0UmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9p ZC1ldmVudC9jdXJyZW50L21zZzAwNDA2Lmh0bWw8L3NwYW4+PC9hPjxicj4NCjxicj4NCio8c3Bh biBjbGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQw MjkzNzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02 OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfaWQt MkRldmVudF9jdXJyZW50X21zZzAwMTQwLmh0bWwmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdO eTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1ZQkNHbEs5bWpqaGNGc2otMnREa24z MUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtzPUd5OWd5Um9JSXRhLWNTaFY3Yk4xNjFheTR5RTZy OUcxX0FhX05lQm55bGcmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pZC1ldmVudC9j dXJyZW50L21zZzAwMTQwLmh0bWw8L3NwYW4+PC9hPjxicj4NCjxicj4NClRoZSBjb25zZW5zdXMs IGF0IGxlYXN0IGFzIEkgaW50ZXJwcmV0ZWQgaXQgaXMgdXAgdG8gdGhlIHJlY2VpdmVyIHRvIGZp Z3VyZSB0aGlzIG91dCBiYXNlZCBvbiB0aGUgZGVmaW5pdGlvbnMgaXQgaGFzIGZvciBlYWNoIGV2 ZW50IFVSSSBhbmQgdGhlIHByb2ZpbGVzIHRoZXkgcmVwcmVzZW50LiBJT1cgLSBSSVNDIGlzIGZy ZWUgdG8gbGltaXQgdGhhdCBvbmx5IG9uZSBSSVNDIGV2ZW50IGJlIGV4cHJlc3NlZCBhdCBhIHRp bWUuPGJyPg0KPGJyPg0KUGhpbDxicj4NCjxicj4NCk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRp dHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0PGJyPg0KPGJyPg0KQGluZGVwZW5kZW50aWQ8YnI+ DQo8YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cC0zQV9fd3d3LmluZGVwZW5kZW50aWQuY29tJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1Ax WXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21h bnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209WUJDR2xLOW1qamhjRnNqLTJ0 RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZhbXA7cz05TlA1bmFtZzZySVZ6d3VuOWMtMXEwd2hz eVh3U3Z0SEIwZjJkS2tmQ1g4JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9 Im0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1 NjEwODBtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFtNjk1ODc3Njk4 MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5jb20mYW1wO2Q9RHdNRmFRJmFtcDtj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6 QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1ZQkNHbEs5bWpqaGNG c2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtzPTlOUDVuYW1nNnJJVnp3dW45Yy0x cTB3aHN5WHdTdnRIQjBmMmRLa2ZDWDgmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbTwvc3Bhbj48L2E+ Jmd0Ozxicj4NCjxicj4NCjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUu Y29tPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5 NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAx Mzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyBPbiBPY3QgMjMsIDIwMTcsIGF0IDc6MDIgUE0sIFJpY2hhcmQgQmFj a21hbiwgQW5uYWJlbGxlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJp Y2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5yaWNoYW5uYUBhbWF6b24uY29tPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ibS0zMTUxNDQ1 OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3 Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAz bTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4m bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cmljaGFubmFAYW1hem9uLmNvbTwvc3Bh bj48L2E+Jmd0OyZndDsNCiB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoZSBjdXJy ZW50IGRyYWZ0IG9mIHRoZSBTRVQgc3BlYyBhbGxvd3MgZm9yIGV4cHJlc3NpbmcgbXVsdGlwbGU8 YnI+DQombmJzcDsgJm5ic3A7IGV2ZW50cyB3aXRoaW4gdGhlIHNhbWUgdG9rZW4sIHdoaWNoIGlu dHJvZHVjZXMgYWRkaXRpb25hbCBjb21wbGV4aXR5PGJyPg0KJm5ic3A7ICZuYnNwOyBhbmQgcm9v bSBmb3IgYW1iaWd1b3VzIHNlbWFudGljcy4gV2XigJl2ZSBkaXNjdXNzZWQgdGhpcyBpbiB0aGUg T0lERjxicj4NCiZuYnNwOyAmbmJzcDsgUklTQyB3b3JraW5nIGdyb3VwIGFuZCB0aGUgY3VycmVu dCBjb25zZW5zdXMgdGhlcmUgaXMgdGhhdCBSSVNDIHdpbGw8YnI+DQombmJzcDsgJm5ic3A7IHJl cXVpcmUgdGhhdCBSSVNDIGV2ZW50cyBtdXN0IGJlIHRoZSBvbmx5IGV2ZW50IGluIHRoZSBTRVQs IGhhdmluZzxicj4NCiZuYnNwOyAmbmJzcDsgaWRlbnRpZmllZCB3YXlzIHRvIGNsZWFybHkgYW5k IGVhc2lseSBzdXBwb3J0IHRoZSBoYW5kZnVsIG9mIHVzZTxicj4NCiZuYnNwOyAmbmJzcDsgY2Fz ZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBwZXIgdG9rZW4gdGhhdCBwZW9wbGUgaGF2ZSByYWlzZWQu IFdpdGg8YnI+DQombmJzcDsgJm5ic3A7IHRoYXQgY29udGV4dCBpbiBtaW5kLCBJIHByb3Bvc2Ug c3RyaWtpbmcgdGhlIGRlZmluaXRpb24gb2YgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyDigJxldmVu dHPigJ0gY2xhaW0gZnJvbSB0aGUgU2VjdXJpdHkgRXZlbnQgVG9rZW4gc3BlYywgYW5kIHJlcGxh Y2luZyBpdDxicj4NCiZuYnNwOyAmbmJzcDsgd2l0aCB0aGUgZm9sbG93aW5nIGRlZmluaXRpb24g Zm9yIGFuIOKAnGV2ZW504oCdIGNsYWltIChzaW5ndWxhcik6PGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyBldmVudDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgQSBKU09OIG9iamVjdCBjb250YWlu aW5nIGFuICZxdW90O2V2ZW50X3R5cGUmcXVvdDsgbWVtYmVyIHdob3NlIHZhbHVlIGlzIGEgVVJJ PGJyPg0KJm5ic3A7ICZuYnNwOyByZXByZXNlbnRpbmcgYSB0eXBlIG9mIGV2ZW50IGRlZmluZWQg aW4gYSBQcm9maWxpbmcgU3BlY2lmaWNhdGlvbi48YnI+DQombmJzcDsgJm5ic3A7IFRoZSBvYmpl Y3QgTUFZIG90aGVyd2lzZSBiZSBlbXB0eSwgb3IgTUFZIGNvbnRhaW4gYWRkaXRpb25hbCBtZW1i ZXJzPGJyPg0KJm5ic3A7ICZuYnNwOyBhcyBkZXNjcmliZWQgYnkgdGhlIFByb2ZpbGluZyBTcGVj aWZpY2F0aW9uLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSGVyZSBpcyB0aGUgZXhhbXBsZSBT RVQgZnJvbSBzZWN0aW9uIDIuMywgcmV3cml0dGVuIHdpdGggdGhpcyBjaGFuZ2U8YnI+DQombmJz cDsgJm5ic3A7IG1pbmQ6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJtLTMx NTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgw bS00Mzc3Nzg3NzU1ODczMjA4OTM1bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2 NjA3MDNtNDAyNjIzNjQ1NjA4MDM0OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPns8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmcXVvdDtqdGkmcXVv dDs6ICZxdW90OzRkMzU1OWVjNjc1MDRhYWJhNjVkNDBiMDM2M2ZhYWQ4JnF1b3Q7LDxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZxdW90O2lhdCZxdW90OzogMTQ1ODQ5NjQw NCw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZxdW90O2lzcyZxdW90Ozog JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbTwvc3Bh bj48L2E+PHNwYW4gY2xhc3M9Im0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMz MDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0 MTAyNjUzMDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFt cGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRw czovL3NjaW0uZXhhbXBsZS5jb20vPC9zcGFuPjwvYT4mZ3Q7JnF1b3Q7LDxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZxdW90O2F1ZCZxdW90OzogWzxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZxdW90OzxhIGhyZWY9Imh0dHBz Oi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9zY2ltLmV4YW1w bGUuY29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQ8L3NwYW4+PC9hPiZxdW90Oyw8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmcXVvdDs8 YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFk NzY3NmVlNyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBz Oi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3PC9zcGFu PjwvYT4mcXVvdDs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyBdLDxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZxdW90O2V2ZW50JnF1b3Q7OiB7PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7ZXZl bnRfdHlwZSZxdW90OzogJnF1b3Q7dXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6Y3JlYXRlJnF1 b3Q7LDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90O3JlZiZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL1Vz ZXJzLzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5odHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRm OTZiZDZhYjYxZTc1MjFkOTwvc3Bhbj48L2E+JnF1b3Q7LDxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2F0dHJpYnV0ZXMmcXVvdDs6IFsmcXVv dDtpZCZxdW90OywgJnF1b3Q7bmFtZSZxdW90OywgJnF1b3Q7dXNlck5hbWUmcXVvdDssICZxdW90 O3Bhc3N3b3JkJnF1b3Q7LCAmcXVvdDtlbWFpbHMmcXVvdDtdPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsmbmJzcDsgfTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgfTxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgRG9lcyBhbnlvbmUgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgaGF2ZSB1c2Ug Y2FzZXMgZm9yIFNFVHMgdGhhdCBjYW5ub3Q8YnI+DQombmJzcDsgJm5ic3A7IGJlIG1ldCBieSB0 aGlzIHByb3Bvc2VkIHRleHQ/IFdpdGhpbiBSSVNDLCB3ZSBpZGVudGlmaWVkIHRocmVlIHVzZTxi cj4NCiZuYnNwOyAmbmJzcDsgY2FzZXMsIHdpdGggc29sdXRpb25zIG91dGxpbmVkIGJlbG93Ojxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgKio8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICpFeHRl bnNpb25zKjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgRXZlbnQgZXh0ZW5zaW9uIG1lY2hhbmlz bXMgY2FuIGJlIGRlZmluZWQgaW50ZXJuYWwgdG8gdGhlIGV2ZW50PGJyPg0KJm5ic3A7ICZuYnNw OyBvYmplY3QuIEEgc2ltcGxlIGFwcHJvYWNoIHdvdWxkIGJlIHRvICZuYnNwO2RlZmluZSBhbiDi gJxleHRlbnNpb25z4oCdIG1lbWJlcjxicj4NCiZuYnNwOyAmbmJzcDsgdGhhdCBpcyBhIGxpc3Qg b2YgZXZlbnQgb2JqZWN0cyAob3Igc2V0IHJlc2VtYmxpbmcgdGhlIOKAnGV2ZW50c+KAnTxicj4N CiZuYnNwOyAmbmJzcDsgY2xhaW0gYXMgZGVmaW5lZCBpbiB0aGUgY3VycmVudCBzcGVjKS4gVGhp cyBoYXMgdGhlIGFkdmFudGFnZSBvZjxicj4NCiZuYnNwOyAmbmJzcDsgbWFraW5nIGl0IGNsZWFy IGluIHRoZSBkYXRhIHN0cnVjdHVyZSB0aGF0IHRoZXJlIGlzIGEgc2luZ2xlIHByaW1hcnk8YnI+ DQombmJzcDsgJm5ic3A7IGV2ZW50LCB3aXRoIHplcm8gb3IgbW9yZSBleHRlbnNpb25zLiBUaGVy ZSBpcyBubyByb29tIGZvciBjb25mdXNpb248YnI+DQombmJzcDsgJm5ic3A7IG92ZXIgd2hpY2gg ZXZlbnQgaXMgcHJpbWFyeSwgb3IgaWYgdGhlcmUgaXMgYSBwcmltYXJ5IGV2ZW50IGF0IGFsbC48 YnI+DQombmJzcDsgJm5ic3A7IEkgd291bGQgYmUgZmluZSB3aXRoIGFkZGluZyBzb21ldGhpbmcg bGlrZSB0aGlzIHRvIG15IHByb3Bvc2VkIHRleHQsPGJyPg0KJm5ic3A7ICZuYnNwOyBpZiB0aGVy ZSBpcyBjb25zZW5zdXMgdGhhdCBpdCBpcyBicm9hZGx5IHVzZWZ1bC48YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICpBbGlhc2VzKjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgVGhpcyB1c2UgY2Fz ZSB3YXMgYnJvdWdodCB1cCBpbiB0aGUgY29udGV4dCBvZiBtaWdyYXRpbmcgY2xpZW50czxicj4N CiZuYnNwOyAmbmJzcDsgZnJvbSBkcmFmdCBldmVudCBuYW1lcyB0byBzdGFuZGFyZGl6ZWQgZXZl bnQgbmFtZXMuIEluIHRoaXMgY2FzZSw8YnI+DQombmJzcDsgJm5ic3A7IHRoZSBldmVudCB0cmFu c21pdHRlciBjYW4gdHJhbnNtaXQgdHdvIHRva2VucyBmb3IgdGhlIGxvZ2ljYWwgZXZlbnQsPGJy Pg0KJm5ic3A7ICZuYnNwOyBvbmUgdXNpbmcgdGhlIG9sZCBuYW1lIGFuZCBhbm90aGVyIHVzaW5n IHRoZSBuZXcgbmFtZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICpSZWxhdGVkIEV2ZW50cyo8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoZSBTRVQgc3BlYyBkZWZpbmVzIHRoZSB0eG4gY2xh aW0gYXMgYSBtZWFucyBvZiBjb3JyZWxhdGluZzxicj4NCiZuYnNwOyAmbmJzcDsgaW5kZXBlbmRl bnQgdG9rZW5zIHRoYXQgcmVsYXRlIHRvIHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQuPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyAtLTxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3 NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwbS00Mzc3Nzg3NzU1ODczMjA4OTM1 bS01MDEzODU0ODYxNDEwMjY1MzAxbTY5NTg3NzY5ODAyNDY2NjA3MDNtNDAyNjIzNjQ1NjA4MDM0 OTY0NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZuYnNwOyAmbmJz cDsgQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgQW1h em9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlczxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5i c3A7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0i bS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2 MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgw MjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+ PHNwYW4gY2xhc3M9Im0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2 ODM0MDI5Mzc3ODE1NjEwODBtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUz MDFtNjk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1l dmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDs8c3BhbiBjbGFz cz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4 MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2 OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQm YW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3 U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZh bXA7bT1zNWJ5QmU1S0FObkdWdUFiMW1BdXBFR29KbjhYRzVKSVVVd1dHRlNpYkVjJmFtcDtzPVg4 b1JTcTNJemxGN2ppUkFlWmhYcFIzZVZJMEk1OFpGZDRlRVpmZ3lvSVkmYW1wO2U9IiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBR Y3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpq V3dsTktlNENfbExJR2smYW1wO209czVieUJlNUtBTm5HVnVBYjFtQXVwRUdvSm44WEc1SklVVXdX R0ZTaWJFYyZhbXA7cz1YOG9SU3EzSXpsRjdqaVJBZVpoWHBSM2VWSTBJNThaRmQ0ZUVaZmd5b0lZ JmFtcDtlPTwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtk PUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5F JmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209 WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxRRzFpdyZhbXA7cz1Xck11UVJ3 TFY4MDJpTVE0d1lCMWYyckZVR3U0emJoY1cwMDFmSzAyRVhzJmFtcDtlPSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1E d01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZh bXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPVlC Q0dsSzltampoY0Zzai0ydERrbjMxQXV4dXJ1aWI5S0FUa1JsUUcxaXcmYW1wO3M9V3JNdVFSd0xW ODAyaU1RNHdZQjFmMnJGVUd1NHpiaGNXMDAxZkswMkVYcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48 YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPi0tPHNw YW4gY2xhc3M9Im0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0 MDI5Mzc3ODE1NjEwODBtLTQzNzc3ODc3NTU4NzMyMDg5MzVtLTUwMTM4NTQ4NjE0MTAyNjUzMDFt Njk1ODc3Njk4MDI0NjY2MDcwM200MDI2MjM2NDU2MDgwMzQ5NjQ0YXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPlN1YnNjcmliZSB0byB0aGU8c3BhbiBjbGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4 bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIw ODkzNW0tNTAxMzg1NDg2MTQxMDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYw ODAzNDk2NDRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJl LmNvbV8mYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1V QjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40 S1pOQSZhbXA7bT1ZQkNHbEs5bWpqaGNGc2otMnREa24zMUF1eHVydWliOUtBVGtSbFFHMWl3JmFt cDtzPUxZTjcyR2dLVmhIc1Q2dEFxQmUtZU1vV012eV83ZGZGbjF1WjBISzZZdVEmYW1wO2U9IiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SEFSRFRXQVJFPC9zcGFu PjwvYT48c3BhbiBjbGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMw MDRtNTY4MzQwMjkzNzc4MTU2MTA4MG0tNDM3Nzc4Nzc1NTg3MzIwODkzNW0tNTAxMzg1NDg2MTQx MDI2NTMwMW02OTU4Nzc2OTgwMjQ2NjYwNzAzbTQwMjYyMzY0NTYwODAzNDk2NDRhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5tYWlsDQogbGlzdCB0byBsZWFybiBhYm91dCBwcm9q ZWN0cyBJIGFtIHdvcmtpbmcgb24hPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5m b19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhC djdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJ MWFMY0xONEtaTkEmYW1wO209WUJDR2xLOW1qamhjRnNqLTJ0RGtuMzFBdXh1cnVpYjlLQVRrUmxR RzFpdyZhbXA7cz1Xck11UVJ3TFY4MDJpTVE0d1lCMWYyckZVR3U0emJoY1cwMDFmSzAyRVhzJmFt cDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5odHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZ dW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFu cVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1ZQkNHbEs5bWpqaGNGc2otMnRE a24zMUF1eHVydWliOUtBVGtSbFFHMWl3JmFtcDtzPVdyTXVRUndMVjgwMmlNUTR3WUIxZjJyRlVH dTR6YmhjVzAwMWZLMDJFWHMmYW1wO2U9PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjti YWNrZ3JvdW5kOndoaXRlIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+SWQtZXZlbnQgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjwvc3Bhbj48YSBo cmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj5JZC1ldmVudEBpZXRmLm9yZzwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdt YW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPVUtYTVIQk5EMEhhVFg0YW5O WmZ6WDdwRHNmSzVmMGg5bVo5Q1pra0dpZWMmYW1wO3M9cnZkcnRJN3JZTlJBbnFaRGx0Q3dCQVpW SEtwLU1KMjB1aTJubTQ2UVN6MCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj5odHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpo OEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBr QUkxYUxjTE40S1pOQSZhbXA7bT1VLWE1SEJORDBIYVRYNGFuTlpmelg3cERzZks1ZjBoOW1aOUNa a2tHaWVjJmFtcDtzPXJ2ZHJ0STdyWU5SQW5xWkRsdEN3QkFaVkhLcC1NSjIwdWkybm00NlFTejAm YW1wO2U9PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+LS08bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij5TdWJzY3JpYmUgdG8gdGhlPHNwYW4gY2xhc3M9Im0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2 MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZ dW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFu cVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1peVZuclptcjlfdUdDUTZNRDB6 RjJ5bVJRUzZsSzY3eUZfOHU4X3FTQ193JmFtcDtzPXd0Z0QzTnAwdnloTGRwRXdVaXFzZjRJdGl3 QTNPbTdHcm9iNzBMeDByM2smYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+SEFSRFRXQVJFPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ibS0zMTUxNDQ1OTU4 NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4MTU2MTA4MGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm1haWwNCiBsaXN0IHRvIGxlYXJuIGFib3V0IHBy b2plY3RzIEkgYW0gd29ya2luZyBvbiE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdf bWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hD Z2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0 RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209aXlWbnJabXI5X3VHQ1E2TUQwekYyeW1S UVM2bEs2N3lGXzh1OF9xU0NfdyZhbXA7cz1PZTBxZkxFWDgzdnRYTTdXbDJjWUJlLUdnMURWUGpo WGpWSmtmaFZSendjJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcm YW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1u YTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPWl5Vm5yWm1y OV91R0NRNk1EMHpGMnltUlFTNmxLNjd5Rl84dThfcVNDX3cmYW1wO3M9T2UwcWZMRVg4M3Z0WE03 V2wyY1lCZS1HZzFEVlBqaFhqVkprZmhWUnp3YyZhbXA7ZT08L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGJyPg0KPGJyIGNsZWFyPSJh bGwiPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+LS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj5TdWJzY3JpYmUgdG8gdGhlPHNwYW4gY2xhc3M9Im0tMzE1MTQ0 NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5Mzc3ODE1NjEwODBhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mYW1wO2Q9 RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUm YW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1z SUd6OGd1cjR3TnFaa3RjbWFndjVFYTIxUUVpcDRIWHBFVktSYTBxaGxvJmFtcDtzPVY5Z3lUVFg5 cXVqckMyVmxpd0xQeTAtS3Z4UzlwWUtKXy1reURhcHdPOGsmYW1wO2U9IiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SEFSRFRXQVJFPC9zcGFuPjwvYT48c3BhbiBj bGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkz Nzc4MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm1haWwNCiBsaXN0 IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiE8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4 OCI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPlN1YnNjcmliZSB0 byB0aGU8c3BhbiBjbGFzcz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMw MDRtNTY4MzQwMjkzNzc4MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw LTNBX19oYXJkdHdhcmUuY29tXyZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZ UjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBw dVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPXNJR3o4Z3VyNHdOcVprdGNtYWd2NUVhMjFRRWlwNEhY cEVWS1JhMHFobG8mYW1wO3M9VjlneVRUWDlxdWpyQzJWbGl3TFB5MC1LdnhTOXBZS0pfLWt5RGFw d084ayZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5I QVJEVFdBUkU8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3 NjM0Njk0Njk1NjgzMzAwNG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+bWFpbA0KIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3 b3JraW5nIG9uITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4 ODg4OCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi0tPHNwYW4g Y2xhc3M9Im0tMzE1MTQ0NTk1ODQ1MTAyOTMxOG03NDc2MzQ2OTQ2OTU2ODMzMDA0bTU2ODM0MDI5 Mzc3ODE1NjEwODBhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPlN1YnNjcmliZSB0byB0aGU8c3BhbiBjbGFz cz0ibS0zMTUxNDQ1OTU4NDUxMDI5MzE4bTc0NzYzNDY5NDY5NTY4MzMwMDRtNTY4MzQwMjkzNzc4 MTU2MTA4MGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUu Y29tXyZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVC NjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRL Wk5BJmFtcDttPXNJR3o4Z3VyNHdOcVprdGNtYWd2NUVhMjFRRWlwNEhYcEVWS1JhMHFobG8mYW1w O3M9VjlneVRUWDlxdWpyQzJWbGl3TFB5MC1LdnhTOXBZS0pfLWt5RGFwd084ayZhbXA7ZT0iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5IQVJEVFdBUkU8L3NwYW4+ PC9hPjxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAw NG01NjgzNDAyOTM3NzgxNTYxMDgwYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ bWFpbA0KIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uITxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNGhvZW56 YiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4O2JhY2tncm91bmQ6d2hpdGUiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJtLTMxNTE0 NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNGhvZW56YiI+PHNwYW4gc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPklkLWV2ZW50IG1haWxpbmcgbGlzdDwvc3Bhbj48L3NwYW4+PGJyPg0K PC9zcGFuPjxzcGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1Njgz MzAwNGhvZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxhIGhyZWY9Im1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 cHVycGxlO2JhY2tncm91bmQ6d2hpdGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izg4ODg4OCI+PGJyPg0KPC9zcGFuPjxz cGFuIGNsYXNzPSJtLTMxNTE0NDU5NTg0NTEwMjkzMThtNzQ3NjM0Njk0Njk1NjgzMzAwNGhvZW56 YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f bGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZ UjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBw dVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPXNJR3o4Z3VyNHdOcVprdGNtYWd2NUVhMjFRRWlwNEhY cEVWS1JhMHFobG8mYW1wO3M9Z2ROcnM3VURBdHRwYWJqTTVuZE9Yd1dLbVp1S2FYRWJUNXd1OXJj T1JWMCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBs ZTtiYWNrZ3JvdW5kOndoaXRlIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj4uPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlO2JhY2tncm91bmQ6d2hpdGUiPmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fd3d3LmllPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlO2Jh Y2tncm91bmQ6d2hpdGUiPnQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGU7YmFj a2dyb3VuZDp3aGl0ZSI+Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGU8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpwdXJwbGU7YmFja2dyb3VuZDp3aGl0ZSI+djwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj5lbnQmYW1wO2Q9RHdJQ0Fn JmFtcDtjPVJvUDFZdW1DWENnYVdIPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxl O2JhY2tncm91bmQ6d2hpdGUiPnY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGU7 YmFja2dyb3VuZDp3aGl0ZSI+bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlO2JhY2tncm91bmQ6d2hpdGUiPnI8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGU7YmFja2dyb3VuZDp3aGl0ZSI+PW5hNUZWekJU V21hbnFXTnk0RHBjdHlYUHB1WXE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGU7 YmFja2dyb3VuZDp3aGl0ZSI+UDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZTti YWNrZ3JvdW5kOndoaXRlIj5rQUkxYUxjTE40S1pOQSZhbXA7bT1zSUd6OGd1cjR3TnE8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGU7YmFja2dyb3VuZDp3aGl0ZSI+Wjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj5rdGNtYWd2NUVh MjFRRWlwNEhYcEVWS1JhMHFobDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZTti YWNrZ3JvdW5kOndoaXRlIj5vPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlO2Jh Y2tncm91bmQ6d2hpdGUiPiZhbXA7cz1nZE5yczdVREF0dHBhYmpNNW5kT1h3V0ttWjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj51PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlO2JhY2tncm91bmQ6d2hpdGUiPkthWEViVDV3dTly Y09SVjAmYW1wO2U9PC9zcGFuPjwvYT48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1h bl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlY UHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209dU5pV1FseUtHVHUtOXA1cUpMUlMxRi0zeUtYcERB QjdLdHBrQ0RjX0pDVSZhbXA7cz1GOF9qOFJaRGxiVVAxcC0xUWZnT0VuclpPLTNJYWc3WXVsMU5L MXhwNEpzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNRmFRJmFt cDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1 RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT11TmlXUWx5S0dU dS05cDVxSkxSUzFGLTN5S1hwREFCN0t0cGtDRGNfSkNVJmFtcDtzPUY4X2o4UlpEbGJVUDFwLTFR ZmdPRW5yWk8tM0lhZzdZdWwxTksxeHA0SnMmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyI+SWQtZXZlbnRAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2 ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2 NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEta TkEmYW1wO209dU5pV1FseUtHVHUtOXA1cUpMUlMxRi0zeUtYcERBQjdLdHBrQ0RjX0pDVSZhbXA7 cz1GOF9qOFJaRGxiVVAxcC0xUWZnT0VuclpPLTNJYWc3WXVsMU5LMXhwNEpzJmFtcDtlPSI+aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1Ax WXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21h bnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209dU5pV1FseUtHVHUtOXA1cUpM UlMxRi0zeUtYcERBQjdLdHBrQ0RjX0pDVSZhbXA7cz1GOF9qOFJaRGxiVVAxcC0xUWZnT0VuclpP LTNJYWc3WXVsMU5LMXhwNEpzJmFtcDtlPTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8B223079B4DF492A808290732DCF2C52amazoncom_-- From nobody Mon Nov 13 10:21:33 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0351D129437 for ; Mon, 13 Nov 2017 10:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYfOPgPvgqqN for ; Mon, 13 Nov 2017 10:21:30 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 7CFA6124BAC for ; Mon, 13 Nov 2017 10:21:30 -0800 (PST) X-AuditID: 1209190e-b81ff700000027a3-cf-5a09e2a961e9 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 67.F8.10147.9A2E90A5; Mon, 13 Nov 2017 13:21:29 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id vADILSwn029243 for ; Mon, 13 Nov 2017 13:21:28 -0500 Received: from [172.20.3.67] ([203.127.152.4]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vADILNFP024143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 13 Nov 2017 13:21:27 -0500 From: Justin Richer To: Date: Mon, 13 Nov 2017 13:21:22 -0500 Message-ID: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> User-Agent: AquaMail/1.6.2.7 (build: 27000207) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUixCmqrLvyEWeUwd5t4hYdC7qZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcbh3JnNBj0TFg4tXmBoYHwl1MXJySAiYSGy+PZOpi5GLQ0hg MZPEvZ1/2SGck4wSb2+/Z4VwDjNJnNr3mBmkhU1AVWL6mhYmEFtEQFyi/8sCsDgLULzvM0gD JwevgLvE1UWtbCC2qICexN1rvxm7GDk4hAUMJI6/0IUoEZQ4OfMJC0iYWcBaYu8XP5Aws4C8 RPPW2cwTGHlnIamahVA1C0nVAkbmVYyyKblVurmJmTnFqcm6xcmJeXmpRbrGermZJXqpKaWb GMGBJMm3g3FSg/chRgEORiUeXocrnFFCrIllxZW5hxglOZiURHlVPrNHCfEl5adUZiQWZ8QX leakFh9ilOBgVhLh/bQOqJw3JbGyKrUoHyYlzcGiJM67LWhXpJBAemJJanZqakFqEUxWhoND SYLXEBgxQoJFqempFWmZOSUIaSYOTpDhPEDDcx6CDC8uSMwtzkyHyJ9i1OV4NvN1A7MQS15+ XqqUOG8fSJEASFFGaR7cHFACOF0/g+UVozjQW8K8k0CqeIDJA27SK6AlTEBLpEC+4y0uSURI STUwxi4NWmLiMJe/OsHeb1VRy5vbE27y/b+0kO9Qo2PrbbU3mt1rufUuTdEPOFUppNWf3OOy V+y2X+jVG1NDpKz5MvWfJoktu3T1x4KSDe2dH8/yHslTCjwqdO6c7pytamWL/ddNj2rNOqW+ dWeI2s8cn2gL4YQlWSVfhWNCcjKTDToVrLa29LxQYinOSDTUYi4qTgQAIXZXD9sCAAA= Archived-At: Subject: [Id-event] Thoughts on Syntax from today's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 18:21:32 -0000 I wanted to take a few moments to get down on virtual-paper some thoughts about the syntax and semantics of a SET from today's meeting. Originally, the event snytax that we brought to the table from the Consent Receipts working group in Kantara was very explicitly a single event being described. When RISC, OIDC sessions, and eventually SCIM came to the conersation, the group decided to try out a way to express multiple aspects of a single event in a single token. While I still agree with this principle, I can see now that it's too much of a temptation to express either multiple events or bend around the semantics in ways that could cause a lot of confusion. I now think that we should collapse the syntax as Annabelle has suggested and go even further to specify what can go where. To wit, SET payload profiles should only ever touch the things inside the event object. So I'm proposing that we do something like this: { iss: <-- string representing the issuer of the SET itself sub: <-- string representing the subject of the SET from the view of the issuer (if known), no format assumed iat: <-- timestamp of when the SET Was created, not to be confused with the event time aud: <-- array or string repreesnting the recipients of this SET, from the view of the issuer of the sET exp: <-- timestamp of when the SET shouldn't be processed anymore event: { <-- object for the event itself, SET profiles do all of their definitions in here toe: <-- timestamp of the event, if known; if not present, event time is unknown iss: <-- issuer namespace for the subject of this event, as known by the recipient sub: <-- subject of the event, as known by the recipient, namespaced by event.iss txn: <-- transaction identifier for tying multiple events together event_type: <-- URI representing this event's type, must be understood by recipient (who can do a string match), can define other additional fields and their semantics } } And to Leif's point, to have a group event we would do: event: { event_type: urn:ietf:secevent:event_group events: [ <-- array of event objects with the semantics of the regular event object, taken all at once; can re-use any of the root event elements defined in SET but must not repeat any in the root event's common attributes ] } Event groups create some interop issues, as you need to have clients that can handle events in a group as well as on their own. But with the way people were describing event groups today, I think that's actually a good thing -- it would force recognition of the associated nature of all the components. If you get an event group, you need to understand everything in the group. No primary/secondary, no pritical fields -- all or nothing. Yes this is a change from current syntax and semantics, but to me it feels like a return to the consent receipt part of the roots. -- Justin From nobody Mon Nov 13 18:35:49 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F9D127869 for ; Mon, 13 Nov 2017 18:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 IU14cZ88XyxR for ; Mon, 13 Nov 2017 18:35:45 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 8223E127735 for ; Mon, 13 Nov 2017 18:35:45 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vAE2Zhwc030970 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 14 Nov 2017 02:35:44 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vAE2Zh2P025282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 14 Nov 2017 02:35:43 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vAE2Zht3017622; Tue, 14 Nov 2017 02:35:43 GMT Received: from dhcp-90e5.meeting.ietf.org (/31.133.144.229) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Nov 2017 18:35:42 -0800 From: Phil Hunt Message-Id: <462D13E3-1D3E-45B8-AFC8-7CB91FDCF8A0@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_89FC8BFA-6FB2-4A35-94CE-A1F15F65FB93" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 14 Nov 2017 10:35:40 +0800 In-Reply-To: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> Cc: id-event@ietf.org To: Justin Richer References: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Id-event] Thoughts on Syntax from today's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:35:48 -0000 --Apple-Mail=_89FC8BFA-6FB2-4A35-94CE-A1F15F65FB93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii How do you propose to handle extensions of event uris? Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Nov 14, 2017, at 2:21 AM, Justin Richer wrote: >=20 > I wanted to take a few moments to get down on virtual-paper some = thoughts about the syntax and semantics of a SET from today's meeting. = Originally, the event snytax that we brought to the table from the = Consent Receipts working group in Kantara was very explicitly a single = event being described. When RISC, OIDC sessions, and eventually SCIM = came to the conersation, the group decided to try out a way to express = multiple aspects of a single event in a single token. While I still = agree with this principle, I can see now that it's too much of a = temptation to express either multiple events or bend around the = semantics in ways that could cause a lot of confusion. I now think that = we should collapse the syntax as Annabelle has suggested and go even = further to specify what can go where. To wit, SET payload profiles = should only ever touch the things inside the event object. So I'm = proposing that we do something like this: >=20 >=20 > { > iss: <-- string representing the issuer of the SET itself > sub: <-- string representing the subject of the SET from the view of = the issuer (if known), no format assumed > iat: <-- timestamp of when the SET Was created, not to be confused = with the event time > aud: <-- array or string repreesnting the recipients of this SET, from = the view of the issuer of the sET > exp: <-- timestamp of when the SET shouldn't be processed anymore > event: { <-- object for the event itself, SET profiles do all of their = definitions in here > toe: <-- timestamp of the event, if known; if not present, event = time is unknown > iss: <-- issuer namespace for the subject of this event, as known = by the recipient > sub: <-- subject of the event, as known by the recipient, = namespaced by event.iss > txn: <-- transaction identifier for tying multiple events together > event_type: <-- URI representing this event's type, must be = understood by recipient (who can do a string match), can define other = additional fields and their semantics > } > } >=20 > And to Leif's point, to have a group event we would do: >=20 > event: { > event_type: urn:ietf:secevent:event_group > > events: [ <-- array of event objects with the semantics of the = regular event object, taken all at once; can re-use any of the root = event elements defined in SET but must not repeat any in the root = event's common attributes > ] > } >=20 > Event groups create some interop issues, as you need to have clients = that can handle events in a group as well as on their own. But with the = way people were describing event groups today, I think that's actually a = good thing -- it would force recognition of the associated nature of all = the components. If you get an event group, you need to understand = everything in the group. No primary/secondary, no pritical fields -- all = or nothing. >=20 > Yes this is a change from current syntax and semantics, but to me it = feels like a return to the consent receipt part of the roots. >=20 > -- Justin >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dy2OPleUr8EEEMvE= MVjHNWNm-dFJbnVcSztxsB-kpYFg&s=3DFZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD= -g&e=3D --Apple-Mail=_89FC8BFA-6FB2-4A35-94CE-A1F15F65FB93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii How do you propose to handle extensions of event uris?

    Phil

    Oracle Corporation, Identity Cloud = Services Architect
    @independentid
    www.independentid.com
    phil.hunt@oracle.com

    On Nov 14, 2017, at 2:21 AM, Justin Richer <jricher@mit.edu> = wrote:

    I wanted to take a few moments to get down on virtual-paper = some thoughts about the syntax and semantics of a SET from today's = meeting. Originally, the event snytax that we brought to the table from = the Consent Receipts working group in Kantara was very explicitly a = single event being described. When RISC, OIDC sessions, and eventually = SCIM came to the conersation, the group decided to try out a way to = express multiple aspects of a single event in a single token. While I = still agree with this principle, I can see now that it's too much of a = temptation to express either multiple events or bend around the = semantics in ways that could cause a lot of confusion. I now think that = we should collapse the syntax as Annabelle has suggested and go even = further to specify what can go where. To wit, SET payload profiles = should only ever touch the things inside the event object. So I'm = proposing that we do something like this:

    {
    iss: <-- string representing the issuer = of the SET itself
    sub: <-- string representing the = subject of the SET from the  view of the issuer (if known), no = format assumed
    iat: <-- timestamp of when the SET Was = created, not to be confused with the event time
    aud: = <-- array or string repreesnting the recipients of this SET, from the = view of the issuer of the sET
    exp: <-- timestamp of = when the SET shouldn't be processed anymore
    event: { = <-- object for the event itself, SET profiles do all of their = definitions in here
       toe: <-- = timestamp of the event, if known; if not present, event time is = unknown
       iss: <-- issuer namespace = for the subject of this event, as known by the recipient
    =    sub: <-- subject of the event, as known by the = recipient, namespaced by event.iss
       txn: = <-- transaction identifier for tying multiple events together
       event_type: <-- URI representing this = event's type, must be understood by recipient (who can do a string = match), can define other additional fields and their semantics
    }
    }

    And to Leif's = point, to have a group event we would do:

    event: {
     event_type: = urn:ietf:secevent:event_group
     <any event = attributes that are common to the whole set, like txn, toe, sub, = etc>
     events: [  <-- array of event = objects with the semantics of the regular event object, taken all at = once; can re-use any of the root event elements defined in SET but must = not repeat any in the root event's common attributes
    =   ]
    }

    Event groups = create some interop issues, as you need to have clients that can handle = events in a group as well as on their own. But with the way people were = describing event groups today, I think that's actually a good thing -- = it would force recognition of the associated nature of all the = components. If you get an event group, you need to understand everything = in the group. No primary/secondary, no pritical fields -- all or = nothing.

    Yes this is a change from current = syntax and semantics, but to me it feels like a return to the consent = receipt part of the roots.

    -- Justin


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4K= ZNA&m=3Dy2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=3DFZu1FlqDXh= YE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e=3D

    = --Apple-Mail=_89FC8BFA-6FB2-4A35-94CE-A1F15F65FB93-- From nobody Mon Nov 13 19:42:30 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13F41242EA for ; Mon, 13 Nov 2017 19:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Aoj7BHZorXl for ; Mon, 13 Nov 2017 19:42:26 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 3786F127517 for ; Mon, 13 Nov 2017 19:42:26 -0800 (PST) X-AuditID: 1209190e-b81ff700000027a3-0e-5a0a662083a6 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 48.58.10147.0266A0A5; Mon, 13 Nov 2017 22:42:25 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id vAE3gN76007001; Mon, 13 Nov 2017 22:42:24 -0500 Received: from [31.133.129.30] (dhcp-811e.meeting.ietf.org [31.133.129.30]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vAE3gH1N022859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Nov 2017 22:42:21 -0500 From: Justin Richer To: Phil Hunt CC: Date: Tue, 14 Nov 2017 11:42:16 +0800 Message-ID: <15fb89ecdc0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> In-Reply-To: <462D13E3-1D3E-45B8-AFC8-7CB91FDCF8A0@oracle.com> References: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <462D13E3-1D3E-45B8-AFC8-7CB91FDCF8A0@oracle.com> User-Agent: AquaMail/1.6.2.7 (build: 27000207) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------15fb89ed179d127101fcc7798" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixCmqrKuYxhVlcHc9u0XHgm4miwXzG9kd mDyWLPnJ5PHx6S2WAKYoLpuU1JzMstQifbsEroyNTS1sBS+rKzY0tLE2MC7N7GLk5JAQMJF4 03aHsYuRi0NIYDGTxIf+z2wQzkZGicM39jNDOCeYJA7eOM8K0sImoCoxfU0LE4gtIqAi8e3q daB2Dg5mAXGJK9+9QcIsQCXn/t4GK+cVcJeYcucyC4jNKWAn8XPCSTaQciGBaompvxlBwqIC ehJ3r0HYwgL2Esc+roNqFZQ4OfMJWCuzQLDEq1nnWCYw8s9CkpqFJDUL7Ahrib1f/CDC8hLN W2czQ9jaEmcOPGZCFl/AyLaKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11gvN7NELzWldBMjOKgl +XYwTmrwPsQowMGoxMPrcIUzSog1say4MvcQoyQHk5Ior8pn9ighvqT8lMqMxOKM+KLSnNTi Q4wSHMxKIrwhwVxRQrwpiZVVqUX5MClpDhYlcd5tQbsihQTSE0tSs1NTC1KLYLIyHBxKEryh qUCNgkWp6akVaZk5JQhpJg5OkOE8QMNfpIAMLy5IzC3OTIfIn2K05Nhw8+4fJo59YPLZzNcN zEIsefl5qVLivDUgQwVAGjJK8+BmgpKUfGuj3CtGcaAXhXmrQKp4gAkObuoroIVMQAulQD7l LS5JREhJNTDWCmxN+bOqcM7bd+8dNbskv/aacYgr7vj6u3TlZw2LCru8DxNMyqMOZ34/JvEi te3w/Abd56uKpxqtk3PqOrXxU+IGe8V83d5c0WkFrkcEzKbN8J/21rtm44e27gnWD5lmF95S 6/vMEpx6Nd7F/I9KQpG558Wr744WrZB6XhkobBPA3vl8WogSS3FGoqEWc1FxIgANdbcZLQMA AA== Archived-At: Subject: Re: [Id-event] Thoughts on Syntax from today's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 03:42:29 -0000 This is a multi-part message in MIME format. ------------15fb89ed179d127101fcc7798 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Extensions to event types just extend the event object itself. So each event type controls the namespace within its event object and can allow additional bits in it. So let's say you've got: event: { event_type: "foo:bar", foo: thing, bar: other-thing ... } And you want to extend "foo:bar" with the "foo:bar:baz" extension you could easily do something like: event: { event_type: "foo:bar", foo: thing, bar: other-thing, baz: extension-thing } Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You could alternatively have an "extensions" object, but that seems like overkill. JSON in practice is schema-by-fiat: you look for things you know and care about and ignore everything else. So extensions can just stack inside the event object, and multiple extensions to the same event type will already need to know to stay out of each others' way. -- Justin On November 14, 2017 10:35:51 AM Phil Hunt wrote: > How do you propose to handle extensions of event uris? > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com phil.hunt@oracle.com > >> On Nov 14, 2017, at 2:21 AM, Justin Richer wrote: >> >> I wanted to take a few moments to get down on virtual-paper some thoughts >> about the syntax and semantics of a SET from today's meeting. Originally, >> the event snytax that we brought to the table from the Consent Receipts >> working group in Kantara was very explicitly a single event being >> described. When RISC, OIDC sessions, and eventually SCIM came to the >> conersation, the group decided to try out a way to express multiple aspects >> of a single event in a single token. While I still agree with this >> principle, I can see now that it's too much of a temptation to express >> either multiple events or bend around the semantics in ways that could >> cause a lot of confusion. I now think that we should collapse the syntax as >> Annabelle has suggested and go even further to specify what can go where. >> To wit, SET payload profiles should only ever touch the things inside the >> event object. So I'm proposing that we do something like this: >> >> >> { >> iss: <-- string representing the issuer of the SET itself >> sub: <-- string representing the subject of the SET from the view of the >> issuer (if known), no format assumed >> iat: <-- timestamp of when the SET Was created, not to be confused with the >> event time >> aud: <-- array or string repreesnting the recipients of this SET, from the >> view of the issuer of the sET >> exp: <-- timestamp of when the SET shouldn't be processed anymore >> event: { <-- object for the event itself, SET profiles do all of their >> definitions in here >> toe: <-- timestamp of the event, if known; if not present, event time is >> unknown >> iss: <-- issuer namespace for the subject of this event, as known by the >> recipient >> sub: <-- subject of the event, as known by the recipient, namespaced by >> event.iss >> txn: <-- transaction identifier for tying multiple events together >> event_type: <-- URI representing this event's type, must be understood by >> recipient (who can do a string match), can define other additional fields >> and their semantics >> } >> } >> >> And to Leif's point, to have a group event we would do: >> >> event: { >> event_type: urn:ietf:secevent:event_group >> > etc> >> events: [ <-- array of event objects with the semantics of the regular >> event object, taken all at once; can re-use any of the root event elements >> defined in SET but must not repeat any in the root event's common attributes >> ] >> } >> >> Event groups create some interop issues, as you need to have clients that >> can handle events in a group as well as on their own. But with the way >> people were describing event groups today, I think that's actually a good >> thing -- it would force recognition of the associated nature of all the >> components. If you get an event group, you need to understand everything in >> the group. No primary/secondary, no pritical fields -- all or nothing. >> >> Yes this is a change from current syntax and semantics, but to me it feels >> like a return to the consent receipt part of the roots. >> >> -- Justin >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e= > ------------15fb89ed179d127101fcc7798 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

    Extensions to event types just extend the event object itself. So each event type controls the namespace within its event object and can allow additional bits in it. So let's say you've got:

    event: {
      event_type: "foo:bar",
      foo: thing,
      bar: other-thing
      ...
    }

    And you want to extend "foo:bar" with the "foo:bar:baz" extension you could easily do something like:

    event: {
      event_type: "foo:bar",
      foo: thing,
       bar: other-thing,
       baz: extension-thing
    }

    Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You could alternatively have an "extensions" object, but that seems like overkill. JSON in practice is schema-by-fiat: you look for things you know and care about and ignore everything else. So extensions can just stack inside the event object, and multiple extensions to the same event type will already need to know to stay out of each others' way.

    -- Justin

    On November 14, 2017 10:35:51 AM Phil Hunt <phil.hunt@oracle.com> wrote:

    How do you propose to handle extensions of event uris?

    Phil

    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    phil.hunt@oracle.com

    On Nov 14, 2017, at 2:21 AM, Justin Richer <jricher@mit.edu> wrote:

    I wanted to take a few moments to get down on virtual-paper some thoughts about the syntax and semantics of a SET from today's meeting. Originally, the event snytax that we brought to the table from the Consent Receipts working group in Kantara was very explicitly a single event being described. When RISC, OIDC sessions, and eventually SCIM came to the conersation, the group decided to try out a way to express multiple aspects of a single event in a single token. While I still agree with this principle, I can see now that it's too much of a temptation to express either multiple events or bend around the semantics in ways that could cause a lot of confusion. I now think that we should collapse the syntax as Annabelle has suggested and go even further to specify what can go where. To wit, SET payload profiles should only ever touch the things inside the event object. So I'm proposing that we do something like this:


    {
    iss: <-- string representing the issuer of the SET itself
    sub: <-- string representing the subject of the SET from the  view of the issuer (if known), no format assumed
    iat: <-- timestamp of when the SET Was created, not to be confused with the event time
    aud: <-- array or string repreesnting the recipients of this SET, from the view of the issuer of the sET
    exp: <-- timestamp of when the SET shouldn't be processed anymore
    event: { <-- object for the event itself, SET profiles do all of their definitions in here
       toe: <-- timestamp of the event, if known; if not present, event time is unknown
       iss: <-- issuer namespace for the subject of this event, as known by the recipient
       sub: <-- subject of the event, as known by the recipient, namespaced by event.iss
       txn: <-- transaction identifier for tying multiple events together
       event_type: <-- URI representing this event's type, must be understood by recipient (who can do a string match), can define other additional fields and their semantics
    }
    }

    And to Leif's point, to have a group event we would do:

    event: {
     event_type: urn:ietf:secevent:event_group
     <any event attributes that are common to the whole set, like txn, toe, sub, etc>
     events: [  <-- array of event objects with the semantics of the regular event object, taken all at once; can re-use any of the root event elements defined in SET but must not repeat any in the root event's common attributes
      ]
    }

    Event groups create some interop issues, as you need to have clients that can handle events in a group as well as on their own. But with the way people were describing event groups today, I think that's actually a good thing -- it would force recognition of the associated nature of all the components. If you get an event group, you need to understand everything in the group. No primary/secondary, no pritical fields -- all or nothing.

    Yes this is a change from current syntax and semantics, but to me it feels like a return to the consent receipt part of the roots.

    -- Justin


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e=

    ------------15fb89ed179d127101fcc7798-- From nobody Mon Nov 13 19:45:24 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F18B126C2F for ; Mon, 13 Nov 2017 19:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no 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 B9hsLaZDc4CJ for ; Mon, 13 Nov 2017 19:45:21 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F6F1242EA for ; Mon, 13 Nov 2017 19:45:21 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id d9so22509404qtd.7 for ; Mon, 13 Nov 2017 19:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3ZyVBKHkE+IcmDgTtyfzOqvyl9PQpcxs6H9+V1KsEP0=; b=NsJrlMZ/+m/+y/dVKfa3CAS9d6h3XXA5cWlmAqGN47F0ODwbHcEMuBF3Zgs0M9pamC houaAQR/65m6qo/6n7xzmTOrM+F7tUm/6QwAK1OcYx6OnfLPBQOUGvz8V+HKJefHhvfD jDPL58nj3lxhAVlHKbflS2u0LIt8F5FpRQvhy6PJvgqCvOmqrkY5/T5UCeNMx4gyoA9r xhcS3XmDkzEGZr9RNnFXMCew/D0qYt7osv+b44LKM6Xggz3HxWkHRitaQ9ic5TLRtmcj 0g4GBIQf+/Dm77rMb48ViZ+SBcayy5ZjEfRvTBd3QFk7QzsB/+FQaUhnUHFqDP6wSxcy P5Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3ZyVBKHkE+IcmDgTtyfzOqvyl9PQpcxs6H9+V1KsEP0=; b=FjwMk5zKmYeJX801lAH19HpbBCNnoD51rxYL9NAK5fEqSpjZhPTdSv1BR9xR5Jzk6l INWPN5AulxCuzA+cU8F8oLWb7yMoOY36bUPCw3NgFx5LeiL8h20pynQhQSmDJKX2sYT9 t7fmVrcU+0AA89pa7gHhYABDPzOJ1/RvY+h0y+k2/yP0oFdPXDZHmNvKCyc96XnWAf80 YTGR8Iwuyle9kdbaF48uv4nUXjiZhrHrA1MDESNBVXWJ3sE9yoklkyTZdDTnbLGBM1z0 XHWSTym0VZM8oSy5VC5GhV6h5aHNBhqU1hwm++8r5SBhSUZfW6mO1WKKps1704+IrlQH gPWQ== X-Gm-Message-State: AJaThX6BERxKVTS80ZSxqaNtYhjrA0dSbgMFveOmYyPWzRyeP7LWWyZT n0pyYznW9GD4Cz/5OWqA/Nomabloxr4Zsx6mOZoJJKGQPXQ= X-Google-Smtp-Source: AGs4zMayHKj/q0TpiUQhKqB5JO4w31lvmJEv6UgYw5UdcjUjJVwBB4aaDQXAh7Eu03i2bL8FPUM7uNMXtEftj8mPxWA= X-Received: by 10.13.227.68 with SMTP id m65mr7119493ywe.387.1510631119954; Mon, 13 Nov 2017 19:45:19 -0800 (PST) MIME-Version: 1.0 From: Luke Camery Date: Tue, 14 Nov 2017 03:45:09 +0000 Message-ID: To: id-event@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0767a24b5fdf055de937d2" Archived-At: Subject: [Id-event] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 03:45:23 -0000 --94eb2c0767a24b5fdf055de937d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *Future Meetings* Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative SET Proposal Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane Friday - 10:00-18:00 at Google Singapore (70 Pasir Panjang Road, #03-71, 117371) on Work Session --=20 * =E2=80=A2 **Luke Camery* * =E2=80=A2 *Associate Product Manager * =E2=80=A2 *Federated Identity --94eb2c0767a24b5fdf055de937d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Future Meetings
    Wednesday - 10:30-12:00 i= n Butterworth on Annabelle's Alternative SET Proposal
    Thursday - 15= :30-18:00 in the Atrium on Marius' Control Plane
    Friday - 10:= 00-18:00 at Google Singapore (70 Pasir Panja= ng Road, #03-71, 117371) on Work Session

    --=
    <= tr style=3D"margin:0px;padding:0px;border:0px;height:48px"> --94eb2c0767a24b5fdf055de937d2-- From nobody Mon Nov 13 19:48:50 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC96126C2F for ; Mon, 13 Nov 2017 19:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 aJ2FQoHJ4WUE for ; Mon, 13 Nov 2017 19:48:38 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 A7D8B1242EA for ; Mon, 13 Nov 2017 19:48:38 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vAE3mbc9018431 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 14 Nov 2017 03:48:37 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vAE3maWp003983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 14 Nov 2017 03:48:37 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vAE3maHw003681; Tue, 14 Nov 2017 03:48:36 GMT Received: from [31.133.150.167] (/31.133.150.167) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Nov 2017 19:48:36 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-AE5858FE-441B-4D83-ACB0-1B2465A4E941 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14G60) In-Reply-To: <15fb89ecdc0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> Date: Tue, 14 Nov 2017 11:48:31 +0800 Cc: id-event@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <7D702F36-AA0E-44A2-9838-A86524C96CDA@oracle.com> References: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <462D13E3-1D3E-45B8-AFC8-7CB91FDCF8A0@oracle.com> <15fb89ecdc0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> To: Justin Richer X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Id-event] Thoughts on Syntax from today's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 03:48:41 -0000 --Apple-Mail-AE5858FE-441B-4D83-ACB0-1B2465A4E941 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I worry this causes potential namespace conflicts.=20 I see complexity if each profile defines the method differently. Which under= mines the value for the new proposal over the existing one.=20 I would like to see an extension mechanism that is standard for set as part o= f the new proposal. =20 Phil > On Nov 14, 2017, at 11:42 AM, Justin Richer wrote: >=20 > Extensions to event types just extend the event object itself. So each eve= nt type controls the namespace within its event object and can allow additio= nal bits in it. So let's say you've got: >=20 > event: { > event_type: "foo:bar", > foo: thing, > bar: other-thing > ... > } >=20 > And you want to extend "foo:bar" with the "foo:bar:baz" extension you coul= d easily do something like: >=20 > event: { > event_type: "foo:bar", > foo: thing, > bar: other-thing, > baz: extension-thing > } >=20 > Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You co= uld alternatively have an "extensions" object, but that seems like overkill.= JSON in practice is schema-by-fiat: you look for things you know and care a= bout and ignore everything else. So extensions can just stack inside the eve= nt object, and multiple extensions to the same event type will already need t= o know to stay out of each others' way. >=20 > -- Justin >> On November 14, 2017 10:35:51 AM Phil Hunt wrote: >>=20 >> How do you propose to handle extensions of event uris? >>=20 >> Phil >>=20 >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On Nov 14, 2017, at 2:21 AM, Justin Richer wrote: >>>=20 >>> I wanted to take a few moments to get down on virtual-paper some thought= s about the syntax and semantics of a SET from today's meeting. Originally, t= he event snytax that we brought to the table from the Consent Receipts worki= ng group in Kantara was very explicitly a single event being described. When= RISC, OIDC sessions, and eventually SCIM came to the conersation, the group= decided to try out a way to express multiple aspects of a single event in a= single token. While I still agree with this principle, I can see now that i= t's too much of a temptation to express either multiple events or bend aroun= d the semantics in ways that could cause a lot of confusion. I now think tha= t we should collapse the syntax as Annabelle has suggested and go even furth= er to specify what can go where. To wit, SET payload profiles should only ev= er touch the things inside the event object. So I'm proposing that we do som= ething like this: >>>=20 >>>=20 >>> { >>> iss: <-- string representing the issuer of the SET itself >>> sub: <-- string representing the subject of the SET from the view of th= e issuer (if known), no format assumed >>> iat: <-- timestamp of when the SET Was created, not to be confused with t= he event time >>> aud: <-- array or string repreesnting the recipients of this SET, from t= he view of the issuer of the sET >>> exp: <-- timestamp of when the SET shouldn't be processed anymore >>> event: { <-- object for the event itself, SET profiles do all of their d= efinitions in here >>> toe: <-- timestamp of the event, if known; if not present, event time= is unknown >>> iss: <-- issuer namespace for the subject of this event, as known by t= he recipient >>> sub: <-- subject of the event, as known by the recipient, namespaced b= y event.iss >>> txn: <-- transaction identifier for tying multiple events together >>> event_type: <-- URI representing this event's type, must be understoo= d by recipient (who can do a string match), can define other additional fiel= ds and their semantics >>> } >>> } >>>=20 >>> And to Leif's point, to have a group event we would do: >>>=20 >>> event: { >>> event_type: urn:ietf:secevent:event_group >>> >>> events: [ <-- array of event objects with the semantics of the regular= event object, taken all at once; can re-use any of the root event elements d= efined in SET but must not repeat any in the root event's common attributes >>> ] >>> } >>>=20 >>> Event groups create some interop issues, as you need to have clients tha= t can handle events in a group as well as on their own. But with the way peo= ple were describing event groups today, I think that's actually a good thing= -- it would force recognition of the associated nature of all the component= s. If you get an event group, you need to understand everything in the group= . No primary/secondary, no pritical fields -- all or nothing. >>>=20 >>> Yes this is a change from current syntax and semantics, but to me it fee= ls like a return to the consent receipt part of the roots. >>>=20 >>> -- Justin >>>=20 >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dy2OPleUr8EEEMvEMV= jHNWNm-dFJbnVcSztxsB-kpYFg&s=3DFZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e= =3D >>=20 --Apple-Mail-AE5858FE-441B-4D83-ACB0-1B2465A4E941 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    I worry this causes potential namespac= e conflicts. 

    I see complexity if each profile defines the method diff= erently. Which undermines the value for the new proposal over the existing o= ne. 

    I would like to see an extension mechanism that is standard for s= et as part of the new proposal.  

    Phil

    On Nov 14, 2= 017, at 11:42 AM, Justin Richer <jrich= er@mit.edu> wrote:

    Extensions to event types just= extend the event object itself. So each event type controls the namespace within its event object and can allow additional bits in it. So let's say you've got:

    event: {
      event_type: "foo:bar",
      foo: thing,
      bar: other-thing
      ...
    }

    And you want to extend "foo:bar" with the "foo:bar:baz" extension you could easily do something like:

    event: {
      event_type: "foo:bar",
      foo: thing,
       bar: other-thing,
       baz: extension-thing
    }

    Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You could alternatively have an "extensions" object, but that seems like overkill. JSON in practice is schema-by-fiat: you look for things you know and care about and ignore everything else. So extensions can just stack inside the event object, and multiple extensions to the same event type will already need to know to stay out of each others' way.

    -- Justin

    On November 14, 2017 10:35:51 AM Phil Hunt <phil.hunt@oracle.com> wrote:

    How do you propose to handle extensions of event uris?

    Phil

    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    www.independentid.com
    phil.hunt@oracle.com
    <= /div>

    On N= ov 14, 2017, at 2:21 AM, Justin Richer <jricher@mit.edu> wrote:

    I wanted to take a few moments to get down on virtual-paper some thoughts about the syntax and semantics of a SET from today's meeting. Originally, the event snytax that we brought to the table from the Consent Receipts working group in Kantara was very explicitly a single event being described. When RISC, OIDC sessions, and eventually SCIM came to the conersation, the group decided to try out a way to express multiple aspects of a single event in a single token. While I still agree with this principle, I can see now that it's too much of a temptation to express either multiple events or bend around the semantics in ways that could cause a lot of confusion. I now think that we should collapse the syntax as Annabelle has suggested and go even further to specify what can go where. To wit, SET payload profiles should only ever touch the things inside the event object. So I'm proposing that we do something like this:


    = {
    iss: <-- string representing the issuer of the SET itsel= f
    sub: <-- string representing the subject of the SET from= the  view of the issuer (if known), no format assumed
    iat: <-- timestamp of when the SET Was created, not to be confused with the event time
    aud: <-- array or string repreesnting the recipients of this SET, from the view of the issuer of the sET
    exp: <-- timestamp of when the SET shouldn't be processed anymore
    event: { <-- object for the event itself, SET profiles do all of their definitions in here
       toe: <-- timestamp of the event, if known; if not present, event time is unknown
       iss: <-- issuer namespace for the subject of= this event, as known by the recipient
       sub: <-- subject of the event, as known by the recipient, namespaced by event.iss
       txn: <-- transaction identifie= r for tying multiple events together
       event_type: <-- URI representing this event's type, must be understood by recipient (who can do a string match), can define other additional fields and their semantics
    }
    }=

    And to Leif's point, to have a group event we w= ould do:

    event: {
     event_type: urn:ietf:secevent:event_group
     <any event attributes that are common to the whole set, like txn, toe, sub, etc>
    =  events: [  <-- array of event objects with the semantics of the regular event object, taken all at once; can re-use any of the root event elements defined in SET but must not repeat any in the root event's common attributes
      ]
    }

    Event groups create some interop issues, as you need to have= clients that can handle events in a group as well as on their own. But with the way people were describing event groups today, I think that's actually a good thing -- it would force recognition of the associated nature of all the components. If you get an event group, you need to understand everything in the group. No primary/secondary, no pritical fields -- all or nothing.

    Yes this is a change from current synt= ax and semantics, but to me it feels like a return to the consent receipt part of the roots.

    -- Justin


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZ= h8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&am= p;m=3Dy2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=3DFZu1FlqDXhYE2GzdLP= FsbjYGIS8UW9CdLs_wOOdcD-g&e=3D

    = --Apple-Mail-AE5858FE-441B-4D83-ACB0-1B2465A4E941-- From nobody Mon Nov 13 19:49:28 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A075D126C2F for ; Mon, 13 Nov 2017 19:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNtMdxJNNrYs for ; Mon, 13 Nov 2017 19:49:22 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 4F03B12944C for ; Mon, 13 Nov 2017 19:49:22 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id j28so11105606pfk.8 for ; Mon, 13 Nov 2017 19:49:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WvFJTqQK7syF2P6FhpLOD0CN6r2Y+EeVNexe3/1AJr8=; b=P0OqPQWOPAzjFl25cTySOtuGxFNBiFVk+Jx9BFU+0X/OnFcd9l4rXVm6fBkYgvT2/p EbpArmH8/GUg1Kgqq3SG8zgLsh9rappYqj9bNQDEjedWgJCIXe5R84FwdtMnGrUByTJx 7hOpg4oqXCsqhvSn1iIOC+RIzkVnmhxrrmFci3SnIDY7D6Af/81UUUYaTPd0FPBLb1g6 1ck1M7szZzo9R6BIQw6VAF99LlIANMaa0mlhtE4sHZjXsyS76uYJ16dVA+jkEhoHW+te d0Z6qTWz1nlJb/nze18srjfgB2ihnDtXmJKEqGceRXHoF6CgSvYg8Z/yCWcoIS8/+I9e 5vTg== 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=WvFJTqQK7syF2P6FhpLOD0CN6r2Y+EeVNexe3/1AJr8=; b=m43aa0ugJ9VkqFsxa0LTO9SoQx0KodJVFg4SpS3zu4QPlAkb3FxHemj5BZcp1kAh7X yr3GslYMND4ERwnMZeDw19F2/pTnDqDsuJOWxppQzBQfHa8IEzQYWfZbKKaGXc61WrGN H3T5v7uwo5qoQwRnruITBkDJHj/JVmwctoVZt7LunifigeeblNJDVbHAV8FsbC3nK0xz 7XdGbtSE+w2S2+nQH8Ko2becyb6v83eDUisRMvtj17bJ58dZjhdlZJ1R8NKLrvKNuT9I 0Y24J5mmpwndU2Cwj/0WQB/jJ7mN4o7tz7OxerwDed68iFywzBEceJAi0OpPKwK13nha boMQ== X-Gm-Message-State: AJaThX5ZMI5dDKeKOzf7+Hu4x9LvWbB94hG5AokPA6/24yFp0v/427Qj uaVJtzOVWbEM0W1JGBKR45uGIpcn0fJzutrpXHs= X-Google-Smtp-Source: AGs4zMav/YboAJycySr33YOyLt/bWMRst7fjU0IQZgfAQmGMef1ePV/Cb/4ubb5l2dgVTxpEmhV1p+nr7nawdxpvXF4= X-Received: by 10.98.189.23 with SMTP id a23mr12288089pff.124.1510631361771; Mon, 13 Nov 2017 19:49:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.128.78 with HTTP; Mon, 13 Nov 2017 19:49:01 -0800 (PST) In-Reply-To: <15fb89ecdc0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> References: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <462D13E3-1D3E-45B8-AFC8-7CB91FDCF8A0@oracle.com> <15fb89ecdc0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> From: Dick Hardt Date: Tue, 14 Nov 2017 11:49:01 +0800 Message-ID: To: Justin Richer Cc: Phil Hunt , SecEvent Content-Type: multipart/alternative; boundary="f403043bc9c4b47df3055de9457f" Archived-At: Subject: Re: [Id-event] Thoughts on Syntax from today's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 03:49:27 -0000 --f403043bc9c4b47df3055de9457f Content-Type: text/plain; charset="UTF-8" Justin: you have "sub" above the event, and within the event. I think there are different values, but it is not clear. On Tue, Nov 14, 2017 at 11:42 AM, Justin Richer wrote: > Extensions to event types just extend the event object itself. So each > event type controls the namespace within its event object and can allow > additional bits in it. So let's say you've got: > > event: { > event_type: "foo:bar", > foo: thing, > bar: other-thing > ... > } > > And you want to extend "foo:bar" with the "foo:bar:baz" extension you > could easily do something like: > > event: { > event_type: "foo:bar", > foo: thing, > bar: other-thing, > baz: extension-thing > } > > Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You > could alternatively have an "extensions" object, but that seems like > overkill. JSON in practice is schema-by-fiat: you look for things you know > and care about and ignore everything else. So extensions can just stack > inside the event object, and multiple extensions to the same event type > will already need to know to stay out of each others' way. > > -- Justin > > On November 14, 2017 10:35:51 AM Phil Hunt wrote: > >> How do you propose to handle extensions of event uris? >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> On Nov 14, 2017, at 2:21 AM, Justin Richer wrote: >> >> I wanted to take a few moments to get down on virtual-paper some thoughts >> about the syntax and semantics of a SET from today's meeting. Originally, >> the event snytax that we brought to the table from the Consent Receipts >> working group in Kantara was very explicitly a single event being >> described. When RISC, OIDC sessions, and eventually SCIM came to the >> conersation, the group decided to try out a way to express multiple aspects >> of a single event in a single token. While I still agree with this >> principle, I can see now that it's too much of a temptation to express >> either multiple events or bend around the semantics in ways that could >> cause a lot of confusion. I now think that we should collapse the syntax as >> Annabelle has suggested and go even further to specify what can go where. >> To wit, SET payload profiles should only ever touch the things inside the >> event object. So I'm proposing that we do something like this: >> >> >> { >> iss: <-- string representing the issuer of the SET itself >> sub: <-- string representing the subject of the SET from the view of the >> issuer (if known), no format assumed >> iat: <-- timestamp of when the SET Was created, not to be confused with >> the event time >> aud: <-- array or string repreesnting the recipients of this SET, from >> the view of the issuer of the sET >> exp: <-- timestamp of when the SET shouldn't be processed anymore >> event: { <-- object for the event itself, SET profiles do all of their >> definitions in here >> toe: <-- timestamp of the event, if known; if not present, event time >> is unknown >> iss: <-- issuer namespace for the subject of this event, as known by >> the recipient >> sub: <-- subject of the event, as known by the recipient, namespaced >> by event.iss >> txn: <-- transaction identifier for tying multiple events together >> event_type: <-- URI representing this event's type, must be understood >> by recipient (who can do a string match), can define other additional >> fields and their semantics >> } >> } >> >> And to Leif's point, to have a group event we would do: >> >> event: { >> event_type: urn:ietf:secevent:event_group >> > sub, etc> >> events: [ <-- array of event objects with the semantics of the regular >> event object, taken all at once; can re-use any of the root event elements >> defined in SET but must not repeat any in the root event's common attributes >> ] >> } >> >> Event groups create some interop issues, as you need to have clients that >> can handle events in a group as well as on their own. But with the way >> people were describing event groups today, I think that's actually a good >> thing -- it would force recognition of the associated nature of all the >> components. If you get an event group, you need to understand everything in >> the group. No primary/secondary, no pritical fields -- all or nothing. >> >> Yes this is a change from current syntax and semantics, but to me it >> feels like a return to the consent receipt part of the roots. >> >> -- Justin >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www. >> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c= >> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r= >> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm- >> dFJbnVcSztxsB-kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e= >> >> >> > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > -- Subscribe to the HARDTWARE mail list to learn about projects I am working on! --f403043bc9c4b47df3055de9457f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Justin: you have "sub" above the event, and with= in the event. I think there are different values, but it is not clear.
    =

    O= n Tue, Nov 14, 2017 at 11:42 AM, Justin Richer <jricher@mit.edu> wrote:

    Extensions to event types just extend the event object itself. So each event type controls the namespace within its event object and can allow additional bits in it. So let's s= ay you've got:

    event: {
    =C2=A0 event_type: "foo:bar",
    =C2=A0 foo: thing,
    =C2=A0 bar: other-thing
    =C2=A0 ...
    }

    And you want to extend "foo:bar" with the "foo:bar:baz" extension you could ea= sily do something like:

    event: {
    =C2=A0 event_type: "foo:bar",
    =C2=A0 foo: thing,
    =C2=A0=C2=A0 bar: other-thing,
    =C2=A0=C2=A0 baz: extension-thing
    }

    Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You could altern= atively have an "extensions" object, but that seems like overkill. JSON in practi= ce is schema-by-fiat: you look for things you know and care about and ignore everything else. So extensions can just stack inside the event object, and multiple extensions to the same event type will already need to know to stay out of each others' way.

    -- Justin

    On November 14, 2017 10:35:51 AM Phil Hunt <phil.hunt@oracle.com> wrote:

    How do you propose to handle extensions of event uris?

    <= div>
    Phil

    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    phil.hu= nt@oracle.com

    On Nov 14, 2017, at 2:21 AM, Justin Richer <jricher@mit.edu> wrote:

    I wanted to take a few moments to get down on virtual-paper some thoughts about the syntax and semantics of a SET from today's meeting. Originally, the eve= nt snytax that we brought to the table from the Consent Receipts working group in Kantara was very explicitly a single event being described. When RISC, OIDC sessions, and eventually SCIM came to the conersation, the group decided to try out a way to express multiple aspects of a single event in a single token. While I still agree with this principle, I can see now that it's too much of a temptation to express either multiple events or bend around the semantics in ways that could cause a lot of confusion. I now think that we should collapse the syntax as Annabelle has suggested and go even further to specify what can go where. To wit, SET payload profiles should only ever touch the things inside the event object. So I'm propo= sing that we do something like this:


    {
    iss: <-- string represe= nting the issuer of the SET itself
    sub: <-- string representing the = subject of the SET from the =C2=A0view of the issuer (if known), no format assumed
    iat: <-- timestamp of when the SET Was created, not to be confused with the event time
    aud: <-- array or string repreesnting the recipients of this SET, from the view of the issuer of the sET
    exp: <-- timestamp of when the SET shouldn't be processed anymore event: { <-- object for the event itself, SET profiles do all of their definitions in here
    =C2=A0=C2=A0=C2=A0toe: <-- timestamp of the event, if known; if not present, event time is unknown
    = =C2=A0=C2=A0=C2=A0iss: <-- issuer namespace for the subject of this event, as known by the recipient
    =C2=A0=C2=A0=C2=A0sub: <-- subject of the event, as known by the recipient, namespaced by event.iss
    =C2=A0=C2=A0=C2=A0txn: <-- transaction identifier for tying multiple events together
    =C2=A0=C2=A0=C2=A0event_type: <-- URI representing this event's type= , must be understood by recipient (who can do a string match), can define other additional fields and their semantics
    }
    }

    And to Leif&#= 39;s point, to have a group event we would do:

    event: {
    =C2=A0event_type: urn:ietf:secevent:event_group
    =C2=A0<any event attributes that are common to the whole set, like txn, toe, sub, etc>
    =C2=A0events: [ =C2=A0<-- array of event objects with the semantics of the regular event object, taken all at once; can re-use any of the root event elements defined in SET but must not repeat any in the root event'= ;s common attributes
    =C2=A0=C2=A0]
    }

    Event groups create some in= terop issues, as you need to have clients that can handle events in a group as well as on their own. But with the way people were describing event groups today, I think that's actua= lly a good thing -- it would force recognition of the associated nature of all the components. If you get an event group, you need to understand everything in the group. No primary/secondary, no pritical fields -- all or nothing.

    Yes this is a change from current syntax and semantics, but to me it feels like a return to the consent receipt part of the roots.

    -- Justin


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://urldefense.proofpoint.com/= v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&= ;d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&a= mp;r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dy= 2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=3DFZu1FlqDXhYE2G= zdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e=3D


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    =
    Subscribe to the HARDTWARE mail list to learn abou= t projects I am working on!
    --f403043bc9c4b47df3055de9457f-- From nobody Mon Nov 13 20:11:15 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824811271DF for ; Mon, 13 Nov 2017 20:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.82 X-Spam-Level: X-Spam-Status: No, score=-11.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 Kqmdl4cldfj9 for ; Mon, 13 Nov 2017 20:11:12 -0800 (PST) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199681243F6 for ; Mon, 13 Nov 2017 20:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1510632672; x=1542168672; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=V+UTlAc+/KL3Y3eN3btOIrti04gfFLCXWtApSTmqn+Y=; b=owTqKFWrSTpbqTG0Li8PAPBiYZot6N4POvCodQYdj6ItG23mPcSlli5x ks9c/LHQCfBeJcY3YGVmiQCpjkUXBbLfaVgDwGRFOMlNTdg+bfKvRJkBD 46/gGSQ6ZmKKuDKQsTKepcihS5rhNg6GWtJTQHl1l2nuI+83xPvvT9qhm 4=; X-IronPort-AV: E=Sophos;i="5.44,392,1505779200"; d="scan'208,217";a="701971531" Received: from sea3-co-svc-lb6-vlan2.sea.amazon.com (HELO email-inbound-relay-2c-a11fcaa7.us-west-2.amazon.com) ([10.47.22.34]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Nov 2017 04:11:10 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2c-a11fcaa7.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id vAE4BAQc092558 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Nov 2017 04:11:10 GMT Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 14 Nov 2017 04:11:10 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 14 Nov 2017 04:11:10 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Tue, 14 Nov 2017 04:11:09 +0000 From: "Richard Backman, Annabelle" To: Luke Camery CC: "id-event@ietf.org" Thread-Topic: [Id-event] Plan for the Week Thread-Index: AQHTXPskQaYCyhQCoEykaMol5jZbbKMTQz2B Date: Tue, 14 Nov 2017 04:11:09 +0000 Message-ID: <75369D63-0131-4719-881C-CB06D9D399EC@amazon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_75369D6301314719881CCB06D9D399ECamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Id-event] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 04:11:14 -0000 --_000_75369D6301314719881CCB06D9D399ECamazoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Correction: the Wednesday meeting is from 10:30 to 12:30. Sent from my iPhone On Nov 14, 2017, at 11:46 AM, Luke Camery > wrote: Future Meetings Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative SET Propo= sal Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane Friday - 10:00-18:00 at Google Singapore (70 Pasir Panjang Road, #03-71, 11= 7371) on Work Session -- [http://i.imgur.com/Ya4Rhss.gif] * Luke Camery * Associate Product Manager * Federated Identity _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event --_000_75369D6301314719881CCB06D9D399ECamazoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Correction: the Wednesday meeting is from 10:30 to 12:30.

    Sent from my iPhone

    On Nov 14, 2017, at 11:46 AM, Luke Camery <lcamery@google.com> wrote:

    Future Meetings
    Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative SET Propo= sal
    Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane
    Friday - 10:00-18:00 at Google Singapore (70 Pasir Panjang Road, #03-71, 117371) on Work Session

    --
    =C2=A0 =E2=80=A2 =C2=A0Luke Camery
    =C2=A0 =E2=80=A2 =C2=A0Associate Product Manager=
    =C2=A0 = =E2=80=A2 =C2=A0Federated Identity
     = •  Luke Camery
      •  Associate Product Manager
      ̶= 6;  Federated Identity
    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://ww= w.ietf.org/mailman/listinfo/id-event
    --_000_75369D6301314719881CCB06D9D399ECamazoncom_-- From nobody Mon Nov 13 21:10:58 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C1E1288B8 for ; Mon, 13 Nov 2017 21:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 3o7vwUsh-YFK for ; Mon, 13 Nov 2017 21:10:55 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 2C7C81286C7 for ; Mon, 13 Nov 2017 21:10:55 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vAE5AsXn012639 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 14 Nov 2017 05:10:54 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vAE5Arhh010365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 14 Nov 2017 05:10:53 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vAE5Aqju015464; Tue, 14 Nov 2017 05:10:53 GMT Received: from [31.133.150.167] (/31.133.150.167) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Nov 2017 21:10:52 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-6B62A9DD-212B-4381-A80F-2F6BC423C86C Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14G60) In-Reply-To: <7D702F36-AA0E-44A2-9838-A86524C96CDA@oracle.com> Date: Tue, 14 Nov 2017 13:10:46 +0800 Cc: id-event@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <462D13E3-1D3E-45B8-AFC8-7CB91FDCF8A0@oracle.com> <15fb89ecdc0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <7D702F36-AA0E-44A2-9838-A86524C96CDA@oracle.com> To: Justin Richer X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [Id-event] Thoughts on Syntax from today's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 05:10:57 -0000 --Apple-Mail-6B62A9DD-212B-4381-A80F-2F6BC423C86C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I withdraw my concern about extensions.=20 Extensions can be added to grouping event type just like we did for events. T= hat means any one can extend any event, even risc. Same outcome just an extr= a level of json for those of us who need it.=20 Phil > On Nov 14, 2017, at 11:48 AM, Phil Hunt (IDM) wrote= : >=20 > I worry this causes potential namespace conflicts.=20 >=20 > I see complexity if each profile defines the method differently. Which und= ermines the value for the new proposal over the existing one.=20 >=20 > I would like to see an extension mechanism that is standard for set as par= t of the new proposal. =20 >=20 > Phil >=20 >> On Nov 14, 2017, at 11:42 AM, Justin Richer wrote: >>=20 >> Extensions to event types just extend the event object itself. So each ev= ent type controls the namespace within its event object and can allow additi= onal bits in it. So let's say you've got: >>=20 >> event: { >> event_type: "foo:bar", >> foo: thing, >> bar: other-thing >> ... >> } >>=20 >> And you want to extend "foo:bar" with the "foo:bar:baz" extension you cou= ld easily do something like: >>=20 >> event: { >> event_type: "foo:bar", >> foo: thing, >> bar: other-thing, >> baz: extension-thing >> } >>=20 >> Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You c= ould alternatively have an "extensions" object, but that seems like overkill= . JSON in practice is schema-by-fiat: you look for things you know and care a= bout and ignore everything else. So extensions can just stack inside the eve= nt object, and multiple extensions to the same event type will already need t= o know to stay out of each others' way. >>=20 >> -- Justin >>> On November 14, 2017 10:35:51 AM Phil Hunt wrote:= >>>=20 >>> How do you propose to handle extensions of event uris? >>>=20 >>> Phil >>>=20 >>> Oracle Corporation, Identity Cloud Services Architect >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>> On Nov 14, 2017, at 2:21 AM, Justin Richer wrote: >>>>=20 >>>> I wanted to take a few moments to get down on virtual-paper some though= ts about the syntax and semantics of a SET from today's meeting. Originally,= the event snytax that we brought to the table from the Consent Receipts wor= king group in Kantara was very explicitly a single event being described. Wh= en RISC, OIDC sessions, and eventually SCIM came to the conersation, the gro= up decided to try out a way to express multiple aspects of a single event in= a single token. While I still agree with this principle, I can see now that= it's too much of a temptation to express either multiple events or bend aro= und the semantics in ways that could cause a lot of confusion. I now think t= hat we should collapse the syntax as Annabelle has suggested and go even fur= ther to specify what can go where. To wit, SET payload profiles should only e= ver touch the things inside the event object. So I'm proposing that we do so= mething like this: >>>>=20 >>>>=20 >>>> { >>>> iss: <-- string representing the issuer of the SET itself >>>> sub: <-- string representing the subject of the SET from the view of t= he issuer (if known), no format assumed >>>> iat: <-- timestamp of when the SET Was created, not to be confused with= the event time >>>> aud: <-- array or string repreesnting the recipients of this SET, from t= he view of the issuer of the sET >>>> exp: <-- timestamp of when the SET shouldn't be processed anymore >>>> event: { <-- object for the event itself, SET profiles do all of their d= efinitions in here >>>> toe: <-- timestamp of the event, if known; if not present, event tim= e is unknown >>>> iss: <-- issuer namespace for the subject of this event, as known by= the recipient >>>> sub: <-- subject of the event, as known by the recipient, namespaced= by event.iss >>>> txn: <-- transaction identifier for tying multiple events together >>>> event_type: <-- URI representing this event's type, must be understo= od by recipient (who can do a string match), can define other additional fie= lds and their semantics >>>> } >>>> } >>>>=20 >>>> And to Leif's point, to have a group event we would do: >>>>=20 >>>> event: { >>>> event_type: urn:ietf:secevent:event_group >>>> >>>> events: [ <-- array of event objects with the semantics of the regula= r event object, taken all at once; can re-use any of the root event elements= defined in SET but must not repeat any in the root event's common attribute= s >>>> ] >>>> } >>>>=20 >>>> Event groups create some interop issues, as you need to have clients th= at can handle events in a group as well as on their own. But with the way pe= ople were describing event groups today, I think that's actually a good thin= g -- it would force recognition of the associated nature of all the componen= ts. If you get an event group, you need to understand everything in the grou= p. No primary/secondary, no pritical fields -- all or nothing. >>>>=20 >>>> Yes this is a change from current syntax and semantics, but to me it fe= els like a return to the consent receipt part of the roots. >>>>=20 >>>> -- Justin >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65e= apI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dy2OPleUr8EEEMvEM= VjHNWNm-dFJbnVcSztxsB-kpYFg&s=3DFZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&= e=3D >>>=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI= _JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DxKhV2MrBhCnkvNpmfi1= YxQW93GgUhANRCR8Cv0CbVtk&s=3Do2UMy3X8NKTXg2j84FbImFb6F7V2QrPxTkiVslrpUXE&e=3D= --Apple-Mail-6B62A9DD-212B-4381-A80F-2F6BC423C86C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    I withdraw my concern about extensions= . 

    Extensions can be added to grouping event type just like we did for= events. That means any one can extend any event, even risc. Same outcome ju= st an extra level of json for those of us who need it. 

    Phil

    On Nov 14, 2017, at 11:48 AM, Ph= il Hunt (IDM) <phil.hunt@oracle.c= om> wrote:

    I worry this= causes potential namespace conflicts. 

    I see complexity if each profi= le defines the method differently. Which undermines the value for the new pr= oposal over the existing one. 

    =
    I would like to see an extension mechan= ism that is standard for set as part of the new proposal.  

    Phil=

    On Nov 14, 2017, at 11:42 AM, Justin Richer <jricher@mit.edu> wrote:

    Extensions to event types just= extend the event object itself. So each event type controls the namespace within its event object and can allow additional bits in it. So let's say you've got:

    event: {
      event_type: "foo:bar",
      foo: thing,
      bar: other-thing
      ...
    }

    And you want to extend "foo:bar" with the "foo:bar:baz" extension you could easily do something like:

    event: {
      event_type: "foo:bar",
      foo: thing,
       bar: other-thing,
       baz: extension-thing
    }

    Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You could alternatively have an "extensions" object, but that seems like overkill. JSON in practice is schema-by-fiat: you look for things you know and care about and ignore everything else. So extensions can just stack inside the event object, and multiple extensions to the same event type will already need to know to stay out of each others' way.

    -- Justin

    On November 14, 2017 10:35:51 AM Phil Hunt <phil.hunt@oracle.com> wrote:

    How do you propose to handle extensions of event uris?

    Phil

    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    www.independentid.com
    phil.hunt@oracle.com
    <= /div>

    On N= ov 14, 2017, at 2:21 AM, Justin Richer <jricher@mit.edu> wrote:

    I wanted to take a few moments to get down on virtual-paper some thoughts about the syntax and semantics of a SET from today's meeting. Originally, the event snytax that we brought to the table from the Consent Receipts working group in Kantara was very explicitly a single event being described. When RISC, OIDC sessions, and eventually SCIM came to the conersation, the group decided to try out a way to express multiple aspects of a single event in a single token. While I still agree with this principle, I can see now that it's too much of a temptation to express either multiple events or bend around the semantics in ways that could cause a lot of confusion. I now think that we should collapse the syntax as Annabelle has suggested and go even further to specify what can go where. To wit, SET payload profiles should only ever touch the things inside the event object. So I'm proposing that we do something like this:


    = {
    iss: <-- string representing the issuer of the SET itsel= f
    sub: <-- string representing the subject of the SET from= the  view of the issuer (if known), no format assumed
    iat: <-- timestamp of when the SET Was created, not to be confused with the event time
    aud: <-- array or string repreesnting the recipients of this SET, from the view of the issuer of the sET
    exp: <-- timestamp of when the SET shouldn't be processed anymore
    event: { <-- object for the event itself, SET profiles do all of their definitions in here
       toe: <-- timestamp of the event, if known; if not present, event time is unknown
       iss: <-- issuer namespace for the subject of= this event, as known by the recipient
       sub: <-- subject of the event, as known by the recipient, namespaced by event.iss
       txn: <-- transaction identifie= r for tying multiple events together
       event_type: <-- URI representing this event's type, must be understood by recipient (who can do a string match), can define other additional fields and their semantics
    }
    }=

    And to Leif's point, to have a group event we w= ould do:

    event: {
     event_type: urn:ietf:secevent:event_group
     <any event attributes that are common to the whole set, like txn, toe, sub, etc>
    =  events: [  <-- array of event objects with the semantics of the regular event object, taken all at once; can re-use any of the root event elements defined in SET but must not repeat any in the root event's common attributes
      ]
    }

    Event groups create some interop issues, as you need to have= clients that can handle events in a group as well as on their own. But with the way people were describing event groups today, I think that's actually a good thing -- it would force recognition of the associated nature of all the components. If you get an event group, you need to understand everything in the group. No primary/secondary, no pritical fields -- all or nothing.

    Yes this is a change from current synt= ax and semantics, but to me it feels like a return to the consent receipt part of the roots.

    -- Justin


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZ= h8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&am= p;m=3Dy2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=3DFZu1FlqDXhYE2GzdLP= FsbjYGIS8UW9CdLs_wOOdcD-g&e=3D

    = --Apple-Mail-6B62A9DD-212B-4381-A80F-2F6BC423C86C-- From nobody Mon Nov 13 21:36:38 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F98E126DCA for ; Mon, 13 Nov 2017 21:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 D2JeJv2UN6TF for ; Mon, 13 Nov 2017 21:36:34 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34CA71201FA for ; Mon, 13 Nov 2017 21:36:34 -0800 (PST) X-AuditID: 12074425-14dff700000030f2-40-5a0a80de126a Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id BC.61.12530.FD08A0A5; Tue, 14 Nov 2017 00:36:32 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id vAE5aQZ6031713; Tue, 14 Nov 2017 00:36:28 -0500 Received: from [31.133.129.30] (dhcp-811e.meeting.ietf.org [31.133.129.30]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vAE5aK6h020848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Nov 2017 00:36:24 -0500 From: Justin Richer To: "Phil Hunt (IDM)" CC: Date: Tue, 14 Nov 2017 13:36:19 +0800 Message-ID: <15fb9073838.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> In-Reply-To: <7D702F36-AA0E-44A2-9838-A86524C96CDA@oracle.com> References: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <462D13E3-1D3E-45B8-AFC8-7CB91FDCF8A0@oracle.com> <15fb89ecdc0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <7D702F36-AA0E-44A2-9838-A86524C96CDA@oracle.com> User-Agent: AquaMail/1.6.2.7 (build: 27000207) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------15fb9073b53d1271013c1a53a" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixG6novuggSvKYPZbCYuOBd1MFgvmN7I7 MHksWfKTyePj01ssAUxRXDYpqTmZZalF+nYJXBkbD1xiK7gyhbFi0UyFBsZPdV2MnBwSAiYS d55dZO5i5OIQEljMJDH/agMbhLORUeLL/t3MIFVCAieYJA50coHYbAKqEtPXtDCB2CICOhIL 7t1l72Lk4GAWEJe48t0bJMwCVHJg33sWEJtXwF1i1YyLTCAlnAJ2El//qkKMf8so8eL9FkaQ GlEBPYm7136D2cIC9hLHPq5jhegVlDg58wnYHGaBYIneb0tYJjDyz0KSmoUkNQvsCmuJvV/8 IMLyEs1bZzND2NoSZw48ZkIWX8DItopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXQi83s0QvNaV0 EyM4qF1UdzDO+et1iFGAg1GJh/fFRc4oIdbEsuLK3EOMkhxMSqK8Kp/Zo4T4kvJTKjMSizPi i0pzUosPMUpwMCuJ8IYEc0UJ8aYkVlalFuXDpKQ5WJTEebcF7YoUEkhPLEnNTk0tSC2Cycpw cChJ8O6tB2oULEpNT61Iy8wpQUgzcXCCDOcBGl4GUsNbXJCYW5yZDpE/xWjJseHm3T9MHPvA 5LOZrxuYhVjy8vNSpcR5F4E0CIA0ZJTmwc0EJSn51ka5V4ziQC8K8+4EqeIBJji4qa+AFjIB LZQC+ZS3uCQRISXVwBgj7GXicy5h6h3LU4yJu/apRky+uCqid3JGrNWrzLhjPK/eb435wHnH YcKex4Ipwuav+35Vr22xZIy9tuSywGyhbrf2qP4kOY6g4roIH9HLNanrra4Gr9/0K9Lohm/I /Vszz0+oeb0xQTVJXWfikub+YwfNNk08m8dz5bRU9IMsbT/b+pt9+kosxRmJhlrMRcWJABK/ gHAtAwAA Archived-At: Subject: Re: [Id-event] Thoughts on Syntax from today's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 05:36:37 -0000 This is a multi-part message in MIME format. ------------15fb9073b53d1271013c1a53a Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit It ultimately is up to the extensions of a given event type to stay out of each other's way. I think the best thing for us would be to provide guidance. I don't think it's going to be a problem in practice as it's unlikely that two extensions to the same event type will be mutually unaware of each other. On November 14, 2017 11:48:48 AM "Phil Hunt (IDM)" wrote: > I worry this causes potential namespace conflicts. > > I see complexity if each profile defines the method differently. Which > undermines the value for the new proposal over the existing one. > > I would like to see an extension mechanism that is standard for set as part > of the new proposal. > > Phil > >> On Nov 14, 2017, at 11:42 AM, Justin Richer wrote: >> >> Extensions to event types just extend the event object itself. So each >> event type controls the namespace within its event object and can allow >> additional bits in it. So let's say you've got: >> >> event: { >> event_type: "foo:bar", >> foo: thing, >> bar: other-thing >> ... >> } >> >> And you want to extend "foo:bar" with the "foo:bar:baz" extension you could >> easily do something like: >> >> event: { >> event_type: "foo:bar", >> foo: thing, >> bar: other-thing, >> baz: extension-thing >> } >> >> Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You >> could alternatively have an "extensions" object, but that seems like >> overkill. JSON in practice is schema-by-fiat: you look for things you know >> and care about and ignore everything else. So extensions can just stack >> inside the event object, and multiple extensions to the same event type >> will already need to know to stay out of each others' way. >> >> -- Justin >>> On November 14, 2017 10:35:51 AM Phil Hunt wrote: >>> >>> How do you propose to handle extensions of event uris? >>> >>> Phil >>> >>> Oracle Corporation, Identity Cloud Services Architect >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>>> On Nov 14, 2017, at 2:21 AM, Justin Richer wrote: >>>> >>>> I wanted to take a few moments to get down on virtual-paper some thoughts >>>> about the syntax and semantics of a SET from today's meeting. Originally, >>>> the event snytax that we brought to the table from the Consent Receipts >>>> working group in Kantara was very explicitly a single event being >>>> described. When RISC, OIDC sessions, and eventually SCIM came to the >>>> conersation, the group decided to try out a way to express multiple aspects >>>> of a single event in a single token. While I still agree with this >>>> principle, I can see now that it's too much of a temptation to express >>>> either multiple events or bend around the semantics in ways that could >>>> cause a lot of confusion. I now think that we should collapse the syntax as >>>> Annabelle has suggested and go even further to specify what can go where. >>>> To wit, SET payload profiles should only ever touch the things inside the >>>> event object. So I'm proposing that we do something like this: >>>> >>>> >>>> { >>>> iss: <-- string representing the issuer of the SET itself >>>> sub: <-- string representing the subject of the SET from the view of the >>>> issuer (if known), no format assumed >>>> iat: <-- timestamp of when the SET Was created, not to be confused with the >>>> event time >>>> aud: <-- array or string repreesnting the recipients of this SET, from the >>>> view of the issuer of the sET >>>> exp: <-- timestamp of when the SET shouldn't be processed anymore >>>> event: { <-- object for the event itself, SET profiles do all of their >>>> definitions in here >>>> toe: <-- timestamp of the event, if known; if not present, event time is >>>> unknown >>>> iss: <-- issuer namespace for the subject of this event, as known by the >>>> recipient >>>> sub: <-- subject of the event, as known by the recipient, namespaced by >>>> event.iss >>>> txn: <-- transaction identifier for tying multiple events together >>>> event_type: <-- URI representing this event's type, must be understood by >>>> recipient (who can do a string match), can define other additional fields >>>> and their semantics >>>> } >>>> } >>>> >>>> And to Leif's point, to have a group event we would do: >>>> >>>> event: { >>>> event_type: urn:ietf:secevent:event_group >>>> >>> etc> >>>> events: [ <-- array of event objects with the semantics of the regular >>>> event object, taken all at once; can re-use any of the root event elements >>>> defined in SET but must not repeat any in the root event's common attributes >>>> ] >>>> } >>>> >>>> Event groups create some interop issues, as you need to have clients that >>>> can handle events in a group as well as on their own. But with the way >>>> people were describing event groups today, I think that's actually a good >>>> thing -- it would force recognition of the associated nature of all the >>>> components. If you get an event group, you need to understand everything in >>>> the group. No primary/secondary, no pritical fields -- all or nothing. >>>> >>>> Yes this is a change from current syntax and semantics, but to me it feels >>>> like a return to the consent receipt part of the roots. >>>> >>>> -- Justin >>>> >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e= >>> ------------15fb9073b53d1271013c1a53a Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

    It ultimately is up to the extensions of a given event type to stay out of each other's way. I think the best thing for us would be to provide guidance. I don't think it's going to be a problem in practice as it's unlikely that two extensions to the same event type will be mutually unaware of each other.

    On November 14, 2017 11:48:48 AM "Phil Hunt (IDM)" <phil.hunt@oracle.com> wrote:

    I worry this causes potential namespace conflicts. 

    I see complexity if each profile defines the method differently. Which undermines the value for the new proposal over the existing one. 

    I would like to see an extension mechanism that is standard for set as part of the new proposal.  

    Phil

    On Nov 14, 2017, at 11:42 AM, Justin Richer <jricher@mit.edu> wrote:

    Extensions to event types just extend the event object itself. So each event type controls the namespace within its event object and can allow additional bits in it. So let's say you've got:

    event: {
      event_type: "foo:bar",
      foo: thing,
      bar: other-thing
      ...
    }

    And you want to extend "foo:bar" with the "foo:bar:baz" extension you could easily do something like:

    event: {
      event_type: "foo:bar",
      foo: thing,
       bar: other-thing,
       baz: extension-thing
    }

    Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You could alternatively have an "extensions" object, but that seems like overkill. JSON in practice is schema-by-fiat: you look for things you know and care about and ignore everything else. So extensions can just stack inside the event object, and multiple extensions to the same event type will already need to know to stay out of each others' way.

    -- Justin

    On November 14, 2017 10:35:51 AM Phil Hunt <phil.hunt@oracle.com> wrote:

    How do you propose to handle extensions of event uris?

    Phil

    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    phil.hunt@oracle.com

    On Nov 14, 2017, at 2:21 AM, Justin Richer <jricher@mit.edu> wrote:

    I wanted to take a few moments to get down on virtual-paper some thoughts about the syntax and semantics of a SET from today's meeting. Originally, the event snytax that we brought to the table from the Consent Receipts working group in Kantara was very explicitly a single event being described. When RISC, OIDC sessions, and eventually SCIM came to the conersation, the group decided to try out a way to express multiple aspects of a single event in a single token. While I still agree with this principle, I can see now that it's too much of a temptation to express either multiple events or bend around the semantics in ways that could cause a lot of confusion. I now think that we should collapse the syntax as Annabelle has suggested and go even further to specify what can go where. To wit, SET payload profiles should only ever touch the things inside the event object. So I'm proposing that we do something like this:


    {
    iss: <-- string representing the issuer of the SET itself
    sub: <-- string representing the subject of the SET from the  view of the issuer (if known), no format assumed
    iat: <-- timestamp of when the SET Was created, not to be confused with the event time
    aud: <-- array or string repreesnting the recipients of this SET, from the view of the issuer of the sET
    exp: <-- timestamp of when the SET shouldn't be processed anymore
    event: { <-- object for the event itself, SET profiles do all of their definitions in here
       toe: <-- timestamp of the event, if known; if not present, event time is unknown
       iss: <-- issuer namespace for the subject of this event, as known by the recipient
       sub: <-- subject of the event, as known by the recipient, namespaced by event.iss
       txn: <-- transaction identifier for tying multiple events together
       event_type: <-- URI representing this event's type, must be understood by recipient (who can do a string match), can define other additional fields and their semantics
    }
    }

    And to Leif's point, to have a group event we would do:

    event: {
     event_type: urn:ietf:secevent:event_group
     <any event attributes that are common to the whole set, like txn, toe, sub, etc>
     events: [  <-- array of event objects with the semantics of the regular event object, taken all at once; can re-use any of the root event elements defined in SET but must not repeat any in the root event's common attributes
      ]
    }

    Event groups create some interop issues, as you need to have clients that can handle events in a group as well as on their own. But with the way people were describing event groups today, I think that's actually a good thing -- it would force recognition of the associated nature of all the components. If you get an event group, you need to understand everything in the group. No primary/secondary, no pritical fields -- all or nothing.

    Yes this is a change from current syntax and semantics, but to me it feels like a return to the consent receipt part of the roots.

    -- Justin


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e=

    ------------15fb9073b53d1271013c1a53a-- From nobody Mon Nov 13 21:38:55 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EEA126D46 for ; Mon, 13 Nov 2017 21:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 dgfz1aBoifFa for ; Mon, 13 Nov 2017 21:38:51 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 CA2671201FA for ; Mon, 13 Nov 2017 21:38:50 -0800 (PST) X-AuditID: 1209190f-da3ff70000002a96-2b-5a0a8168018b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id AE.F1.10902.9618A0A5; Tue, 14 Nov 2017 00:38:49 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id vAE5ciZE032048; Tue, 14 Nov 2017 00:38:46 -0500 Received: from [31.133.129.30] (dhcp-811e.meeting.ietf.org [31.133.129.30]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vAE5ccEn021240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Nov 2017 00:38:42 -0500 From: Justin Richer To: Dick Hardt CC: Phil Hunt , SecEvent Date: Tue, 14 Nov 2017 13:38:37 +0800 Message-ID: <15fb9095348.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> In-Reply-To: References: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <462D13E3-1D3E-45B8-AFC8-7CB91FDCF8A0@oracle.com> <15fb89ecdc0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> User-Agent: AquaMail/1.6.2.7 (build: 27000207) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------15fb9095599d127102056a9e" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsUixG6nopvZyBVl8HStksXjmUUWHQu6mSwW zG9kd2D22DnrLrvHkiU/mTw+Pr3FEsAcxWWTkpqTWZZapG+XwJXR+2c9e8HcHsaKvbePsjcw tlR2MXJySAiYSMy6u4iti5GLQ0hgMZPEklMvGCGcjYwS79/9ZoVwTjBJrP/znxmkhU1AVWL6 mhYmEFsEyD5wtoUFxGYWcJI4cO0eWJwFKH6m9SYbiM0r4C7x6NADsF5OgUCJbSfmQg1tYJKY 8fEuWLOogJ7E3Wu/GUFsYQF7iWMf17FCNAtKnJz5BKiGA2hBkETPBNYJjPyzkGRmIWQgTGuJ vV/8ZoEdJC/RvHU2M4StLXHmwGMmZPEFjGyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE30cjNL 9FJTSjcxgkKdU5J/B+OcBu9DjAIcjEo8vA5XOKOEWBPLiitzDzFKcjApifKqfGaPEuJLyk+p zEgszogvKs1JLT7EKMHBrCTCGxLMFSXEm5JYWZValA+TkuZgURLn3Ra0K1JIID2xJDU7NbUg tQgmK8PBoSTBW90A1ChYlJqeWpGWmVOCkGbi4AQZzgM0vKweZHhxQWJucWY6RP4Uoz3HgQlX /jBxbLh5F0juA5PPZr5uYBZiycvPS5US540HGS0A0pZRmgc3GZTG5Fsb5V4xigM9KsybC1LF A0yBcLNfAa1lAlorBfIvb3FJIkJKqoExMO7QnhvsHrcq5CXmXdRbpbDBcXrxvKY74lnnPO4d +xD3/+Z04yX2r7m/emxw5wjKeszmobvDl7N8zY3WaV9/cN1a5nshtPr69jM6LjsO/6p60byu rDxqjejHfRZ/jfjud34/3rmoXmPHs5hb/SaKol9q1RektqnO/LNLXag69PUHLaXqTaL3lFiK MxINtZiLihMBatATkT4DAAA= Archived-At: Subject: Re: [Id-event] Thoughts on Syntax from today's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 05:38:53 -0000 This is a multi-part message in MIME format. ------------15fb9095599d127102056a9e Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Yes, they're intended to be potentially different values but could be the same in some circumstances. Syntactically, one is "sub" and the other is "event.sub". I'd be perfectly happy renaming the "event.sub" claim to "event.event_sub" or something, and I think the "risc_subject" with an object type is also perfectly reasonable as it's providing data beyond what the regular "event.sub" would do (as a string). Semantically, "sub" is from the perspective of the issuer of the SET and "event.sub" is the perspective of the receiver of the SET. -- Justin On November 14, 2017 11:49:27 AM Dick Hardt wrote: > Justin: you have "sub" above the event, and within the event. I think there > are different values, but it is not clear. > > > On Tue, Nov 14, 2017 at 11:42 AM, Justin Richer wrote: > >> Extensions to event types just extend the event object itself. So each >> event type controls the namespace within its event object and can allow >> additional bits in it. So let's say you've got: >> >> event: { >> event_type: "foo:bar", >> foo: thing, >> bar: other-thing >> ... >> } >> >> And you want to extend "foo:bar" with the "foo:bar:baz" extension you >> could easily do something like: >> >> event: { >> event_type: "foo:bar", >> foo: thing, >> bar: other-thing, >> baz: extension-thing >> } >> >> Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You >> could alternatively have an "extensions" object, but that seems like >> overkill. JSON in practice is schema-by-fiat: you look for things you know >> and care about and ignore everything else. So extensions can just stack >> inside the event object, and multiple extensions to the same event type >> will already need to know to stay out of each others' way. >> >> -- Justin >> >> On November 14, 2017 10:35:51 AM Phil Hunt wrote: >> >>> How do you propose to handle extensions of event uris? >>> >>> Phil >>> >>> Oracle Corporation, Identity Cloud Services Architect >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> On Nov 14, 2017, at 2:21 AM, Justin Richer wrote: >>> >>> I wanted to take a few moments to get down on virtual-paper some thoughts >>> about the syntax and semantics of a SET from today's meeting. Originally, >>> the event snytax that we brought to the table from the Consent Receipts >>> working group in Kantara was very explicitly a single event being >>> described. When RISC, OIDC sessions, and eventually SCIM came to the >>> conersation, the group decided to try out a way to express multiple aspects >>> of a single event in a single token. While I still agree with this >>> principle, I can see now that it's too much of a temptation to express >>> either multiple events or bend around the semantics in ways that could >>> cause a lot of confusion. I now think that we should collapse the syntax as >>> Annabelle has suggested and go even further to specify what can go where. >>> To wit, SET payload profiles should only ever touch the things inside the >>> event object. So I'm proposing that we do something like this: >>> >>> >>> { >>> iss: <-- string representing the issuer of the SET itself >>> sub: <-- string representing the subject of the SET from the view of the >>> issuer (if known), no format assumed >>> iat: <-- timestamp of when the SET Was created, not to be confused with >>> the event time >>> aud: <-- array or string repreesnting the recipients of this SET, from >>> the view of the issuer of the sET >>> exp: <-- timestamp of when the SET shouldn't be processed anymore >>> event: { <-- object for the event itself, SET profiles do all of their >>> definitions in here >>> toe: <-- timestamp of the event, if known; if not present, event time >>> is unknown >>> iss: <-- issuer namespace for the subject of this event, as known by >>> the recipient >>> sub: <-- subject of the event, as known by the recipient, namespaced >>> by event.iss >>> txn: <-- transaction identifier for tying multiple events together >>> event_type: <-- URI representing this event's type, must be understood >>> by recipient (who can do a string match), can define other additional >>> fields and their semantics >>> } >>> } >>> >>> And to Leif's point, to have a group event we would do: >>> >>> event: { >>> event_type: urn:ietf:secevent:event_group >>> >> sub, etc> >>> events: [ <-- array of event objects with the semantics of the regular >>> event object, taken all at once; can re-use any of the root event elements >>> defined in SET but must not repeat any in the root event's common attributes >>> ] >>> } >>> >>> Event groups create some interop issues, as you need to have clients that >>> can handle events in a group as well as on their own. But with the way >>> people were describing event groups today, I think that's actually a good >>> thing -- it would force recognition of the associated nature of all the >>> components. If you get an event group, you need to understand everything in >>> the group. No primary/secondary, no pritical fields -- all or nothing. >>> >>> Yes this is a change from current syntax and semantics, but to me it >>> feels like a return to the consent receipt part of the roots. >>> >>> -- Justin >>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www. >>> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c= >>> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r= >>> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm- >>> dFJbnVcSztxsB-kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e= >>> >>> >>> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> > > > -- > Subscribe to the HARDTWARE mail list to learn about > projects I am working on! ------------15fb9095599d127102056a9e Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

    Yes, they're intended to be potentially different values but could be the same in some circumstances. Syntactically, one is "sub" and the other is "event.sub".  I'd be perfectly happy renaming the "event.sub" claim to "event.event_sub" or something, and I think the "risc_subject" with an object type is also perfectly reasonable as it's providing data beyond what the regular "event.sub" would do (as a string). Semantically, "sub" is from the perspective of the issuer of the SET and "event.sub" is the perspective of the receiver of the SET.

    -- Justin

    On November 14, 2017 11:49:27 AM Dick Hardt <dick.hardt@gmail.com> wrote:

    Justin: you have "sub" above the event, and within the event. I think there are different values, but it is not clear.


    On Tue, Nov 14, 2017 at 11:42 AM, Justin Richer <jricher@mit.edu> wrote:

    Extensions to event types just extend the event object itself. So each event type controls the namespace within its event object and can allow additional bits in it. So let's say you've got:

    event: {
      event_type: "foo:bar",
      foo: thing,
      bar: other-thing
      ...
    }

    And you want to extend "foo:bar" with the "foo:bar:baz" extension you could easily do something like:

    event: {
      event_type: "foo:bar",
      foo: thing,
       bar: other-thing,
       baz: extension-thing
    }

    Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You could alternatively have an "extensions" object, but that seems like overkill. JSON in practice is schema-by-fiat: you look for things you know and care about and ignore everything else. So extensions can just stack inside the event object, and multiple extensions to the same event type will already need to know to stay out of each others' way.

    -- Justin

    On November 14, 2017 10:35:51 AM Phil Hunt <phil.hunt@oracle.com> wrote:

    How do you propose to handle extensions of event uris?

    Phil

    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    phil.hunt@oracle.com

    On Nov 14, 2017, at 2:21 AM, Justin Richer <jricher@mit.edu> wrote:

    I wanted to take a few moments to get down on virtual-paper some thoughts about the syntax and semantics of a SET from today's meeting. Originally, the event snytax that we brought to the table from the Consent Receipts working group in Kantara was very explicitly a single event being described. When RISC, OIDC sessions, and eventually SCIM came to the conersation, the group decided to try out a way to express multiple aspects of a single event in a single token. While I still agree with this principle, I can see now that it's too much of a temptation to express either multiple events or bend around the semantics in ways that could cause a lot of confusion. I now think that we should collapse the syntax as Annabelle has suggested and go even further to specify what can go where. To wit, SET payload profiles should only ever touch the things inside the event object. So I'm proposing that we do something like this:


    {
    iss: <-- string representing the issuer of the SET itself
    sub: <-- string representing the subject of the SET from the  view of the issuer (if known), no format assumed
    iat: <-- timestamp of when the SET Was created, not to be confused with the event time
    aud: <-- array or string repreesnting the recipients of this SET, from the view of the issuer of the sET
    exp: <-- timestamp of when the SET shouldn't be processed anymore
    event: { <-- object for the event itself, SET profiles do all of their definitions in here
       toe: <-- timestamp of the event, if known; if not present, event time is unknown
       iss: <-- issuer namespace for the subject of this event, as known by the recipient
       sub: <-- subject of the event, as known by the recipient, namespaced by event.iss
       txn: <-- transaction identifier for tying multiple events together
       event_type: <-- URI representing this event's type, must be understood by recipient (who can do a string match), can define other additional fields and their semantics
    }
    }

    And to Leif's point, to have a group event we would do:

    event: {
     event_type: urn:ietf:secevent:event_group
     <any event attributes that are common to the whole set, like txn, toe, sub, etc>
     events: [  <-- array of event objects with the semantics of the regular event object, taken all at once; can re-use any of the root event elements defined in SET but must not repeat any in the root event's common attributes
      ]
    }

    Event groups create some interop issues, as you need to have clients that can handle events in a group as well as on their own. But with the way people were describing event groups today, I think that's actually a good thing -- it would force recognition of the associated nature of all the components. If you get an event group, you need to understand everything in the group. No primary/secondary, no pritical fields -- all or nothing.

    Yes this is a change from current syntax and semantics, but to me it feels like a return to the consent receipt part of the roots.

    -- Justin


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e=


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    Subscribe to the HARDTWARE mail list to learn about projects I am working on!
    ------------15fb9095599d127102056a9e-- From nobody Mon Nov 13 21:44:08 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694991270A7 for ; Mon, 13 Nov 2017 21:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 w-CaDwZdn7xJ for ; Mon, 13 Nov 2017 21:44:04 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E40171201FA for ; Mon, 13 Nov 2017 21:44:03 -0800 (PST) X-AuditID: 12074422-89bff70000003a4a-81-5a0a82a0812f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id FF.F1.14922.1A28A0A5; Tue, 14 Nov 2017 00:44:02 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id vAE5htHD031824; Tue, 14 Nov 2017 00:43:57 -0500 Received: from [31.133.129.30] (dhcp-811e.meeting.ietf.org [31.133.129.30]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vAE5hnsQ022410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Nov 2017 00:43:53 -0500 From: Justin Richer To: "Phil Hunt (IDM)" CC: Date: Tue, 14 Nov 2017 13:43:48 +0800 Message-ID: <15fb90e1220.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> In-Reply-To: References: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <462D13E3-1D3E-45B8-AFC8-7CB91FDCF8A0@oracle.com> <15fb89ecdc0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <7D702F36-AA0E-44A2-9838-A86524C96CDA@oracle.com> User-Agent: AquaMail/1.6.2.7 (build: 27000207) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------15fb90e1612d127103fb92fb3" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixG6nrruoiSvKYPcfRouOBd1MFgvmN7I7 MHksWfKTyePj01ssAUxRXDYpqTmZZalF+nYJXBlzrvxjLFi/nLFiQ+cL1gbGeRMYuxg5OSQE TCRmdc5g6mLk4hASWMwk0TX9LyOEs5FRYufbbUwgVUICJ5gkTrfLg9hsAqoS09e0gMVFBHQk Fty7y97FyMHBLCAuceW7N0iYBahkztl77CA2r4C7RNOaN2wgNqeAnUTn7UNsEPMXMkn8753A CpIQFdCTuHvtN9hFwgL2Esc+rmOFaBaUODnzCQvE/GCJp201Exj5ZyHJzELIQJjWEnu/+IFU MAvISzRvnc0MYWtLnDnwmAlZfAEj2ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdU73czBK91JTS TYzgsHZR2sE48Z/XIUYBDkYlHl6HK5xRQqyJZcWVuYcYJTmYlER5VT6zRwnxJeWnVGYkFmfE F5XmpBYfYpTgYFYS4Q0J5ooS4k1JrKxKLcqHSUlzsCiJ824L2hUpJJCeWJKanZpakFoEk5Xh 4FCS4F3TCNQoWJSanlqRlplTgpBm4uAEGc4DNFwGpIa3uCAxtzgzHSJ/itGSY8PNu3+YOPaB yWczXzcwC7Hk5eelSonzvmgAahAAacgozYObCUpT8q2Ncq8YxYFeFOadDTKWB5ji4Ka+AlrI BLRQCuRT3uKSRISUVANjTdz/omh+o835/SIzOdvd++ZdSynUOt3RcNpfQmZ99Xd3L9+lToGt u9nduxRWvApt5dk8ddaO08uXbTr/8kPj+S+J6zeKb1vrxbinp3dm7pMk3fb9Roqc9srG+ut+ T6tcbGJ1o3FWhp7m5o0mKscMfYXXtL9zj1ow59NZ2YL5H9Zw7p/c4CmrxFKckWioxVxUnAgA MPGhbC4DAAA= Archived-At: Subject: Re: [Id-event] Thoughts on Syntax from today's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 05:44:06 -0000 This is a multi-part message in MIME format. ------------15fb90e1612d127103fb92fb3 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Yes, if you want your extensions to have their own full object structure and have it be completely separate, you can use the group syntax. I think you can also, with this syntax, have a simpler extension mechanism that says "just add the 'baz' field into the exsting event object and it means 'qux'". -- Justin On November 14, 2017 1:11:04 PM "Phil Hunt (IDM)" wrote: > I withdraw my concern about extensions. > > Extensions can be added to grouping event type just like we did for events. > That means any one can extend any event, even risc. Same outcome just an > extra level of json for those of us who need it. > > Phil > >> On Nov 14, 2017, at 11:48 AM, Phil Hunt (IDM) wrote: >> >> I worry this causes potential namespace conflicts. >> >> I see complexity if each profile defines the method differently. Which >> undermines the value for the new proposal over the existing one. >> >> I would like to see an extension mechanism that is standard for set as part >> of the new proposal. >> >> Phil >> >>> On Nov 14, 2017, at 11:42 AM, Justin Richer wrote: >>> >>> Extensions to event types just extend the event object itself. So each >>> event type controls the namespace within its event object and can allow >>> additional bits in it. So let's say you've got: >>> >>> event: { >>> event_type: "foo:bar", >>> foo: thing, >>> bar: other-thing >>> ... >>> } >>> >>> And you want to extend "foo:bar" with the "foo:bar:baz" extension you could >>> easily do something like: >>> >>> event: { >>> event_type: "foo:bar", >>> foo: thing, >>> bar: other-thing, >>> baz: extension-thing >>> } >>> >>> Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You >>> could alternatively have an "extensions" object, but that seems like >>> overkill. JSON in practice is schema-by-fiat: you look for things you know >>> and care about and ignore everything else. So extensions can just stack >>> inside the event object, and multiple extensions to the same event type >>> will already need to know to stay out of each others' way. >>> >>> -- Justin >>>> On November 14, 2017 10:35:51 AM Phil Hunt wrote: >>>> >>>> How do you propose to handle extensions of event uris? >>>> >>>> Phil >>>> >>>> Oracle Corporation, Identity Cloud Services Architect >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>>> On Nov 14, 2017, at 2:21 AM, Justin Richer wrote: >>>>> >>>>> I wanted to take a few moments to get down on virtual-paper some thoughts >>>>> about the syntax and semantics of a SET from today's meeting. Originally, >>>>> the event snytax that we brought to the table from the Consent Receipts >>>>> working group in Kantara was very explicitly a single event being >>>>> described. When RISC, OIDC sessions, and eventually SCIM came to the >>>>> conersation, the group decided to try out a way to express multiple aspects >>>>> of a single event in a single token. While I still agree with this >>>>> principle, I can see now that it's too much of a temptation to express >>>>> either multiple events or bend around the semantics in ways that could >>>>> cause a lot of confusion. I now think that we should collapse the syntax as >>>>> Annabelle has suggested and go even further to specify what can go where. >>>>> To wit, SET payload profiles should only ever touch the things inside the >>>>> event object. So I'm proposing that we do something like this: >>>>> >>>>> >>>>> { >>>>> iss: <-- string representing the issuer of the SET itself >>>>> sub: <-- string representing the subject of the SET from the view of the >>>>> issuer (if known), no format assumed >>>>> iat: <-- timestamp of when the SET Was created, not to be confused with the >>>>> event time >>>>> aud: <-- array or string repreesnting the recipients of this SET, from the >>>>> view of the issuer of the sET >>>>> exp: <-- timestamp of when the SET shouldn't be processed anymore >>>>> event: { <-- object for the event itself, SET profiles do all of their >>>>> definitions in here >>>>> toe: <-- timestamp of the event, if known; if not present, event time is >>>>> unknown >>>>> iss: <-- issuer namespace for the subject of this event, as known by the >>>>> recipient >>>>> sub: <-- subject of the event, as known by the recipient, namespaced by >>>>> event.iss >>>>> txn: <-- transaction identifier for tying multiple events together >>>>> event_type: <-- URI representing this event's type, must be understood by >>>>> recipient (who can do a string match), can define other additional fields >>>>> and their semantics >>>>> } >>>>> } >>>>> >>>>> And to Leif's point, to have a group event we would do: >>>>> >>>>> event: { >>>>> event_type: urn:ietf:secevent:event_group >>>>> >>>> etc> >>>>> events: [ <-- array of event objects with the semantics of the regular >>>>> event object, taken all at once; can re-use any of the root event elements >>>>> defined in SET but must not repeat any in the root event's common attributes >>>>> ] >>>>> } >>>>> >>>>> Event groups create some interop issues, as you need to have clients that >>>>> can handle events in a group as well as on their own. But with the way >>>>> people were describing event groups today, I think that's actually a good >>>>> thing -- it would force recognition of the associated nature of all the >>>>> components. If you get an event group, you need to understand everything in >>>>> the group. No primary/secondary, no pritical fields -- all or nothing. >>>>> >>>>> Yes this is a change from current syntax and semantics, but to me it feels >>>>> like a return to the consent receipt part of the roots. >>>>> >>>>> -- Justin >>>>> >>>>> >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e= >>>> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xKhV2MrBhCnkvNpmfi1YxQW93GgUhANRCR8Cv0CbVtk&s=o2UMy3X8NKTXg2j84FbImFb6F7V2QrPxTkiVslrpUXE&e= ------------15fb90e1612d127103fb92fb3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

    Yes, if you want your extensions to have their own full object structure and have it be completely separate, you can use the group syntax. I think you can also, with this syntax, have a simpler extension mechanism that says "just add the 'baz' field into the exsting event object and it means 'qux'".

    -- Justin

    On November 14, 2017 1:11:04 PM "Phil Hunt (IDM)" <phil.hunt@oracle.com> wrote:

    I withdraw my concern about extensions. 

    Extensions can be added to grouping event type just like we did for events. That means any one can extend any event, even risc. Same outcome just an extra level of json for those of us who need it. 

    Phil

    On Nov 14, 2017, at 11:48 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

    I worry this causes potential namespace conflicts. 

    I see complexity if each profile defines the method differently. Which undermines the value for the new proposal over the existing one. 

    I would like to see an extension mechanism that is standard for set as part of the new proposal.  

    Phil

    On Nov 14, 2017, at 11:42 AM, Justin Richer <jricher@mit.edu> wrote:

    Extensions to event types just extend the event object itself. So each event type controls the namespace within its event object and can allow additional bits in it. So let's say you've got:

    event: {
      event_type: "foo:bar",
      foo: thing,
      bar: other-thing
      ...
    }

    And you want to extend "foo:bar" with the "foo:bar:baz" extension you could easily do something like:

    event: {
      event_type: "foo:bar",
      foo: thing,
       bar: other-thing,
       baz: extension-thing
    }

    Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You could alternatively have an "extensions" object, but that seems like overkill. JSON in practice is schema-by-fiat: you look for things you know and care about and ignore everything else. So extensions can just stack inside the event object, and multiple extensions to the same event type will already need to know to stay out of each others' way.

    -- Justin

    On November 14, 2017 10:35:51 AM Phil Hunt <phil.hunt@oracle.com> wrote:

    How do you propose to handle extensions of event uris?

    Phil

    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    phil.hunt@oracle.com

    On Nov 14, 2017, at 2:21 AM, Justin Richer <jricher@mit.edu> wrote:

    I wanted to take a few moments to get down on virtual-paper some thoughts about the syntax and semantics of a SET from today's meeting. Originally, the event snytax that we brought to the table from the Consent Receipts working group in Kantara was very explicitly a single event being described. When RISC, OIDC sessions, and eventually SCIM came to the conersation, the group decided to try out a way to express multiple aspects of a single event in a single token. While I still agree with this principle, I can see now that it's too much of a temptation to express either multiple events or bend around the semantics in ways that could cause a lot of confusion. I now think that we should collapse the syntax as Annabelle has suggested and go even further to specify what can go where. To wit, SET payload profiles should only ever touch the things inside the event object. So I'm proposing that we do something like this:


    {
    iss: <-- string representing the issuer of the SET itself
    sub: <-- string representing the subject of the SET from the  view of the issuer (if known), no format assumed
    iat: <-- timestamp of when the SET Was created, not to be confused with the event time
    aud: <-- array or string repreesnting the recipients of this SET, from the view of the issuer of the sET
    exp: <-- timestamp of when the SET shouldn't be processed anymore
    event: { <-- object for the event itself, SET profiles do all of their definitions in here
       toe: <-- timestamp of the event, if known; if not present, event time is unknown
       iss: <-- issuer namespace for the subject of this event, as known by the recipient
       sub: <-- subject of the event, as known by the recipient, namespaced by event.iss
       txn: <-- transaction identifier for tying multiple events together
       event_type: <-- URI representing this event's type, must be understood by recipient (who can do a string match), can define other additional fields and their semantics
    }
    }

    And to Leif's point, to have a group event we would do:

    event: {
     event_type: urn:ietf:secevent:event_group
     <any event attributes that are common to the whole set, like txn, toe, sub, etc>
     events: [  <-- array of event objects with the semantics of the regular event object, taken all at once; can re-use any of the root event elements defined in SET but must not repeat any in the root event's common attributes
      ]
    }

    Event groups create some interop issues, as you need to have clients that can handle events in a group as well as on their own. But with the way people were describing event groups today, I think that's actually a good thing -- it would force recognition of the associated nature of all the components. If you get an event group, you need to understand everything in the group. No primary/secondary, no pritical fields -- all or nothing.

    Yes this is a change from current syntax and semantics, but to me it feels like a return to the consent receipt part of the roots.

    -- Justin


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e=

    ------------15fb90e1612d127103fb92fb3-- From nobody Mon Nov 13 21:47:03 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359CB124B0A for ; Mon, 13 Nov 2017 21:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ea89Kr55dnA for ; Mon, 13 Nov 2017 21:46:58 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7041275F4 for ; Mon, 13 Nov 2017 21:46:58 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id s75so14565199pgs.0 for ; Mon, 13 Nov 2017 21:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pbLFugdhOvebe0gDGrG4Jyib+5epPGn2xc8VmS/LbE0=; b=rc7MTlibZg5vJ05y8q9M70/Pz8dFrolL7jNnmL6hR5M6gTIQKN7usi61Kfg51o61Bf AU+mMkbEcjk0/tkM202KPWpF8BQqsNEWPCUGtm4d5Mk9Ug3UweHhf/PqPYZQGujAbKYE WTx8Gw6Xte+Rsoc56lypIzmpYvxSHA4I1utSovyjVPLib/21T4aL96Y+KZSXJ99+mIbo UNusk32XWxBB6IpwSPnn2LGCpBjqZumoWFi3+wzQYpHmegdz48TstRGVGmR4fiEQYNbW c7EK7Rd4lJfbQCdCFVlPeNL1t0+1+8YGQUfH6aPnDY1onxEXiZzGgRFDSGQLiLmGfx6n ILOw== 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=pbLFugdhOvebe0gDGrG4Jyib+5epPGn2xc8VmS/LbE0=; b=beu4/aQkkdbDIYoFPo8ci6Gp4FgJFo6yl85sAr8Kp3PI0oAIxWMGSeA304QU2GDHag ehN/Xy3x9tE7DFgS3RRDs2uibXNAz8zJWwuBKLFfxqUf0BNHMS1Id1x4LAN8ZPfPcM60 bRDW2jQ0ZSx87Ea1X9JxfgbFbBcWKa/uasmGjMPFB2AmSsdu8RMK5GeVJg11c+fGD31x BBiAjS2QfcEqAM/YqyNVGrJi0xWRhtvKvmSoqjqjRNR94ubtagscbd3tduL3KoFkdeZ2 Q88IzC6JoUtOrld6G2F7wzk8/is9xbvDLItlI+084fFFUTpBUtOkFX4TqQdLTAJw1oTD VOCQ== X-Gm-Message-State: AJaThX6lkzPU6RtEu4f5zdWHTr4iYihK1qmwyuiWT35fLpgvBzHp7x6L fHjlD49IxXp77GoqGdSi6m8/yfEwCmyPFZRTZpU= X-Google-Smtp-Source: AGs4zMZ5y5ba8W/y6QKVeal/mt7Rx/HtZ5a4tnYnIJIx4Ab1UhiZMRnHEQtMCqMwm/istZgt0O2LwFxw64qhqLmPN9k= X-Received: by 10.84.149.197 with SMTP id a5mr11500770plh.231.1510638417494; Mon, 13 Nov 2017 21:46:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.128.78 with HTTP; Mon, 13 Nov 2017 21:46:36 -0800 (PST) In-Reply-To: <15fb9095348.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> References: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <462D13E3-1D3E-45B8-AFC8-7CB91FDCF8A0@oracle.com> <15fb89ecdc0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <15fb9095348.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> From: Dick Hardt Date: Tue, 14 Nov 2017 13:46:36 +0800 Message-ID: To: Justin Richer Cc: Phil Hunt , SecEvent Content-Type: multipart/alternative; boundary="94eb2c148268424aca055deaea03" Archived-At: Subject: Re: [Id-event] Thoughts on Syntax from today's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 05:47:01 -0000 --94eb2c148268424aca055deaea03 Content-Type: text/plain; charset="UTF-8" Hey Justin, I'm having a hard time understanding the difference between "sub" and "event.sub". Do you have an example that highlight the semantic difference? On Tue, Nov 14, 2017 at 1:38 PM, Justin Richer wrote: > Yes, they're intended to be potentially different values but could be the > same in some circumstances. Syntactically, one is "sub" and the other is > "event.sub". I'd be perfectly happy renaming the "event.sub" claim to > "event.event_sub" or something, and I think the "risc_subject" with an > object type is also perfectly reasonable as it's providing data beyond what > the regular "event.sub" would do (as a string). Semantically, "sub" is from > the perspective of the issuer of the SET and "event.sub" is the perspective > of the receiver of the SET. > > -- Justin > > On November 14, 2017 11:49:27 AM Dick Hardt wrote: > >> Justin: you have "sub" above the event, and within the event. I think >> there are different values, but it is not clear. >> >> >> On Tue, Nov 14, 2017 at 11:42 AM, Justin Richer wrote: >> >>> Extensions to event types just extend the event object itself. So each >>> event type controls the namespace within its event object and can allow >>> additional bits in it. So let's say you've got: >>> >>> event: { >>> event_type: "foo:bar", >>> foo: thing, >>> bar: other-thing >>> ... >>> } >>> >>> And you want to extend "foo:bar" with the "foo:bar:baz" extension you >>> could easily do something like: >>> >>> event: { >>> event_type: "foo:bar", >>> foo: thing, >>> bar: other-thing, >>> baz: extension-thing >>> } >>> >>> Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You >>> could alternatively have an "extensions" object, but that seems like >>> overkill. JSON in practice is schema-by-fiat: you look for things you know >>> and care about and ignore everything else. So extensions can just stack >>> inside the event object, and multiple extensions to the same event type >>> will already need to know to stay out of each others' way. >>> >>> -- Justin >>> >>> On November 14, 2017 10:35:51 AM Phil Hunt wrote: >>> >>>> How do you propose to handle extensions of event uris? >>>> >>>> Phil >>>> >>>> Oracle Corporation, Identity Cloud Services Architect >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> On Nov 14, 2017, at 2:21 AM, Justin Richer wrote: >>>> >>>> I wanted to take a few moments to get down on virtual-paper some >>>> thoughts about the syntax and semantics of a SET from today's meeting. >>>> Originally, the event snytax that we brought to the table from the Consent >>>> Receipts working group in Kantara was very explicitly a single event being >>>> described. When RISC, OIDC sessions, and eventually SCIM came to the >>>> conersation, the group decided to try out a way to express multiple aspects >>>> of a single event in a single token. While I still agree with this >>>> principle, I can see now that it's too much of a temptation to express >>>> either multiple events or bend around the semantics in ways that could >>>> cause a lot of confusion. I now think that we should collapse the syntax as >>>> Annabelle has suggested and go even further to specify what can go where. >>>> To wit, SET payload profiles should only ever touch the things inside the >>>> event object. So I'm proposing that we do something like this: >>>> >>>> >>>> { >>>> iss: <-- string representing the issuer of the SET itself >>>> sub: <-- string representing the subject of the SET from the view of >>>> the issuer (if known), no format assumed >>>> iat: <-- timestamp of when the SET Was created, not to be confused with >>>> the event time >>>> aud: <-- array or string repreesnting the recipients of this SET, from >>>> the view of the issuer of the sET >>>> exp: <-- timestamp of when the SET shouldn't be processed anymore >>>> event: { <-- object for the event itself, SET profiles do all of their >>>> definitions in here >>>> toe: <-- timestamp of the event, if known; if not present, event >>>> time is unknown >>>> iss: <-- issuer namespace for the subject of this event, as known by >>>> the recipient >>>> sub: <-- subject of the event, as known by the recipient, namespaced >>>> by event.iss >>>> txn: <-- transaction identifier for tying multiple events together >>>> event_type: <-- URI representing this event's type, must be >>>> understood by recipient (who can do a string match), can define other >>>> additional fields and their semantics >>>> } >>>> } >>>> >>>> And to Leif's point, to have a group event we would do: >>>> >>>> event: { >>>> event_type: urn:ietf:secevent:event_group >>>> >>> sub, etc> >>>> events: [ <-- array of event objects with the semantics of the >>>> regular event object, taken all at once; can re-use any of the root event >>>> elements defined in SET but must not repeat any in the root event's common >>>> attributes >>>> ] >>>> } >>>> >>>> Event groups create some interop issues, as you need to have clients >>>> that can handle events in a group as well as on their own. But with the way >>>> people were describing event groups today, I think that's actually a good >>>> thing -- it would force recognition of the associated nature of all the >>>> components. If you get an event group, you need to understand everything in >>>> the group. No primary/secondary, no pritical fields -- all or nothing. >>>> >>>> Yes this is a change from current syntax and semantics, but to me it >>>> feels like a return to the consent receipt part of the roots. >>>> >>>> -- Justin >>>> >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet >>>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv >>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq >>>> PkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB- >>>> kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e= >>>> >>>> >>>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >> >> >> -- >> Subscribe to the HARDTWARE mail list to learn >> about projects I am working on! >> > -- Subscribe to the HARDTWARE mail list to learn about projects I am working on! --94eb2c148268424aca055deaea03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hey Justin, I'm having a hard time understanding the d= ifference between "sub" and "event.sub". Do you have an= example that highlight the semantic difference?

    On Tue, Nov 14, 2017 at 1:38 PM, Justi= n Richer <jricher@mit.edu> wrote:

    Yes, they're intended to be potentially different values but could be the same in some circumstances. Syntactically, one is "sub" and the other is "event.sub"= ;.=C2=A0 I'd be perfectly happy renaming the "event.sub" claim to "event.eve= nt_sub" or something, and I think the "risc_subject" with an object type is = also perfectly reasonable as it's providing data beyond what the regular "event.sub" would do (as a string). Semantically, "sub"= is from the perspective of the issuer of the SET and "event.sub" is the persp= ective of the receiver of the SET.

    -- Justin

    On November 14, 2017 11:49:27 AM Dick Hardt <dick.hardt@gmail.com> wrote:

    Justin: you have "sub" above the event, and with= in the event. I think there are different values, but it is not clear.


    On Tue, Nov 14, 2017 at 11:42 AM, Justin Richer <jricher@mit.edu> wrote:

    Extensions to event types just extend the event object itself. So each event type controls the namespace within its event object and can allow additional bits in it. So let's s= ay you've got:

    event: {
    =C2=A0 event_type: "foo:bar",
    =C2=A0 foo: thing,
    =C2=A0 bar: other-thing
    =C2=A0 ...
    }

    And you want to extend "foo:bar" with the "foo:bar:baz" extension you could easily do something like:

    event: {
    =C2=A0 event_type: "foo:bar",
    =C2=A0 foo: thing,
    =C2=A0=C2=A0 bar: other-thing,
    =C2=A0=C2=A0 baz: extension-thing
    }

    Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You could alternatively have an "extensions" object, but that seems like overkill. JSON in practice is schema-by-fiat: you look for things you know and care about and ignore everything else. So extensions can just stack inside the event object, and multiple extensions to the same event type will already need to know to stay out of each others' way.

    -- Justin

    On November 14, 2017 10:35:51 AM Phil Hunt <phil.hunt@oracle.com> wrote:

    How do you propose to handle extensions of event uris?

    <= div>
    Ph= il

    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    phil.hu= nt@oracle.com

    On Nov 14, 2017, at 2:21 AM, Justin Richer <jricher@mit.edu> wrote:

    I wante= d to take a few moments to get down on virtual-paper some thoughts about the syntax and semantics of a SET from today's meeting. Originally, the eve= nt snytax that we brought to the table from the Consent Receipts working group in Kantara was very explicitly a single event being described. When RISC, OIDC sessions, and eventually SCIM came to the conersation, the group decided to try out a way to express multiple aspects of a single event in a single token. While I still agree with this principle, I can see now that it's too much of a temptation to express either multiple events or bend around the semantics in ways that could cause a lot of confusion. I now think that we should collapse the syntax as Annabelle has suggested and go even further to specify what can go where. To wit, SET payload profiles should only ever touch the things inside the event object. So I'm propo= sing that we do something like this:


    {
    iss: <-- string representing the issuer of the SET itself
    sub: <-- string representing the subject of the SET from the =C2=A0view of the issuer (if known), no format assumed
    iat: <-- timestamp of when the SET Was created, not to be confused with the event time
    aud: <-- array or string repreesnting the recipients of this SET, from the view of the issuer of the sET
    exp: <-- timestamp of when the SET shouldn't be processed anymore event: { <-- object for the event itself, SET profiles do all of their definitions in here
    =C2=A0=C2=A0=C2=A0toe: <-- timestamp of the event, if known; if not present, event time is unknown
    =C2=A0=C2=A0=C2=A0iss: <-- issuer namespace for the subject of this event, as known by the recipient
    =C2=A0=C2=A0=C2=A0sub: <-- subject of the event, as known by the recipient, namespaced by event.iss
    =C2=A0=C2=A0=C2=A0txn: <-- transaction identifier for tying multiple events together
    =C2=A0=C2=A0=C2=A0event_type: <-- URI representing this event's type= , must be understood by recipient (who can do a string match), can define other additional fields and their semantics
    }
    }

    And to Leif&#= 39;s point, to have a group event we would do:

    event: {
    =C2=A0event_type: urn:ietf:secevent:event_group
    =C2=A0<any event attributes that are common to the whole set, like txn, toe, sub, etc>
    =C2=A0events: [ =C2=A0<-- array of event objects with the semantics of the regular event object, taken all at once; can re-use any of the root event elements defined in SET but must not repeat any in the root event'= ;s common attributes
    =C2=A0=C2=A0]
    }

    Event groups create some interop issues, as you need to have clients that can handle events in a group as well as on their own. But with the way people were describing event groups today, I think that's actua= lly a good thing -- it would force recognition of the associated nature of all the components. If you get an event group, you need to understand everything in the group. No primary/secondary, no pritical fields -- all or nothing.

    Yes this is a change from current syntax and semantics, but to me it feels like a return to the consent receipt part of the roots.

    -- Justin


    _______________________________________________
    I= d-event mailing list
    Id-e= vent@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXC= gaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyX= PpuYqPkAI1aLcLN4KZNA&m=3Dy2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxs= B-kpYFg&s=3DFZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e= =3D


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    Subscribe = to the HARDTWARE ma= il list to learn about projects I am working on!



    --
    Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
    --94eb2c148268424aca055deaea03-- From nobody Tue Nov 14 00:11:51 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9941294A6 for ; Tue, 14 Nov 2017 00:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Yj1YVeGKmmag for ; Tue, 14 Nov 2017 00:11:46 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 3853C124234 for ; Tue, 14 Nov 2017 00:11:46 -0800 (PST) X-AuditID: 12074423-727ff700000029a2-76-5a0aa53d8aaa Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id B3.07.10658.E35AA0A5; Tue, 14 Nov 2017 03:11:44 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id vAE8Bbqb010922; Tue, 14 Nov 2017 03:11:38 -0500 Received: from [31.133.129.30] (dhcp-811e.meeting.ietf.org [31.133.129.30]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vAE8BUMo019635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Nov 2017 03:11:34 -0500 From: Justin Richer To: Dick Hardt CC: Phil Hunt , SecEvent Date: Tue, 14 Nov 2017 16:11:29 +0800 Message-ID: <15fb9954768.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> In-Reply-To: References: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <462D13E3-1D3E-45B8-AFC8-7CB91FDCF8A0@oracle.com> <15fb89ecdc0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <15fb9095348.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> User-Agent: AquaMail/1.6.2.7 (build: 27000207) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------15fb995498dd1271021341c9f" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixG6nruuwlCvKYOpfVovHM4ssOhZ0M1ks mN/I7sDssXPWXXaPJUt+Mnl8fHqLJYA5issmJTUnsyy1SN8ugSvj/9FrTAW3dzNWrPm1gr2B ccNCxi5GTg4JAROJ3rVv2boYuTiEBBYzSfRN+skC4WxklDh2qosJpEpI4ASTxOwzpiA2m4Cq xPQ1LWBxESD7wNkWFhCbWcBJ4sC1e2BxFqD4ucnL2EFsXgF3iUXTZrOC2JwCgRL/b65ghljQ yixxZO0FZpCEqICexN1rv8FOEhawlzj2cR0rRLOgxMmZT6AWBEt0X//DOoGRfxaS1CwkKQjb QmLVtPPsELa8RPPW2cwQtobEgjv7GJHFFzCyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI108vN LNFLTSndxAgOeBflHYwv+7wPMQpwMCrx8Dpc4YwSYk0sK67MPcQoycGkJMqr8pk9SogvKT+l MiOxOCO+qDQntfgQowQHs5II785ZXFFCvCmJlVWpRfkwKWkOFiVx3m1BuyKFBNITS1KzU1ML UotgsjIcHEoSvP8WAzUKFqWmp1akZeaUIKSZODhBhvMADZ+zBGR4cUFibnFmOkT+FKMlx4ab d/8wcewDk89mvm5gFmLJy89LlRLnfQAyVACkIaM0D24mKIHJtzbKvWIUB3pRmJcFZCwPMPnB TX0FtJAJaKEUyKe8xSWJCCmpBsaM10u/69tuaItg9lsgOX3Nxsyfa0p2LvkVomu0u+a82IGf uRUdS24bX3PNW6m04YzVzQt9jx+tvsGuc0Ds+3qGf6v2Bvn95VqzZU6hxploxaXLX9/PKo9h yPPb4iySnbFewWfdyjuLFF/xOehMXnCqwvmno+JxH5V1201e71XwFy4TXC2u5XpaiaU4I9FQ i7moOBEALch92DsDAAA= Archived-At: Subject: Re: [Id-event] Thoughts on Syntax from today's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 08:11:49 -0000 This is a multi-part message in MIME format. ------------15fb995498dd1271021341c9f Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Sure, here's a somewhat concrete strawman. Let's say you've got an event issued by the RP in an identity system, sending information to another party (either the IdP or someone else). The "subject" from the OIDC perspective is what you'd find in an ID Token, say "abcd-1234". This only makes sense in the contex of the IdP's issuer, "https://id.example.com/", so it doesn't make sense to send the subject on its own without the issuer. However, the issuer of the SET itself is going to be the RP, "rp-client-id-1234" in the OIDC world or even "https://rp.example.net/" in a wider ecosystem. So in this example, we want to talk about a user "abcd-1234" from "https://id.example.com/", but it's "rp-client-id-1234" that's talking about that user. Which gives us: { "iss": "rp-client-1234", "event": { "iss": "https://id.example.com/", "sub": "abcd-1234" } } So why would you use "sub" at the root? Only if the issuer of the SET has their own, independent way to look at the user. In our case, let's say the RP has a local username identifier of "user-9876", you could have: {   "iss": "rp-client-1234", "sub": "user-9876",   "event": {     "iss": "https://id.example.com/",     "sub": "abcd-1234"   } } I think that the use of "sub" at the root should be less common than the use of "event.sub", in th use cases that people have brought up here. I'm against using "sub" as a shortcut for "event.sub", as has been suggested. -- Justin On November 14, 2017 1:47:05 PM Dick Hardt wrote: > Hey Justin, I'm having a hard time understanding the difference between > "sub" and "event.sub". Do you have an example that highlight the semantic > difference? > > On Tue, Nov 14, 2017 at 1:38 PM, Justin Richer wrote: > >> Yes, they're intended to be potentially different values but could be the >> same in some circumstances. Syntactically, one is "sub" and the other is >> "event.sub". I'd be perfectly happy renaming the "event.sub" claim to >> "event.event_sub" or something, and I think the "risc_subject" with an >> object type is also perfectly reasonable as it's providing data beyond what >> the regular "event.sub" would do (as a string). Semantically, "sub" is from >> the perspective of the issuer of the SET and "event.sub" is the perspective >> of the receiver of the SET. >> >> -- Justin >> >> On November 14, 2017 11:49:27 AM Dick Hardt wrote: >> >>> Justin: you have "sub" above the event, and within the event. I think >>> there are different values, but it is not clear. >>> >>> >>> On Tue, Nov 14, 2017 at 11:42 AM, Justin Richer wrote: >>> >>>> Extensions to event types just extend the event object itself. So each >>>> event type controls the namespace within its event object and can allow >>>> additional bits in it. So let's say you've got: >>>> >>>> event: { >>>> event_type: "foo:bar", >>>> foo: thing, >>>> bar: other-thing >>>> ... >>>> } >>>> >>>> And you want to extend "foo:bar" with the "foo:bar:baz" extension you >>>> could easily do something like: >>>> >>>> event: { >>>> event_type: "foo:bar", >>>> foo: thing, >>>> bar: other-thing, >>>> baz: extension-thing >>>> } >>>> >>>> Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You >>>> could alternatively have an "extensions" object, but that seems like >>>> overkill. JSON in practice is schema-by-fiat: you look for things you know >>>> and care about and ignore everything else. So extensions can just stack >>>> inside the event object, and multiple extensions to the same event type >>>> will already need to know to stay out of each others' way. >>>> >>>> -- Justin >>>> >>>> On November 14, 2017 10:35:51 AM Phil Hunt wrote: >>>> >>>>> How do you propose to handle extensions of event uris? >>>>> >>>>> Phil >>>>> >>>>> Oracle Corporation, Identity Cloud Services Architect >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> On Nov 14, 2017, at 2:21 AM, Justin Richer wrote: >>>>> >>>>> I wanted to take a few moments to get down on virtual-paper some >>>>> thoughts about the syntax and semantics of a SET from today's meeting. >>>>> Originally, the event snytax that we brought to the table from the Consent >>>>> Receipts working group in Kantara was very explicitly a single event being >>>>> described. When RISC, OIDC sessions, and eventually SCIM came to the >>>>> conersation, the group decided to try out a way to express multiple aspects >>>>> of a single event in a single token. While I still agree with this >>>>> principle, I can see now that it's too much of a temptation to express >>>>> either multiple events or bend around the semantics in ways that could >>>>> cause a lot of confusion. I now think that we should collapse the syntax as >>>>> Annabelle has suggested and go even further to specify what can go where. >>>>> To wit, SET payload profiles should only ever touch the things inside the >>>>> event object. So I'm proposing that we do something like this: >>>>> >>>>> >>>>> { >>>>> iss: <-- string representing the issuer of the SET itself >>>>> sub: <-- string representing the subject of the SET from the view of >>>>> the issuer (if known), no format assumed >>>>> iat: <-- timestamp of when the SET Was created, not to be confused with >>>>> the event time >>>>> aud: <-- array or string repreesnting the recipients of this SET, from >>>>> the view of the issuer of the sET >>>>> exp: <-- timestamp of when the SET shouldn't be processed anymore >>>>> event: { <-- object for the event itself, SET profiles do all of their >>>>> definitions in here >>>>> toe: <-- timestamp of the event, if known; if not present, event >>>>> time is unknown >>>>> iss: <-- issuer namespace for the subject of this event, as known by >>>>> the recipient >>>>> sub: <-- subject of the event, as known by the recipient, namespaced >>>>> by event.iss >>>>> txn: <-- transaction identifier for tying multiple events together >>>>> event_type: <-- URI representing this event's type, must be >>>>> understood by recipient (who can do a string match), can define other >>>>> additional fields and their semantics >>>>> } >>>>> } >>>>> >>>>> And to Leif's point, to have a group event we would do: >>>>> >>>>> event: { >>>>> event_type: urn:ietf:secevent:event_group >>>>> >>>> sub, etc> >>>>> events: [ <-- array of event objects with the semantics of the >>>>> regular event object, taken all at once; can re-use any of the root event >>>>> elements defined in SET but must not repeat any in the root event's common >>>>> attributes >>>>> ] >>>>> } >>>>> >>>>> Event groups create some interop issues, as you need to have clients >>>>> that can handle events in a group as well as on their own. But with the way >>>>> people were describing event groups today, I think that's actually a good >>>>> thing -- it would force recognition of the associated nature of all the >>>>> components. If you get an event group, you need to understand everything in >>>>> the group. No primary/secondary, no pritical fields -- all or nothing. >>>>> >>>>> Yes this is a change from current syntax and semantics, but to me it >>>>> feels like a return to the consent receipt part of the roots. >>>>> >>>>> -- Justin >>>>> >>>>> >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet >>>>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv >>>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq >>>>> PkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB- >>>>> kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e= >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>> >>>> >>> >>> >>> -- >>> Subscribe to the HARDTWARE mail list to learn >>> about projects I am working on! >>> >> > > > -- > Subscribe to the HARDTWARE mail list to learn about > projects I am working on! ------------15fb995498dd1271021341c9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit

    Sure, here's a somewhat concrete strawman. Let's say you've got an event issued by the RP in an identity system, sending information to another party (either the IdP or someone else). The "subject" from the OIDC perspective is what you'd find in an ID Token, say "abcd-1234". This only makes sense in the contex of the IdP's issuer, "https://id.example.com/", so it doesn't make sense to send the subject on its own without the issuer. However, the issuer of the SET itself is going to be the RP, "rp-client-id-1234" in the OIDC world or even "https://rp.example.net/" in a wider ecosystem.

    So in this example, we want to talk about a user "abcd-1234" from "https://id.example.com/", but it's "rp-client-id-1234" that's talking about that user. Which gives us:

    {
      "iss": "rp-client-1234",
      "event": {
        "iss": "https://id.example.com/",
        "sub": "abcd-1234"
      }
    }

    So why would you use "sub" at the root? Only if the issuer of the SET has their own, independent way to look at the user. In our case, let's say the RP has a local username identifier of "user-9876", you could have:

    {
      "iss": "rp-client-1234",
      "sub": "user-9876",
      "event": {
        "iss": "https://id.example.com/",
        "sub": "abcd-1234"
      }
    }

    I think that the use of "sub" at the root should be less common than the use of "event.sub", in th use cases that people have brought up here. I'm against using "sub" as a shortcut for "event.sub", as has been suggested.

    -- Justin

    On November 14, 2017 1:47:05 PM Dick Hardt <dick.hardt@gmail.com> wrote:

    Hey Justin, I'm having a hard time understanding the difference between "sub" and "event.sub". Do you have an example that highlight the semantic difference?

    On Tue, Nov 14, 2017 at 1:38 PM, Justin Richer <jricher@mit.edu> wrote:

    Yes, they're intended to be potentially different values but could be the same in some circumstances. Syntactically, one is "sub" and the other is "event.sub".  I'd be perfectly happy renaming the "event.sub" claim to "event.event_sub" or something, and I think the "risc_subject" with an object type is also perfectly reasonable as it's providing data beyond what the regular "event.sub" would do (as a string). Semantically, "sub" is from the perspective of the issuer of the SET and "event.sub" is the perspective of the receiver of the SET.

    -- Justin

    On November 14, 2017 11:49:27 AM Dick Hardt <dick.hardt@gmail.com> wrote:

    Justin: you have "sub" above the event, and within the event. I think there are different values, but it is not clear.


    On Tue, Nov 14, 2017 at 11:42 AM, Justin Richer <jricher@mit.edu> wrote:

    Extensions to event types just extend the event object itself. So each event type controls the namespace within its event object and can allow additional bits in it. So let's say you've got:

    event: {
      event_type: "foo:bar",
      foo: thing,
      bar: other-thing
      ...
    }

    And you want to extend "foo:bar" with the "foo:bar:baz" extension you could easily do something like:

    event: {
      event_type: "foo:bar",
      foo: thing,
       bar: other-thing,
       baz: extension-thing
    }

    Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You could alternatively have an "extensions" object, but that seems like overkill. JSON in practice is schema-by-fiat: you look for things you know and care about and ignore everything else. So extensions can just stack inside the event object, and multiple extensions to the same event type will already need to know to stay out of each others' way.

    -- Justin

    On November 14, 2017 10:35:51 AM Phil Hunt <phil.hunt@oracle.com> wrote:

    How do you propose to handle extensions of event uris?

    Phil

    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    phil.hunt@oracle.com

    On Nov 14, 2017, at 2:21 AM, Justin Richer <jricher@mit.edu> wrote:

    I wanted to take a few moments to get down on virtual-paper some thoughts about the syntax and semantics of a SET from today's meeting. Originally, the event snytax that we brought to the table from the Consent Receipts working group in Kantara was very explicitly a single event being described. When RISC, OIDC sessions, and eventually SCIM came to the conersation, the group decided to try out a way to express multiple aspects of a single event in a single token. While I still agree with this principle, I can see now that it's too much of a temptation to express either multiple events or bend around the semantics in ways that could cause a lot of confusion. I now think that we should collapse the syntax as Annabelle has suggested and go even further to specify what can go where. To wit, SET payload profiles should only ever touch the things inside the event object. So I'm proposing that we do something like this:


    {
    iss: <-- string representing the issuer of the SET itself
    sub: <-- string representing the subject of the SET from the  view of the issuer (if known), no format assumed
    iat: <-- timestamp of when the SET Was created, not to be confused with the event time
    aud: <-- array or string repreesnting the recipients of this SET, from the view of the issuer of the sET
    exp: <-- timestamp of when the SET shouldn't be processed anymore
    event: { <-- object for the event itself, SET profiles do all of their definitions in here
       toe: <-- timestamp of the event, if known; if not present, event time is unknown
       iss: <-- issuer namespace for the subject of this event, as known by the recipient
       sub: <-- subject of the event, as known by the recipient, namespaced by event.iss
       txn: <-- transaction identifier for tying multiple events together
       event_type: <-- URI representing this event's type, must be understood by recipient (who can do a string match), can define other additional fields and their semantics
    }
    }

    And to Leif's point, to have a group event we would do:

    event: {
     event_type: urn:ietf:secevent:event_group
     <any event attributes that are common to the whole set, like txn, toe, sub, etc>
     events: [  <-- array of event objects with the semantics of the regular event object, taken all at once; can re-use any of the root event elements defined in SET but must not repeat any in the root event's common attributes
      ]
    }

    Event groups create some interop issues, as you need to have clients that can handle events in a group as well as on their own. But with the way people were describing event groups today, I think that's actually a good thing -- it would force recognition of the associated nature of all the components. If you get an event group, you need to understand everything in the group. No primary/secondary, no pritical fields -- all or nothing.

    Yes this is a change from current syntax and semantics, but to me it feels like a return to the consent receipt part of the roots.

    -- Justin


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e=


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    Subscribe to the HARDTWARE mail list to learn about projects I am working on!



    --
    Subscribe to the HARDTWARE mail list to learn about projects I am working on!
    ------------15fb995498dd1271021341c9f-- From nobody Tue Nov 14 00:20:30 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D0A129AC6 for ; Tue, 14 Nov 2017 00:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnrGI_YX-s9e for ; Tue, 14 Nov 2017 00:20:18 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47EE129A96 for ; Tue, 14 Nov 2017 00:20:18 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id q4so5747298pfg.13 for ; Tue, 14 Nov 2017 00:20:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZKtMX3qepV/cvjkzM5DNdH1s041fnRxTBaW0Igp2vJc=; b=pi0wUEvRzQ9L/xE35zjwpCmp6f3CLKUkkyiwbYrfjDAegKJM1oZFP16/Et4NP526TU +nmWEH3uJaWL+1D7NZN05hCF1bp9E5q4DOmQNI5j5t4H9EAH8MqB/f0r9kN6KrTlL0Gl Jzwoy9a6Li46V9orseGWGv2RQKUz0nIeKG1Xb5kEUmbGcS+4lcS7IH5+P9X7sLr9GPnd 1GHumBsuiUruEmj/OTJuiH4U9V+uY4jjJfSStslTSWB25xjo0XlNmSpoGF5QiL1MKDQK xhgcSoncxs342cuLKgL1TdN2SZIx/iCcrd8gHrb0Ti3MwCPgKtoSx5xpoqB56msgXp+d YPhg== 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=ZKtMX3qepV/cvjkzM5DNdH1s041fnRxTBaW0Igp2vJc=; b=N++N+ct3vsA37kq9zYJ+akqBRjDUz44Ijr9dy5ZCeO7Qjd4rFez0W/WremLIyf2qTN 8kmfH4p/N5lX43zGYWfaHDv3CjqwWEpheEAwy7XuTUnfw/JW66i6RLKSeHgkK897OygO tbXAQ/8RQoHKivvF+ojRnOhRvfSfeqAzs+TCcJBvFMH0zfXWoSWOk3R3lXFP99fXeD1C P49DbgnEj6pkBYQ/9m/Q9reyb8ZiBQ58/iMIjzNmw3a/kE5EME6aGbQjyISrmq1iXXOx W0wEsbksVt2uHN/m/nT+uk0MIj5LFanYI66NPJCayfW7Hw6rsun+a4VvlYrHeoFtXx7p P+Bg== X-Gm-Message-State: AJaThX6AiTkkOJljADTOEvzpC6GHHZXBXMoW+4m8KFktLrslTomZJuFS NJ3qWxGfvf3i1du3JWGuHJnJfXnTkydyFy1i8NA2Pg== X-Google-Smtp-Source: AGs4zMbrI1FqAhCwBgTgsnH+BXJaas3PzGGdNM1gp0+ZXjaRvQwLkU5SHXLpEaYKHuN4vk4ijAJsc1GHL0Z+0xjxTrM= X-Received: by 10.159.207.147 with SMTP id z19mr11592057plo.441.1510647618195; Tue, 14 Nov 2017 00:20:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.149.143 with HTTP; Tue, 14 Nov 2017 00:19:55 -0800 (PST) In-Reply-To: <15fb9954768.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> References: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <462D13E3-1D3E-45B8-AFC8-7CB91FDCF8A0@oracle.com> <15fb89ecdc0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <15fb9095348.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <15fb9954768.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> From: Dick Hardt Date: Tue, 14 Nov 2017 16:19:55 +0800 Message-ID: To: Justin Richer Cc: Phil Hunt , SecEvent Content-Type: multipart/alternative; boundary="089e0828c024a9d52f055ded0eb0" Archived-At: Subject: Re: [Id-event] Thoughts on Syntax from today's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 08:20:28 -0000 --089e0828c024a9d52f055ded0eb0 Content-Type: text/plain; charset="UTF-8" Thanks Justin. What value would there be to the IdP to have the RP's identifier? Is there a reason the IdP needs it? I worry about the privacy implications of sharing the additional identifier that the RP has that the IdP does not have. On Tue, Nov 14, 2017 at 4:11 PM, Justin Richer wrote: > Sure, here's a somewhat concrete strawman. Let's say you've got an event > issued by the RP in an identity system, sending information to another > party (either the IdP or someone else). The "subject" from the OIDC > perspective is what you'd find in an ID Token, say "abcd-1234". This only > makes sense in the contex of the IdP's issuer, "https://id.example.com/", > so it doesn't make sense to send the subject on its own without the issuer. > However, the issuer of the SET itself is going to be the RP, > "rp-client-id-1234" in the OIDC world or even "https://rp.example.net/" > in a wider ecosystem. > > So in this example, we want to talk about a user "abcd-1234" from " > https://id.example.com/", but it's "rp-client-id-1234" that's talking > about that user. Which gives us: > > { > "iss": "rp-client-1234", > "event": { > "iss": "https://id.example.com/", > "sub": "abcd-1234" > } > } > > So why would you use "sub" at the root? Only if the issuer of the SET has > their own, independent way to look at the user. In our case, let's say the > RP has a local username identifier of "user-9876", you could have: > > { > "iss": "rp-client-1234", > "sub": "user-9876", > "event": { > "iss": "https://id.example.com/", > "sub": "abcd-1234" > } > } > > I think that the use of "sub" at the root should be less common than the > use of "event.sub", in th use cases that people have brought up here. I'm > against using "sub" as a shortcut for "event.sub", as has been suggested. > > -- Justin > > On November 14, 2017 1:47:05 PM Dick Hardt wrote: > >> Hey Justin, I'm having a hard time understanding the difference between >> "sub" and "event.sub". Do you have an example that highlight the semantic >> difference? >> >> On Tue, Nov 14, 2017 at 1:38 PM, Justin Richer wrote: >> >>> Yes, they're intended to be potentially different values but could be >>> the same in some circumstances. Syntactically, one is "sub" and the other >>> is "event.sub". I'd be perfectly happy renaming the "event.sub" claim to >>> "event.event_sub" or something, and I think the "risc_subject" with an >>> object type is also perfectly reasonable as it's providing data beyond what >>> the regular "event.sub" would do (as a string). Semantically, "sub" is from >>> the perspective of the issuer of the SET and "event.sub" is the perspective >>> of the receiver of the SET. >>> >>> -- Justin >>> >>> On November 14, 2017 11:49:27 AM Dick Hardt >>> wrote: >>> >>>> Justin: you have "sub" above the event, and within the event. I think >>>> there are different values, but it is not clear. >>>> >>>> >>>> On Tue, Nov 14, 2017 at 11:42 AM, Justin Richer >>>> wrote: >>>> >>>>> Extensions to event types just extend the event object itself. So each >>>>> event type controls the namespace within its event object and can allow >>>>> additional bits in it. So let's say you've got: >>>>> >>>>> event: { >>>>> event_type: "foo:bar", >>>>> foo: thing, >>>>> bar: other-thing >>>>> ... >>>>> } >>>>> >>>>> And you want to extend "foo:bar" with the "foo:bar:baz" extension you >>>>> could easily do something like: >>>>> >>>>> event: { >>>>> event_type: "foo:bar", >>>>> foo: thing, >>>>> bar: other-thing, >>>>> baz: extension-thing >>>>> } >>>>> >>>>> Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. >>>>> You could alternatively have an "extensions" object, but that seems like >>>>> overkill. JSON in practice is schema-by-fiat: you look for things you know >>>>> and care about and ignore everything else. So extensions can just stack >>>>> inside the event object, and multiple extensions to the same event type >>>>> will already need to know to stay out of each others' way. >>>>> >>>>> -- Justin >>>>> >>>>> On November 14, 2017 10:35:51 AM Phil Hunt >>>>> wrote: >>>>> >>>>>> How do you propose to handle extensions of event uris? >>>>>> >>>>>> Phil >>>>>> >>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>> >>>>>> On Nov 14, 2017, at 2:21 AM, Justin Richer wrote: >>>>>> >>>>>> I wanted to take a few moments to get down on virtual-paper some >>>>>> thoughts about the syntax and semantics of a SET from today's meeting. >>>>>> Originally, the event snytax that we brought to the table from the Consent >>>>>> Receipts working group in Kantara was very explicitly a single event being >>>>>> described. When RISC, OIDC sessions, and eventually SCIM came to the >>>>>> conersation, the group decided to try out a way to express multiple aspects >>>>>> of a single event in a single token. While I still agree with this >>>>>> principle, I can see now that it's too much of a temptation to express >>>>>> either multiple events or bend around the semantics in ways that could >>>>>> cause a lot of confusion. I now think that we should collapse the syntax as >>>>>> Annabelle has suggested and go even further to specify what can go where. >>>>>> To wit, SET payload profiles should only ever touch the things inside the >>>>>> event object. So I'm proposing that we do something like this: >>>>>> >>>>>> >>>>>> { >>>>>> iss: <-- string representing the issuer of the SET itself >>>>>> sub: <-- string representing the subject of the SET from the view of >>>>>> the issuer (if known), no format assumed >>>>>> iat: <-- timestamp of when the SET Was created, not to be confused >>>>>> with the event time >>>>>> aud: <-- array or string repreesnting the recipients of this SET, >>>>>> from the view of the issuer of the sET >>>>>> exp: <-- timestamp of when the SET shouldn't be processed anymore >>>>>> event: { <-- object for the event itself, SET profiles do all of >>>>>> their definitions in here >>>>>> toe: <-- timestamp of the event, if known; if not present, event >>>>>> time is unknown >>>>>> iss: <-- issuer namespace for the subject of this event, as known >>>>>> by the recipient >>>>>> sub: <-- subject of the event, as known by the recipient, >>>>>> namespaced by event.iss >>>>>> txn: <-- transaction identifier for tying multiple events together >>>>>> event_type: <-- URI representing this event's type, must be >>>>>> understood by recipient (who can do a string match), can define other >>>>>> additional fields and their semantics >>>>>> } >>>>>> } >>>>>> >>>>>> And to Leif's point, to have a group event we would do: >>>>>> >>>>>> event: { >>>>>> event_type: urn:ietf:secevent:event_group >>>>>> >>>>> toe, sub, etc> >>>>>> events: [ <-- array of event objects with the semantics of the >>>>>> regular event object, taken all at once; can re-use any of the root event >>>>>> elements defined in SET but must not repeat any in the root event's common >>>>>> attributes >>>>>> ] >>>>>> } >>>>>> >>>>>> Event groups create some interop issues, as you need to have clients >>>>>> that can handle events in a group as well as on their own. But with the way >>>>>> people were describing event groups today, I think that's actually a good >>>>>> thing -- it would force recognition of the associated nature of all the >>>>>> components. If you get an event group, you need to understand everything in >>>>>> the group. No primary/secondary, no pritical fields -- all or nothing. >>>>>> >>>>>> Yes this is a change from current syntax and semantics, but to me it >>>>>> feels like a return to the consent receipt part of the roots. >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet >>>>>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv >>>>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqP >>>>>> kAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg >>>>>> &s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e= >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>> >>>>> >>>> >>>> >>>> -- >>>> Subscribe to the HARDTWARE mail list to learn >>>> about projects I am working on! >>>> >>> >> >> >> -- >> Subscribe to the HARDTWARE mail list to learn >> about projects I am working on! >> > -- Subscribe to the HARDTWARE mail list to learn about projects I am working on! --089e0828c024a9d52f055ded0eb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks Justin.

    What value would there b= e to the IdP to have the RP's identifier? Is there a reason the IdP nee= ds it?

    I worry about the privacy implications of s= haring the additional identifier that the RP has that the IdP does not have= .


    --
    Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
    --089e0828c024a9d52f055ded0eb0-- From nobody Tue Nov 14 06:54:25 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4E4127137 for ; Tue, 14 Nov 2017 06:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.82 X-Spam-Level: X-Spam-Status: No, score=-11.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 S_6QrZgHyaGw for ; Tue, 14 Nov 2017 06:54:18 -0800 (PST) Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FB2124C27 for ; Tue, 14 Nov 2017 06:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1510671258; x=1542207258; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nuhv7U2vid3wNfmzkSMnFL5bmX+bXYlYxOTZ+oLRAt0=; b=l/j+Pv9gxGr07ruHnl2kOevX5NOk641ILoZlLWCzyu1rwu6Rc5q49+VV HtzFqJSWJXNpcLK3HGnezTZQ5grWMcbarbm87wuN1ud4VMhcDPl65SMju 8rclkDegN8zv7dboGnqUFTQPNtRjspcmPYlShzan+X7UeN1CgrdFFr4cV Q=; X-IronPort-AV: E=Sophos;i="5.44,395,1505779200"; d="scan'208,217";a="318978320" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1d-98acfc19.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Nov 2017 14:54:08 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1d-98acfc19.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id vAEEs4Dd078115 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Nov 2017 14:54:08 GMT Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 14 Nov 2017 14:54:07 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 14 Nov 2017 14:54:06 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Tue, 14 Nov 2017 14:54:07 +0000 From: "Richard Backman, Annabelle" To: Luke Camery CC: "id-event@ietf.org" Thread-Topic: [Id-event] Plan for the Week Thread-Index: AQHTXPskQaYCyhQCoEykaMol5jZbbKMTQz2BgACzoAA= Date: Tue, 14 Nov 2017 14:54:07 +0000 Message-ID: References: <75369D63-0131-4719-881C-CB06D9D399EC@amazon.com> In-Reply-To: <75369D63-0131-4719-881C-CB06D9D399EC@amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.100] Content-Type: multipart/alternative; boundary="_000_CA446DC522264FF19D032469E5254D4Famazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Id-event] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 14:54:20 -0000 --_000_CA446DC522264FF19D032469E5254D4Famazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVyZSBpcyB0aGUgZHJhZnQgSSB3aWxsIGJlIHByZXNlbnRpbmcgZHVyaW5nIHRvbW9ycm934oCZ cyBtZWV0aW5nOiBodHRwczovL2dpdGh1Yi5jb20vcmljaGFubmEvc2VjZXZlbnQvYmxvYi9zZXQt YWx0L2RyYWZ0LXJpY2hhbm5hLXNlY2V2ZW50LXRva2VuLnR4dA0KDQpIaWdobGlnaHRzOg0KDQog ICogICBTZWN0aW9uIDIgaXMgYWxtb3N0IGNvbXBsZXRlbHkgcmV3cml0dGVuLCB3aXRoIHRoZSBm b2xsb3dpbmcgbWFqb3IgY2hhbmdlczoNCiAgICAgKiAgIEkgc3RyaXBwZWQgb3V0IHJlZHVuZGFu dCB0ZXh0IHdpdGhpbiB0aGUgZHJhZnQgYW5kIGJldHdlZW4gaXQgYW5kIFJGQyA3NTE5Lg0KICAg ICAqICAgTWFrZXMgbW9yZSBleHBsaWNpdCB0aGUgaWRlYSBvZiBhIFNFVCBlbnZlbG9wZSBhbmQg YW4gZXZlbnQgcGF5bG9hZC4gTnVkZ2VzIFByb2ZpbGluZyBTcGVjcyB0b3dhcmQgZGVmaW5pbmcg ZXZlbnQgcGF5bG9hZCBjbGFpbXMuDQogICAgICogICDigJxldmVudHPigJ0gY2xhaW0gaXMgbm93 IOKAnGV2ZW504oCdDQogICAgICogICBJIHB1bGxlZCBpbiB0aGUgU3ViamVjdCBJZGVudGlmaWVy IGNvbmNlcHQgZGVmaW5lZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2N1 cnRlc2N1LXNlY2V2ZW50LWV2ZW50LXN0cmVhbS1tZ210LWFwaS0wMCwgYXMgaXQgaGVscHMgdG8g ZGVmaW5lIGhvdyB0aGUg4oCcc3Vi4oCdIGV2ZW50IHBheWxvYWQgY2xhaW0gc2hvdWxkIHdvcmsu IFRoaXMgc3BlYyBkZWZpbmVzIFN1YmplY3QgSWRlbnRpZmllciBUeXBlcyBmb3IgZW1haWwsIHBo b25lIG51bWJlciwgYW5kIGlzc3VlciBhbmQgc3ViamVjdCwgYW5kIGhhcyBhIGJpZyBvbGXigJkg VE9ETyBmb3IgYW4gSUFOQSByZWdpc3RyeSBmb3IgdGhlc2UuDQogICogICBBZGRlZCBzZWN0aW9u IGRlZmluaW5nIGEgUmVsYXRlZCBFdmVudHMgZXZlbnQsIGFsb25nIHRoZSBsaW5lcyBvZiB0aGUg cHJvcG9zYWwgSnVzdGluIHBvc3RlZCB0byB0aGUgbGlzdCBlYXJsaWVyIHRvZGF5Lg0KICAgICAq ICAgVGhlcmXigJlzIGEgbG90IG9mIGxhbmd1YWdlIHRoZXJlIGFyb3VuZCBtYWtpbmcgY2xlYXIg dGhlIHJlcXVpcmVtZW50cyBmb3IgU0VUcyBjb250YWluaW5nIHRoaXMgZXZlbnQsIHRyeWluZyB0 byBtaW5pbWl6ZSBhbWJpZ3VpdHkgYW5kIGNsYXJpZnkgcmVxdWlyZW1lbnRzLiBXZeKAmWxsIHdh bnQgdG8gdGFrZSBhIGdvb2QgbG9vayBhdCB0aGlzLg0KICAqICAgQWRkZWQgc3ViLXNlY3Rpb24g b24gZXZlbnQgZXh0ZW5zaW9ucywgZ2l2aW5nIGd1aWRhbmNlIG9uIGhvdyB0byBwbGF5IG5pY2Ug d2l0aCBvbmUgYW5vdGhlci4NCg0KSSBsaXN0ZWQgYWxsIHRoZSBhdXRob3JzIGZyb20gdGhlIC0w MyBkcmFmdCBvbiB0aGlzIG9uZSwgc2luY2UgSSBzdGFydGVkIGZyb20gLTAzIGFuZCBwYXJlZCBk b3duL2VkaXRlZCB0byBnZXQgdG8gdGhpcyBvbmUsIGJ1dCBJ4oCZbSBob25lc3RseSBub3Qgc3Vy ZSB3aGF0IHRoZSBldGlxdWl0ZSBpcyBoZXJlLCBlLmcuIGxlYXZlIHBlb3BsZSBhcyBhdXRob3Jz IG9uIHNvbWV0aGluZyB0aGV5IGhhdmVu4oCZdCBoYWQgaW5wdXQgaW50byB5ZXQgb3IgbW92ZSB0 aGVtIHRvIGFja25vd2xlZGdlbWVudHM/IEZlZWwgZnJlZSB0byBsZXQgbWUga25vdyBpZiB5b3Ug d2FudCBtZSB0byByZW1vdmUgeW91IGFzIGFuIGF1dGhvci4gQ3VycmVudGx5LCB0aGUgYXV0aG9y cyBsaXN0ZWQgYXJlIG15c2VsZiwgUGhpbCwgV2lsbGlhbSwgTW9ydGV6YSwgYW5kIE1pa2UuDQoN Ci0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBbWF6b24g4oCTIElkZW50aXR5IFNlcnZp Y2VzDQoNCg0KRnJvbTogSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJl aGFsZiBvZiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29t Pg0KRGF0ZTogVHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcgYXQgMTI6MTEgUE0NClRvOiBMdWtl IENhbWVyeSA8bGNhbWVyeUBnb29nbGUuY29tPg0KQ2M6ICJpZC1ldmVudEBpZXRmLm9yZyIgPGlk LWV2ZW50QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gUGxhbiBmb3IgdGhlIFdl ZWsNCg0KQ29ycmVjdGlvbjogdGhlIFdlZG5lc2RheSBtZWV0aW5nIGlzIGZyb20gMTA6MzAgdG8g MTI6MzAuDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIE5vdiAxNCwgMjAxNywgYXQgMTE6NDYg QU0sIEx1a2UgQ2FtZXJ5IDxsY2FtZXJ5QGdvb2dsZS5jb208bWFpbHRvOmxjYW1lcnlAZ29vZ2xl LmNvbT4+IHdyb3RlOg0KRnV0dXJlIE1lZXRpbmdzDQpXZWRuZXNkYXkgLSAxMDozMC0xMjowMCBp biBCdXR0ZXJ3b3J0aCBvbiBBbm5hYmVsbGUncyBBbHRlcm5hdGl2ZSBTRVQgUHJvcG9zYWwNClRo dXJzZGF5IC0gMTU6MzAtMTg6MDAgaW4gdGhlIEF0cml1bSBvbiBNYXJpdXMnIENvbnRyb2wgUGxh bmUNCkZyaWRheSAtIDEwOjAwLTE4OjAwIGF0IEdvb2dsZSBTaW5nYXBvcmUgKDcwIFBhc2lyIFBh bmphbmcgUm9hZCwgIzAzLTcxLCAxMTczNzEpIG9uIFdvcmsgU2Vzc2lvbg0KDQotLQ0KW2h0dHA6 Ly9pLmltZ3VyLmNvbS9ZYTRSaHNzLmdpZl0NCg0KICDigKIgIEx1a2UgQ2FtZXJ5DQogIOKAoiAg QXNzb2NpYXRlIFByb2R1Y3QgTWFuYWdlcg0KICDigKIgIEZlZGVyYXRlZCBJZGVudGl0eQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQg bWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQo= --_000_CA446DC522264FF19D032469E5254D4Famazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <564BECAE73E352458CB9D1E48C3C38EE@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCXBhbm9zZS0xOjIgNyAzIDkgMiAyIDUgMiA0 IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsN CgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE1MzE5ODg2Mzk7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDIwODMyMjIg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpA bGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVy ZSBpcyB0aGUgZHJhZnQgSSB3aWxsIGJlIHByZXNlbnRpbmcgZHVyaW5nIHRvbW9ycm934oCZcyBt ZWV0aW5nOg0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3JpY2hhbm5hL3NlY2V2ZW50L2Js b2Ivc2V0LWFsdC9kcmFmdC1yaWNoYW5uYS1zZWNldmVudC10b2tlbi50eHQiPg0KaHR0cHM6Ly9n aXRodWIuY29tL3JpY2hhbm5hL3NlY2V2ZW50L2Jsb2Ivc2V0LWFsdC9kcmFmdC1yaWNoYW5uYS1z ZWNldmVudC10b2tlbi50eHQ8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpZ2hsaWdodHM6 PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+U2VjdGlvbiAyIGlzIGFsbW9zdCBjb21wbGV0ZWx5IHJld3Jp dHRlbiwgd2l0aCB0aGUgZm9sbG93aW5nIG1ham9yIGNoYW5nZXM6PG86cD48L286cD4NCjx1bCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEi Pkkgc3RyaXBwZWQgb3V0IHJlZHVuZGFudCB0ZXh0IHdpdGhpbiB0aGUgZHJhZnQgYW5kIGJldHdl ZW4gaXQgYW5kIFJGQyA3NTE5LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPk1h a2VzIG1vcmUgZXhwbGljaXQgdGhlIGlkZWEgb2YgYSBTRVQgZW52ZWxvcGUgYW5kIGFuIGV2ZW50 IHBheWxvYWQuIE51ZGdlcyBQcm9maWxpbmcgU3BlY3MgdG93YXJkIGRlZmluaW5nIGV2ZW50IHBh eWxvYWQgY2xhaW1zLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPuKAnGV2ZW50 c+KAnSBjbGFpbSBpcyBub3cg4oCcZXZlbnTigJ08bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVs MiBsZm8xIj5JIHB1bGxlZCBpbiB0aGUgU3ViamVjdCBJZGVudGlmaWVyIGNvbmNlcHQgZGVmaW5l ZCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjdXJ0ZXNj dS1zZWNldmVudC1ldmVudC1zdHJlYW0tbWdtdC1hcGktMDAiPg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXNjdXJ0ZXNjdS1zZWNldmVudC1ldmVudC1zdHJlYW0tbWdtdC1hcGkt MDA8L2E+LCBhcyBpdCBoZWxwcyB0byBkZWZpbmUgaG93IHRoZSDigJxzdWLigJ0gZXZlbnQgcGF5 bG9hZCBjbGFpbSBzaG91bGQgd29yay4gVGhpcyBzcGVjIGRlZmluZXMgU3ViamVjdCBJZGVudGlm aWVyIFR5cGVzIGZvciBlbWFpbCwgcGhvbmUgbnVtYmVyLCBhbmQgaXNzdWVyIGFuZCBzdWJqZWN0 LCBhbmQgaGFzIGEgYmlnDQogb2xl4oCZIFRPRE8gZm9yIGFuIElBTkEgcmVnaXN0cnkgZm9yIHRo ZXNlLiA8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5BZGRl ZCBzZWN0aW9uIGRlZmluaW5nIGEgUmVsYXRlZCBFdmVudHMgZXZlbnQsIGFsb25nIHRoZSBsaW5l cyBvZiB0aGUgcHJvcG9zYWwgSnVzdGluIHBvc3RlZCB0byB0aGUgbGlzdCBlYXJsaWVyIHRvZGF5 LjxvOnA+PC9vOnA+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJjaXJjbGUiPg0K PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwwIGxldmVsMiBsZm8xIj5UaGVyZeKAmXMgYSBsb3Qgb2YgbGFuZ3VhZ2UgdGhlcmUgYXJv dW5kIG1ha2luZyBjbGVhciB0aGUgcmVxdWlyZW1lbnRzIGZvciBTRVRzIGNvbnRhaW5pbmcgdGhp cyBldmVudCwgdHJ5aW5nIHRvIG1pbmltaXplIGFtYmlndWl0eSBhbmQgY2xhcmlmeSByZXF1aXJl bWVudHMuIFdl4oCZbGwgd2FudCB0byB0YWtlIGEgZ29vZA0KIGxvb2sgYXQgdGhpcy48bzpwPjwv bzpwPjwvbGk+PC91bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5BZGRlZCBzdWItc2VjdGlv biBvbiBldmVudCBleHRlbnNpb25zLCBnaXZpbmcgZ3VpZGFuY2Ugb24gaG93IHRvIHBsYXkgbmlj ZSB3aXRoIG9uZSBhbm90aGVyLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGxpc3Rl ZCBhbGwgdGhlIGF1dGhvcnMgZnJvbSB0aGUgLTAzIGRyYWZ0IG9uIHRoaXMgb25lLCBzaW5jZSBJ IHN0YXJ0ZWQgZnJvbSAtMDMgYW5kIHBhcmVkIGRvd24vZWRpdGVkIHRvIGdldCB0byB0aGlzIG9u ZSwgYnV0IEnigJltIGhvbmVzdGx5IG5vdCBzdXJlIHdoYXQgdGhlIGV0aXF1aXRlIGlzIGhlcmUs IGUuZy4gbGVhdmUgcGVvcGxlIGFzIGF1dGhvcnMgb24gc29tZXRoaW5nIHRoZXkgaGF2ZW7igJl0 IGhhZA0KIGlucHV0IGludG8geWV0IG9yIG1vdmUgdGhlbSB0byBhY2tub3dsZWRnZW1lbnRzPyBG ZWVsIGZyZWUgdG8gbGV0IG1lIGtub3cgaWYgeW91IHdhbnQgbWUgdG8gcmVtb3ZlIHlvdSBhcyBh biBhdXRob3IuIEN1cnJlbnRseSwgdGhlIGF1dGhvcnMgbGlzdGVkIGFyZSBteXNlbGYsIFBoaWws IFdpbGxpYW0sIE1vcnRlemEsIGFuZCBNaWtlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQg QmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+QW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5JZC1ldmVudCAmbHQ7aWQtZXZlbnQtYm91 bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mICZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5u YWJlbGxlJnF1b3Q7ICZsdDtyaWNoYW5uYUBhbWF6b24uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5UdWVzZGF5LCBOb3ZlbWJlciAxNCwgMjAxNyBhdCAxMjoxMSBQTTxicj4NCjxiPlRvOiA8L2I+ THVrZSBDYW1lcnkgJmx0O2xjYW1lcnlAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZx dW90O2lkLWV2ZW50QGlldGYub3JnJnF1b3Q7ICZsdDtpZC1ldmVudEBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtJZC1ldmVudF0gUGxhbiBmb3IgdGhlIFdlZWs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5Db3JyZWN0aW9uOiB0aGUgV2VkbmVzZGF5IG1lZXRpbmcgaXMg ZnJvbSAxMDozMCB0byAxMjozMC48bzpwPjwvbzpwPjwvcD4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNp Z25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW50IGZyb20gbXkgaVBob25lPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIE5vdiAxNCwgMjAxNywgYXQgMTE6NDYgQU0sIEx1 a2UgQ2FtZXJ5ICZsdDs8YSBocmVmPSJtYWlsdG86bGNhbWVyeUBnb29nbGUuY29tIj5sY2FtZXJ5 QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5GdXR1cmUgTWVldGluZ3M8 L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlZG5lc2Rh eSAtIDEwOjMwLTEyOjAwIGluIEJ1dHRlcndvcnRoIG9uIEFubmFiZWxsZSdzIEFsdGVybmF0aXZl IFNFVCBQcm9wb3NhbA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGh1cnNkYXkgLSAxNTozMC0xODowMCBpbiB0aGUgQXRyaXVtIG9uIE1hcml1cycgQ29udHJv bCBQbGFuZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RnJpZGF5IC0gMTA6MDAtMTg6MDAgYXQgR29vZ2xlIFNpbmdhcG9yZSAoPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPjcwIFBhc2lyIFBhbmphbmcgUm9hZCwgIzAzLTcxLCAxMTczNzEp IG9uIFdvcmsgU2Vzc2lvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIGNl bGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlO2JvcmRlcjpub25l Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0Oi41aW4iPg0KPHRkIHN0eWxlPSJib3JkZXI6 c29saWQgd2hpdGUgMS4wcHQ7cGFkZGluZzoxLjVwdCAyLjI1cHQgMS41cHQgMi4yNXB0O2hlaWdo dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0 LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4Ij48aW1nIGJvcmRlcj0i MCIgd2lkdGg9Ijk2IiBoZWlnaHQ9IjQyIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHA6Ly9p LmltZ3VyLmNvbS9ZYTRSaHNzLmdpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0 ZCBzdHlsZT0iYm9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7cGFkZGlu ZzoxLjVwdCAyLjI1cHQgMS41cHQgMi4yNXB0O2hlaWdodDouNWluIj4NCjwvdGQ+DQo8dGQgdmFs aWduPSJib3R0b20iIHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLWxlZnQ6 bm9uZTtwYWRkaW5nOjEuNXB0IDIuMjVwdCAxLjVwdCAyLjI1cHQ7aGVpZ2h0Oi41aW4iPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzNE ODVDNiI+Jm5ic3A7IOKAoiAmbmJzcDs8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzY2NjY2NiI+THVrZSBDYW1lcnk8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzNE ODVDNjtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj48YnI+DQo8L3Nw YW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVkIj4mbmJzcDsg4oCiICZuYnNwOzwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2JvcmRlcjpub25lIHdpbmRvd3RleHQg MS4wcHQ7cGFkZGluZzowaW4iPkFzc29jaWF0ZSBQcm9kdWN0IE1hbmFnZXI8L3NwYW4+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpyZWQ7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjBpbiI+PGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6I0ZGQ0MzMyI+Jm5i c3A7IOKAoiAmbmJzcDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2Njtib3Jk ZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5GZWRlcmF0ZWQgSWRlbnRpdHk8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOklkLWV2ZW50QGlldGYub3JnIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50Ij5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CA446DC522264FF19D032469E5254D4Famazoncom_-- From nobody Tue Nov 14 07:53:18 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77943128BB6 for ; Tue, 14 Nov 2017 07:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 3ivBYq2GSHtU for ; Tue, 14 Nov 2017 07:53:13 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D4D128BC8 for ; Tue, 14 Nov 2017 07:53:12 -0800 (PST) X-AuditID: 12074425-135ff700000030f2-50-5a0b1165a723 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id B2.06.12530.6611B0A5; Tue, 14 Nov 2017 10:53:10 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id vAEFr8gN012705; Tue, 14 Nov 2017 10:53:09 -0500 Received: from [172.20.3.197] ([202.55.67.146]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vAEFr2H6004380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Nov 2017 10:53:06 -0500 From: Justin Richer To: Dick Hardt CC: Phil Hunt , SecEvent Date: Tue, 14 Nov 2017 23:53:00 +0800 Message-ID: <15fbb3bcf60.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> In-Reply-To: References: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <462D13E3-1D3E-45B8-AFC8-7CB91FDCF8A0@oracle.com> <15fb89ecdc0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <15fb9095348.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <15fb9954768.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> User-Agent: AquaMail/1.6.2.7 (build: 27000207) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------15fbb3bd310d127101595823a" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUixCmqrZsmyB1lsLbX2uLxzCKLjgXdTBYL 5jeyOzB77Jx1l91jyZKfTB4fn95iCWCO4rJJSc3JLEst0rdL4MqY8GAhY8HM24wV7e3f2RoY m/cydjFyckgImEg8fryEqYuRi0NIYDGTxJ57s1kgnI2MErPnT2aEcNYwSdxofMQO0sImoCox fU0LE4gtAmQfONvCAmIzCzhJHLh2DyzOAhS/degsUD0HB6+Au8SWizIgYU6BQIkZz5exgthC Al0sEl9O5YPYogJ6Enev/Qa7SFjAXuLYx3VgNbwCghInZz6BGh8s8XvVTeYJjPyzkKRmIUnN AtrGLGAtsfeLH0RYXqJ562xmCFtb4syBx0zI4gsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbp WujlZpbopaaUbmIEBTu7i+oOxjl/vQ4xCnAwKvHwvrjIGSXEmlhWXJl7iFGSg0lJlFflM3uU EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHenbO4ooR4UxIrq1KL8mFS0hwsSuK824J2RQoJpCeW pGanphakFsFkZTg4lCR4ZwhwRwkJFqWmp1akZeaUIKSZODhBhvMADb8GUsNbXJCYW5yZDpE/ xWjJseHm3T9MHPvA5LOZrxuYhVjy8vNSpcR5LUAaBEAaMkrz4GaCktcpc+dJrxjFgV4U5jUD qeIBJj64qa+AFjIBLZQC+ZS3uCQRISXVwBh7WTWypOTU+SOnTNtt6g8vtJCKaK/9G3Nq/wyt bv4JdXd0zsluODyRpS/w2IGA12F8Hf/nedW9XPdvwZQt9wQZv1f/u7qtYHbMwY5mZ8NUj2NK UaGTHWW3br0hLnV27U+1yLim60fyrQT7jW3Eg7RuKtZr/PXh2dVa8mjzs/dTekutT7NW71Zi Kc5INNRiLipOBAAjHs33OQMAAA== Archived-At: Subject: Re: [Id-event] Thoughts on Syntax from today's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 15:53:16 -0000 This is a multi-part message in MIME format. ------------15fbb3bd310d127101595823a Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit For the strawman, no, the IdP wouldn't need it. An audit system that knows about the RP's storage/lookup might need it. That's why, if we include it in the spec, we'd want some language making it clear that it's only within the view of the party generating the SET and that if it's for consumption externally the user should be identified by a field in the event, or event.sub. -- Justin On November 14, 2017 4:20:25 PM Dick Hardt wrote: > Thanks Justin. > > What value would there be to the IdP to have the RP's identifier? Is there > a reason the IdP needs it? > > I worry about the privacy implications of sharing the additional identifier > that the RP has that the IdP does not have. > > On Tue, Nov 14, 2017 at 4:11 PM, Justin Richer wrote: > >> Sure, here's a somewhat concrete strawman. Let's say you've got an event >> issued by the RP in an identity system, sending information to another >> party (either the IdP or someone else). The "subject" from the OIDC >> perspective is what you'd find in an ID Token, say "abcd-1234". This only >> makes sense in the contex of the IdP's issuer, "https://id.example.com/", >> so it doesn't make sense to send the subject on its own without the issuer. >> However, the issuer of the SET itself is going to be the RP, >> "rp-client-id-1234" in the OIDC world or even "https://rp.example.net/" >> in a wider ecosystem. >> >> So in this example, we want to talk about a user "abcd-1234" from " >> https://id.example.com/", but it's "rp-client-id-1234" that's talking >> about that user. Which gives us: >> >> { >> "iss": "rp-client-1234", >> "event": { >> "iss": "https://id.example.com/", >> "sub": "abcd-1234" >> } >> } >> >> So why would you use "sub" at the root? Only if the issuer of the SET has >> their own, independent way to look at the user. In our case, let's say the >> RP has a local username identifier of "user-9876", you could have: >> >> { >> "iss": "rp-client-1234", >> "sub": "user-9876", >> "event": { >> "iss": "https://id.example.com/", >> "sub": "abcd-1234" >> } >> } >> >> I think that the use of "sub" at the root should be less common than the >> use of "event.sub", in th use cases that people have brought up here. I'm >> against using "sub" as a shortcut for "event.sub", as has been suggested. >> >> -- Justin >> >> On November 14, 2017 1:47:05 PM Dick Hardt wrote: >> >>> Hey Justin, I'm having a hard time understanding the difference between >>> "sub" and "event.sub". Do you have an example that highlight the semantic >>> difference? >>> >>> On Tue, Nov 14, 2017 at 1:38 PM, Justin Richer wrote: >>> >>>> Yes, they're intended to be potentially different values but could be >>>> the same in some circumstances. Syntactically, one is "sub" and the other >>>> is "event.sub". I'd be perfectly happy renaming the "event.sub" claim to >>>> "event.event_sub" or something, and I think the "risc_subject" with an >>>> object type is also perfectly reasonable as it's providing data beyond what >>>> the regular "event.sub" would do (as a string). Semantically, "sub" is from >>>> the perspective of the issuer of the SET and "event.sub" is the perspective >>>> of the receiver of the SET. >>>> >>>> -- Justin >>>> >>>> On November 14, 2017 11:49:27 AM Dick Hardt >>>> wrote: >>>> >>>>> Justin: you have "sub" above the event, and within the event. I think >>>>> there are different values, but it is not clear. >>>>> >>>>> >>>>> On Tue, Nov 14, 2017 at 11:42 AM, Justin Richer >>>>> wrote: >>>>> >>>>>> Extensions to event types just extend the event object itself. So each >>>>>> event type controls the namespace within its event object and can allow >>>>>> additional bits in it. So let's say you've got: >>>>>> >>>>>> event: { >>>>>> event_type: "foo:bar", >>>>>> foo: thing, >>>>>> bar: other-thing >>>>>> ... >>>>>> } >>>>>> >>>>>> And you want to extend "foo:bar" with the "foo:bar:baz" extension you >>>>>> could easily do something like: >>>>>> >>>>>> event: { >>>>>> event_type: "foo:bar", >>>>>> foo: thing, >>>>>> bar: other-thing, >>>>>> baz: extension-thing >>>>>> } >>>>>> >>>>>> Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. >>>>>> You could alternatively have an "extensions" object, but that seems like >>>>>> overkill. JSON in practice is schema-by-fiat: you look for things you know >>>>>> and care about and ignore everything else. So extensions can just stack >>>>>> inside the event object, and multiple extensions to the same event type >>>>>> will already need to know to stay out of each others' way. >>>>>> >>>>>> -- Justin >>>>>> >>>>>> On November 14, 2017 10:35:51 AM Phil Hunt >>>>>> wrote: >>>>>> >>>>>>> How do you propose to handle extensions of event uris? >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>> >>>>>>> On Nov 14, 2017, at 2:21 AM, Justin Richer wrote: >>>>>>> >>>>>>> I wanted to take a few moments to get down on virtual-paper some >>>>>>> thoughts about the syntax and semantics of a SET from today's meeting. >>>>>>> Originally, the event snytax that we brought to the table from the Consent >>>>>>> Receipts working group in Kantara was very explicitly a single event being >>>>>>> described. When RISC, OIDC sessions, and eventually SCIM came to the >>>>>>> conersation, the group decided to try out a way to express multiple aspects >>>>>>> of a single event in a single token. While I still agree with this >>>>>>> principle, I can see now that it's too much of a temptation to express >>>>>>> either multiple events or bend around the semantics in ways that could >>>>>>> cause a lot of confusion. I now think that we should collapse the syntax as >>>>>>> Annabelle has suggested and go even further to specify what can go where. >>>>>>> To wit, SET payload profiles should only ever touch the things inside the >>>>>>> event object. So I'm proposing that we do something like this: >>>>>>> >>>>>>> >>>>>>> { >>>>>>> iss: <-- string representing the issuer of the SET itself >>>>>>> sub: <-- string representing the subject of the SET from the view of >>>>>>> the issuer (if known), no format assumed >>>>>>> iat: <-- timestamp of when the SET Was created, not to be confused >>>>>>> with the event time >>>>>>> aud: <-- array or string repreesnting the recipients of this SET, >>>>>>> from the view of the issuer of the sET >>>>>>> exp: <-- timestamp of when the SET shouldn't be processed anymore >>>>>>> event: { <-- object for the event itself, SET profiles do all of >>>>>>> their definitions in here >>>>>>> toe: <-- timestamp of the event, if known; if not present, event >>>>>>> time is unknown >>>>>>> iss: <-- issuer namespace for the subject of this event, as known >>>>>>> by the recipient >>>>>>> sub: <-- subject of the event, as known by the recipient, >>>>>>> namespaced by event.iss >>>>>>> txn: <-- transaction identifier for tying multiple events together >>>>>>> event_type: <-- URI representing this event's type, must be >>>>>>> understood by recipient (who can do a string match), can define other >>>>>>> additional fields and their semantics >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> And to Leif's point, to have a group event we would do: >>>>>>> >>>>>>> event: { >>>>>>> event_type: urn:ietf:secevent:event_group >>>>>>> >>>>>> toe, sub, etc> >>>>>>> events: [ <-- array of event objects with the semantics of the >>>>>>> regular event object, taken all at once; can re-use any of the root event >>>>>>> elements defined in SET but must not repeat any in the root event's common >>>>>>> attributes >>>>>>> ] >>>>>>> } >>>>>>> >>>>>>> Event groups create some interop issues, as you need to have clients >>>>>>> that can handle events in a group as well as on their own. But with the way >>>>>>> people were describing event groups today, I think that's actually a good >>>>>>> thing -- it would force recognition of the associated nature of all the >>>>>>> components. If you get an event group, you need to understand everything in >>>>>>> the group. No primary/secondary, no pritical fields -- all or nothing. >>>>>>> >>>>>>> Yes this is a change from current syntax and semantics, but to me it >>>>>>> feels like a return to the consent receipt part of the roots. >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet >>>>>>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv >>>>>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqP >>>>>>> kAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg >>>>>>> &s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e= >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Subscribe to the HARDTWARE mail list to learn >>>>> about projects I am working on! >>>>> >>>> >>> >>> >>> -- >>> Subscribe to the HARDTWARE mail list to learn >>> about projects I am working on! >>> >> > > > -- > Subscribe to the HARDTWARE mail list to learn about > projects I am working on! ------------15fbb3bd310d127101595823a Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

    For the strawman, no, the IdP wouldn't need it. An audit system that knows about the RP's storage/lookup might need it. That's why, if we include it in the spec, we'd want some language making it clear that it's only within the view of the party generating the SET and that if it's for consumption externally the user should be identified by a field in the event, or event.sub.

    -- Justin

    On November 14, 2017 4:20:25 PM Dick Hardt <dick.hardt@gmail.com> wrote:

    Thanks Justin.

    What value would there be to the IdP to have the RP's identifier? Is there a reason the IdP needs it?

    I worry about the privacy implications of sharing the additional identifier that the RP has that the IdP does not have.

    On Tue, Nov 14, 2017 at 4:11 PM, Justin Richer <jricher@mit.edu> wrote:

    Sure, here's a somewhat concrete strawman. Let's say you've got an event issued by the RP in an identity system, sending information to another party (either the IdP or someone else). The "subject" from the OIDC perspective is what you'd find in an ID Token, say "abcd-1234". This only makes sense in the contex of the IdP's issuer, "https://id.example.com/", so it doesn't make sense to send the subject on its own without the issuer. However, the issuer of the SET itself is going to be the RP, "rp-client-id-1234" in the OIDC world or even "https://rp.example.net/" in a wider ecosystem.

    So in this example, we want to talk about a user "abcd-1234" from "https://id.example.com/", but it's "rp-client-id-1234" that's talking about that user. Which gives us:

    {
      "iss": "rp-client-1234",
      "event": {
        "iss": "https://id.example.com/",
        "sub": "abcd-1234"
      }
    }

    So why would you use "sub" at the root? Only if the issuer of the SET has their own, independent way to look at the user. In our case, let's say the RP has a local username identifier of "user-9876", you could have:

    {
      "iss": "rp-client-1234",
      "sub": "user-9876",
      "event": {
        "iss": "https://id.example.com/",
        "sub": "abcd-1234"
      }
    }

    I think that the use of "sub" at the root should be less common than the use of "event.sub", in th use cases that people have brought up here. I'm against using "sub" as a shortcut for "event.sub", as has been suggested.

    -- Justin

    On November 14, 2017 1:47:05 PM Dick Hardt <dick.hardt@gmail.com> wrote:

    Hey Justin, I'm having a hard time understanding the difference between "sub" and "event.sub". Do you have an example that highlight the semantic difference?

    On Tue, Nov 14, 2017 at 1:38 PM, Justin Richer <jricher@mit.edu> wrote:

    Yes, they're intended to be potentially different values but could be the same in some circumstances. Syntactically, one is "sub" and the other is "event.sub".  I'd be perfectly happy renaming the "event.sub" claim to "event.event_sub" or something, and I think the "risc_subject" with an object type is also perfectly reasonable as it's providing data beyond what the regular "event.sub" would do (as a string). Semantically, "sub" is from the perspective of the issuer of the SET and "event.sub" is the perspective of the receiver of the SET.

    -- Justin

    On November 14, 2017 11:49:27 AM Dick Hardt <dick.hardt@gmail.com> wrote:

    Justin: you have "sub" above the event, and within the event. I think there are different values, but it is not clear.


    On Tue, Nov 14, 2017 at 11:42 AM, Justin Richer <jricher@mit.edu> wrote:

    Extensions to event types just extend the event object itself. So each event type controls the namespace within its event object and can allow additional bits in it. So let's say you've got:

    event: {
      event_type: "foo:bar",
      foo: thing,
      bar: other-thing
      ...
    }

    And you want to extend "foo:bar" with the "foo:bar:baz" extension you could easily do something like:

    event: {
      event_type: "foo:bar",
      foo: thing,
       bar: other-thing,
       baz: extension-thing
    }

    Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You could alternatively have an "extensions" object, but that seems like overkill. JSON in practice is schema-by-fiat: you look for things you know and care about and ignore everything else. So extensions can just stack inside the event object, and multiple extensions to the same event type will already need to know to stay out of each others' way.

    -- Justin

    On November 14, 2017 10:35:51 AM Phil Hunt <phil.hunt@oracle.com> wrote:

    How do you propose to handle extensions of event uris?

    Phil

    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    phil.hunt@oracle.com

    On Nov 14, 2017, at 2:21 AM, Justin Richer <jricher@mit.edu> wrote:

    I wanted to take a few moments to get down on virtual-paper some thoughts about the syntax and semantics of a SET from today's meeting. Originally, the event snytax that we brought to the table from the Consent Receipts working group in Kantara was very explicitly a single event being described. When RISC, OIDC sessions, and eventually SCIM came to the conersation, the group decided to try out a way to express multiple aspects of a single event in a single token. While I still agree with this principle, I can see now that it's too much of a temptation to express either multiple events or bend around the semantics in ways that could cause a lot of confusion. I now think that we should collapse the syntax as Annabelle has suggested and go even further to specify what can go where. To wit, SET payload profiles should only ever touch the things inside the event object. So I'm proposing that we do something like this:


    {
    iss: <-- string representing the issuer of the SET itself
    sub: <-- string representing the subject of the SET from the  view of the issuer (if known), no format assumed
    iat: <-- timestamp of when the SET Was created, not to be confused with the event time
    aud: <-- array or string repreesnting the recipients of this SET, from the view of the issuer of the sET
    exp: <-- timestamp of when the SET shouldn't be processed anymore
    event: { <-- object for the event itself, SET profiles do all of their definitions in here
       toe: <-- timestamp of the event, if known; if not present, event time is unknown
       iss: <-- issuer namespace for the subject of this event, as known by the recipient
       sub: <-- subject of the event, as known by the recipient, namespaced by event.iss
       txn: <-- transaction identifier for tying multiple events together
       event_type: <-- URI representing this event's type, must be understood by recipient (who can do a string match), can define other additional fields and their semantics
    }
    }

    And to Leif's point, to have a group event we would do:

    event: {
     event_type: urn:ietf:secevent:event_group
     <any event attributes that are common to the whole set, like txn, toe, sub, etc>
     events: [  <-- array of event objects with the semantics of the regular event object, taken all at once; can re-use any of the root event elements defined in SET but must not repeat any in the root event's common attributes
      ]
    }

    Event groups create some interop issues, as you need to have clients that can handle events in a group as well as on their own. But with the way people were describing event groups today, I think that's actually a good thing -- it would force recognition of the associated nature of all the components. If you get an event group, you need to understand everything in the group. No primary/secondary, no pritical fields -- all or nothing.

    Yes this is a change from current syntax and semantics, but to me it feels like a return to the consent receipt part of the roots.

    -- Justin


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e=


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    Subscribe to the HARDTWARE mail list to learn about projects I am working on!



    --
    Subscribe to the HARDTWARE mail list to learn about projects I am working on!



    --
    Subscribe to the HARDTWARE mail list to learn about projects I am working on!
    ------------15fbb3bd310d127101595823a-- From nobody Tue Nov 14 18:27:53 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088BC126E3A for ; Tue, 14 Nov 2017 18:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.818 X-Spam-Level: X-Spam-Status: No, score=-11.818 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 0XLoIVCBY30X for ; Tue, 14 Nov 2017 18:27:48 -0800 (PST) Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7F11205F0 for ; Tue, 14 Nov 2017 18:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1510712867; x=1542248867; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vCtjoa6UTpeOnGyPulwuzXUWYrztDECO3INhUodLIOc=; b=aznVmJgXawp0VLNeLBwGFnvRmriFInTvqXJ6B7KV1nWmR21TyYOgPthh yWuvFL9MauMNnRRX6Ti92dlmqDLE9/7npHCFVcW0rP2te17MQXFBFnEvK Es4ctENeVQBngWHfAI7vraibGoXnzGj7Djb6jI6mH+WBWiy3ZBpgEz/cY A=; X-IronPort-AV: E=Sophos;i="5.44,397,1505779200"; d="scan'208,217";a="319089540" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1a-715bee71.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 02:27:39 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1a-715bee71.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id vAF2RY0A095849 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2017 02:27:38 GMT Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 15 Nov 2017 02:27:38 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 15 Nov 2017 02:27:37 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Wed, 15 Nov 2017 02:27:37 +0000 From: "Richard Backman, Annabelle" To: Justin Richer , Dick Hardt CC: SecEvent , Phil Hunt Thread-Topic: [Id-event] Thoughts on Syntax from today's meeting Thread-Index: AQHTXKxB8BBqYKXeRkiM63ERMNNNAKMTKSwAgAASnACAAAHjgIAAHp+AgAACOwCAACh7gIAAAluAgAB+lwCAALFOAA== Date: Wed, 15 Nov 2017 02:27:37 +0000 Message-ID: References: <15fb69d48d0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <462D13E3-1D3E-45B8-AFC8-7CB91FDCF8A0@oracle.com> <15fb89ecdc0.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <15fb9095348.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <15fb9954768.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> <15fbb3bcf60.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> In-Reply-To: <15fbb3bcf60.2710.ba6b30732dbb1622ab6fd5be690399aa@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.100] Content-Type: multipart/alternative; boundary="_000_BA0E06F9A6B9454F88735ED0EA5AD657amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] Thoughts on Syntax from today's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:27:51 -0000 --_000_BA0E06F9A6B9454F88735ED0EA5AD657amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aG9zZSBhcmUgc2VtYW50aWNzIHRoYXQgY291bGQgYmUgZGVjbGFyZWQgYnkgYSBQ cm9maWxpbmcgU3BlY2lmaWNhdGlvbi4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4N CkFtYXpvbiDigJMgSWRlbnRpdHkgU2VydmljZXMNCg0KDQpGcm9tOiBJZC1ldmVudCA8aWQtZXZl bnQtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJA bWl0LmVkdT4NCkRhdGU6IFR1ZXNkYXksIE5vdmVtYmVyIDE0LCAyMDE3IGF0IDExOjUzIFBNDQpU bzogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpDYzogU2VjRXZlbnQgPGlkLWV2 ZW50QGlldGYub3JnPiwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4NClN1YmplY3Q6 IFJlOiBbSWQtZXZlbnRdIFRob3VnaHRzIG9uIFN5bnRheCBmcm9tIHRvZGF5J3MgbWVldGluZw0K DQoNCkZvciB0aGUgc3RyYXdtYW4sIG5vLCB0aGUgSWRQIHdvdWxkbid0IG5lZWQgaXQuIEFuIGF1 ZGl0IHN5c3RlbSB0aGF0IGtub3dzIGFib3V0IHRoZSBSUCdzIHN0b3JhZ2UvbG9va3VwIG1pZ2h0 IG5lZWQgaXQuIFRoYXQncyB3aHksIGlmIHdlIGluY2x1ZGUgaXQgaW4gdGhlIHNwZWMsIHdlJ2Qg d2FudCBzb21lIGxhbmd1YWdlIG1ha2luZyBpdCBjbGVhciB0aGF0IGl0J3Mgb25seSB3aXRoaW4g dGhlIHZpZXcgb2YgdGhlIHBhcnR5IGdlbmVyYXRpbmcgdGhlIFNFVCBhbmQgdGhhdCBpZiBpdCdz IGZvciBjb25zdW1wdGlvbiBleHRlcm5hbGx5IHRoZSB1c2VyIHNob3VsZCBiZSBpZGVudGlmaWVk IGJ5IGEgZmllbGQgaW4gdGhlIGV2ZW50LCBvciBldmVudC5zdWIuDQoNCi0tIEp1c3Rpbg0KDQpP biBOb3ZlbWJlciAxNCwgMjAxNyA0OjIwOjI1IFBNIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21h aWwuY29tPiB3cm90ZToNClRoYW5rcyBKdXN0aW4uDQoNCldoYXQgdmFsdWUgd291bGQgdGhlcmUg YmUgdG8gdGhlIElkUCB0byBoYXZlIHRoZSBSUCdzIGlkZW50aWZpZXI/IElzIHRoZXJlIGEgcmVh c29uIHRoZSBJZFAgbmVlZHMgaXQ/DQoNCkkgd29ycnkgYWJvdXQgdGhlIHByaXZhY3kgaW1wbGlj YXRpb25zIG9mIHNoYXJpbmcgdGhlIGFkZGl0aW9uYWwgaWRlbnRpZmllciB0aGF0IHRoZSBSUCBo YXMgdGhhdCB0aGUgSWRQIGRvZXMgbm90IGhhdmUuDQoNCk9uIFR1ZSwgTm92IDE0LCAyMDE3IGF0 IDQ6MTEgUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBt aXQuZWR1Pj4gd3JvdGU6DQoNClN1cmUsIGhlcmUncyBhIHNvbWV3aGF0IGNvbmNyZXRlIHN0cmF3 bWFuLiBMZXQncyBzYXkgeW91J3ZlIGdvdCBhbiBldmVudCBpc3N1ZWQgYnkgdGhlIFJQIGluIGFu IGlkZW50aXR5IHN5c3RlbSwgc2VuZGluZyBpbmZvcm1hdGlvbiB0byBhbm90aGVyIHBhcnR5IChl aXRoZXIgdGhlIElkUCBvciBzb21lb25lIGVsc2UpLiBUaGUgInN1YmplY3QiIGZyb20gdGhlIE9J REMgcGVyc3BlY3RpdmUgaXMgd2hhdCB5b3UnZCBmaW5kIGluIGFuIElEIFRva2VuLCBzYXkgImFi Y2QtMTIzNCIuIFRoaXMgb25seSBtYWtlcyBzZW5zZSBpbiB0aGUgY29udGV4IG9mIHRoZSBJZFAn cyBpc3N1ZXIsICJodHRwczovL2lkLmV4YW1wbGUuY29tLyIsIHNvIGl0IGRvZXNuJ3QgbWFrZSBz ZW5zZSB0byBzZW5kIHRoZSBzdWJqZWN0IG9uIGl0cyBvd24gd2l0aG91dCB0aGUgaXNzdWVyLiBI b3dldmVyLCB0aGUgaXNzdWVyIG9mIHRoZSBTRVQgaXRzZWxmIGlzIGdvaW5nIHRvIGJlIHRoZSBS UCwgInJwLWNsaWVudC1pZC0xMjM0IiBpbiB0aGUgT0lEQyB3b3JsZCBvciBldmVuICJodHRwczov L3JwLmV4YW1wbGUubmV0LyIgaW4gYSB3aWRlciBlY29zeXN0ZW0uDQoNClNvIGluIHRoaXMgZXhh bXBsZSwgd2Ugd2FudCB0byB0YWxrIGFib3V0IGEgdXNlciAiYWJjZC0xMjM0IiBmcm9tICJodHRw czovL2lkLmV4YW1wbGUuY29tLyIsIGJ1dCBpdCdzICJycC1jbGllbnQtaWQtMTIzNCIgdGhhdCdz IHRhbGtpbmcgYWJvdXQgdGhhdCB1c2VyLiBXaGljaCBnaXZlcyB1czoNCg0Kew0KICAiaXNzIjog InJwLWNsaWVudC0xMjM0IiwNCiAgImV2ZW50Ijogew0KICAgICJpc3MiOiAiaHR0cHM6Ly9pZC5l eGFtcGxlLmNvbS8iLA0KICAgICJzdWIiOiAiYWJjZC0xMjM0Ig0KICB9DQp9DQoNClNvIHdoeSB3 b3VsZCB5b3UgdXNlICJzdWIiIGF0IHRoZSByb290PyBPbmx5IGlmIHRoZSBpc3N1ZXIgb2YgdGhl IFNFVCBoYXMgdGhlaXIgb3duLCBpbmRlcGVuZGVudCB3YXkgdG8gbG9vayBhdCB0aGUgdXNlci4g SW4gb3VyIGNhc2UsIGxldCdzIHNheSB0aGUgUlAgaGFzIGEgbG9jYWwgdXNlcm5hbWUgaWRlbnRp ZmllciBvZiAidXNlci05ODc2IiwgeW91IGNvdWxkIGhhdmU6DQoNCnsNCiAgImlzcyI6ICJycC1j bGllbnQtMTIzNCIsDQogICJzdWIiOiAidXNlci05ODc2IiwNCiAgImV2ZW50Ijogew0KICAgICJp c3MiOiAiaHR0cHM6Ly9pZC5leGFtcGxlLmNvbS8iLA0KICAgICJzdWIiOiAiYWJjZC0xMjM0Ig0K ICB9DQp9DQoNCkkgdGhpbmsgdGhhdCB0aGUgdXNlIG9mICJzdWIiIGF0IHRoZSByb290IHNob3Vs ZCBiZSBsZXNzIGNvbW1vbiB0aGFuIHRoZSB1c2Ugb2YgImV2ZW50LnN1YiIsIGluIHRoIHVzZSBj YXNlcyB0aGF0IHBlb3BsZSBoYXZlIGJyb3VnaHQgdXAgaGVyZS4gSSdtIGFnYWluc3QgdXNpbmcg InN1YiIgYXMgYSBzaG9ydGN1dCBmb3IgImV2ZW50LnN1YiIsIGFzIGhhcyBiZWVuIHN1Z2dlc3Rl ZC4NCg0KLS0gSnVzdGluDQoNCk9uIE5vdmVtYmVyIDE0LCAyMDE3IDE6NDc6MDUgUE0gRGljayBI YXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4g d3JvdGU6DQpIZXkgSnVzdGluLCBJJ20gaGF2aW5nIGEgaGFyZCB0aW1lIHVuZGVyc3RhbmRpbmcg dGhlIGRpZmZlcmVuY2UgYmV0d2VlbiAic3ViIiBhbmQgImV2ZW50LnN1YiIuIERvIHlvdSBoYXZl IGFuIGV4YW1wbGUgdGhhdCBoaWdobGlnaHQgdGhlIHNlbWFudGljIGRpZmZlcmVuY2U/DQoNCk9u IFR1ZSwgTm92IDE0LCAyMDE3IGF0IDE6MzggUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0 LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQoNClllcywgdGhleSdyZSBpbnRl bmRlZCB0byBiZSBwb3RlbnRpYWxseSBkaWZmZXJlbnQgdmFsdWVzIGJ1dCBjb3VsZCBiZSB0aGUg c2FtZSBpbiBzb21lIGNpcmN1bXN0YW5jZXMuIFN5bnRhY3RpY2FsbHksIG9uZSBpcyAic3ViIiBh bmQgdGhlIG90aGVyIGlzICJldmVudC5zdWIiLiAgSSdkIGJlIHBlcmZlY3RseSBoYXBweSByZW5h bWluZyB0aGUgImV2ZW50LnN1YiIgY2xhaW0gdG8gImV2ZW50LmV2ZW50X3N1YiIgb3Igc29tZXRo aW5nLCBhbmQgSSB0aGluayB0aGUgInJpc2Nfc3ViamVjdCIgd2l0aCBhbiBvYmplY3QgdHlwZSBp cyBhbHNvIHBlcmZlY3RseSByZWFzb25hYmxlIGFzIGl0J3MgcHJvdmlkaW5nIGRhdGEgYmV5b25k IHdoYXQgdGhlIHJlZ3VsYXIgImV2ZW50LnN1YiIgd291bGQgZG8gKGFzIGEgc3RyaW5nKS4gU2Vt YW50aWNhbGx5LCAic3ViIiBpcyBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgaXNzdWVyIG9m IHRoZSBTRVQgYW5kICJldmVudC5zdWIiIGlzIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgcmVjZWl2 ZXIgb2YgdGhlIFNFVC4NCg0KLS0gSnVzdGluDQoNCk9uIE5vdmVtYmVyIDE0LCAyMDE3IDExOjQ5 OjI3IEFNIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0 QGdtYWlsLmNvbT4+IHdyb3RlOg0KSnVzdGluOiB5b3UgaGF2ZSAic3ViIiBhYm92ZSB0aGUgZXZl bnQsIGFuZCB3aXRoaW4gdGhlIGV2ZW50LiBJIHRoaW5rIHRoZXJlIGFyZSBkaWZmZXJlbnQgdmFs dWVzLCBidXQgaXQgaXMgbm90IGNsZWFyLg0KDQoNCk9uIFR1ZSwgTm92IDE0LCAyMDE3IGF0IDEx OjQyIEFNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0 LmVkdT4+IHdyb3RlOg0KDQpFeHRlbnNpb25zIHRvIGV2ZW50IHR5cGVzIGp1c3QgZXh0ZW5kIHRo ZSBldmVudCBvYmplY3QgaXRzZWxmLiBTbyBlYWNoIGV2ZW50IHR5cGUgY29udHJvbHMgdGhlIG5h bWVzcGFjZSB3aXRoaW4gaXRzIGV2ZW50IG9iamVjdCBhbmQgY2FuIGFsbG93IGFkZGl0aW9uYWwg Yml0cyBpbiBpdC4gU28gbGV0J3Mgc2F5IHlvdSd2ZSBnb3Q6DQoNCmV2ZW50OiB7DQogIGV2ZW50 X3R5cGU6ICJmb286YmFyIiwNCiAgZm9vOiB0aGluZywNCiAgYmFyOiBvdGhlci10aGluZw0KICAu Li4NCn0NCg0KQW5kIHlvdSB3YW50IHRvIGV4dGVuZCAiZm9vOmJhciIgd2l0aCB0aGUgImZvbzpi YXI6YmF6IiBleHRlbnNpb24geW91IGNvdWxkIGVhc2lseSBkbyBzb21ldGhpbmcgbGlrZToNCg0K ZXZlbnQ6IHsNCiAgZXZlbnRfdHlwZTogImZvbzpiYXIiLA0KICBmb286IHRoaW5nLA0KICAgYmFy OiBvdGhlci10aGluZywNCiAgIGJhejogZXh0ZW5zaW9uLXRoaW5nDQp9DQoNCk9yIHlvdSBjb3Vs ZCBtYWtlIHRoZSBsdmFsdWUgImJheiIgdG8gYmUgImZvbzpiYXI6YmF6IiBvciB3aGF0ZXZlci4g WW91IGNvdWxkIGFsdGVybmF0aXZlbHkgaGF2ZSBhbiAiZXh0ZW5zaW9ucyIgb2JqZWN0LCBidXQg dGhhdCBzZWVtcyBsaWtlIG92ZXJraWxsLiBKU09OIGluIHByYWN0aWNlIGlzIHNjaGVtYS1ieS1m aWF0OiB5b3UgbG9vayBmb3IgdGhpbmdzIHlvdSBrbm93IGFuZCBjYXJlIGFib3V0IGFuZCBpZ25v cmUgZXZlcnl0aGluZyBlbHNlLiBTbyBleHRlbnNpb25zIGNhbiBqdXN0IHN0YWNrIGluc2lkZSB0 aGUgZXZlbnQgb2JqZWN0LCBhbmQgbXVsdGlwbGUgZXh0ZW5zaW9ucyB0byB0aGUgc2FtZSBldmVu dCB0eXBlIHdpbGwgYWxyZWFkeSBuZWVkIHRvIGtub3cgdG8gc3RheSBvdXQgb2YgZWFjaCBvdGhl cnMnIHdheS4NCg0KLS0gSnVzdGluDQoNCk9uIE5vdmVtYmVyIDE0LCAyMDE3IDEwOjM1OjUxIEFN IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tPj4gd3JvdGU6DQpIb3cgZG8geW91IHByb3Bvc2UgdG8gaGFuZGxlIGV4dGVuc2lvbnMgb2Yg ZXZlbnQgdXJpcz8NCg0KUGhpbA0KDQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3Vk IFNlcnZpY2VzIEFyY2hpdGVjdA0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNv bTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQpPbiBOb3YgMTQsIDIwMTcsIGF0IDI6MjEgQU0s IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4g d3JvdGU6DQoNCkkgd2FudGVkIHRvIHRha2UgYSBmZXcgbW9tZW50cyB0byBnZXQgZG93biBvbiB2 aXJ0dWFsLXBhcGVyIHNvbWUgdGhvdWdodHMgYWJvdXQgdGhlIHN5bnRheCBhbmQgc2VtYW50aWNz IG9mIGEgU0VUIGZyb20gdG9kYXkncyBtZWV0aW5nLiBPcmlnaW5hbGx5LCB0aGUgZXZlbnQgc255 dGF4IHRoYXQgd2UgYnJvdWdodCB0byB0aGUgdGFibGUgZnJvbSB0aGUgQ29uc2VudCBSZWNlaXB0 cyB3b3JraW5nIGdyb3VwIGluIEthbnRhcmEgd2FzIHZlcnkgZXhwbGljaXRseSBhIHNpbmdsZSBl dmVudCBiZWluZyBkZXNjcmliZWQuIFdoZW4gUklTQywgT0lEQyBzZXNzaW9ucywgYW5kIGV2ZW50 dWFsbHkgU0NJTSBjYW1lIHRvIHRoZSBjb25lcnNhdGlvbiwgdGhlIGdyb3VwIGRlY2lkZWQgdG8g dHJ5IG91dCBhIHdheSB0byBleHByZXNzIG11bHRpcGxlIGFzcGVjdHMgb2YgYSBzaW5nbGUgZXZl bnQgaW4gYSBzaW5nbGUgdG9rZW4uIFdoaWxlIEkgc3RpbGwgYWdyZWUgd2l0aCB0aGlzIHByaW5j aXBsZSwgSSBjYW4gc2VlIG5vdyB0aGF0IGl0J3MgdG9vIG11Y2ggb2YgYSB0ZW1wdGF0aW9uIHRv IGV4cHJlc3MgZWl0aGVyIG11bHRpcGxlIGV2ZW50cyBvciBiZW5kIGFyb3VuZCB0aGUgc2VtYW50 aWNzIGluIHdheXMgdGhhdCBjb3VsZCBjYXVzZSBhIGxvdCBvZiBjb25mdXNpb24uIEkgbm93IHRo aW5rIHRoYXQgd2Ugc2hvdWxkIGNvbGxhcHNlIHRoZSBzeW50YXggYXMgQW5uYWJlbGxlIGhhcyBz dWdnZXN0ZWQgYW5kIGdvIGV2ZW4gZnVydGhlciB0byBzcGVjaWZ5IHdoYXQgY2FuIGdvIHdoZXJl LiBUbyB3aXQsIFNFVCBwYXlsb2FkIHByb2ZpbGVzIHNob3VsZCBvbmx5IGV2ZXIgdG91Y2ggdGhl IHRoaW5ncyBpbnNpZGUgdGhlIGV2ZW50IG9iamVjdC4gU28gSSdtIHByb3Bvc2luZyB0aGF0IHdl IGRvIHNvbWV0aGluZyBsaWtlIHRoaXM6DQoNCg0Kew0KaXNzOiA8LS0gc3RyaW5nIHJlcHJlc2Vu dGluZyB0aGUgaXNzdWVyIG9mIHRoZSBTRVQgaXRzZWxmDQpzdWI6IDwtLSBzdHJpbmcgcmVwcmVz ZW50aW5nIHRoZSBzdWJqZWN0IG9mIHRoZSBTRVQgZnJvbSB0aGUgIHZpZXcgb2YgdGhlIGlzc3Vl ciAoaWYga25vd24pLCBubyBmb3JtYXQgYXNzdW1lZA0KaWF0OiA8LS0gdGltZXN0YW1wIG9mIHdo ZW4gdGhlIFNFVCBXYXMgY3JlYXRlZCwgbm90IHRvIGJlIGNvbmZ1c2VkIHdpdGggdGhlIGV2ZW50 IHRpbWUNCmF1ZDogPC0tIGFycmF5IG9yIHN0cmluZyByZXByZWVzbnRpbmcgdGhlIHJlY2lwaWVu dHMgb2YgdGhpcyBTRVQsIGZyb20gdGhlIHZpZXcgb2YgdGhlIGlzc3VlciBvZiB0aGUgc0VUDQpl eHA6IDwtLSB0aW1lc3RhbXAgb2Ygd2hlbiB0aGUgU0VUIHNob3VsZG4ndCBiZSBwcm9jZXNzZWQg YW55bW9yZQ0KZXZlbnQ6IHsgPC0tIG9iamVjdCBmb3IgdGhlIGV2ZW50IGl0c2VsZiwgU0VUIHBy b2ZpbGVzIGRvIGFsbCBvZiB0aGVpciBkZWZpbml0aW9ucyBpbiBoZXJlDQogICB0b2U6IDwtLSB0 aW1lc3RhbXAgb2YgdGhlIGV2ZW50LCBpZiBrbm93bjsgaWYgbm90IHByZXNlbnQsIGV2ZW50IHRp bWUgaXMgdW5rbm93bg0KICAgaXNzOiA8LS0gaXNzdWVyIG5hbWVzcGFjZSBmb3IgdGhlIHN1Ympl Y3Qgb2YgdGhpcyBldmVudCwgYXMga25vd24gYnkgdGhlIHJlY2lwaWVudA0KICAgc3ViOiA8LS0g c3ViamVjdCBvZiB0aGUgZXZlbnQsIGFzIGtub3duIGJ5IHRoZSByZWNpcGllbnQsIG5hbWVzcGFj ZWQgYnkgZXZlbnQuaXNzDQogICB0eG46IDwtLSB0cmFuc2FjdGlvbiBpZGVudGlmaWVyIGZvciB0 eWluZyBtdWx0aXBsZSBldmVudHMgdG9nZXRoZXINCiAgIGV2ZW50X3R5cGU6IDwtLSBVUkkgcmVw cmVzZW50aW5nIHRoaXMgZXZlbnQncyB0eXBlLCBtdXN0IGJlIHVuZGVyc3Rvb2QgYnkgcmVjaXBp ZW50ICh3aG8gY2FuIGRvIGEgc3RyaW5nIG1hdGNoKSwgY2FuIGRlZmluZSBvdGhlciBhZGRpdGlv bmFsIGZpZWxkcyBhbmQgdGhlaXIgc2VtYW50aWNzDQp9DQp9DQoNCkFuZCB0byBMZWlmJ3MgcG9p bnQsIHRvIGhhdmUgYSBncm91cCBldmVudCB3ZSB3b3VsZCBkbzoNCg0KZXZlbnQ6IHsNCiBldmVu dF90eXBlOiB1cm46aWV0ZjpzZWNldmVudDpldmVudF9ncm91cA0KIDxhbnkgZXZlbnQgYXR0cmli dXRlcyB0aGF0IGFyZSBjb21tb24gdG8gdGhlIHdob2xlIHNldCwgbGlrZSB0eG4sIHRvZSwgc3Vi LCBldGM+DQogZXZlbnRzOiBbICA8LS0gYXJyYXkgb2YgZXZlbnQgb2JqZWN0cyB3aXRoIHRoZSBz ZW1hbnRpY3Mgb2YgdGhlIHJlZ3VsYXIgZXZlbnQgb2JqZWN0LCB0YWtlbiBhbGwgYXQgb25jZTsg Y2FuIHJlLXVzZSBhbnkgb2YgdGhlIHJvb3QgZXZlbnQgZWxlbWVudHMgZGVmaW5lZCBpbiBTRVQg YnV0IG11c3Qgbm90IHJlcGVhdCBhbnkgaW4gdGhlIHJvb3QgZXZlbnQncyBjb21tb24gYXR0cmli dXRlcw0KICBdDQp9DQoNCkV2ZW50IGdyb3VwcyBjcmVhdGUgc29tZSBpbnRlcm9wIGlzc3Vlcywg YXMgeW91IG5lZWQgdG8gaGF2ZSBjbGllbnRzIHRoYXQgY2FuIGhhbmRsZSBldmVudHMgaW4gYSBn cm91cCBhcyB3ZWxsIGFzIG9uIHRoZWlyIG93bi4gQnV0IHdpdGggdGhlIHdheSBwZW9wbGUgd2Vy ZSBkZXNjcmliaW5nIGV2ZW50IGdyb3VwcyB0b2RheSwgSSB0aGluayB0aGF0J3MgYWN0dWFsbHkg YSBnb29kIHRoaW5nIC0tIGl0IHdvdWxkIGZvcmNlIHJlY29nbml0aW9uIG9mIHRoZSBhc3NvY2lh dGVkIG5hdHVyZSBvZiBhbGwgdGhlIGNvbXBvbmVudHMuIElmIHlvdSBnZXQgYW4gZXZlbnQgZ3Jv dXAsIHlvdSBuZWVkIHRvIHVuZGVyc3RhbmQgZXZlcnl0aGluZyBpbiB0aGUgZ3JvdXAuIE5vIHBy aW1hcnkvc2Vjb25kYXJ5LCBubyBwcml0aWNhbCBmaWVsZHMgLS0gYWxsIG9yIG5vdGhpbmcuDQoN ClllcyB0aGlzIGlzIGEgY2hhbmdlIGZyb20gY3VycmVudCBzeW50YXggYW5kIHNlbWFudGljcywg YnV0IHRvIG1lIGl0IGZlZWxzIGxpa2UgYSByZXR1cm4gdG8gdGhlIGNvbnNlbnQgcmVjZWlwdCBw YXJ0IG9mIHRoZSByb290cy4NCg0KLS0gSnVzdGluDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZl bnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3 cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xO NEtaTkEmbT15Mk9QbGVVcjhFRUVNdkVNVmpITldObS1kRkpiblZjU3p0eHNCLWtwWUZnJnM9Rlp1 MUZscURYaFlFMkd6ZExQRnNiallHSVM4VVc5Q2RMc193T09kY0QtZyZlPQ0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5n IGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg0KDQoNCi0tDQpTdWJz Y3JpYmUgdG8gdGhlIEhBUkRUV0FSRTxodHRwOi8vaGFyZHR3YXJlLmNvbS8+IG1haWwgbGlzdCB0 byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hDQoNCg0KDQotLQ0KU3Vic2Ny aWJlIHRvIHRoZSBIQVJEVFdBUkU8aHR0cDovL2hhcmR0d2FyZS5jb20vPiBtYWlsIGxpc3QgdG8g bGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0KDQoNCg0KLS0NClN1YnNjcmli ZSB0byB0aGUgSEFSRFRXQVJFPGh0dHA6Ly9oYXJkdHdhcmUuY29tLz4gbWFpbCBsaXN0IHRvIGxl YXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCg== --_000_BA0E06F9A6B9454F88735ED0EA5AD657amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6 aG9lbnpiO30NCnNwYW4ubS01MTM0Njg1MTUxNDAxOTY3NTIwaG9lbnpiDQoJe21zby1zdHlsZS1u YW1lOm1fLTUxMzQ2ODUxNTE0MDE5Njc1MjBob2VuemI7fQ0Kc3Bhbi5tLTUxMzQ2ODUxNTE0MDE5 Njc1MjBtNjY2NTE2NjA0NzcxNzk2NTc4NWhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTptXy01MTM0 Njg1MTUxNDAxOTY3NTIwbV82NjY1MTY2MDQ3NzE3OTY1Nzg1aG9lbnpiO30NCnNwYW4ubS01MTM0 Njg1MTUxNDAxOTY3NTIwbTY2NjUxNjYwNDc3MTc5NjU3ODVtLTI5NTIwMzU2OTUwNzMwMzczNTZh cHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOm1fLTUxMzQ2ODUxNTE0MDE5Njc1MjBt XzY2NjUxNjYwNDc3MTc5NjU3ODVtXy0yOTUyMDM1Njk1MDczMDM3MzU2YXBwbGUtc3R5bGUtc3Bh bjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRob3NlIGFyZSBzZW1hbnRp Y3MgdGhhdCBjb3VsZCBiZSBkZWNsYXJlZCBieSBhIFByb2ZpbGluZyBTcGVjaWZpY2F0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW1hem9uIOKAkyBJZGVu dGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5G cm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5JZC1ldmVudCAmbHQ7aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9m IEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ VHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcgYXQgMTE6NTMgUE08YnI+DQo8Yj5UbzogPC9iPkRp Y2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+U2Vj RXZlbnQgJmx0O2lkLWV2ZW50QGlldGYub3JnJmd0OywgUGhpbCBIdW50ICZsdDtwaGlsLmh1bnRA b3JhY2xlLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtJZC1ldmVudF0gVGhvdWdo dHMgb24gU3ludGF4IGZyb20gdG9kYXkncyBtZWV0aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW4iPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gb3IgdGhlIHN0cmF3bWFuLCBubywgdGhlIElkUCB3 b3VsZG4ndCBuZWVkIGl0LiBBbiBhdWRpdCBzeXN0ZW0gdGhhdCBrbm93cyBhYm91dCB0aGUgUlAn cyBzdG9yYWdlL2xvb2t1cCBtaWdodCBuZWVkIGl0LiBUaGF0J3Mgd2h5LCBpZiB3ZSBpbmNsdWRl IGl0IGluIHRoZSBzcGVjLCB3ZSdkIHdhbnQgc29tZSBsYW5ndWFnZSBtYWtpbmcgaXQgY2xlYXIg dGhhdCBpdCdzIG9ubHkgd2l0aGluIHRoZSB2aWV3DQogb2YgdGhlIHBhcnR5IGdlbmVyYXRpbmcg dGhlIFNFVCBhbmQgdGhhdCBpZiBpdCdzIGZvciBjb25zdW1wdGlvbiBleHRlcm5hbGx5IHRoZSB1 c2VyIHNob3VsZCBiZSBpZGVudGlmaWVkIGJ5IGEgZmllbGQgaW4gdGhlIGV2ZW50LCBvciBldmVu dC5zdWIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0 OjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPi0tIEp1c3RpbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MTAu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMC4wcHQ7bWFyZ2luLWxlZnQ6MGlu Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk9uIE5vdmVtYmVyIDE0LCAyMDE3IDQ6MjA6 MjUgUE0gRGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBncmF5IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNS4wcHQ7bWFyZ2luLWxl ZnQ6NC41cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGFua3MgSnVzdGluLiA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPldoYXQgdmFsdWUgd291bGQg dGhlcmUgYmUgdG8gdGhlIElkUCB0byBoYXZlIHRoZSBSUCdzIGlkZW50aWZpZXI/IElzIHRoZXJl IGEgcmVhc29uIHRoZSBJZFAgbmVlZHMgaXQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkgd29ycnkgYWJvdXQgdGhlIHByaXZh Y3kgaW1wbGljYXRpb25zIG9mIHNoYXJpbmcgdGhlIGFkZGl0aW9uYWwgaWRlbnRpZmllciB0aGF0 IHRoZSBSUCBoYXMgdGhhdCB0aGUgSWRQIGRvZXMgbm90IGhhdmUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9uIFR1ZSwgTm92 IDE0LCAyMDE3IGF0IDQ6MTEgUE0sIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpq cmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5TdXJlLCBoZXJlJ3MgYSBzb21ld2hhdCBjb25jcmV0ZSBzdHJhd21hbi4gTGV0J3Mg c2F5IHlvdSd2ZSBnb3QgYW4gZXZlbnQgaXNzdWVkIGJ5IHRoZSBSUCBpbiBhbiBpZGVudGl0eSBz eXN0ZW0sIHNlbmRpbmcgaW5mb3JtYXRpb24gdG8gYW5vdGhlciBwYXJ0eSAoZWl0aGVyIHRoZSBJ ZFAgb3Igc29tZW9uZSBlbHNlKS4gVGhlICZxdW90O3N1YmplY3QmcXVvdDsgZnJvbSB0aGUgT0lE QyBwZXJzcGVjdGl2ZSBpcyB3aGF0DQogeW91J2QgZmluZCBpbiBhbiBJRCBUb2tlbiwgc2F5ICZx dW90O2FiY2QtMTIzNCZxdW90Oy4gVGhpcyBvbmx5IG1ha2VzIHNlbnNlIGluIHRoZSBjb250ZXgg b2YgdGhlIElkUCdzIGlzc3VlciwgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9pZC5leGFtcGxlLmNv bS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2lkLmV4YW1wbGUuY29tLzwvYT4mcXVvdDssIHNv IGl0IGRvZXNuJ3QgbWFrZSBzZW5zZSB0byBzZW5kIHRoZSBzdWJqZWN0IG9uIGl0cyBvd24gd2l0 aG91dCB0aGUgaXNzdWVyLg0KIEhvd2V2ZXIsIHRoZSBpc3N1ZXIgb2YgdGhlIFNFVCBpdHNlbGYg aXMgZ29pbmcgdG8gYmUgdGhlIFJQLCAmcXVvdDtycC1jbGllbnQtaWQtMTIzNCZxdW90OyBpbiB0 aGUgT0lEQyB3b3JsZCBvciBldmVuICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vcnAuZXhhbXBsZS5u ZXQvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9ycC5leGFtcGxlLm5ldC88L2E+JnF1b3Q7IGlu IGEgd2lkZXIgZWNvc3lzdGVtLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBw dDttYXJnaW4tbGVmdDowaW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TbyBpbiB0aGlz IGV4YW1wbGUsIHdlIHdhbnQgdG8gdGFsayBhYm91dCBhIHVzZXIgJnF1b3Q7YWJjZC0xMjM0JnF1 b3Q7IGZyb20gJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9pZC5leGFtcGxlLmNvbS8iIHRhcmdldD0i X2JsYW5rIj5odHRwczovL2lkLmV4YW1wbGUuY29tLzwvYT4mcXVvdDssIGJ1dCBpdCdzICZxdW90 O3JwLWNsaWVudC1pZC0xMjM0JnF1b3Q7IHRoYXQncyB0YWxraW5nIGFib3V0IHRoYXQgdXNlci4g V2hpY2ggZ2l2ZXMgdXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJn aW4tbGVmdDowaW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj57PGJyPg0KJm5ic3A7ICZx dW90O2lzcyZxdW90OzogJnF1b3Q7cnAtY2xpZW50LTEyMzQmcXVvdDssPGJyPg0KJm5ic3A7ICZx dW90O2V2ZW50JnF1b3Q7OiB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2lzcyZxdW90 OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9pZC5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2lkLmV4YW1wbGUuY29tLzwvYT4mcXVvdDssPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7ICZxdW90O3N1YiZxdW90OzogJnF1b3Q7YWJjZC0xMjM0JnF1b3Q7PGJyPg0KJm5ic3A7IH08 YnI+DQp9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDow aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TbyB3aHkgd291bGQgeW91IHVzZSAmcXVv dDtzdWImcXVvdDsgYXQgdGhlIHJvb3Q/IE9ubHkgaWYgdGhlIGlzc3VlciBvZiB0aGUgU0VUIGhh cyB0aGVpciBvd24sIGluZGVwZW5kZW50IHdheSB0byBsb29rIGF0IHRoZSB1c2VyLiBJbiBvdXIg Y2FzZSwgbGV0J3Mgc2F5IHRoZSBSUCBoYXMgYSBsb2NhbCB1c2VybmFtZSBpZGVudGlmaWVyIG9m ICZxdW90O3VzZXItOTg3NiZxdW90OywgeW91IGNvdWxkIGhhdmU6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj57PGJyPg0KJm5ic3A7ICZxdW90O2lzcyZxdW90OzogJnF1b3Q7cnAtY2xpZW50LTEy MzQmcXVvdDssPGJyPg0KJm5ic3A7ICZxdW90O3N1YiZxdW90OzogJnF1b3Q7dXNlci05ODc2JnF1 b3Q7LDxicj4NCiZuYnNwOyAmcXVvdDtldmVudCZxdW90Ozogezxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyAmcXVvdDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vaWQuZXhhbXBsZS5j b20vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9pZC5leGFtcGxlLmNvbS88L2E+JnF1b3Q7LDxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtzdWImcXVvdDs6ICZxdW90O2FiY2QtMTIzNCZx dW90Ozxicj4NCiZuYnNwOyB9PGJyPg0KfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTox Mi4wcHQ7bWFyZ2luLWxlZnQ6MGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSB0aGlu ayB0aGF0IHRoZSB1c2Ugb2YgJnF1b3Q7c3ViJnF1b3Q7IGF0IHRoZSByb290IHNob3VsZCBiZSBs ZXNzIGNvbW1vbiB0aGFuIHRoZSB1c2Ugb2YgJnF1b3Q7ZXZlbnQuc3ViJnF1b3Q7LCBpbiB0aCB1 c2UgY2FzZXMgdGhhdCBwZW9wbGUgaGF2ZSBicm91Z2h0IHVwIGhlcmUuIEknbSBhZ2FpbnN0IHVz aW5nICZxdW90O3N1YiZxdW90OyBhcyBhIHNob3J0Y3V0IGZvciAmcXVvdDtldmVudC5zdWImcXVv dDssIGFzIGhhcyBiZWVuIHN1Z2dlc3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 MTIuMHB0O21hcmdpbi1sZWZ0OjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPi0tIEp1 c3RpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDoxMC4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjEwLjBwdDttYXJnaW4tbGVmdDowaW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+T24gTm92ZW1iZXIgMTQsIDIwMTcgMTo0NzowNSBQTSBEaWNrIEhhcmR0ICZsdDs8YSBo cmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhh cmR0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBncmF5IDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNS4wcHQ7bWFyZ2luLWxlZnQ6NC41cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5IZXkgSnVzdGluLCBJJ20gaGF2aW5nIGEgaGFyZCB0aW1lIHVuZGVyc3RhbmRpbmcgdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiAmcXVvdDtzdWImcXVvdDsgYW5kICZxdW90O2V2ZW50LnN1YiZxdW90 Oy4gRG8geW91IGhhdmUgYW4gZXhhbXBsZSB0aGF0IGhpZ2hsaWdodCB0aGUgc2VtYW50aWMgZGlm ZmVyZW5jZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPk9uIFR1ZSwgTm92IDE0LCAyMDE3IGF0IDE6MzggUE0sIEp1c3RpbiBSaWNoZXIgJmx0 OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVy QG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW4iPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5ZZXMsIHRoZXkncmUgaW50ZW5kZWQgdG8gYmUgcG90 ZW50aWFsbHkgZGlmZmVyZW50IHZhbHVlcyBidXQgY291bGQgYmUgdGhlIHNhbWUgaW4gc29tZSBj aXJjdW1zdGFuY2VzLiBTeW50YWN0aWNhbGx5LCBvbmUgaXMgJnF1b3Q7c3ViJnF1b3Q7IGFuZCB0 aGUgb3RoZXIgaXMgJnF1b3Q7ZXZlbnQuc3ViJnF1b3Q7LiZuYnNwOyBJJ2QgYmUgcGVyZmVjdGx5 IGhhcHB5IHJlbmFtaW5nIHRoZSAmcXVvdDtldmVudC5zdWImcXVvdDsgY2xhaW0gdG8gJnF1b3Q7 ZXZlbnQuZXZlbnRfc3ViJnF1b3Q7DQogb3Igc29tZXRoaW5nLCBhbmQgSSB0aGluayB0aGUgJnF1 b3Q7cmlzY19zdWJqZWN0JnF1b3Q7IHdpdGggYW4gb2JqZWN0IHR5cGUgaXMgYWxzbyBwZXJmZWN0 bHkgcmVhc29uYWJsZSBhcyBpdCdzIHByb3ZpZGluZyBkYXRhIGJleW9uZCB3aGF0IHRoZSByZWd1 bGFyICZxdW90O2V2ZW50LnN1YiZxdW90OyB3b3VsZCBkbyAoYXMgYSBzdHJpbmcpLiBTZW1hbnRp Y2FsbHksICZxdW90O3N1YiZxdW90OyBpcyBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgaXNz dWVyIG9mIHRoZSBTRVQgYW5kICZxdW90O2V2ZW50LnN1YiZxdW90Ow0KIGlzIHRoZSBwZXJzcGVj dGl2ZSBvZiB0aGUgcmVjZWl2ZXIgb2YgdGhlIFNFVC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si Pi0tIEp1c3RpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDoxMC4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjEwLjBwdDttYXJnaW4tbGVmdDowaW4iPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+T24gTm92ZW1iZXIgMTQsIDIwMTcgMTE6NDk6MjcgQU0gRGljayBIYXJkdCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgZ3JheSAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDUuMHB0O21hcmdpbi1sZWZ0OjQuNXB0O21hcmdpbi1y aWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+SnVzdGluOiB5b3UgaGF2ZSAmcXVvdDtzdWImcXVvdDsgYWJvdmUgdGhlIGV2ZW50 LCBhbmQgd2l0aGluIHRoZSBldmVudC4gSSB0aGluayB0aGVyZSBhcmUgZGlmZmVyZW50IHZhbHVl cywgYnV0IGl0IGlzIG5vdCBjbGVhci4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5PbiBUdWUsIE5vdiAxNCwgMjAxNyBhdCAxMTo0MiBBTSwgSnVzdGluIFJpY2hlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0 LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbiI+DQo8c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkV4dGVuc2lvbnMgdG8gZXZlbnQgdHlwZXMganVzdCBleHRl bmQgdGhlIGV2ZW50IG9iamVjdCBpdHNlbGYuIFNvIGVhY2ggZXZlbnQgdHlwZSBjb250cm9scyB0 aGUgbmFtZXNwYWNlIHdpdGhpbiBpdHMgZXZlbnQgb2JqZWN0IGFuZCBjYW4gYWxsb3cgYWRkaXRp b25hbCBiaXRzIGluIGl0LiBTbyBsZXQncyBzYXkgeW91J3ZlIGdvdDo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbiI+DQo8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPmV2ZW50OiB7PGJyPg0KJm5ic3A7IGV2ZW50X3R5cGU6ICZxdW90O2ZvbzpiYXIm cXVvdDssPGJyPg0KJm5ic3A7IGZvbzogdGhpbmcsPGJyPg0KJm5ic3A7IGJhcjogb3RoZXItdGhp bmc8YnI+DQombmJzcDsgLi4uPGJyPg0KfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTox Mi4wcHQ7bWFyZ2luLWxlZnQ6MGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QW5kIHlv dSB3YW50IHRvIGV4dGVuZCAmcXVvdDtmb286YmFyJnF1b3Q7IHdpdGggdGhlICZxdW90O2Zvbzpi YXI6YmF6JnF1b3Q7IGV4dGVuc2lvbiB5b3UgY291bGQgZWFzaWx5IGRvIHNvbWV0aGluZyBsaWtl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGlu O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGluIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ZXZlbnQ6IHs8YnI+DQombmJzcDsgZXZlbnRfdHlw ZTogJnF1b3Q7Zm9vOmJhciZxdW90Oyw8YnI+DQombmJzcDsgZm9vOiB0aGluZyw8YnI+DQombmJz cDsmbmJzcDsgYmFyOiBvdGhlci10aGluZyw8YnI+DQombmJzcDsmbmJzcDsgYmF6OiBleHRlbnNp b24tdGhpbmc8YnI+DQp9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJn aW4tbGVmdDowaW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5PciB5b3UgY291bGQgbWFr ZSB0aGUgbHZhbHVlICZxdW90O2JheiZxdW90OyB0byBiZSAmcXVvdDtmb286YmFyOmJheiZxdW90 OyBvciB3aGF0ZXZlci4gWW91IGNvdWxkIGFsdGVybmF0aXZlbHkgaGF2ZSBhbiAmcXVvdDtleHRl bnNpb25zJnF1b3Q7IG9iamVjdCwgYnV0IHRoYXQgc2VlbXMgbGlrZSBvdmVya2lsbC4gSlNPTiBp biBwcmFjdGljZSBpcyBzY2hlbWEtYnktZmlhdDogeW91IGxvb2sgZm9yIHRoaW5ncyB5b3Uga25v dyBhbmQgY2FyZSBhYm91dA0KIGFuZCBpZ25vcmUgZXZlcnl0aGluZyBlbHNlLiBTbyBleHRlbnNp b25zIGNhbiBqdXN0IHN0YWNrIGluc2lkZSB0aGUgZXZlbnQgb2JqZWN0LCBhbmQgbXVsdGlwbGUg ZXh0ZW5zaW9ucyB0byB0aGUgc2FtZSBldmVudCB0eXBlIHdpbGwgYWxyZWFkeSBuZWVkIHRvIGtu b3cgdG8gc3RheSBvdXQgb2YgZWFjaCBvdGhlcnMnIHdheS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+LS0gSnVzdGluPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjEwLjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206MTAuMHB0O21hcmdpbi1sZWZ0OjBpbiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5PbiBOb3ZlbWJlciAxNCwgMjAxNyAxMDozNTo1MSBBTSBQaGlsIEh1 bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGdy YXkgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA1LjBwdDttYXJnaW4tbGVmdDo0LjVwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+SG93IGRvIHlvdSBwcm9wb3NlIHRvIGhhbmRsZSBleHRlbnNpb25zIG9mIGV2ZW50IHVy aXM/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T3JhY2xlIENvcnBvcmF0aW9uLCBJZGVudGl0eSBD bG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkBpbmRl cGVuZGVudGlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3 LmluZGVwZW5kZW50aWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+d3d3LmluZGVwZW5kZW50aWQuY29t PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5PbiBOb3YgMTQsIDIwMTcsIGF0IDI6MjEgQU0sIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5l ZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkkgd2FudGVkIHRvIHRha2UgYSBmZXcgbW9tZW50cyB0byBnZXQgZG93 biBvbiB2aXJ0dWFsLXBhcGVyIHNvbWUgdGhvdWdodHMgYWJvdXQgdGhlIHN5bnRheCBhbmQgc2Vt YW50aWNzIG9mIGEgU0VUIGZyb20gdG9kYXkncyBtZWV0aW5nLiBPcmlnaW5hbGx5LCB0aGUgZXZl bnQgc255dGF4IHRoYXQgd2UgYnJvdWdodCB0byB0aGUgdGFibGUgZnJvbSB0aGUgQ29uc2VudA0K IFJlY2VpcHRzIHdvcmtpbmcgZ3JvdXAgaW4gS2FudGFyYSB3YXMgdmVyeSBleHBsaWNpdGx5IGEg c2luZ2xlIGV2ZW50IGJlaW5nIGRlc2NyaWJlZC4gV2hlbiBSSVNDLCBPSURDIHNlc3Npb25zLCBh bmQgZXZlbnR1YWxseSBTQ0lNIGNhbWUgdG8gdGhlIGNvbmVyc2F0aW9uLCB0aGUgZ3JvdXAgZGVj aWRlZCB0byB0cnkgb3V0IGEgd2F5IHRvIGV4cHJlc3MgbXVsdGlwbGUgYXNwZWN0cyBvZiBhIHNp bmdsZSBldmVudCBpbiBhIHNpbmdsZSB0b2tlbi4NCiBXaGlsZSBJIHN0aWxsIGFncmVlIHdpdGgg dGhpcyBwcmluY2lwbGUsIEkgY2FuIHNlZSBub3cgdGhhdCBpdCdzIHRvbyBtdWNoIG9mIGEgdGVt cHRhdGlvbiB0byBleHByZXNzIGVpdGhlciBtdWx0aXBsZSBldmVudHMgb3IgYmVuZCBhcm91bmQg dGhlIHNlbWFudGljcyBpbiB3YXlzIHRoYXQgY291bGQgY2F1c2UgYSBsb3Qgb2YgY29uZnVzaW9u LiBJIG5vdyB0aGluayB0aGF0IHdlIHNob3VsZCBjb2xsYXBzZSB0aGUgc3ludGF4IGFzIEFubmFi ZWxsZQ0KIGhhcyBzdWdnZXN0ZWQgYW5kIGdvIGV2ZW4gZnVydGhlciB0byBzcGVjaWZ5IHdoYXQg Y2FuIGdvIHdoZXJlLiBUbyB3aXQsIFNFVCBwYXlsb2FkIHByb2ZpbGVzIHNob3VsZCBvbmx5IGV2 ZXIgdG91Y2ggdGhlIHRoaW5ncyBpbnNpZGUgdGhlIGV2ZW50IG9iamVjdC4gU28gSSdtIHByb3Bv c2luZyB0aGF0IHdlIGRvIHNvbWV0aGluZyBsaWtlIHRoaXM6PGJyPg0KPGJyPg0KPGJyPg0Kezxi cj4NCmlzczogJmx0Oy0tIHN0cmluZyByZXByZXNlbnRpbmcgdGhlIGlzc3VlciBvZiB0aGUgU0VU IGl0c2VsZjxicj4NCnN1YjogJmx0Oy0tIHN0cmluZyByZXByZXNlbnRpbmcgdGhlIHN1YmplY3Qg b2YgdGhlIFNFVCBmcm9tIHRoZSAmbmJzcDt2aWV3IG9mIHRoZSBpc3N1ZXIgKGlmIGtub3duKSwg bm8gZm9ybWF0IGFzc3VtZWQ8YnI+DQppYXQ6ICZsdDstLSB0aW1lc3RhbXAgb2Ygd2hlbiB0aGUg U0VUIFdhcyBjcmVhdGVkLCBub3QgdG8gYmUgY29uZnVzZWQgd2l0aCB0aGUgZXZlbnQgdGltZTxi cj4NCmF1ZDogJmx0Oy0tIGFycmF5IG9yIHN0cmluZyByZXByZWVzbnRpbmcgdGhlIHJlY2lwaWVu dHMgb2YgdGhpcyBTRVQsIGZyb20gdGhlIHZpZXcgb2YgdGhlIGlzc3VlciBvZiB0aGUgc0VUPGJy Pg0KZXhwOiAmbHQ7LS0gdGltZXN0YW1wIG9mIHdoZW4gdGhlIFNFVCBzaG91bGRuJ3QgYmUgcHJv Y2Vzc2VkIGFueW1vcmU8YnI+DQpldmVudDogeyAmbHQ7LS0gb2JqZWN0IGZvciB0aGUgZXZlbnQg aXRzZWxmLCBTRVQgcHJvZmlsZXMgZG8gYWxsIG9mIHRoZWlyIGRlZmluaXRpb25zIGluIGhlcmU8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDt0b2U6ICZsdDstLSB0aW1lc3RhbXAgb2YgdGhlIGV2ZW50 LCBpZiBrbm93bjsgaWYgbm90IHByZXNlbnQsIGV2ZW50IHRpbWUgaXMgdW5rbm93bjxicj4NCiZu YnNwOyZuYnNwOyZuYnNwO2lzczogJmx0Oy0tIGlzc3VlciBuYW1lc3BhY2UgZm9yIHRoZSBzdWJq ZWN0IG9mIHRoaXMgZXZlbnQsIGFzIGtub3duIGJ5IHRoZSByZWNpcGllbnQ8YnI+DQombmJzcDsm bmJzcDsmbmJzcDtzdWI6ICZsdDstLSBzdWJqZWN0IG9mIHRoZSBldmVudCwgYXMga25vd24gYnkg dGhlIHJlY2lwaWVudCwgbmFtZXNwYWNlZCBieSBldmVudC5pc3M8YnI+DQombmJzcDsmbmJzcDsm bmJzcDt0eG46ICZsdDstLSB0cmFuc2FjdGlvbiBpZGVudGlmaWVyIGZvciB0eWluZyBtdWx0aXBs ZSBldmVudHMgdG9nZXRoZXI8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtldmVudF90eXBlOiAmbHQ7 LS0gVVJJIHJlcHJlc2VudGluZyB0aGlzIGV2ZW50J3MgdHlwZSwgbXVzdCBiZSB1bmRlcnN0b29k IGJ5IHJlY2lwaWVudCAod2hvIGNhbiBkbyBhIHN0cmluZyBtYXRjaCksIGNhbiBkZWZpbmUgb3Ro ZXIgYWRkaXRpb25hbCBmaWVsZHMgYW5kIHRoZWlyIHNlbWFudGljczxicj4NCn08YnI+DQp9PGJy Pg0KPGJyPg0KQW5kIHRvIExlaWYncyBwb2ludCwgdG8gaGF2ZSBhIGdyb3VwIGV2ZW50IHdlIHdv dWxkIGRvOjxicj4NCjxicj4NCmV2ZW50OiB7PGJyPg0KJm5ic3A7ZXZlbnRfdHlwZTogdXJuOmll dGY6c2VjZXZlbnQ6ZXZlbnRfZ3JvdXA8YnI+DQombmJzcDsmbHQ7YW55IGV2ZW50IGF0dHJpYnV0 ZXMgdGhhdCBhcmUgY29tbW9uIHRvIHRoZSB3aG9sZSBzZXQsIGxpa2UgdHhuLCB0b2UsIHN1Yiwg ZXRjJmd0Ozxicj4NCiZuYnNwO2V2ZW50czogWyAmbmJzcDsmbHQ7LS0gYXJyYXkgb2YgZXZlbnQg b2JqZWN0cyB3aXRoIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHJlZ3VsYXIgZXZlbnQgb2JqZWN0LCB0 YWtlbiBhbGwgYXQgb25jZTsgY2FuIHJlLXVzZSBhbnkgb2YgdGhlIHJvb3QgZXZlbnQgZWxlbWVu dHMgZGVmaW5lZCBpbiBTRVQgYnV0IG11c3Qgbm90IHJlcGVhdCBhbnkgaW4gdGhlIHJvb3QgZXZl bnQncyBjb21tb24gYXR0cmlidXRlczxicj4NCiZuYnNwOyZuYnNwO108YnI+DQp9PGJyPg0KPGJy Pg0KRXZlbnQgZ3JvdXBzIGNyZWF0ZSBzb21lIGludGVyb3AgaXNzdWVzLCBhcyB5b3UgbmVlZCB0 byBoYXZlIGNsaWVudHMgdGhhdCBjYW4gaGFuZGxlIGV2ZW50cyBpbiBhIGdyb3VwIGFzIHdlbGwg YXMgb24gdGhlaXIgb3duLiBCdXQgd2l0aCB0aGUgd2F5IHBlb3BsZSB3ZXJlIGRlc2NyaWJpbmcg ZXZlbnQgZ3JvdXBzIHRvZGF5LCBJIHRoaW5rIHRoYXQncyBhY3R1YWxseSBhIGdvb2QgdGhpbmcg LS0gaXQgd291bGQgZm9yY2UgcmVjb2duaXRpb24gb2YNCiB0aGUgYXNzb2NpYXRlZCBuYXR1cmUg b2YgYWxsIHRoZSBjb21wb25lbnRzLiBJZiB5b3UgZ2V0IGFuIGV2ZW50IGdyb3VwLCB5b3UgbmVl ZCB0byB1bmRlcnN0YW5kIGV2ZXJ5dGhpbmcgaW4gdGhlIGdyb3VwLiBObyBwcmltYXJ5L3NlY29u ZGFyeSwgbm8gcHJpdGljYWwgZmllbGRzIC0tIGFsbCBvciBub3RoaW5nLjxicj4NCjxicj4NClll cyB0aGlzIGlzIGEgY2hhbmdlIGZyb20gY3VycmVudCBzeW50YXggYW5kIHNlbWFudGljcywgYnV0 IHRvIG1lIGl0IGZlZWxzIGxpa2UgYSByZXR1cm4gdG8gdGhlIGNvbnNlbnQgcmVjZWlwdCBwYXJ0 IG9mIHRoZSByb290cy48YnI+DQo8YnI+DQotLSBKdXN0aW48YnI+DQo8YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50 IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055 NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPXkyT1BsZVVyOEVFRU12RU1WakhOV05t LWRGSmJuVmNTenR4c0Ita3BZRmcmYW1wO3M9Rlp1MUZscURYaFlFMkd6ZExQRnNiallHSVM4VVc5 Q2RMc193T09kY0QtZyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4 UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZ cVBrQUkxYUxjTE40S1pOQSZhbXA7bT15Mk9QbGVVcjhFRUVNdkVNVmpITldObS1kRkpiblZjU3p0 eHNCLWtwWUZnJmFtcDtzPUZadTFGbHFEWGhZRTJHemRMUEZzYmpZR0lTOFVXOUNkTHNfd09PZGNE LWcmYW1wO2U9PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2 ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxiciBj bGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPlN1YnNjcmliZSB0byB0aGUgPGEgaHJlZj0iaHR0cDovL2hhcmR0d2FyZS5jb20vIiB0 YXJnZXQ9Il9ibGFuayI+DQpIQVJEVFdBUkU8L2E+IG1haWwgbGlzdCB0byBsZWFybiBhYm91dCBw cm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si Pjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlN1YnNjcmliZSB0byB0aGUgPGEgaHJlZj0iaHR0cDovL2hhcmR0 d2FyZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+DQpIQVJEVFdBUkU8L2E+IG1haWwgbGlzdCB0byBs ZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlN1YnNjcmliZSB0byB0aGUgPGEgaHJlZj0i aHR0cDovL2hhcmR0d2FyZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+DQpIQVJEVFdBUkU8L2E+IG1h aWwgbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_BA0E06F9A6B9454F88735ED0EA5AD657amazoncom_-- From nobody Tue Nov 14 20:36:02 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871BC1242EA for ; Tue, 14 Nov 2017 20:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dqCpkqshCvY for ; Tue, 14 Nov 2017 20:36:00 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA88F126E64 for ; Tue, 14 Nov 2017 20:35:59 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id q1so15502577ywh.5 for ; Tue, 14 Nov 2017 20:35:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XXcnTVxP12lD7TrL2KZIC0/wUJMnoO1twgu4JVez39M=; b=QfuIvPvUaNrGZ+7GmENlWReftbiONYmWDI+3dGuOdHmtWL8k3+SgOTWGtceBxVxfh3 VLNhDfRKGqzymQUCLZhjV2Ctu4t8xyTCc8DA7homdaGqjnerZAc8Ck1/QexDAd9HwKPz 4cJINSjpTtNYoeopGNBVxthxwbP6O40i5r+JeYUR4GvMoBq2bcsq1YMAFcJVwC1FWThr otecLtue2qFWgOONDIm/2YEic+CL6Xlui+iPv7YdI8Fj5QL1vIxdNormt6pEotrS0iTT 1/AcEsEsH5VYU3O3XXWiTSYDeKAQ7uoo7yCu5Ij15hmZ7B9ypfw7RuADUDbAqUOjlKS3 QJpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XXcnTVxP12lD7TrL2KZIC0/wUJMnoO1twgu4JVez39M=; b=j7deVmg7iLwM03qMcJpq9IgUB7BorlZ7u/gR3uzOzE6Zs075XOjDjd2eeHbuBY558D 5jwFZL2MMHkoLSo3wt31cT8LoWjZAEmrpcabwqcl6ohYDpmx/NhTQOVKUvQ/OCLsNjp6 1X8bCIiZQKyAd3exSNOQWTFe5KCNRxBNrtwF/eGL5zt8Lf1c9ANJtbWUSskHNhKCJf6K tw5DTVrRJxgmPG+efH9gLY/rAv/T92Ts4W1XrR3ipwJi01uXMUNTvxb+U9eP5Gh7noAZ 6s/4f5zUdWImSmOZTdFhTVdBSBJ0BHj57eUotOFaiWc5Dj5mnrfUjSgJtHwlSOIBFi17 2WMA== X-Gm-Message-State: AJaThX5ilXJjRkZ8JvZxq5DBKE6KDYdOTyJ1NFNHFyz6fzMeb29EZvqH k43KwUilTVUmlHcx/w0qnQ5OkDwH0tnKnI1t7xxxQLzP X-Google-Smtp-Source: AGs4zMZf9kA3fBvpR4n6uiXx2a0HKu6U0zg3mEdk9L7Eaxxt/+6OH+S5+0LXfcykvEMbpAEw2Kag6PZvG6BuEjCh9nI= X-Received: by 10.37.55.143 with SMTP id e137mr1503520yba.8.1510720558592; Tue, 14 Nov 2017 20:35:58 -0800 (PST) MIME-Version: 1.0 From: Luke Camery Date: Wed, 15 Nov 2017 04:35:47 +0000 Message-ID: To: id-event@ietf.org Content-Type: multipart/alternative; boundary="001a11473dae405e6f055dfe0a2a" Archived-At: Subject: [Id-event] [Update] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 04:36:01 -0000 --001a11473dae405e6f055dfe0a2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We *potentially* have the room Clark from 1:20-3:20. Confirmation will follow. On Tue, Nov 14, 2017, 11:45 AM Luke Camery wrote: > *Future Meetings* > Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative SET > Proposal > Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane > Friday - 10:00-18:00 at Google Singapore (70 Pasir Panjang Road, #03-71, > 117371) on Work Session > > -- > > * =E2=80=A2 **Luke Camery* > * =E2=80=A2 *Associate Product Manager > * =E2=80=A2 *Federated Identity > > --001a11473dae405e6f055dfe0a2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    We *potentially* have the room Clark from 1:20-3:20. Conf= irmation will follow.=C2=A0

    On Tue, Nov 14, 2017, 11:45 AM Luke Camery <lcamery@google.com> wrote:
    Future Meetings
    Wednesday = - 10:30-12:00 in Butterworth on Annabelle's Alternative SET ProposalThursday - 15:30-18:00 in the Atrium on Marius' Control Plane
    Friday - 10:00-18:00 at Google Singapore (70 Pasir Panjang Road, #03-71, 117371) on Work Session

    --
    =C2=A0 =E2=80= =A2 =C2=A0Luke Camery
    =C2=A0 =E2=80=A2 =C2=A0Associ= ate Product Manager
    =C2=A0 =E2=80=A2 =C2=A0Federated Identity<= /blockquote>
    --001a11473dae405e6f055dfe0a2a-- From nobody Tue Nov 14 21:01:54 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4706D127873 for ; Tue, 14 Nov 2017 21:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_H27lkrWbse for ; Tue, 14 Nov 2017 21:01:50 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C85E1242EA for ; Tue, 14 Nov 2017 21:01:50 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id 4so8266107pge.1 for ; Tue, 14 Nov 2017 21:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wTHX2PZd+/EFxuBnmdLiBLnx2Ly2WkTj/CXovazre1Y=; b=F/TN1v7io3fPO2WMpIm0VQJQUoYbld1d6KMPjKY8XMizwX6dbgt70pCAelgtjfwNiw 1ikoZ5OJs0x7cPyX+Lfm2MsaOhktCSiBG+0Qi9BttINYsaLhqdYTTVDd4+qUA+qaRJ0E bsCgRcGU+FS9UHl6QyCb0UQAtIxuSIA5mzbSLKvi/uZl9o9Iqumq1onIznmumkrsyDgp JQ6ZtyEcfYbEJzLKSC+4hWwAP9vNxz8O5eFNVNS7LXBNKaUMR14xp6yIKxXJaFcgerKx ojK+0uEhASfREUYj9Nd1coDq2nB3TSHUpb+ZyYbAU4qC7TUYe97OXo5pgpXEWhye60bo FrkQ== 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=wTHX2PZd+/EFxuBnmdLiBLnx2Ly2WkTj/CXovazre1Y=; b=OC5uGz5mLrPhQZ2/wWiBqFOcxKF36/J6bGbpO5oLFsavLLhZaOlGcnnlL61TJ0CRGW gcn8zfCNHypI15516g2do+8L+gLwHLYCLjllvYML53IcqZBfus8/CUI0ofiz1WdcfbNd 7qLXDP0hBx0ACR0dePtIDTqD1T9TauHOsubO5rZrLJ1tjO2+wjT0R8QX3UJgAftqEukX YRpn5M4S7mdGmLRKpQ28l9PXrBytyQcjzpgttFy+JYfGnzsMnDPh2D6Rgwdc2w7aF34r P+QmBccI0uGGLXFOIvkps+QP4S7NR8p8KBfRr2rcQeuGl8sloMSFEa0m+b/hrKsVx4v9 yD3A== X-Gm-Message-State: AJaThX7Ty17ffXN8dsDWRNq6tmsN6P8EzFft0WhuPhvHr1+TmRalhugn +qGg9noaQD9m8KIuJPaGvh3JSmmujXKHpz2e4zc= X-Google-Smtp-Source: AGs4zMbVPckuuXXSz4jyGBl3xEB2Kwvd8j6rLfSjD6B+3noYaMMXM1ornXyGc7Qp6hzD1bhSL7jg88iHgV2GBEfKF5U= X-Received: by 10.84.132.35 with SMTP id 32mr13178598ple.225.1510722109616; Tue, 14 Nov 2017 21:01:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.190.1 with HTTP; Tue, 14 Nov 2017 21:01:29 -0800 (PST) In-Reply-To: References: From: Dick Hardt Date: Wed, 15 Nov 2017 13:01:29 +0800 Message-ID: To: Luke Camery Cc: SecEvent Content-Type: multipart/alternative; boundary="94eb2c119f82b2b712055dfe66a1" Archived-At: Subject: Re: [Id-event] [Update] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 05:01:52 -0000 --94eb2c119f82b2b712055dfe66a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No one has that room currently at that time. I'm trying to find an AD to schedule it for us. If anyone else comes across an AD, please ask them to reserve it for us. If nothing else, we can ask the people in that room right now if we can have it later on. On Wed, Nov 15, 2017 at 12:35 PM, Luke Camery wrote: > We *potentially* have the room Clark from 1:20-3:20. Confirmation will > follow. > > On Tue, Nov 14, 2017, 11:45 AM Luke Camery wrote: > >> *Future Meetings* >> Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative SET >> Proposal >> Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane >> Friday - 10:00-18:00 at Google Singapore (70 Pasir Panjang Road, #03-71, >> 117371) on Work Session >> >> -- >> >> * =E2=80=A2 **Luke Camery* >> * =E2=80=A2 *Associate Product Manager >> * =E2=80=A2 *Federated Identity >> >> > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --94eb2c119f82b2b712055dfe66a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    No one has that room currently at that time. I'm tryin= g to find an AD to schedule it for us. If anyone else comes across an AD, p= lease ask them to reserve it for us.

    If nothing else, we= can ask the people in that room right now if we can have it later on.




    On Wed, Nov 15, 2017 at 12:35 PM, Luke C= amery <lcamery@google.com> wrote:
    We *potentially* have the room Clark from 1:20-3= :20. Confirmation will follow.=C2=A0

    On Tue, Nov 14, 2017, 11:45 AM Luke Camery <lcamery@google.com> wrote= :
    Future M= eetings
    Wednesday - 10:30-12:00 in Butterworth on Annabelle's = Alternative SET Proposal
    Thursday - 15:30-18:00 in the Atrium on Marius= ' Control Plane
    Friday - 10:00-18:00 at Google Singapore (70 Pasir Panjang Road, #03-71, 117371) on Work = Session

    --
    =C2=A0 =E2=80=A2 =C2=A0Luke Camery
    =C2=A0 = =E2=80=A2 =C2=A0Associate Product Manager
    =C2=A0 =E2=80=A2 =C2=A0Feder= ated Identity

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    =
    Subscribe to the HARDTWARE mail list to learn abou= t projects I am working on!
    --94eb2c119f82b2b712055dfe66a1-- From nobody Tue Nov 14 21:11:02 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A4D1271DF for ; Tue, 14 Nov 2017 21:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJrDSVYTguoP for ; Tue, 14 Nov 2017 21:10:58 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::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 42400127B73 for ; Tue, 14 Nov 2017 21:10:58 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id t10so16150900pgo.3 for ; Tue, 14 Nov 2017 21:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S/23N6b3qG7nHPKcvuM1MVRtBJekUwaY2xiqiqv7L+M=; b=U9BqGrJqk2ahDZss6OcOockWC8+LGs7zc3BWuLj07dycGLzbRCE0AP+wmN5heGXkzh jHhUzijbOXrFuD9r1EeeZgLMKECIFOdKNpgm0PggStxmole5Vm/MGq+rffyyDQuMBCvd josB0mBSsyO3ksx2G/2zNW+ZjV2KCAIPaUt8NRozdLkZzh+5pnVC72J+YtLbD1TF/bqH ACP8nfz9AA/zGh8m8qdIZ/qxQpXaLB0LgW4OhCfwi+xxzsnEDYnxS8V2tgYnqJxhIZAv p2Uy5fdFkxPaykvGHT+Wt045JflDz2fjgHJN+vRpcYNVHWHMFv0qfhaPUfaRwEo30WeZ dGMA== 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=S/23N6b3qG7nHPKcvuM1MVRtBJekUwaY2xiqiqv7L+M=; b=jk11u6zzAefyN/dKAfN+ne12jrhxsO12YegF8g4alyl9fKCTpqmEBB+LVrGzxJ+OJw tQEVl3/sq77r5Wg5AynVFRI/RjRPis+pBBDEW3868XUXGrbgFYSCt44YuOMwzqoSpqTi 5eJv86+oVcXlk2seQTzNRVv/gb1igdAd/c8khxC+aSSrWzFdDwYI/yEYtRy280Fjsufj TWbeNQ0bPQOfrn8ajbgPbkGo3wuIt6DXxCJukuG/KvNpm+4cYmmgBHU2MhPrVQuTrEiA ecu4UOl93pUkwBZgzRE72hUx8TslFEC2SEY8yM53QWUqGbWcd8cIbeQZRelQGZwm2UO6 e0bg== X-Gm-Message-State: AJaThX6JcQzCbxfqVUXRPlTgam2Zq9HP05fuWcWBqyp+o8G/TeGd3u3a xvkMxCJ0RFgUmlgkog54C2crOiM+14PnXUKSTVY= X-Google-Smtp-Source: AGs4zMYPwp4XSyJ31t/v+uUF6NHjamR9be9uT6RGwh0BTUi/i05di+ZVUafmvlL3VNKfNrrRMvErnMzkCSPURJ+1X4E= X-Received: by 10.98.247.4 with SMTP id h4mr16198351pfi.16.1510722657753; Tue, 14 Nov 2017 21:10:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.190.1 with HTTP; Tue, 14 Nov 2017 21:10:37 -0800 (PST) In-Reply-To: References: From: Dick Hardt Date: Wed, 15 Nov 2017 13:10:37 +0800 Message-ID: To: Luke Camery Cc: SecEvent , Marius Scurtescu , Phil Hunt , Mike Jones , Anthony Nadalin , Leif Johansson Content-Type: multipart/alternative; boundary="f403043a04185e9f02055dfe870b" Archived-At: Subject: Re: [Id-event] [Update] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 05:11:00 -0000 --f403043a04185e9f02055dfe870b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We are confirmed to have Clark from 1:20 - 3:20 now. On Wed, Nov 15, 2017 at 1:01 PM, Dick Hardt wrote: > No one has that room currently at that time. I'm trying to find an AD to > schedule it for us. If anyone else comes across an AD, please ask them to > reserve it for us. > > If nothing else, we can ask the people in that room right now if we can > have it later on. > > > > > On Wed, Nov 15, 2017 at 12:35 PM, Luke Camery wrote: > >> We *potentially* have the room Clark from 1:20-3:20. Confirmation will >> follow. >> >> On Tue, Nov 14, 2017, 11:45 AM Luke Camery wrote: >> >>> *Future Meetings* >>> Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative SET >>> Proposal >>> Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane >>> Friday - 10:00-18:00 at Google Singapore (70 Pasir Panjang Road, >>> #03-71, 117371) on Work Session >>> >>> -- >>> >>> * =E2=80=A2 **Luke Camery* >>> * =E2=80=A2 *Associate Product Manager >>> * =E2=80=A2 *Federated Identity >>> >>> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> > > > -- > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --f403043a04185e9f02055dfe870b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    We are confirmed to have Clark from 1:20 - 3:20 now.
    =

    On Wed, Nov 15, 2= 017 at 1:01 PM, Dick Hardt <dick.hardt@gmail.com> wrote:<= br>
    No one has that room cur= rently at that time. I'm trying to find an AD to schedule it for us. If= anyone else comes across an AD, please ask them to reserve it for us.
    =
    If nothing else, we can ask the people in that room right no= w if we can have it later on.



    <= /div>

    <= div class=3D"h5">On Wed, Nov 15, 2017 at 12:35 PM, Luke Camery <lcamery@g= oogle.com> wrote:
    We *potentially* have the room = Clark from 1:20-3:20. Confirmation will follow.=C2=A0

    On Tue, Nov 14, 2017, 11:45 AM Luke Camer= y <lcamery@googl= e.com> wrote:
    Future Meetings
    Wednesday - 10:30-12:00 in Butterworth = on Annabelle's Alternative SET Proposal
    Thursday - 15:30-18:00 in t= he Atrium on Marius' Control Plane
    Friday - 10:00-18:00 at Go= ogle Singapore (70 Pasir Panjang Road, #03-7= 1, 117371) on Work Session

    --
    =C2=A0 = =E2=80=A2 =C2=A0Luke Camery
    =C2=A0 =E2=80=A2 =C2= =A0= Associate Product Manager
    =C2=A0 =E2=80=A2 =C2=A0Federated Identity=

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event


    <= br clear=3D"all">

    --
    Subscribe to the HARDTWARE mail list to learn about proje= cts I am working on!



    --
    Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
    --f403043a04185e9f02055dfe870b-- From nobody Tue Nov 14 21:16:04 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5852B127201 for ; Tue, 14 Nov 2017 21:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVUGc_MSz5R6 for ; Tue, 14 Nov 2017 21:16:00 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C8A127058 for ; Tue, 14 Nov 2017 21:15:59 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id y42so19439675wrd.3 for ; Tue, 14 Nov 2017 21:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vBdEKEnnNfTxvj1jouv4vF2keqxNgIvUbqyLHX0URWI=; b=qE+4I++7EI3lLNxfRKshkGbebL57VdaNd00HjG9NYZHUXnSqZEBLL1i+xpSQRdNbP0 wBZlMSnPF3XJ9mdjo64C0MCDnY4aBopYvG1xf5ZvtjgsYDT7kuOei2jyMWzRcQxh2bin 8tpXhlKE2He5cHXOQZWdRHbFNeRsQdr52J1dUtYVCwgtP1jGKP+Q+ufAYVtM7D6Lcdk+ NIjbXDMxStmqE7CDJ/VcK0ioEladgsbcde15DVIaTPzfwvpqpCKEWLz2dCp545XC9pun x+HMqfsl1QsZmXHGGl5RqSUwrzJXYImu8JmI8uKNEB8TDdQZirFOAaF3sLusAtbqJ/gD S8oQ== 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=vBdEKEnnNfTxvj1jouv4vF2keqxNgIvUbqyLHX0URWI=; b=CszF7AEmtbJG6mktfvqsxI3d6OiooLzTYjgjdNUIy2AaAaJ7KDp2E7+rM3KzoU+Hfr tna/dn28XwLSWffb43y0jNK3/mfhERH6STULKEspdSoCMgbQf/J28tKuZy+XiQfGmD98 mh9dQFEUc/5aWZVS+TH+nxA6zbsRADIF/5+8Ucf6JmZzWnUA8Jruym9e9JSQjNvW+UH8 G9bjpomxZjoJfadxqNeArnJyD53lcialbIwtCGpbd1Zc7m0R6Lri+MGJhWvdQxPCiXkr uxuAZhTnKMAWHslBQs6aqFpFA7h7/TpyXYyglIbGtPIXxhL6RcCJhbQGZjuObrHinFvG TGzw== X-Gm-Message-State: AJaThX4yA71ZQDQLgzOdvXNj052UMSIV+2mlSj06yo/+qECq0nviSncU d4hTpjMQQkPWhQpWIxp2MYJKilBx+TJmK8jl0ps= X-Google-Smtp-Source: AGs4zMYgRWpbEHMz0S8mDBIjNZfPJLWFC8iE3RiGB7kdJVjvEmUteWSIftmcHLBZY9URhsLBwGvlq4JLjQsrfX7SnpE= X-Received: by 10.223.176.27 with SMTP id f27mr12474418wra.105.1510722958332; Tue, 14 Nov 2017 21:15:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.188.2 with HTTP; Tue, 14 Nov 2017 21:15:57 -0800 (PST) Received: by 10.223.188.2 with HTTP; Tue, 14 Nov 2017 21:15:57 -0800 (PST) In-Reply-To: References: From: Marius Scurtescu Date: Tue, 14 Nov 2017 21:15:57 -0800 Message-ID: To: Dick Hardt Cc: Luke Camery , SecEvent , Phil Hunt , Mike Jones , Anthony Nadalin , Leif Johansson Content-Type: multipart/alternative; boundary="001a1141adb64918c1055dfe995e" Archived-At: Subject: Re: [Id-event] [Update] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 05:16:02 -0000 --001a1141adb64918c1055dfe995e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Awesome. Waiting for take out food, will go there as soon as I get it. Sent from my phone. On Nov 15, 2017 1:10 PM, "Dick Hardt" wrote: We are confirmed to have Clark from 1:20 - 3:20 now. On Wed, Nov 15, 2017 at 1:01 PM, Dick Hardt wrote: > No one has that room currently at that time. I'm trying to find an AD to > schedule it for us. If anyone else comes across an AD, please ask them to > reserve it for us. > > If nothing else, we can ask the people in that room right now if we can > have it later on. > > > > > On Wed, Nov 15, 2017 at 12:35 PM, Luke Camery wrote: > >> We *potentially* have the room Clark from 1:20-3:20. Confirmation will >> follow. >> >> On Tue, Nov 14, 2017, 11:45 AM Luke Camery wrote: >> >>> *Future Meetings* >>> Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative SET >>> Proposal >>> Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane >>> Friday - 10:00-18:00 at Google Singapore ( >>> 70 >>> Pasir Panjang Road, #03 >>> -71, >>> 117371) on Work Session >>> >>> -- >>> >>> * =E2=80=A2 **Luke Camery* >>> * =E2=80=A2 *Associate Product Manager >>> * =E2=80=A2 *Federated Identity >>> >>> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> > > > -- > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --001a1141adb64918c1055dfe995e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Awesome. Waiting for take out food, will go there as soon= as I get it.

    Sent from my p= hone.

    = On Nov 15, 2017 1:10 PM, "Dick Hardt" <dick.hardt@gmail.com> wrote:
    We are confirmed to have Clark = from 1:20 - 3:20 now.

    On Wed, Nov 15, 2017 at 1:01 PM, Dick Hardt <= ;dick.hardt@gmail= .com> wrote:
    No one has that room currently at that time. I'm trying to find an A= D to schedule it for us. If anyone else comes across an AD, please ask them= to reserve it for us.

    If nothing else, we can ask the p= eople in that room right now if we can have it later on.




    On Wed, No= v 15, 2017 at 12:35 PM, Luke Camery <lcamery@google.com> wr= ote:
    We *potentially* have the room Clark = from 1:20-3:20. Confirmation will follow.=C2=A0

    On Tue, Nov 14, 2017, 11:45 AM Luke Camery <lcamery@google.com> wrote:
    = Future Meetings
    Wednesday - 10:30-12:00 in Butterworth on Annab= elle's Alternative SET Proposal
    Thursday - 15:30-18:00 in the Atriu= m on Marius' Control Plane

    --
    =C2=A0 =E2=80=A2 =C2=A0Luke Camery
    =C2=A0 =E2=80=A2 =C2=A0Associate Product Manager
    =C2=A0 =E2=80=A2 =C2=A0Federated Identity

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    Subscribe to the HARDTWARE mail list to learn about projects I am = working on!



    --
    Subscribe to the HARDTWARE mail list to learn about projects I am working on= !

    --001a1141adb64918c1055dfe995e-- From nobody Tue Nov 14 21:21:40 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C73127201 for ; Tue, 14 Nov 2017 21:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5xG4kFf5BTX for ; Tue, 14 Nov 2017 21:21:36 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70007127058 for ; Tue, 14 Nov 2017 21:21:36 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id t69so7230037pfg.4 for ; Tue, 14 Nov 2017 21:21:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tDyBF5I+A8KffrOZXH18CRn/PaBh8Bj0MDGJ/u20jmU=; b=jYyv6LL2mIfEphGrXR8s2llj2aMBdUlC84DVDFvSCi1QHumPkqbePl5xXZOXvOt1OA XR1jx9o1QdWFLGNv8dn6sIh8rsvrQ9cbxcqpQoqouIWOWmMTsOmHRWOomOyTKboMxIrU wySNelGwvYxrD+/Ko4y8fMtRxg/NNZ+cKKfpBr1xSPFvGBRJbnHB8AEg4tEDSNR6JW4h Mhm7jz05cTZHx5afcljCarCcPDbbp9+rcemtHKbmkKalsjHVjwfeEFmu7SiZOtco9IzO v44w8M6PucrudX6i/LILMS2di1XcH26GJjsYacF4icXUXnlAHI9Ki/+LYAPJcPbiMXhl 2K7A== 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=tDyBF5I+A8KffrOZXH18CRn/PaBh8Bj0MDGJ/u20jmU=; b=QX0AS4DYyxhshNIrHDgPrLChTAWuUdp/yYBjrq9jnUQVZFtBidds0NRZxwMR+R5e77 ctIaZYTqxs8LBhvMcLE5NzGrs5ceLMpZKYQ8j2wcKJWbivFWsHjX1JPL4PuPNVnFuM9E 5ofvk+M6DHvAa+GoTegC0VxPjPGWanI3jSkUjFTFHM+jGe5w+WSQE+OEJksHaWPQTqVr WxT4vxygFhBQ0Y9QZTUe+NTQcR8jJi4oQ6ooaIW4oGl/YGwDQ1PTU9+MwGPa9GcoB6EQ 4ty2bFR6mlp2pTkGogonGDvTutCseqNc1YGBpulLnXVr3FOxL407Qpzv/x6zSVcwgRKV Lpdw== X-Gm-Message-State: AJaThX49Ij6zNHhT0uaK2Wgz75cqLKzyC2GSoL7mXP9TmC7WVUIbX+k3 K7bYYDR6QLRdlGVkkHv5GlpQEK8nqe/cAgBdTjs= X-Google-Smtp-Source: AGs4zMbJa9J1GhSVZqnvvJtrQx+WFPaJcqVZB0KEVTbN96VOaPOrPCX4EQ4Ixviqrbyr1K666bdaQXbPxTgKI94/hgM= X-Received: by 10.84.132.35 with SMTP id 32mr13222606ple.225.1510723295949; Tue, 14 Nov 2017 21:21:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.190.1 with HTTP; Tue, 14 Nov 2017 21:21:15 -0800 (PST) In-Reply-To: References: From: Dick Hardt Date: Wed, 15 Nov 2017 13:21:15 +0800 Message-ID: To: Marius Scurtescu Cc: Luke Camery , SecEvent , Phil Hunt , Mike Jones , Anthony Nadalin , Leif Johansson Content-Type: multipart/alternative; boundary="94eb2c119f8268bc95055dfead46" Archived-At: Subject: Re: [Id-event] [Update] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 05:21:38 -0000 --94eb2c119f8268bc95055dfead46 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FYI: Clark (the room we have) is two rooms down from Butterworth where we were meeting earlier. On Wed, Nov 15, 2017 at 1:15 PM, Marius Scurtescu < marius.scurtescu@gmail.com> wrote: > Awesome. Waiting for take out food, will go there as soon as I get it. > > Sent from my phone. > > On Nov 15, 2017 1:10 PM, "Dick Hardt" wrote: > > We are confirmed to have Clark from 1:20 - 3:20 now. > > On Wed, Nov 15, 2017 at 1:01 PM, Dick Hardt wrote: > >> No one has that room currently at that time. I'm trying to find an AD to >> schedule it for us. If anyone else comes across an AD, please ask them t= o >> reserve it for us. >> >> If nothing else, we can ask the people in that room right now if we can >> have it later on. >> >> >> >> >> On Wed, Nov 15, 2017 at 12:35 PM, Luke Camery wrote= : >> >>> We *potentially* have the room Clark from 1:20-3:20. Confirmation will >>> follow. >>> >>> On Tue, Nov 14, 2017, 11:45 AM Luke Camery wrote: >>> >>>> *Future Meetings* >>>> Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative SET >>>> Proposal >>>> Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane >>>> Friday - 10:00-18:00 at Google Singapore ( >>>> 70 >>>> Pasir Panjang Road, #03 >>>> -71, >>>> 117371) on Work Session >>>> >>>> -- >>>> >>>> * =E2=80=A2 **Luke Camery* >>>> * =E2=80=A2 *Associate Product Manager >>>> * =E2=80=A2 *Federated Identity >>>> >>>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >> >> >> -- >> Subscribe to the HARDTWARE mail list to learn >> about projects I am working on! >> > > > > -- > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > > > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --94eb2c119f8268bc95055dfead46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    FYI: Clark (the room we have) is two rooms down from Butte= rworth where we were meeting earlier.


    On Wed, Nov 15, 2017 at 1:15 P= M, Marius Scurtescu <marius.scurtescu@gmail.com> wr= ote:
    Awesome. Waiting f= or take out food, will go there as soon as I get it.

    Sent from my phone.

    On Nov 15, 2017 1:10 PM, "Dick Hardt" <dick.hardt@gmail.com> wrote:<= br type=3D"attribution">
    We are confirmed to have Clark from 1:20 - 3:20 now.

    On Wed, Nov 15, 2017 = at 1:01 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
    No one has that room current= ly at that time. I'm trying to find an AD to schedule it for us. If any= one else comes across an AD, please ask them to reserve it for us.

    =
    If nothing else, we can ask the people in that room right now if= we can have it later on.




    On Wed, Nov 15, 201= 7 at 12:35 PM, Luke Camery <lcamery@google.com> wrote:
    <= /div>
    We *potentially* have th= e room Clark from 1:20-3:20. Confirmation will follow.=C2=A0

    On Tue, Nov 14, 2017, 11:45 AM Luke = Camery <lcamery@= google.com> wrote:
    Future Meetings
    Wednesday - 10:30-12:00 in Butter= worth on Annabelle's Alternative SET Proposal
    Thursday - 15:30-18:0= 0 in the Atrium on Marius' Control Plane
    Friday - 10:00-18:00= at Google Singapo= re (70 Pasir Panjang Road, #03-71, 117371) on Work Ses= sion

    --=
    =C2=A0 =E2=80=A2 = =C2=A0Luke Camery
    =C2=A0 =E2=80=A2 =C2=A0Associate = Product Manager
    =C2=A0 =E2=80=A2 =C2=A0Federated Identity

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    Sub= scribe to the HARDTWARE= mail list to learn about projects I am working on!



    --
    =
    Subscribe to the HARDTWARE mail list to learn about pro= jects I am working on!



    --
    =
    Subscribe to the HARDTWARE mail list to l= earn about projects I am working on!
    --94eb2c119f8268bc95055dfead46-- From nobody Wed Nov 15 19:10:52 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96044127275 for ; Wed, 15 Nov 2017 19:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jyFYXkvUbd9 for ; Wed, 15 Nov 2017 19:10:49 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885E4124BE8 for ; Wed, 15 Nov 2017 19:10:49 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id 207so16743449pgc.12 for ; Wed, 15 Nov 2017 19:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RBAx1ZQU3AioOsA3LDZRrCZBVuRGGv+VMX1PoXnIbxM=; b=ZIrNLeGnIrdsZ9kBZ1LPqdFs6wF3BM2SffsBCacUqO5Gb56oTSleJ9t4wjrCXEJ1PN mIrY7V8ofBOl2YnEduu/JuI+wB6tCv48PKUN9pQgQtiSHZJnO2QH16JWsrod4YA4mslV wUjyinDVmvg0WI3Qn2eIkjiQ4DKnvX7lwsEIp2YU6RJQcISH0maskM3gyMvjV11s1BFa Igg9lSLLX5xmAsKS1wh6zWSqTx1w/bkd4bh+9GZ9RGe0P0MJoAnboeENrvHyypxbe0p7 +ata4n9KNbh7qLgyPiS+mJU5OzlY+zVPpMFCUEsTpojZ8zsNgcTknF9kj7mJcVgT2YlF /mPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RBAx1ZQU3AioOsA3LDZRrCZBVuRGGv+VMX1PoXnIbxM=; b=KX4NSezNfe6xs1CKBs7iVf7mOkUmwZ8YfYjB9up5Wa1HOdGvLXzSND8jStQY03YMYX /160aA4wjZWuhTAf8xZsga5rrvPerZrX+d1yAA8+2TX6cxHOT85sQ/JDhkfx5+42P6Dn 4r/lSFu1vPqTO2cfw6EzB3F9nvhAzT7vkZKqs2NGZUxCyLv9+kDkw+PBdNgTHb4LUN2j zFpBHvA38nAwjRG1750H6YD5gcl1a+VdXQ/OLAWoLkozo5SCs2vFNwwniQfQFIahxhmP Dz6YT7o6QQumKg+yxh0S3q/O14Bjtq8G9BHUmG5KO1waWAEaFdS/QgYnlIa/QUWhY6Th U4yA== X-Gm-Message-State: AJaThX6O1rqadeeegmTl9R64QVdpNTIOn7w4MHxNM43MzPUheBaG/YqL OZP2EXa+vcSbiB122/JjN/I4s62NT9KblvUG2zc= X-Google-Smtp-Source: AGs4zMaJ7ehsqOo57jLQFpVScENQsA7bym+WDSMlrYA3nd1tYEhDd/pyMLIfirpnwO+7w/k9BaxiJjcQMNmfgMn/HQA= X-Received: by 10.98.189.23 with SMTP id a23mr275539pff.124.1510801849041; Wed, 15 Nov 2017 19:10:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 16 Nov 2017 03:10:38 +0000 Message-ID: To: Marius Scurtescu Cc: Anthony Nadalin , Leif Johansson , Luke Camery , Mike Jones , Phil Hunt , SecEvent Content-Type: multipart/alternative; boundary="f403043bc9c489c858055e10f78e" Archived-At: Subject: Re: [Id-event] [Update] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 03:10:51 -0000 --f403043bc9c489c858055e10f78e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We have VIP B this afternoon at 3:30. On Wed, Nov 15, 2017 at 1:21 PM Dick Hardt wrote: > FYI: Clark (the room we have) is two rooms down from Butterworth where we > were meeting earlier. > > > On Wed, Nov 15, 2017 at 1:15 PM, Marius Scurtescu < > marius.scurtescu@gmail.com> wrote: > >> Awesome. Waiting for take out food, will go there as soon as I get it. >> >> Sent from my phone. >> >> On Nov 15, 2017 1:10 PM, "Dick Hardt" wrote: >> >> We are confirmed to have Clark from 1:20 - 3:20 now. >> >> On Wed, Nov 15, 2017 at 1:01 PM, Dick Hardt wrote= : >> >>> No one has that room currently at that time. I'm trying to find an AD t= o >>> schedule it for us. If anyone else comes across an AD, please ask them = to >>> reserve it for us. >>> >>> If nothing else, we can ask the people in that room right now if we can >>> have it later on. >>> >>> >>> >>> >>> On Wed, Nov 15, 2017 at 12:35 PM, Luke Camery >>> wrote: >>> >>>> We *potentially* have the room Clark from 1:20-3:20. Confirmation will >>>> follow. >>>> >>>> On Tue, Nov 14, 2017, 11:45 AM Luke Camery wrote: >>>> >>>>> *Future Meetings* >>>>> Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative SET >>>>> Proposal >>>>> Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane >>>>> Friday - 10:00-18:00 at Google Singapore ( >>>>> 70 >>>>> Pasir Panjang Road, #03 >>>>> -71, >>>>> 117371) on Work Session >>>>> >>>>> -- >>>>> >>>>> * =E2=80=A2 **Luke Camery* >>>>> * =E2=80=A2 *Associate Product Manager >>>>> * =E2=80=A2 *Federated Identity >>>>> >>>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>> >>>> >>> >>> >>> -- >>> Subscribe to the HARDTWARE mail list to learn >>> about projects I am working on! >>> >> >> >> >> -- >> Subscribe to the HARDTWARE mail list to learn >> about projects I am working on! >> >> >> > > > -- > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --f403043bc9c489c858055e10f78e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    We have VIP B this afternoon at 3:30.

    On Wed, Nov 15, 2017 at 1:21 PM Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com">dick.hardt@gmail.com> wrote:<= br>
    FYI: Clark (the room we have) = is two rooms down from Butterworth where we were meeting earlier.
    <= br>

    On= Wed, Nov 15, 2017 at 1:15 PM, Marius Scurtescu <marius.scurtescu@gmail.com> wrote:
    Aw= esome. Waiting for take out food, will go there as soon as I get it.
    Sent from my phone.

    On Nov 15, 20= 17 1:10 PM, "Dick Hardt" <dick.hardt@gmail.com> wrote:
    =
    We are confirmed to have Clark from 1:20 - 3:20 now.

    On Wed, Nov 15, 2017 at 1:0= 1 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
    No one has that room currently at that time. I'm try= ing to find an AD to schedule it for us. If anyone else comes across an AD,= please ask them to reserve it for us.

    If nothing else, = we can ask the people in that room right now if we can have it later on.




    On Wed, Nov 15, 2017 at 12= :35 PM, Luke Camery <lcamery@google.com> wrote:
    We *potentially* have= the room Clark from 1:20-3:20. Confirmation will follow.=C2=A0

    On Tue, Nov 14, 2017, 11:45 AM Luke Camery &l= t;lcamery@google.co= m> wrote:
    Futur= e Meetings
    Wednesday - 10:30-12:00 in Butterworth on Annabelle'= ;s Alternative SET Proposal
    Thursday - 15:30-18:00 in the Atrium on Mar= ius' Control Plane
    Friday - 10:00-18:00 at Google Singapore (7= 0 Pasir Panjang Road, #03-71, 117371) on Work Session

    -- =
    =C2=A0 =E2=80=A2 =C2=A0= = Luke Camery
    =C2=A0 =E2=80=A2 =C2=A0Associate Produc= t Manager
    =C2=A0 =E2=80=A2 =C2=A0Federated Identity

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    Subscribe to the HAR= DTWARE mail list to learn about projects I am working on!



    --
    <= div>
    Subscribe to the HARDTWARE mail list to learn about projects I am work= ing on!




    --
    =
    Subscribe to the HARDTWARE mail list to learn about proje= cts I am working on!
    --
    Subscribe to the HARDTWARE mail list to learn about projects I= am working on!
    --f403043bc9c489c858055e10f78e-- From nobody Wed Nov 15 19:16:40 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1019F129456 for ; Wed, 15 Nov 2017 19:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 GO9-a3_rljJK for ; Wed, 15 Nov 2017 19:16:36 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 4DC7E129482 for ; Wed, 15 Nov 2017 19:16:19 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vAG3GFIu001488 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 Nov 2017 03:16:16 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vAG3GF2K028323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 Nov 2017 03:16:15 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vAG3GEqj026401; Thu, 16 Nov 2017 03:16:14 GMT Received: from [31.133.144.59] (/31.133.144.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 Nov 2017 19:16:13 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-F52C1900-5774-4055-BA55-3BE66AA63AC3 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Thu, 16 Nov 2017 11:16:06 +0800 Cc: Marius Scurtescu , Anthony Nadalin , Luke Camery , Leif Johansson , Mike Jones , SecEvent Content-Transfer-Encoding: 7bit Message-Id: References: To: Dick Hardt X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Id-event] [Update] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 03:16:39 -0000 --Apple-Mail-F52C1900-5774-4055-BA55-3BE66AA63AC3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Agenda? Phil > On Nov 16, 2017, at 11:10 AM, Dick Hardt wrote: >=20 > We have VIP B this afternoon at 3:30. >=20 >> On Wed, Nov 15, 2017 at 1:21 PM Dick Hardt wrote: >> FYI: Clark (the room we have) is two rooms down from Butterworth where we= were meeting earlier. >>=20 >>=20 >>> On Wed, Nov 15, 2017 at 1:15 PM, Marius Scurtescu wrote: >>> Awesome. Waiting for take out food, will go there as soon as I get it. >>>=20 >>> Sent from my phone. >>>=20 >>> On Nov 15, 2017 1:10 PM, "Dick Hardt" wrote: >>> We are confirmed to have Clark from 1:20 - 3:20 now. >>>=20 >>> On Wed, Nov 15, 2017 at 1:01 PM, Dick Hardt wrote= : >>>> No one has that room currently at that time. I'm trying to find an AD t= o schedule it for us. If anyone else comes across an AD, please ask them to r= eserve it for us. >>>>=20 >>>> If nothing else, we can ask the people in that room right now if we can= have it later on. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> On Wed, Nov 15, 2017 at 12:35 PM, Luke Camery wro= te: >>>>> We *potentially* have the room Clark from 1:20-3:20. Confirmation will= follow.=20 >>>>>=20 >>>>>> On Tue, Nov 14, 2017, 11:45 AM Luke Camery wrote= : >>>>>> Future Meetings >>>>>> Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative SET= Proposal >>>>>> Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane >>>>>> Friday - 10:00-18:00 at Google Singapore (70 Pasir Panjang Road, #03-= 71, 117371) on Work Session >>>>>>=20 >>>>>> --=20 >>>>>> =09 >>>>>> =E2=80=A2 Luke Camery >>>>>> =E2=80=A2 Associate Product Manager >>>>>> =E2=80=A2 Federated Identity >>>>>=20 >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Subscribe to the HARDTWARE mail list to learn about projects I am worki= ng on! >>>=20 >>>=20 >>>=20 >>> --=20 >>> Subscribe to the HARDTWARE mail list to learn about projects I am workin= g on! >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Subscribe to the HARDTWARE mail list to learn about projects I am working= on! >=20 > --=20 > Subscribe to the HARDTWARE mail list to learn about projects I am working o= n! > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI= _JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D109OW8XGYF2R4KSbIrN= J93Ol9JbZhzY4yeRIU_cqsrU&s=3DMHReHuR8iihnIL2tUrDyudmDM536Zzw3x3l_AYBdo8E&e=3D= --Apple-Mail-F52C1900-5774-4055-BA55-3BE66AA63AC3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Agenda?

    Phil

    On N= ov 16, 2017, at 11:10 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

    We have VIP B this afternoon at 3:30.
    <= br>
    On Wed, Nov 15, 2017 at 1:21 PM Dick Hard= t <dick.hardt@gmail.com> w= rote:
    FYI: Clark (the room we ha= ve) is two rooms down from Butterworth where we were meeting earlier.


    = On Wed, Nov 15, 2017 at 1:15 PM, Marius Scurtescu <marius.scurtescu@gmail.com> wrote:
    Aweso= me. Waiting for take out food, will go there as soon as I get it.

    Sent from my phone.

    On Nov 15, 2017 1:10= PM, "Dick Hardt" <dick.hardt@gmail.com> wrote:
    We are confirmed t= o have Clark from 1:20 - 3:20 now.

    On Wed, Nov 15, 2017 at 1:01 PM, Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.co= m> wrote:
    No one has tha= t room currently at that time. I'm trying to find an AD to schedule it for u= s. If anyone else comes across an AD, please ask them to reserve it for us.<= div>
    If nothing else, we can ask the people in that room right= now if we can have it later on.




    =
    On Wed, Nov 15, 2017 at 12:35 PM, Luke Camery <lcamery@google.com> w= rote:
    We *potentially* have the room Clark from 1:20-3:20. Confirmation will f= ollow. 

    On Tue, Nov 14, 2017, 1= 1:45 AM Luke Camery <lcamery@google.com> wrote:
    Future Meetings
    Wednesday - 10:30-12:00 in Butterwort= h on Annabelle's Alternative SET Proposal
    Thursday - 15:30-18:00 in the A= trium on Marius' Control Plane
    Friday - 10:00-18:00 at Google Singapore (70 Pasir Panjang Roa= d, #03-71, 117371) on Work Session

    --
    <= tr style=3D"margin:0px;padding:0px;border:0px;height:48px">
      =E2=80=A2  Luke Camery
      =E2= =80=A2  Associate Product Manager
      =E2=80=A2  Federated Identi= ty

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org=
    htt= ps://www.ietf.org/mailman/listinfo/id-event




    --
    Su= bscribe to the HARDTWARE mail list to learn a= bout projects I am working on!


    --




    --
    <= div class=3D"m_2750090645348104599gmail_signature" data-smartmail=3D"gmail_s= ignature">
    Subscribe to the HARDTWARE mail list to learn about projects I am working on!
    --
    Subscribe to the HARD= TWARE mail list to learn about projects I am working on!
    = --Apple-Mail-F52C1900-5774-4055-BA55-3BE66AA63AC3-- From nobody Wed Nov 15 19:17:53 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39B3129456 for ; Wed, 15 Nov 2017 19:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW5UlSAfLgT9 for ; Wed, 15 Nov 2017 19:17:49 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5330F124BE8 for ; Wed, 15 Nov 2017 19:17:49 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id o7so19553933pgc.4 for ; Wed, 15 Nov 2017 19:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RSUK7rSUsmP5V0N22b58zMZOqfq+od5LOVmMSqLJBGA=; b=cNNUicErBi7YOa6DeIMvLLMMf3Rl8pvIB5r/72ngWfLY3qW2hIq92mUqDNwC6G+xK5 blQUWt308M8ePouLWKUch9J8efTthCnT8927ZuOQ9gMM5rwx3HBHC0WbzP2u/l7lDe/k lxHYvCEsbmwcrbnCITCNZ87+VKZb11nrIREPUB/lLmycMxaG7G2PEXotrehcXDZ+NP4N 5wf3yQDp2asYsCdhTJ3DSTh2ny7PizRCW/scVQAhyht19S92aayaJMT2xZXGLvPNi12F VKy8IHKe2cVi27CqBQOG/QuotQLrBXKojv4LGeiMsm9tjN5ZHhzopHQwfYS2/xPISVGJ 4ZIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RSUK7rSUsmP5V0N22b58zMZOqfq+od5LOVmMSqLJBGA=; b=kqpfpXSJnne3W5bcxY99ZOStu3LAtDNiDjfi/Bteekire1QEHIxRBzvghgmiD7FxVM 4Bjs4uwfSr84uonWSn03BZ7zBXsqq/YD8MdTLi/nyyI2zxNBkqOwLns1/xygeo0/gY5l 0znsvTMtBMLEPy66HaUmPfDgibP/Nl3U+cp8moQ9Fpk4BbftlJs7/YDy8neXOSYL9bkz ozuwBjJHvYDhlwvOM4o1hmHXZ7WWHyMaHhrwqD5Le2ntFkvp/5n95QTpLEVIqIRY2HCX d80rClL5lLqbrmk+53KBSE5KvU3ZvBpCH5c3i8zn7QxRIPxt4oYI3yGv/AksXZTR9XRz H7ew== X-Gm-Message-State: AJaThX5bJyWGQ8LOhG73nA/Q7k5dEl4adqMpMyr6UPRnAiYEHL0Q/9JI BthvzysNzt4pRnTc71sAEfOo/aRw4C2uCBMjLbM= X-Google-Smtp-Source: AGs4zMbywJPPRiw6rlexXmcE+f+TotvnCjkuH8dzZf/n0cPtDNfGJ/Eb7QSv2g0zwEr/Q9aaUfh3Er9IbFafvYVP/RE= X-Received: by 10.84.149.197 with SMTP id a5mr246093plh.231.1510802268819; Wed, 15 Nov 2017 19:17:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 16 Nov 2017 03:17:38 +0000 Message-ID: To: "Phil Hunt (IDM)" Cc: Anthony Nadalin , Leif Johansson , Luke Camery , Marius Scurtescu , Mike Jones , SecEvent Content-Type: multipart/alternative; boundary="94eb2c1482688f15ed055e1110dc" Archived-At: Subject: Re: [Id-event] [Update] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 03:17:52 -0000 --94eb2c1482688f15ed055e1110dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Continue reviewing Annabelle=E2=80=99s draft, and then distribution and con= trol plane time permitting. On Thu, Nov 16, 2017 at 11:16 AM Phil Hunt (IDM) wrote: > Agenda? > > Phil > > On Nov 16, 2017, at 11:10 AM, Dick Hardt wrote: > > We have VIP B this afternoon at 3:30. > > On Wed, Nov 15, 2017 at 1:21 PM Dick Hardt wrote: > >> FYI: Clark (the room we have) is two rooms down from Butterworth where w= e >> were meeting earlier. >> >> >> On Wed, Nov 15, 2017 at 1:15 PM, Marius Scurtescu < >> marius.scurtescu@gmail.com> wrote: >> >>> Awesome. Waiting for take out food, will go there as soon as I get it. >>> >>> Sent from my phone. >>> >>> On Nov 15, 2017 1:10 PM, "Dick Hardt" wrote: >>> >>> We are confirmed to have Clark from 1:20 - 3:20 now. >>> >>> On Wed, Nov 15, 2017 at 1:01 PM, Dick Hardt >>> wrote: >>> >>>> No one has that room currently at that time. I'm trying to find an AD >>>> to schedule it for us. If anyone else comes across an AD, please ask t= hem >>>> to reserve it for us. >>>> >>>> If nothing else, we can ask the people in that room right now if we ca= n >>>> have it later on. >>>> >>>> >>>> >>>> >>>> On Wed, Nov 15, 2017 at 12:35 PM, Luke Camery >>>> wrote: >>>> >>>>> We *potentially* have the room Clark from 1:20-3:20. Confirmation wil= l >>>>> follow. >>>>> >>>>> On Tue, Nov 14, 2017, 11:45 AM Luke Camery wrote= : >>>>> >>>>>> *Future Meetings* >>>>>> Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative SE= T >>>>>> Proposal >>>>>> Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane >>>>>> Friday - 10:00-18:00 at Google Singapore ( >>>>>> 70 >>>>>> Pasir Panjang Road, #03 >>>>>> -71, >>>>>> 117371) on Work Session >>>>>> >>>>>> -- >>>>>> >>>>>> * =E2=80=A2 **Luke Camery* >>>>>> * =E2=80=A2 *Associate Product Manager >>>>>> * =E2=80=A2 *Federated Identity >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Subscribe to the HARDTWARE >>>> >>>> mail list to learn about projects I am working on! >>>> >>> >>> >>> >>> -- >>> Subscribe to the HARDTWARE >>> >>> mail list to learn about projects I am working on! >>> >>> >>> >> >> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> > -- > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D109OW8XGYF2R4KSb= IrNJ93Ol9JbZhzY4yeRIU_cqsrU&s=3DMHReHuR8iihnIL2tUrDyudmDM536Zzw3x3l_AYBdo8E= &e=3D > > -- Subscribe to the HARDTWARE mail list to learn about projects I am working on! --94eb2c1482688f15ed055e1110dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Continue reviewing Annabelle=E2=80=99s draft, and th= en distribution and control plane time permitting.

    On Thu, Nov 16, 2017 at 11:16 AM Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
    <= /div>
    Agenda?

    P= hil

    On Nov 16, 2017, at 11:10 AM, Dic= k Hardt <dick.= hardt@gmail.com> wrote:

    =
    We have VIP B this afternoon at 3:30.

    On Wed, Nov 15, 2017 at 1:21 PM Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om> wrote:
    FYI: Clark (= the room we have) is two rooms down from Butterworth where we were meeting = earlier.


    On Wed, Nov 15, 2017 at 1:15 PM, Marius Scurtescu &l= t;marius.sc= urtescu@gmail.com> wrote:
    <= div dir=3D"auto">Awesome. Waiting for take out food, will go there as soon = as I get it.

    Sent from my ph= one.

    On Nov 15, 2017 1:10 PM, &q= uot;Dick Hardt" <dick.hardt@gmail.com> wrote:
    We are confirmed to have Clark from 1:20 - 3:20 now.

    On Wed, Nov 15, 2017 a= t 1:01 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
    No one has that room currently at that time. I'm = trying to find an AD to schedule it for us. If anyone else comes across an = AD, please ask them to reserve it for us.

    If nothing els= e, we can ask the people in that room right now if we can have it later on.=




    On= Wed, Nov 15, 2017 at 12:35 PM, Luke Camery <lcamery@google.com> wrote:=
    We *potentially* have the room Clark from 1:20-3:20.= Confirmation will follow.=C2=A0

    O= n Tue, Nov 14, 2017, 11:45 AM Luke Camery <lcamery@google.com> wrote:
    Future Meetings
    Wednesday -= 10:30-12:00 in Butterworth on Annabelle's Alternative SET ProposalThursday - 15:30-18:00 in the Atrium on Marius' Control Plane
    Friday - 10:00-18:00 at Google Singapore (70 Pasir Panjang Road, #03-71, 117371) on = Work Session

    --
    =C2=A0 =E2=80=A2 =C2=A0Lu= ke Camery
    =C2=A0 =E2=80=A2 =C2=A0Associate Product = Manager
    =C2=A0 =E2=80=A2 =C2=A0Federated Identity

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    Subscribe to the HARDTWARE mail list to learn about projects I am= working on!



    --
    Subscribe to the HARDTWARE mail list to learn about projects I am= working on!




    --
    =
    Subscribe to the = HARDTWARE mail list to learn about proje= cts I am working on!
    --
    =
    Subscribe to the HARDTWARE mail lis= t to learn about projects I am working on!
    <= span>_______________________________________________
    Id-eve= nt mailing list
    Id-event@ietf.org
    --
    =
    Subscribe to the = HARDTWARE mail list= to learn about projects I am working on!
    --94eb2c1482688f15ed055e1110dc-- From nobody Wed Nov 15 19:20:21 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632C812947F for ; Wed, 15 Nov 2017 19:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-lWWqESdIwx for ; Wed, 15 Nov 2017 19:20:14 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6DF012947D for ; Wed, 15 Nov 2017 19:20:13 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id 17so18569870pfn.12 for ; Wed, 15 Nov 2017 19:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7JT+XqzCL6OXS8tzn9JdUmcbHWLk2gZBxJnaGSB0mrk=; b=R0z2/KATBcbfv4F5sFIDDJlXpZ1TeNADlLVVHuWAikPAl55CVTts9d9ICX6u9/cPyp 2w2A7SGRTw1j6GhejcBp40auNLDkDtpG0rr3Q3K0OrpbjX/IJeGagw1hjPUW/o6wUrth Cfit7RPqTIUmWpkEugn4jeBOaff8iuFYUvf3KDwgruqpIv/nt5dmZ8J/B9SM9v2M0o97 4xcuteepQTgzqRLrmWDZgUtHMKxWiZss6FGPpSSutiRIrqnh+4fP9WvvdkezIppLAK00 2ToQGWW04sYMbJE7bJDaVAxY7QECFNlIyaVr6G0jBCAJ8J5MfZVZPk4W17b+2bmmR5Xd OriA== 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=7JT+XqzCL6OXS8tzn9JdUmcbHWLk2gZBxJnaGSB0mrk=; b=nozZTI8Ug6VGY+dt8jiX5ETHugOOmSMGq3OuFuS3Xp/5XOAfcE1ED4CVjbwVr/hv+y 692ZqzmRMM82VMO8gxzIrQQEbWJulKgvueJXlK620fcYLjRkI09jpo8PHe4ZWSCd9IEG sUe60dnDXemq85HrQbcDH6qM5gMqRQ1r0LoI+ClNr6ZHDBFzLNtDq5cduzx/TzJpKgSE g15U4gyOGyPcWHaVDX3s1WAVhzZf3CHSoQ6H9kMnGg8vuctI6sSjywBgQk5joIm9T20U Z2bSiiB8COqia+zvFiLz9mdmGMWBwozPDmL91cq3QZTuuGcNP2fbRiHr18gpepkM3hhJ DoFQ== X-Gm-Message-State: AJaThX52VDbymQ5/0/k5PRvvJ3rpdMSdqT3K4OyNmX2jQGWGcnFSnbe4 S8jvPE5cm4T0NrN7ZbGoASvP+aOWKDufZ+jgP54= X-Google-Smtp-Source: AGs4zMYlfTmmrjjAC7t2AI6ULqzzzWSp+sCf/jtHM0tr1epIAx6pRKrOHgU2yTkdXFS6KOhZ7OnbMGmFcK5V6ppzVII= X-Received: by 10.98.59.66 with SMTP id i63mr274468pfa.117.1510802413474; Wed, 15 Nov 2017 19:20:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.155.9 with HTTP; Wed, 15 Nov 2017 19:19:32 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Wed, 15 Nov 2017 22:19:32 -0500 Message-ID: To: Dick Hardt Cc: "Phil Hunt (IDM)" , Anthony Nadalin , Luke Camery , Leif Johansson , Mike Jones , Marius Scurtescu , SecEvent Content-Type: multipart/alternative; boundary="94eb2c1135da2e5998055e111946" Archived-At: Subject: Re: [Id-event] [Update] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 03:20:19 -0000 --94eb2c1135da2e5998055e111946 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Could you please send a summary report to the list from the side meetings for those of us that cannot attend? Thank you, Kathleen On Wed, Nov 15, 2017 at 10:17 PM, Dick Hardt wrote: > Continue reviewing Annabelle=E2=80=99s draft, and then distribution and c= ontrol > plane time permitting. > > On Thu, Nov 16, 2017 at 11:16 AM Phil Hunt (IDM) > wrote: > >> Agenda? >> >> Phil >> >> On Nov 16, 2017, at 11:10 AM, Dick Hardt wrote: >> >> We have VIP B this afternoon at 3:30. >> >> On Wed, Nov 15, 2017 at 1:21 PM Dick Hardt wrote: >> >>> FYI: Clark (the room we have) is two rooms down from Butterworth where >>> we were meeting earlier. >>> >>> >>> On Wed, Nov 15, 2017 at 1:15 PM, Marius Scurtescu < >>> marius.scurtescu@gmail.com> wrote: >>> >>>> Awesome. Waiting for take out food, will go there as soon as I get it. >>>> >>>> Sent from my phone. >>>> >>>> On Nov 15, 2017 1:10 PM, "Dick Hardt" wrote: >>>> >>>> We are confirmed to have Clark from 1:20 - 3:20 now. >>>> >>>> On Wed, Nov 15, 2017 at 1:01 PM, Dick Hardt >>>> wrote: >>>> >>>>> No one has that room currently at that time. I'm trying to find an AD >>>>> to schedule it for us. If anyone else comes across an AD, please ask = them >>>>> to reserve it for us. >>>>> >>>>> If nothing else, we can ask the people in that room right now if we >>>>> can have it later on. >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Nov 15, 2017 at 12:35 PM, Luke Camery >>>>> wrote: >>>>> >>>>>> We *potentially* have the room Clark from 1:20-3:20. Confirmation >>>>>> will follow. >>>>>> >>>>>> On Tue, Nov 14, 2017, 11:45 AM Luke Camery >>>>>> wrote: >>>>>> >>>>>>> *Future Meetings* >>>>>>> Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative >>>>>>> SET Proposal >>>>>>> Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane >>>>>>> Friday - 10:00-18:00 at Google Singapore ( >>>>>>> 70 >>>>>>> Pasir Panjang Road, #03 >>>>>>> -71, >>>>>>> 117371) on Work Session >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> * =E2=80=A2 **Luke Camery* >>>>>>> * =E2=80=A2 *Associate Product Manager >>>>>>> * =E2=80=A2 *Federated Identity >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Subscribe to the HARDTWARE >>>>> >>>>> mail list to learn about projects I am working on! >>>>> >>>> >>>> >>>> >>>> -- >>>> Subscribe to the HARDTWARE >>>> >>>> mail list to learn about projects I am working on! >>>> >>>> >>>> >>> >>> >>> -- >>> Subscribe to the HARDTWARE >>> >>> mail list to learn about projects I am working on! >>> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. >> ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D >> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D >> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D >> 109OW8XGYF2R4KSbIrNJ93Ol9JbZhzY4yeRIU_cqsrU&s=3D >> MHReHuR8iihnIL2tUrDyudmDM536Zzw3x3l_AYBdo8E&e=3D >> >> -- > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --=20 Best regards, Kathleen --94eb2c1135da2e5998055e111946 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Could you please send a summary report to the list from th= e side meetings for those of us that cannot attend?

    Than= k you,
    Kathleen

    On Wed, Nov 15, 2017 at 10:17 PM, Dick Hardt <dick= .hardt@gmail.com> wrote:
    Continue reviewing Annabelle=E2=80=99s draft, and then= distribution and control plane time permitting.

    On Thu, Nov 16, 2017 at 11:16 AM Phil= Hunt (IDM) <p= hil.hunt@oracle.com> wrote:
    =
    Agenda?

    Phil

    On Nov 16, 2017, at 11:10 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
    We have VIP B= this afternoon at 3:30.

    On Wed, N= ov 15, 2017 at 1:21 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    FYI: Clark (the room we have) is two rooms down = from Butterworth where we were meeting earlier.


    On Wed, Nov 15, 2017= at 1:15 PM, Marius Scurtescu <marius.scurtescu@gmail.com> wrot= e:
    Awesome. Waiting for= take out food, will go there as soon as I get it.

    Sent from my phone.

    On Nov 15, 2017 1:10 = PM, "Dick Hardt" <dick.hardt@gmail.com> wrote:
    <= blockquote class=3D"m_-337575948922754591m_3131324498101504111m_27500906453= 48104599m_-7394396981340918457quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex">
    We are confirmed to have Clark from = 1:20 - 3:20 now.

    On Wed, Nov 15, 2017 at 1:01 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
    No one has that room curre= ntly at that time. I'm trying to find an AD to schedule it for us. If a= nyone else comes across an AD, please ask them to reserve it for us.
    If nothing else, we can ask the people in that room right now = if we can have it later on.




    On Wed, Nov 15, 2017 at 12:35= PM, Luke Camery <lcamery@google.com> wrote:
    <= div dir=3D"auto">We *potentially* have the room Clark from 1:20-3:20. Confi= rmation will follow.=C2=A0

    On Tue,= Nov 14, 2017, 11:45 AM Luke Camery <lcamery@google.com> wrote:
    Future Meetings
    Wednesday - 10:30= -12:00 in Butterworth on Annabelle's Alternative SET Proposal
    Thurs= day - 15:30-18:00 in the Atrium on Marius' Control Plane
    Frid= ay - 10:00-18:00 at Google Singapore (70 Pasir Panjang Road, #03-71, 117371) on Work S= ession

    --
    =
    <= img src=3D"http://i.imgur.com/Ya4Rhss.gif" width=3D"96" height=3D"42">
    =C2=A0 =E2=80=A2 =C2=A0Luke Camery
    <= /font>=C2= =A0 =E2=80=A2 =C2=A0Associate Product Manager
    = =C2=A0 =E2=80=A2 =C2=A0= Fed= erated Identity

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    Subscribe to the HARDTWARE m= ail list to learn about projects I am working on!



    --
    Subscribe= to the HARDTWARE mail list to learn abo= ut projects I am working on!




    --
    =
    <= div>Subscribe to the HARDTWARE mail lis= t to learn about projects I am working on!
    --
    Subscribe to the = HARDTWARE mail list to learn about projects I am working on!
    <= span>_______________________________________________
    I= d-event mailing list
    Id-event@ietf.org
    <= div dir=3D"auto">
    --
    =
    Subscribe to the HARDTWARE mail list to learn about pro= jects I am working on!

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    =
    Best regards,
    Kathleen
    --94eb2c1135da2e5998055e111946-- From nobody Wed Nov 15 19:30:09 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DA4127010 for ; Wed, 15 Nov 2017 19:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwobFOHFoAvq for ; Wed, 15 Nov 2017 19:30:04 -0800 (PST) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69CD5124BE8 for ; Wed, 15 Nov 2017 19:30:04 -0800 (PST) Received: by mail-wr0-x22a.google.com with SMTP id z14so3402508wrb.8 for ; Wed, 15 Nov 2017 19:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uRPYk2LuRyPtoK0VewmrnMEThH5BFnqu2A6yEzwaCLI=; b=Zsh7q2n5eM7skMjeHIdRZDWPQVKAj2Mc3TcaN9usHLoy4JtLe+Ra4i/awrm+f7zGJZ iv7f7U8WbiiuBX8EddJDOM2dDMJzKI6a7arjIUoKf+OsPq5q20sz7Qoz/OW2aKJLPIuQ NfnnOPpqQUmq/SKPGJBG3D4vWIxhxEKvynzM2Xs6wU2roJJx+uQ7JMSAhHGUspr/RBOZ ur8lBpugd/2H+mXBXUck1sg/I0izp2ggRH9Z2Qz9QXbrhB2ab9dT73wE88/cU2ewGPnd rC/j1zXBdARKg7+N1p5GFbUeQ/vwl3wDYEiz0TQfKvpYCm2Od3v81gqJVom5ptFZf8qC 8PDg== 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=uRPYk2LuRyPtoK0VewmrnMEThH5BFnqu2A6yEzwaCLI=; b=rOkOq6NVlv+tDbRJFabsFuVR+MgxbfoiWSivp6YTBQM5Hm02+7rWlhiIabJ7TzZ478 MiqB/ac+9yRL0cwsYPjhPIRIm02P+wzGpHvmk3qels4PgDlW15qeRidNCQJFwhb5MIy0 tJ32t4McWXck6F2m0uiKFhS1Goq1ofcvQCroBT3DJTeQY1gHjBoIl5XLKYJkaUYSmJpy OPhOWMMN5uUgBlpzZ6fcKoduLZpllXJGeTgSURqFAJQl6wjBMDlI7cjDH0GBCP16U56r AFr68ZgIMX/UBm1UdqYPt8wN/7JVZFOWppRaPKpNimUYJdiKtMXI8s0z5WjFOhoaXw/N XYQg== X-Gm-Message-State: AJaThX5RTd8ihEkct3UXwGM2UiTZ6C6Sa/dPnXZOY4wtxmRnZ1x4bPCZ u9YWKhWD0MPIcO1WcGViFun5H3KSGtjkTU3kQWY= X-Google-Smtp-Source: AGs4zMbXKOv89w1+/VofeSop62eHnPBe3bOklTjKBFRumEfZnXNsVCITlGz9WEAEZhe7h9LvdyeCPXErzfquDnt+m0E= X-Received: by 10.223.146.37 with SMTP id 34mr159952wrj.79.1510803002758; Wed, 15 Nov 2017 19:30:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.151.131 with HTTP; Wed, 15 Nov 2017 19:30:01 -0800 (PST) Received: by 10.223.151.131 with HTTP; Wed, 15 Nov 2017 19:30:01 -0800 (PST) In-Reply-To: References: From: Marius Scurtescu Date: Wed, 15 Nov 2017 19:30:01 -0800 Message-ID: To: "Phil Hunt (IDM)" Cc: Dick Hardt , Anthony Nadalin , Luke Camery , Leif Johansson , Mike Jones , SecEvent Content-Type: multipart/alternative; boundary="94eb2c0d20de4e1c13055e113c96" Archived-At: Subject: Re: [Id-event] [Update] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 03:30:07 -0000 --94eb2c0d20de4e1c13055e113c96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Management API. I will walk through a comparison between the two proposals. Not sure if we need to finish anything from yesterday's meeting. Sent from my phone. On Nov 16, 2017 11:16 AM, "Phil Hunt (IDM)" wrote: > Agenda? > > Phil > > On Nov 16, 2017, at 11:10 AM, Dick Hardt wrote: > > We have VIP B this afternoon at 3:30. > > On Wed, Nov 15, 2017 at 1:21 PM Dick Hardt wrote: > >> FYI: Clark (the room we have) is two rooms down from Butterworth where w= e >> were meeting earlier. >> >> >> On Wed, Nov 15, 2017 at 1:15 PM, Marius Scurtescu < >> marius.scurtescu@gmail.com> wrote: >> >>> Awesome. Waiting for take out food, will go there as soon as I get it. >>> >>> Sent from my phone. >>> >>> On Nov 15, 2017 1:10 PM, "Dick Hardt" wrote: >>> >>> We are confirmed to have Clark from 1:20 - 3:20 now. >>> >>> On Wed, Nov 15, 2017 at 1:01 PM, Dick Hardt >>> wrote: >>> >>>> No one has that room currently at that time. I'm trying to find an AD >>>> to schedule it for us. If anyone else comes across an AD, please ask t= hem >>>> to reserve it for us. >>>> >>>> If nothing else, we can ask the people in that room right now if we ca= n >>>> have it later on. >>>> >>>> >>>> >>>> >>>> On Wed, Nov 15, 2017 at 12:35 PM, Luke Camery >>>> wrote: >>>> >>>>> We *potentially* have the room Clark from 1:20-3:20. Confirmation wil= l >>>>> follow. >>>>> >>>>> On Tue, Nov 14, 2017, 11:45 AM Luke Camery wrote= : >>>>> >>>>>> *Future Meetings* >>>>>> Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative SE= T >>>>>> Proposal >>>>>> Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane >>>>>> Friday - 10:00-18:00 at Google Singapore ( >>>>>> 70 >>>>>> Pasir Panjang Road, #03 >>>>>> -71, >>>>>> 117371) on Work Session >>>>>> >>>>>> -- >>>>>> >>>>>> * =E2=80=A2 **Luke Camery* >>>>>> * =E2=80=A2 *Associate Product Manager >>>>>> * =E2=80=A2 *Federated Identity >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Subscribe to the HARDTWARE >>>> >>>> mail list to learn about projects I am working on! >>>> >>> >>> >>> >>> -- >>> Subscribe to the HARDTWARE >>> >>> mail list to learn about projects I am working on! >>> >>> >>> >> >> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> > -- > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D > 109OW8XGYF2R4KSbIrNJ93Ol9JbZhzY4yeRIU_cqsrU&s=3D > MHReHuR8iihnIL2tUrDyudmDM536Zzw3x3l_AYBdo8E&e=3D > > --94eb2c0d20de4e1c13055e113c96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Management API. I will walk through a comparison between = the two proposals.

    Not sure if= we need to finish anything from yesterday's meeting.

    Sent from my phone.
    <= /div>

    On Nov 16, 2= 017 11:16 AM, "Phil Hunt (IDM)" <phil.hunt@oracle.com> wrote:
    Agenda?

    Phil
    =

    On Nov 16, 2017, at 11:10 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
    We have VI= P B this afternoon at 3:30.

    On Wed= , Nov 15, 2017 at 1:21 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    FYI: Clark (the room we have) is two rooms do= wn from Butterworth where we were meeting earlier.

    =

    On Wed, Nov 15, 2= 017 at 1:15 PM, Marius Scurtescu <marius.scurtescu@gmail.com> w= rote:
    Awesome. Waiting = for take out food, will go there as soon as I get it.

    Sent from my phone.

    On Nov 15, 2017 1:10 PM, "Dick Hardt" <dick.hardt@gmail.com> wrote:
    We are confirmed t= o have Clark from 1:20 - 3:20 now.

    On Wed, Nov 15, 2017 at 1:01 PM, Dick Hardt &l= t;    dick.hardt@gmai= l.com> wrote:
    No one h= as that room currently at that time. I'm trying to find an AD to schedu= le it for us. If anyone else comes across an AD, please ask them to reserve= it for us.

    If nothing else, we can ask the people in th= at room right now if we can have it later on.


    =


    On Wed, Nov 15, 2017 at 12:35 P= M, Luke Camery <lcamery@google.com> wrote:
    We *p= otentially* have the room Clark from 1:20-3:20. Confirmation will follow.= =C2=A0

    On Tue, Nov 14, 2017, 11:45= AM Luke Camery <lcamery@google.com> wrote:
    =
    Future Meetings
    Wednesday - 10:30-12:00 in Butterwort= h on Annabelle's Alternative SET Proposal
    Thursday - 15:30-18:00 in= the Atrium on Marius' Control Plane
    Friday - 10:00-18:00 at = Google Singapore (70 Pasir Panjang Road, #03-71, 117371) on Work Session
    <= span class=3D"m_-5242727143496985606m_2750090645348104599m_-739439698134091= 8457m_5615710805901951258m_-107635314010104633HOEnZb">

    --
    =
    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    <= div class=3D"m_-5242727143496985606m_2750090645348104599m_-7394396981340918= 457m_5615710805901951258m_-107635314010104633gmail_signature" data-smartmai= l=3D"gmail_signature">
    Subscribe to the HARDTWARE mail list to learn about projects I am= working on!


    --
    Subscribe to the HARDTWARE mail list to learn about projects I am= working on!




    --
    =
    Subscribe to the= HARDTWARE mail list to learn about proj= ects I am working on!
    --
    Subscribe to the HARDTWARE mail list to learn about project= s I am working on!
    <= /div> --94eb2c0d20de4e1c13055e113c96-- From nobody Wed Nov 15 19:33:59 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029F712945E for ; Wed, 15 Nov 2017 19:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y--oqXEz7BGb for ; Wed, 15 Nov 2017 19:33:55 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 3992A127010 for ; Wed, 15 Nov 2017 19:33:55 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id 17so18595085pfn.12 for ; Wed, 15 Nov 2017 19:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VgxZAA9uBAaKTcVl0/Znle0AQaTqto690wyldWORdKs=; b=MbLEQtWLDGJTcKbtFKlf/yKnsMf70zgUevqZEXyD1cW9z4L/EqbhMvyS3FgjAhD+Or fRhRh1JbqD5SP8XiHQM17Iwrv5ecEWOFlt6Ne6Sd6zJpjA3VelseslBxUfJvkXWZFggx 4e3VDZuREEO0hdjxz5xIOsOkdTbhHT7ZdiQJf6UQ5DY64zlXJK1CXPb044PShBu0POUk JRMCIGx19V7vIzTdYfgqIKhQ1x3GtMBRitfZIHjojLgwT7k1e3m3eBqD82MUPupg81L5 a9Buku+QUn0bsFk2HBv51io143OiXKgRuH9DIGSrPK3wnb2vCrMVkVKElEXx+c38BJYH tvGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VgxZAA9uBAaKTcVl0/Znle0AQaTqto690wyldWORdKs=; b=ZbuYd01Wcz8D0Zo1hjy6v47FekkjqLzprke5XU2rBVrkM04T3KvSATQV+VKioxWKWm kUOnt68tIm8Gyv+I1DHTyvLwWnbuKFNiWDaoVIftNKhvW7IPymjN3yD5gDimYPUArGEl ySyCyWM5BvBqf6+4vHS93RDzewvP1441/nUURoSR2Aq5sArW6xeu20JTEW4FimStUv3w Bmtq+TQLIr+PfKeAioOFt3pKoe3NAo0E4GMD4jn16ZVGoZsZsZG1xyOedE+cA5mosC0Y 5YZhLnvmX6ucbxSGYwV4kIJJdZt1c6RnjHPhEEp9Uy8eN2nb7+xfOAkDh1uZyU7/p4rY 745Q== X-Gm-Message-State: AJaThX4ZTTYZjV6o7+Tbp0uG8EKNGXry5ADoW3BoK58eOt8EfLFinEFJ +xKoDiGDMyK8fY5nzXFO7dSj0gKB3Gnp/2wcmSk= X-Google-Smtp-Source: AGs4zMaJZyCM4eDeaqL5qsbBxZfZMo+7SjsnZGT7vGAC8hL2Py1k6VJKNsQClkFORdJc+Zyq8jfgyoxixg1M9KfSN/8= X-Received: by 10.99.115.4 with SMTP id o4mr273496pgc.371.1510803234699; Wed, 15 Nov 2017 19:33:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 16 Nov 2017 03:33:42 +0000 Message-ID: To: Kathleen Moriarty Cc: Anthony Nadalin , Leif Johansson , Luke Camery , Marius Scurtescu , Mike Jones , "Phil Hunt (IDM)" , SecEvent Content-Type: multipart/alternative; boundary="f403045cd36421415e055e114a26" Archived-At: Subject: Re: [Id-event] [Update] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 03:33:58 -0000 --f403045cd36421415e055e114a26 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Will do. The conversation has been continuing, and will summarize when concluded. On Thu, Nov 16, 2017 at 11:20 AM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Could you please send a summary report to the list from the side meetings > for those of us that cannot attend? > > Thank you, > Kathleen > > On Wed, Nov 15, 2017 at 10:17 PM, Dick Hardt wrote= : > >> Continue reviewing Annabelle=E2=80=99s draft, and then distribution and = control >> plane time permitting. >> >> On Thu, Nov 16, 2017 at 11:16 AM Phil Hunt (IDM) >> wrote: >> >>> Agenda? >>> >>> Phil >>> >>> On Nov 16, 2017, at 11:10 AM, Dick Hardt wrote: >>> >>> We have VIP B this afternoon at 3:30. >>> >>> On Wed, Nov 15, 2017 at 1:21 PM Dick Hardt wrote= : >>> >>>> FYI: Clark (the room we have) is two rooms down from Butterworth where >>>> we were meeting earlier. >>>> >>>> >>>> On Wed, Nov 15, 2017 at 1:15 PM, Marius Scurtescu < >>>> marius.scurtescu@gmail.com> wrote: >>>> >>>>> Awesome. Waiting for take out food, will go there as soon as I get it= . >>>>> >>>>> Sent from my phone. >>>>> >>>>> On Nov 15, 2017 1:10 PM, "Dick Hardt" wrote: >>>>> >>>>> We are confirmed to have Clark from 1:20 - 3:20 now. >>>>> >>>>> On Wed, Nov 15, 2017 at 1:01 PM, Dick Hardt >>>>> wrote: >>>>> >>>>>> No one has that room currently at that time. I'm trying to find an A= D >>>>>> to schedule it for us. If anyone else comes across an AD, please ask= them >>>>>> to reserve it for us. >>>>>> >>>>>> If nothing else, we can ask the people in that room right now if we >>>>>> can have it later on. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Nov 15, 2017 at 12:35 PM, Luke Camery >>>>>> wrote: >>>>>> >>>>>>> We *potentially* have the room Clark from 1:20-3:20. Confirmation >>>>>>> will follow. >>>>>>> >>>>>>> On Tue, Nov 14, 2017, 11:45 AM Luke Camery >>>>>>> wrote: >>>>>>> >>>>>>>> *Future Meetings* >>>>>>>> Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative >>>>>>>> SET Proposal >>>>>>>> Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane >>>>>>>> Friday - 10:00-18:00 at Google Singapore ( >>>>>>>> 70 >>>>>>>> Pasir Panjang Road, #03 >>>>>>>> -71, >>>>>>>> 117371) on Work Session >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> * =E2=80=A2 **Luke Camery* >>>>>>>> * =E2=80=A2 *Associate Product Manager >>>>>>>> * =E2=80=A2 *Federated Identity >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Subscribe to the HARDTWARE >>>>>> >>>>>> mail list to learn about projects I am working on! >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Subscribe to the HARDTWARE >>>>> >>>>> mail list to learn about projects I am working on! >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Subscribe to the HARDTWARE >>>> >>>> mail list to learn about projects I am working on! >>>> >>> -- >>> Subscribe to the HARDTWARE >>> >>> mail list to learn about projects I am working on! >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> >>> >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65= eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D109OW8XGYF2R4K= SbIrNJ93Ol9JbZhzY4yeRIU_cqsrU&s=3DMHReHuR8iihnIL2tUrDyudmDM536Zzw3x3l_AYBdo= 8E&e=3D >>> >>> -- >> Subscribe to the HARDTWARE mail list to learn >> about projects I am working on! >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> > > > -- > > Best regards, > Kathleen > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --f403045cd36421415e055e114a26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Will do. The conversation has been continuing, and w= ill summarize when concluded.

    On T= hu, Nov 16, 2017 at 11:20 AM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:=
    Could you please send a summa= ry report to the list from the side meetings for those of us that cannot at= tend?

    Thank you,
    Kathleen

    On Wed, Nov 15, 2017 at 10:17 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
    Conti= nue reviewing Annabelle=E2=80=99s draft, and then distribution and control = plane time permitting.
    On Thu, Nov 16, 2017 at 11:16 AM Phil Hun= t (IDM) <phil.= hunt@oracle.com> wrote:
    Agenda?

    Phil
    On Nov 16, 2017, at 11:10 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

    We have VIP B thi= s afternoon at 3:30.

    On Wed, Nov 1= 5, 2017 at 1:21 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    FYI: Clark (the room we have) is two rooms down from= Butterworth where we were meeting earlier.


    On Wed, Nov 15, 2017 at = 1:15 PM, Marius Scurtescu <marius.scurtescu@gmail.com> wrote:
    Awesome. Waiting for tak= e out food, will go there as soon as I get it.

    Sent from my phone.

    On Nov 15, 2017 1:10 PM, "Dick Hardt" <dick.hardt@gmail.com= > wrote:
    We are confirmed to have Clark from 1:20 - 3:20 = now.

    On Wed,= Nov 15, 2017 at 1:01 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
    No one has that room currently at that= time. I'm trying to find an AD to schedule it for us. If anyone else c= omes across an AD, please ask them to reserve it for us.

    If nothing else, we can ask the people in that room right now if we can ha= ve it later on.




    On Wed, Nov 15, 201= 7 at 12:35 PM, Luke Camery <lcamery@google.com> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
    We *potentially* have the = room Clark from 1:20-3:20. Confirmation will follow.=C2=A0

    On Tue, Nov 14, 2017, 11:45 AM Luke Camery <lcamery@google.com= > wrote:
    Future Mee= tings
    Wednesday - 10:30-12:00 in Butterworth on Annabelle's Al= ternative SET Proposal
    Thursday - 15:30-18:00 in the Atrium on Marius&#= 39; Control Plane
    Friday - 10:00-18:00 at Google Singapore (70 Pasir Panjang Roa= d, #03-71, 117371) on Work Session

    --
    =C2=A0 =E2=80=A2 =C2=A0Luke Camery
    =C2=A0 =E2=80=A2 =C2=A0Associate Product Manager=
    =C2=A0 = =E2=80=A2 =C2=A0Federated Identity
    =
    		=C2=A0 =E2=80=A2 =C2=A0Luke Camery
    = =C2=A0 =E2=80=A2 =C2=A0Associate Product Manager
    =C2=A0 =E2=80=A2 =C2= =A0= Federated Identity

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    Subscribe to the HARDTWARE mail list to learn about project= s I am working on!



    --
    Subscribe to the HARDTWARE = mail list to learn about projects I am working on!
    <= /div>




    --
    =
    Subscribe to the = HARDTWARE mail list to learn about projects I am working on!
    --
    Subscribe to the HARDTWARE mail list to learn about projects I am= working on!
    <= span>_______________________________________________
    Id-eve= nt mailing list
    Id-event@ietf.org
    <= div>--
    Subscribe to the HARDT= WARE mail list to learn about projects I am working on!

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --

    Best regards,
    Kathleen
    --
    Subscribe to the HARDTWARE mail list to learn about projects I= am working on!
    --f403045cd36421415e055e114a26-- From nobody Wed Nov 15 20:00:17 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E238312948F for ; Wed, 15 Nov 2017 20:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nc8_7N-I2DK8 for ; Wed, 15 Nov 2017 20:00:13 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 77078124BE8 for ; Wed, 15 Nov 2017 20:00:13 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id 17so18642365pfn.12 for ; Wed, 15 Nov 2017 20:00:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8+mG+AGgxOuCa2CSYFyIFpRpAuPi6qjOu3uGn+tBZlQ=; b=TDgurUpFQpxqf0uHWldfpqayvz6BF34RfVeSguDo1JsVR4uRFT/XX3C38jBTAdHfex /vP28PLdRmDOW+7y1TlKEX3d9kXbuh39Ab8CZpGbcpt7FM0d0ecfY8zOMuiztISNN2C4 d1pPfFh18EbEKt9kosG1aUeDGyl+PzpW6jKO7MusSC2JHkOy6fIS0zbkhVSu39v2dwHH G9ZDyKMMrDO0j/QKciLUFyPhQUm/IuB3lIdGT6oF9gpYRMvjq8kRGVjfBVDwTj/OPNPM vWEltfW4Un61JIDXpVe2JeBpROFlf7l46W2xPRNuv3NKYpVFtBRZYt0ULry5Ons8DYxi 9SoQ== 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=8+mG+AGgxOuCa2CSYFyIFpRpAuPi6qjOu3uGn+tBZlQ=; b=HPyKaCfqnPxGsW3I5qEaStC4hRQEE8l48K7nGupplgO/m9ou4hhx75GL3EInyPz1vx itau+DVPL1q7VTcVUOpr65pDMrYDPxSepvHO9dnZ5eI7AE1azhutKV83+ub777ZFBV04 AjbxWw+ZBAE4oCxnR55HOBrqmYvNg7mtF1KLlii2jpYdeqZzLbbrOUhUa7YFXr5JYogR 0TNM0fzOh1zBlEKHTO0ZNFcrG8YQXpXY0SnnFb5n2FUWr5xqgsMLFMp7YPl4uYOkRrS7 N5bQ+HVW46lfrXWoCXbe6IoLgThJzSK526H0PIf1uA85O1g9PVadYCPpbGt9YNwvROJi Ffjg== X-Gm-Message-State: AJaThX5lWfuHMYLcpExPCDecoIicc0XAmLKz8w1WibES1qrs90lMUyL/ aPoWRCuCvpyM0SgxpZq4ZE1k0qK8vrZb2Ct//60= X-Google-Smtp-Source: AGs4zMaZ4QAoVAJhlPw83M3RtlbFV0E0oata5LEYIj97O9kjPd3pTro4RvPnDD4/Qg+MPOhIOpkeNgmHrgJfNdIkS+U= X-Received: by 10.99.117.70 with SMTP id f6mr337801pgn.339.1510804813092; Wed, 15 Nov 2017 20:00:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.155.9 with HTTP; Wed, 15 Nov 2017 19:59:32 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Wed, 15 Nov 2017 22:59:32 -0500 Message-ID: To: Dick Hardt Cc: Anthony Nadalin , Leif Johansson , Luke Camery , Marius Scurtescu , Mike Jones , "Phil Hunt (IDM)" , SecEvent Content-Type: multipart/alternative; boundary="f403045cd374359df4055e11a852" Archived-At: Subject: Re: [Id-event] [Update] Plan for the Week X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 04:00:16 -0000 --f403045cd374359df4055e11a852 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you! On Wed, Nov 15, 2017 at 10:33 PM, Dick Hardt wrote: > Will do. The conversation has been continuing, and will summarize when > concluded. > > On Thu, Nov 16, 2017 at 11:20 AM Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Could you please send a summary report to the list from the side meeting= s >> for those of us that cannot attend? >> >> Thank you, >> Kathleen >> >> On Wed, Nov 15, 2017 at 10:17 PM, Dick Hardt >> wrote: >> >>> Continue reviewing Annabelle=E2=80=99s draft, and then distribution and= control >>> plane time permitting. >>> >>> On Thu, Nov 16, 2017 at 11:16 AM Phil Hunt (IDM) >>> wrote: >>> >>>> Agenda? >>>> >>>> Phil >>>> >>>> On Nov 16, 2017, at 11:10 AM, Dick Hardt wrote: >>>> >>>> We have VIP B this afternoon at 3:30. >>>> >>>> On Wed, Nov 15, 2017 at 1:21 PM Dick Hardt >>>> wrote: >>>> >>>>> FYI: Clark (the room we have) is two rooms down from Butterworth wher= e >>>>> we were meeting earlier. >>>>> >>>>> >>>>> On Wed, Nov 15, 2017 at 1:15 PM, Marius Scurtescu < >>>>> marius.scurtescu@gmail.com> wrote: >>>>> >>>>>> Awesome. Waiting for take out food, will go there as soon as I get i= t. >>>>>> >>>>>> Sent from my phone. >>>>>> >>>>>> On Nov 15, 2017 1:10 PM, "Dick Hardt" wrote: >>>>>> >>>>>> We are confirmed to have Clark from 1:20 - 3:20 now. >>>>>> >>>>>> On Wed, Nov 15, 2017 at 1:01 PM, Dick Hardt >>>>>> wrote: >>>>>> >>>>>>> No one has that room currently at that time. I'm trying to find an >>>>>>> AD to schedule it for us. If anyone else comes across an AD, please= ask >>>>>>> them to reserve it for us. >>>>>>> >>>>>>> If nothing else, we can ask the people in that room right now if we >>>>>>> can have it later on. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Nov 15, 2017 at 12:35 PM, Luke Camery >>>>>>> wrote: >>>>>>> >>>>>>>> We *potentially* have the room Clark from 1:20-3:20. Confirmation >>>>>>>> will follow. >>>>>>>> >>>>>>>> On Tue, Nov 14, 2017, 11:45 AM Luke Camery >>>>>>>> wrote: >>>>>>>> >>>>>>>>> *Future Meetings* >>>>>>>>> Wednesday - 10:30-12:00 in Butterworth on Annabelle's Alternative >>>>>>>>> SET Proposal >>>>>>>>> Thursday - 15:30-18:00 in the Atrium on Marius' Control Plane >>>>>>>>> Friday - 10:00-18:00 at Google Singapore ( >>>>>>>>> 70 >>>>>>>>> Pasir Panjang Road, #03 >>>>>>>>> -71, >>>>>>>>> 117371) on Work Session >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> * =E2=80=A2 **Luke Camery* >>>>>>>>> * =E2=80=A2 *Associate Product Manager >>>>>>>>> * =E2=80=A2 *Federated Identity >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Id-event mailing list >>>>>>>> Id-event@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Subscribe to the HARDTWARE >>>>>>> >>>>>>> mail list to learn about projects I am working on! >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Subscribe to the HARDTWARE >>>>>> >>>>>> mail list to learn about projects I am working on! >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Subscribe to the HARDTWARE >>>>> >>>>> mail list to learn about projects I am working on! >>>>> >>>> -- >>>> Subscribe to the HARDTWARE >>>> >>>> mail list to learn about projects I am working on! >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. >>>> ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D >>>> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D >>>> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D >>>> 109OW8XGYF2R4KSbIrNJ93Ol9JbZhzY4yeRIU_cqsrU&s=3D >>>> MHReHuR8iihnIL2tUrDyudmDM536Zzw3x3l_AYBdo8E&e=3D >>>> >>>> -- >>> Subscribe to the HARDTWARE mail list to learn >>> about projects I am working on! >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >> >> >> -- >> >> Best regards, >> Kathleen >> > -- > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > --=20 Best regards, Kathleen --f403045cd374359df4055e11a852 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thank you!

    On Wed, Nov 15, 2017 at 10:33 PM, Dick Hardt <dick.har= dt@gmail.com> wrote:
    <= div dir=3D"auto">Will do. The conversation has been continuing, and will su= mmarize when concluded.

    On Thu, Nov 16, 2017 at 11:20 AM Kathleen Moriarty <kathleen.mor= iarty.ietf@gmail.com> wrote:
    Could you please send a summary report to the list from the side= meetings for those of us that cannot attend?

    Thank you,=
    Kathleen

    On Wed, Nov 15, 2017 at 10:= 17 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
    Continue reviewing Annabelle=E2=80=99s= draft, and then distribution and control plane time permitting.
    =

    On Thu, Nov 16, 2017 at 11:16 AM Phil Hunt (IDM) <= ;phil.hunt@oracle= .com> wrote:
    Agenda?

    Phil

    On Nov 16= , 2017, at 11:10 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

    We have VIP B this afternoon= at 3:30.

    On Wed, Nov 15, 2017 at = 1:21 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    FYI: Clark (the room we have) is two rooms down from Butterwort= h where we were meeting earlier.


    On Wed, Nov 15, 2017 at 1:15 PM, Ma= rius Scurtescu <marius.scurtescu@gmail.com> wrote:
    Awesome. Waiting for take out food,= will go there as soon as I get it.

    Sent from my phone.

    On Nov 15, 2017 1:10 PM,= "Dick Hardt" <dick.hardt@gmail.com> wrote:
    We are confirmed to have Clark from 1:20 - 3:20 now.

    On Wed, Nov 15, 2017 at 1:0= 1 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
    No one has that room currently at that time. I'm try= ing to find an AD to schedule it for us. If anyone else comes across an AD,= please ask them to reserve it for us.

    If nothing else, = we can ask the people in that room right now if we can have it later on.




    On Wed, Nov 15,= 2017 at 12:35 PM, Luke Camery <lcamery@google.com> wrote:
    = We *potentially* have the room Clark from 1:20-3:20. Confirmation will foll= ow.=C2=A0

    On Tue, Nov 14, 2017, 11= :45 AM Luke Camery <lcamery@google.com> wrote:
    Future Meetings
    Wednesday - 10:30-12:00 in Butterw= orth on Annabelle's Alternative SET Proposal
    Thursday - 15:30-18:00= in the Atrium on Marius' Control Plane
    Friday - 10:00-18:00 = at Google Singapore (= 70 Pasir Panjang Road, #03-71, 117371) on Work Session
    =

    --
    =C2=A0 =E2=80=A2 =C2=A0Luke Camery
    =C2=A0 = =E2=80=A2 =C2=A0Associate Product Manager
    =C2=A0 =E2=80=A2 =C2=A0Feder= ated Identity

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event


    <= br clear=3D"all">

    --
    Subscribe to the = HARDTWARE mail list to learn about projects I am working on!



    --
    Subscribe to the HARDTWARE mail list to learn about projects I am working on!




    --
    =
    Subscribe to the HARDTWARE mail list to learn about projects I am= working on!
    --
    Subsc= ribe to the HARDTWARE mail list to learn= about projects I am working on!
    <= span>_______________________________________________
    I= d-event mailing list
    Id-event@ietf.org
    <= div dir=3D"auto">
    --
    Subscribe to the HARDTWARE mail list to learn = about projects I am working on!

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --

    B= est regards,
    Kathleen
    --



    --
    =

    Best regards,
    Kathleen
    --f403045cd374359df4055e11a852-- From nobody Thu Nov 16 01:37:20 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2AA1292AE for ; Thu, 16 Nov 2017 01:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 652UBoqOR7Vq for ; Thu, 16 Nov 2017 01:37:16 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51DB2126C2F for ; Thu, 16 Nov 2017 01:37:16 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id d2so14334609ywb.11 for ; Thu, 16 Nov 2017 01:37:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xNSMzSwP7G52WKFR/o3Ys5EhR7noVdH5N2kXXHC9Uug=; b=T/j3ohfdc22knmjlLUPyGzaYJUOCVs3SvBx+8Y43EBMqFKMcFBYnL62wpdZgmgNmfw vsmHD53tmPktNufVO+u5jixysTzK2I2QbR6mglBXhqzrE91sCNJz8ioMOKJ7em8kvoEy sELSkMHSz7SJAaTfFC3nZ7Tdt1IH4ERB7xMPQg9kNFnmZdUYE6Y1r/mKGzId2nteUQcY XBjZ2ZAsxQhb9UZorpjHdpeBmpaOwvaO1NZNeQyP08+tDGz+qbJiOBMkk+o4oViI97Nq fq1zLajKDHqQkB3+4OJBi5wdfrwo87TLQj/8kDfLHRLcYT9XTcX/gMMiPOpxhEbraJEk ZycQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xNSMzSwP7G52WKFR/o3Ys5EhR7noVdH5N2kXXHC9Uug=; b=AfYRzs7B8gZelGROo7a6VIFnNMTGzVuLqOg1zvoHYIZiGIvHsJBcAYGxH2QGxq4yCB TjxI+xUgzqQTLnllhEAbfZ9xojp1o4Xy39avZoY7+8ioGjrwlbXUrzVSOIt5rltq5sYB hfQbkAM/Cffhgq40CJdlYQX2L9fM2YbYKqyw0EcVCiDIlhmzMZjUq+p+GyOtk+BPKkp/ tFXYVxb+eRvLsyYkfX9QH6AABU62Gkiq3JzSS2QFRDdvLWPdiLotAGCj5esgscxrJkru lwyNkkFkJf8+bvXrkZbp7Ewgbyz1WOiy38WL/pE7Fg4o3j7zLfyodZ5J4qWTp0bW8/Rl Ve3g== X-Gm-Message-State: AJaThX7vq4yHcDhj6TeBxs+j+gk+ZrYCcdKnVlmUqSnOd645fIjHRk3k K5RsyDP5glatjmz1GUzvGNWw69YLwKAhoCLYTGUA/4rIG3k= X-Google-Smtp-Source: AGs4zMbDtKFGLhPvKfHCWCjoCvGEZJNrIBkYnx3fopNlWCO5vlCarOWE9StbCWTWd3bYNYRXm1EnPBr7we0aPZaBNDE= X-Received: by 10.37.135.69 with SMTP id e5mr144048ybn.124.1510825035106; Thu, 16 Nov 2017 01:37:15 -0800 (PST) MIME-Version: 1.0 From: Luke Camery Date: Thu, 16 Nov 2017 09:37:04 +0000 Message-ID: To: id-event@ietf.org Content-Type: multipart/alternative; boundary="089e0828e6bc89a730055e165d5d" Archived-At: Subject: [Id-event] Adhoc Meeting 11/16/17 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 09:37:18 -0000 --089e0828e6bc89a730055e165d5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable TL;DR - Meet in the building lobby at 9:40 to be escorted upstairs for a 10:00 start *Time* 09:40-15:30 *Location* Google Singapore 70 Pasir Panjang Road, #03-71, 117371 *Agenda* 1. Review and discuss the two Management API drafts: - Spec 1 - Spec 2 2. Address remaining open questions --=20 * =E2=80=A2 **Luke Camery* * =E2=80=A2 *Associate Product Manager * =E2=80=A2 *Federated Identity --089e0828e6bc89a730055e165d5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    TL;DR - Meet in the building lobby at 9:40 to be esco= rted upstairs for a 10:00 start

    Time=
    09:40-15:30

    Location
    Googl= e Singapore
    70 Pasir Panjang Road,= #03-71, 117371

    Agenda
    1. Review and discuss the two Management API drafts:
    =C2=A0 - Spec 2
    2. = Address remaining open questions

    --
    		=C2=A0 =E2=80=A2 =C2=A0Luke Camery=C2=A0 =E2=80=A2 =C2=A0Associate Product Manager
    <= /font>=C2=A0 =E2=80=A2 = =C2=A0Federated Identity
    --089e0828e6bc89a730055e165d5d-- From nobody Thu Nov 16 16:44:54 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9ABD1272E1 for ; Thu, 16 Nov 2017 16:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D25bIrt1ZjuH for ; Thu, 16 Nov 2017 16:44:51 -0800 (PST) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::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 1CF6E126CD8 for ; Thu, 16 Nov 2017 16:44:51 -0800 (PST) Received: by mail-yb0-x22f.google.com with SMTP id e83so109553yba.4 for ; Thu, 16 Nov 2017 16:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=G/1tJAmrqnNasjruQ/yFFPPhvM3oh73uRcWGW9zDzjg=; b=WXK4kEVT/xEw53k62071T59CEHVYgyL9RI84Sxc5KfSQ8G59AgglkMrWJoNLTQvd9T E0vEGAVkRJUFT7S/UMcFT0Xl6iXAPLlUElKrxCeiwJa5CYJluA9QrCspz6seX7mbMYi2 Iggp477JzJRf331A36XDWrit9w7orgqGSlAnTKhXTOl98jzy3t35DnURzoRsd0DcGSls BRQ+0X9DQye5BKaPlduSRCmYJAVlFcl/KyKwSjnfTWWqBH7ygfZ0OE87b9LSoki23BJb tAXKPFQ90OJoHpA6oSdZxcxR1cFxl19x5KZL/GY1dwVjNlYkVzpwuDX0LsoPOGNUPTlP 3X6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=G/1tJAmrqnNasjruQ/yFFPPhvM3oh73uRcWGW9zDzjg=; b=HSRiGaEiRCH01adt5VKlr66LDiAEW7XnO1rUIVlf3bCNHaRiDieB1nLjdzNaFNORKV Iv+hoEG1a7dFDboqmneBhzAhAE7IjW8Jh3sMCnJQ173YCpja4VVPvN3+a+mZ2/BQKIWl Leja+nXxAUZmnMK142PVKrVWEt6JgK2svDck36h7b2uI4uVbQ4fb6A3cE3EtZie/AMxQ xjPkuLnbjwCxBndVCSV4gVCu3OW44oSeGCe2RILcv7dRdCE/gSBmud3k1UrEbI4tNZ9L OFZ1aS4PQ9U5BtFLQzhOlcbqK19VTiiXR+0Rva3nfUk1FjmkadAo9uTEw9k1BjyDlZbQ wc4w== X-Gm-Message-State: AJaThX7zavqWKlFu778OIWzZx8dSnq2O5Rvv9127jJM5MXTIHonsiznt P06FfN5P8ky8hCyThxx/EkYGU1hOPBBQJ0E/bagPFz8i X-Google-Smtp-Source: AGs4zMaiFunB4fgzXOs5qcO/ffBO1av8PQsPtnk7KSSPdxaL82GAaMF+XA7sQ7cI8jf8wmrwSr0EmOgW84jsakyCh/8= X-Received: by 10.37.1.133 with SMTP id 127mr2003972ybb.402.1510879489729; Thu, 16 Nov 2017 16:44:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Luke Camery Date: Fri, 17 Nov 2017 00:44:38 +0000 Message-ID: To: id-event@ietf.org Content-Type: multipart/alternative; boundary="001a113cec384938d4055e230b10" Archived-At: Subject: Re: [Id-event] Adhoc Meeting 11/16/17 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 00:44:53 -0000 --001a113cec384938d4055e230b10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Since my cab driver was confused, I should I'd sent helpful directional tips. See here for the exact coordinates that you're going to. Note that you'll see Mapletree Business Center from the highway. Enter the complex and follow the internal roads for 60-80. There will be three stops at the second tower with the center stop being 70 (and your destination). The lobby is exclusively for Google with lots of Google branding so you'll recognize it. Ping me when you arrive. On Thu, Nov 16, 2017 at 5:37 PM Luke Camery wrote: > TL;DR - Meet in the building lobby at 9:40 to be escorted upstairs for a > 10:00 start > > *Time* > 09:40-15:30 > > *Location* > Google Singapore > 70 Pasir Panjang Road, #03-71, 117371 > > *Agenda* > 1. Review and discuss the two Management API drafts: > - Spec 1 > > - Spec 2 > > 2. Address remaining open questions > > -- > > * =E2=80=A2 **Luke Camery* > * =E2=80=A2 *Associate Product Manager > * =E2=80=A2 *Federated Identity > > -- * =E2=80=A2 **Luke Camery* * =E2=80=A2 *Associate Product Manager * =E2=80=A2 *Federated Identity --001a113cec384938d4055e230b10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Since my cab driver was confused, I should I'd sent he= lpful directional tips. See he= re for the exact coordinates that you're going to.

    Note that you'll see Mapletree Business Center from the highway. Ent= er the complex and follow the internal roads for 60-80. There will be three= stops at the second tower with the center stop being 70 (and your destinat= ion). The lobby is exclusively for Google with lots of Google branding so y= ou'll recognize it. Ping me when you arrive.


    On Thu, Nov 16, 2017 at 5:37 PM Luke C= amery <lcamery@google.com> = wrote:
    TL;DR = - Meet in the building lobby at 9:40 to be escorted upstairs for a 10:00 st= art

    Time
    09:40-15:30
    =

    Location
    Google Singapore
    70 Pasir Panjang Road, #03-71, 117371

    Agenda
    1. Review and discuss the = two Management API drafts:
    =C2=A0 -=C2=A0Spec 1
    =C2=A0 - Spec 2
    2. Address remaining open questions

    -- <= br>
    =C2=A0 =E2=80=A2 =C2=A0Luke Came= ry
    =C2=A0 =E2=80=A2 =C2=A0Associate Product Manager=
    =C2=A0 =E2=80=A2 =C2=A0Federated Identity
    --
    =
    =C2=A0 =E2=80=A2 =C2=A0Lu= ke Camery
    =C2=A0 =E2=80=A2 =C2=A0Associate Product = Manager
    =C2=A0 =E2=80=A2 =C2=A0Federated Identity
    --001a113cec384938d4055e230b10-- From nobody Thu Nov 16 16:55:47 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A05C126CD8 for ; Thu, 16 Nov 2017 16:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9N53tQX0r3p0 for ; Thu, 16 Nov 2017 16:55:43 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35AED126BF0 for ; Thu, 16 Nov 2017 16:55:43 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id u3so660459pgn.7 for ; Thu, 16 Nov 2017 16:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=V8AsQfON7BXsD/qZ9uVHW1Hm/tY+jtHoKJUVX9FUCsg=; b=vccTivitQgZKKNQ8BFFcPFGDvcQXNSp4gw73joBJ/EewJ/RQmj+bG+HiEnPKyAquAI i4BL3F/IOBGgbHjgF4/usCbeycqeesTckzoNjb6OweiayWqig7AecoSxmmcCqwlMOFcg 4QqhLvDSepeXskv+rQArUNzwjQ5pMLB3GIVzYeTtc9eGcDBCp6E/ZhlfZO4RX+n1xOPS ZdF0OQ0N9QSa0MaHZC9VJnvbkFUxVvc5LQteXWHLe5KuB7DHcJt88mviGQzqIrbuMvji QBzxVOx1n3zd2TkG31omGCstBJo4RPA9CxOolJZANqwysnaEJ5mTIYyQzXmnXAnGrmHO A4Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=V8AsQfON7BXsD/qZ9uVHW1Hm/tY+jtHoKJUVX9FUCsg=; b=as1JGUzEvgb/+XsLQsDjfKZmGVzHNFhxdzmJ92AOOgn/LuJd0bRuSIb9I5emybxJwS irrRq9HGCnCfG2xLp6V/SI4bkOHsDmmvGqWvoLT4Xj5rkmhnqtDnNU1y8pWwJT5FJxxh kPVuvKOtX3lfy1KsQee/X7lBq2RA1qEwTo/J2+5yDRvDhc+SLyMipQfquTLDE0GwbYMM go9lnxi4vJ2xB11W+5WlNBgva1LSiG8RBp3T+M2OWoIJACxqeQQ1aNbnag2jY9c4BCQv LaqvWg5VTxBBmS2Hac5zYrQgDtz2jcB6h0ZJJ5QqUN1fc5k2C+ZxIFwvGDCIJrKrmhPU wjjA== X-Gm-Message-State: AJaThX425FfRYVl3/bBJye/dfKfuUVWHUyMxC6P9IBfXREjTc1EsFyIz lLAFuH7KzuwJfTgYp7FZFP9BECRsh8ifKwq5AMQ= X-Google-Smtp-Source: AGs4zMZDH8trOzPcGzIa1qrOK8bOM2POl2Umx1EGD/kK+WgYhosZYnd9JPlH9ZiNhTHi4SguDU4wEHAH2ZCtzjp5tGI= X-Received: by 10.101.93.9 with SMTP id e9mr3320671pgr.302.1510880142648; Thu, 16 Nov 2017 16:55:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 17 Nov 2017 00:55:30 +0000 Message-ID: To: Luke Camery , id-event@ietf.org Content-Type: multipart/alternative; boundary="089e0824731c336b2a055e233252" Archived-At: Subject: Re: [Id-event] Adhoc Meeting 11/16/17 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 00:55:45 -0000 --089e0824731c336b2a055e233252 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Luke Uber knows the destination as Google, so hoping that is seemless. On Fri, Nov 17, 2017 at 8:44 AM Luke Camery wrote: > Since my cab driver was confused, I should I'd sent helpful directional > tips. See here for the exact > coordinates that you're going to. > > Note that you'll see Mapletree Business Center from the highway. Enter th= e > complex and follow the internal roads for 60-80. There will be three stop= s > at the second tower with the center stop being 70 (and your destination). > The lobby is exclusively for Google with lots of Google branding so you'l= l > recognize it. Ping me when you arrive. > > > On Thu, Nov 16, 2017 at 5:37 PM Luke Camery wrote: > >> TL;DR - Meet in the building lobby at 9:40 to be escorted upstairs for a >> 10:00 start >> >> *Time* >> 09:40-15:30 >> >> *Location* >> Google Singapore >> 70 Pasir Panjang Road, #03-71, 117371 >> >> *Agenda* >> 1. Review and discuss the two Management API drafts: >> - Spec 1 >> >> - Spec 2 >> >> 2. Address remaining open questions >> >> -- >> >> * =E2=80=A2 **Luke Camery* >> * =E2=80=A2 *Associate Product Manager >> * =E2=80=A2 *Federated Identity >> >> -- > > * =E2=80=A2 **Luke Camery* > * =E2=80=A2 *Associate Product Manager > * =E2=80=A2 *Federated Identity > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --089e0824731c336b2a055e233252 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks Luke

    Uber knows the destination as Google, so hoping that is seemless= .

    On Fri, Nov 17, 2017 at 8:44 AM = Luke Camery <lcamery@google.com> wrote:
    Since my cab driv= er was confused, I should I'd sent helpful directional tips. See here for the e= xact coordinates that you're going to.

    Note that you= 'll see Mapletree Business Center from the highway. Enter the complex a= nd follow the internal roads for 60-80. There will be three stops at the se= cond tower with the center stop being 70 (and your destination). The lobby = is exclusively for Google with lots of Google branding so you'll recogn= ize it. Ping me when you arrive.


    On Thu, Nov 16, 2017 at 5:37 PM Luke Camery <lcamery@google.com> wrote:
    =
    TL;DR - Meet in the building= lobby at 9:40 to be escorted upstairs for a 10:00 start

    <= /b>
    Time
    09:40-15:30

    = Location
    Google Singapore
    70 Pasir Panjang Road, #03-71, 117371

    Agenda
    1. Review and discuss the two Management API dra= fts:
    =C2=A0 -=C2=A0Spec 1
    =C2=A0 - Spec 2
    2. Address remainin= g open questions

    --
    		=C2=A0 =E2=80=A2 =C2=A0Luke Camery
    =C2=A0 =E2=80=A2 =C2=A0Associate Product Manager
    <= /b>    =C2=A0 =E2=80= =A2 =C2=A0Federated Identity
    --
    =C2=A0 =E2=80=A2 =C2=A0Luke Camery
    =C2=A0 =E2=80=A2 =C2=A0Associate Product Manager
    = =C2=A0 =E2=80=A2 =C2=A0Federated Identity
    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event
    --
    Subscribe to the HARDTWARE mail list to learn about projects I= am working on!
    --089e0824731c336b2a055e233252-- From nobody Sat Nov 18 23:06:38 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2442F126CC4 for ; Sat, 18 Nov 2017 23:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ywr4Eef4Swe for ; Sat, 18 Nov 2017 23:06:35 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2478E1242EA for ; Sat, 18 Nov 2017 23:06:34 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id q4so4974187pfg.13 for ; Sat, 18 Nov 2017 23:06:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=7Sxb5oOLYagkkhZMQe3AMWTMsSEgd3iSdwz7DlQgsvg=; b=KmvtLoF/JKQJ776K5iDQFVmwog3oOsiIDhSrDPXF7PxBoOhBi6e4jrIJQXbhGMnoJq UX3j+P1ijad9YyYllmkvZjHD0SHi3UrH8aE1PNR77cQCVDxTHkXIDISoz23mcmZNbVgx 4Sc5Ff69dzPX7vHl5rh+eqalyaXcDWc+4bLbJfwfFg+cetpC/A4wCeuEVnW84Nvbb6cv O/06eyQbND8BcbA30P1IvwL+yZm4drex/BoGlTfx2zBqM0LkdNJ8doJsDz8kPUHHNHii PQ43YWTaR/tIcFtEHlKlCWKvmzPYJHIW6Mlj9A2ZJCeeF4p9dxOsSqM5m3pqRJBeWNF3 sE0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7Sxb5oOLYagkkhZMQe3AMWTMsSEgd3iSdwz7DlQgsvg=; b=dpn35pPn61oEx9b/CnPQAxaNgRgwYbS0AvWGUC9AN36IHlzfYBCP6fjrNFIZm5fnoJ OPmXvcravFeW54A10xDJk5DuKZ/gklF7fgWL3UvBETw7/uerg3RYAFgD/b4lSTqsxWCX 37fKVGSEfnZaiComzO5h9+MxLLusnxcjst8RzIrd/ksA9V6LHgYql6P1SrtTBwG8BaMT J0EPpXs6xzGRHK3vyG4SE6lhWbWBUzCxJ7FOgVUvSm/gEdVIes85+7FKntTs668WYUd0 SVunC8N++l9/jZGnHmmljG//dIKqj3S6Jx7pjtrys03De6xtTWgWUNWaUKffrWtTMa6i mnOQ== X-Gm-Message-State: AJaThX4y+R7e0xRwFCY7n0chEJFKvb3t1pbM7ffpXyq7Gh3MusfYKieT O8cz3Myuu8UJkpgELTt7lErtt/pDjwPZPdlB2yE= X-Google-Smtp-Source: AGs4zMaS7EOrNebPxZLmpPGW8Pi0cQCN/qMIQQmQhBAFU4GAMCJfutId0jVXRgpJbUGWT44BGxKuZoSMUyBEPtHJPhw= X-Received: by 10.101.93.9 with SMTP id e9mr9619267pgr.302.1511075194193; Sat, 18 Nov 2017 23:06:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.143.133 with HTTP; Sat, 18 Nov 2017 23:06:13 -0800 (PST) From: Dick Hardt Date: Sun, 19 Nov 2017 15:06:13 +0800 Message-ID: To: SecEvent Content-Type: multipart/alternative; boundary="089e0824731c2dcd39055e509c1b" Archived-At: Subject: [Id-event] HEADS UP - upcoming consensus discussions X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 07:06:36 -0000 --089e0824731c2dcd39055e509c1b Content-Type: text/plain; charset="UTF-8" Hey WG For those that were not in Singapore, there was lots of side meetings, and we identified a number of topics that we are going to ask for consensus on. Watch this list for upcoming emails describing the topics and the choices (and of course the opportunity to discuss those) /Dick --089e0824731c2dcd39055e509c1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hey WG

    For those that were not in Singapore, there was lots of= side meetings, and we identified a number of topics that we are going to a= sk for consensus on.

    Watch this list for upcoming = emails describing the topics and the choices (and of course the opportunity= to discuss those)

    /Dick
    --089e0824731c2dcd39055e509c1b-- From nobody Mon Nov 27 15:31:04 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4246127419 for ; Mon, 27 Nov 2017 15:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpm7xo4mD0it for ; Mon, 27 Nov 2017 15:31:00 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABED9127005 for ; Mon, 27 Nov 2017 15:31:00 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id l24so18101377pfj.6 for ; Mon, 27 Nov 2017 15:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=/E0t6hIBecbmE9APtBMA9TRAlgdQPb6sQ4EGPX1yJwI=; b=fjrKcPbxca0jkQ0Q1BpQ/NTxyGFr5y61qYJ6PEZusLYav9LTd0CudwgyAyHtjg8+0l wdiT6gnGWjjb8sG2JYuDmbQGRdaUCinzUm1F00Z+lr/ZoOVU2GWZI+N9lEztIoTFPqGi o+5qUsudEMoRy7rvtG9vdPr/bNdJ2xHAIm0Y2Am5AkuUOb+r4VTdW5mBdcL/JCO74Wbo Fqmt12+75ydFJFLjuJBiOipOePMmnoYSaoalbpIxZUfDSwGLn2PsjXolZz6RBCQGu4aQ /zrIe86Xt+lsdRmAgmfQBerze/qCTjAZTURmJiJgd4mF8yvIoWGCtT3STtZ8hLD8MjGR RBHQ== 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=/E0t6hIBecbmE9APtBMA9TRAlgdQPb6sQ4EGPX1yJwI=; b=IhFsx2trTU1XL+f+xVM0IkRbmX0XgMzL4q/Yy8vW+HwTHiStO2l3lCn4nSCGKixPrZ ePL/+nPwnI3Sq+mQyQTttqfW2XdnzkwWwHGqtkkgrV9a2SYzqMOJIVXdkt79ioYb/F3h eBSiIkawyAL+8bo1ESsKcPhGJMRO3P36pv9N/sQNGSZPQJRNpkwmC3ZRaJPLZVg/Z4In TV+VwVUoLw3aLgnutmPGXGDhd3ieEbHLdktAAG0aU9e0/12UREPg1StfCc9X6zuqxgt0 HspRgDqrBBDGMUbOidX234HRpKlukasroAgsdj377oNcxMBXLsuhRB6F4lHVoFSLfj5n ZTLQ== X-Gm-Message-State: AJaThX4POtK87IZ1z6ePEuIwGv3YcDLBnA9RmKNvD4UO0pZrF0BeZB6O DVkq2CFi9PtpyV9zOen7DPJ46jY/Uv4xth38jQc= X-Google-Smtp-Source: AGs4zMZvwwiCOuJtrFUQmt0LmnltDF/ecSs4DDv6ze5Ji8lnaACKYpZzoOjhDgsXwvYsOlGPzBcX6ER+3HwiTlGLgaw= X-Received: by 10.98.127.149 with SMTP id a143mr39140152pfd.65.1511825459748; Mon, 27 Nov 2017 15:30:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.143.133 with HTTP; Mon, 27 Nov 2017 15:30:39 -0800 (PST) From: Dick Hardt Date: Mon, 27 Nov 2017 15:30:39 -0800 Message-ID: To: SecEvent Cc: "Morteza Ansari (moransar)" Content-Type: multipart/alternative; boundary="94eb2c1268147da560055eff4bf5" Archived-At: Subject: [Id-event] Control Plane Author's meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 23:31:03 -0000 --94eb2c1268147da560055eff4bf5 Content-Type: text/plain; charset="UTF-8" As we currently do not have a WG document for the control plane, the authors and interested parties are getting together to discuss the control plane personal draft. Anyone interested and wanting to contribute is welcome to join. Meeting is Dec 20th hosted by Cisco campus in San Jose CA. Please contact Morteza if you are planning to join. Minutes from the meeting will be posted to the list. NOTE: this is not an official working group meeting, but wanted to provide transparency on related discussions to this list. -- Dick --94eb2c1268147da560055eff4bf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    As we currently do not have a WG document for the control = plane, the authors and interested parties are getting together to discuss t= he control plane personal draft. Anyone interested and wanting to contribut= e is welcome to join. Meeting is Dec 20th hosted by Cisco campus in San Jos= e CA. Please contact Morteza if you are planning to join. Minutes from the = meeting will be posted to the list.

    NOTE: this is not an official working group meeting, but w= anted to provide transparency on related discussions to this list.

    -- Dick
    --94eb2c1268147da560055eff4bf5-- From nobody Thu Nov 30 17:30:16 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D15124D68 for ; Thu, 30 Nov 2017 17:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.3 X-Spam-Level: X-Spam-Status: No, score=-17.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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 Ifcr9AbIPw9K for ; Thu, 30 Nov 2017 17:30:13 -0800 (PST) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4836126C83 for ; Thu, 30 Nov 2017 17:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1512091806; x=1543627806; h=from:to:subject:date:message-id:mime-version; bh=4zXd6ce0c25wI3vSPYr6OpWs4U/xP1CGZalo+jJGVbk=; b=f3bFzB+d2ToZkdGbflvLbKazQzmopBer5hGY7jrZNvcaiDsfve6+Q2Ui I2PJ+ladSzVuahqR3jwGBaooN43RplltjomI5ZKFKLaNcHiDpXO7yW9D/ w8/cZBeJC9A4GRo/qVHNZ2e7GptjwmfuyadHwn0R1wQnOhqPCmYAj/+8n o=; X-IronPort-AV: E=Sophos;i="5.45,343,1508803200"; d="scan'208,217";a="577073506" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-1e-a70de69e.us-east-1.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Dec 2017 01:30:05 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1e-a70de69e.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id vB11U1JO122781 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 1 Dec 2017 01:30:04 GMT Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 1 Dec 2017 01:30:03 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 1 Dec 2017 01:30:03 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Fri, 1 Dec 2017 01:30:03 +0000 From: "Richard Backman, Annabelle" To: "id-event@ietf.org" Thread-Topic: Single-event SET token draft proposal Thread-Index: AQHTakPpCMzN07kznk+B7CHcbGRmOQ== Date: Fri, 1 Dec 2017 01:30:03 +0000 Message-ID: <561EA2F9-C829-4B31-A764-501C02A762DB@amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.83] Content-Type: multipart/alternative; boundary="_000_561EA2F9C8294B31A764501C02A762DBamazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: [Id-event] Single-event SET token draft proposal X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 01:30:15 -0000 --_000_561EA2F9C8294B31A764501C02A762DBamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gc2VjZXZlbnQgbGlzdCwNCg0KSSBoYXZlIHN1Ym1pdHRlZCBkcmFmdC1iYWNrbWFuLXNl Y2V2ZW50LXRva2VuPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJhY2tt YW4tc2VjZXZlbnQtdG9rZW4vPiBhbiBhbHRlcm5hdGUgcHJvcG9zYWwgZm9yIHRoZSBTZWN1cml0 eSBFdmVudCBUb2tlbiBmb3JtYXQsIGFzIGFuIGF0dGVtcHQgdG8gYWRkcmVzcyB0aGUgb3BlbiBp c3N1ZXMgYXJvdW5kIGV2ZW50IHN1YmplY3QgaWRlbnRpZmljYXRpb24gYW5kIHNpbmdsZS1ldmVu dCB2ZXJzdXMgbXVsdGlwbGUtZXZlbnQgU0VUcy4gSGVyZSBpcyBhIHF1aWNrIHN1bW1hcnkgb2Yg dGhlIG1ham9yIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhpcyBkcmFmdCBhbmQgZHJhZnQtaWV0Zi1z ZWNldmVudC10b2tlbi0wMzoNCg0KDQogIDEuICBSZXBsYWNlcyB0aGUg4oCcZXZlbnRz4oCdIGNs YWltIHdpdGggYW4g4oCcZXZlbnTigJ0gY2xhaW0gd2hvc2UgdmFsdWUgaXMgYSBzaW5nbGUgSlNP TiDigJxldmVudCBwYXlsb2Fk4oCdIG9iamVjdCBjb250YWluaW5nIGEgaGFuZGZ1bCBvZiBtZXRh ZGF0YSBjbGFpbXMgYWxvbmcgd2l0aCB3aGF0ZXZlciBldmVudCBjbGFpbXMgdGhlIHByb2ZpbGlu ZyBzcGVjaWZpY2F0aW9uIGRlZmluZXMuDQogIDIuICBEZWZpbmVzIGFuIOKAnGV2ZW50LmV2ZW50 X3N1YmplY3TigJ0gY2xhaW0gd2hvc2UgdmFsdWUgaXMgYSBKU09OIG9iamVjdCByZXByZXNlbnRp bmcgYSBTdWJqZWN0IElkZW50aWZpZXIuDQogICAgICogICBSZWNvbW1lbmRzIHRoZSB1c2Ugb2Yg 4oCcZXZlbnQuZXZlbnRfc3ViamVjdOKAnSB1bmxlc3MgdGhlIHN1YmplY3QgaXMgaW1wbGljaXRs eSBrbm93biBvciBzcGVjaWZpZWQgdGhyb3VnaCB0aGUgSldUIOKAnHN1YuKAnSBjbGFpbS4NCiAg My4gIEludHJvZHVjZXMg4oCcU3ViamVjdCBJZGVudGlmaWVy4oCdOiBhIHNldCBvZiBjbGFpbXMg dGhhdCB3aGVuIHRha2VuIHRvZ2V0aGVyIGlkZW50aWZ5IHRoZSBzdWJqZWN0IG9mIGFuIGV2ZW50 Lg0KICAgICAqICAgRGVmaW5lcyB0aGUg4oCcZW1haWzigJ0sIOKAnHBob25lX251bWJlcuKAnSwg YW5kIOKAnGlzc19zdWLigJ0gU3ViamVjdCBJZGVudGlmaWVyIFR5cGVzLg0KICA0LiAgRGVmaW5l cyB0aGUg4oCcUmVsYXRlZCBFdmVudHPigJ0gZXZlbnQgdHlwZSwgd2hpY2ggaGFzIGFuIOKAnGV2 ZW50c+KAnSBjbGFpbSB0aGF0IGNvbnRhaW5zIGEgbGlzdCBvZiBldmVudHMgdGhhdCDigJxyZXBy ZXNlbnQgb3IgZXhwcmVzcyBkaWZmZXJlbnQgYXNwZWN0cyBvZiB0aGUgc2FtZSBldmVudCBvciBz dGF0ZSBjaGFuZ2Uu4oCdDQogIDUuICBSZWNvbW1lbmRzIHRoZSB1c2Ugb2YgQ29sbGlzaW9uIFJl c2lzdGFudCBOYW1lcyB3aGVuIGV4dGVuZGluZyBleGlzdGluZyBldmVudHMgd2l0aCBhZGRpdGlv bmFsIGNsYWltcy4NCg0KSSBlbmNvdXJhZ2UgZXZlcnlvbmUgdG8gcmVhZCB0aHJvdWdoIHRoaXMg ZHJhZnQgYW5kIHNob290IHdoYXRldmVyIGhvbGVzIHlvdSBjYW4gaW4gaXQuIOKYug0KDQpNeSBw cm9wb3NhbDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmFja21hbi1z ZWNldmVudC10b2tlbi8NCkN1cnJlbnRseSBhZG9wdGVkIGRyYWZ0OiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNlY2V2ZW50LXRva2VuLw0KDQoNCi0tDQpBbm5h YmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBbWF6b24g4oCTIElkZW50aXR5IFNlcnZpY2VzDQoNCg== --_000_561EA2F9C8294B31A764501C02A762DBamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <463CFBF255BB9244B05C28747B6B091F@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQXBwbGUgQ29sb3IgRW1vamkiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2 M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0Rjcy Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90 dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu Lm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToi IjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjE5MDY5MTA2NzU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjE4OTgxOTAwMzIgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2 OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5IZWxsbyBzZWNldmVudCBsaXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+SSBoYXZlIHN1Ym1pdHRlZCA8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1iYWNrbWFuLXNlY2V2ZW50LXRva2VuLyI+DQpkcmFmdC1i YWNrbWFuLXNlY2V2ZW50LXRva2VuPC9hPiBhbiBhbHRlcm5hdGUgcHJvcG9zYWwgZm9yIHRoZSBT ZWN1cml0eSBFdmVudCBUb2tlbiBmb3JtYXQsIGFzIGFuIGF0dGVtcHQgdG8gYWRkcmVzcyB0aGUg b3BlbiBpc3N1ZXMgYXJvdW5kIGV2ZW50IHN1YmplY3QgaWRlbnRpZmljYXRpb24gYW5kIHNpbmds ZS1ldmVudCB2ZXJzdXMgbXVsdGlwbGUtZXZlbnQgU0VUcy4gSGVyZSBpcyBhIHF1aWNrIHN1bW1h cnkgb2YgdGhlIG1ham9yIGRpZmZlcmVuY2VzDQogYmV0d2VlbiB0aGlzIGRyYWZ0IGFuZCBkcmFm dC1pZXRmLXNlY2V2ZW50LXRva2VuLTAzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlw ZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5SZXBsYWNlcyB0aGUg4oCcZXZlbnRz4oCdIGNsYWltIHdpdGggYW4g4oCcZXZlbnTigJ0gY2xh aW0gd2hvc2UgdmFsdWUgaXMgYSBzaW5nbGUgSlNPTiDigJxldmVudCBwYXlsb2Fk4oCdIG9iamVj dCBjb250YWluaW5nIGEgaGFuZGZ1bCBvZiBtZXRhZGF0YSBjbGFpbXMgYWxvbmcgd2l0aA0KIHdo YXRldmVyIGV2ZW50IGNsYWltcyB0aGUgcHJvZmlsaW5nIHNwZWNpZmljYXRpb24gZGVmaW5lcy48 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkRlZmluZXMgYW4g4oCcZXZlbnQuZXZlbnRfc3ViamVjdOKAnSBjbGFp bSB3aG9zZSB2YWx1ZSBpcyBhIEpTT04gb2JqZWN0IHJlcHJlc2VudGluZyBhIFN1YmplY3QgSWRl bnRpZmllci48bzpwPjwvbzpwPjwvc3Bhbj4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0 YXJ0PSIxIiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPlJlY29tbWVuZHMgdGhlIHVzZSBvZiDigJxldmVudC5ldmVudF9zdWJqZWN0 4oCdIHVubGVzcyB0aGUgc3ViamVjdCBpcyBpbXBsaWNpdGx5IGtub3duIG9yIHNwZWNpZmllZCB0 aHJvdWdoIHRoZSBKV1Qg4oCcc3Vi4oCdIGNsYWltLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9v bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+SW50cm9kdWNlcyDigJxTdWJqZWN0IElkZW50aWZpZXLigJ06IGEgc2V0IG9mIGNsYWltcyB0 aGF0IHdoZW4gdGFrZW4gdG9nZXRoZXIgaWRlbnRpZnkgdGhlIHN1YmplY3Qgb2YgYW4gZXZlbnQu PG86cD48L286cD48L3NwYW4+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIg dHlwZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5EZWZpbmVzIHRoZSDigJxlbWFpbOKAnSwg4oCccGhvbmVfbnVtYmVy4oCdLCBhbmQg4oCc aXNzX3N1YuKAnSBTdWJqZWN0IElkZW50aWZpZXIgVHlwZXMuPG86cD48L286cD48L3NwYW4+PC9s aT48L29sPg0KPC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5EZWZpbmVzIHRoZSDigJxSZWxhdGVkIEV2ZW50c+KAnSBldmVudCB0eXBlLCB3aGlj aCBoYXMgYW4g4oCcZXZlbnRz4oCdIGNsYWltIHRoYXQgY29udGFpbnMgYSBsaXN0IG9mIGV2ZW50 cyB0aGF0IOKAnHJlcHJlc2VudCBvciBleHByZXNzIGRpZmZlcmVudCBhc3BlY3RzIG9mIHRoZQ0K IHNhbWUgZXZlbnQgb3Igc3RhdGUgY2hhbmdlLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxp IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVjb21tZW5k cyB0aGUgdXNlIG9mIENvbGxpc2lvbiBSZXNpc3RhbnQgTmFtZXMgd2hlbiBleHRlbmRpbmcgZXhp c3RpbmcgZXZlbnRzIHdpdGggYWRkaXRpb25hbCBjbGFpbXMuPG86cD48L286cD48L3NwYW4+PC9s aT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGVuY291cmFnZSBldmVyeW9uZSB0byByZWFk IHRocm91Z2ggdGhpcyBkcmFmdCBhbmQgc2hvb3Qgd2hhdGV2ZXIgaG9sZXMgeW91IGNhbiBpbiBp dC4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtBcHBsZSBDb2xvciBFbW9qaSZxdW90OyI+4pi6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk15 IHByb3Bvc2FsOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWJhY2ttYW4tc2VjZXZlbnQtdG9rZW4vIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1iYWNrbWFuLXNlY2V2ZW50LXRva2VuLzwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Q3VycmVudGx5IGFkb3B0ZWQgZHJhZnQ6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zZWNldmVudC10b2tlbi8iPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2VjZXZlbnQtdG9rZW4vPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNr bWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW1hem9u IOKAkyBJZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_561EA2F9C8294B31A764501C02A762DBamazoncom_-- From nobody Thu Nov 30 18:32:19 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F4212704B for ; Thu, 30 Nov 2017 18:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mX6IL-tzN15 for ; Thu, 30 Nov 2017 18:32:17 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 6F334126B72 for ; Thu, 30 Nov 2017 18:32:17 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vB12WFUr018876 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Dec 2017 02:32:16 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vB12WFUr004804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Dec 2017 02:32:15 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vB12WEBo016651; Fri, 1 Dec 2017 02:32:15 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 Nov 2017 18:32:14 -0800 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii From: Phil Hunt Mime-Version: 1.0 (1.0) Message-Id: <66C9C2E3-C732-4A6A-A433-85696529D425@oracle.com> Date: Thu, 30 Nov 2017 18:32:07 -0800 To: ID Events Mailing List X-Mailer: iPhone Mail (14G60) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: [Id-event] Secevents IETF 100 discussion (minutes) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 02:32:18 -0000 Over the week at IETF100 there was initially the official wg meeting plus a n= umber of daily side meetings. =20 I have not seen the minutes yet, so here are some of my thoughts on the new d= raft from Annabelle.=20 The change in direction is substantial (a totally new format and design prin= ciple) and I recommend strongly that people read the new draft from Annabell= e.=20 I am aware of some people that could not attend that would like to catch up w= ith minutes before commenting. A key design difference is the new individual draft acts more as a command m= essage. A SET event is singular and expresses specific intent by the issuer t= hat may be more easily understood. In contrast, the WG draft describes a set= of event statements (eg one or more state changes) by the issuer where the r= eceiver decides meaning and action if any within its own context.=20 I will provide further commentary later. For now I am very concerned with th= e change in design that suggests SETs be more like structured commands by tr= ansmitters to receiving parties.=20 Best regards, Phil= From nobody Thu Nov 30 20:41:37 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272AC1241F5 for ; Thu, 30 Nov 2017 20:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fq4_hM6mtVSH for ; Thu, 30 Nov 2017 20:41:34 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::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 6C0C2120454 for ; Thu, 30 Nov 2017 20:41:34 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id y6so3992447pgp.4 for ; Thu, 30 Nov 2017 20:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jD2qXqnjkNB/CdYCmOSjoTT1xgtXc7VRvovGFIXQo0Q=; b=cVXxgf6m0bgkZQwdVxZfvNcW9kViJ4tG+M9ci/BDiJEG35nxnZo99Sm6oYMEAdS61e xVTJxNr1hO81o954Xo4dtLH1c+iuUIVwVO782cNAbEdA9mpd+qXPHg8b9kxvbrg63jTM xjyE+ZJRF5egNNX8eZQtNOxJON02zUMZ8i9oxJTsL77Whk4IaN6sOsFFKFUtp+hq66E1 sLuCTCP4oqnKoqdBFqpOkZ8Why/wtY/r9Ev29OGGZed+P/ToLPyLj1bhT1q4BeABBA4z UK0qZ4Pc0qWR45cl2e36zsDMEofiT/BdZ3VESmIAxNBysxNmLQfe0i0cdYu0Ng4NHicu RQLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jD2qXqnjkNB/CdYCmOSjoTT1xgtXc7VRvovGFIXQo0Q=; b=bNiPBokEWppjer04KohdqNbylZSDqmlz4GoqLlExtnlh1y9UAFTK8WQQGQIyQ8dX0l atU1BRPd4lklZs+5sT0JaFNiPlsX0mRwKOYCOLRJ+V6/SYUlLxcMoHShlZevqvD7ZYtk p5fbIBiZfpQpBP1A+Y43W4AhfTJcRg8GmyDXer9Oaxm5AUpJHodqBRquMPXseVGRm23v n6YzWA42uWDTd6FcDr/oJHnEf3jEbPXDruMR76nagvEgjDEYiVToqMIPmFyV8l6u6KL1 tITn7hMssIMpcPOJ/0zva4J+svfVx9EaPYlFhC9sdZDCSF/EUYYwre0du3/VFWJmFgbl plVw== X-Gm-Message-State: AJaThX40KsI+k0h+quuMyGv7lhOO8s4MlPan0FWzwn1d5lp3nnG/YpUE USufOuI10yZwEgvRnWzYATfOHo1PieCTChxnYCs= X-Google-Smtp-Source: AGs4zMaNK6JoMiDR4upOw2ZzsuEihS3HFdOoXcANQEPuOhDiRdGN2/gKAkpbcm5pj5GkA8eEtTBJbQE7LcFWGVJPJ/s= X-Received: by 10.101.71.134 with SMTP id e6mr4714178pgs.141.1512103293429; Thu, 30 Nov 2017 20:41:33 -0800 (PST) MIME-Version: 1.0 References: <66C9C2E3-C732-4A6A-A433-85696529D425@oracle.com> In-Reply-To: <66C9C2E3-C732-4A6A-A433-85696529D425@oracle.com> From: Dick Hardt Date: Fri, 01 Dec 2017 04:41:20 +0000 Message-ID: To: ID Events Mailing List , Phil Hunt Content-Type: multipart/alternative; boundary="089e0826a40cab320b055f3ffb41" Archived-At: Subject: Re: [Id-event] Secevents IETF 100 discussion (minutes) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 04:41:36 -0000 --089e0826a40cab320b055f3ffb41 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I will be posting a summary of the side meetings real-soon-now. Per an earlier post, I=E2=80=99ll be posting some questions looking to get consensus on a number of topics. On Thu, Nov 30, 2017 at 6:32 PM Phil Hunt wrote: > Over the week at IETF100 there was initially the official wg meeting plus > a number of daily side meetings. > > I have not seen the minutes yet, so here are some of my thoughts on the > new draft from Annabelle. > > The change in direction is substantial (a totally new format and design > principle) and I recommend strongly that people read the new draft from > Annabelle. > > I am aware of some people that could not attend that would like to catch > up with minutes before commenting. > > A key design difference is the new individual draft acts more as a comman= d > message. A SET event is singular and expresses specific intent by the > issuer that may be more easily understood. In contrast, the WG draft > describes a set of event statements (eg one or more state changes) by the > issuer where the receiver decides meaning and action if any within its ow= n > context. > > I will provide further commentary later. For now I am very concerned with > the change in design that suggests SETs be more like structured commands = by > transmitters to receiving parties. > > Best regards, > > Phil > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --089e0826a40cab320b055f3ffb41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I will be posting a summary of the side meetings rea= l-soon-now.

    Per an earli= er post, I=E2=80=99ll be posting some questions looking to get consensus on= a number of topics.

    On Thu, Nov 3= 0, 2017 at 6:32 PM Phil Hunt <ph= il.hunt@oracle.com> wrote:
    O= ver the week at IETF100 there was initially the official wg meeting plus a = number of daily side meetings.

    I have not seen the minutes yet, so here are some of my thoughts on the new= draft from Annabelle.

    The change in direction is substantial (a totally new format and design pri= nciple) and I recommend strongly that people read the new draft from Annabe= lle.

    I am aware of some people that could not attend that would like to catch up= with minutes before commenting.

    A key design difference is the new individual draft acts more as a command = message. A SET event is singular and expresses specific intent by the issue= r that may be more easily understood. In contrast, the WG draft describes a= set of event statements (eg one or more state changes) by the issuer where= the receiver decides meaning and action if any within its own context.

    I will provide further commentary later. For now I am very concerned with t= he change in design that suggests SETs be more like structured commands by = transmitters to receiving parties.

    Best regards,

    Phil
    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event
    --
    Subscribe to the HARDTWARE mail list to learn about projects I= am working on!
    --089e0826a40cab320b055f3ffb41--

    On T= ue, Nov 14, 2017 at 4:11 PM, Justin Richer <jricher@mit.edu> w= rote:

    Sure, here's a somewhat concrete strawman. Let's say you've got an event issued by the RP i= n an identity system, sending information to another party (either the IdP or someone else). The "subject" from the OIDC perspective is what yo= u'd find in an ID Token, say "abcd-1234". This only makes sense in the con= tex of the IdP's issuer, "https://id.exam= ple.com/", so it doesn't make sense to send the subject on its own without the issuer. However, the issuer of the SET itself is going to be the RP, "rp-client-id-1234" in the OIDC world or even "https://rp.exam= ple.net/" in a wider ecosystem.

    So in this example, we want to talk about a user "abcd-1234" from "https://id.exam= ple.com/", but it's "rp-client-id-1234" that's talking about that user. Which giv= es us:

    {
    =C2=A0 "iss": "rp-client-1234",
    =C2=A0 "event": {
    =C2=A0=C2=A0=C2=A0 "iss": "https://id.exam= ple.com/",
    =C2=A0=C2=A0=C2=A0 "sub": "abcd-1234"
    =C2=A0 }
    }

    So why would you use "sub&qu= ot; at the root? Only if the issuer of the SET has their own, independent way to look at the user. In our case, let's say the RP has a local username identifier of "user-9876", you could have:

    {
    =C2=A0 "iss": "rp-client-1234",
    =C2=A0 "sub": "user-9876",
    =C2=A0 "event": {
    =C2=A0=C2=A0=C2=A0 "iss": "https://id.example.com/",
    =C2=A0=C2=A0=C2=A0 "sub": "abcd-1234"
    =C2=A0 }
    }

    I think that the use of "sub= " at the root should be less common than the use of "event.sub", in= th use cases that people have brought up here. I'm against using "sub&quo= t; as a shortcut for "event.sub", as has been suggested.

    -- Justin

    On November 14, 2017 1:47:05 PM Dick Hardt <dick.hardt@gmail.com> wrote:

    Hey Justin, I'm having a hard time understanding the d= ifference between "sub" and "event.sub". Do you have an example that highlight the semantic difference?
    On Tue, Nov 14, 2017 at 1:38 PM, Justin Richer <jricher@mit.edu> wrote:

    Yes, they're intended to be potentially different values but could be the same in some circumstances. Syntactically, one is "sub" and the other is "event.sub".=C2=A0 I'd be perfectly happy renaming the "event.sub" claim to "event.event_sub" or something, and I think the "risc_subject" with an object type is = also perfectly reasonable as it's providing data beyond what the regular "event.sub" would do (as a string). Semantically, "sub" is from the perspective of the issuer of the SET and "event.sub" is the perspective of the receiver of the SET.

    -- Justin

    On November 14, 2017 11:49:27 AM Dick Hardt <dick.hardt@gmail.com> wrote:

    Justin: you have "sub" above the event, and with= in the event. I think there are different values, but it is not clear.


    On Tue, Nov 14, 2017 at 11:42 AM, Justin Richer <jricher@mit.edu> wrote:

    Extensions to event types just extend the event object itself. So each event type controls the namespace within its event object and can allow additional bits in it. So let's s= ay you've got:

    event: {
    =C2=A0 event_type: "foo:bar",
    =C2=A0 foo: thing,
    =C2=A0 bar: other-thing
    =C2=A0 ...
    }

    And you want to extend "foo:bar" with the "foo:bar:baz" extension you could easily do something like:

    event: {
    =C2=A0 event_type: "foo:bar",
    =C2=A0 foo: thing,
    =C2=A0=C2=A0 bar: other-thing,
    =C2=A0=C2=A0 baz: extension-thing
    }

    Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You could alternatively have an "extensions" object, but that seems like overkill. JSON in practice is schema-by-fiat: you look for things you know and care about and ignore everything else. So extensions can just stack inside the event object, and multiple extensions to the same event type will already need to know to stay out of each others' way.

    -- Justin

    On November 14, 2017 10:35:51 AM Phil Hunt <phil.hunt@oracle.com> wrote:

    How do you propose to handle extensions of event uris?

    <= div>
    Phil

    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    phil.hu= nt@oracle.com

    On Nov 14, 2017, at 2:21 AM, Justin Richer <jricher@mit.edu> wrote:

    I wanted to take a few moments to get down on virtual-paper some thoughts about the syntax and semantics of a SET from today's meeting. Originally, the eve= nt snytax that we brought to the table from the Consent Receipts working group in Kantara was very explicitly a single event being described. When RISC, OIDC sessions, and eventually SCIM came to the conersation, the group decided to try out a way to express multiple aspects of a single event in a single token. While I still agree with this principle, I can see now that it's too much of a temptation to express either multiple events or bend around the semantics in ways that could cause a lot of confusion. I now think that we should collapse the syntax as Annabelle has suggested and go even further to specify what can go where. To wit, SET payload profiles should only ever touch the things inside the event object. So I'm propo= sing that we do something like this:


    {
    iss: <-- string representing the issuer of the SET itself
    sub: <-- string representing the subject of the SET from the =C2=A0view of the issuer (if known), no format assumed
    iat: <-- timestamp of when the SET Was created, not to be confused with the event time
    aud: <-- array or string repreesnting the recipients of this SET, from the view of the issuer of the sET
    exp: <-- timestamp of when the SET shouldn't be processed anymore event: { <-- object for the event itself, SET profiles do all of their definitions in here
    =C2=A0=C2=A0=C2=A0toe: <-- timestamp of the event, if known; if not present, event time is unknown
    =C2=A0=C2=A0=C2=A0iss: <-- issuer namespace for the subject of this event, as known by the recipient
    =C2=A0=C2=A0=C2=A0sub: <-- subject of the event, as known by the recipient, namespaced by event.iss
    =C2=A0=C2=A0=C2=A0txn: <-- transaction identifier for tying multiple events together
    =C2=A0=C2=A0=C2=A0event_type: <-- URI representing this event's type= , must be understood by recipient (who can do a string match), can define other additional fields and their semantics
    }
    }

    And to Leif&#= 39;s point, to have a group event we would do:

    event: {
    =C2=A0event_type: urn:ietf:secevent:event_group
    =C2=A0<any event attributes that are common to the whole set, like txn, toe, sub, etc>
    =C2=A0events: [ =C2=A0<-- array of event objects with the semantics of the regular event object, taken all at once; can re-use any of the root event elements defined in SET but must not repeat any in the root event'= ;s common attributes
    =C2=A0=C2=A0]
    }

    Event groups create some interop issues, as you need to have clients that can handle events in a group as well as on their own. But with the way people were describing event groups today, I think that's actua= lly a good thing -- it would force recognition of the associated nature of all the components. If you get an event group, you need to understand everything in the group. No primary/secondary, no pritical fields -- all or nothing.

    Yes this is a change from current syntax and semantics, but to me it feels like a return to the consent receipt part of the roots.

    -- Justin


    _______________________________________________
    I= d-event mailing list
    Id-e= vent@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXC= gaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyX= PpuYqPkAI1aLcLN4KZNA&m=3Dy2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxs= B-kpYFg&s=3DFZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e= =3D


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    Subscribe to the HARDTWARE mail list to learn about projects I am working on!



    --
    Subscribe t= o the HARDTWARE mai= l list to learn about projects I am working on!

    On Wed, Nov 1, 2017 at 2:37 PM, Marius Scurtescu <= span dir=3D"ltr"><mscurtescu@google.com> wrote:
    On Wed, Nov 1, 2017 at 12:45 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
    You can=E2=80=99t real= ly have multiple events (at least of the same type).=C2=A0 The current spec= can only have one instance of a URI (afaik). =C2=A0

    Not= e that the spec normatively does not support multiple event SETS.=C2=A0 It = currently states:
    events
      The semantics of this claim is to define a set of event statements
      that each MAY add additional claims to fully describe a single
      logical event that has occurred (e.g. a state change to a
      subject).  Multiple event statements of the same type SHALL NOT be
      accepted.  The "events" claim SHOULD NOT be used to express
      multiple logical events.

    The sp= ec has *always* supported requirements (as stated in the spec) for multiple= separate profile statements (from one or more profile familities) needing = to be sent as a single message.=C2=A0 It would be INSECURE to force multipl= e SETs because the current delivery mechanism only allows one SET to be del= ivered at a time. There is no way to assure that a single receiver gets all= of the SETs it needs in a multi-threaded, multi-node environment at scale.= =C2=A0 Assembling multiple SETs to track =E2=80=9Ctxn=E2=80=9D in a common = state database is NOT simple nor cost effective.

    I totally agree that it is difficult for rece= ivers to receive separate events, in no particular order and correlate base= d on "txn". But, receivers have to solve this issue regardless of= "events" or "event", so it is unrelated to this propos= al.

    =C2=A0

    If we accomm= odate this in the proposed form, we end up with a complex, deeply nested JS= ON structure with the possibility of namespace conflicts.

    IMO The proposal does not simplify, it complicating and limiting. = =C2=A0

    The current spec has very clean JSON and av= oids namespace conflicts between profiles. I think we should stay on track = with the current draft and observe the normative text if not make it strong= er in regards to multi-events (understood that Mike may disagree).

    Phil
    <= div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-i= ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap= :break-word">

    Oracle Corporation, Identity Cl= oud Services Architect
    @independentid
    phil.hunt@oracle.com

    On Nov 1, 2017, at 12:18 PM, Richar= d Backman, Annabelle <richanna@amazon.com> wr= ote:

    Unless the profile = guarantees that such related events will always be included in the same SET= , then the receiver has to correlate across SETs anyway, and multiple event= s per SET is just giving the receiver another scenario that they have to su= pport.
    =C2=A0
    I= =E2=80=99ve already provided several other reasons why we should not suppor= t multiple tokens per SET that no one has addressed. Here they are again:
    1. Multiple event support results in a more complex structure = for the single event use case, which I think we all agree is the majority u= se case.
    2. Multiple-event SETs have ambiguous semantics.= The presence of two events A and B in the same SET could mean any of:
      1. A and B are related to the same logical event (i.e. the same thing a= s if they were from different SETs that have a common txn).
      2. A is an extension of B.
      3. B is an extension of A.<= u>
      4. A is an alias for B, or vice-versa.
        5. =
      5. A and B are not actually related to one another in any way, and the tran= smitter bundled them together because they were going to the same receiver.=
    3. Top-level claim semantics become harder to = define, as different profiles may want to use the same claims in different = ways.
    4. Event authenticity cannot be verified without ha= ving the entire SET. This forces receivers to expose downstream systems to = more information necessary, if those systems need to be able to verify auth= enticity.
    =C2=A0
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">--=C2=A0
    Annabelle Richard Bac= kman
    Amazon =E2=80=93 Identity Services=
    =C2=A0
    =C2=A0
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">From:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
    Date:=C2=A0Wedne= sday, November 1, 2017 at 11:21 AM
    To:=C2=A0Dick Hard= t <dick.hardt@gmail.com>
    Cc:=C2= =A0Yaron Sheffer <yaronf.ietf@gmail.com= >, "Richard Backman, Annabelle" <ri= channa@amazon.com>, ID Events Mailing List <id-= event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
    Subject:=C2=A0RE: [Id-= event] Use cases for multiple events per SET?
    =C2=A0
    I completely agree on moving complexity to the issuer o= ver the recipient.=C2=A0 In my view, it=E2=80=99s more complex for recipien= ts to have to correlate and process a sequence of multiple SETs providing i= nformation about the same logical event, and validate N signatures, than to= receive one SET with all the aspects of the logical event as =E2=80=9Ceven= ts=E2=80=9D fields, with no correlation over time then required.<= /u>
    =C2=A0<= u>
    =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 -- Mike
    From:=C2=A0Dick Hardt= [mailto:dick.hardt@gmail.com]=C2=A0Sent:=C2=A0Wednesday, November 1, 2017 9:39 AM
    T= o:=C2=A0Mike Jones <Michael.= Jones@microsoft.com>
    Cc:=C2=A0Yaron Sheffer &l= t;yaronf.ietf@gmail.com>; Richard Backman, Ann= abelle <richanna@amazon.com>; ID Events Maili= ng List <id-event@ietf.org>; Phil Hunt (IDM) &l= t;phil.hunt@oracle.com>
    Subject:= =C2=A0Re: [Id-event] Use cases for multiple events per SET?
    =C2=A0
    Your com= ments highlight a couple of points:
    =C2=A0
    1) The example is how to ha= ve a predefined extension point for extensions of a specific event, it is n= ot how to add another event. Myself, I think this is overly complicated. Ev= ents should be comparatively static, and as with many other JSON formats, t= he receiver should ignore properties it does not understand, which let'= s new properties be introduced as extensions. There should not be any confl= ict as extensions should only be done by the profile that created the event= format to start off with.
    =C2=A0
    2) Having an lvalue be a URI is much= harder to code against. I'm not sure why Marius had that in his exampl= e. Per the event, the type of the event is well defined with=C2=A0
    =C2=A0
    =C2=A0
    3) This thread is about reasons for multiple = events to be contained in one set. Your mention of an issuer not wanting to= sign separate events as a reason to allow multiple events. I think we have= decided that given a preference, we will push effort to the transmitter ov= er the receiver as in many use cases there are many more receivers. Given t= hat, it is more complex for a receiver to have different ways of managing t= he receipt of multiple events as not all issuers will bundle the events, so= it is simpler to have only one event per SET. Including the separate event= s with a URI as an lvalue is challenging to implement, speaking from experi= ence.
    =C2=A0
    =C2=A0
    =C2=A0<= /u>
    =C2=A0
    =
    =C2=A0
    =C2=A0=
    =C2=A0
    =C2=A0
    =C2=A0
    <= div>
    =C2=A0
    =C2=A0<= u>
    =C2=A0
    On Tue, Oct 31, 2017 at 11:05 PM, Mike Jones <Michael.Jones@micro= soft.com> wrote:
    <= div>
    Marius=E2=80=99 proposed s= yntax, pasted in below, has exactly this characteristic.=C2=A0 The way I se= e it, his proposal essentially has a primary passwordReset event and a seco= ndary passwordResetExt data structure, which could have been simply another= event value in the current draft.
    =C2=A0
    = This breaking change makes the data stru= ctures more complicated - not less.=C2=A0 And it makes things that used to = be possible impossible, reducing flexibility to those who would use the spe= c.
    = =C2=A0
    These seem like bad tradeoffs to me.
    =C2=A0
    {
    =C2=A0 "jti": "3d0c3cf79= 7584bd193bd0fb1bd4e7d30",
    =C2=A0= "iat": 1458496025,
    =C2=A0 "= ;iss": "https://scim.example.com",
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0 "aud": [
    =C2=A0 =C2= =A0],
    =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"resetAttempts":5,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<= u>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}=
    =C2=A0 =C2=A0 =C2=A0 =C2=A0}
    = }
    = =C2=A0
    In particular, it makes it impossible to sign multiple related events sh= aring a common claims schema with a single signature by the issuer.=C2=A0 I= t forces the issuer to do the extra work of signing each of the related eve= nts (or facets of the same logical event) individually and forces the recip= ients to do the extra work of checking all those unnecessary signatures.
    =C2=A0=
    Not= every profile will ever have multiple keys in the =E2=80=9Cevents=E2=80=9D= set but there=E2=80=99s absolutely no reason to preclude it.=
    =C2=A0<= /u>
    =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 -- Mike
    From:=C2= =A0Id-event [mailto:id-event-bounces@ietf.org]=C2=A0= On Behalf Of=C2=A0Dick Hardt
    Sent:= =C2=A0Tuesday, October 31, 2017 9:52 PM
    To:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
    Cc:= =C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, = Annabelle <richanna@amazon.com>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt (IDM) <phil.hunt@oracle.com>

    Subject:=C2=A0Re: [Id-event] Use c= ases for multiple events per SET?
    =
    =C2=A0
    Please direct me to a pr= oposal that has a "primary" and "secondary" events. I a= gree that is undesirable. I would also encourage to engage in the discussio= ns so that we can drive clarity and simplicity.
    =C2=A0
    I think the proposal = is that there is one event per SET.
    =C2=A0
    I think having more than on= e event per SET adds complexity as a receiver must deal with receiving corr= elated events in one SET as well as correlated events in the same SET.
    =C2=A0
    /Dick
    =C2=A0
    On Tue, Oct 31, 2017 at 9:42 PM, Mike Jones <<= a href=3D"mailto:Michael.Jones@microsoft.com" style=3D"color:purple;text-de= coration:underline" class=3D"m_4134400763206086768cremed" target=3D"_blank"= >Michael.Jones@microsoft.com> wrote:
    I hear= you on the fact that different people have joined the effort at different = times.=C2=A0 That=E2=80=99s a normal process as an effort builds momentum.= =C2=A0 I get that not everyone was there when previous consensus calls were= taken.
    =C2=A0
    I should note that I have specific technical objections to the speci= fic proposed changes being discussed as well.=C2=A0 Currently all events in= the set have the same syntax.=C2=A0 The proposals, as I understand them, r= evert us to a state where there=E2=80=99s a =E2=80=9Cprimary=E2=80=9D and = =E2=80=9Csecondary=E2=80=9D events, with different syntax for the two class= es.=C2=A0 That=E2=80=99s needlessly more complicated, adding no actual valu= e.
    = =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 -- Mike
    =C2=A0
    From:= =C2=A0Dick Hardt [mailto:dick.hardt@gmail.com]=C2=A0
    Sent:=C2=A0Tuesday, October 31, 2017 9:37 PM
    = To:=C2=A0Mike Jones <Michael.Jones@microsoft.com>
    Cc:=C2=A0Phil Hunt (IDM) <    phil.hunt@oracle.com>; Yaron Sheffer <yaronf.ietf@gmail.com>; Richard Backman, Annabe= lle <richanna@amazon.com>; ID Events Mailing List <id-event@ietf.org>= ;

    Subject:=C2=A0Re: [Id-event] Use cases for multiple events per SET?
    =C2=A0
    = Mike
    =C2=A0
    As you well know, many people in a WG don't look closely at = a specification until last call is made. Additionally, we are coming up on = only the 3rd WG meeting. The WG has not existed for very long. While some o= f the participants have been working on this for a while, many have not, an= d we are looking for consensus across the WG.
    =C2=A0
    Since SecEvent is= a framework that we expect to be profiled, I feel it is important to ensur= e that SecEvent specifications are easy for a variety of profiles to adopt,= and that the semantics make sense. I also think that properties that are s= pecific to a profile should be left to that profile and not be included in = SecEvent.
    =C2=A0
    Since this is a framework, it is expected that as dif= ferent groups profile it, there will be additional feedback.<= /div>
    =C2=A0
    = Specifically, as a participant in the RISC profile of SET, a number of issu= es in SET have surfaced as the RISC WG has looked at how to use the SET.=
    =C2=A0
    =
    As for SET being stable for over a year, there have been a number= of changes to SET since then. I also don't think there was consensus. = Before the WG was formed, I and several others had expressed concern on the= design of SET when Phil presented it at an IIW session.
    =C2=A0
    As to = taking another year, I am hopeful we can resolve the remaining issues in SE= T and publish a new draft for last call. I do not think we will need to wai= t for another WG meeting to ask for last call.=C2=A0
    =C2=A0
    We also ha= ve a number of other documents that are not in last call, and we don't = have a WG adopted draft yet for management. So there are still a number of = documents to work through before we have all the bits for someone to work w= ith.
    =C2=A0
    I do think we have been making good progress since the las= t IETF meeting, and I am hopeful we can keep up this momentum and finalize = all the documents in a timely manner.
    =C2=A0
    /Dick
    =
    =C2=A0
    = =C2=A0
    On Tue, Oct 31, 2017 at 12:48 PM, = Mike Jones <Michael.Jones@microsoft.com> wrote:
    It=E2=80=99s hard for me to even express my level of frustration = with the recent attempts to once again redesign the SecEvent Token spec.=C2= =A0 We=E2=80=99ve been at this for multiple years because people keep tryin= g to revisit decisions that were long ago made by consensus.=C2=A0 It=E2=80= =99s been stable for over a year and the majority of WGLC respondents said = some variant of =E2=80=9CWorks for me =E2=80=93 ship it!=E2=80=9D=
    =C2=A0=
    There=E2= =80=99s not sufficient justification to try to undo consensus positions tha= t have been debated and affirmed over and over.=C2=A0 Countenancing wholesa= le changes at this late date is counterproductive in the extreme!=
    =C2=A0=
    It=E2=80= =99s far better than good enough as-is.=C2=A0 In my experience, if we start= redesigning it, it will result in another year=E2=80=99s delay.=C2=A0 It d= oes something simple and useful.=C2=A0 Please, let=E2=80=99s just ship it, = so people can rely on it.
    =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=
    =C2=A0<= /u>
    From= :=C2=A0Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=C2= =A0
    Sent:=C2=A0Monday, October 30, 2017 2:42 P= M
    To:=C2=A0Dick Hardt <dick.hardt@gmail.com>
    = Cc:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>; Ri= chard Backman, Annabelle <richanna@amazon.com>; Mike Jones <Mich= ael.Jones@microsoft.com>; ID Events Mailing List <id-event@ietf.org&g= t;

    Subject:=C2=A0Re: [Id-event] Use cases for multiple events per SET?
    =C2=A0
    Inline...

    Phil


    On Oct 30, 2017, at 2:22 PM, Dick Hardt <dick.hardt@gmail.co= m> wrote:

    Hi Phil=
    =C2=A0
    Correct= me if I am misunderstanding, but there is a RISC profile event=C2=A0
    =C2=A0<=
/u>
    "http://schemas.openid.net/secevent/risc/eve=
nt-type/account-credential-change-required=E2=80=9D
    =C2=A0
    and an SCIM profile event
    = =C2=A0
    https://example.com/scim/event/passwordResetE=
xt=E2=80=9D
    =
=C2=A0
    I'm suggesting that two = different events would be sent. Embedding one in the other does not make se= nse.
    <ph>= It is a hypothetical example. Just because you disagree on this does not me= an others are not valid.=C2=A0
    =C2=A0<= /u>
    I just picked overlapping proposals th= at have different meaning (but not the same) to illustrate the difference f= rom issuing a single set with different events.=C2=A0
    =C2=A0

    As I have stated this is very different from asserting multiple distin= ct events in one SET.=C2=A0

    =C2=A0
    Also, I think it is simpler to have eve= nt_type be at the same level as event
    =
    =C2=A0

    <ph>may be. I was working from Annabelle's proposed form= at.=C2=A0

    =C2=A0
    {
    =C2=A0 "jti": "3d0c3cf7975= 84bd193bd0fb1bd4e7d30",
    =C2=A0 "= iat": 1458496025,
    =C2=A0 "iss": = "h= ttps://scim.example.com",
    =C2=A0 "= ;aud": [
    =C2=A0 =C2=A0],
    <= /div>
    <= /div>
    =C2=A0 =C2=A0"event": {=C2=A0=C2=A0
    = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"id":"44f6142df96bd6ab61e7= 521d9",
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"resetAttempts":5
    =C2=A0 =C2=A0= =C2=A0 =C2=A0}
    =C2=A0
    On Mon, Oct 30, 2017 at 12:09 PM, Phil Hunt &= lt;ph= il.hunt@oracle.com> wrote:
    Annabelle/Dick,
    =C2=A0
    Thanks for the comments= . I think we need to examine the consequences of the proposal in JSON.
    =C2=A0
    As I stated, what causes most of the issue is the proposed extension mec= hanism in the payload (possibly using events in a recursive way). Does it f= ollow the old format or the new?
    =C2=A0
    Let=E2=80=99s =C2=A0consider a use c= ase where we have an identity management system that uses SCIM, but the SCI= M system is also the underlying data store for Connect.=C2=A0 A Password re= set might generate the following event which has an extension (conveying re= set count) AND overlapping statement from RISC.=C2=A0 BOTH of which might b= e important to a similar receiver using SCIM and OIDC. =C2=A0=
    =C2=A0
    = The 03 spec currently would allow:
    =C2=A0
    {<=
/u>
    =C2=A0 "jti": "3d0c3cf797584bd19=
3bd0fb1bd4e7d30",
    =C2=A0 &q=
uot;iat": 1458496025,
    =C2=A0 &qu=
ot;iss": "https://scim.example.com",
    =C2=A0 "aud": [
    =C2=A0=C2=A0=C2=A0 "https://jhub.example.com=
/Feeds/98d52461fa5bbc879593b7754",
    =C2=A0=C2=A0=C2=A0 "https://jhub.e=
xample.com/Feeds/5d7604516b1d08641d7676ee7"
    =C2=A0=C2=A0 ],
    =
=C2=A0=C2=A0 "events": {
    =
=C2=A0=C2=A0=C2=A0=C2=A0 "urn:ietf:params:scim:event:passwordRese=
t":
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 { "id":"44f6142df96bd6ab61e7521d9"},<=
/u>
    =C2=A0=C2=A0=C2=A0=C2=A0 "https://example.com/scim/event/passwordResetExt":<=
/u>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { &=
quot;resetAttempts":5},
    =C2=A0=C2=A0=C2=A0=C2=A0 "http://schemas.o=
penid.net/secevent/risc/event-type/\
    =C2=A0 =C2=A0 =C2=A0 =C2=
=A0account-credential-change-required": {
    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=
=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ciss=
=E2=80=9D:"https://idp.example.com/"
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
    =C2=A0 }
    }=

    =C2=A0
    In the above - each =
payload is a =E2=80=98peer' and issued without preference by the transm=
itter. The receiver can assign priority in its own context if that matters.=

    =C2=A0
    The new proposal:
    =C2=A0
    {
    =C2=A0 "jti": "3d0c3cf797584bd193bd0fb=
1bd4e7d30",
    =C2=A0 "ia=
t": 1458496025,
    =C2=A0 "iss=
": "https://scim.example.com",
    =C2=A0 "aud": [
    =C2=
=A0=C2=A0=C2=A0 "https://jhub.example.com/Feed=
s/98d52461fa5bbc879593b7754",
    =C2=A0=C2=A0=C2=A0 "https://jhub.exam=
ple.com/Feeds/5d7604516b1d08641d7676ee7"
    <=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courie=
r New',serif">=C2=A0=C2=A0 ],
    =C2=
=A0=C2=A0 "event": {
    =C2=A0=
=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:"urn:ietf:params:=
scim:event:passwordReset=E2=80=9D,
    =
=C2=A0=C2=A0=C2=A0=C2=A0 "id":=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=
=A0 =E2=80=9Cevents=E2=80=9D:{
    =C2=A0=
=C2=A0=C2=A0=C2=A0 ->note =E2=80=A6is this the old or new structure? <=
;-
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 "https://example.com/scim/event/passwordResetE=
xt":
    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAttempts":5},
    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 "http://schemas.openid.net/secevent/risc/eve=
nt-type/\
    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0account-credential-=
change-required": {
    =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
    =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ciss=E2=80=9D:"=
https://idp.example.com/"<=
/u>
    =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
    =
=C2=A0=C2=A0=C2=A0=C2=A0 }<=
/u>
    =C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0 
    }
    =C2=A0
    In the above, sub-events or extensions have a different format. =
The same complaint about the original stands.
    =C2=A0
    *OR* (if the receiver cares about RIS=
C more).=C2=A0 Note that this leads to a triple nested structure.
    =C2=A0
    {
    =C2=A0 "jti": &=
quot;3d0c3cf797584bd193bd0fb1bd4e7d30",
    =C2=A0 "iat": 1458496025,
    =C2=A0 "iss": "https://scim.example.com",
    =C2=A0 "aud": [
    =C2=A0=C2=A0=C2=A0 "htt=
ps://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
    =C2=A0=C2=A0=C2=A0 "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7&qu=
ot;
    =C2=A0=C2=A0 ],
    =C2=A0=C2=A0 "event": {
    <=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courie=
r New',serif">=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:"http://schemas.openid.net/sec=
event/risc/event-type/\
    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 =C2=A0account-credential-change-required=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0=E2=80=9Ciss=E2=80=9D:"ht=
tps://idp.example.com/=E2=80=9C,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=E2=80=9Cevents=E2=80=9D:{
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &quo=
t;urn:ietf:params:scim:event:passwordReset":=

    =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 {=C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "id":=
=E2=80=9D44f6142df96bd6ab61e7521d9=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=9Cevents=E2=80=9D:{
    =C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://example.com/scim/event/passwordResetExt":<=
u>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "resetAttempts":5},<=
span style=3D"font-size:13.5pt">=C2=A0 
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0}=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0}
    =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0=C2=A0 
    =C2=A0=C2=A0=C2=A0}<=
/pre>
    }
    =C2=A0
    In the above,=
 the extension is placed inside the event it extends. It follows the old fo=
rmat (or should it follow the new?)
    *OR* F=
ollowing the top layer pattern of singular event=C2=A0 Note that this leads=
 to a triple nested structure.
    =C2=A0
    {
    =C2=A0 "jti": "3d0c3cf797584bd193bd0fb1bd4e7<=
wbr>d30",
    =C2=A0 "iat"=
: 1458496025,
    =C2=A0 "iss":=
 "=
https://scim.example.com",
    =
=C2=A0 "aud": [
    =C2=A0=C2=
=A0=C2=A0 "https://jhub.example.com/Feeds=
/98d52461fa5bbc879593b7754",
    =C2=A0=C2=A0=C2=A0 "https://jhub.example.com=
/Feeds/5d7604516b1d08641d7676ee7"
    =C2=A0=C2=A0 ],
    =C2=A0=C2=
=A0 "event": {
    =C2=A0=C2=A0=
=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:=
"http://schemas.openid.net/secevent/risc/event-type/\<=
/a>
    =C2=A0 =C2=A0 =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0account-credential-change-require=
d=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 =E2=80=9Csub=E2=80=9D:=E2=80=9D7375626A656374=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Ciss=
=E2=80=9D:"https://idp.example.com/=E2=80=9C,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent=E2=80=9D:=
{
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent_type=E2=80=9D:=
"urn:ietf:params:scim:event:passwordReset=E2=80=9D,=

    =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "id":=E2=80=9D44f6142df96bd=
6ab61e7521d9=E2=80=9D,
    =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cevent=E2=80=9D:{
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 =E2=80=9Cevent_type=E2=80=9D:"https://example.=
com/scim/event/passwordResetExt=E2=80=9D,
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "=
resetAttempts":5 
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0}
    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 }=C2=A0=C2=A0=C2=A0=C2=A0 
    =
=C2=A0=C2=A0=C2=A0}
    }<=
/pre>
    =C2=A0
    This format follows the proposed=
 singular event format recursively and is 3 layers deep. Note that the pars=
er has to continue to search the document for things that aren=E2=80=99t th=
ere as it has to stop when no =E2=80=9Cevent=E2=80=9D attribute is found ra=
ther than iterate over an array.
    =C2=A0
    Phil

    Oracle = Corporation, Identity Cloud Services Architect
    @independentid
    www.independentid.com
    phil.hun= t@oracle.com
    =C2=A0
    On Oct 30, 2017, at 8:57 AM, Richard Backman, An= nabelle <richanna@amazon.com> wrote:
    =C2=A0
    Replies inline= .
    =C2= =A0
    --= =C2=A0
    Identity Services
    =C2=A0
    <= div>
    =C2=A0
    From:=C2=A0Phil Hunt <phil.= hunt@oracle.com>
    Date:=C2=A0Sund= ay, October 29, 2017 at 5:25 PM
    To:=C2=A0Dick = Hardt <dick.hardt@gmail.com>
    Cc:=C2=A0    Yaron Sheffer <yaronf.ietf@gmail.com>, Mike Jones <Michael.Jones@microsoft.com>, "Richard Backman= , Annabelle" <richanna@amazon.com= >, ID Events Mailing List <id-event@ietf.org>
    Subject:=C2=A0Re: [Id-event] Use c= ases for multiple events per SET?
    =C2=A0
    I hope this answers your ques= tion.
    =C2=A0
    My =E2=80=9Cmay=E2=80=9D was because I can=E2=80=99t see a reaso= n why not. The question should be, what is the justification to make =E2=80= =9Cevents=E2=80=9D singular?
    [richanna]The singul= ar =E2=80=9Cevent=E2=80=9D claim has clearer semantics and is easier to pro= cess. We should opt for easier solutions unless there are use cases that re= quire more complexity.[/richanna]
    =C2=A0
    There are many reasons for mu= ltiple events in a SET.=C2=A0 Some are good, some not so good. Some of the = reasons...
    =C2=A0
    1.=C2=A0 Multiple event payloads expressing statements abou= t largely the *same*thing. For example, SCIM password reset AND RISC passwo= rd reset.=C2=A0 A RISC Event and an OpenBanking Event. Is one a complement = to the other?=C2=A0 Do they overlap or are they distinct? =C2=A0<= /u>
    [richanna]Copy/pasted from my earlier email:<= u>
    Why is it necessary or appropriate to include these even= ts in the same SET? They are likely being generated by different systems at= different times on the transmitter=E2=80=99s side, consumed by different s= ystems on the receiver=E2=80=99s side, and possibly being transmitted over = different event streams. I know the latter would be the case for us, as a r= eceiver. Even if it=E2=80=99s not, is it burdensome to send these events se= parately? What value is gained in combining them?
    =C2=A0
    Additionally, since the sig= nature is over the SET and not the event objects, Receivers independently r= oute separate events from a single token without either losing the ability = to verify the authenticity of the event or sharing all information in the S= ET with every system handling any event in the token.[/richanna]<= /u>
    =C2=A0

    2.=C2=A0 Multiple events paylo= ads expressing different statements about the same transaction - RISC Passw= ord Reset and RISC Session Cancel
    = [richanna]Same as above[/richanna]

    3.=C2=A0 A new profile defines new e= vent attributes to be added on to an existing event type (a pure extension)= =C2=A0
    [richanna]I have suggested = a way to support extensions within an event body, multiple times now. If yo= u see problems with it, please point them out.[/richanna]<= /u>
    =C2=A0
    I thi= nk it is quite valid to allow 1 and 3. =C2=A02 could be limited by specific= profiles like RISC if they want.
    =
    =C2=A0
    I am not in agreement that making ev= ent singular simplifies anything. For one is makes extensions complex (anot= her nested JSON structure) and potentially conflicting.=C2=A0
    [richanna]
    Way= s that multiple-event SETs are more complicated:
    =
    1. It results in a more= complex structure for the single event use case, which I think we all agre= e is the majority use case.
    2. Multiple-event SETs have ambiguous = semantics. The presence of two events A and B in the same SET could mean an= y of:
      1. They are relate= d to the same logical event (i.e. the same thing as if they were from diffe= rent SETs that have a common txn).
      2. A is an extension of B.
      3. B is an extension of A.
      4. They are aliases for one anothe= r.
      5. They are not actually related to one another in any way.<= /u>
    1. C= laim semantics become harder to define, as different profiles may want to u= se the same claims in different ways.
    =C2=A0
    If the WG wants to block 1 and 2 a= bove, then I believe we have to establish an event registry to ensure new E= vent profiles do not overlap to eliminate the need to express multiple even= ts.
    [richanna]I=E2=80=99m not sure wha= t you mean by this. Are you referring to event names? Those are already def= ined by the spec to be URIs.[/richanna]
    Phil=
    =C2=A0<= /u>
    Orac= le Corporation, Identity Cloud Services Architect
    =
    @independentid
    <= div>
    =C2=A0
    On Oct 29, 2017, at 4:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
    =
    =C2=A0
    Phil:
    =
    =C2=A0
    In your examples for having a plurality of = events, you use the word "may", which leads me to question if a p= lurality of events is really required in SET.
    =C2=A0
    You posit that it will be difficul= t for a distributed system to correlate multiple SETs with the same "t= xn", but the distributed system will certainly need to correlate event= s on the same subject -- correlating events on the same "txn" on = the same subject seems fairly simple.
    =C2=A0
    I think that a receiver will need to corre= late multiple SEts on the same subject, so having multiple events in a SET = is redundant, and adds complexity with no clear benefit that I can see.
    =C2=A0
    An imple= mentor may choose to send multiple SETs, or send a single SET with multiple= events, so a receiver will need to support both. I prefer we pick one way = and minimize the code paths, and we will need to support correlating across= multiple SETs, so that seems the best mechanism.
    =C2=A0
    Let me know if there is someth= ing I missed in my logic.
    <= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif;background-color:white">=C2=A0
    =
    /Dick
    =
    =C2=A0
    =C2=A0
    On Sun, Oct 29, 2017 at 11:28 AM, Yaron Sheffer=C2=A0<yaronf.ietf@gmail.com>=C2=A0wrote:
    In that case, let&#= 39;s add text to that effect, e.g. we could add to the definition of the &q= uot;events" claim:

    Profiling specifications SHOULD define the a= llowed event statements, and MAY restrict their number. For example, some p= rofiles may require this claim to contain only a single event statement.
    Thanks,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Yaron
    On 24/10/17 22:10, Mike Jones wrote:
    =

    I agree with much o= f Phil=E2=80=99s rationale here.

    It=E2=80=99s fine for some profiles= to say that the =E2=80=9Cevents=E2=80=9D set must be a singleton.=C2=A0 Th= at doesn=E2=80=99t have to be true for all events.=C2=A0 I think things are= fine as-is.

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-- Mike
    *From:* Id-event [mailto:id-event-bounce= s@ietf.org] *On Behalf Of *Phil Hunt
    *Sent:* Monday, Oct= ober 23, 2017 8:47 PM
    *To:* Richard Backman, Annabelle <richanna@amazon.com>
    *Cc:* ID Events Mailing Lis= t <id-event@ietf.org    >
    *Subject:* R= e: [Id-event] Use cases for multiple events per SET?

    Annabelle,
    <= br>I have a number of concerns with this proposal.

    Profiling Indepen= dence / Keeping Event Payloads Independent

    Indicating that extension= s should be handled by profiles leads to more inter-operability issues and = more importantly intrudes on the Event payload space by suggesting a sub-sc= hema creates potential limitations and conflicts that may add to complexity= later on. The current format allows a parser to discover and unload one or= more JSON payloads which can each have independent structure.

    Gener= al extensions

    The proposal also rules out general purpose extensions= not related to any specific event. Given the emergence of items like GPRD,= I would not want to block the ability to add meta-data or other general pu= rpose items. We can also anticipate some delivery scenarios where additiona= l data might be required. Even though there is no current planned use, I se= e no good reason to rule this out.

    Multiple Events From Different Fa= milies (vs. Multiple Events from a single family like RISC)

    In our R= ISC session we discussed expressing multiple distinct RISC events in one SE= T. The discussion was that only one RISC event at a time. We did not discus= s other event profiles. I don=E2=80=99t see a reason to rule out multi-even= ts from different families at the SET level. Each profile is expressing sli= ghtly different things about the same event.

    I can forsee some cases= where it is not clear which is the primary and which is the extension.=C2= =A0 There may not be a clear winner.

    A couple of examples (these are= necessarily real=E2=80=A6just possibilities):

    * It is probably usef= ul to be able to express simlar/overlapping events from different SET profi= les in one SET.=C2=A0 For example a Backchannel Logout & a RISC session= cancel event.

    * SCIM may want to represent a single transaction as = causing multiple state changes in an event (e.g. a password change causes m= ultiple effects). Having to chase down multiple events and correlate by =E2= =80=9Ctxn=E2=80=9D would be challenging in a multi-threaded/multi-node deli= very system.=C2=A0 =C2=A0The SCIM list has not discussed this, but I would = not want to block this capability.=C2=A0 IOW - Just because RISC does not w= ant to express multiple events does not make this true for other profiles.<= br>
    * We may wish to indicate a SCIM Password Reset was performed and a = Logout/session cancellation is expressed at the same time.=C2=A0 The events= are related but express different data.

    Avoiding Confusion From Sim= ilar Events Originating from the Same Transaction

    If events are sent= separately, then more tracking of state (e.g. by txn) would be required to= ensure similar events are not mistaken or handled as repeats. While txn pr= ovides useful audit analysis capability, I=E2=80=99m not sure it can be use= d in live or near-real time systems given distributed multi-node, multi-thr= eading architectures.

    Previous Discussion

    I note that I origi= nally raised having an attribute to designate primary event attribute to al= leviate your concern, but this was not accepted. See:

    *=C2=A0https://www= .ietf.org/mail-archive/web/id-event/current/msg00406.html<= /a>

    *=C2=A0    https://www.ietf.org/mail-archive/web/id-event/current/msg00140.html

    The consensus, at least as I interpreted it= is up to the receiver to figure this out based on the definitions it has f= or each event URI and the profiles they represent. IOW - RISC is free to li= mit that only one RISC event be expressed at a time.

    Phil

    Ora= cle Corporation, Identity Cloud Services Architect

    @independentid
    www.independentid.com=C2=A0<h= ttp://www.independentid.com>

    phil.hunt@oracle.com=C2=A0<mailto:phil.hunt@oracle.com>

    =C2=A0= =C2=A0 On Oct 23, 2017, at 7:02 PM, Richard Backman, Annabelle
    =C2=A0 = =C2=A0 <richanna@amazon.com=C2=A0<mailto:richanna@amazon.com>> wrote:

    =C2=A0 =C2=A0 The current draft of the SET s= pec allows for expressing multiple
    =C2=A0 =C2=A0 events within the same = token, which introduces additional complexity
    =C2=A0 =C2=A0 and room for= ambiguous semantics. We=E2=80=99ve discussed this in the OIDF
    =C2=A0 = =C2=A0 RISC working group and the current consensus there is that RISC will=
    =C2=A0 =C2=A0 require that RISC events must be the only event in the SE= T, having
    =C2=A0 =C2=A0 identified ways to clearly and easily support th= e handful of use
    =C2=A0 =C2=A0 cases for multiple events per token that = people have raised. With
    =C2=A0 =C2=A0 that context in mind, I propose s= triking the definition of the
    =C2=A0 =C2=A0 =E2=80=9Cevents=E2=80=9D cla= im from the Security Event Token spec, and replacing it
    =C2=A0 =C2=A0 wi= th the following definition for an =E2=80=9Cevent=E2=80=9D claim (singular)= :

    =C2=A0 =C2=A0 event

    =C2=A0 =C2=A0 A JSON object containing = an "event_type" member whose value is a URI
    =C2=A0 =C2=A0 repr= esenting a type of event defined in a Profiling Specification.
    =C2=A0 = =C2=A0 The object MAY otherwise be empty, or MAY contain additional members=
    =C2=A0 =C2=A0 as described by the Profiling Specification.

    =C2= =A0 =C2=A0 Here is the example SET from section 2.3, rewritten with this ch= ange
    =C2=A0 =C2=A0 mind:

    =C2=A0 =C2=A0=C2=A0{<= br>
    =C2=A0 =C2=A0 =C2=A0=C2=A0 "jti": "4d3559ec67504aaba6= 5d40b0363faad8",

    =C2=A0 =C2=A0 =C2=A0=C2=A0 "iat"= ;: 1458496404,

    =C2=A0 =C2=A0 =C2=A0=C2=A0"iss": "https://scim.example.com=C2=A0<= https://scim.example.com/>&= quot;,

    =C2=A0 =C2=A0 =C2=A0=C2=A0 "aud": [

    =C2=A0 = =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0"https://scim.example.com/Feeds/98d52461fa5bbc879593b= 7754",

    =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0&= quot;https://scim.exam= ple.com/Feeds/5d7604516b1d08641d7676ee7"

    =C2=A0= =C2=A0 =C2=A0=C2=A0 ],

    =C2=A0 =C2=A0 =C2=A0=C2=A0 "event"= : {

    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 "event_type": &= quot;urn:ietf:params:scim:event:create",

    =C2=A0 =C2=A0 =C2= =A0=C2=A0=C2=A0=C2=A0 "ref": "https://scim.example.com/Users/44f6142df96bd6ab= 61e7521d9",

    =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 &= quot;attributes": ["id", "name", "userName&qu= ot;, "password", "emails"]

    =C2=A0 =C2=A0 =C2=A0= =C2=A0 }

    =C2=A0 =C2=A0 }

    =C2=A0 =C2=A0 Does anyone in the wor= king group have use cases for SETs that cannot
    =C2=A0 =C2=A0 be met by t= his proposed text? Within RISC, we identified three use
    =C2=A0 =C2=A0 ca= ses, with solutions outlined below:

    =C2=A0 =C2=A0 **

    =C2=A0 = =C2=A0 *Extensions*

    =C2=A0 =C2=A0 Event extension mechanisms can be = defined internal to the event
    =C2=A0 =C2=A0 object. A simple approach wo= uld be to =C2=A0define an =E2=80=9Cextensions=E2=80=9D member
    =C2=A0 =C2= =A0 that is a list of event objects (or set resembling the =E2=80=9Cevents= =E2=80=9D
    =C2=A0 =C2=A0 claim as defined in the current spec). This has = the advantage of
    =C2=A0 =C2=A0 making it clear in the data structure tha= t there is a single primary
    =C2=A0 =C2=A0 event, with zero or more exten= sions. There is no room for confusion
    =C2=A0 =C2=A0 over which event is = primary, or if there is a primary event at all.
    =C2=A0 =C2=A0 I would be= fine with adding something like this to my proposed text,
    =C2=A0 =C2=A0= if there is consensus that it is broadly useful.

    =C2=A0 =C2=A0 *Ali= ases*

    =C2=A0 =C2=A0 This use case was brought up in the context of m= igrating clients
    =C2=A0 =C2=A0 from draft event names to standardized ev= ent names. In this case,
    =C2=A0 =C2=A0 the event transmitter can transmi= t two tokens for the logical event,
    =C2=A0 =C2=A0 one using the old name= and another using the new name.

    =C2=A0 =C2=A0 *Related Events*
    <= br>=C2=A0 =C2=A0 The SET spec defines the txn claim as a means of correlati= ng
    =C2=A0 =C2=A0 independent tokens that relate to the same logical even= t.

    =C2=A0 =C2=A0 --=C2=A0
    =C2=A0 =C2=A0 Annabe= lle Richard Backman

    =C2=A0 =C2=A0 Amazon =E2=80=93 Identity Services=

    =C2=A0 =C2=A0 _______________________________________________<= br>=C2=A0 =C2=A0 Id-event mailing list
    =C2=A0 =C2=A0=C2=A0Id-event@ietf.org=C2=A0<mailto:Id-event@ietf.org>=C2=A0 =C2=A0=C2=A0https://url= defense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_= listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQ= cxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe= 4C_lLIGk&m=3Ds5byBe5KANnGVuAb1mAupEGoJn8XG5JIUUwWGFSibEc&= s=3DX8oRSq3IzlF7jiRAeZhXpR3eVI0I58ZFd4eEZfgyoIY&e=3D


    _______________________________________________
    Id-eve= nt mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event

    _______________________________________________
    Id-event mailing = list
    = Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event
    =

    =C2=A0
    --=C2=A0
    Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn = about projects I am working on!
    =C2=A0
    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org

    =C2=A0
    --
    Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I a= m working on!
    =

    <= br clear=3D"all">
    =C2=A0
    --
    Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I = am working on!