From Adam.Montville@cisecurity.org Wed Jul 3 10:02:23 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3025811E810C for ; Wed, 3 Jul 2013 10:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZZ3f6UCJ9mc for ; Wed, 3 Jul 2013 10:02:18 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.13]) by ietfa.amsl.com (Postfix) with ESMTP id 75AE411E80F2 for ; Wed, 3 Jul 2013 10:02:18 -0700 (PDT) Received: from [216.82.250.19:4119] by server-13.bemta-12.messagelabs.com id AA/F9-06194-A0954D15; Wed, 03 Jul 2013 17:02:02 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-4.tower-87.messagelabs.com!1372870909!14108995!12 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 28425 invoked from network); 3 Jul 2013 17:02:02 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-4.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 3 Jul 2013 17:02:02 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Wed, 3 Jul 2013 12:51:52 -0400 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Berlin Meeting Thread-Index: Ac54C8T0vI3rw79uRzyAYc89//zKvg== Date: Wed, 3 Jul 2013 16:51:54 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D67053C9@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D67053C9CISEXCHANGE1msisa_" MIME-Version: 1.0 Subject: [sacm] Berlin Meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 17:02:23 -0000 --_000_05BCCEB107AF88469B9F99783D47C1D67053C9CISEXCHANGE1msisa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All: While we are not yet an official WG, I'd like to try to get our ducks in a= row and progress as though we are a WG. I see some important dates have = passed, and that some are upcoming (http://www.ietf.org/meeting/cutoff-dat= es-2013.html#IETF87). Notably: * 2013-07-05 (this Friday): Final agenda published * 2013-07-15: Internet Draft submission cut-off (for all drafts, including= -00) * 2013-07-17: Draft WG agendas due by UTC 24:00 Given the milestones listed in our charter, it seems that our agenda shoul= d contain a healthy dose of use case an discussion and possibly some requi= rements discussion. Proposed (loose) Agenda: * Note well + agenda bashing * Charter and Milestone Review * Use Case Discussion * Review of list * Presentation on latest draft (if update submitted) * Requirements discussion (time permitting) * Administravia (new-WG-related stuff) Are there relevant drafts that we want to discuss in Berlin and can be sub= mitted before the 15 July deadline? At present, the following "related do= cuments" show up on our Documents page (http://datatracker.ietf.org/wg/sac= m/): * draft-booth-sacm-vuln-model-02 * draft-waltermire-sacm-architecture-00 * draft-waltermire-sacm-use-cases-04 I'm looking forward to seeing you in Berlin! Regards, Adam This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. --_000_05BCCEB107AF88469B9F99783D47C1D67053C9CISEXCHANGE1msisa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All:

While we are not yet an official WG, I'd like to try to get our ducks= in a row and progress as though we are a WG.  I see some important d= ates have passed, and that some are upcoming (http://www.iet= f.org/meeting/cutoff-dates-2013.html#IETF87).

Notably:

* 2013-07-05 (this Friday): Final agenda published
* 2013-07-15: Internet Draft submission cut-off (for all drafts, incl= uding -00)
* 2013-07-17: Draft WG agendas due by UTC 24:00

Given the milestones listed in our charter, it seems that our agenda = should contain a healthy dose of use case an discussion and possibly some = requirements discussion.

Proposed (loose) Agenda:

* Note well + agenda bashing
* Charter and Milestone Review
* Use Case Discussion
    * Review of list
    * Presentation on latest draft (if update submitted)
* Requirements discussion (time permitting)
* Administravia (new-WG-related stuff)

Are there relevant drafts that we want to discuss in Berlin and can b= e submitted before the 15 July deadline?  At present, the following &= quot;related documents" show up on our Documents page (http://datatra= cker.ietf.org/wg/sacm/):

* draft-booth-sacm-vuln-model-02
* draft-waltermire-sacm-architecture-00
* draft-waltermire-sacm-use-cases-04

I'm looking forward to=20seeing you in Berlin!

Regards,

Adam


This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments.
--_000_05BCCEB107AF88469B9F99783D47C1D67053C9CISEXCHANGE1msisa_-- From turners@ieca.com Wed Jul 3 20:54:01 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A8521F9CE2 for ; Wed, 3 Jul 2013 20:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.059 X-Spam-Level: X-Spam-Status: No, score=-102.059 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIknS9xoDPZd for ; Wed, 3 Jul 2013 20:53:56 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.66.25]) by ietfa.amsl.com (Postfix) with ESMTP id 049B221F9CB5 for ; Wed, 3 Jul 2013 20:53:55 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id D8A8BBAC22D8E; Wed, 3 Jul 2013 22:53:47 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id CC881BAC22D47 for ; Wed, 3 Jul 2013 22:53:47 -0500 (CDT) Received: from [173.73.135.86] (port=52836 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UuacF-0001xK-7N; Wed, 03 Jul 2013 22:53:55 -0500 Message-ID: <51D4F1D2.104@ieca.com> Date: Wed, 03 Jul 2013 23:53:54 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Montville References: <05BCCEB107AF88469B9F99783D47C1D67053C9@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D67053C9@CISEXCHANGE1.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.86]:52836 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "sacm@ietf.org" Subject: Re: [sacm] Berlin Meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 03:54:01 -0000 On 7/3/13 12:51 PM, Adam Montville wrote: > All: > > While we are not yet an official WG, I'd like to try to get our ducks in > a row and progress as though we are a WG. I see some important dates > have passed, and that some are upcoming > (http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87). > > Notably: > > * 2013-07-05 (this Friday): Final agenda published > * 2013-07-15: Internet Draft submission cut-off (for all drafts, > including -00) > * 2013-07-17: Draft WG agendas due by UTC 24:00 > > Given the milestones listed in our charter, it seems that our agenda > should contain a healthy dose of use case an discussion and possibly > some requirements discussion. > > Proposed (loose) Agenda: > > * Note well + agenda bashing > * Charter and Milestone Review If it's chartered, then we can skip the charter review - it won't be up for discussion because it'll be approved ;) Normally, I'd suggest that sessions avoid summaries of the existing drafts. Participants (used this word on purpose) should read the drafts *before* they come to the session. I'd actually like presenters to ask before they start who has read their draft ;) But, being that this would be the first ever session it's probably okay to present what's in them. In the future, though we can push the work forward and get to the point by only talking about open issues. > * Use Case Discussion > * Review of list > * Presentation on latest draft (if update submitted) > * Requirements discussion (time permitting) > * Administravia (new-WG-related stuff) > > Are there relevant drafts that we want to discuss in Berlin and can be > submitted before the 15 July deadline? At present, the following > "related documents" show up on our Documents page > (http://datatracker.ietf.org/wg/sacm/): > > * draft-booth-sacm-vuln-model-02 > * draft-waltermire-sacm-architecture-00 > * draft-waltermire-sacm-use-cases-04 Ideally, all of these drafts would be updated before the meeting (hint) ;) > I'm looking forward to seeing you in Berlin! > > Regards, > > Adam > > > This message and attachments may contain confidential information. If it > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments > is strictly prohibited. Please notify the sender immediately and > permanently delete the message and any attachments. > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From Adam.Montville@cisecurity.org Fri Jul 5 12:44:25 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BE021F9A3A for ; Fri, 5 Jul 2013 12:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM+jFQGMviST for ; Fri, 5 Jul 2013 12:44:19 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id A2FDD21F9A35 for ; Fri, 5 Jul 2013 12:44:19 -0700 (PDT) Received: from [216.82.253.227:24446] by server-2.bemta-7.messagelabs.com id 69/C4-07784-11227D15; Fri, 05 Jul 2013 19:44:17 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-15.tower-170.messagelabs.com!1373053457!20037019!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 16499 invoked from network); 5 Jul 2013 19:44:17 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-15.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 5 Jul 2013 19:44:17 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Fri, 5 Jul 2013 15:43:42 -0400 From: Adam Montville To: Sean Turner Thread-Topic: [sacm] Berlin Meeting Thread-Index: Ac54C8T0vI3rw79uRzyAYc89//zKvgAf9w0AAEruIsA= Date: Fri, 5 Jul 2013 19:43:45 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6705BF1@CISEXCHANGE1.msisac.org.local> References: <05BCCEB107AF88469B9F99783D47C1D67053C9@CISEXCHANGE1.msisac.org.local> <51D4F1D2.104@ieca.com> In-Reply-To: <51D4F1D2.104@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Berlin Meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 19:44:25 -0000 NOTE: Please ignore the confidentiality notice at the bottom of this e-mai= l (and others) - it is added after I hit "send" and will be removed for IE= TF correspondence sometime in the next week or two. > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Wednesday, July 03, 2013 8:53 PM > To: Adam Montville > Cc: sacm@ietf.org > Subject: Re: [sacm] Berlin Meeting >=20 > On 7/3/13 12:51 PM, Adam Montville wrote: > > All: > > > > While we are not yet an official WG, I'd like to try to get our ducks > > in a row and progress as though we are a WG. I see some important > > dates have passed, and that some are upcoming > > (http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87). > > > > Notably: > > > > * 2013-07-05 (this Friday): Final agenda published > > * 2013-07-15: Internet Draft submission cut-off (for all drafts, > > including -00) > > * 2013-07-17: Draft WG agendas due by UTC 24:00 > > > > Given the milestones listed in our charter, it seems that our agenda > > should contain a healthy dose of use case an discussion and possibly > > some requirements discussion. > > > > Proposed (loose) Agenda: > > > > * Note well + agenda bashing > > * Charter and Milestone Review >=20 > If it's chartered, then we can skip the charter review - it won't be up = for > discussion because it'll be approved ;) Fair enough. Consider the two stricken from the proposed agenda. >=20 > Normally, I'd suggest that sessions avoid summaries of the existing draf= ts. > Participants (used this word on purpose) should read the drafts > *before* they come to the session. I'd actually like presenters to ask = before > they start who has read their draft ;) >=20 > But, being that this would be the first ever session it's probably okay = to > present what's in them. In the future, though we can push the work forw= ard > and get to the point by only talking about open issues. I would encourage everyone to read ahead even for this first session and w= ould anticipate review of these to be minimal and only for those who may n= ot otherwise have heard about SACM work before Berlin. >=20 > > * Use Case Discussion > > * Review of list > > * Presentation on latest draft (if update submitted) > > * Requirements discussion (time permitting) > > * Administravia (new-WG-related stuff) > > > > Are there relevant drafts that we want to discuss in Berlin and can be= > > submitted before the 15 July deadline? At present, the following > > "related documents" show up on our Documents page > > (http://datatracker.ietf.org/wg/sacm/): > > > > * draft-booth-sacm-vuln-model-02 > > * draft-waltermire-sacm-architecture-00 > > * draft-waltermire-sacm-use-cases-04 >=20 > Ideally, all of these drafts would be updated before the meeting (hint) = ;) I am unsure as to the state of the vulnerability model and the architectur= e document. I know that David Harrington has been working on trimming up = the use case document. On that note, he has asked on several occasions for some more concrete use= case examples, but I haven't really seen many provided. It would be good= for this community to throw a few out there. Remember that use cases don= 't need to be comprehensive with respect to the requirements. They should= exemplify. If there are use cases treated elsewhere, but to which access is limited (= i.e. other organizations have published similar use cases but the document= s aren't free), then I suggest that we summarize them here without simply = referencing that work. >=20 > > I'm looking forward to seeing you in Berlin! > > > > Regards, > > > > Adam > > > > > > This message and attachments may contain confidential information. If > > it appears that this message was sent to you by mistake, any > > retention, dissemination, distribution or copying of this message and > > attachments is strictly prohibited. Please notify the sender > > immediately and permanently delete the message and any attachments. > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > >=20 > ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From shanna@juniper.net Fri Jul 5 13:40:21 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B72021F9EC7 for ; Fri, 5 Jul 2013 13:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU1ZKICpoBvF for ; Fri, 5 Jul 2013 13:40:14 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5918221F9DEF for ; Fri, 5 Jul 2013 13:40:14 -0700 (PDT) Received: from mail17-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE037.bigfish.com (10.236.130.100) with Microsoft SMTP Server id 14.1.225.22; Fri, 5 Jul 2013 20:40:13 +0000 Received: from mail17-co9 (localhost [127.0.0.1]) by mail17-co9-R.bigfish.com (Postfix) with ESMTP id 35C553803DE for ; Fri, 5 Jul 2013 20:40:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail17-co9: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=shanna@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail17-co9 (localhost.localdomain [127.0.0.1]) by mail17-co9 (MessageSwitch) id 1373056810556711_10552; Fri, 5 Jul 2013 20:40:10 +0000 (UTC) Received: from CO9EHSMHS009.bigfish.com (unknown [10.236.132.233]) by mail17-co9.bigfish.com (Postfix) with ESMTP id 84E3E10026F for ; Fri, 5 Jul 2013 20:40:10 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.52) by CO9EHSMHS009.bigfish.com (10.236.130.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 5 Jul 2013 20:40:07 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 5 Jul 2013 13:40:06 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 5 Jul 2013 13:40:06 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.185) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 5 Jul 2013 13:52:52 -0700 Received: from mail71-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Fri, 5 Jul 2013 20:40:05 +0000 Received: from mail71-ch1 (localhost [127.0.0.1]) by mail71-ch1-R.bigfish.com (Postfix) with ESMTP id 8DE334C02AA for ; Fri, 5 Jul 2013 20:40:05 +0000 (UTC) Received: from mail71-ch1 (localhost.localdomain [127.0.0.1]) by mail71-ch1 (MessageSwitch) id 1373056803346088_4159; Fri, 5 Jul 2013 20:40:03 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail71-ch1.bigfish.com (Postfix) with ESMTP id 47785380048 for ; Fri, 5 Jul 2013 20:40:03 +0000 (UTC) Received: from SN2PRD0510HT003.namprd05.prod.outlook.com (157.56.234.117) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 5 Jul 2013 20:40:03 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.180]) by SN2PRD0510HT003.namprd05.prod.outlook.com ([10.255.116.38]) with mapi id 14.16.0324.000; Fri, 5 Jul 2013 20:39:53 +0000 From: Stephen Hanna To: "sacm@ietf.org" Thread-Topic: SACM Use Cases Thread-Index: AQHOeb/NLlrbQCcXNUaNRqQ7rj6Jqg== Date: Fri, 5 Jul 2013 20:39:53 +0000 Message-ID: References: <05BCCEB107AF88469B9F99783D47C1D67053C9@CISEXCHANGE1.msisac.org.local> <51D4F1D2.104@ieca.com> <05BCCEB107AF88469B9F99783D47C1D6705BF1@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6705BF1@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: [sacm] SACM Use Cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 20:40:21 -0000 I have a few comments and questions on the SACM Use Cases document. Since Adam has encouraged us to discuss it and offer our thoughts, I'll do so now. First, I recall that we previously agreed to focus our work on UC1 only for now. Our current draft charter seems to reflect that agreement, which is good! So I suggest that UC2 and UC3 be removed from the use case document before it becomes a Working Group document. Second, I often find it's helpful to have specific examples in use cases to make them concrete. After all, people want to solve specific problems with our systems. And this can keep us grounded. For example, we could add an example for UC1 that says: In order to meet compliance requirements and ensure that corporate finance information is not revealed improperly, all computers in the finance department of Example Corporation are required to run only software contained on an approved list and to be configured to download and install software patches every night. Each computer is checked to make sure it complies with this policy whenever it connects to the network and at least once a day thereafter. As part of this daily compliance check, the SACM protocols are used to assess the posture of each computer and report on its compliance with policy. Handling of non-compliant endpoints is not part of the SACM architecture. What do people think? Do you like having such examples? If so, I can write a few more such as one where suspicious endpoint behavior (like contacting a known command and control server) triggers a compliance check. Or one dealing with user-owned (BYOD) devices. These examples may translate into sub-cases of UC1 or we may decide to break out UC1 into several use cases. Other examples could include pulling up a report to see which endpoints have a particular version of software that has just been discovered to have a particular vulnerability. Or which endpoints have *ever* had that software, since the vulnerability might have been exploited before we learned of it. I'm glad we're getting a bit more specific here. That seems appropriate for a use case document! BTW, I see that the charter calls for the use cases to go into the Architecture document. OK by me! But let's start with use cases before we spend too much time talking about architecture. Best to fully understand the problem before we design the solution! And yes, I know that may of us probably think we have a clear idea of the problem already. The issue is that until we've written down the problem description in excruciating detail with examples and agreed upon it, we probably all have different understandings of exactly what the problem is. That's normal. Thanks, Steve From ietfdbh@comcast.net Fri Jul 5 16:17:02 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B2D21F9FDD for ; Fri, 5 Jul 2013 16:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.317 X-Spam-Level: X-Spam-Status: No, score=-100.317 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQJS0FH0HHIA for ; Fri, 5 Jul 2013 16:16:56 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 9F26711E80D3 for ; Fri, 5 Jul 2013 16:16:56 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta07.westchester.pa.mail.comcast.net with comcast id wmky1l0051swQuc57nGwDv; Fri, 05 Jul 2013 23:16:56 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta15.westchester.pa.mail.comcast.net with comcast id wnGv1l00a2yZEBF3bnGvqL; Fri, 05 Jul 2013 23:16:56 +0000 From: "ietfdbh" To: "'Adam Montville'" , "'Sean Turner'" References: <05BCCEB107AF88469B9F99783D47C1D67053C9@CISEXCHANGE1.msisac.org.local> <51D4F1D2.104@ieca.com> <05BCCEB107AF88469B9F99783D47C1D6705BF1@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6705BF1@CISEXCHANGE1.msisac.org.local> Date: Fri, 5 Jul 2013 19:16:30 -0400 Message-ID: <020601ce79d5$aebb2ba0$0c3182e0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGV72V+O1VzEdJYIwyIHtWAjQG4tgHOJnQGAj7uwoqZp1odYA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373066216; bh=c9M2QRb/vGSLigAmKlbN/avqBNmBGKTUSxRw4NoKjN8=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=GvGvyrQj21qC65dZo9WbrJhNOR8nME1gR/K0AAIyPzkPWufsrzfdmJV0fDltP6/9c lALu113Sf3dwjB0jHTCGcNiDlyeEl/klX2BYeA+rUxpfBcC3mVPm12PCN/ES5TQzim p1ks1m7GBHScyFNXY1xWW5NH8uISNLO9zdYhpVGwneE8uHxFYZf2xCSB81y8GwgjcC fN+XUpQ1wp2rM1sBwN3UM04+lPj3bj9BDYDMyOcTo21M02vDzQ4Zt2uRtkoZTU0abx O8h08uWL+SCExJLEigOOMxSyqerXvA7iY78l+ap6MSLilp1y6vyO1/YbFHfF29VVgb ow1qJixfVYKZg== Cc: sacm@ietf.org Subject: Re: [sacm] Berlin Meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 23:17:02 -0000 > I know that David Harrington has been working on trimming up > the use case document. > > On that note, he has asked on several occasions for some more concrete use > case examples, but I haven't really seen many provided. It would be good > for this community to throw a few out there. Remember that use cases > don't need to be comprehensive with respect to the requirements. They > should exemplify. Remember that the IETF mantra is "rough consensus and running code" - the IETF focuses on a bottom-up approach; we like to look at what has been implemented in products or open source, etc. and try to reach consensus on the good common functionality across multiple examples of existing "running code". What we have so far seems be a lot of 50,000 foot abstractions and promises of what the industry will be able to do with what we produce. It reminds me of vaporware marketing ... It would be really good to get some examples of "running code" as use cases. For example, "we ship an application that controls user access to the network, and we use the IETF NEA protocol to gather data, using this information model, and this method of assessment. Implementer feedback has shown these aspects of the specification to be problematic in certain environments for these reasons; customer feedback on deployment of this approach has been successful in these environments, but less successful in these other environments because ...." Or "we have running code for an IPS implementation, in shipping product, and here is text that describes the information model and method of assessing abnormal user behavior, and this method for establishing policy about acceptable variation from normal, and have found that it works well." (UC3) Or, "we have running code in an open source library for continuously monitoring router security configuration. We find that the standards are inadequate in expressing information for this aspect of router configuration, and we had to supplement the standards with our own proprietary data model to add this functionality to our monitoring." We have gotten a number of pointers to work done elsewhere, but it is usually to other standards organizations' specifications. Well, if other SDOs have already written specifications in this space, then why do we need to do anything in the IETF? The IETF doesn't do rubber-stamping of other organizations' specifications. It would be good to get internet-drafts that describes the specifications of other fora that have addressed these issues, and - most importantly - the field experience of implementations/deployments of those other approaches. So if you think we should consider a DMTF information model, or 3GPP information model, or NIST/MITRE information model, then it really should be submitted to the IETF, in an Internet-draft, under IETF IPR rules, and giving change control to the IETF, so we can consider the proposal as input to an IETF design. If you think we should consider such specifications because you have implemented or deployed them and think they work well, then write an ID that discusses your implementation/deployment experience with those other specifications. > > If there are use cases treated elsewhere, but to which access is limited (i.e. > other organizations have published similar use cases but the documents > aren't free), then I suggest that we summarize them here without simply > referencing that work. > And, as always, we welcome text that you propose we add to the use-cases document (or other documents). David Harrington ietfdbh@comcast.net +1-603-828-1401 From shanna@juniper.net Fri Jul 5 17:29:57 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC6D11E80E0 for ; Fri, 5 Jul 2013 17:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.809 X-Spam-Level: X-Spam-Status: No, score=-101.809 tagged_above=-999 required=5 tests=[AWL=-1.657, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Njgq6v8cuZlZ for ; Fri, 5 Jul 2013 17:29:52 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 8C91A21F9FF9 for ; Fri, 5 Jul 2013 17:29:52 -0700 (PDT) Received: from mail50-co1-R.bigfish.com (10.243.78.250) by CO1EHSOBE026.bigfish.com (10.243.66.89) with Microsoft SMTP Server id 14.1.225.22; Sat, 6 Jul 2013 00:29:51 +0000 Received: from mail50-co1 (localhost [127.0.0.1]) by mail50-co1-R.bigfish.com (Postfix) with ESMTP id A078350026B for ; Sat, 6 Jul 2013 00:29:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: PS-27(zz98dI9371I542I1432I4015I168aJdb82hzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL17326ah8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail50-co1: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=shanna@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail50-co1 (localhost.localdomain [127.0.0.1]) by mail50-co1 (MessageSwitch) id 1373070589147389_6449; Sat, 6 Jul 2013 00:29:49 +0000 (UTC) Received: from CO1EHSMHS015.bigfish.com (unknown [10.243.78.226]) by mail50-co1.bigfish.com (Postfix) with ESMTP id 170AF8C004E for ; Sat, 6 Jul 2013 00:29:49 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by CO1EHSMHS015.bigfish.com (10.243.66.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 6 Jul 2013 00:29:48 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 5 Jul 2013 17:29:47 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 5 Jul 2013 17:29:47 -0700 Received: from CO9EHSOBE005.bigfish.com (207.46.163.25) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 5 Jul 2013 17:42:33 -0700 Received: from mail102-co9-R.bigfish.com (10.236.132.244) by CO9EHSOBE005.bigfish.com (10.236.130.68) with Microsoft SMTP Server id 14.1.225.22; Sat, 6 Jul 2013 00:29:46 +0000 Received: from mail102-co9 (localhost [127.0.0.1]) by mail102-co9-R.bigfish.com (Postfix) with ESMTP id D99B034020E for ; Sat, 6 Jul 2013 00:29:46 +0000 (UTC) Received: from mail102-co9 (localhost.localdomain [127.0.0.1]) by mail102-co9 (MessageSwitch) id 1373070584275366_19333; Sat, 6 Jul 2013 00:29:44 +0000 (UTC) Received: from CO9EHSMHS020.bigfish.com (unknown [10.236.132.241]) by mail102-co9.bigfish.com (Postfix) with ESMTP id 34FEB3C005C; Sat, 6 Jul 2013 00:29:44 +0000 (UTC) Received: from SN2PRD0510HT003.namprd05.prod.outlook.com (157.56.234.117) by CO9EHSMHS020.bigfish.com (10.236.130.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 6 Jul 2013 00:29:43 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.180]) by SN2PRD0510HT003.namprd05.prod.outlook.com ([10.255.116.38]) with mapi id 14.16.0324.000; Sat, 6 Jul 2013 00:29:42 +0000 From: Stephen Hanna To: ietfdbh , 'Adam Montville' , 'Sean Turner' Thread-Topic: [sacm] Berlin Meeting Thread-Index: Ac54C8T0vI3rw79uRzyAYc89//zKvgAXlUkAAFN27IAAB24iAAABmZIw Date: Sat, 6 Jul 2013 00:29:42 +0000 Message-ID: References: <05BCCEB107AF88469B9F99783D47C1D67053C9@CISEXCHANGE1.msisac.org.local> <51D4F1D2.104@ieca.com> <05BCCEB107AF88469B9F99783D47C1D6705BF1@CISEXCHANGE1.msisac.org.local> <020601ce79d5$aebb2ba0$0c3182e0$@comcast.net> In-Reply-To: <020601ce79d5$aebb2ba0$0c3182e0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%COMCAST.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISECURITY.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IECA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "sacm@ietf.org" Subject: Re: [sacm] Berlin Meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 00:29:58 -0000 Dave Harrington wrote: > It would be really good to get some examples of "running > code" as use cases. OK, Dave. I'll bite and send some info on running code that uses open standards for endpoint assessment. I expect that others will also, after they return from their holiday weekend. Dozens of products (open source and commercial) and thousands of customers (millions of users) have done endpoint assessment using the TNC/NEA standards. Customers typically use these standards to solve problems like the ones described in RFC 5209 (the NEA Requirements spec). Those problems are very similar to the ones described for SACM but we seem to be adding a bit more by wanting to have a standard compliance language and some reporting. Maybe also the ability to assess devices that don't have NEA support built in, which TNC can sort of support via the IF-MAP and CESP specs (although some aspects of that are underspecified right now). SCAP has standards for a standard compliance language and some reporting but they don't seem to have any actual protocols for endpoint assessment. Now you probably want more hard facts. Which products support the TNC standards? Which customers are using them? What are they doing with them? TCG has a certification program for products that have implemented the TNC/NEA specs. The list of certified products is here: https://www.trustedcomputinggroup.org/certification/tnc_certified_products_= list And this page has links to case studies that document actual customers who have happily implemented this: https://www.trustedcomputinggroup.org/solutions/network_access_and_identity The SCAP Validation Program is here: http://scap.nist.gov/validation/ For a list of validated products, go here: http://nvd.nist.gov/scapproducts.cfm I don't have links to case studies from customers who are using the SCAP standards. I'm sure that some of the SCAP experts on this list can provide links. I don't want to toot my own horn but since you asked for first-hand experience, I will say that Juniper has been shipping products that conform to the TNC standards for the last eight years and those standards work pretty darn well! Not perfect and more is needed but they are a good starting point. For my ideas on how the TNC/NEA standards can be used for SACM and what more is needed, see this draft: http://datatracker.ietf.org/doc/draft-hanna-sacm-assessment-protocols I guess I'd better update that draft to wake it from its dormancy and bring it up to date. Will do. You asked why IETF needs to be involved if there are already standards in this area. As described in my I-D linked to above, the TNC/NEA standards don't provide a rich enough language for policy checks. SCAP can provide that and fits nicely with the TNC protocols. For one idea on how to fit those specs together, see this Public Review draft (not final): http://www.trustedcomputinggroup.org/resources/tnc_scap_messages_for_ifm Obviously, that document would need more work to be ready. And many of the SCAP documents aren't really open standards, at least in my view. And we need a way to handle endpoints that don't support the TNC/NEA protocols. TCG has some solutions in that area (IF-MAP and CESP) but I would never claim that TCG has the answer to everything. IETF brings together an unparalleled group of experts who will make the SACM specs much better than what went in. Like you, I'm allergic to "meta-architectural frameworks", as Radia Perlman calls them. Let's get specific! Please respond to the other email I sent today on use cases. Let's get that document nailed down to some specific problems that real customers have. Then we can move on to creating standards that solve those problems, preferably by starting with standards that have been used for years in the real world so that we know what their flaws are and we can fix them! Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > ietfdbh > Sent: Friday, July 05, 2013 7:17 PM > To: 'Adam Montville'; 'Sean Turner' > Cc: sacm@ietf.org > Subject: Re: [sacm] Berlin Meeting >=20 > > I know that David Harrington has been working on trimming up > > the use case document. > > > > On that note, he has asked on several occasions for some more > concrete use > > case examples, but I haven't really seen many provided. It would be > good > > for this community to throw a few out there. Remember that use cases > > don't need to be comprehensive with respect to the requirements. > They > > should exemplify. >=20 > Remember that the IETF mantra is "rough consensus and running code" - > the > IETF focuses on a bottom-up approach; we like to look at what has been > implemented in products or open source, etc. and try to reach consensus > on > the good common functionality across multiple examples of existing > "running > code". > What we have so far seems be a lot of 50,000 foot abstractions and > promises > of what the industry will be able to do with what we produce. > It reminds me of vaporware marketing ... >=20 > It would be really good to get some examples of "running code" as use > cases. > For example, "we ship an application that controls user access to the > network, and we use the IETF NEA protocol to gather data, using this > information model, and this method of assessment. Implementer feedback > has > shown these aspects of the specification to be problematic in certain > environments for these reasons; customer feedback on deployment of > this > approach has been successful in these environments, but less successful > in > these other environments because ...." >=20 > Or "we have running code for an IPS implementation, in shipping > product, and > here is text that describes the information model and method of > assessing > abnormal user behavior, and this method for establishing policy about > acceptable variation from normal, and have found that it works well." > (UC3) >=20 > Or, "we have running code in an open source library for continuously > monitoring router security configuration. We find that the standards > are > inadequate in expressing information for this aspect of router > configuration, and we had to supplement the standards with our own > proprietary data model to add this functionality to our monitoring." >=20 > We have gotten a number of pointers to work done elsewhere, but it is > usually to other standards organizations' specifications. > Well, if other SDOs have already written specifications in this space, > then > why do we need to do anything in the IETF? The IETF doesn't do > rubber-stamping of other organizations' specifications. > It would be good to get internet-drafts that describes the > specifications of > other fora that have addressed these issues, and - most importantly - > the > field experience of implementations/deployments of those other > approaches. > So if you think we should consider a DMTF information model, or 3GPP > information model, or NIST/MITRE information model, then it really > should be > submitted to the IETF, in an Internet-draft, under IETF IPR rules, and > giving change control to the IETF, so we can consider the proposal as > input > to an IETF design. > If you think we should consider such specifications because you have > implemented or deployed them and think they work well, then write an ID > that > discusses your implementation/deployment experience with those other > specifications. >=20 > > > > If there are use cases treated elsewhere, but to which access is > limited > (i.e. > > other organizations have published similar use cases but the > documents > > aren't free), then I suggest that we summarize them here without > simply > > referencing that work. > > >=20 > And, as always, we welcome text that you propose we add to the use- > cases > document (or other documents). >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From ietfdbh@comcast.net Sat Jul 6 05:58:36 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC8B21F9BA6 for ; Sat, 6 Jul 2013 05:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.337 X-Spam-Level: X-Spam-Status: No, score=-100.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U66UJ1iS-cHa for ; Sat, 6 Jul 2013 05:58:30 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id ADAC821F9BAB for ; Sat, 6 Jul 2013 05:58:30 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id wzwl1l0010xGWP8530yWZb; Sat, 06 Jul 2013 12:58:30 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta12.westchester.pa.mail.comcast.net with comcast id x0yV1l00o2yZEBF3Y0yVuo; Sat, 06 Jul 2013 12:58:30 +0000 From: "ietfdbh" To: "'Stephen Hanna'" , References: <05BCCEB107AF88469B9F99783D47C1D67053C9@CISEXCHANGE1.msisac.org.local> <51D4F1D2.104@ieca.com> <05BCCEB107AF88469B9F99783D47C1D6705BF1@CISEXCHANGE1.msisac.org.local> In-Reply-To: Date: Sat, 6 Jul 2013 08:58:01 -0400 Message-ID: <023501ce7a48$72bbd730$58338590$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGV72V+O1VzEdJYIwyIHtWAjQG4tgHOJnQGAj7uwooB/L+SiJmYWpZQ Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373115510; bh=jUfl8RDQDk2ybb4Ux9IHxixprCW2E54j4wsRECvo9Yw=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=oWIsiTC+QexVJmOctH1G7Zr+vrzTptBZbsDwd36gF5gbH2YJQ3g0aRZFA+IKDJMrD +RgNHhjBu6Egw25AuZxqGSiSO9gSR2M9VlA5/BDzaaTxSpx60DCYEzkbdjazJA8T3f QC+Ew0UGofnBRS6C1BFhCoZ2xDUl7uiZ86Xk6R82lXNIvHamQISgWnYci7e+8abEHd OmEIWp5yg9yIq+IsdxEh5aoVaYkBG+YQDjexPRHm2ER3GB5t2SVNqg/GrhfvnUy8aR t+wWne41iWqsdtYIA3kF1jAS+f0LZRSPqGIs2B84qCMhsFoPmwtCu6Rbww1x8zfkSX /QC9Fxd/LnvaA== Subject: Re: [sacm] SACM Use Cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 12:58:36 -0000 Thank you Steve. Specific examples seem very helpful in understanding the scope of the problem, so we can better focus on the scope of the possible solution(s). Comments inline ... > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Friday, July 05, 2013 4:40 PM > To: sacm@ietf.org > Subject: [sacm] SACM Use Cases > > I have a few comments and questions on the SACM Use Cases document. > Since Adam has encouraged us to discuss it and offer our thoughts, I'll do so > now. > > First, I recall that we previously agreed to focus our work on UC1 only for > now. Our current draft charter seems to reflect that agreement, which is > good! So I suggest that UC2 and UC3 be removed from the use case > document before it becomes a Working Group document. I can do that if there is consensus. Anybody disagree strongly with removing these sections, and focusing solely on UC1 in this document? We can re-title this document "Using Security Posture Assessment to Grant Access to Network Resources" Comments? Anybody want to develop documents for use cases for UC2 and UC3? (everything can be merged/broken out differently later if desired.) > > Second, I often find it's helpful to have specific examples in use cases to > make them concrete. After all, people want to solve specific problems with > our systems. > And this can keep us grounded. I definitely agree with this. > > For example, we could add an example for UC1 that > says: > > In order to meet compliance requirements and ensure that corporate > finance information is not revealed improperly, all computers in the finance > department of Example Corporation are required to run only software > contained on an approved list and to be configured to download and install > software patches every night. Each computer is checked to make sure it > complies with this policy whenever it connects to the network and at least > once a day thereafter. As part of this daily compliance check, the SACM > protocols are used to assess the posture of each computer and report on its > compliance with policy. Added the example to the UC draft. > Handling of non-compliant endpoints is not part of the SACM architecture. I left this part out; it didn't seem appropriate for the UC document. Maybe it belongs in the charter or the arch doc? > > What do people think? Do you like having such examples? > If so, I can write a few more such as one where suspicious endpoint behavior > (like contacting a known command and control server) triggers a compliance > check. > Or one dealing with user-owned (BYOD) devices. These examples may > translate into sub-cases of UC1 or we may decide to break out UC1 into > several use cases. > Other examples could include pulling up a report to see which endpoints > have a particular version of software that has just been discovered to have a > particular vulnerability. Or which endpoints have > *ever* had that software, since the vulnerability might have been exploited > before we learned of it. I would gladly add such examples to the UC doc. Can you please write them up for inclusion? > > I'm glad we're getting a bit more specific here. > That seems appropriate for a use case document! +1 > > BTW, I see that the charter calls for the use cases to go into the Architecture > document. OK by me! But let's start with use cases before we spend too > much time talking about architecture. Best to fully understand the problem > before we design the solution! +1 > > And yes, I know that may of us probably think we have a clear idea of the > problem already. The issue is that until we've written down the problem > description in excruciating detail with examples and agreed upon it, we > probably all have different understandings of exactly what the problem is. > That's normal. Agreed. I don't know about the excruciating detail, but at least some concrete examples of the problem(s) we're trying to solve seems called for, to help us all get on the same page. In addition, having some concrete examples of use cases will help others, such as the IESG, to better understand the nature of the problems we want to work on, and to narrow down what types of functionality and information models might benefit from standardization. David Harrington ietfdbh@comcast.net +1-603-828-1401 From Adam.Montville@cisecurity.org Tue Jul 9 04:27:46 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C8121F9FE4 for ; Tue, 9 Jul 2013 04:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JHSZx1I4WF1 for ; Tue, 9 Jul 2013 04:27:41 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.109]) by ietfa.amsl.com (Postfix) with ESMTP id 40B0E21F9FD5 for ; Tue, 9 Jul 2013 04:27:41 -0700 (PDT) Received: from [216.82.253.243:62514] by server-13.bemta-7.messagelabs.com id 2E/B1-01054-BA3FBD15; Tue, 09 Jul 2013 11:27:39 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-9.tower-171.messagelabs.com!1373369259!17453654!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 16309 invoked from network); 9 Jul 2013 11:27:39 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-9.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 9 Jul 2013 11:27:39 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Tue, 9 Jul 2013 07:26:57 -0400 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: [sacm] SACM Use Cases Thread-Index: AQHOeb/NsPG+Kr3eaEm3dpwoNTzYK5lX4HKAgARYhzA= Date: Tue, 9 Jul 2013 11:27:00 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6706332@CISEXCHANGE1.msisac.org.local> References: <05BCCEB107AF88469B9F99783D47C1D67053C9@CISEXCHANGE1.msisac.org.local> <51D4F1D2.104@ieca.com> <05BCCEB107AF88469B9F99783D47C1D6705BF1@CISEXCHANGE1.msisac.org.local> <023501ce7a48$72bbd730$58338590$@comcast.net> In-Reply-To: <023501ce7a48$72bbd730$58338590$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM Use Cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 11:27:46 -0000 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > ietfdbh > Sent: Saturday, July 06, 2013 5:58 AM > To: 'Stephen Hanna'; sacm@ietf.org > Subject: Re: [sacm] SACM Use Cases >=20 > Thank you Steve. > Specific examples seem very helpful in understanding the scope of the > problem, so we can better focus on the scope of the possible solution(s)= . > Comments inline ... >=20 >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Stephen Hanna > > Sent: Friday, July 05, 2013 4:40 PM > > To: sacm@ietf.org > > Subject: [sacm] SACM Use Cases > > > > I have a few comments and questions on the SACM Use Cases document. > > Since Adam has encouraged us to discuss it and offer our thoughts, > > I'll do > so > > now. > > > > First, I recall that we previously agreed to focus our work on UC1 > > only > for > > now. Our current draft charter seems to reflect that agreement, which > > is good! So I suggest that UC2 and UC3 be removed from the use case > > document before it becomes a Working Group document. >=20 > I can do that if there is consensus. > Anybody disagree strongly with removing these sections, and focusing sol= ely > on UC1 in this document? I would not have any objection to removing these use cases from the docume= nt, but do have a concern about "forgetting" them over time. While we hav= e agreed to be focused on the first use case, I do not see why we cannot i= nclude a brief "epic" or "scenario" level description of the other use cas= es and simply explicitly state that we are focused on the first use case, = which would subsequently be discussed in detail.=20 >=20 > We can re-title this document "Using Security Posture Assessment to Gran= t > Access to Network Resources" > Comments? > Anybody want to develop documents for use cases for UC2 and UC3? > (everything can be merged/broken out differently later if desired.) >=20 > > > > Second, I often find it's helpful to have specific examples in use > > cases > to > > make them concrete. After all, people want to solve specific problems > > with our systems. > > And this can keep us grounded. >=20 > I definitely agree with this. >=20 > > > > For example, we could add an example for UC1 that > > says: > > > > In order to meet compliance requirements and ensure that corporate > > finance information is not revealed improperly, all computers in the > finance > > department of Example Corporation are required to run only software > > contained on an approved list and to be configured to download and > > install software patches every night. Each computer is checked to make= > > sure it complies with this policy whenever it connects to the network > > and at least once a day thereafter. As part of this daily compliance > > check, the SACM protocols are used to assess the posture of each > > computer and report on > its > > compliance with policy. >=20 > Added the example to the UC draft. >=20 > > Handling of non-compliant endpoints is not part of the SACM architectu= re. >=20 > I left this part out; it didn't seem appropriate for the UC document. > Maybe it belongs in the charter or the arch doc? >=20 > > > > What do people think? Do you like having such examples? I would not be surprised if many in this community have these or similar e= xamples in mind when reading these documents. That said, I'd like to be a= s helpful as possible for newcomers to our problem domain, so I have no ob= jection to including such examples. My concern is that we end up building= something that is too constrained for other valid examples, so we may hav= e to watch for that. > > If so, I can write a few more such as one where suspicious endpoint > behavior > > (like contacting a known command and control server) triggers a > > compliance check. > > Or one dealing with user-owned (BYOD) devices. These examples may > > translate into sub-cases of UC1 or we may decide to break out UC1 into= > > several use cases. > > Other examples could include pulling up a report to see which > > endpoints have a particular version of software that has just been > > discovered to > have a > > particular vulnerability. Or which endpoints have > > *ever* had that software, since the vulnerability might have been > exploited > > before we learned of it. >=20 > I would gladly add such examples to the UC doc. > Can you please write them up for inclusion? Steve, if you need help with some of these (for the sake of time, I know y= ou don't need "help" considering the examples), let me know and I'll write= a couple (just be specific about which ones you'd like me to write). For that matter, I would encourage others on the list to look at the detai= led examples that have been provided and to submit, perhaps as a reply to = this thread, your own examples. The more examples we have, the better abs= tractions we'll be able to see, and thus a better architecture should be a= chievable. >=20 > > > > I'm glad we're getting a bit more specific here. > > That seems appropriate for a use case document! >=20 > +1 +1, but let's not go overboard either :-) We should have enough example t= o enable careful readers to build an abstract model in their minds, so as = to yield an effective overall architecture... >=20 > > > > BTW, I see that the charter calls for the use cases to go into the > Architecture > > document. OK by me! But let's start with use cases before we spend too= > > much time talking about architecture. Best to fully understand the > > problem before we design the solution! >=20 > +1 +1 >=20 > > > > And yes, I know that may of us probably think we have a clear idea of > > the problem already. The issue is that until we've written down the > > problem description in excruciating detail with examples and agreed > > upon it, we probably all have different understandings of exactly what= the > problem is. > > That's normal. >=20 > Agreed. I don't know about the excruciating detail, but at least some > concrete examples of the problem(s) we're trying to solve seems called f= or, > to help us all get on the same page. > In addition, having some concrete examples of use cases will=20help othe= rs, > such as the IESG, to better understand the nature of the problems we wan= t > to work on, and to narrow down what types of functionality and informati= on > models might benefit from standardization. >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From turners@ieca.com Thu Jul 11 09:26:54 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984CD21F9B38 for ; Thu, 11 Jul 2013 09:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.053 X-Spam-Level: X-Spam-Status: No, score=-101.053 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXYuvmHtmzwk for ; Thu, 11 Jul 2013 09:26:45 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.142.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9F54421F99FA for ; Thu, 11 Jul 2013 09:26:45 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 13EBEBCD4065E; Thu, 11 Jul 2013 11:26:37 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 069A6BCD40638 for ; Thu, 11 Jul 2013 11:26:37 -0500 (CDT) Received: from [74.96.0.204] (port=51127 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UxJhc-0002ww-QK for sacm@ietf.org; Thu, 11 Jul 2013 11:26:44 -0500 Message-ID: <51DEDCC4.7010802@ieca.com> Date: Thu, 11 Jul 2013 12:26:44 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: sacm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [74.96.0.204]:51127 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [sacm] charter status X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 16:26:54 -0000 The charter was approved on today's call. You'll see the official announcement early next week. spt From turners@ieca.com Thu Jul 11 09:31:58 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BAD21F9A1C for ; Thu, 11 Jul 2013 09:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.193 X-Spam-Level: X-Spam-Status: No, score=-102.193 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MnsFZkWeCW1 for ; Thu, 11 Jul 2013 09:31:53 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [67.18.34.19]) by ietfa.amsl.com (Postfix) with ESMTP id B093A21F9BDB for ; Thu, 11 Jul 2013 09:31:37 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 76D56BD56741C; Thu, 11 Jul 2013 11:31:34 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 699A8BD5673ED for ; Thu, 11 Jul 2013 11:31:34 -0500 (CDT) Received: from [74.96.0.204] (port=51135 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UxJmI-0005FI-8q for sacm@ietf.org; Thu, 11 Jul 2013 11:31:34 -0500 Message-ID: <51DEDDE5.2070101@ieca.com> Date: Thu, 11 Jul 2013 12:31:33 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: sacm@ietf.org References: <20130711162658.7093.66495.idtracker@ietfa.amsl.com> In-Reply-To: <20130711162658.7093.66495.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130711162658.7093.66495.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [74.96.0.204]:51135 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 16:31:59 -0000 Food for thought. spt -------- Original Message -------- Subject: I-D Action: draft-handt-sacm-alternate-architecture-00.txt Date: Thu, 11 Jul 2013 09:26:58 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : sacm: Alternate Architecture Author(s) : Russ Housley Sean Turner Filename : draft-handt-sacm-alternate-architecture-00.txt Pages : 5 Date : 2013-07-11 Abstract: This document proposes and alternate architecture for sacm (a proposed working group at the time this draft was submitted). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-handt-sacm-alternate-architecture There's also a htmlized version available at: http://tools.ietf.org/html/draft-handt-sacm-alternate-architecture-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From turners@ieca.com Thu Jul 11 09:51:51 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE98B21F9F29 for ; Thu, 11 Jul 2013 09:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.197 X-Spam-Level: X-Spam-Status: No, score=-102.197 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvFFoXGGaF1n for ; Thu, 11 Jul 2013 09:51:45 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.137.84]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDE621F9799 for ; Thu, 11 Jul 2013 09:51:43 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 6D00B8AFF7DF1; Thu, 11 Jul 2013 11:51:36 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 2D4A38AFF76DC for ; Thu, 11 Jul 2013 11:51:34 -0500 (CDT) Received: from [74.96.0.204] (port=51254 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UxK5d-0005t5-W4 for sacm@ietf.org; Thu, 11 Jul 2013 11:51:34 -0500 Message-ID: <51DEE295.3050403@ieca.com> Date: Thu, 11 Jul 2013 12:51:33 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: sacm@ietf.org References: <20130711165015.29939.87432.idtracker@ietfa.amsl.com> In-Reply-To: <20130711165015.29939.87432.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130711165015.29939.87432.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [74.96.0.204]:51254 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 12 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 16:51:51 -0000 More food for thought. spt -------- Original Message -------- Subject: I-D Action: draft-handt-sacm-asset-identifiers-00.txt Date: Thu, 11 Jul 2013 09:50:15 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : sacm: Asset Identifier Author(s) : Russ Housley Sean Turner Filename : draft-handt-sacm-asset-identifiers-00.txt Pages : 7 Date : 2013-07-11 Abstract: This document examines the asset identifiers available for sacm and it proposes that OIDs (Object Identifiers) be selected as the asset identifier format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-handt-sacm-asset-identifiers There's also a htmlized version available at: http://tools.ietf.org/html/draft-handt-sacm-asset-identifiers-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From dromasca@avaya.com Fri Jul 12 04:05:51 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B409F21F9DED for ; Fri, 12 Jul 2013 04:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.327 X-Spam-Level: X-Spam-Status: No, score=-103.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4cmZ+dEIRYR for ; Fri, 12 Jul 2013 04:05:45 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id EB2F521F9DBA for ; Fri, 12 Jul 2013 04:05:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFALDi31GHCzI1/2dsb2JhbABagmUhgQODBr5LF3EWdIIjAQEBAQMSERFRBgEIDQQEAQEDAgYdAwIEMBQBBgEBBQUEEwgah20Blj2EQoo7kTwXgSaOChYoglAzbAOeI4sHgxGCKA X-IronPort-AV: E=Sophos;i="4.89,652,1367985600"; d="scan'208";a="16299770" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Jul 2013 07:05:31 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Jul 2013 06:59:38 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Fri, 12 Jul 2013 07:05:28 -0400 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: sacm - Requested session has been scheduled for IETF 87 Thread-Index: AQHOc3QGaPtvLQ3GwESJU5Z0fFN09plg9whw Date: Fri, 12 Jul 2013 11:05:28 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1286BD26@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sacm] FW: sacm - Requested session has been scheduled for IETF 87 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 11:05:51 -0000 DQpIaSwNCg0KVGhlIGZvcm1hdGlvbiBvZiB0aGUgU0FDTSBXRyB3YXMgYXBwcm92ZWQgeWVzdGVy ZGF5IGJ5IHRoZSBJRVNHLiBUaGUgb2ZmaWNpYWwgYW5ub3VuY2VtZW50IHdpbGwgYmUgb3V0IGJ5 IHRoZSBiZWdpbm5pbmcgb2YgdGhlIG5leHQgd2Vlay4gVGhlIHBsYW5uZWQgc2Vzc2lvbiBpcyBu b3cgYmVjb21pbmcgdGhlIGZpcnN0IFdHIHNlc3Npb24uIEFzIHRoZSBXRyBpcyBmb3JtZWQgd2Ug aGF2ZSBhbHNvIGZyZWVkIHNvbWUgdGltZSBhcyB3ZSBkbyBub3QgbmVlZCB0byBkZWFsIHdpdGgg dGhlIGNoYXJ0ZXIgZGlzY3Vzc2lvbnMgYW55IGxvbmdlci4gUGxlYXNlIHNlbmQgYWdlbmRhIHJl cXVlc3RzIGlmIHlvdSBkaWQgbm90IGRvIGl0IHlldC4gQWxzbyBwbGVhc2UgcGF5IGF0dGVudGlv biB0byB0aGUgRnJpZGF5IHNjaGVkdWxpbmcgYW5kIHBsYW4geW91ciB0cmlwIGFjY29yZGluZ2x5 LiANCg0KUmVnYXJkcywNCg0KRGFuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogIklFVEYgU2VjcmV0YXJpYXQiIFttYWlsdG86YWdlbmRhQGlldGYub3JnXSANClNlbnQ6 IFRodXJzZGF5LCBKdW5lIDI3LCAyMDEzIDExOjIyIFBNDQpUbzogY21vcmdhbkBhbXNsLmNvbQ0K Q2M6IHNhY20tYWRzQHRvb2xzLmlldGYub3JnOyBSb21hc2NhbnUsIERhbiAoRGFuKTsgS2F0aGxl ZW4uTW9yaWFydHlAZW1jLmNvbTsgbWJlYXVsaWV1QGFtc2wuY29tDQpTdWJqZWN0OiBzYWNtIC0g UmVxdWVzdGVkIHNlc3Npb24gaGFzIGJlZW4gc2NoZWR1bGVkIGZvciBJRVRGIDg3DQoNCkRlYXIg Q2luZHkgTW9yZ2FuLA0KDQpUaGUgc2Vzc2lvbihzKSB0aGF0IHlvdSBoYXZlIHJlcXVlc3RlZCBo YXZlIGJlZW4gc2NoZWR1bGVkLg0KQmVsb3cgaXMgdGhlIHNjaGVkdWxlZCBzZXNzaW9uIGluZm9y bWF0aW9uIGZvbGxvd2VkIGJ5IHRoZSBvcmlnaW5hbCByZXF1ZXN0LiANCg0Kc2FjbSBTZXNzaW9u IDEgKDI6MDA6MDApDQogICAgRnJpZGF5LCBBZnRlcm5vb24gU2Vzc2lvbiBJIDExMjAtMTIyMA0K ICAgIFJvb20gTmFtZTogUG90c2RhbSAyDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQogICAgDQoNCg0KUmVxdWVzdCBJbmZvcm1hdGlvbjoNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CldvcmtpbmcgR3JvdXAgTmFtZTogDQpBcmVhIE5hbWU6IA0KU2Vzc2lvbiBSZXF1ZXN0ZXI6IA0K DQpOdW1iZXIgb2YgU2Vzc2lvbnM6IDENCkxlbmd0aCBvZiBTZXNzaW9uKHMpOiAgMiBIb3Vycw0K TnVtYmVyIG9mIEF0dGVuZGVlczogODANCkNvbmZsaWN0cyB0byBBdm9pZDogDQogRmlyc3QgUHJp b3JpdHk6IGxtYXAgeHJibG9jayBtaWxlIHNhYWcgb3BzZWMgZW1hbiBuZXRjb25mIG5ldG1vZCB0 bHMgaXBzZWNtZSBlbXUgam9zZSBzY2ltDQoNCg0KDQoNClNwZWNpYWwgUmVxdWVzdHM6DQogIA0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCg== From dbharrington@comcast.net Fri Jul 12 07:07:46 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576E721F9A4B for ; Fri, 12 Jul 2013 07:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRQmXmQGe3KM for ; Fri, 12 Jul 2013 07:07:41 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 3057C21F9EBD for ; Fri, 12 Jul 2013 07:07:27 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id zQ0n1l0011swQuc53S7SPK; Fri, 12 Jul 2013 14:07:26 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta15.westchester.pa.mail.comcast.net with comcast id zS7S1l00R2yZEBF3bS7SDX; Fri, 12 Jul 2013 14:07:26 +0000 From: "David Harrington" To: "'Sean Turner'" , References: <20130711162658.7093.66495.idtracker@ietfa.amsl.com> <51DEDDE5.2070101@ieca.com> In-Reply-To: <51DEDDE5.2070101@ieca.com> Date: Fri, 12 Jul 2013 10:06:53 -0400 Message-ID: <012d01ce7f09$0fc8bc90$2f5a35b0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHznD1rOpqPCNVF4Uo3EJCv58gmKAINk8g2mQZqUzA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373638046; bh=KKHqtsS6l0QAKMDNaHo4sv0y3XgecTe0Al0799u924c=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=pnHSWXcNV/YBkwjxe2XcKoiWDtrYDvTvUnpzTeJZPXHilGmWn66MZkKELG/MCN9NM QhydFbHFMYZFtknsjQVJHWkicAz/muLCJRrL6Ga9fDp3VsJcF877hwZcj1rBilSnjQ wLLtKzTh16/YTJ3QsZlhGLURs2jHdlqqhBrO7Cpd34OegWf54nCWBlrl//NMHQlzIF txU0vy4s2MtzHbNGH4+SqyOGt2agusJZKmVqWd5IKGT2mPJ0thweJZ517slGxjzK3e kER9hzJFnClr5tZBbSn1+ST17IhZhCjimsdLJ0MKcLGzImpyjqBkUA5PplxJyYKOdQ 6CdtBNs6etXKQ== Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 14:07:46 -0000 Hi, While I don't fully agree with the original architecture, I find it easier to understand the intended functionality than in the alternate architecture. I understand the goal here of showing where the on-the-wire protocols operate between entities. The data flows in the Waltermire architecture do not clearly capture the on-the-wire-ness of the flows, and what sits where in the network. It might be helpful to use both diagrams, combined, to show the network entities and on-the-wire data flows, and then show within the entity boxes, the expected functionality provided by each. The new architecture seems focused on a combination firewall/IDS box; that seems like a particular use case. As you all know already, I think the scope of the sacm work needs to be narrowed, but this might narrow it too much. (Sean, can you write up a firewall/IDS use case that I can put into the use-cases document for this usage?) David Harrington dbharrington@comcast.net +1-603-828-1401 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Thursday, July 11, 2013 12:32 PM > To: sacm@ietf.org > Subject: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture- > 00.txt > > Food for thought. > > spt > -------- Original Message -------- > Subject: I-D Action: draft-handt-sacm-alternate-architecture-00.txt > Date: Thu, 11 Jul 2013 09:26:58 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : sacm: Alternate Architecture > Author(s) : Russ Housley > Sean Turner > Filename : draft-handt-sacm-alternate-architecture-00.txt > Pages : 5 > Date : 2013-07-11 > > Abstract: > This document proposes and alternate architecture for sacm (a > proposed working group at the time this draft was submitted). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-handt-sacm-alternate-architecture > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-handt-sacm-alternate-architecture-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Fri Jul 12 08:11:16 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC6721F91CB for ; Fri, 12 Jul 2013 08:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYmS592VGKQM for ; Fri, 12 Jul 2013 08:11:11 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8113D21F91C4 for ; Fri, 12 Jul 2013 08:11:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=O+Bsi5nD+wagVARG04qbfrdiDR8EN2OncvfGtyaPlvapOe67OoJichWANky/z0jrH2iNPDiIwtnsFkE2PW+w5RshWHHCYo8EsPXZCvzApy/1NwS6sd2VpsrzbkXq+WtD; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; Received: (qmail 17394 invoked from network); 12 Jul 2013 08:09:00 -0700 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Jul 2013 08:08:57 -0700 Message-ID: <51E01C90.1040403@ThreatGuard.com> Date: Fri, 12 Jul 2013 11:11:12 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Harrington References: <20130711162658.7093.66495.idtracker@ietfa.amsl.com> <51DEDDE5.2070101@ieca.com> <012d01ce7f09$0fc8bc90$2f5a35b0$@comcast.net> In-Reply-To: <012d01ce7f09$0fc8bc90$2f5a35b0$@comcast.net> Content-Type: multipart/mixed; boundary="------------010902070800010109090005" Cc: 'Sean Turner' , sacm@ietf.org Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 15:11:16 -0000 This is a multi-part message in MIME format. --------------010902070800010109090005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I like the original. It's only concerned with the logical components that make up SACM -- the flexibility in how they are mixed and match to solve real problems is one of its big strengths. But it's also apparent that this is not being effectively communicated. I sent some (lousy) drawings to the mailing list a while back trying to capture that flexibility -- attached here again for your amusement/befuddlement. Do very specific use cases help people understand how these standards can be applied? --gun On 7/12/2013 10:06 AM, David Harrington wrote: > Hi, > > While I don't fully agree with the original architecture, I find it easier > to understand the intended functionality than in the alternate architecture. > > I understand the goal here of showing where the on-the-wire protocols > operate between entities. > The data flows in the Waltermire architecture do not clearly capture the > on-the-wire-ness of the flows, and what sits where in the network. > It might be helpful to use both diagrams, combined, to show the network > entities and on-the-wire data flows, and then show within the entity boxes, > the expected functionality provided by each. > > The new architecture seems focused on a combination firewall/IDS box; that > seems like a particular use case. > As you all know already, I think the scope of the sacm work needs to be > narrowed, but this might narrow it too much. > > (Sean, can you write up a firewall/IDS use case that I can put into the > use-cases document for this usage?) > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Sean Turner >> Sent: Thursday, July 11, 2013 12:32 PM >> To: sacm@ietf.org >> Subject: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture- >> 00.txt >> >> Food for thought. >> >> spt >> -------- Original Message -------- >> Subject: I-D Action: draft-handt-sacm-alternate-architecture-00.txt >> Date: Thu, 11 Jul 2013 09:26:58 -0700 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> >> >> Title : sacm: Alternate Architecture >> Author(s) : Russ Housley >> Sean Turner >> Filename : draft-handt-sacm-alternate-architecture-00.txt >> Pages : 5 >> Date : 2013-07-11 >> >> Abstract: >> This document proposes and alternate architecture for sacm (a >> proposed working group at the time this draft was submitted). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-handt-sacm-alternate-architecture >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-handt-sacm-alternate-architecture-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --------------010902070800010109090005 Content-Type: image/svg+xml; name="BasicEntities.svg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="BasicEntities.svg" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+ CjwhLS0gQ3JlYXRlZCB3aXRoIElua3NjYXBlIChodHRwOi8vd3d3Lmlua3NjYXBlLm9yZy8p IC0tPgoKPHN2ZwogICB4bWxuczpvc2I9Imh0dHA6Ly93d3cub3BlbnN3YXRjaGJvb2sub3Jn L3VyaS8yMDA5L29zYiIKICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50 cy8xLjEvIgogICB4bWxuczpjYz0iaHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbnMjIgog ICB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1u cyMiCiAgIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciCiAgIHhtbG5z PSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIKICAgeG1sbnM6eGxpbms9Imh0dHA6Ly93 d3cudzMub3JnLzE5OTkveGxpbmsiCiAgIHhtbG5zOnNvZGlwb2RpPSJodHRwOi8vc29kaXBv ZGkuc291cmNlZm9yZ2UubmV0L0RURC9zb2RpcG9kaS0wLmR0ZCIKICAgeG1sbnM6aW5rc2Nh cGU9Imh0dHA6Ly93d3cuaW5rc2NhcGUub3JnL25hbWVzcGFjZXMvaW5rc2NhcGUiCiAgIHdp ZHRoPSI3NDQuMDk0NDg4MTkiCiAgIGhlaWdodD0iMTA1Mi4zNjIyMDQ3IgogICBpZD0ic3Zn MiIKICAgdmVyc2lvbj0iMS4xIgogICBpbmtzY2FwZTp2ZXJzaW9uPSIwLjQ4LjQgcjk5Mzki CiAgIHNvZGlwb2RpOmRvY25hbWU9IkJhc2ljRW50aXRpZXMuc3ZnIj4KICA8ZGVmcwogICAg IGlkPSJkZWZzNCI+CiAgICA8bWFya2VyCiAgICAgICBpbmtzY2FwZTpzdG9ja2lkPSJUYWls IgogICAgICAgb3JpZW50PSJhdXRvIgogICAgICAgcmVmWT0iMC4wIgogICAgICAgcmVmWD0i MC4wIgogICAgICAgaWQ9IlRhaWwiCiAgICAgICBzdHlsZT0ib3ZlcmZsb3c6dmlzaWJsZSI+ CiAgICAgIDxnCiAgICAgICAgIGlkPSJnNTY0NCIKICAgICAgICAgdHJhbnNmb3JtPSJzY2Fs ZSgtMS4yKSI+CiAgICAgICAgPHBhdGgKICAgICAgICAgICBpZD0icGF0aDU2NDYiCiAgICAg ICAgICAgZD0iTSAtMy44MDQ4Njc0LC0zLjk1ODUyMjcgTCAwLjU0MzUyMDk0LDAiCiAgICAg ICAgICAgc3R5bGU9ImZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzAwMDAw MDtzdHJva2Utd2lkdGg6MC44O3N0cm9rZS1saW5lY2FwOnJvdW5kIiAvPgogICAgICAgIDxw YXRoCiAgICAgICAgICAgaWQ9InBhdGg1NjQ4IgogICAgICAgICAgIGQ9Ik0gLTEuMjg2Njgz MiwtMy45NTg1MjI3IEwgMy4wNjE3MDUzLDAiCiAgICAgICAgICAgc3R5bGU9ImZpbGw6bm9u ZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MC44O3N0 cm9rZS1saW5lY2FwOnJvdW5kIiAvPgogICAgICAgIDxwYXRoCiAgICAgICAgICAgaWQ9InBh dGg1NjUwIgogICAgICAgICAgIGQ9Ik0gMS4zMDUzNTgyLC0zLjk1ODUyMjcgTCA1LjY1Mzc0 NjYsMCIKICAgICAgICAgICBzdHlsZT0iZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0 cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDowLjg7c3Ryb2tlLWxpbmVjYXA6cm91bmQiIC8+ CiAgICAgICAgPHBhdGgKICAgICAgICAgICBpZD0icGF0aDU2NTIiCiAgICAgICAgICAgZD0i TSAtMy44MDQ4Njc0LDQuMTc3NTgzOCBMIDAuNTQzNTIwOTQsMC4yMTk3NDIyNiIKICAgICAg ICAgICBzdHlsZT0iZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojMDAwMDAw O3N0cm9rZS13aWR0aDowLjg7c3Ryb2tlLWxpbmVjYXA6cm91bmQiIC8+CiAgICAgICAgPHBh dGgKICAgICAgICAgICBpZD0icGF0aDU2NTQiCiAgICAgICAgICAgZD0iTSAtMS4yODY2ODMy LDQuMTc3NTgzOCBMIDMuMDYxNzA1MywwLjIxOTc0MjI2IgogICAgICAgICAgIHN0eWxlPSJm aWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRo OjAuODtzdHJva2UtbGluZWNhcDpyb3VuZCIgLz4KICAgICAgICA8cGF0aAogICAgICAgICAg IGlkPSJwYXRoNTY1NiIKICAgICAgICAgICBkPSJNIDEuMzA1MzU4Miw0LjE3NzU4MzggTCA1 LjY1Mzc0NjYsMC4yMTk3NDIyNiIKICAgICAgICAgICBzdHlsZT0iZmlsbDpub25lO2ZpbGwt cnVsZTpldmVub2RkO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDowLjg7c3Ryb2tlLWxp bmVjYXA6cm91bmQiIC8+CiAgICAgIDwvZz4KICAgIDwvbWFya2VyPgogICAgPG1hcmtlcgog ICAgICAgaW5rc2NhcGU6c3RvY2tpZD0iQXJyb3cyTGVuZCIKICAgICAgIG9yaWVudD0iYXV0 byIKICAgICAgIHJlZlk9IjAuMCIKICAgICAgIHJlZlg9IjAuMCIKICAgICAgIGlkPSJBcnJv dzJMZW5kIgogICAgICAgc3R5bGU9Im92ZXJmbG93OnZpc2libGU7Ij4KICAgICAgPHBhdGgK ICAgICAgICAgaWQ9InBhdGg1NjI5IgogICAgICAgICBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5v ZGQ7c3Ryb2tlLXdpZHRoOjAuNjI1MDAwMDA7c3Ryb2tlLWxpbmVqb2luOnJvdW5kOyIKICAg ICAgICAgZD0iTSA4LjcxODU4NzgsNC4wMzM3MzUyIEwgLTIuMjA3Mjg5NSwwLjAxNjAxMzI1 NiBMIDguNzE4NTg4NCwtNC4wMDE3MDc4IEMgNi45NzMwOTAwLC0xLjYyOTY0NjkgNi45ODMx NDc2LDEuNjE1NzQ0MSA4LjcxODU4NzgsNC4wMzM3MzUyIHogIgogICAgICAgICB0cmFuc2Zv cm09InNjYWxlKDEuMSkgcm90YXRlKDE4MCkgdHJhbnNsYXRlKDEsMCkiIC8+CiAgICA8L21h cmtlcj4KICAgIDxtYXJrZXIKICAgICAgIGlua3NjYXBlOnN0b2NraWQ9IkFycm93MkxzdGFy dCIKICAgICAgIG9yaWVudD0iYXV0byIKICAgICAgIHJlZlk9IjAuMCIKICAgICAgIHJlZlg9 IjAuMCIKICAgICAgIGlkPSJBcnJvdzJMc3RhcnQiCiAgICAgICBzdHlsZT0ib3ZlcmZsb3c6 dmlzaWJsZSI+CiAgICAgIDxwYXRoCiAgICAgICAgIGlkPSJwYXRoNTYyNiIKICAgICAgICAg c3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO3N0cm9rZS13aWR0aDowLjYyNTAwMDAwO3N0cm9r ZS1saW5lam9pbjpyb3VuZCIKICAgICAgICAgZD0iTSA4LjcxODU4NzgsNC4wMzM3MzUyIEwg LTIuMjA3Mjg5NSwwLjAxNjAxMzI1NiBMIDguNzE4NTg4NCwtNC4wMDE3MDc4IEMgNi45NzMw OTAwLC0xLjYyOTY0NjkgNi45ODMxNDc2LDEuNjE1NzQ0MSA4LjcxODU4NzgsNC4wMzM3MzUy IHogIgogICAgICAgICB0cmFuc2Zvcm09InNjYWxlKDEuMSkgdHJhbnNsYXRlKDEsMCkiIC8+ CiAgICA8L21hcmtlcj4KICAgIDxtYXJrZXIKICAgICAgIGlua3NjYXBlOnN0b2NraWQ9IkFy cm93MUxlbmQiCiAgICAgICBvcmllbnQ9ImF1dG8iCiAgICAgICByZWZZPSIwLjAiCiAgICAg ICByZWZYPSIwLjAiCiAgICAgICBpZD0iQXJyb3cxTGVuZCIKICAgICAgIHN0eWxlPSJvdmVy Zmxvdzp2aXNpYmxlOyI+CiAgICAgIDxwYXRoCiAgICAgICAgIGlkPSJwYXRoNTYxMSIKICAg ICAgICAgZD0iTSAwLjAsMC4wIEwgNS4wLC01LjAgTCAtMTIuNSwwLjAgTCA1LjAsNS4wIEwg MC4wLDAuMCB6ICIKICAgICAgICAgc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO3N0cm9rZToj MDAwMDAwO3N0cm9rZS13aWR0aDoxLjBwdDsiCiAgICAgICAgIHRyYW5zZm9ybT0ic2NhbGUo MC44KSByb3RhdGUoMTgwKSB0cmFuc2xhdGUoMTIuNSwwKSIgLz4KICAgIDwvbWFya2VyPgog ICAgPG1hcmtlcgogICAgICAgaW5rc2NhcGU6c3RvY2tpZD0iQXJyb3cxTXN0YXJ0IgogICAg ICAgb3JpZW50PSJhdXRvIgogICAgICAgcmVmWT0iMC4wIgogICAgICAgcmVmWD0iMC4wIgog ICAgICAgaWQ9IkFycm93MU1zdGFydCIKICAgICAgIHN0eWxlPSJvdmVyZmxvdzp2aXNpYmxl Ij4KICAgICAgPHBhdGgKICAgICAgICAgaWQ9InBhdGg1NjE0IgogICAgICAgICBkPSJNIDAu MCwwLjAgTCA1LjAsLTUuMCBMIC0xMi41LDAuMCBMIDUuMCw1LjAgTCAwLjAsMC4wIHogIgog ICAgICAgICBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tl LXdpZHRoOjEuMHB0IgogICAgICAgICB0cmFuc2Zvcm09InNjYWxlKDAuNCkgdHJhbnNsYXRl KDEwLDApIiAvPgogICAgPC9tYXJrZXI+CiAgICA8bWFya2VyCiAgICAgICBpbmtzY2FwZTpz dG9ja2lkPSJBcnJvdzFNZW5kIgogICAgICAgb3JpZW50PSJhdXRvIgogICAgICAgcmVmWT0i MC4wIgogICAgICAgcmVmWD0iMC4wIgogICAgICAgaWQ9IkFycm93MU1lbmQiCiAgICAgICBz dHlsZT0ib3ZlcmZsb3c6dmlzaWJsZTsiPgogICAgICA8cGF0aAogICAgICAgICBpZD0icGF0 aDU2MTciCiAgICAgICAgIGQ9Ik0gMC4wLDAuMCBMIDUuMCwtNS4wIEwgLTEyLjUsMC4wIEwg NS4wLDUuMCBMIDAuMCwwLjAgeiAiCiAgICAgICAgIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9k ZDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MS4wcHQ7IgogICAgICAgICB0cmFuc2Zv cm09InNjYWxlKDAuNCkgcm90YXRlKDE4MCkgdHJhbnNsYXRlKDEwLDApIiAvPgogICAgPC9t YXJrZXI+CiAgICA8bWFya2VyCiAgICAgICBpbmtzY2FwZTpzdG9ja2lkPSJBcnJvdzFTc3Rh cnQiCiAgICAgICBvcmllbnQ9ImF1dG8iCiAgICAgICByZWZZPSIwLjAiCiAgICAgICByZWZY PSIwLjAiCiAgICAgICBpZD0iQXJyb3cxU3N0YXJ0IgogICAgICAgc3R5bGU9Im92ZXJmbG93 OnZpc2libGUiPgogICAgICA8cGF0aAogICAgICAgICBpZD0icGF0aDU2MjAiCiAgICAgICAg IGQ9Ik0gMC4wLDAuMCBMIDUuMCwtNS4wIEwgLTEyLjUsMC4wIEwgNS4wLDUuMCBMIDAuMCww LjAgeiAiCiAgICAgICAgIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzAwMDAw MDtzdHJva2Utd2lkdGg6MS4wcHQiCiAgICAgICAgIHRyYW5zZm9ybT0ic2NhbGUoMC4yKSB0 cmFuc2xhdGUoNiwwKSIgLz4KICAgIDwvbWFya2VyPgogICAgPG1hcmtlcgogICAgICAgaW5r c2NhcGU6c3RvY2tpZD0iQXJyb3cxTHN0YXJ0IgogICAgICAgb3JpZW50PSJhdXRvIgogICAg ICAgcmVmWT0iMC4wIgogICAgICAgcmVmWD0iMC4wIgogICAgICAgaWQ9IkFycm93MUxzdGFy dCIKICAgICAgIHN0eWxlPSJvdmVyZmxvdzp2aXNpYmxlIj4KICAgICAgPHBhdGgKICAgICAg ICAgaWQ9InBhdGg1NjA4IgogICAgICAgICBkPSJNIDAuMCwwLjAgTCA1LjAsLTUuMCBMIC0x Mi41LDAuMCBMIDUuMCw1LjAgTCAwLjAsMC4wIHogIgogICAgICAgICBzdHlsZT0iZmlsbC1y dWxlOmV2ZW5vZGQ7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjEuMHB0IgogICAgICAg ICB0cmFuc2Zvcm09InNjYWxlKDAuOCkgdHJhbnNsYXRlKDEyLjUsMCkiIC8+CiAgICA8L21h cmtlcj4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ0 MyIKICAgICAgIG9zYjpwYWludD0ic29saWQiPgogICAgICA8c3RvcAogICAgICAgICBzdHls ZT0ic3RvcC1jb2xvcjojYjNjY2Y4O3N0b3Atb3BhY2l0eToxOyIKICAgICAgICAgb2Zmc2V0 PSIwIgogICAgICAgICBpZD0ic3RvcDU0NDUiIC8+CiAgICA8L2xpbmVhckdyYWRpZW50Pgog ICAgPGxpbmVhckdyYWRpZW50CiAgICAgICBpZD0ibGluZWFyR3JhZGllbnQ1MjU3IgogICAg ICAgb3NiOnBhaW50PSJzb2xpZCI+CiAgICAgIDxzdG9wCiAgICAgICAgIHN0eWxlPSJzdG9w LWNvbG9yOiMwMDAwZmY7c3RvcC1vcGFjaXR5OjAuMzQzOTE1MzQ7IgogICAgICAgICBvZmZz ZXQ9IjAiCiAgICAgICAgIGlkPSJzdG9wNTI1OSIgLz4KICAgIDwvbGluZWFyR3JhZGllbnQ+ CiAgICA8aW5rc2NhcGU6cGVyc3BlY3RpdmUKICAgICAgIHNvZGlwb2RpOnR5cGU9Imlua3Nj YXBlOnBlcnNwM2QiCiAgICAgICBpbmtzY2FwZTp2cF94PSIwIDogNTI2LjE4MTA5IDogMSIK ICAgICAgIGlua3NjYXBlOnZwX3k9IjAgOiAxMDAwIDogMCIKICAgICAgIGlua3NjYXBlOnZw X3o9Ijc0NC4wOTQ0OCA6IDUyNi4xODEwOSA6IDEiCiAgICAgICBpbmtzY2FwZTpwZXJzcDNk LW9yaWdpbj0iMzcyLjA0NzI0IDogMzUwLjc4NzM5IDogMSIKICAgICAgIGlkPSJwZXJzcGVj dGl2ZTI5OTUiIC8+CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAgIGlua3NjYXBlOmNvbGxl Y3Q9ImFsd2F5cyIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMiCiAg ICAgICBpZD0ibGluZWFyR3JhZGllbnQ1NDUxIgogICAgICAgeDE9Ijc2Ljc5MTkwMSIKICAg ICAgIHkxPSIxODEuMTA1NjIiCiAgICAgICB4Mj0iMjMyLjMxNDc3IgogICAgICAgeTI9IjE4 MS4xMDU2MiIKICAgICAgIGdyYWRpZW50VW5pdHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAg Z3JhZGllbnRUcmFuc2Zvcm09InRyYW5zbGF0ZSgtMTAuMDIwOTE1LDEzOS41NTQ2MSkiIC8+ CiAgICA8ZmlsdGVyCiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiCiAgICAgICBp ZD0iZmlsdGVyNTQ3MyIKICAgICAgIHg9Ii0wLjEwMDQiCiAgICAgICB3aWR0aD0iMS4yMDA4 IgogICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhlaWdodD0iMS4yOTgyMTc4Ij4KICAg ICAgPGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIK ICAgICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIiCiAgICAgICAgIGlkPSJmZUdhdXNz aWFuQmx1cjU0NzUiIC8+CiAgICA8L2ZpbHRlcj4KICAgIDxsaW5lYXJHcmFkaWVudAogICAg ICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAgeGxpbms6aHJlZj0iI2xpbmVh ckdyYWRpZW50NTQ0My0yIgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ1MS01IgogICAg ICAgeDE9Ijc2Ljc5MTkwMSIKICAgICAgIHkxPSIxODEuMTA1NjIiCiAgICAgICB4Mj0iMjMy LjMxNDc3IgogICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIGdyYWRpZW50VW5pdHM9InVz ZXJTcGFjZU9uVXNlIiAvPgogICAgPGxpbmVhckdyYWRpZW50CiAgICAgICBpZD0ibGluZWFy R3JhZGllbnQ1NDQzLTIiCiAgICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAgPHN0b3AK ICAgICAgICAgc3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6MTsiCiAg ICAgICAgIG9mZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1LTMiIC8+CiAgICA8L2xp bmVhckdyYWRpZW50PgogICAgPGZpbHRlcgogICAgICAgY29sb3ItaW50ZXJwb2xhdGlvbi1m aWx0ZXJzPSJzUkdCIgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAg aWQ9ImZpbHRlcjU0NzMtMSIKICAgICAgIHg9Ii0wLjEwMDQiCiAgICAgICB3aWR0aD0iMS4y MDA3OTk5IgogICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhlaWdodD0iMS4yOTgyMTc4 Ij4KICAgICAgPGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFs d2F5cyIKICAgICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIiCiAgICAgICAgIGlkPSJm ZUdhdXNzaWFuQmx1cjU0NzUtNiIgLz4KICAgIDwvZmlsdGVyPgogICAgPGxpbmVhckdyYWRp ZW50CiAgICAgICBncmFkaWVudFRyYW5zZm9ybT0idHJhbnNsYXRlKDQ2NS4xMDQyLC0zNi4z NjU0ODQpIgogICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIHgyPSIyMzIuMzE0NzciCiAg ICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAgeDE9Ijc2Ljc5MTkwMSIKICAgICAgIGdyYWRp ZW50VW5pdHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ5 MyIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMtMiIKICAgICAgIGlu a3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIgLz4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAg aW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAgeGxpbms6aHJlZj0iI2xpbmVhckdy YWRpZW50NTQ0My0yNyIKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVudDU0NTEtOCIKICAgICAg IHgxPSI3Ni43OTE5MDEiCiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAgeDI9IjIzMi4z MTQ3NyIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICBncmFkaWVudFVuaXRzPSJ1c2Vy U3BhY2VPblVzZSIgLz4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgaWQ9ImxpbmVhckdy YWRpZW50NTQ0My0yNyIKICAgICAgIG9zYjpwYWludD0ic29saWQiPgogICAgICA8c3RvcAog ICAgICAgICBzdHlsZT0ic3RvcC1jb2xvcjojYjNjY2Y4O3N0b3Atb3BhY2l0eToxOyIKICAg ICAgICAgb2Zmc2V0PSIwIgogICAgICAgICBpZD0ic3RvcDU0NDUtNyIgLz4KICAgIDwvbGlu ZWFyR3JhZGllbnQ+CiAgICA8ZmlsdGVyCiAgICAgICBjb2xvci1pbnRlcnBvbGF0aW9uLWZp bHRlcnM9InNSR0IiCiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiCiAgICAgICBp ZD0iZmlsdGVyNTQ3My0xMiIKICAgICAgIHg9Ii0wLjEwMDQiCiAgICAgICB3aWR0aD0iMS4y MDA3OTk5IgogICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhlaWdodD0iMS4yOTgyMTc4 Ij4KICAgICAgPGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFs d2F5cyIKICAgICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIiCiAgICAgICAgIGlkPSJm ZUdhdXNzaWFuQmx1cjU0NzUtNjAiIC8+CiAgICA8L2ZpbHRlcj4KICAgIDxsaW5lYXJHcmFk aWVudAogICAgICAgZ3JhZGllbnRUcmFuc2Zvcm09InRyYW5zbGF0ZSgtMTAuMDIwOTI4LC0z Ni4zNjU1MDYpIgogICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIHgyPSIyMzIuMzE0Nzci CiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAgeDE9Ijc2Ljc5MTkwMSIKICAgICAgIGdy YWRpZW50VW5pdHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50 NTQ5My00IgogICAgICAgeGxpbms6aHJlZj0iI2xpbmVhckdyYWRpZW50NTQ0My0yNyIKICAg ICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIgLz4KICAgIDxsaW5lYXJHcmFkaWVudAog ICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAgeGxpbms6aHJlZj0iI2xp bmVhckdyYWRpZW50NTQ0My02IgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ1MS00Igog ICAgICAgeDE9Ijc2Ljc5MTkwMSIKICAgICAgIHkxPSIxODEuMTA1NjIiCiAgICAgICB4Mj0i MjMyLjMxNDc3IgogICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIGdyYWRpZW50VW5pdHM9 InVzZXJTcGFjZU9uVXNlIiAvPgogICAgPGxpbmVhckdyYWRpZW50CiAgICAgICBpZD0ibGlu ZWFyR3JhZGllbnQ1NDQzLTYiCiAgICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAgPHN0 b3AKICAgICAgICAgc3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6MTsi CiAgICAgICAgIG9mZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1LTAiIC8+CiAgICA8 L2xpbmVhckdyYWRpZW50PgogICAgPGZpbHRlcgogICAgICAgY29sb3ItaW50ZXJwb2xhdGlv bi1maWx0ZXJzPSJzUkdCIgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAg ICAgaWQ9ImZpbHRlcjU0NzMtMyIKICAgICAgIHg9Ii0wLjEwMDQiCiAgICAgICB3aWR0aD0i MS4yMDA3OTk5IgogICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhlaWdodD0iMS4yOTgy MTc4Ij4KICAgICAgPGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9 ImFsd2F5cyIKICAgICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIiCiAgICAgICAgIGlk PSJmZUdhdXNzaWFuQmx1cjU0NzUtNjIiIC8+CiAgICA8L2ZpbHRlcj4KICAgIDxsaW5lYXJH cmFkaWVudAogICAgICAgZ3JhZGllbnRUcmFuc2Zvcm09InRyYW5zbGF0ZSg0NjUuMTA0MTYs NDgzLjU4NjQ0KSIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICB4Mj0iMjMyLjMxNDc3 IgogICAgICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgxPSI3Ni43OTE5MDEiCiAgICAgICBn cmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVu dDU0OTMtNDUiCiAgICAgICB4bGluazpocmVmPSIjbGluZWFyR3JhZGllbnQ1NDQzLTYiCiAg ICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiIC8+CiAgICA8bGluZWFyR3JhZGllbnQK ICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIKICAgICAgIHhsaW5rOmhyZWY9IiNs aW5lYXJHcmFkaWVudDU0NDMtMjEiCiAgICAgICBpZD0ibGluZWFyR3JhZGllbnQ1NDUxLTEi CiAgICAgICB4MT0iNzYuNzkxOTAxIgogICAgICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgy PSIyMzIuMzE0NzciCiAgICAgICB5Mj0iMTgxLjEwNTYyIgogICAgICAgZ3JhZGllbnRVbml0 cz0idXNlclNwYWNlT25Vc2UiIC8+CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAgIGlkPSJs aW5lYXJHcmFkaWVudDU0NDMtMjEiCiAgICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAg PHN0b3AKICAgICAgICAgc3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6 MTsiCiAgICAgICAgIG9mZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1LTQiIC8+CiAg ICA8L2xpbmVhckdyYWRpZW50PgogICAgPGZpbHRlcgogICAgICAgY29sb3ItaW50ZXJwb2xh dGlvbi1maWx0ZXJzPSJzUkdCIgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgog ICAgICAgaWQ9ImZpbHRlcjU0NzMtOSIKICAgICAgIHg9Ii0wLjEwMDQiCiAgICAgICB3aWR0 aD0iMS4yMDA3OTk5IgogICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhlaWdodD0iMS4y OTgyMTc4Ij4KICAgICAgPGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3NjYXBlOmNvbGxl Y3Q9ImFsd2F5cyIKICAgICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIiCiAgICAgICAg IGlkPSJmZUdhdXNzaWFuQmx1cjU0NzUtOCIgLz4KICAgIDwvZmlsdGVyPgogICAgPGxpbmVh ckdyYWRpZW50CiAgICAgICBncmFkaWVudFRyYW5zZm9ybT0idHJhbnNsYXRlKDIyOS45MTg4 OCwxMzkuNTU0NjIpIgogICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIHgyPSIyMzIuMzE0 NzciCiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAgeDE9Ijc2Ljc5MTkwMSIKICAgICAg IGdyYWRpZW50VW5pdHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAgaWQ9ImxpbmVhckdyYWRp ZW50NTQ5My0yIgogICAgICAgeGxpbms6aHJlZj0iI2xpbmVhckdyYWRpZW50NTQ0My0yMSIK ICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIgLz4KICAgIDxsaW5lYXJHcmFkaWVu dAogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAgeGxpbms6aHJlZj0i I2xpbmVhckdyYWRpZW50NTQ0My05IgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ1MS01 MiIKICAgICAgIHgxPSI3Ni43OTE5MDEiCiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAg eDI9IjIzMi4zMTQ3NyIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICBncmFkaWVudFVu aXRzPSJ1c2VyU3BhY2VPblVzZSIgLz4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgaWQ9 ImxpbmVhckdyYWRpZW50NTQ0My05IgogICAgICAgb3NiOnBhaW50PSJzb2xpZCI+CiAgICAg IDxzdG9wCiAgICAgICAgIHN0eWxlPSJzdG9wLWNvbG9yOiNiM2NjZjg7c3RvcC1vcGFjaXR5 OjE7IgogICAgICAgICBvZmZzZXQ9IjAiCiAgICAgICAgIGlkPSJzdG9wNTQ0NS05IiAvPgog ICAgPC9saW5lYXJHcmFkaWVudD4KICAgIDxmaWx0ZXIKICAgICAgIGNvbG9yLWludGVycG9s YXRpb24tZmlsdGVycz0ic1JHQiIKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIK ICAgICAgIGlkPSJmaWx0ZXI1NDczLTgiCiAgICAgICB4PSItMC4xMDA0IgogICAgICAgd2lk dGg9IjEuMjAwNzk5OSIKICAgICAgIHk9Ii0wLjE0OTEwODkiCiAgICAgICBoZWlnaHQ9IjEu Mjk4MjE3OCI+CiAgICAgIDxmZUdhdXNzaWFuQmx1cgogICAgICAgICBpbmtzY2FwZTpjb2xs ZWN0PSJhbHdheXMiCiAgICAgICAgIHN0ZERldmlhdGlvbj0iNi4zMzg3MDcyIgogICAgICAg ICBpZD0iZmVHYXVzc2lhbkJsdXI1NDc1LTMiIC8+CiAgICA8L2ZpbHRlcj4KICAgIDxsaW5l YXJHcmFkaWVudAogICAgICAgZ3JhZGllbnRUcmFuc2Zvcm09InRyYW5zbGF0ZSg0NjUuMTA0 MjEsMzExLjIzMTA1KSIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICB4Mj0iMjMyLjMx NDc3IgogICAgICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgxPSI3Ni43OTE5MDEiCiAgICAg ICBncmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIKICAgICAgIGlkPSJsaW5lYXJHcmFk aWVudDU0OTMtOCIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMtOSIK ICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIgLz4KICA8L2RlZnM+CiAgPHNvZGlw b2RpOm5hbWVkdmlldwogICAgIGlkPSJiYXNlIgogICAgIHBhZ2Vjb2xvcj0iI2ZmZmZmZiIK ICAgICBib3JkZXJjb2xvcj0iIzY2NjY2NiIKICAgICBib3JkZXJvcGFjaXR5PSIxLjAiCiAg ICAgaW5rc2NhcGU6cGFnZW9wYWNpdHk9IjAuMCIKICAgICBpbmtzY2FwZTpwYWdlc2hhZG93 PSIyIgogICAgIGlua3NjYXBlOnpvb209IjAuOTg5OTQ5NDkiCiAgICAgaW5rc2NhcGU6Y3g9 IjM4NS40MzQ4NCIKICAgICBpbmtzY2FwZTpjeT0iNTgyLjQ0NTU0IgogICAgIGlua3NjYXBl OmRvY3VtZW50LXVuaXRzPSJweCIKICAgICBpbmtzY2FwZTpjdXJyZW50LWxheWVyPSJsYXll cjEiCiAgICAgc2hvd2dyaWQ9ImZhbHNlIgogICAgIGlua3NjYXBlOndpbmRvdy13aWR0aD0i MTI3OSIKICAgICBpbmtzY2FwZTp3aW5kb3ctaGVpZ2h0PSIxMDgxIgogICAgIGlua3NjYXBl OndpbmRvdy14PSIyMDYxIgogICAgIGlua3NjYXBlOndpbmRvdy15PSI0MCIKICAgICBpbmtz Y2FwZTp3aW5kb3ctbWF4aW1pemVkPSIwIiAvPgogIDxtZXRhZGF0YQogICAgIGlkPSJtZXRh ZGF0YTciPgogICAgPHJkZjpSREY+CiAgICAgIDxjYzpXb3JrCiAgICAgICAgIHJkZjphYm91 dD0iIj4KICAgICAgICA8ZGM6Zm9ybWF0PmltYWdlL3N2Zyt4bWw8L2RjOmZvcm1hdD4KICAg ICAgICA8ZGM6dHlwZQogICAgICAgICAgIHJkZjpyZXNvdXJjZT0iaHR0cDovL3B1cmwub3Jn L2RjL2RjbWl0eXBlL1N0aWxsSW1hZ2UiIC8+CiAgICAgICAgPGRjOnRpdGxlPjwvZGM6dGl0 bGU+CiAgICAgIDwvY2M6V29yaz4KICAgIDwvcmRmOlJERj4KICA8L21ldGFkYXRhPgogIDxn CiAgICAgaW5rc2NhcGU6bGFiZWw9IkxheWVyIDEiCiAgICAgaW5rc2NhcGU6Z3JvdXBtb2Rl PSJsYXllciIKICAgICBpZD0ibGF5ZXIxIj4KICAgIDxyZWN0CiAgICAgICBzdHlsZT0iZmls bDp1cmwoI2xpbmVhckdyYWRpZW50NTQ1MSk7ZmlsbC1vcGFjaXR5OjE7ZmlsbC1ydWxlOm5v bnplcm87c3Ryb2tlOiMwMzAwNzg7c3Ryb2tlLXdpZHRoOjQ7c3Ryb2tlLWxpbmVjYXA6c3F1 YXJlO3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2UtbWl0ZXJsaW1pdDo0O3N0cm9rZS1v cGFjaXR5OjE7c3Ryb2tlLWRhc2hhcnJheTpub25lO3N0cm9rZS1kYXNob2Zmc2V0OjA7Zmls dGVyOnVybCgjZmlsdGVyNTQ3MykiCiAgICAgICBpZD0icmVjdDMwMTkiCiAgICAgICB3aWR0 aD0iMTUxLjUyMjg3IgogICAgICAgaGVpZ2h0PSIxMDIuMDI1NDEiCiAgICAgICB4PSI2OC43 NzA5OTYiCiAgICAgICB5PSIyNjkuNjQ3NTIiIC8+CiAgICA8cmVjdAogICAgICAgc3R5bGU9 ImZpbGw6dXJsKCNsaW5lYXJHcmFkaWVudDU0OTMtMik7ZmlsbC1vcGFjaXR5OjE7ZmlsbC1y dWxlOm5vbnplcm87c3Ryb2tlOiMwMzAwNzg7c3Ryb2tlLXdpZHRoOjQ7c3Ryb2tlLWxpbmVj YXA6c3F1YXJlO3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2UtbWl0ZXJsaW1pdDo0O3N0 cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLWRhc2hhcnJheTpub25lO3N0cm9rZS1kYXNob2Zmc2V0 OjA7ZmlsdGVyOnVybCgjZmlsdGVyNTQ3My05KSIKICAgICAgIGlkPSJyZWN0MzAxOS00Igog ICAgICAgd2lkdGg9IjE1MS41MjI4NyIKICAgICAgIGhlaWdodD0iMTAyLjAyNTQxIgogICAg ICAgeD0iMzA4LjcxMDgyIgogICAgICAgeT0iMjY5LjY0NzUyIiAvPgogICAgPHJlY3QKICAg ICAgIHN0eWxlPSJmaWxsOnVybCgjbGluZWFyR3JhZGllbnQ1NDkzKTtmaWxsLW9wYWNpdHk6 MTtmaWxsLXJ1bGU6bm9uemVybztzdHJva2U6IzAzMDA3ODtzdHJva2Utd2lkdGg6NDtzdHJv a2UtbGluZWNhcDpzcXVhcmU7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1taXRlcmxp bWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtZGFzaGFycmF5Om5vbmU7c3Ryb2tlLWRh c2hvZmZzZXQ6MDtmaWx0ZXI6dXJsKCNmaWx0ZXI1NDczLTEpIgogICAgICAgaWQ9InJlY3Qz MDE5LTgiCiAgICAgICB3aWR0aD0iMTUxLjUyMjg3IgogICAgICAgaGVpZ2h0PSIxMDIuMDI1 NDEiCiAgICAgICB4PSI1NDMuODk2MDYiCiAgICAgICB5PSI5My43Mjc0MTciIC8+CiAgICA8 cmVjdAogICAgICAgc3R5bGU9ImZpbGw6dXJsKCNsaW5lYXJHcmFkaWVudDU0OTMtNCk7Zmls bC1vcGFjaXR5OjE7ZmlsbC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMzAwNzg7c3Ryb2tlLXdp ZHRoOjQ7c3Ryb2tlLWxpbmVjYXA6c3F1YXJlO3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJv a2UtbWl0ZXJsaW1pdDo0O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLWRhc2hhcnJheTpub25l O3N0cm9rZS1kYXNob2Zmc2V0OjA7ZmlsdGVyOnVybCgjZmlsdGVyNTQ3My0xMikiCiAgICAg ICBpZD0icmVjdDMwMTktOSIKICAgICAgIHdpZHRoPSIxNTEuNTIyODciCiAgICAgICBoZWln aHQ9IjEwMi4wMjU0MSIKICAgICAgIHg9IjY4Ljc3MDk5NiIKICAgICAgIHk9IjkzLjcyNzQx NyIgLz4KICAgIDxyZWN0CiAgICAgICBzdHlsZT0iZmlsbDp1cmwoI2xpbmVhckdyYWRpZW50 NTQ5My00NSk7ZmlsbC1vcGFjaXR5OjE7ZmlsbC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMzAw Nzg7c3Ryb2tlLXdpZHRoOjQ7c3Ryb2tlLWxpbmVjYXA6c3F1YXJlO3N0cm9rZS1saW5lam9p bjptaXRlcjtzdHJva2UtbWl0ZXJsaW1pdDo0O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLWRh c2hhcnJheTpub25lO3N0cm9rZS1kYXNob2Zmc2V0OjA7ZmlsdGVyOnVybCgjZmlsdGVyNTQ3 My0zKSIKICAgICAgIGlkPSJyZWN0MzAxOS04OCIKICAgICAgIHdpZHRoPSIxNTEuNTIyODci CiAgICAgICBoZWlnaHQ9IjEwMi4wMjU0MSIKICAgICAgIHg9IjU0My44OTYwNiIKICAgICAg IHk9IjYxMy42NzkyNiIgLz4KICAgIDxyZWN0CiAgICAgICBzdHlsZT0iZmlsbDp1cmwoI2xp bmVhckdyYWRpZW50NTQ5My04KTtmaWxsLW9wYWNpdHk6MTtmaWxsLXJ1bGU6bm9uemVybztz dHJva2U6IzAzMDA3ODtzdHJva2Utd2lkdGg6NDtzdHJva2UtbGluZWNhcDpzcXVhcmU7c3Ry b2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6 MTtzdHJva2UtZGFzaGFycmF5Om5vbmU7c3Ryb2tlLWRhc2hvZmZzZXQ6MDtmaWx0ZXI6dXJs KCNmaWx0ZXI1NDczLTgpIgogICAgICAgaWQ9InJlY3QzMDE5LTYiCiAgICAgICB3aWR0aD0i MTUxLjUyMjg3IgogICAgICAgaGVpZ2h0PSIxMDIuMDI1NDEiCiAgICAgICB4PSI1NDMuODk2 MDYiCiAgICAgICB5PSI0NDEuMzIzOTciIC8+CiAgICA8cGF0aAogICAgICAgc3R5bGU9ImZp bGw6bm9uZTtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MjtzdHJva2UtbGluZWNhcDpi dXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2UtbWl0ZXJsaW1pdDo0O3N0cm9rZS1v cGFjaXR5OjE7c3Ryb2tlLWRhc2hhcnJheTpub25lO21hcmtlci1zdGFydDp1cmwoI0Fycm93 MU1zdGFydCk7bWFya2VyLWVuZDp1cmwoI0Fycm93MU1lbmQpO2Rpc3BsYXk6aW5saW5lIgog ICAgICAgZD0ibSAyMTguMTkyOTUsMTQzLjIyNDg5IDMxOS4yMDgyLDEuMDEwMTUiCiAgICAg ICBpZD0icGF0aDU1OTAiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItdHlwZT0icG9seWxp bmUiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItY3VydmF0dXJlPSIzIiAvPgogICAgPHBh dGgKICAgICAgIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRo OjI7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1p dGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6bm9uZTttYXJr ZXItc3RhcnQ6dXJsKCNBcnJvdzFNc3RhcnQpO21hcmtlci1lbmQ6dXJsKCNBcnJvdzFNZW5k KSIKICAgICAgIGQ9Im0gMjIwLjI5Mzg3LDMyMC42NjAyMyA4OC40MTY5NSwwIgogICAgICAg aWQ9InBhdGg1NTkyIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLXR5cGU9InBvbHlsaW5l IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMyIKICAgICAgIGlua3Nj YXBlOmNvbm5lY3Rpb24tc3RhcnQ9IiNyZWN0MzAxOSIKICAgICAgIGlua3NjYXBlOmNvbm5l Y3Rpb24tc3RhcnQtcG9pbnQ9ImQ0IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQ9 IiNyZWN0MzAxOS00IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQtcG9pbnQ9ImQ0 IiAvPgogICAgPHBhdGgKICAgICAgIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlOiMwMDAwMDA7 c3Ryb2tlLXdpZHRoOjFweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjpt aXRlcjtzdHJva2Utb3BhY2l0eToxIgogICAgICAgZD0ibSAzODQuNDcyMjUsMzIwLjY2MDIz IDAsMCIKICAgICAgIGlkPSJwYXRoNTU5NCIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rvci10 eXBlPSJwb2x5bGluZSIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rvci1jdXJ2YXR1cmU9IjMi CiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLXN0YXJ0PSIjcmVjdDMwMTktNCIKICAgICAg IGlua3NjYXBlOmNvbm5lY3Rpb24tc3RhcnQtcG9pbnQ9ImQ0IgogICAgICAgaW5rc2NhcGU6 Y29ubmVjdGlvbi1lbmQ9IiNyZWN0MzAxOS00IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlv bi1lbmQtcG9pbnQ9ImQ0IiAvPgogICAgPHBhdGgKICAgICAgIHN0eWxlPSJmaWxsOm5vbmU7 c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjI7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJv a2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eTox O3N0cm9rZS1kYXNoYXJyYXk6bm9uZTttYXJrZXItc3RhcnQ6dXJsKCNBcnJvdzFNc3RhcnQp O21hcmtlci1taWQ6bm9uZTttYXJrZXItZW5kOnVybCgjQXJyb3cxTWVuZCkiCiAgICAgICBk PSJNIDU0OS43NzM1LDQ0MS4zMjM5NyA0NTQuMzU2MjQsMzcxLjY3Mjk0IgogICAgICAgaWQ9 InBhdGg1NTk2IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLXR5cGU9InBvbHlsaW5lIgog ICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMyIKICAgICAgIGlua3NjYXBl OmNvbm5lY3Rpb24tc3RhcnQ9IiNyZWN0MzAxOS02IgogICAgICAgaW5rc2NhcGU6Y29ubmVj dGlvbi1zdGFydC1wb2ludD0iZDQiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLWVuZD0i I3JlY3QzMDE5LTQiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLWVuZC1wb2ludD0iZDQi IC8+CiAgICA8cGF0aAogICAgICAgc3R5bGU9ImZpbGw6bm9uZTtzdHJva2U6IzAwMDAwMDtz dHJva2Utd2lkdGg6MjtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRl cjtzdHJva2UtbWl0ZXJsaW1pdDo0O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLWRhc2hhcnJh eTpub25lO21hcmtlci1zdGFydDp1cmwoI0Fycm93MU1zdGFydCk7bWFya2VyLWVuZDp1cmwo I0Fycm93MU1lbmQpIgogICAgICAgZD0ibSA2MTkuNjU3NDksNTQzLjM0OTM5IDAsNzAuMzI5 ODciCiAgICAgICBpZD0icGF0aDU1OTgiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItdHlw ZT0icG9seWxpbmUiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItY3VydmF0dXJlPSIzIgog ICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFydD0iI3JlY3QzMDE5LTYiCiAgICAgICBp bmtzY2FwZTpjb25uZWN0aW9uLXN0YXJ0LXBvaW50PSJkNCIKICAgICAgIGlua3NjYXBlOmNv bm5lY3Rpb24tZW5kPSIjcmVjdDMwMTktODgiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9u LWVuZC1wb2ludD0iZDQiIC8+CiAgICA8cGF0aAogICAgICAgc3R5bGU9ImZpbGw6bm9uZTtz dHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MjtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9r ZS1saW5lam9pbjptaXRlcjtzdHJva2UtbWl0ZXJsaW1pdDo0O3N0cm9rZS1vcGFjaXR5OjE7 c3Ryb2tlLWRhc2hhcnJheToyLCAyO3N0cm9rZS1kYXNob2Zmc2V0OjA7bWFya2VyLXN0YXJ0 OnVybCgjQXJyb3cxTXN0YXJ0KTttYXJrZXItZW5kOnVybCgjQXJyb3cxTWVuZCkiCiAgICAg ICBkPSJtIDYxOS42NTc0OSw0NDEuMzIzOTcgMCwtMjQ1LjU3MTE0IgogICAgICAgaWQ9InBh dGg1NjAwIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLXR5cGU9InBvbHlsaW5lIgogICAg ICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMyIKICAgICAgIGlua3NjYXBlOmNv bm5lY3Rpb24tc3RhcnQ9IiNyZWN0MzAxOS02IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlv bi1zdGFydC1wb2ludD0iZDQiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLWVuZD0iI3Jl Y3QzMDE5LTgiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLWVuZC1wb2ludD0iZDQiIC8+ CiAgICA8cGF0aAogICAgICAgc3R5bGU9ImZpbGw6bm9uZTtzdHJva2U6IzAwMDAwMDtzdHJv a2Utd2lkdGg6MjtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtz dHJva2UtbWl0ZXJsaW1pdDo0O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLWRhc2hhcnJheToy LCAyO3N0cm9rZS1kYXNob2Zmc2V0OjA7bWFya2VyLXN0YXJ0OnVybCgjQXJyb3cxTXN0YXJ0 KTttYXJrZXItZW5kOnVybCgjQXJyb3cxTWVuZCkiCiAgICAgICBkPSJtIDQ1Mi42NzA0Niwy NjkuNjQ3NTIgOTguNzg4ODMsLTczLjg5NDY5IgogICAgICAgaWQ9InBhdGg1NjAyIgogICAg ICAgaW5rc2NhcGU6Y29ubmVjdG9yLXR5cGU9InBvbHlsaW5lIgogICAgICAgaW5rc2NhcGU6 Y29ubmVjdG9yLWN1cnZhdHVyZT0iMyIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tc3Rh cnQ9IiNyZWN0MzAxOS00IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFydC1wb2lu dD0iZDQiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLWVuZD0iI3JlY3QzMDE5LTgiCiAg ICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLWVuZC1wb2ludD0iZDQiIC8+CiAgICA8dGV4dAog ICAgICAgeG1sOnNwYWNlPSJwcmVzZXJ2ZSIKICAgICAgIHN0eWxlPSJmb250LXNpemU6MzJw eDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0OmJv bGQ7Zm9udC1zdHJldGNoOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O2xpbmUtaGVpZ2h0OjEy NSU7bGV0dGVyLXNwYWNpbmc6MHB4O3dvcmQtc3BhY2luZzowcHg7d3JpdGluZy1tb2RlOmxy LXRiO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6IzAwNDEwMDtmaWxsLW9wYWNpdHk6MTtzdHJv a2U6bm9uZTtmb250LWZhbWlseTpQbGFudGFnZW5ldCBDaGVyb2tlZTstaW5rc2NhcGUtZm9u dC1zcGVjaWZpY2F0aW9uOlBsYW50YWdlbmV0IENoZXJva2VlIEJvbGQiCiAgICAgICB4PSI5 My44MDQ4OTMiCiAgICAgICB5PSIxMzUuNzE1MjMiCiAgICAgICBpZD0idGV4dDEwMTc0Igog ICAgICAgc29kaXBvZGk6bGluZXNwYWNpbmc9IjEyNSUiPjx0c3BhbgogICAgICAgICBzb2Rp cG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBpZD0idHNwYW4xMDE3NiIKICAgICAgICAgeD0i OTMuODA0ODkzIgogICAgICAgICB5PSIxMzUuNzE1MjMiPlJlc3VsdHM8L3RzcGFuPjx0c3Bh bgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICB4PSI5My44MDQ4OTMi CiAgICAgICAgIHk9IjE3NS43MTUyMyIKICAgICAgICAgaWQ9InRzcGFuMTAxNzgiPlZpZXdl cjwvdHNwYW4+PC90ZXh0PgogICAgPHRleHQKICAgICAgIHhtbDpzcGFjZT0icHJlc2VydmUi CiAgICAgICBzdHlsZT0iZm9udC1zaXplOjMycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12 YXJpYW50Om5vcm1hbDtmb250LXdlaWdodDpib2xkO2ZvbnQtc3RyZXRjaDpub3JtYWw7dGV4 dC1hbGlnbjpjZW50ZXI7bGluZS1oZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29y ZC1zcGFjaW5nOjBweDt3cml0aW5nLW1vZGU6bHItdGI7dGV4dC1hbmNob3I6bWlkZGxlO2Zp bGw6IzAwM2YwMDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpQbGFu dGFnZW5ldCBDaGVyb2tlZTstaW5rc2NhcGUtZm9udC1zcGVjaWZpY2F0aW9uOlBsYW50YWdl bmV0IENoZXJva2VlIEJvbGQiCiAgICAgICB4PSIxNDMuODk5NjMiCiAgICAgICB5PSIzMTEu NjUyNCIKICAgICAgIGlkPSJ0ZXh0MTAxODAiCiAgICAgICBzb2RpcG9kaTpsaW5lc3BhY2lu Zz0iMTI1JSI+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAgICAgICAg IGlkPSJ0c3BhbjEwMTgyIgogICAgICAgICB4PSIxNDMuODk5NjMiCiAgICAgICAgIHk9IjMx MS42NTI0Ij5Db250cm9sbGVyPC90c3Bhbj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9s ZT0ibGluZSIKICAgICAgICAgeD0iMTQzLjg5OTYzIgogICAgICAgICB5PSIzNTEuNjUyNCIK ICAgICAgICAgaWQ9InRzcGFuMTAxODQiPkZyb250LUVuZDwvdHNwYW4+PC90ZXh0PgogICAg PHRleHQKICAgICAgIHhtbDpzcGFjZT0icHJlc2VydmUiCiAgICAgICBzdHlsZT0iZm9udC1z aXplOjI4cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdl aWdodDpib2xkO2ZvbnQtc3RyZXRjaDpub3JtYWw7dGV4dC1hbGlnbjpjZW50ZXI7bGluZS1o ZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29yZC1zcGFjaW5nOjBweDt3cml0aW5n LW1vZGU6bHItdGI7dGV4dC1hbmNob3I6bWlkZGxlO2ZpbGw6IzQxMDAwMDtmaWxsLW9wYWNp dHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpQbGFudGFnZW5ldCBDaGVyb2tlZTstaW5r c2NhcGUtZm9udC1zcGVjaWZpY2F0aW9uOlBsYW50YWdlbmV0IENoZXJva2VlIEJvbGQiCiAg ICAgICB4PSI2MTkuNjI0NTciCiAgICAgICB5PSIxMzYuOTQzNzQiCiAgICAgICBpZD0idGV4 dDEwMTg2IgogICAgICAgc29kaXBvZGk6bGluZXNwYWNpbmc9IjEyNSUiPjx0c3BhbgogICAg ICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBpZD0idHNwYW4xMDE4OCIKICAg ICAgICAgeD0iNjE5LjYyNDU3IgogICAgICAgICB5PSIxMzYuOTQzNzQiPlJlc3VsdHM8L3Rz cGFuPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICB4PSI2 MTkuNjI0NTciCiAgICAgICAgIHk9IjE3MS45NDM3NCIKICAgICAgICAgaWQ9InRzcGFuMTAx OTAiPkRhdGFzdG9yZTwvdHNwYW4+PC90ZXh0PgogICAgPHRleHQKICAgICAgIHhtbDpzcGFj ZT0icHJlc2VydmUiCiAgICAgICBzdHlsZT0iZm9udC1zaXplOjI4cHg7Zm9udC1zdHlsZTpu b3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdlaWdodDpib2xkO2ZvbnQtc3RyZXRj aDpub3JtYWw7dGV4dC1hbGlnbjpjZW50ZXI7bGluZS1oZWlnaHQ6MTI1JTtsZXR0ZXItc3Bh Y2luZzowcHg7d29yZC1zcGFjaW5nOjBweDt3cml0aW5nLW1vZGU6bHI7dGV4dC1hbmNob3I6 bWlkZGxlO2ZpbGw6IzAwMDA4MjtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZh bWlseTpQbGFudGFnZW5ldCBDaGVyb2tlZTstaW5rc2NhcGUtZm9udC1zcGVjaWZpY2F0aW9u OlBsYW50YWdlbmV0IENoZXJva2VlIEJvbGQiCiAgICAgICB4PSIzODMuNjY1MTMiCiAgICAg ICB5PSIzMzEuNzUwMDYiCiAgICAgICBpZD0idGV4dDEwMTkyIgogICAgICAgc29kaXBvZGk6 bGluZXNwYWNpbmc9IjEyNSUiPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5l IgogICAgICAgICBpZD0idHNwYW4xMDE5NCIKICAgICAgICAgeD0iMzgzLjY2NTEzIgogICAg ICAgICB5PSIzMzEuNzUwMDYiPkNvbnRyb2xsZXI8L3RzcGFuPjwvdGV4dD4KICAgIDx0ZXh0 CiAgICAgICB4bWw6c3BhY2U9InByZXNlcnZlIgogICAgICAgc3R5bGU9ImZvbnQtc2l6ZToz MnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6 Ym9sZDtmb250LXN0cmV0Y2g6bm9ybWFsO3RleHQtYWxpZ246Y2VudGVyO2xpbmUtaGVpZ2h0 OjEyNSU7bGV0dGVyLXNwYWNpbmc6MHB4O3dvcmQtc3BhY2luZzowcHg7d3JpdGluZy1tb2Rl OmxyLXRiO3RleHQtYW5jaG9yOm1pZGRsZTtmaWxsOiM0MTAwMDA7ZmlsbC1vcGFjaXR5OjE7 c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6UGxhbnRhZ2VuZXQgQ2hlcm9rZWU7LWlua3NjYXBl LWZvbnQtc3BlY2lmaWNhdGlvbjpQbGFudGFnZW5ldCBDaGVyb2tlZSBCb2xkIgogICAgICAg eD0iNjE5LjA1Njg4IgogICAgICAgeT0iNTAzLjMxMTc3IgogICAgICAgaWQ9InRleHQxMDE5 NiIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIxMjUlIj48dHNwYW4KICAgICAgICAg c29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAgICAgaWQ9InRzcGFuMTAxOTgiCiAgICAgICAg IHg9IjYxOS4wNTY4OCIKICAgICAgICAgeT0iNTAzLjMxMTc3Ij5FdmFsdWF0b3I8L3RzcGFu PjwvdGV4dD4KICAgIDx0ZXh0CiAgICAgICB4bWw6c3BhY2U9InByZXNlcnZlIgogICAgICAg c3R5bGU9ImZvbnQtc2l6ZTozMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpu b3JtYWw7Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0cmV0Y2g6bm9ybWFsO3RleHQtYWxpZ246 Y2VudGVyO2xpbmUtaGVpZ2h0OjEyNSU7bGV0dGVyLXNwYWNpbmc6MHB4O3dvcmQtc3BhY2lu ZzowcHg7d3JpdGluZy1tb2RlOmxyLXRiO3RleHQtYW5jaG9yOm1pZGRsZTtmaWxsOiM0ODAw MDA7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6UGxhbnRhZ2VuZXQg Q2hlcm9rZWU7LWlua3NjYXBlLWZvbnQtc3BlY2lmaWNhdGlvbjpQbGFudGFnZW5ldCBDaGVy b2tlZSBCb2xkIgogICAgICAgeD0iNjE4Ljg1MDM0IgogICAgICAgeT0iNjU1LjQzNzA3Igog ICAgICAgaWQ9InRleHQxMDIwMCIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIxMjUl Ij48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAgICAgaWQ9InRz cGFuMTAyMDIiCiAgICAgICAgIHg9IjYxOC44NTAzNCIKICAgICAgICAgeT0iNjU1LjQzNzA3 Ij5EYXRhPC90c3Bhbj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAg ICAgICAgeD0iNjE4Ljg1MDM0IgogICAgICAgICB5PSI2OTUuNDM3MDciCiAgICAgICAgIGlk PSJ0c3BhbjEwMjA0Ij5Db2xsZWN0b3I8L3RzcGFuPjwvdGV4dD4KICA8L2c+Cjwvc3ZnPgo= --------------010902070800010109090005 Content-Type: image/svg+xml; name="BasicGroupedEntities.svg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="BasicGroupedEntities.svg" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+ CjwhLS0gQ3JlYXRlZCB3aXRoIElua3NjYXBlIChodHRwOi8vd3d3Lmlua3NjYXBlLm9yZy8p IC0tPgoKPHN2ZwogICB4bWxuczpvc2I9Imh0dHA6Ly93d3cub3BlbnN3YXRjaGJvb2sub3Jn L3VyaS8yMDA5L29zYiIKICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50 cy8xLjEvIgogICB4bWxuczpjYz0iaHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbnMjIgog ICB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1u cyMiCiAgIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciCiAgIHhtbG5z PSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIKICAgeG1sbnM6eGxpbms9Imh0dHA6Ly93 d3cudzMub3JnLzE5OTkveGxpbmsiCiAgIHhtbG5zOnNvZGlwb2RpPSJodHRwOi8vc29kaXBv ZGkuc291cmNlZm9yZ2UubmV0L0RURC9zb2RpcG9kaS0wLmR0ZCIKICAgeG1sbnM6aW5rc2Nh cGU9Imh0dHA6Ly93d3cuaW5rc2NhcGUub3JnL25hbWVzcGFjZXMvaW5rc2NhcGUiCiAgIHdp ZHRoPSI3NDQuMDk0NDg4MTkiCiAgIGhlaWdodD0iMTA1Mi4zNjIyMDQ3IgogICBpZD0ic3Zn MiIKICAgdmVyc2lvbj0iMS4xIgogICBpbmtzY2FwZTp2ZXJzaW9uPSIwLjQ4LjQgcjk5Mzki CiAgIHNvZGlwb2RpOmRvY25hbWU9IkJhc2ljR3JvdXBlZEVudGl0aWVzLnN2ZyI+CiAgPGRl ZnMKICAgICBpZD0iZGVmczQiPgogICAgPG1hcmtlcgogICAgICAgaW5rc2NhcGU6c3RvY2tp ZD0iVGFpbCIKICAgICAgIG9yaWVudD0iYXV0byIKICAgICAgIHJlZlk9IjAuMCIKICAgICAg IHJlZlg9IjAuMCIKICAgICAgIGlkPSJUYWlsIgogICAgICAgc3R5bGU9Im92ZXJmbG93OnZp c2libGUiPgogICAgICA8ZwogICAgICAgICBpZD0iZzU2NDQiCiAgICAgICAgIHRyYW5zZm9y bT0ic2NhbGUoLTEuMikiPgogICAgICAgIDxwYXRoCiAgICAgICAgICAgaWQ9InBhdGg1NjQ2 IgogICAgICAgICAgIGQ9Ik0gLTMuODA0ODY3NCwtMy45NTg1MjI3IEwgMC41NDM1MjA5NCww IgogICAgICAgICAgIHN0eWxlPSJmaWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tl OiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjAuODtzdHJva2UtbGluZWNhcDpyb3VuZCIgLz4KICAg ICAgICA8cGF0aAogICAgICAgICAgIGlkPSJwYXRoNTY0OCIKICAgICAgICAgICBkPSJNIC0x LjI4NjY4MzIsLTMuOTU4NTIyNyBMIDMuMDYxNzA1MywwIgogICAgICAgICAgIHN0eWxlPSJm aWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRo OjAuODtzdHJva2UtbGluZWNhcDpyb3VuZCIgLz4KICAgICAgICA8cGF0aAogICAgICAgICAg IGlkPSJwYXRoNTY1MCIKICAgICAgICAgICBkPSJNIDEuMzA1MzU4MiwtMy45NTg1MjI3IEwg NS42NTM3NDY2LDAiCiAgICAgICAgICAgc3R5bGU9ImZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZl bm9kZDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MC44O3N0cm9rZS1saW5lY2FwOnJv dW5kIiAvPgogICAgICAgIDxwYXRoCiAgICAgICAgICAgaWQ9InBhdGg1NjUyIgogICAgICAg ICAgIGQ9Ik0gLTMuODA0ODY3NCw0LjE3NzU4MzggTCAwLjU0MzUyMDk0LDAuMjE5NzQyMjYi CiAgICAgICAgICAgc3R5bGU9ImZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6 IzAwMDAwMDtzdHJva2Utd2lkdGg6MC44O3N0cm9rZS1saW5lY2FwOnJvdW5kIiAvPgogICAg ICAgIDxwYXRoCiAgICAgICAgICAgaWQ9InBhdGg1NjU0IgogICAgICAgICAgIGQ9Ik0gLTEu Mjg2NjgzMiw0LjE3NzU4MzggTCAzLjA2MTcwNTMsMC4yMTk3NDIyNiIKICAgICAgICAgICBz dHlsZT0iZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojMDAwMDAwO3N0cm9r ZS13aWR0aDowLjg7c3Ryb2tlLWxpbmVjYXA6cm91bmQiIC8+CiAgICAgICAgPHBhdGgKICAg ICAgICAgICBpZD0icGF0aDU2NTYiCiAgICAgICAgICAgZD0iTSAxLjMwNTM1ODIsNC4xNzc1 ODM4IEwgNS42NTM3NDY2LDAuMjE5NzQyMjYiCiAgICAgICAgICAgc3R5bGU9ImZpbGw6bm9u ZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MC44O3N0 cm9rZS1saW5lY2FwOnJvdW5kIiAvPgogICAgICA8L2c+CiAgICA8L21hcmtlcj4KICAgIDxt YXJrZXIKICAgICAgIGlua3NjYXBlOnN0b2NraWQ9IkFycm93MkxlbmQiCiAgICAgICBvcmll bnQ9ImF1dG8iCiAgICAgICByZWZZPSIwLjAiCiAgICAgICByZWZYPSIwLjAiCiAgICAgICBp ZD0iQXJyb3cyTGVuZCIKICAgICAgIHN0eWxlPSJvdmVyZmxvdzp2aXNpYmxlOyI+CiAgICAg IDxwYXRoCiAgICAgICAgIGlkPSJwYXRoNTYyOSIKICAgICAgICAgc3R5bGU9ImZpbGwtcnVs ZTpldmVub2RkO3N0cm9rZS13aWR0aDowLjYyNTAwMDAwO3N0cm9rZS1saW5lam9pbjpyb3Vu ZDsiCiAgICAgICAgIGQ9Ik0gOC43MTg1ODc4LDQuMDMzNzM1MiBMIC0yLjIwNzI4OTUsMC4w MTYwMTMyNTYgTCA4LjcxODU4ODQsLTQuMDAxNzA3OCBDIDYuOTczMDkwMCwtMS42Mjk2NDY5 IDYuOTgzMTQ3NiwxLjYxNTc0NDEgOC43MTg1ODc4LDQuMDMzNzM1MiB6ICIKICAgICAgICAg dHJhbnNmb3JtPSJzY2FsZSgxLjEpIHJvdGF0ZSgxODApIHRyYW5zbGF0ZSgxLDApIiAvPgog ICAgPC9tYXJrZXI+CiAgICA8bWFya2VyCiAgICAgICBpbmtzY2FwZTpzdG9ja2lkPSJBcnJv dzJMc3RhcnQiCiAgICAgICBvcmllbnQ9ImF1dG8iCiAgICAgICByZWZZPSIwLjAiCiAgICAg ICByZWZYPSIwLjAiCiAgICAgICBpZD0iQXJyb3cyTHN0YXJ0IgogICAgICAgc3R5bGU9Im92 ZXJmbG93OnZpc2libGUiPgogICAgICA8cGF0aAogICAgICAgICBpZD0icGF0aDU2MjYiCiAg ICAgICAgIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2Utd2lkdGg6MC42MjUwMDAw MDtzdHJva2UtbGluZWpvaW46cm91bmQiCiAgICAgICAgIGQ9Ik0gOC43MTg1ODc4LDQuMDMz NzM1MiBMIC0yLjIwNzI4OTUsMC4wMTYwMTMyNTYgTCA4LjcxODU4ODQsLTQuMDAxNzA3OCBD IDYuOTczMDkwMCwtMS42Mjk2NDY5IDYuOTgzMTQ3NiwxLjYxNTc0NDEgOC43MTg1ODc4LDQu MDMzNzM1MiB6ICIKICAgICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjEpIHRyYW5zbGF0ZSgx LDApIiAvPgogICAgPC9tYXJrZXI+CiAgICA8bWFya2VyCiAgICAgICBpbmtzY2FwZTpzdG9j a2lkPSJBcnJvdzFMZW5kIgogICAgICAgb3JpZW50PSJhdXRvIgogICAgICAgcmVmWT0iMC4w IgogICAgICAgcmVmWD0iMC4wIgogICAgICAgaWQ9IkFycm93MUxlbmQiCiAgICAgICBzdHls ZT0ib3ZlcmZsb3c6dmlzaWJsZTsiPgogICAgICA8cGF0aAogICAgICAgICBpZD0icGF0aDU2 MTEiCiAgICAgICAgIGQ9Ik0gMC4wLDAuMCBMIDUuMCwtNS4wIEwgLTEyLjUsMC4wIEwgNS4w LDUuMCBMIDAuMCwwLjAgeiAiCiAgICAgICAgIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtz dHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MS4wcHQ7IgogICAgICAgICB0cmFuc2Zvcm09 InNjYWxlKDAuOCkgcm90YXRlKDE4MCkgdHJhbnNsYXRlKDEyLjUsMCkiIC8+CiAgICA8L21h cmtlcj4KICAgIDxtYXJrZXIKICAgICAgIGlua3NjYXBlOnN0b2NraWQ9IkFycm93MU1zdGFy dCIKICAgICAgIG9yaWVudD0iYXV0byIKICAgICAgIHJlZlk9IjAuMCIKICAgICAgIHJlZlg9 IjAuMCIKICAgICAgIGlkPSJBcnJvdzFNc3RhcnQiCiAgICAgICBzdHlsZT0ib3ZlcmZsb3c6 dmlzaWJsZSI+CiAgICAgIDxwYXRoCiAgICAgICAgIGlkPSJwYXRoNTYxNCIKICAgICAgICAg ZD0iTSAwLjAsMC4wIEwgNS4wLC01LjAgTCAtMTIuNSwwLjAgTCA1LjAsNS4wIEwgMC4wLDAu MCB6ICIKICAgICAgICAgc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojMDAwMDAw O3N0cm9rZS13aWR0aDoxLjBwdCIKICAgICAgICAgdHJhbnNmb3JtPSJzY2FsZSgwLjQpIHRy YW5zbGF0ZSgxMCwwKSIgLz4KICAgIDwvbWFya2VyPgogICAgPG1hcmtlcgogICAgICAgaW5r c2NhcGU6c3RvY2tpZD0iQXJyb3cxTWVuZCIKICAgICAgIG9yaWVudD0iYXV0byIKICAgICAg IHJlZlk9IjAuMCIKICAgICAgIHJlZlg9IjAuMCIKICAgICAgIGlkPSJBcnJvdzFNZW5kIgog ICAgICAgc3R5bGU9Im92ZXJmbG93OnZpc2libGU7Ij4KICAgICAgPHBhdGgKICAgICAgICAg aWQ9InBhdGg1NjE3IgogICAgICAgICBkPSJNIDAuMCwwLjAgTCA1LjAsLTUuMCBMIC0xMi41 LDAuMCBMIDUuMCw1LjAgTCAwLjAsMC4wIHogIgogICAgICAgICBzdHlsZT0iZmlsbC1ydWxl OmV2ZW5vZGQ7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjEuMHB0OyIKICAgICAgICAg dHJhbnNmb3JtPSJzY2FsZSgwLjQpIHJvdGF0ZSgxODApIHRyYW5zbGF0ZSgxMCwwKSIgLz4K ICAgIDwvbWFya2VyPgogICAgPG1hcmtlcgogICAgICAgaW5rc2NhcGU6c3RvY2tpZD0iQXJy b3cxU3N0YXJ0IgogICAgICAgb3JpZW50PSJhdXRvIgogICAgICAgcmVmWT0iMC4wIgogICAg ICAgcmVmWD0iMC4wIgogICAgICAgaWQ9IkFycm93MVNzdGFydCIKICAgICAgIHN0eWxlPSJv dmVyZmxvdzp2aXNpYmxlIj4KICAgICAgPHBhdGgKICAgICAgICAgaWQ9InBhdGg1NjIwIgog ICAgICAgICBkPSJNIDAuMCwwLjAgTCA1LjAsLTUuMCBMIC0xMi41LDAuMCBMIDUuMCw1LjAg TCAwLjAsMC4wIHogIgogICAgICAgICBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tl OiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjEuMHB0IgogICAgICAgICB0cmFuc2Zvcm09InNjYWxl KDAuMikgdHJhbnNsYXRlKDYsMCkiIC8+CiAgICA8L21hcmtlcj4KICAgIDxtYXJrZXIKICAg ICAgIGlua3NjYXBlOnN0b2NraWQ9IkFycm93MUxzdGFydCIKICAgICAgIG9yaWVudD0iYXV0 byIKICAgICAgIHJlZlk9IjAuMCIKICAgICAgIHJlZlg9IjAuMCIKICAgICAgIGlkPSJBcnJv dzFMc3RhcnQiCiAgICAgICBzdHlsZT0ib3ZlcmZsb3c6dmlzaWJsZSI+CiAgICAgIDxwYXRo CiAgICAgICAgIGlkPSJwYXRoNTYwOCIKICAgICAgICAgZD0iTSAwLjAsMC4wIEwgNS4wLC01 LjAgTCAtMTIuNSwwLjAgTCA1LjAsNS4wIEwgMC4wLDAuMCB6ICIKICAgICAgICAgc3R5bGU9 ImZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDoxLjBwdCIK ICAgICAgICAgdHJhbnNmb3JtPSJzY2FsZSgwLjgpIHRyYW5zbGF0ZSgxMi41LDApIiAvPgog ICAgPC9tYXJrZXI+CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAgIGlkPSJsaW5lYXJHcmFk aWVudDU0NDMiCiAgICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAgPHN0b3AKICAgICAg ICAgc3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6MTsiCiAgICAgICAg IG9mZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1IiAvPgogICAgPC9saW5lYXJHcmFk aWVudD4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTI1 NyIKICAgICAgIG9zYjpwYWludD0ic29saWQiPgogICAgICA8c3RvcAogICAgICAgICBzdHls ZT0ic3RvcC1jb2xvcjojMDAwMGZmO3N0b3Atb3BhY2l0eTowLjM0MzkxNTM0OyIKICAgICAg ICAgb2Zmc2V0PSIwIgogICAgICAgICBpZD0ic3RvcDUyNTkiIC8+CiAgICA8L2xpbmVhckdy YWRpZW50PgogICAgPGlua3NjYXBlOnBlcnNwZWN0aXZlCiAgICAgICBzb2RpcG9kaTp0eXBl PSJpbmtzY2FwZTpwZXJzcDNkIgogICAgICAgaW5rc2NhcGU6dnBfeD0iMCA6IDUyNi4xODEw OSA6IDEiCiAgICAgICBpbmtzY2FwZTp2cF95PSIwIDogMTAwMCA6IDAiCiAgICAgICBpbmtz Y2FwZTp2cF96PSI3NDQuMDk0NDggOiA1MjYuMTgxMDkgOiAxIgogICAgICAgaW5rc2NhcGU6 cGVyc3AzZC1vcmlnaW49IjM3Mi4wNDcyNCA6IDM1MC43ODczOSA6IDEiCiAgICAgICBpZD0i cGVyc3BlY3RpdmUyOTk1IiAvPgogICAgPGxpbmVhckdyYWRpZW50CiAgICAgICBpbmtzY2Fw ZTpjb2xsZWN0PSJhbHdheXMiCiAgICAgICB4bGluazpocmVmPSIjbGluZWFyR3JhZGllbnQ1 NDQzIgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ1MSIKICAgICAgIHgxPSI3Ni43OTE5 MDEiCiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAgeDI9IjIzMi4zMTQ3NyIKICAgICAg IHkyPSIxODEuMTA1NjIiCiAgICAgICBncmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIK ICAgICAgIGdyYWRpZW50VHJhbnNmb3JtPSJ0cmFuc2xhdGUoLTEwLjAyMDkxNSwxMzkuNTU0 NjEpIiAvPgogICAgPGZpbHRlcgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgog ICAgICAgaWQ9ImZpbHRlcjU0NzMiCiAgICAgICB4PSItMC4xMDA0IgogICAgICAgd2lkdGg9 IjEuMjAwOCIKICAgICAgIHk9Ii0wLjE0OTEwODkiCiAgICAgICBoZWlnaHQ9IjEuMjk4MjE3 OCI+CiAgICAgIDxmZUdhdXNzaWFuQmx1cgogICAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJh bHdheXMiCiAgICAgICAgIHN0ZERldmlhdGlvbj0iNi4zMzg3MDcyIgogICAgICAgICBpZD0i ZmVHYXVzc2lhbkJsdXI1NDc1IiAvPgogICAgPC9maWx0ZXI+CiAgICA8bGluZWFyR3JhZGll bnQKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIKICAgICAgIHhsaW5rOmhyZWY9 IiNsaW5lYXJHcmFkaWVudDU0NDMtMiIKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVudDU0NTEt NSIKICAgICAgIHgxPSI3Ni43OTE5MDEiCiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAg eDI9IjIzMi4zMTQ3NyIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICBncmFkaWVudFVu aXRzPSJ1c2VyU3BhY2VPblVzZSIgLz4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgaWQ9 ImxpbmVhckdyYWRpZW50NTQ0My0yIgogICAgICAgb3NiOnBhaW50PSJzb2xpZCI+CiAgICAg IDxzdG9wCiAgICAgICAgIHN0eWxlPSJzdG9wLWNvbG9yOiNiM2NjZjg7c3RvcC1vcGFjaXR5 OjE7IgogICAgICAgICBvZmZzZXQ9IjAiCiAgICAgICAgIGlkPSJzdG9wNTQ0NS0zIiAvPgog ICAgPC9saW5lYXJHcmFkaWVudD4KICAgIDxmaWx0ZXIKICAgICAgIGNvbG9yLWludGVycG9s YXRpb24tZmlsdGVycz0ic1JHQiIKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIK ICAgICAgIGlkPSJmaWx0ZXI1NDczLTEiCiAgICAgICB4PSItMC4xMDA0IgogICAgICAgd2lk dGg9IjEuMjAwNzk5OSIKICAgICAgIHk9Ii0wLjE0OTEwODkiCiAgICAgICBoZWlnaHQ9IjEu Mjk4MjE3OCI+CiAgICAgIDxmZUdhdXNzaWFuQmx1cgogICAgICAgICBpbmtzY2FwZTpjb2xs ZWN0PSJhbHdheXMiCiAgICAgICAgIHN0ZERldmlhdGlvbj0iNi4zMzg3MDcyIgogICAgICAg ICBpZD0iZmVHYXVzc2lhbkJsdXI1NDc1LTYiIC8+CiAgICA8L2ZpbHRlcj4KICAgIDxsaW5l YXJHcmFkaWVudAogICAgICAgZ3JhZGllbnRUcmFuc2Zvcm09InRyYW5zbGF0ZSg0NjUuMTA0 MiwtMzYuMzY1NDg0KSIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICB4Mj0iMjMyLjMx NDc3IgogICAgICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgxPSI3Ni43OTE5MDEiCiAgICAg ICBncmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIKICAgICAgIGlkPSJsaW5lYXJHcmFk aWVudDU0OTMiCiAgICAgICB4bGluazpocmVmPSIjbGluZWFyR3JhZGllbnQ1NDQzLTIiCiAg ICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiIC8+CiAgICA8bGluZWFyR3JhZGllbnQK ICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIKICAgICAgIHhsaW5rOmhyZWY9IiNs aW5lYXJHcmFkaWVudDU0NDMtMjciCiAgICAgICBpZD0ibGluZWFyR3JhZGllbnQ1NDUxLTgi CiAgICAgICB4MT0iNzYuNzkxOTAxIgogICAgICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgy PSIyMzIuMzE0NzciCiAgICAgICB5Mj0iMTgxLjEwNTYyIgogICAgICAgZ3JhZGllbnRVbml0 cz0idXNlclNwYWNlT25Vc2UiIC8+CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAgIGlkPSJs aW5lYXJHcmFkaWVudDU0NDMtMjciCiAgICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAg PHN0b3AKICAgICAgICAgc3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6 MTsiCiAgICAgICAgIG9mZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1LTciIC8+CiAg ICA8L2xpbmVhckdyYWRpZW50PgogICAgPGZpbHRlcgogICAgICAgY29sb3ItaW50ZXJwb2xh dGlvbi1maWx0ZXJzPSJzUkdCIgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgog ICAgICAgaWQ9ImZpbHRlcjU0NzMtMTIiCiAgICAgICB4PSItMC4xMDA0IgogICAgICAgd2lk dGg9IjEuMjAwNzk5OSIKICAgICAgIHk9Ii0wLjE0OTEwODkiCiAgICAgICBoZWlnaHQ9IjEu Mjk4MjE3OCI+CiAgICAgIDxmZUdhdXNzaWFuQmx1cgogICAgICAgICBpbmtzY2FwZTpjb2xs ZWN0PSJhbHdheXMiCiAgICAgICAgIHN0ZERldmlhdGlvbj0iNi4zMzg3MDcyIgogICAgICAg ICBpZD0iZmVHYXVzc2lhbkJsdXI1NDc1LTYwIiAvPgogICAgPC9maWx0ZXI+CiAgICA8bGlu ZWFyR3JhZGllbnQKICAgICAgIGdyYWRpZW50VHJhbnNmb3JtPSJ0cmFuc2xhdGUoLTEwLjAy MDkyOCwtMzYuMzY1NTA2KSIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICB4Mj0iMjMy LjMxNDc3IgogICAgICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgxPSI3Ni43OTE5MDEiCiAg ICAgICBncmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIKICAgICAgIGlkPSJsaW5lYXJH cmFkaWVudDU0OTMtNCIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMt MjciCiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiIC8+CiAgICA8bGluZWFyR3Jh ZGllbnQKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIKICAgICAgIHhsaW5rOmhy ZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMtNiIKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVudDU0 NTEtNCIKICAgICAgIHgxPSI3Ni43OTE5MDEiCiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAg ICAgeDI9IjIzMi4zMTQ3NyIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICBncmFkaWVu dFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIgLz4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAg aWQ9ImxpbmVhckdyYWRpZW50NTQ0My02IgogICAgICAgb3NiOnBhaW50PSJzb2xpZCI+CiAg ICAgIDxzdG9wCiAgICAgICAgIHN0eWxlPSJzdG9wLWNvbG9yOiNiM2NjZjg7c3RvcC1vcGFj aXR5OjE7IgogICAgICAgICBvZmZzZXQ9IjAiCiAgICAgICAgIGlkPSJzdG9wNTQ0NS0wIiAv PgogICAgPC9saW5lYXJHcmFkaWVudD4KICAgIDxmaWx0ZXIKICAgICAgIGNvbG9yLWludGVy cG9sYXRpb24tZmlsdGVycz0ic1JHQiIKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5 cyIKICAgICAgIGlkPSJmaWx0ZXI1NDczLTMiCiAgICAgICB4PSItMC4xMDA0IgogICAgICAg d2lkdGg9IjEuMjAwNzk5OSIKICAgICAgIHk9Ii0wLjE0OTEwODkiCiAgICAgICBoZWlnaHQ9 IjEuMjk4MjE3OCI+CiAgICAgIDxmZUdhdXNzaWFuQmx1cgogICAgICAgICBpbmtzY2FwZTpj b2xsZWN0PSJhbHdheXMiCiAgICAgICAgIHN0ZERldmlhdGlvbj0iNi4zMzg3MDcyIgogICAg ICAgICBpZD0iZmVHYXVzc2lhbkJsdXI1NDc1LTYyIiAvPgogICAgPC9maWx0ZXI+CiAgICA8 bGluZWFyR3JhZGllbnQKICAgICAgIGdyYWRpZW50VHJhbnNmb3JtPSJ0cmFuc2xhdGUoNDY1 LjEwNDE2LDQ4My41ODY0NCkiCiAgICAgICB5Mj0iMTgxLjEwNTYyIgogICAgICAgeDI9IjIz Mi4zMTQ3NyIKICAgICAgIHkxPSIxODEuMTA1NjIiCiAgICAgICB4MT0iNzYuNzkxOTAxIgog ICAgICAgZ3JhZGllbnRVbml0cz0idXNlclNwYWNlT25Vc2UiCiAgICAgICBpZD0ibGluZWFy R3JhZGllbnQ1NDkzLTQ1IgogICAgICAgeGxpbms6aHJlZj0iI2xpbmVhckdyYWRpZW50NTQ0 My02IgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIiAvPgogICAgPGxpbmVhckdy YWRpZW50CiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiCiAgICAgICB4bGluazpo cmVmPSIjbGluZWFyR3JhZGllbnQ1NDQzLTIxIgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50 NTQ1MS0xIgogICAgICAgeDE9Ijc2Ljc5MTkwMSIKICAgICAgIHkxPSIxODEuMTA1NjIiCiAg ICAgICB4Mj0iMjMyLjMxNDc3IgogICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIGdyYWRp ZW50VW5pdHM9InVzZXJTcGFjZU9uVXNlIiAvPgogICAgPGxpbmVhckdyYWRpZW50CiAgICAg ICBpZD0ibGluZWFyR3JhZGllbnQ1NDQzLTIxIgogICAgICAgb3NiOnBhaW50PSJzb2xpZCI+ CiAgICAgIDxzdG9wCiAgICAgICAgIHN0eWxlPSJzdG9wLWNvbG9yOiNiM2NjZjg7c3RvcC1v cGFjaXR5OjE7IgogICAgICAgICBvZmZzZXQ9IjAiCiAgICAgICAgIGlkPSJzdG9wNTQ0NS00 IiAvPgogICAgPC9saW5lYXJHcmFkaWVudD4KICAgIDxmaWx0ZXIKICAgICAgIGNvbG9yLWlu dGVycG9sYXRpb24tZmlsdGVycz0ic1JHQiIKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFs d2F5cyIKICAgICAgIGlkPSJmaWx0ZXI1NDczLTkiCiAgICAgICB4PSItMC4xMDA0IgogICAg ICAgd2lkdGg9IjEuMjAwNzk5OSIKICAgICAgIHk9Ii0wLjE0OTEwODkiCiAgICAgICBoZWln aHQ9IjEuMjk4MjE3OCI+CiAgICAgIDxmZUdhdXNzaWFuQmx1cgogICAgICAgICBpbmtzY2Fw ZTpjb2xsZWN0PSJhbHdheXMiCiAgICAgICAgIHN0ZERldmlhdGlvbj0iNi4zMzg3MDcyIgog ICAgICAgICBpZD0iZmVHYXVzc2lhbkJsdXI1NDc1LTgiIC8+CiAgICA8L2ZpbHRlcj4KICAg IDxsaW5lYXJHcmFkaWVudAogICAgICAgZ3JhZGllbnRUcmFuc2Zvcm09InRyYW5zbGF0ZSgy MjkuOTE4ODgsMTM5LjU1NDYyKSIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICB4Mj0i MjMyLjMxNDc3IgogICAgICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgxPSI3Ni43OTE5MDEi CiAgICAgICBncmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIKICAgICAgIGlkPSJsaW5l YXJHcmFkaWVudDU0OTMtMiIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0 NDMtMjEiCiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiIC8+CiAgICA8bGluZWFy R3JhZGllbnQKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIKICAgICAgIHhsaW5r OmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMtOSIKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVu dDU0NTEtNTIiCiAgICAgICB4MT0iNzYuNzkxOTAxIgogICAgICAgeTE9IjE4MS4xMDU2MiIK ICAgICAgIHgyPSIyMzIuMzE0NzciCiAgICAgICB5Mj0iMTgxLjEwNTYyIgogICAgICAgZ3Jh ZGllbnRVbml0cz0idXNlclNwYWNlT25Vc2UiIC8+CiAgICA8bGluZWFyR3JhZGllbnQKICAg ICAgIGlkPSJsaW5lYXJHcmFkaWVudDU0NDMtOSIKICAgICAgIG9zYjpwYWludD0ic29saWQi PgogICAgICA8c3RvcAogICAgICAgICBzdHlsZT0ic3RvcC1jb2xvcjojYjNjY2Y4O3N0b3At b3BhY2l0eToxOyIKICAgICAgICAgb2Zmc2V0PSIwIgogICAgICAgICBpZD0ic3RvcDU0NDUt OSIgLz4KICAgIDwvbGluZWFyR3JhZGllbnQ+CiAgICA8ZmlsdGVyCiAgICAgICBjb2xvci1p bnRlcnBvbGF0aW9uLWZpbHRlcnM9InNSR0IiCiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJh bHdheXMiCiAgICAgICBpZD0iZmlsdGVyNTQ3My04IgogICAgICAgeD0iLTAuMTAwNCIKICAg ICAgIHdpZHRoPSIxLjIwMDc5OTkiCiAgICAgICB5PSItMC4xNDkxMDg5IgogICAgICAgaGVp Z2h0PSIxLjI5ODIxNzgiPgogICAgICA8ZmVHYXVzc2lhbkJsdXIKICAgICAgICAgaW5rc2Nh cGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAgICBzdGREZXZpYXRpb249IjYuMzM4NzA3MiIK ICAgICAgICAgaWQ9ImZlR2F1c3NpYW5CbHVyNTQ3NS0zIiAvPgogICAgPC9maWx0ZXI+CiAg ICA8bGluZWFyR3JhZGllbnQKICAgICAgIGdyYWRpZW50VHJhbnNmb3JtPSJ0cmFuc2xhdGUo NDY1LjEwNDIxLDMxMS4yMzEwNSkiCiAgICAgICB5Mj0iMTgxLjEwNTYyIgogICAgICAgeDI9 IjIzMi4zMTQ3NyIKICAgICAgIHkxPSIxODEuMTA1NjIiCiAgICAgICB4MT0iNzYuNzkxOTAx IgogICAgICAgZ3JhZGllbnRVbml0cz0idXNlclNwYWNlT25Vc2UiCiAgICAgICBpZD0ibGlu ZWFyR3JhZGllbnQ1NDkzLTgiCiAgICAgICB4bGluazpocmVmPSIjbGluZWFyR3JhZGllbnQ1 NDQzLTkiCiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiIC8+CiAgPC9kZWZzPgog IDxzb2RpcG9kaTpuYW1lZHZpZXcKICAgICBpZD0iYmFzZSIKICAgICBwYWdlY29sb3I9IiNm ZmZmZmYiCiAgICAgYm9yZGVyY29sb3I9IiM2NjY2NjYiCiAgICAgYm9yZGVyb3BhY2l0eT0i MS4wIgogICAgIGlua3NjYXBlOnBhZ2VvcGFjaXR5PSIwLjAiCiAgICAgaW5rc2NhcGU6cGFn ZXNoYWRvdz0iMiIKICAgICBpbmtzY2FwZTp6b29tPSIwLjk4OTk0OTQ5IgogICAgIGlua3Nj YXBlOmN4PSIzODUuNDM0ODQiCiAgICAgaW5rc2NhcGU6Y3k9IjY0OS45NjI4NyIKICAgICBp bmtzY2FwZTpkb2N1bWVudC11bml0cz0icHgiCiAgICAgaW5rc2NhcGU6Y3VycmVudC1sYXll cj0ibGF5ZXIxIgogICAgIHNob3dncmlkPSJmYWxzZSIKICAgICBpbmtzY2FwZTp3aW5kb3ct d2lkdGg9IjEyNzkiCiAgICAgaW5rc2NhcGU6d2luZG93LWhlaWdodD0iMTA4MSIKICAgICBp bmtzY2FwZTp3aW5kb3cteD0iMjA2MSIKICAgICBpbmtzY2FwZTp3aW5kb3cteT0iNDAiCiAg ICAgaW5rc2NhcGU6d2luZG93LW1heGltaXplZD0iMCIgLz4KICA8bWV0YWRhdGEKICAgICBp ZD0ibWV0YWRhdGE3Ij4KICAgIDxyZGY6UkRGPgogICAgICA8Y2M6V29yawogICAgICAgICBy ZGY6YWJvdXQ9IiI+CiAgICAgICAgPGRjOmZvcm1hdD5pbWFnZS9zdmcreG1sPC9kYzpmb3Jt YXQ+CiAgICAgICAgPGRjOnR5cGUKICAgICAgICAgICByZGY6cmVzb3VyY2U9Imh0dHA6Ly9w dXJsLm9yZy9kYy9kY21pdHlwZS9TdGlsbEltYWdlIiAvPgogICAgICAgIDxkYzp0aXRsZT48 L2RjOnRpdGxlPgogICAgICA8L2NjOldvcms+CiAgICA8L3JkZjpSREY+CiAgPC9tZXRhZGF0 YT4KICA8ZwogICAgIGlua3NjYXBlOmxhYmVsPSJMYXllciAxIgogICAgIGlua3NjYXBlOmdy b3VwbW9kZT0ibGF5ZXIiCiAgICAgaWQ9ImxheWVyMSI+CiAgICA8cmVjdAogICAgICAgc3R5 bGU9ImZpbGw6dXJsKCNsaW5lYXJHcmFkaWVudDU0NTEpO2ZpbGwtb3BhY2l0eToxO2ZpbGwt cnVsZTpub256ZXJvO3N0cm9rZTojMDMwMDc4O3N0cm9rZS13aWR0aDo0O3N0cm9rZS1saW5l Y2FwOnNxdWFyZTtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6NDtz dHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6bm9uZTtzdHJva2UtZGFzaG9mZnNl dDowO2ZpbHRlcjp1cmwoI2ZpbHRlcjU0NzMpIgogICAgICAgaWQ9InJlY3QzMDE5IgogICAg ICAgd2lkdGg9IjE1MS41MjI4NyIKICAgICAgIGhlaWdodD0iMTAyLjAyNTQxIgogICAgICAg eD0iNjguNzcwOTk2IgogICAgICAgeT0iMjY5LjY0NzUyIiAvPgogICAgPHJlY3QKICAgICAg IHN0eWxlPSJmaWxsOnVybCgjbGluZWFyR3JhZGllbnQ1NDkzLTIpO2ZpbGwtb3BhY2l0eTox O2ZpbGwtcnVsZTpub256ZXJvO3N0cm9rZTojMDMwMDc4O3N0cm9rZS13aWR0aDo0O3N0cm9r ZS1saW5lY2FwOnNxdWFyZTtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1pdGVybGlt aXQ6NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6bm9uZTtzdHJva2UtZGFz aG9mZnNldDowO2ZpbHRlcjp1cmwoI2ZpbHRlcjU0NzMtOSkiCiAgICAgICBpZD0icmVjdDMw MTktNCIKICAgICAgIHdpZHRoPSIxNTEuNTIyODciCiAgICAgICBoZWlnaHQ9IjEwMi4wMjU0 MSIKICAgICAgIHg9IjMwOC43MTA4MiIKICAgICAgIHk9IjI2OS42NDc1MiIgLz4KICAgIDxy ZWN0CiAgICAgICBzdHlsZT0iZmlsbDp1cmwoI2xpbmVhckdyYWRpZW50NTQ5Myk7ZmlsbC1v cGFjaXR5OjE7ZmlsbC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMzAwNzg7c3Ryb2tlLXdpZHRo OjQ7c3Ryb2tlLWxpbmVjYXA6c3F1YXJlO3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Ut bWl0ZXJsaW1pdDo0O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLWRhc2hhcnJheTpub25lO3N0 cm9rZS1kYXNob2Zmc2V0OjA7ZmlsdGVyOnVybCgjZmlsdGVyNTQ3My0xKSIKICAgICAgIGlk PSJyZWN0MzAxOS04IgogICAgICAgd2lkdGg9IjE1MS41MjI4NyIKICAgICAgIGhlaWdodD0i MTAyLjAyNTQxIgogICAgICAgeD0iNTQzLjg5NjA2IgogICAgICAgeT0iOTMuNzI3NDE3IiAv PgogICAgPHJlY3QKICAgICAgIHN0eWxlPSJmaWxsOnVybCgjbGluZWFyR3JhZGllbnQ1NDkz LTQpO2ZpbGwtb3BhY2l0eToxO2ZpbGwtcnVsZTpub256ZXJvO3N0cm9rZTojMDMwMDc4O3N0 cm9rZS13aWR0aDo0O3N0cm9rZS1saW5lY2FwOnNxdWFyZTtzdHJva2UtbGluZWpvaW46bWl0 ZXI7c3Ryb2tlLW1pdGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJy YXk6bm9uZTtzdHJva2UtZGFzaG9mZnNldDowO2ZpbHRlcjp1cmwoI2ZpbHRlcjU0NzMtMTIp IgogICAgICAgaWQ9InJlY3QzMDE5LTkiCiAgICAgICB3aWR0aD0iMTUxLjUyMjg3IgogICAg ICAgaGVpZ2h0PSIxMDIuMDI1NDEiCiAgICAgICB4PSI2OC43NzA5OTYiCiAgICAgICB5PSI5 My43Mjc0MTciIC8+CiAgICA8cmVjdAogICAgICAgc3R5bGU9ImZpbGw6dXJsKCNsaW5lYXJH cmFkaWVudDU0OTMtNDUpO2ZpbGwtb3BhY2l0eToxO2ZpbGwtcnVsZTpub256ZXJvO3N0cm9r ZTojMDMwMDc4O3N0cm9rZS13aWR0aDo0O3N0cm9rZS1saW5lY2FwOnNxdWFyZTtzdHJva2Ut bGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eToxO3N0 cm9rZS1kYXNoYXJyYXk6bm9uZTtzdHJva2UtZGFzaG9mZnNldDowO2ZpbHRlcjp1cmwoI2Zp bHRlcjU0NzMtMykiCiAgICAgICBpZD0icmVjdDMwMTktODgiCiAgICAgICB3aWR0aD0iMTUx LjUyMjg3IgogICAgICAgaGVpZ2h0PSIxMDIuMDI1NDEiCiAgICAgICB4PSI1NDMuODk2MDYi CiAgICAgICB5PSI2MTMuNjc5MjYiIC8+CiAgICA8cmVjdAogICAgICAgc3R5bGU9ImZpbGw6 dXJsKCNsaW5lYXJHcmFkaWVudDU0OTMtOCk7ZmlsbC1vcGFjaXR5OjE7ZmlsbC1ydWxlOm5v bnplcm87c3Ryb2tlOiMwMzAwNzg7c3Ryb2tlLXdpZHRoOjQ7c3Ryb2tlLWxpbmVjYXA6c3F1 YXJlO3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2UtbWl0ZXJsaW1pdDo0O3N0cm9rZS1v cGFjaXR5OjE7c3Ryb2tlLWRhc2hhcnJheTpub25lO3N0cm9rZS1kYXNob2Zmc2V0OjA7Zmls dGVyOnVybCgjZmlsdGVyNTQ3My04KSIKICAgICAgIGlkPSJyZWN0MzAxOS02IgogICAgICAg d2lkdGg9IjE1MS41MjI4NyIKICAgICAgIGhlaWdodD0iMTAyLjAyNTQxIgogICAgICAgeD0i NTQzLjg5NjA2IgogICAgICAgeT0iNDQxLjMyMzk3IiAvPgogICAgPHBhdGgKICAgICAgIHN0 eWxlPSJmaWxsOm5vbmU7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjI7c3Ryb2tlLWxp bmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6NDtz dHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6bm9uZTttYXJrZXItc3RhcnQ6dXJs KCNBcnJvdzFNc3RhcnQpO21hcmtlci1lbmQ6dXJsKCNBcnJvdzFNZW5kKTtkaXNwbGF5Omlu bGluZSIKICAgICAgIGQ9Im0gMjE4LjE5Mjk1LDE0My4yMjQ4OSAzMTkuMjA4MiwxLjAxMDE1 IgogICAgICAgaWQ9InBhdGg1NTkwIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLXR5cGU9 InBvbHlsaW5lIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMyIgLz4K ICAgIDxwYXRoCiAgICAgICBzdHlsZT0iZmlsbDpub25lO3N0cm9rZTojMDAwMDAwO3N0cm9r ZS13aWR0aDoyO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0 cm9rZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtZGFzaGFycmF5Om5v bmU7bWFya2VyLXN0YXJ0OnVybCgjQXJyb3cxTXN0YXJ0KTttYXJrZXItZW5kOnVybCgjQXJy b3cxTWVuZCkiCiAgICAgICBkPSJtIDIyMC4yOTM4NywzMjAuNjYwMjMgODguNDE2OTUsMCIK ICAgICAgIGlkPSJwYXRoNTU5MiIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rvci10eXBlPSJw b2x5bGluZSIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rvci1jdXJ2YXR1cmU9IjMiCiAgICAg ICBpbmtzY2FwZTpjb25uZWN0aW9uLXN0YXJ0PSIjcmVjdDMwMTkiCiAgICAgICBpbmtzY2Fw ZTpjb25uZWN0aW9uLXN0YXJ0LXBvaW50PSJkNCIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rp b24tZW5kPSIjcmVjdDMwMTktNCIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tZW5kLXBv aW50PSJkNCIgLz4KICAgIDxwYXRoCiAgICAgICBzdHlsZT0iZmlsbDpub25lO3N0cm9rZToj MDAwMDAwO3N0cm9rZS13aWR0aDoxcHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGlu ZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MSIKICAgICAgIGQ9Im0gMzg0LjQ3MjI1LDMy MC42NjAyMyAwLDAiCiAgICAgICBpZD0icGF0aDU1OTQiCiAgICAgICBpbmtzY2FwZTpjb25u ZWN0b3ItdHlwZT0icG9seWxpbmUiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItY3VydmF0 dXJlPSIzIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFydD0iI3JlY3QzMDE5LTQi CiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLXN0YXJ0LXBvaW50PSJkNCIKICAgICAgIGlu a3NjYXBlOmNvbm5lY3Rpb24tZW5kPSIjcmVjdDMwMTktNCIKICAgICAgIGlua3NjYXBlOmNv bm5lY3Rpb24tZW5kLXBvaW50PSJkNCIgLz4KICAgIDxwYXRoCiAgICAgICBzdHlsZT0iZmls bDpub25lO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDoyO3N0cm9rZS1saW5lY2FwOmJ1 dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9w YWNpdHk6MTtzdHJva2UtZGFzaGFycmF5Om5vbmU7bWFya2VyLXN0YXJ0OnVybCgjQXJyb3cx TXN0YXJ0KTttYXJrZXItbWlkOm5vbmU7bWFya2VyLWVuZDp1cmwoI0Fycm93MU1lbmQpIgog ICAgICAgZD0iTSA1NDkuNzczNSw0NDEuMzIzOTcgNDU0LjM1NjI0LDM3MS42NzI5NCIKICAg ICAgIGlkPSJwYXRoNTU5NiIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rvci10eXBlPSJwb2x5 bGluZSIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rvci1jdXJ2YXR1cmU9IjMiCiAgICAgICBp bmtzY2FwZTpjb25uZWN0aW9uLXN0YXJ0PSIjcmVjdDMwMTktNiIKICAgICAgIGlua3NjYXBl OmNvbm5lY3Rpb24tc3RhcnQtcG9pbnQ9ImQ0IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlv bi1lbmQ9IiNyZWN0MzAxOS00IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQtcG9p bnQ9ImQ0IiAvPgogICAgPHBhdGgKICAgICAgIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlOiMw MDAwMDA7c3Ryb2tlLXdpZHRoOjI7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpv aW46bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1k YXNoYXJyYXk6bm9uZTttYXJrZXItc3RhcnQ6dXJsKCNBcnJvdzFNc3RhcnQpO21hcmtlci1l bmQ6dXJsKCNBcnJvdzFNZW5kKSIKICAgICAgIGQ9Im0gNjE5LjY1NzQ5LDU0My4zNDkzOSAw LDcwLjMyOTg3IgogICAgICAgaWQ9InBhdGg1NTk4IgogICAgICAgaW5rc2NhcGU6Y29ubmVj dG9yLXR5cGU9InBvbHlsaW5lIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVy ZT0iMyIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tc3RhcnQ9IiNyZWN0MzAxOS02Igog ICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFydC1wb2ludD0iZDQiCiAgICAgICBpbmtz Y2FwZTpjb25uZWN0aW9uLWVuZD0iI3JlY3QzMDE5LTg4IgogICAgICAgaW5rc2NhcGU6Y29u bmVjdGlvbi1lbmQtcG9pbnQ9ImQ0IiAvPgogICAgPHBhdGgKICAgICAgIHN0eWxlPSJmaWxs Om5vbmU7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjI7c3Ryb2tlLWxpbmVjYXA6YnV0 dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6NDtzdHJva2Utb3Bh Y2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6bm9uZTtzdHJva2UtZGFzaG9mZnNldDowO21hcmtl ci1zdGFydDp1cmwoI0Fycm93MU1zdGFydCk7bWFya2VyLWVuZDp1cmwoI0Fycm93MU1lbmQp IgogICAgICAgZD0ibSA0NTIuNjcwNDYsMjY5LjY0NzUyIDk4Ljc4ODgzLC03My44OTQ2OSIK ICAgICAgIGlkPSJwYXRoNTYwMiIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rvci10eXBlPSJw b2x5bGluZSIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rvci1jdXJ2YXR1cmU9IjMiCiAgICAg ICBpbmtzY2FwZTpjb25uZWN0aW9uLXN0YXJ0PSIjcmVjdDMwMTktNCIKICAgICAgIGlua3Nj YXBlOmNvbm5lY3Rpb24tc3RhcnQtcG9pbnQ9ImQ0IgogICAgICAgaW5rc2NhcGU6Y29ubmVj dGlvbi1lbmQ9IiNyZWN0MzAxOS04IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQt cG9pbnQ9ImQ0IiAvPgogICAgPHRleHQKICAgICAgIHhtbDpzcGFjZT0icHJlc2VydmUiCiAg ICAgICBzdHlsZT0iZm9udC1zaXplOjMycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJp YW50Om5vcm1hbDtmb250LXdlaWdodDpib2xkO2ZvbnQtc3RyZXRjaDpub3JtYWw7dGV4dC1h bGlnbjpzdGFydDtsaW5lLWhlaWdodDoxMjUlO2xldHRlci1zcGFjaW5nOjBweDt3b3JkLXNw YWNpbmc6MHB4O3dyaXRpbmctbW9kZTpsci10Yjt0ZXh0LWFuY2hvcjpzdGFydDtmaWxsOiMw MDQxMDA7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6UGxhbnRhZ2Vu ZXQgQ2hlcm9rZWU7LWlua3NjYXBlLWZvbnQtc3BlY2lmaWNhdGlvbjpQbGFudGFnZW5ldCBD aGVyb2tlZSBCb2xkIgogICAgICAgeD0iOTMuODA0ODkzIgogICAgICAgeT0iMTM1LjcxNTIz IgogICAgICAgaWQ9InRleHQxMDE3NCIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIx MjUlIj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAgICAgaWQ9 InRzcGFuMTAxNzYiCiAgICAgICAgIHg9IjkzLjgwNDg5MyIKICAgICAgICAgeT0iMTM1Ljcx NTIzIj5SZXN1bHRzPC90c3Bhbj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGlu ZSIKICAgICAgICAgeD0iOTMuODA0ODkzIgogICAgICAgICB5PSIxNzUuNzE1MjMiCiAgICAg ICAgIGlkPSJ0c3BhbjEwMTc4Ij5WaWV3ZXI8L3RzcGFuPjwvdGV4dD4KICAgIDx0ZXh0CiAg ICAgICB4bWw6c3BhY2U9InByZXNlcnZlIgogICAgICAgc3R5bGU9ImZvbnQtc2l6ZTozMnB4 O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6Ym9s ZDtmb250LXN0cmV0Y2g6bm9ybWFsO3RleHQtYWxpZ246Y2VudGVyO2xpbmUtaGVpZ2h0OjEy NSU7bGV0dGVyLXNwYWNpbmc6MHB4O3dvcmQtc3BhY2luZzowcHg7d3JpdGluZy1tb2RlOmxy LXRiO3RleHQtYW5jaG9yOm1pZGRsZTtmaWxsOiMwMDNmMDA7ZmlsbC1vcGFjaXR5OjE7c3Ry b2tlOm5vbmU7Zm9udC1mYW1pbHk6UGxhbnRhZ2VuZXQgQ2hlcm9rZWU7LWlua3NjYXBlLWZv bnQtc3BlY2lmaWNhdGlvbjpQbGFudGFnZW5ldCBDaGVyb2tlZSBCb2xkIgogICAgICAgeD0i MTQzLjg5OTYzIgogICAgICAgeT0iMzExLjY1MjQiCiAgICAgICBpZD0idGV4dDEwMTgwIgog ICAgICAgc29kaXBvZGk6bGluZXNwYWNpbmc9IjEyNSUiPjx0c3BhbgogICAgICAgICBzb2Rp cG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBpZD0idHNwYW4xMDE4MiIKICAgICAgICAgeD0i MTQzLjg5OTYzIgogICAgICAgICB5PSIzMTEuNjUyNCI+Q29udHJvbGxlcjwvdHNwYW4+PHRz cGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAgICAgICAgIHg9IjE0My44OTk2 MyIKICAgICAgICAgeT0iMzUxLjY1MjQiCiAgICAgICAgIGlkPSJ0c3BhbjEwMTg0Ij5Gcm9u dC1FbmQ8L3RzcGFuPjwvdGV4dD4KICAgIDx0ZXh0CiAgICAgICB4bWw6c3BhY2U9InByZXNl cnZlIgogICAgICAgc3R5bGU9ImZvbnQtc2l6ZToyOHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2Zv bnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0cmV0Y2g6bm9ybWFs O3RleHQtYWxpZ246Y2VudGVyO2xpbmUtaGVpZ2h0OjEyNSU7bGV0dGVyLXNwYWNpbmc6MHB4 O3dvcmQtc3BhY2luZzowcHg7d3JpdGluZy1tb2RlOmxyLXRiO3RleHQtYW5jaG9yOm1pZGRs ZTtmaWxsOiM0MTAwMDA7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6 UGxhbnRhZ2VuZXQgQ2hlcm9rZWU7LWlua3NjYXBlLWZvbnQtc3BlY2lmaWNhdGlvbjpQbGFu dGFnZW5ldCBDaGVyb2tlZSBCb2xkIgogICAgICAgeD0iNjE5LjYyNDU3IgogICAgICAgeT0i MTM2Ljk0Mzc0IgogICAgICAgaWQ9InRleHQxMDE4NiIKICAgICAgIHNvZGlwb2RpOmxpbmVz cGFjaW5nPSIxMjUlIj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAg ICAgICAgaWQ9InRzcGFuMTAxODgiCiAgICAgICAgIHg9IjYxOS42MjQ1NyIKICAgICAgICAg eT0iMTM2Ljk0Mzc0Ij5SZXN1bHRzPC90c3Bhbj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6 cm9sZT0ibGluZSIKICAgICAgICAgeD0iNjE5LjYyNDU3IgogICAgICAgICB5PSIxNzEuOTQz NzQiCiAgICAgICAgIGlkPSJ0c3BhbjEwMTkwIj5EYXRhc3RvcmU8L3RzcGFuPjwvdGV4dD4K ICAgIDx0ZXh0CiAgICAgICB4bWw6c3BhY2U9InByZXNlcnZlIgogICAgICAgc3R5bGU9ImZv bnQtc2l6ZToyOHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9u dC13ZWlnaHQ6Ym9sZDtmb250LXN0cmV0Y2g6bm9ybWFsO3RleHQtYWxpZ246Y2VudGVyO2xp bmUtaGVpZ2h0OjEyNSU7bGV0dGVyLXNwYWNpbmc6MHB4O3dvcmQtc3BhY2luZzowcHg7d3Jp dGluZy1tb2RlOmxyO3RleHQtYW5jaG9yOm1pZGRsZTtmaWxsOiMwMDAwODI7ZmlsbC1vcGFj aXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6UGxhbnRhZ2VuZXQgQ2hlcm9rZWU7LWlu a3NjYXBlLWZvbnQtc3BlY2lmaWNhdGlvbjpQbGFudGFnZW5ldCBDaGVyb2tlZSBCb2xkIgog ICAgICAgeD0iMzgzLjY2NTEzIgogICAgICAgeT0iMzMxLjc1MDA2IgogICAgICAgaWQ9InRl eHQxMDE5MiIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIxMjUlIj48dHNwYW4KICAg ICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAgICAgaWQ9InRzcGFuMTAxOTQiCiAg ICAgICAgIHg9IjM4My42NjUxMyIKICAgICAgICAgeT0iMzMxLjc1MDA2Ij5Db250cm9sbGVy PC90c3Bhbj48L3RleHQ+CiAgICA8dGV4dAogICAgICAgeG1sOnNwYWNlPSJwcmVzZXJ2ZSIK ICAgICAgIHN0eWxlPSJmb250LXNpemU6MzJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZh cmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1zdHJldGNoOm5vcm1hbDt0ZXh0 LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxMjUlO2xldHRlci1zcGFjaW5nOjBweDt3b3Jk LXNwYWNpbmc6MHB4O3dyaXRpbmctbW9kZTpsci10Yjt0ZXh0LWFuY2hvcjptaWRkbGU7Zmls bDojNDEwMDAwO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OlBsYW50 YWdlbmV0IENoZXJva2VlOy1pbmtzY2FwZS1mb250LXNwZWNpZmljYXRpb246UGxhbnRhZ2Vu ZXQgQ2hlcm9rZWUgQm9sZCIKICAgICAgIHg9IjYxOS4wNTY4OCIKICAgICAgIHk9IjUwMy4z MTE3NyIKICAgICAgIGlkPSJ0ZXh0MTAxOTYiCiAgICAgICBzb2RpcG9kaTpsaW5lc3BhY2lu Zz0iMTI1JSI+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAgICAgICAg IGlkPSJ0c3BhbjEwMTk4IgogICAgICAgICB4PSI2MTkuMDU2ODgiCiAgICAgICAgIHk9IjUw My4zMTE3NyI+RXZhbHVhdG9yPC90c3Bhbj48L3RleHQ+CiAgICA8dGV4dAogICAgICAgeG1s OnNwYWNlPSJwcmVzZXJ2ZSIKICAgICAgIHN0eWxlPSJmb250LXNpemU6MzJweDtmb250LXN0 eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1z dHJldGNoOm5vcm1hbDt0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxMjUlO2xldHRl ci1zcGFjaW5nOjBweDt3b3JkLXNwYWNpbmc6MHB4O3dyaXRpbmctbW9kZTpsci10Yjt0ZXh0 LWFuY2hvcjptaWRkbGU7ZmlsbDojNDgwMDAwO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25l O2ZvbnQtZmFtaWx5OlBsYW50YWdlbmV0IENoZXJva2VlOy1pbmtzY2FwZS1mb250LXNwZWNp ZmljYXRpb246UGxhbnRhZ2VuZXQgQ2hlcm9rZWUgQm9sZCIKICAgICAgIHg9IjYxOC44NTAz NCIKICAgICAgIHk9IjY1NS40MzcwNyIKICAgICAgIGlkPSJ0ZXh0MTAyMDAiCiAgICAgICBz b2RpcG9kaTpsaW5lc3BhY2luZz0iMTI1JSI+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJv bGU9ImxpbmUiCiAgICAgICAgIGlkPSJ0c3BhbjEwMjAyIgogICAgICAgICB4PSI2MTguODUw MzQiCiAgICAgICAgIHk9IjY1NS40MzcwNyI+RGF0YTwvdHNwYW4+PHRzcGFuCiAgICAgICAg IHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAgICAgICAgIHg9IjYxOC44NTAzNCIKICAgICAgICAg eT0iNjk1LjQzNzA3IgogICAgICAgICBpZD0idHNwYW4xMDIwNCI+Q29sbGVjdG9yPC90c3Bh bj48L3RleHQ+CiAgICA8cmVjdAogICAgICAgc3R5bGU9ImZpbGw6bm9uZTtzdHJva2U6Izli MDAwMDtzdHJva2Utd2lkdGg6OC40NzczOTAyOTtzdHJva2UtbGluZWpvaW46YmV2ZWw7c3Ry b2tlLW1pdGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eTowLjM4NjI0MzM5O3N0cm9rZS1kYXNo YXJyYXk6bm9uZSIKICAgICAgIGlkPSJyZWN0MTAyMDYiCiAgICAgICB3aWR0aD0iNjY5LjI2 OTc4IgogICAgICAgaGVpZ2h0PSIzMTguNzQ2OTUiCiAgICAgICB4PSI0Ni4xOTI1ODEiCiAg ICAgICB5PSI3My4yNDk5MzEiIC8+CiAgICA8cmVjdAogICAgICAgc3R5bGU9ImZpbGw6bm9u ZTtzdHJva2U6IzAwOTQwMDtzdHJva2Utd2lkdGg6Ny43Njk4MDYzOTAwMDAwMDAzMDtzdHJv a2UtbGluZWNhcDpzcXVhcmU7c3Ryb2tlLWxpbmVqb2luOmJldmVsO3N0cm9rZS1taXRlcmxp bWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MC4zODYyNDM0O3N0cm9rZS1kYXNoYXJyYXk6bm9uZTtz dHJva2UtZGFzaG9mZnNldDowIgogICAgICAgaWQ9InJlY3QxMDIwOCIKICAgICAgIHdpZHRo PSIxOTEuMTM4ODkiCiAgICAgICBoZWlnaHQ9IjMxMS4zNDcwMiIKICAgICAgIHg9IjUyMi42 NDM5MiIKICAgICAgIHk9IjQyMy40MzIyMiIgLz4KICAgIDx0ZXh0CiAgICAgICB4bWw6c3Bh Y2U9InByZXNlcnZlIgogICAgICAgc3R5bGU9ImZvbnQtc2l6ZTo0MHB4O2ZvbnQtc3R5bGU6 bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsaW5lLWhlaWdodDoxMjUlO2xldHRlci1zcGFj aW5nOjBweDt3b3JkLXNwYWNpbmc6MHB4O2ZpbGw6IzliMDAwMDtmaWxsLW9wYWNpdHk6MC4z ODYyNDM0O3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OlNhbnMiCiAgICAgICB4PSIxODcuODg4 MzciCiAgICAgICB5PSI1NC4yMjk5NDIiCiAgICAgICBpZD0idGV4dDEwMjEwIgogICAgICAg c29kaXBvZGk6bGluZXNwYWNpbmc9IjEyNSUiPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpy b2xlPSJsaW5lIgogICAgICAgICBpZD0idHNwYW4xMDIxMiIKICAgICAgICAgeD0iMTg3Ljg4 ODM3IgogICAgICAgICB5PSI1NC4yMjk5NDIiPk1hbmFnZW1lbnQgU3lzdGVtPC90c3Bhbj48 L3RleHQ+CiAgICA8dGV4dAogICAgICAgeG1sOnNwYWNlPSJwcmVzZXJ2ZSIKICAgICAgIHN0 eWxlPSJmb250LXNpemU6NDBweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3Jt YWw7bGluZS1oZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29yZC1zcGFjaW5nOjBw eDtmaWxsOiMwMDliMDA7ZmlsbC1vcGFjaXR5OjAuMzg0MzEzNzM7c3Ryb2tlOm5vbmU7Zm9u dC1mYW1pbHk6U2FucyIKICAgICAgIHg9IjE1My41NDMxOCIKICAgICAgIHk9IjU5Mi43NDI4 IgogICAgICAgaWQ9InRleHQxMDIxNCIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIx MjUlIj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAgICAgaWQ9 InRzcGFuMTAyMTYiCiAgICAgICAgIHg9IjE1My41NDMxOCIKICAgICAgICAgeT0iNTkyLjc0 MjgiPkNvbGxlY3Rvci9Qcm9jZXNzb3I8L3RzcGFuPjwvdGV4dD4KICA8L2c+Cjwvc3ZnPgo= --------------010902070800010109090005 Content-Type: image/svg+xml; name="EntitiesInUse.svg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="EntitiesInUse.svg" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+ CjwhLS0gQ3JlYXRlZCB3aXRoIElua3NjYXBlIChodHRwOi8vd3d3Lmlua3NjYXBlLm9yZy8p IC0tPgoKPHN2ZwogICB4bWxuczpvc2I9Imh0dHA6Ly93d3cub3BlbnN3YXRjaGJvb2sub3Jn L3VyaS8yMDA5L29zYiIKICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50 cy8xLjEvIgogICB4bWxuczpjYz0iaHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbnMjIgog ICB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1u cyMiCiAgIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciCiAgIHhtbG5z PSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIKICAgeG1sbnM6eGxpbms9Imh0dHA6Ly93 d3cudzMub3JnLzE5OTkveGxpbmsiCiAgIHhtbG5zOnNvZGlwb2RpPSJodHRwOi8vc29kaXBv ZGkuc291cmNlZm9yZ2UubmV0L0RURC9zb2RpcG9kaS0wLmR0ZCIKICAgeG1sbnM6aW5rc2Nh cGU9Imh0dHA6Ly93d3cuaW5rc2NhcGUub3JnL25hbWVzcGFjZXMvaW5rc2NhcGUiCiAgIHdp ZHRoPSI3NDQuMDk0NDg4MTkiCiAgIGhlaWdodD0iMTA1Mi4zNjIyMDQ3IgogICBpZD0ic3Zn MiIKICAgdmVyc2lvbj0iMS4xIgogICBpbmtzY2FwZTp2ZXJzaW9uPSIwLjQ4LjQgcjk5Mzki CiAgIHNvZGlwb2RpOmRvY25hbWU9IkVudGl0aWVzSW5Vc2Uuc3ZnIj4KICA8ZGVmcwogICAg IGlkPSJkZWZzNCI+CiAgICA8bWFya2VyCiAgICAgICBpbmtzY2FwZTpzdG9ja2lkPSJUYWls IgogICAgICAgb3JpZW50PSJhdXRvIgogICAgICAgcmVmWT0iMC4wIgogICAgICAgcmVmWD0i MC4wIgogICAgICAgaWQ9IlRhaWwiCiAgICAgICBzdHlsZT0ib3ZlcmZsb3c6dmlzaWJsZSI+ CiAgICAgIDxnCiAgICAgICAgIGlkPSJnNTY0NCIKICAgICAgICAgdHJhbnNmb3JtPSJzY2Fs ZSgtMS4yKSI+CiAgICAgICAgPHBhdGgKICAgICAgICAgICBpZD0icGF0aDU2NDYiCiAgICAg ICAgICAgZD0iTSAtMy44MDQ4Njc0LC0zLjk1ODUyMjcgTCAwLjU0MzUyMDk0LDAiCiAgICAg ICAgICAgc3R5bGU9ImZpbGw6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzAwMDAw MDtzdHJva2Utd2lkdGg6MC44O3N0cm9rZS1saW5lY2FwOnJvdW5kIiAvPgogICAgICAgIDxw YXRoCiAgICAgICAgICAgaWQ9InBhdGg1NjQ4IgogICAgICAgICAgIGQ9Ik0gLTEuMjg2Njgz MiwtMy45NTg1MjI3IEwgMy4wNjE3MDUzLDAiCiAgICAgICAgICAgc3R5bGU9ImZpbGw6bm9u ZTtmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MC44O3N0 cm9rZS1saW5lY2FwOnJvdW5kIiAvPgogICAgICAgIDxwYXRoCiAgICAgICAgICAgaWQ9InBh dGg1NjUwIgogICAgICAgICAgIGQ9Ik0gMS4zMDUzNTgyLC0zLjk1ODUyMjcgTCA1LjY1Mzc0 NjYsMCIKICAgICAgICAgICBzdHlsZT0iZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0 cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDowLjg7c3Ryb2tlLWxpbmVjYXA6cm91bmQiIC8+ CiAgICAgICAgPHBhdGgKICAgICAgICAgICBpZD0icGF0aDU2NTIiCiAgICAgICAgICAgZD0i TSAtMy44MDQ4Njc0LDQuMTc3NTgzOCBMIDAuNTQzNTIwOTQsMC4yMTk3NDIyNiIKICAgICAg ICAgICBzdHlsZT0iZmlsbDpub25lO2ZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojMDAwMDAw O3N0cm9rZS13aWR0aDowLjg7c3Ryb2tlLWxpbmVjYXA6cm91bmQiIC8+CiAgICAgICAgPHBh dGgKICAgICAgICAgICBpZD0icGF0aDU2NTQiCiAgICAgICAgICAgZD0iTSAtMS4yODY2ODMy LDQuMTc3NTgzOCBMIDMuMDYxNzA1MywwLjIxOTc0MjI2IgogICAgICAgICAgIHN0eWxlPSJm aWxsOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRo OjAuODtzdHJva2UtbGluZWNhcDpyb3VuZCIgLz4KICAgICAgICA8cGF0aAogICAgICAgICAg IGlkPSJwYXRoNTY1NiIKICAgICAgICAgICBkPSJNIDEuMzA1MzU4Miw0LjE3NzU4MzggTCA1 LjY1Mzc0NjYsMC4yMTk3NDIyNiIKICAgICAgICAgICBzdHlsZT0iZmlsbDpub25lO2ZpbGwt cnVsZTpldmVub2RkO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDowLjg7c3Ryb2tlLWxp bmVjYXA6cm91bmQiIC8+CiAgICAgIDwvZz4KICAgIDwvbWFya2VyPgogICAgPG1hcmtlcgog ICAgICAgaW5rc2NhcGU6c3RvY2tpZD0iQXJyb3cyTGVuZCIKICAgICAgIG9yaWVudD0iYXV0 byIKICAgICAgIHJlZlk9IjAuMCIKICAgICAgIHJlZlg9IjAuMCIKICAgICAgIGlkPSJBcnJv dzJMZW5kIgogICAgICAgc3R5bGU9Im92ZXJmbG93OnZpc2libGU7Ij4KICAgICAgPHBhdGgK ICAgICAgICAgaWQ9InBhdGg1NjI5IgogICAgICAgICBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5v ZGQ7c3Ryb2tlLXdpZHRoOjAuNjI1MDAwMDA7c3Ryb2tlLWxpbmVqb2luOnJvdW5kOyIKICAg ICAgICAgZD0iTSA4LjcxODU4NzgsNC4wMzM3MzUyIEwgLTIuMjA3Mjg5NSwwLjAxNjAxMzI1 NiBMIDguNzE4NTg4NCwtNC4wMDE3MDc4IEMgNi45NzMwOTAwLC0xLjYyOTY0NjkgNi45ODMx NDc2LDEuNjE1NzQ0MSA4LjcxODU4NzgsNC4wMzM3MzUyIHogIgogICAgICAgICB0cmFuc2Zv cm09InNjYWxlKDEuMSkgcm90YXRlKDE4MCkgdHJhbnNsYXRlKDEsMCkiIC8+CiAgICA8L21h cmtlcj4KICAgIDxtYXJrZXIKICAgICAgIGlua3NjYXBlOnN0b2NraWQ9IkFycm93MkxzdGFy dCIKICAgICAgIG9yaWVudD0iYXV0byIKICAgICAgIHJlZlk9IjAuMCIKICAgICAgIHJlZlg9 IjAuMCIKICAgICAgIGlkPSJBcnJvdzJMc3RhcnQiCiAgICAgICBzdHlsZT0ib3ZlcmZsb3c6 dmlzaWJsZSI+CiAgICAgIDxwYXRoCiAgICAgICAgIGlkPSJwYXRoNTYyNiIKICAgICAgICAg c3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO3N0cm9rZS13aWR0aDowLjYyNTAwMDAwO3N0cm9r ZS1saW5lam9pbjpyb3VuZCIKICAgICAgICAgZD0iTSA4LjcxODU4NzgsNC4wMzM3MzUyIEwg LTIuMjA3Mjg5NSwwLjAxNjAxMzI1NiBMIDguNzE4NTg4NCwtNC4wMDE3MDc4IEMgNi45NzMw OTAwLC0xLjYyOTY0NjkgNi45ODMxNDc2LDEuNjE1NzQ0MSA4LjcxODU4NzgsNC4wMzM3MzUy IHogIgogICAgICAgICB0cmFuc2Zvcm09InNjYWxlKDEuMSkgdHJhbnNsYXRlKDEsMCkiIC8+ CiAgICA8L21hcmtlcj4KICAgIDxtYXJrZXIKICAgICAgIGlua3NjYXBlOnN0b2NraWQ9IkFy cm93MUxlbmQiCiAgICAgICBvcmllbnQ9ImF1dG8iCiAgICAgICByZWZZPSIwLjAiCiAgICAg ICByZWZYPSIwLjAiCiAgICAgICBpZD0iQXJyb3cxTGVuZCIKICAgICAgIHN0eWxlPSJvdmVy Zmxvdzp2aXNpYmxlOyI+CiAgICAgIDxwYXRoCiAgICAgICAgIGlkPSJwYXRoNTYxMSIKICAg ICAgICAgZD0iTSAwLjAsMC4wIEwgNS4wLC01LjAgTCAtMTIuNSwwLjAgTCA1LjAsNS4wIEwg MC4wLDAuMCB6ICIKICAgICAgICAgc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO3N0cm9rZToj MDAwMDAwO3N0cm9rZS13aWR0aDoxLjBwdDsiCiAgICAgICAgIHRyYW5zZm9ybT0ic2NhbGUo MC44KSByb3RhdGUoMTgwKSB0cmFuc2xhdGUoMTIuNSwwKSIgLz4KICAgIDwvbWFya2VyPgog ICAgPG1hcmtlcgogICAgICAgaW5rc2NhcGU6c3RvY2tpZD0iQXJyb3cxTXN0YXJ0IgogICAg ICAgb3JpZW50PSJhdXRvIgogICAgICAgcmVmWT0iMC4wIgogICAgICAgcmVmWD0iMC4wIgog ICAgICAgaWQ9IkFycm93MU1zdGFydCIKICAgICAgIHN0eWxlPSJvdmVyZmxvdzp2aXNpYmxl Ij4KICAgICAgPHBhdGgKICAgICAgICAgaWQ9InBhdGg1NjE0IgogICAgICAgICBkPSJNIDAu MCwwLjAgTCA1LjAsLTUuMCBMIC0xMi41LDAuMCBMIDUuMCw1LjAgTCAwLjAsMC4wIHogIgog ICAgICAgICBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tl LXdpZHRoOjEuMHB0IgogICAgICAgICB0cmFuc2Zvcm09InNjYWxlKDAuNCkgdHJhbnNsYXRl KDEwLDApIiAvPgogICAgPC9tYXJrZXI+CiAgICA8bWFya2VyCiAgICAgICBpbmtzY2FwZTpz dG9ja2lkPSJBcnJvdzFNZW5kIgogICAgICAgb3JpZW50PSJhdXRvIgogICAgICAgcmVmWT0i MC4wIgogICAgICAgcmVmWD0iMC4wIgogICAgICAgaWQ9IkFycm93MU1lbmQiCiAgICAgICBz dHlsZT0ib3ZlcmZsb3c6dmlzaWJsZTsiPgogICAgICA8cGF0aAogICAgICAgICBpZD0icGF0 aDU2MTciCiAgICAgICAgIGQ9Ik0gMC4wLDAuMCBMIDUuMCwtNS4wIEwgLTEyLjUsMC4wIEwg NS4wLDUuMCBMIDAuMCwwLjAgeiAiCiAgICAgICAgIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9k ZDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MS4wcHQ7IgogICAgICAgICB0cmFuc2Zv cm09InNjYWxlKDAuNCkgcm90YXRlKDE4MCkgdHJhbnNsYXRlKDEwLDApIiAvPgogICAgPC9t YXJrZXI+CiAgICA8bWFya2VyCiAgICAgICBpbmtzY2FwZTpzdG9ja2lkPSJBcnJvdzFTc3Rh cnQiCiAgICAgICBvcmllbnQ9ImF1dG8iCiAgICAgICByZWZZPSIwLjAiCiAgICAgICByZWZY PSIwLjAiCiAgICAgICBpZD0iQXJyb3cxU3N0YXJ0IgogICAgICAgc3R5bGU9Im92ZXJmbG93 OnZpc2libGUiPgogICAgICA8cGF0aAogICAgICAgICBpZD0icGF0aDU2MjAiCiAgICAgICAg IGQ9Ik0gMC4wLDAuMCBMIDUuMCwtNS4wIEwgLTEyLjUsMC4wIEwgNS4wLDUuMCBMIDAuMCww LjAgeiAiCiAgICAgICAgIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzAwMDAw MDtzdHJva2Utd2lkdGg6MS4wcHQiCiAgICAgICAgIHRyYW5zZm9ybT0ic2NhbGUoMC4yKSB0 cmFuc2xhdGUoNiwwKSIgLz4KICAgIDwvbWFya2VyPgogICAgPG1hcmtlcgogICAgICAgaW5r c2NhcGU6c3RvY2tpZD0iQXJyb3cxTHN0YXJ0IgogICAgICAgb3JpZW50PSJhdXRvIgogICAg ICAgcmVmWT0iMC4wIgogICAgICAgcmVmWD0iMC4wIgogICAgICAgaWQ9IkFycm93MUxzdGFy dCIKICAgICAgIHN0eWxlPSJvdmVyZmxvdzp2aXNpYmxlIj4KICAgICAgPHBhdGgKICAgICAg ICAgaWQ9InBhdGg1NjA4IgogICAgICAgICBkPSJNIDAuMCwwLjAgTCA1LjAsLTUuMCBMIC0x Mi41LDAuMCBMIDUuMCw1LjAgTCAwLjAsMC4wIHogIgogICAgICAgICBzdHlsZT0iZmlsbC1y dWxlOmV2ZW5vZGQ7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjEuMHB0IgogICAgICAg ICB0cmFuc2Zvcm09InNjYWxlKDAuOCkgdHJhbnNsYXRlKDEyLjUsMCkiIC8+CiAgICA8L21h cmtlcj4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ0 MyIKICAgICAgIG9zYjpwYWludD0ic29saWQiPgogICAgICA8c3RvcAogICAgICAgICBzdHls ZT0ic3RvcC1jb2xvcjojYjNjY2Y4O3N0b3Atb3BhY2l0eToxOyIKICAgICAgICAgb2Zmc2V0 PSIwIgogICAgICAgICBpZD0ic3RvcDU0NDUiIC8+CiAgICA8L2xpbmVhckdyYWRpZW50Pgog ICAgPGxpbmVhckdyYWRpZW50CiAgICAgICBpZD0ibGluZWFyR3JhZGllbnQ1MjU3IgogICAg ICAgb3NiOnBhaW50PSJzb2xpZCI+CiAgICAgIDxzdG9wCiAgICAgICAgIHN0eWxlPSJzdG9w LWNvbG9yOiMwMDAwZmY7c3RvcC1vcGFjaXR5OjAuMzQzOTE1MzQ7IgogICAgICAgICBvZmZz ZXQ9IjAiCiAgICAgICAgIGlkPSJzdG9wNTI1OSIgLz4KICAgIDwvbGluZWFyR3JhZGllbnQ+ CiAgICA8aW5rc2NhcGU6cGVyc3BlY3RpdmUKICAgICAgIHNvZGlwb2RpOnR5cGU9Imlua3Nj YXBlOnBlcnNwM2QiCiAgICAgICBpbmtzY2FwZTp2cF94PSIwIDogNTI2LjE4MTA5IDogMSIK ICAgICAgIGlua3NjYXBlOnZwX3k9IjAgOiAxMDAwIDogMCIKICAgICAgIGlua3NjYXBlOnZw X3o9Ijc0NC4wOTQ0OCA6IDUyNi4xODEwOSA6IDEiCiAgICAgICBpbmtzY2FwZTpwZXJzcDNk LW9yaWdpbj0iMzcyLjA0NzI0IDogMzUwLjc4NzM5IDogMSIKICAgICAgIGlkPSJwZXJzcGVj dGl2ZTI5OTUiIC8+CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAgIGlua3NjYXBlOmNvbGxl Y3Q9ImFsd2F5cyIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMiCiAg ICAgICBpZD0ibGluZWFyR3JhZGllbnQ1NDUxIgogICAgICAgeDE9Ijc2Ljc5MTkwMSIKICAg ICAgIHkxPSIxODEuMTA1NjIiCiAgICAgICB4Mj0iMjMyLjMxNDc3IgogICAgICAgeTI9IjE4 MS4xMDU2MiIKICAgICAgIGdyYWRpZW50VW5pdHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAg Z3JhZGllbnRUcmFuc2Zvcm09InRyYW5zbGF0ZSgtMTAuMDIwOTE1LDEzOS41NTQ2MSkiIC8+ CiAgICA8ZmlsdGVyCiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiCiAgICAgICBp ZD0iZmlsdGVyNTQ3MyIKICAgICAgIHg9Ii0wLjEwMDQiCiAgICAgICB3aWR0aD0iMS4yMDA4 IgogICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhlaWdodD0iMS4yOTgyMTc4Ij4KICAg ICAgPGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIK ICAgICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIiCiAgICAgICAgIGlkPSJmZUdhdXNz aWFuQmx1cjU0NzUiIC8+CiAgICA8L2ZpbHRlcj4KICAgIDxsaW5lYXJHcmFkaWVudAogICAg ICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAgeGxpbms6aHJlZj0iI2xpbmVh ckdyYWRpZW50NTQ0My0yIgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ1MS01IgogICAg ICAgeDE9Ijc2Ljc5MTkwMSIKICAgICAgIHkxPSIxODEuMTA1NjIiCiAgICAgICB4Mj0iMjMy LjMxNDc3IgogICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIGdyYWRpZW50VW5pdHM9InVz ZXJTcGFjZU9uVXNlIiAvPgogICAgPGxpbmVhckdyYWRpZW50CiAgICAgICBpZD0ibGluZWFy R3JhZGllbnQ1NDQzLTIiCiAgICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAgPHN0b3AK ICAgICAgICAgc3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6MTsiCiAg ICAgICAgIG9mZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1LTMiIC8+CiAgICA8L2xp bmVhckdyYWRpZW50PgogICAgPGZpbHRlcgogICAgICAgY29sb3ItaW50ZXJwb2xhdGlvbi1m aWx0ZXJzPSJzUkdCIgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAg aWQ9ImZpbHRlcjU0NzMtMSIKICAgICAgIHg9Ii0wLjEwMDQiCiAgICAgICB3aWR0aD0iMS4y MDA3OTk5IgogICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhlaWdodD0iMS4yOTgyMTc4 Ij4KICAgICAgPGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFs d2F5cyIKICAgICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIiCiAgICAgICAgIGlkPSJm ZUdhdXNzaWFuQmx1cjU0NzUtNiIgLz4KICAgIDwvZmlsdGVyPgogICAgPGxpbmVhckdyYWRp ZW50CiAgICAgICBncmFkaWVudFRyYW5zZm9ybT0idHJhbnNsYXRlKDQ2NS4xMDQyLC0zNi4z NjU0ODQpIgogICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIHgyPSIyMzIuMzE0NzciCiAg ICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAgeDE9Ijc2Ljc5MTkwMSIKICAgICAgIGdyYWRp ZW50VW5pdHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ5 MyIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMtMiIKICAgICAgIGlu a3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIgLz4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAg aW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAgeGxpbms6aHJlZj0iI2xpbmVhckdy YWRpZW50NTQ0My0yNyIKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVudDU0NTEtOCIKICAgICAg IHgxPSI3Ni43OTE5MDEiCiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAgeDI9IjIzMi4z MTQ3NyIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICBncmFkaWVudFVuaXRzPSJ1c2Vy U3BhY2VPblVzZSIgLz4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgaWQ9ImxpbmVhckdy YWRpZW50NTQ0My0yNyIKICAgICAgIG9zYjpwYWludD0ic29saWQiPgogICAgICA8c3RvcAog ICAgICAgICBzdHlsZT0ic3RvcC1jb2xvcjojYjNjY2Y4O3N0b3Atb3BhY2l0eToxOyIKICAg ICAgICAgb2Zmc2V0PSIwIgogICAgICAgICBpZD0ic3RvcDU0NDUtNyIgLz4KICAgIDwvbGlu ZWFyR3JhZGllbnQ+CiAgICA8ZmlsdGVyCiAgICAgICBjb2xvci1pbnRlcnBvbGF0aW9uLWZp bHRlcnM9InNSR0IiCiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiCiAgICAgICBp ZD0iZmlsdGVyNTQ3My0xMiIKICAgICAgIHg9Ii0wLjEwMDQiCiAgICAgICB3aWR0aD0iMS4y MDA3OTk5IgogICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhlaWdodD0iMS4yOTgyMTc4 Ij4KICAgICAgPGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFs d2F5cyIKICAgICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIiCiAgICAgICAgIGlkPSJm ZUdhdXNzaWFuQmx1cjU0NzUtNjAiIC8+CiAgICA8L2ZpbHRlcj4KICAgIDxsaW5lYXJHcmFk aWVudAogICAgICAgZ3JhZGllbnRUcmFuc2Zvcm09InRyYW5zbGF0ZSgtMTAuMDIwOTI4LC0z Ni4zNjU1MDYpIgogICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIHgyPSIyMzIuMzE0Nzci CiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAgeDE9Ijc2Ljc5MTkwMSIKICAgICAgIGdy YWRpZW50VW5pdHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50 NTQ5My00IgogICAgICAgeGxpbms6aHJlZj0iI2xpbmVhckdyYWRpZW50NTQ0My0yNyIKICAg ICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIgLz4KICAgIDxsaW5lYXJHcmFkaWVudAog ICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAgeGxpbms6aHJlZj0iI2xp bmVhckdyYWRpZW50NTQ0My02IgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ1MS00Igog ICAgICAgeDE9Ijc2Ljc5MTkwMSIKICAgICAgIHkxPSIxODEuMTA1NjIiCiAgICAgICB4Mj0i MjMyLjMxNDc3IgogICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIGdyYWRpZW50VW5pdHM9 InVzZXJTcGFjZU9uVXNlIiAvPgogICAgPGxpbmVhckdyYWRpZW50CiAgICAgICBpZD0ibGlu ZWFyR3JhZGllbnQ1NDQzLTYiCiAgICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAgPHN0 b3AKICAgICAgICAgc3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6MTsi CiAgICAgICAgIG9mZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1LTAiIC8+CiAgICA8 L2xpbmVhckdyYWRpZW50PgogICAgPGZpbHRlcgogICAgICAgY29sb3ItaW50ZXJwb2xhdGlv bi1maWx0ZXJzPSJzUkdCIgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAg ICAgaWQ9ImZpbHRlcjU0NzMtMyIKICAgICAgIHg9Ii0wLjEwMDQiCiAgICAgICB3aWR0aD0i MS4yMDA3OTk5IgogICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhlaWdodD0iMS4yOTgy MTc4Ij4KICAgICAgPGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9 ImFsd2F5cyIKICAgICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIiCiAgICAgICAgIGlk PSJmZUdhdXNzaWFuQmx1cjU0NzUtNjIiIC8+CiAgICA8L2ZpbHRlcj4KICAgIDxsaW5lYXJH cmFkaWVudAogICAgICAgZ3JhZGllbnRUcmFuc2Zvcm09InRyYW5zbGF0ZSg0NjUuMTA0MTYs NDgzLjU4NjQ0KSIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICB4Mj0iMjMyLjMxNDc3 IgogICAgICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgxPSI3Ni43OTE5MDEiCiAgICAgICBn cmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVu dDU0OTMtNDUiCiAgICAgICB4bGluazpocmVmPSIjbGluZWFyR3JhZGllbnQ1NDQzLTYiCiAg ICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiIC8+CiAgICA8bGluZWFyR3JhZGllbnQK ICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIKICAgICAgIHhsaW5rOmhyZWY9IiNs aW5lYXJHcmFkaWVudDU0NDMtMjEiCiAgICAgICBpZD0ibGluZWFyR3JhZGllbnQ1NDUxLTEi CiAgICAgICB4MT0iNzYuNzkxOTAxIgogICAgICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgy PSIyMzIuMzE0NzciCiAgICAgICB5Mj0iMTgxLjEwNTYyIgogICAgICAgZ3JhZGllbnRVbml0 cz0idXNlclNwYWNlT25Vc2UiIC8+CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAgIGlkPSJs aW5lYXJHcmFkaWVudDU0NDMtMjEiCiAgICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAg PHN0b3AKICAgICAgICAgc3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6 MTsiCiAgICAgICAgIG9mZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1LTQiIC8+CiAg ICA8L2xpbmVhckdyYWRpZW50PgogICAgPGZpbHRlcgogICAgICAgY29sb3ItaW50ZXJwb2xh dGlvbi1maWx0ZXJzPSJzUkdCIgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgog ICAgICAgaWQ9ImZpbHRlcjU0NzMtOSIKICAgICAgIHg9Ii0wLjEwMDQiCiAgICAgICB3aWR0 aD0iMS4yMDA3OTk5IgogICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhlaWdodD0iMS4y OTgyMTc4Ij4KICAgICAgPGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3NjYXBlOmNvbGxl Y3Q9ImFsd2F5cyIKICAgICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIiCiAgICAgICAg IGlkPSJmZUdhdXNzaWFuQmx1cjU0NzUtOCIgLz4KICAgIDwvZmlsdGVyPgogICAgPGxpbmVh ckdyYWRpZW50CiAgICAgICBncmFkaWVudFRyYW5zZm9ybT0idHJhbnNsYXRlKDIyOS45MTg4 OCwxMzkuNTU0NjIpIgogICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIHgyPSIyMzIuMzE0 NzciCiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAgeDE9Ijc2Ljc5MTkwMSIKICAgICAg IGdyYWRpZW50VW5pdHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAgaWQ9ImxpbmVhckdyYWRp ZW50NTQ5My0yIgogICAgICAgeGxpbms6aHJlZj0iI2xpbmVhckdyYWRpZW50NTQ0My0yMSIK ICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIgLz4KICAgIDxsaW5lYXJHcmFkaWVu dAogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAgeGxpbms6aHJlZj0i I2xpbmVhckdyYWRpZW50NTQ0My05IgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ1MS01 MiIKICAgICAgIHgxPSI3Ni43OTE5MDEiCiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAg eDI9IjIzMi4zMTQ3NyIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICBncmFkaWVudFVu aXRzPSJ1c2VyU3BhY2VPblVzZSIgLz4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgaWQ9 ImxpbmVhckdyYWRpZW50NTQ0My05IgogICAgICAgb3NiOnBhaW50PSJzb2xpZCI+CiAgICAg IDxzdG9wCiAgICAgICAgIHN0eWxlPSJzdG9wLWNvbG9yOiNiM2NjZjg7c3RvcC1vcGFjaXR5 OjE7IgogICAgICAgICBvZmZzZXQ9IjAiCiAgICAgICAgIGlkPSJzdG9wNTQ0NS05IiAvPgog ICAgPC9saW5lYXJHcmFkaWVudD4KICAgIDxmaWx0ZXIKICAgICAgIGNvbG9yLWludGVycG9s YXRpb24tZmlsdGVycz0ic1JHQiIKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIK ICAgICAgIGlkPSJmaWx0ZXI1NDczLTgiCiAgICAgICB4PSItMC4xMDA0IgogICAgICAgd2lk dGg9IjEuMjAwNzk5OSIKICAgICAgIHk9Ii0wLjE0OTEwODkiCiAgICAgICBoZWlnaHQ9IjEu Mjk4MjE3OCI+CiAgICAgIDxmZUdhdXNzaWFuQmx1cgogICAgICAgICBpbmtzY2FwZTpjb2xs ZWN0PSJhbHdheXMiCiAgICAgICAgIHN0ZERldmlhdGlvbj0iNi4zMzg3MDcyIgogICAgICAg ICBpZD0iZmVHYXVzc2lhbkJsdXI1NDc1LTMiIC8+CiAgICA8L2ZpbHRlcj4KICAgIDxsaW5l YXJHcmFkaWVudAogICAgICAgZ3JhZGllbnRUcmFuc2Zvcm09InRyYW5zbGF0ZSg0NjUuMTA0 MjEsMzExLjIzMTA1KSIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICB4Mj0iMjMyLjMx NDc3IgogICAgICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgxPSI3Ni43OTE5MDEiCiAgICAg ICBncmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIKICAgICAgIGlkPSJsaW5lYXJHcmFk aWVudDU0OTMtOCIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMtOSIK ICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIgLz4KICAgIDxsaW5lYXJHcmFkaWVu dAogICAgICAgZ3JhZGllbnRUcmFuc2Zvcm09InRyYW5zbGF0ZSg0NjUuMTA0MjEsMzExLjIz MTA1KSIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICB4Mj0iMjMyLjMxNDc3IgogICAg ICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgxPSI3Ni43OTE5MDEiCiAgICAgICBncmFkaWVu dFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVudDU0OTMt OC05IgogICAgICAgeGxpbms6aHJlZj0iI2xpbmVhckdyYWRpZW50NTQ0My05LTgiCiAgICAg ICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiIC8+CiAgICA8bGluZWFyR3JhZGllbnQKICAg ICAgIGlkPSJsaW5lYXJHcmFkaWVudDU0NDMtOS04IgogICAgICAgb3NiOnBhaW50PSJzb2xp ZCI+CiAgICAgIDxzdG9wCiAgICAgICAgIHN0eWxlPSJzdG9wLWNvbG9yOiNiM2NjZjg7c3Rv cC1vcGFjaXR5OjE7IgogICAgICAgICBvZmZzZXQ9IjAiCiAgICAgICAgIGlkPSJzdG9wNTQ0 NS05LTYiIC8+CiAgICA8L2xpbmVhckdyYWRpZW50PgogICAgPGZpbHRlcgogICAgICAgY29s b3ItaW50ZXJwb2xhdGlvbi1maWx0ZXJzPSJzUkdCIgogICAgICAgaW5rc2NhcGU6Y29sbGVj dD0iYWx3YXlzIgogICAgICAgaWQ9ImZpbHRlcjU0NzMtOC02IgogICAgICAgeD0iLTAuMTAw NCIKICAgICAgIHdpZHRoPSIxLjIwMDc5OTkiCiAgICAgICB5PSItMC4xNDkxMDg5IgogICAg ICAgaGVpZ2h0PSIxLjI5ODIxNzgiPgogICAgICA8ZmVHYXVzc2lhbkJsdXIKICAgICAgICAg aW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAgICBzdGREZXZpYXRpb249IjYuMzM4 NzA3MiIKICAgICAgICAgaWQ9ImZlR2F1c3NpYW5CbHVyNTQ3NS0zLTIiIC8+CiAgICA8L2Zp bHRlcj4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgZ3JhZGllbnRUcmFuc2Zvcm09InRy YW5zbGF0ZSg0NjUuMTA0MTYsNDgzLjU4NjQ0KSIKICAgICAgIHkyPSIxODEuMTA1NjIiCiAg ICAgICB4Mj0iMjMyLjMxNDc3IgogICAgICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgxPSI3 Ni43OTE5MDEiCiAgICAgICBncmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIKICAgICAg IGlkPSJsaW5lYXJHcmFkaWVudDU0OTMtNDUtMyIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5l YXJHcmFkaWVudDU0NDMtNi04IgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIiAv PgogICAgPGxpbmVhckdyYWRpZW50CiAgICAgICBpZD0ibGluZWFyR3JhZGllbnQ1NDQzLTYt OCIKICAgICAgIG9zYjpwYWludD0ic29saWQiPgogICAgICA8c3RvcAogICAgICAgICBzdHls ZT0ic3RvcC1jb2xvcjojYjNjY2Y4O3N0b3Atb3BhY2l0eToxOyIKICAgICAgICAgb2Zmc2V0 PSIwIgogICAgICAgICBpZD0ic3RvcDU0NDUtMC0yIiAvPgogICAgPC9saW5lYXJHcmFkaWVu dD4KICAgIDxmaWx0ZXIKICAgICAgIGNvbG9yLWludGVycG9sYXRpb24tZmlsdGVycz0ic1JH QiIKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIKICAgICAgIGlkPSJmaWx0ZXI1 NDczLTMtNiIKICAgICAgIHg9Ii0wLjEwMDQiCiAgICAgICB3aWR0aD0iMS4yMDA3OTk5Igog ICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhlaWdodD0iMS4yOTgyMTc4Ij4KICAgICAg PGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIKICAg ICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIiCiAgICAgICAgIGlkPSJmZUdhdXNzaWFu Qmx1cjU0NzUtNjItMiIgLz4KICAgIDwvZmlsdGVyPgogICAgPGxpbmVhckdyYWRpZW50CiAg ICAgICB5Mj0iMTgxLjEwNTYyIgogICAgICAgeDI9IjIzMi4zMTQ3NyIKICAgICAgIHkxPSIx ODEuMTA1NjIiCiAgICAgICB4MT0iNzYuNzkxOTAxIgogICAgICAgZ3JhZGllbnRUcmFuc2Zv cm09InRyYW5zbGF0ZSg0NjUuMTA0MTYsNDgzLjU4NjQ0KSIKICAgICAgIGdyYWRpZW50VW5p dHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50MTAzMzkiCiAg ICAgICB4bGluazpocmVmPSIjbGluZWFyR3JhZGllbnQ1NDQzLTYtOCIKICAgICAgIGlua3Nj YXBlOmNvbGxlY3Q9ImFsd2F5cyIgLz4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgZ3Jh ZGllbnRUcmFuc2Zvcm09InRyYW5zbGF0ZSgyMjkuOTE4ODgsMTM5LjU1NDYyKSIKICAgICAg IHkyPSIxODEuMTA1NjIiCiAgICAgICB4Mj0iMjMyLjMxNDc3IgogICAgICAgeTE9IjE4MS4x MDU2MiIKICAgICAgIHgxPSI3Ni43OTE5MDEiCiAgICAgICBncmFkaWVudFVuaXRzPSJ1c2Vy U3BhY2VPblVzZSIKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVudDU0OTMtMi0wIgogICAgICAg eGxpbms6aHJlZj0iI2xpbmVhckdyYWRpZW50NTQ0My0yMS0yIgogICAgICAgaW5rc2NhcGU6 Y29sbGVjdD0iYWx3YXlzIiAvPgogICAgPGxpbmVhckdyYWRpZW50CiAgICAgICBpZD0ibGlu ZWFyR3JhZGllbnQ1NDQzLTIxLTIiCiAgICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAg PHN0b3AKICAgICAgICAgc3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6 MTsiCiAgICAgICAgIG9mZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1LTQtMCIgLz4K ICAgIDwvbGluZWFyR3JhZGllbnQ+CiAgICA8ZmlsdGVyCiAgICAgICBjb2xvci1pbnRlcnBv bGF0aW9uLWZpbHRlcnM9InNSR0IiCiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMi CiAgICAgICBpZD0iZmlsdGVyNTQ3My05LTgiCiAgICAgICB4PSItMC4xMDA0IgogICAgICAg d2lkdGg9IjEuMjAwNzk5OSIKICAgICAgIHk9Ii0wLjE0OTEwODkiCiAgICAgICBoZWlnaHQ9 IjEuMjk4MjE3OCI+CiAgICAgIDxmZUdhdXNzaWFuQmx1cgogICAgICAgICBpbmtzY2FwZTpj b2xsZWN0PSJhbHdheXMiCiAgICAgICAgIHN0ZERldmlhdGlvbj0iNi4zMzg3MDcyIgogICAg ICAgICBpZD0iZmVHYXVzc2lhbkJsdXI1NDc1LTgtOSIgLz4KICAgIDwvZmlsdGVyPgogICAg PGxpbmVhckdyYWRpZW50CiAgICAgICB5Mj0iMTgxLjEwNTYyIgogICAgICAgeDI9IjIzMi4z MTQ3NyIKICAgICAgIHkxPSIxODEuMTA1NjIiCiAgICAgICB4MT0iNzYuNzkxOTAxIgogICAg ICAgZ3JhZGllbnRUcmFuc2Zvcm09InRyYW5zbGF0ZSgyMjkuOTE4ODgsMTM5LjU1NDYyKSIK ICAgICAgIGdyYWRpZW50VW5pdHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAgaWQ9ImxpbmVh ckdyYWRpZW50MTA0MDEiCiAgICAgICB4bGluazpocmVmPSIjbGluZWFyR3JhZGllbnQ1NDQz LTIxLTIiCiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiIC8+CiAgICA8bGluZWFy R3JhZGllbnQKICAgICAgIGdyYWRpZW50VHJhbnNmb3JtPSJ0cmFuc2xhdGUoNDY1LjEwNDE2 LDQ4My41ODY0NCkiCiAgICAgICB5Mj0iMTgxLjEwNTYyIgogICAgICAgeDI9IjIzMi4zMTQ3 NyIKICAgICAgIHkxPSIxODEuMTA1NjIiCiAgICAgICB4MT0iNzYuNzkxOTAxIgogICAgICAg Z3JhZGllbnRVbml0cz0idXNlclNwYWNlT25Vc2UiCiAgICAgICBpZD0ibGluZWFyR3JhZGll bnQ1NDkzLTQ1LTYiCiAgICAgICB4bGluazpocmVmPSIjbGluZWFyR3JhZGllbnQ1NDQzLTYt NyIKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIgLz4KICAgIDxsaW5lYXJHcmFk aWVudAogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ0My02LTciCiAgICAgICBvc2I6cGFp bnQ9InNvbGlkIj4KICAgICAgPHN0b3AKICAgICAgICAgc3R5bGU9InN0b3AtY29sb3I6I2Iz Y2NmODtzdG9wLW9wYWNpdHk6MTsiCiAgICAgICAgIG9mZnNldD0iMCIKICAgICAgICAgaWQ9 InN0b3A1NDQ1LTAtOCIgLz4KICAgIDwvbGluZWFyR3JhZGllbnQ+CiAgICA8ZmlsdGVyCiAg ICAgICBjb2xvci1pbnRlcnBvbGF0aW9uLWZpbHRlcnM9InNSR0IiCiAgICAgICBpbmtzY2Fw ZTpjb2xsZWN0PSJhbHdheXMiCiAgICAgICBpZD0iZmlsdGVyNTQ3My0zLTciCiAgICAgICB4 PSItMC4xMDA0IgogICAgICAgd2lkdGg9IjEuMjAwNzk5OSIKICAgICAgIHk9Ii0wLjE0OTEw ODkiCiAgICAgICBoZWlnaHQ9IjEuMjk4MjE3OCI+CiAgICAgIDxmZUdhdXNzaWFuQmx1cgog ICAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiCiAgICAgICAgIHN0ZERldmlhdGlv bj0iNi4zMzg3MDcyIgogICAgICAgICBpZD0iZmVHYXVzc2lhbkJsdXI1NDc1LTYyLTgiIC8+ CiAgICA8L2ZpbHRlcj4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgeTI9IjE4MS4xMDU2 MiIKICAgICAgIHgyPSIyMzIuMzE0NzciCiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAg eDE9Ijc2Ljc5MTkwMSIKICAgICAgIGdyYWRpZW50VHJhbnNmb3JtPSJ0cmFuc2xhdGUoNDY1 LjEwNDE2LDQ4My41ODY0NCkiCiAgICAgICBncmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVz ZSIKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVudDExMDc3IgogICAgICAgeGxpbms6aHJlZj0i I2xpbmVhckdyYWRpZW50NTQ0My02LTciCiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdh eXMiIC8+CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAgIGdyYWRpZW50VHJhbnNmb3JtPSJ0 cmFuc2xhdGUoLTEwLjAyMDkyOCwtMzYuMzY1NTA2KSIKICAgICAgIHkyPSIxODEuMTA1NjIi CiAgICAgICB4Mj0iMjMyLjMxNDc3IgogICAgICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgx PSI3Ni43OTE5MDEiCiAgICAgICBncmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIKICAg ICAgIGlkPSJsaW5lYXJHcmFkaWVudDU0OTMtNC01IgogICAgICAgeGxpbms6aHJlZj0iI2xp bmVhckdyYWRpZW50NTQ0My0yNy04IgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlz IiAvPgogICAgPGxpbmVhckdyYWRpZW50CiAgICAgICBpZD0ibGluZWFyR3JhZGllbnQ1NDQz LTI3LTgiCiAgICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAgPHN0b3AKICAgICAgICAg c3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6MTsiCiAgICAgICAgIG9m ZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1LTctOSIgLz4KICAgIDwvbGluZWFyR3Jh ZGllbnQ+CiAgICA8ZmlsdGVyCiAgICAgICBjb2xvci1pbnRlcnBvbGF0aW9uLWZpbHRlcnM9 InNSR0IiCiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiCiAgICAgICBpZD0iZmls dGVyNTQ3My0xMi0wIgogICAgICAgeD0iLTAuMTAwNCIKICAgICAgIHdpZHRoPSIxLjIwMDc5 OTkiCiAgICAgICB5PSItMC4xNDkxMDg5IgogICAgICAgaGVpZ2h0PSIxLjI5ODIxNzgiPgog ICAgICA8ZmVHYXVzc2lhbkJsdXIKICAgICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlz IgogICAgICAgICBzdGREZXZpYXRpb249IjYuMzM4NzA3MiIKICAgICAgICAgaWQ9ImZlR2F1 c3NpYW5CbHVyNTQ3NS02MC0wIiAvPgogICAgPC9maWx0ZXI+CiAgICA8bGluZWFyR3JhZGll bnQKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICB4Mj0iMjMyLjMxNDc3IgogICAgICAg eTE9IjE4MS4xMDU2MiIKICAgICAgIHgxPSI3Ni43OTE5MDEiCiAgICAgICBncmFkaWVudFRy YW5zZm9ybT0idHJhbnNsYXRlKC0xMC4wMjA5MjgsLTM2LjM2NTUwNikiCiAgICAgICBncmFk aWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVudDEx MTIzIgogICAgICAgeGxpbms6aHJlZj0iI2xpbmVhckdyYWRpZW50NTQ0My0yNy04IgogICAg ICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIiAvPgogICAgPGxpbmVhckdyYWRpZW50CiAg ICAgICBncmFkaWVudFRyYW5zZm9ybT0idHJhbnNsYXRlKDQ2NS4xMDQyLC0zNi4zNjU0ODQp IgogICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIHgyPSIyMzIuMzE0NzciCiAgICAgICB5 MT0iMTgxLjEwNTYyIgogICAgICAgeDE9Ijc2Ljc5MTkwMSIKICAgICAgIGdyYWRpZW50VW5p dHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ5My00OCIK ICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMtMi02IgogICAgICAgaW5r c2NhcGU6Y29sbGVjdD0iYWx3YXlzIiAvPgogICAgPGxpbmVhckdyYWRpZW50CiAgICAgICBp ZD0ibGluZWFyR3JhZGllbnQ1NDQzLTItNiIKICAgICAgIG9zYjpwYWludD0ic29saWQiPgog ICAgICA8c3RvcAogICAgICAgICBzdHlsZT0ic3RvcC1jb2xvcjojYjNjY2Y4O3N0b3Atb3Bh Y2l0eToxOyIKICAgICAgICAgb2Zmc2V0PSIwIgogICAgICAgICBpZD0ic3RvcDU0NDUtMy00 IiAvPgogICAgPC9saW5lYXJHcmFkaWVudD4KICAgIDxmaWx0ZXIKICAgICAgIGNvbG9yLWlu dGVycG9sYXRpb24tZmlsdGVycz0ic1JHQiIKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFs d2F5cyIKICAgICAgIGlkPSJmaWx0ZXI1NDczLTEtNiIKICAgICAgIHg9Ii0wLjEwMDQiCiAg ICAgICB3aWR0aD0iMS4yMDA3OTk5IgogICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhl aWdodD0iMS4yOTgyMTc4Ij4KICAgICAgPGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3Nj YXBlOmNvbGxlY3Q9ImFsd2F5cyIKICAgICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIi CiAgICAgICAgIGlkPSJmZUdhdXNzaWFuQmx1cjU0NzUtNi04IiAvPgogICAgPC9maWx0ZXI+ CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICB4Mj0i MjMyLjMxNDc3IgogICAgICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgxPSI3Ni43OTE5MDEi CiAgICAgICBncmFkaWVudFRyYW5zZm9ybT0idHJhbnNsYXRlKDQ2NS4xMDQyLC0zNi4zNjU0 ODQpIgogICAgICAgZ3JhZGllbnRVbml0cz0idXNlclNwYWNlT25Vc2UiCiAgICAgICBpZD0i bGluZWFyR3JhZGllbnQxMTIxNSIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVu dDU0NDMtMi02IgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIiAvPgogICAgPGxp bmVhckdyYWRpZW50CiAgICAgICB5Mj0iMTgxLjEwNTYyIgogICAgICAgeDI9IjIzMi4zMTQ3 NyIKICAgICAgIHkxPSIxODEuMTA1NjIiCiAgICAgICB4MT0iNzYuNzkxOTAxIgogICAgICAg Z3JhZGllbnRUcmFuc2Zvcm09InRyYW5zbGF0ZSgtMTAuMDIwOTI4LC0zNi4zNjU1MDYpIgog ICAgICAgZ3JhZGllbnRVbml0cz0idXNlclNwYWNlT25Vc2UiCiAgICAgICBpZD0ibGluZWFy R3JhZGllbnQxMTEyMy01IgogICAgICAgeGxpbms6aHJlZj0iI2xpbmVhckdyYWRpZW50NTQ0 My0yNy04LTEiCiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiIC8+CiAgICA8bGlu ZWFyR3JhZGllbnQKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVudDU0NDMtMjctOC0xIgogICAg ICAgb3NiOnBhaW50PSJzb2xpZCI+CiAgICAgIDxzdG9wCiAgICAgICAgIHN0eWxlPSJzdG9w LWNvbG9yOiNiM2NjZjg7c3RvcC1vcGFjaXR5OjE7IgogICAgICAgICBvZmZzZXQ9IjAiCiAg ICAgICAgIGlkPSJzdG9wNTQ0NS03LTktNSIgLz4KICAgIDwvbGluZWFyR3JhZGllbnQ+CiAg ICA8ZmlsdGVyCiAgICAgICBjb2xvci1pbnRlcnBvbGF0aW9uLWZpbHRlcnM9InNSR0IiCiAg ICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiCiAgICAgICBpZD0iZmlsdGVyNTQ3My0x Mi0wLTUiCiAgICAgICB4PSItMC4xMDA0IgogICAgICAgd2lkdGg9IjEuMjAwNzk5OSIKICAg ICAgIHk9Ii0wLjE0OTEwODkiCiAgICAgICBoZWlnaHQ9IjEuMjk4MjE3OCI+CiAgICAgIDxm ZUdhdXNzaWFuQmx1cgogICAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiCiAgICAg ICAgIHN0ZERldmlhdGlvbj0iNi4zMzg3MDcyIgogICAgICAgICBpZD0iZmVHYXVzc2lhbkJs dXI1NDc1LTYwLTAtOCIgLz4KICAgIDwvZmlsdGVyPgogICAgPGxpbmVhckdyYWRpZW50CiAg ICAgICB5Mj0iMTgxLjEwNTYyIgogICAgICAgeDI9IjIzMi4zMTQ3NyIKICAgICAgIHkxPSIx ODEuMTA1NjIiCiAgICAgICB4MT0iNzYuNzkxOTAxIgogICAgICAgZ3JhZGllbnRUcmFuc2Zv cm09InRyYW5zbGF0ZSgtMTAuMDIwOTI4LC0zNi4zNjU1MDYpIgogICAgICAgZ3JhZGllbnRV bml0cz0idXNlclNwYWNlT25Vc2UiCiAgICAgICBpZD0ibGluZWFyR3JhZGllbnQxMTI2MSIK ICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMtMjctOC0xIgogICAgICAg aW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIiAvPgogICAgPGxpbmVhckdyYWRpZW50CiAgICAg ICBncmFkaWVudFRyYW5zZm9ybT0idHJhbnNsYXRlKDIyOS45MTg4OCwxMzkuNTU0NjIpIgog ICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIHgyPSIyMzIuMzE0NzciCiAgICAgICB5MT0i MTgxLjEwNTYyIgogICAgICAgeDE9Ijc2Ljc5MTkwMSIKICAgICAgIGdyYWRpZW50VW5pdHM9 InVzZXJTcGFjZU9uVXNlIgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ5My0yLTQiCiAg ICAgICB4bGluazpocmVmPSIjbGluZWFyR3JhZGllbnQ1NDQzLTIxLTkiCiAgICAgICBpbmtz Y2FwZTpjb2xsZWN0PSJhbHdheXMiIC8+CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAgIGlk PSJsaW5lYXJHcmFkaWVudDU0NDMtMjEtOSIKICAgICAgIG9zYjpwYWludD0ic29saWQiPgog ICAgICA8c3RvcAogICAgICAgICBzdHlsZT0ic3RvcC1jb2xvcjojYjNjY2Y4O3N0b3Atb3Bh Y2l0eToxOyIKICAgICAgICAgb2Zmc2V0PSIwIgogICAgICAgICBpZD0ic3RvcDU0NDUtNC05 IiAvPgogICAgPC9saW5lYXJHcmFkaWVudD4KICAgIDxmaWx0ZXIKICAgICAgIGNvbG9yLWlu dGVycG9sYXRpb24tZmlsdGVycz0ic1JHQiIKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFs d2F5cyIKICAgICAgIGlkPSJmaWx0ZXI1NDczLTktMCIKICAgICAgIHg9Ii0wLjEwMDQiCiAg ICAgICB3aWR0aD0iMS4yMDA3OTk5IgogICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhl aWdodD0iMS4yOTgyMTc4Ij4KICAgICAgPGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3Nj YXBlOmNvbGxlY3Q9ImFsd2F5cyIKICAgICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIi CiAgICAgICAgIGlkPSJmZUdhdXNzaWFuQmx1cjU0NzUtOC0zIiAvPgogICAgPC9maWx0ZXI+ CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAgIHkyPSIxODEuMTA1NjIiCiAgICAgICB4Mj0i MjMyLjMxNDc3IgogICAgICAgeTE9IjE4MS4xMDU2MiIKICAgICAgIHgxPSI3Ni43OTE5MDEi CiAgICAgICBncmFkaWVudFRyYW5zZm9ybT0idHJhbnNsYXRlKDIyOS45MTg4OCwxMzkuNTU0 NjIpIgogICAgICAgZ3JhZGllbnRVbml0cz0idXNlclNwYWNlT25Vc2UiCiAgICAgICBpZD0i bGluZWFyR3JhZGllbnQxMTMyOCIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVu dDU0NDMtMjEtOSIKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIgLz4KICAgIDxt YXJrZXIKICAgICAgIGlua3NjYXBlOnN0b2NraWQ9IkFycm93MU1zdGFydCIKICAgICAgIG9y aWVudD0iYXV0byIKICAgICAgIHJlZlk9IjAiCiAgICAgICByZWZYPSIwIgogICAgICAgaWQ9 IkFycm93MU1zdGFydC0xIgogICAgICAgc3R5bGU9Im92ZXJmbG93OnZpc2libGUiPgogICAg ICA8cGF0aAogICAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItY3VydmF0dXJlPSIwIgogICAg ICAgICBpZD0icGF0aDU2MTQtNyIKICAgICAgICAgZD0iTSAwLDAgNSwtNSAtMTIuNSwwIDUs NSAwLDAgeiIKICAgICAgICAgc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojMDAw MDAwO3N0cm9rZS13aWR0aDoxcHQiCiAgICAgICAgIHRyYW5zZm9ybT0ibWF0cml4KDAuNCww LDAsMC40LDQsMCkiIC8+CiAgICA8L21hcmtlcj4KICAgIDxtYXJrZXIKICAgICAgIGlua3Nj YXBlOnN0b2NraWQ9IkFycm93MU1lbmQiCiAgICAgICBvcmllbnQ9ImF1dG8iCiAgICAgICBy ZWZZPSIwIgogICAgICAgcmVmWD0iMCIKICAgICAgIGlkPSJBcnJvdzFNZW5kLTQiCiAgICAg ICBzdHlsZT0ib3ZlcmZsb3c6dmlzaWJsZSI+CiAgICAgIDxwYXRoCiAgICAgICAgIGlua3Nj YXBlOmNvbm5lY3Rvci1jdXJ2YXR1cmU9IjAiCiAgICAgICAgIGlkPSJwYXRoNTYxNy0wIgog ICAgICAgICBkPSJNIDAsMCA1LC01IC0xMi41LDAgNSw1IDAsMCB6IgogICAgICAgICBzdHls ZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjFwdCIK ICAgICAgICAgdHJhbnNmb3JtPSJtYXRyaXgoLTAuNCwwLDAsLTAuNCwtNCwwKSIgLz4KICAg IDwvbWFya2VyPgogICAgPG1hcmtlcgogICAgICAgaW5rc2NhcGU6c3RvY2tpZD0iQXJyb3cx TXN0YXJ0IgogICAgICAgb3JpZW50PSJhdXRvIgogICAgICAgcmVmWT0iMCIKICAgICAgIHJl Zlg9IjAiCiAgICAgICBpZD0ibWFya2VyMzE5OCIKICAgICAgIHN0eWxlPSJvdmVyZmxvdzp2 aXNpYmxlIj4KICAgICAgPHBhdGgKICAgICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZh dHVyZT0iMCIKICAgICAgICAgaWQ9InBhdGgzMjAwIgogICAgICAgICBkPSJNIDAsMCA1LC01 IC0xMi41LDAgNSw1IDAsMCB6IgogICAgICAgICBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7 c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjFwdCIKICAgICAgICAgdHJhbnNmb3JtPSJt YXRyaXgoMC40LDAsMCwwLjQsNCwwKSIgLz4KICAgIDwvbWFya2VyPgogICAgPG1hcmtlcgog ICAgICAgaW5rc2NhcGU6c3RvY2tpZD0iQXJyb3cxTWVuZCIKICAgICAgIG9yaWVudD0iYXV0 byIKICAgICAgIHJlZlk9IjAiCiAgICAgICByZWZYPSIwIgogICAgICAgaWQ9Im1hcmtlcjMy MDIiCiAgICAgICBzdHlsZT0ib3ZlcmZsb3c6dmlzaWJsZSI+CiAgICAgIDxwYXRoCiAgICAg ICAgIGlua3NjYXBlOmNvbm5lY3Rvci1jdXJ2YXR1cmU9IjAiCiAgICAgICAgIGlkPSJwYXRo MzIwNCIKICAgICAgICAgZD0iTSAwLDAgNSwtNSAtMTIuNSwwIDUsNSAwLDAgeiIKICAgICAg ICAgc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0 aDoxcHQiCiAgICAgICAgIHRyYW5zZm9ybT0ibWF0cml4KC0wLjQsMCwwLC0wLjQsLTQsMCki IC8+CiAgICA8L21hcmtlcj4KICAgIDxtYXJrZXIKICAgICAgIGlua3NjYXBlOnN0b2NraWQ9 IkFycm93MU1zdGFydCIKICAgICAgIG9yaWVudD0iYXV0byIKICAgICAgIHJlZlk9IjAiCiAg ICAgICByZWZYPSIwIgogICAgICAgaWQ9Im1hcmtlcjMyMDYiCiAgICAgICBzdHlsZT0ib3Zl cmZsb3c6dmlzaWJsZSI+CiAgICAgIDxwYXRoCiAgICAgICAgIGlua3NjYXBlOmNvbm5lY3Rv ci1jdXJ2YXR1cmU9IjAiCiAgICAgICAgIGlkPSJwYXRoMzIwOCIKICAgICAgICAgZD0iTSAw LDAgNSwtNSAtMTIuNSwwIDUsNSAwLDAgeiIKICAgICAgICAgc3R5bGU9ImZpbGwtcnVsZTpl dmVub2RkO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDoxcHQiCiAgICAgICAgIHRyYW5z Zm9ybT0ibWF0cml4KDAuNCwwLDAsMC40LDQsMCkiIC8+CiAgICA8L21hcmtlcj4KICAgIDxt YXJrZXIKICAgICAgIGlua3NjYXBlOnN0b2NraWQ9IkFycm93MU1lbmQiCiAgICAgICBvcmll bnQ9ImF1dG8iCiAgICAgICByZWZZPSIwIgogICAgICAgcmVmWD0iMCIKICAgICAgIGlkPSJt YXJrZXIzMjEwIgogICAgICAgc3R5bGU9Im92ZXJmbG93OnZpc2libGUiPgogICAgICA8cGF0 aAogICAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItY3VydmF0dXJlPSIwIgogICAgICAgICBp ZD0icGF0aDMyMTIiCiAgICAgICAgIGQ9Ik0gMCwwIDUsLTUgLTEyLjUsMCA1LDUgMCwwIHoi CiAgICAgICAgIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzAwMDAwMDtzdHJv a2Utd2lkdGg6MXB0IgogICAgICAgICB0cmFuc2Zvcm09Im1hdHJpeCgtMC40LDAsMCwtMC40 LC00LDApIiAvPgogICAgPC9tYXJrZXI+CiAgICA8bWFya2VyCiAgICAgICBpbmtzY2FwZTpz dG9ja2lkPSJBcnJvdzFNc3RhcnQiCiAgICAgICBvcmllbnQ9ImF1dG8iCiAgICAgICByZWZZ PSIwIgogICAgICAgcmVmWD0iMCIKICAgICAgIGlkPSJtYXJrZXIzMjE0IgogICAgICAgc3R5 bGU9Im92ZXJmbG93OnZpc2libGUiPgogICAgICA8cGF0aAogICAgICAgICBpbmtzY2FwZTpj b25uZWN0b3ItY3VydmF0dXJlPSIwIgogICAgICAgICBpZD0icGF0aDMyMTYiCiAgICAgICAg IGQ9Ik0gMCwwIDUsLTUgLTEyLjUsMCA1LDUgMCwwIHoiCiAgICAgICAgIHN0eWxlPSJmaWxs LXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MXB0IgogICAgICAg ICB0cmFuc2Zvcm09Im1hdHJpeCgwLjQsMCwwLDAuNCw0LDApIiAvPgogICAgPC9tYXJrZXI+ CiAgICA8bWFya2VyCiAgICAgICBpbmtzY2FwZTpzdG9ja2lkPSJBcnJvdzFNZW5kIgogICAg ICAgb3JpZW50PSJhdXRvIgogICAgICAgcmVmWT0iMCIKICAgICAgIHJlZlg9IjAiCiAgICAg ICBpZD0ibWFya2VyMzIxOCIKICAgICAgIHN0eWxlPSJvdmVyZmxvdzp2aXNpYmxlIj4KICAg ICAgPHBhdGgKICAgICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMCIKICAg ICAgICAgaWQ9InBhdGgzMjIwIgogICAgICAgICBkPSJNIDAsMCA1LC01IC0xMi41LDAgNSw1 IDAsMCB6IgogICAgICAgICBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMwMDAw MDA7c3Ryb2tlLXdpZHRoOjFwdCIKICAgICAgICAgdHJhbnNmb3JtPSJtYXRyaXgoLTAuNCww LDAsLTAuNCwtNCwwKSIgLz4KICAgIDwvbWFya2VyPgogICAgPGxpbmVhckdyYWRpZW50CiAg ICAgICBpZD0ibGluZWFyR3JhZGllbnQ1NDQzLTI3LTgtMS00IgogICAgICAgb3NiOnBhaW50 PSJzb2xpZCI+CiAgICAgIDxzdG9wCiAgICAgICAgIHN0eWxlPSJzdG9wLWNvbG9yOiNiM2Nj Zjg7c3RvcC1vcGFjaXR5OjE7IgogICAgICAgICBvZmZzZXQ9IjAiCiAgICAgICAgIGlkPSJz dG9wNTQ0NS03LTktNS04IiAvPgogICAgPC9saW5lYXJHcmFkaWVudD4KICAgIDxsaW5lYXJH cmFkaWVudAogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50NTQ0My0yLTYtNSIKICAgICAgIG9z YjpwYWludD0ic29saWQiPgogICAgICA8c3RvcAogICAgICAgICBzdHlsZT0ic3RvcC1jb2xv cjojYjNjY2Y4O3N0b3Atb3BhY2l0eToxOyIKICAgICAgICAgb2Zmc2V0PSIwIgogICAgICAg ICBpZD0ic3RvcDU0NDUtMy00LTUiIC8+CiAgICA8L2xpbmVhckdyYWRpZW50PgogICAgPG1h cmtlcgogICAgICAgaW5rc2NhcGU6c3RvY2tpZD0iQXJyb3cxTXN0YXJ0IgogICAgICAgb3Jp ZW50PSJhdXRvIgogICAgICAgcmVmWT0iMCIKICAgICAgIHJlZlg9IjAiCiAgICAgICBpZD0i bWFya2VyMzIzMiIKICAgICAgIHN0eWxlPSJvdmVyZmxvdzp2aXNpYmxlIj4KICAgICAgPHBh dGgKICAgICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMCIKICAgICAgICAg aWQ9InBhdGgzMjM0IgogICAgICAgICBkPSJNIDAsMCA1LC01IC0xMi41LDAgNSw1IDAsMCB6 IgogICAgICAgICBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMwMDAwMDA7c3Ry b2tlLXdpZHRoOjFwdCIKICAgICAgICAgdHJhbnNmb3JtPSJtYXRyaXgoMC40LDAsMCwwLjQs NCwwKSIgLz4KICAgIDwvbWFya2VyPgogICAgPG1hcmtlcgogICAgICAgaW5rc2NhcGU6c3Rv Y2tpZD0iQXJyb3cxTWVuZCIKICAgICAgIG9yaWVudD0iYXV0byIKICAgICAgIHJlZlk9IjAi CiAgICAgICByZWZYPSIwIgogICAgICAgaWQ9Im1hcmtlcjMyMzYiCiAgICAgICBzdHlsZT0i b3ZlcmZsb3c6dmlzaWJsZSI+CiAgICAgIDxwYXRoCiAgICAgICAgIGlua3NjYXBlOmNvbm5l Y3Rvci1jdXJ2YXR1cmU9IjAiCiAgICAgICAgIGlkPSJwYXRoMzIzOCIKICAgICAgICAgZD0i TSAwLDAgNSwtNSAtMTIuNSwwIDUsNSAwLDAgeiIKICAgICAgICAgc3R5bGU9ImZpbGwtcnVs ZTpldmVub2RkO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDoxcHQiCiAgICAgICAgIHRy YW5zZm9ybT0ibWF0cml4KC0wLjQsMCwwLC0wLjQsLTQsMCkiIC8+CiAgICA8L21hcmtlcj4K ICAgIDxtYXJrZXIKICAgICAgIGlua3NjYXBlOnN0b2NraWQ9IkFycm93MU1zdGFydCIKICAg ICAgIG9yaWVudD0iYXV0byIKICAgICAgIHJlZlk9IjAiCiAgICAgICByZWZYPSIwIgogICAg ICAgaWQ9Im1hcmtlcjMyNDAiCiAgICAgICBzdHlsZT0ib3ZlcmZsb3c6dmlzaWJsZSI+CiAg ICAgIDxwYXRoCiAgICAgICAgIGlua3NjYXBlOmNvbm5lY3Rvci1jdXJ2YXR1cmU9IjAiCiAg ICAgICAgIGlkPSJwYXRoMzI0MiIKICAgICAgICAgZD0iTSAwLDAgNSwtNSAtMTIuNSwwIDUs NSAwLDAgeiIKICAgICAgICAgc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojMDAw MDAwO3N0cm9rZS13aWR0aDoxcHQiCiAgICAgICAgIHRyYW5zZm9ybT0ibWF0cml4KDAuNCww LDAsMC40LDQsMCkiIC8+CiAgICA8L21hcmtlcj4KICAgIDxtYXJrZXIKICAgICAgIGlua3Nj YXBlOnN0b2NraWQ9IkFycm93MU1lbmQiCiAgICAgICBvcmllbnQ9ImF1dG8iCiAgICAgICBy ZWZZPSIwIgogICAgICAgcmVmWD0iMCIKICAgICAgIGlkPSJtYXJrZXIzMjQ0IgogICAgICAg c3R5bGU9Im92ZXJmbG93OnZpc2libGUiPgogICAgICA8cGF0aAogICAgICAgICBpbmtzY2Fw ZTpjb25uZWN0b3ItY3VydmF0dXJlPSIwIgogICAgICAgICBpZD0icGF0aDMyNDYiCiAgICAg ICAgIGQ9Ik0gMCwwIDUsLTUgLTEyLjUsMCA1LDUgMCwwIHoiCiAgICAgICAgIHN0eWxlPSJm aWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MXB0IgogICAg ICAgICB0cmFuc2Zvcm09Im1hdHJpeCgtMC40LDAsMCwtMC40LC00LDApIiAvPgogICAgPC9t YXJrZXI+CiAgICA8bWFya2VyCiAgICAgICBpbmtzY2FwZTpzdG9ja2lkPSJBcnJvdzFNc3Rh cnQiCiAgICAgICBvcmllbnQ9ImF1dG8iCiAgICAgICByZWZZPSIwIgogICAgICAgcmVmWD0i MCIKICAgICAgIGlkPSJtYXJrZXIzMjQ4IgogICAgICAgc3R5bGU9Im92ZXJmbG93OnZpc2li bGUiPgogICAgICA8cGF0aAogICAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItY3VydmF0dXJl PSIwIgogICAgICAgICBpZD0icGF0aDMyNTAiCiAgICAgICAgIGQ9Ik0gMCwwIDUsLTUgLTEy LjUsMCA1LDUgMCwwIHoiCiAgICAgICAgIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJv a2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MXB0IgogICAgICAgICB0cmFuc2Zvcm09Im1hdHJp eCgwLjQsMCwwLDAuNCw0LDApIiAvPgogICAgPC9tYXJrZXI+CiAgICA8bWFya2VyCiAgICAg ICBpbmtzY2FwZTpzdG9ja2lkPSJBcnJvdzFNZW5kIgogICAgICAgb3JpZW50PSJhdXRvIgog ICAgICAgcmVmWT0iMCIKICAgICAgIHJlZlg9IjAiCiAgICAgICBpZD0ibWFya2VyMzI1MiIK ICAgICAgIHN0eWxlPSJvdmVyZmxvdzp2aXNpYmxlIj4KICAgICAgPHBhdGgKICAgICAgICAg aW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMCIKICAgICAgICAgaWQ9InBhdGgzMjU0 IgogICAgICAgICBkPSJNIDAsMCA1LC01IC0xMi41LDAgNSw1IDAsMCB6IgogICAgICAgICBz dHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjFw dCIKICAgICAgICAgdHJhbnNmb3JtPSJtYXRyaXgoLTAuNCwwLDAsLTAuNCwtNCwwKSIgLz4K ICAgIDwvbWFya2VyPgogICAgPG1hcmtlcgogICAgICAgaW5rc2NhcGU6c3RvY2tpZD0iQXJy b3cxTXN0YXJ0IgogICAgICAgb3JpZW50PSJhdXRvIgogICAgICAgcmVmWT0iMCIKICAgICAg IHJlZlg9IjAiCiAgICAgICBpZD0ibWFya2VyMzI1NiIKICAgICAgIHN0eWxlPSJvdmVyZmxv dzp2aXNpYmxlIj4KICAgICAgPHBhdGgKICAgICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1 cnZhdHVyZT0iMCIKICAgICAgICAgaWQ9InBhdGgzMjU4IgogICAgICAgICBkPSJNIDAsMCA1 LC01IC0xMi41LDAgNSw1IDAsMCB6IgogICAgICAgICBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5v ZGQ7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjFwdCIKICAgICAgICAgdHJhbnNmb3Jt PSJtYXRyaXgoMC40LDAsMCwwLjQsNCwwKSIgLz4KICAgIDwvbWFya2VyPgogICAgPG1hcmtl cgogICAgICAgaW5rc2NhcGU6c3RvY2tpZD0iQXJyb3cxTWVuZCIKICAgICAgIG9yaWVudD0i YXV0byIKICAgICAgIHJlZlk9IjAiCiAgICAgICByZWZYPSIwIgogICAgICAgaWQ9Im1hcmtl cjMyNjAiCiAgICAgICBzdHlsZT0ib3ZlcmZsb3c6dmlzaWJsZSI+CiAgICAgIDxwYXRoCiAg ICAgICAgIGlua3NjYXBlOmNvbm5lY3Rvci1jdXJ2YXR1cmU9IjAiCiAgICAgICAgIGlkPSJw YXRoMzI2MiIKICAgICAgICAgZD0iTSAwLDAgNSwtNSAtMTIuNSwwIDUsNSAwLDAgeiIKICAg ICAgICAgc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13 aWR0aDoxcHQiCiAgICAgICAgIHRyYW5zZm9ybT0ibWF0cml4KC0wLjQsMCwwLC0wLjQsLTQs MCkiIC8+CiAgICA8L21hcmtlcj4KICAgIDxtYXJrZXIKICAgICAgIGlua3NjYXBlOnN0b2Nr aWQ9IkFycm93MU1zdGFydCIKICAgICAgIG9yaWVudD0iYXV0byIKICAgICAgIHJlZlk9IjAi CiAgICAgICByZWZYPSIwIgogICAgICAgaWQ9Im1hcmtlcjMyNjQiCiAgICAgICBzdHlsZT0i b3ZlcmZsb3c6dmlzaWJsZSI+CiAgICAgIDxwYXRoCiAgICAgICAgIGlua3NjYXBlOmNvbm5l Y3Rvci1jdXJ2YXR1cmU9IjAiCiAgICAgICAgIGlkPSJwYXRoMzI2NiIKICAgICAgICAgZD0i TSAwLDAgNSwtNSAtMTIuNSwwIDUsNSAwLDAgeiIKICAgICAgICAgc3R5bGU9ImZpbGwtcnVs ZTpldmVub2RkO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDoxcHQiCiAgICAgICAgIHRy YW5zZm9ybT0ibWF0cml4KDAuNCwwLDAsMC40LDQsMCkiIC8+CiAgICA8L21hcmtlcj4KICAg IDxtYXJrZXIKICAgICAgIGlua3NjYXBlOnN0b2NraWQ9IkFycm93MU1lbmQiCiAgICAgICBv cmllbnQ9ImF1dG8iCiAgICAgICByZWZZPSIwIgogICAgICAgcmVmWD0iMCIKICAgICAgIGlk PSJtYXJrZXIzMjY4IgogICAgICAgc3R5bGU9Im92ZXJmbG93OnZpc2libGUiPgogICAgICA8 cGF0aAogICAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItY3VydmF0dXJlPSIwIgogICAgICAg ICBpZD0icGF0aDMyNzAiCiAgICAgICAgIGQ9Ik0gMCwwIDUsLTUgLTEyLjUsMCA1LDUgMCww IHoiCiAgICAgICAgIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzAwMDAwMDtz dHJva2Utd2lkdGg6MXB0IgogICAgICAgICB0cmFuc2Zvcm09Im1hdHJpeCgtMC40LDAsMCwt MC40LC00LDApIiAvPgogICAgPC9tYXJrZXI+CiAgICA8bWFya2VyCiAgICAgICBpbmtzY2Fw ZTpzdG9ja2lkPSJBcnJvdzFNc3RhcnQiCiAgICAgICBvcmllbnQ9ImF1dG8iCiAgICAgICBy ZWZZPSIwIgogICAgICAgcmVmWD0iMCIKICAgICAgIGlkPSJtYXJrZXIzMjcyIgogICAgICAg c3R5bGU9Im92ZXJmbG93OnZpc2libGUiPgogICAgICA8cGF0aAogICAgICAgICBpbmtzY2Fw ZTpjb25uZWN0b3ItY3VydmF0dXJlPSIwIgogICAgICAgICBpZD0icGF0aDMyNzQiCiAgICAg ICAgIGQ9Ik0gMCwwIDUsLTUgLTEyLjUsMCA1LDUgMCwwIHoiCiAgICAgICAgIHN0eWxlPSJm aWxsLXJ1bGU6ZXZlbm9kZDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MXB0IgogICAg ICAgICB0cmFuc2Zvcm09Im1hdHJpeCgwLjQsMCwwLDAuNCw0LDApIiAvPgogICAgPC9tYXJr ZXI+CiAgICA8bWFya2VyCiAgICAgICBpbmtzY2FwZTpzdG9ja2lkPSJBcnJvdzFNZW5kIgog ICAgICAgb3JpZW50PSJhdXRvIgogICAgICAgcmVmWT0iMCIKICAgICAgIHJlZlg9IjAiCiAg ICAgICBpZD0ibWFya2VyMzI3NiIKICAgICAgIHN0eWxlPSJvdmVyZmxvdzp2aXNpYmxlIj4K ICAgICAgPHBhdGgKICAgICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMCIK ICAgICAgICAgaWQ9InBhdGgzMjc4IgogICAgICAgICBkPSJNIDAsMCA1LC01IC0xMi41LDAg NSw1IDAsMCB6IgogICAgICAgICBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7c3Ryb2tlOiMw MDAwMDA7c3Ryb2tlLXdpZHRoOjFwdCIKICAgICAgICAgdHJhbnNmb3JtPSJtYXRyaXgoLTAu NCwwLDAsLTAuNCwtNCwwKSIgLz4KICAgIDwvbWFya2VyPgogICAgPGxpbmVhckdyYWRpZW50 CiAgICAgICB5Mj0iMTgxLjEwNTYyIgogICAgICAgeDI9IjIzMi4zMTQ3NyIKICAgICAgIHkx PSIxODEuMTA1NjIiCiAgICAgICB4MT0iNzYuNzkxOTAxIgogICAgICAgZ3JhZGllbnRUcmFu c2Zvcm09InRyYW5zbGF0ZSg0NjUuMTA0MTYsNDgzLjU4NjQ0KSIKICAgICAgIGdyYWRpZW50 VW5pdHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50MTEwNzct MSIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMtNi03LTEiCiAgICAg ICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiIC8+CiAgICA8bGluZWFyR3JhZGllbnQKICAg ICAgIGlkPSJsaW5lYXJHcmFkaWVudDU0NDMtNi03LTEiCiAgICAgICBvc2I6cGFpbnQ9InNv bGlkIj4KICAgICAgPHN0b3AKICAgICAgICAgc3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtz dG9wLW9wYWNpdHk6MTsiCiAgICAgICAgIG9mZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1 NDQ1LTAtOC01IiAvPgogICAgPC9saW5lYXJHcmFkaWVudD4KICAgIDxmaWx0ZXIKICAgICAg IGNvbG9yLWludGVycG9sYXRpb24tZmlsdGVycz0ic1JHQiIKICAgICAgIGlua3NjYXBlOmNv bGxlY3Q9ImFsd2F5cyIKICAgICAgIGlkPSJmaWx0ZXI1NDczLTMtNy0yIgogICAgICAgeD0i LTAuMTAwNCIKICAgICAgIHdpZHRoPSIxLjIwMDc5OTkiCiAgICAgICB5PSItMC4xNDkxMDg5 IgogICAgICAgaGVpZ2h0PSIxLjI5ODIxNzgiPgogICAgICA8ZmVHYXVzc2lhbkJsdXIKICAg ICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAgICBzdGREZXZpYXRpb249 IjYuMzM4NzA3MiIKICAgICAgICAgaWQ9ImZlR2F1c3NpYW5CbHVyNTQ3NS02Mi04LTciIC8+ CiAgICA8L2ZpbHRlcj4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgeTI9IjE4MS4xMDU2 MiIKICAgICAgIHgyPSIyMzIuMzE0NzciCiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAg eDE9Ijc2Ljc5MTkwMSIKICAgICAgIGdyYWRpZW50VHJhbnNmb3JtPSJ0cmFuc2xhdGUoMjI5 LjkxODg4LDEzOS41NTQ2MikiCiAgICAgICBncmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVz ZSIKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVudDEwNDAxLTYiCiAgICAgICB4bGluazpocmVm PSIjbGluZWFyR3JhZGllbnQ1NDQzLTIxLTItMSIKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9 ImFsd2F5cyIgLz4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgaWQ9ImxpbmVhckdyYWRp ZW50NTQ0My0yMS0yLTEiCiAgICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAgPHN0b3AK ICAgICAgICAgc3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6MTsiCiAg ICAgICAgIG9mZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1LTQtMC00IiAvPgogICAg PC9saW5lYXJHcmFkaWVudD4KICAgIDxmaWx0ZXIKICAgICAgIGNvbG9yLWludGVycG9sYXRp b24tZmlsdGVycz0ic1JHQiIKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIKICAg ICAgIGlkPSJmaWx0ZXI1NDczLTktOC0yIgogICAgICAgeD0iLTAuMTAwNCIKICAgICAgIHdp ZHRoPSIxLjIwMDc5OTkiCiAgICAgICB5PSItMC4xNDkxMDg5IgogICAgICAgaGVpZ2h0PSIx LjI5ODIxNzgiPgogICAgICA8ZmVHYXVzc2lhbkJsdXIKICAgICAgICAgaW5rc2NhcGU6Y29s bGVjdD0iYWx3YXlzIgogICAgICAgICBzdGREZXZpYXRpb249IjYuMzM4NzA3MiIKICAgICAg ICAgaWQ9ImZlR2F1c3NpYW5CbHVyNTQ3NS04LTktMyIgLz4KICAgIDwvZmlsdGVyPgogICAg PGxpbmVhckdyYWRpZW50CiAgICAgICBncmFkaWVudFRyYW5zZm9ybT0idHJhbnNsYXRlKDQ2 NS4xMDQyMSwzMTEuMjMxMDUpIgogICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIHgyPSIy MzIuMzE0NzciCiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAgeDE9Ijc2Ljc5MTkwMSIK ICAgICAgIGdyYWRpZW50VW5pdHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAgaWQ9ImxpbmVh ckdyYWRpZW50NTQ5My04LTktMiIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVu dDU0NDMtOS04LTIiCiAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiIC8+CiAgICA8 bGluZWFyR3JhZGllbnQKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVudDU0NDMtOS04LTIiCiAg ICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAgPHN0b3AKICAgICAgICAgc3R5bGU9InN0 b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6MTsiCiAgICAgICAgIG9mZnNldD0iMCIK ICAgICAgICAgaWQ9InN0b3A1NDQ1LTktNi0xIiAvPgogICAgPC9saW5lYXJHcmFkaWVudD4K ICAgIDxmaWx0ZXIKICAgICAgIGNvbG9yLWludGVycG9sYXRpb24tZmlsdGVycz0ic1JHQiIK ICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIKICAgICAgIGlkPSJmaWx0ZXI1NDcz LTgtNi02IgogICAgICAgeD0iLTAuMTAwNCIKICAgICAgIHdpZHRoPSIxLjIwMDc5OTkiCiAg ICAgICB5PSItMC4xNDkxMDg5IgogICAgICAgaGVpZ2h0PSIxLjI5ODIxNzgiPgogICAgICA8 ZmVHYXVzc2lhbkJsdXIKICAgICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAg ICAgICBzdGREZXZpYXRpb249IjYuMzM4NzA3MiIKICAgICAgICAgaWQ9ImZlR2F1c3NpYW5C bHVyNTQ3NS0zLTItOCIgLz4KICAgIDwvZmlsdGVyPgogICAgPGxpbmVhckdyYWRpZW50CiAg ICAgICB5Mj0iMTgxLjEwNTYyIgogICAgICAgeDI9IjIzMi4zMTQ3NyIKICAgICAgIHkxPSIx ODEuMTA1NjIiCiAgICAgICB4MT0iNzYuNzkxOTAxIgogICAgICAgZ3JhZGllbnRUcmFuc2Zv cm09InRyYW5zbGF0ZSg0NjUuMTA0MTYsNDgzLjU4NjQ0KSIKICAgICAgIGdyYWRpZW50VW5p dHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAgaWQ9ImxpbmVhckdyYWRpZW50MTAzMzktNSIK ICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMtNi04LTciCiAgICAgICBp bmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiIC8+CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAg IGlkPSJsaW5lYXJHcmFkaWVudDU0NDMtNi04LTciCiAgICAgICBvc2I6cGFpbnQ9InNvbGlk Ij4KICAgICAgPHN0b3AKICAgICAgICAgc3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9w LW9wYWNpdHk6MTsiCiAgICAgICAgIG9mZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1 LTAtMi02IiAvPgogICAgPC9saW5lYXJHcmFkaWVudD4KICAgIDxmaWx0ZXIKICAgICAgIGNv bG9yLWludGVycG9sYXRpb24tZmlsdGVycz0ic1JHQiIKICAgICAgIGlua3NjYXBlOmNvbGxl Y3Q9ImFsd2F5cyIKICAgICAgIGlkPSJmaWx0ZXI1NDczLTMtNi0xIgogICAgICAgeD0iLTAu MTAwNCIKICAgICAgIHdpZHRoPSIxLjIwMDc5OTkiCiAgICAgICB5PSItMC4xNDkxMDg5Igog ICAgICAgaGVpZ2h0PSIxLjI5ODIxNzgiPgogICAgICA8ZmVHYXVzc2lhbkJsdXIKICAgICAg ICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAgICBzdGREZXZpYXRpb249IjYu MzM4NzA3MiIKICAgICAgICAgaWQ9ImZlR2F1c3NpYW5CbHVyNTQ3NS02Mi0yLTgiIC8+CiAg ICA8L2ZpbHRlcj4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgaWQ9ImxpbmVhckdyYWRp ZW50NTQ0My05LTciCiAgICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAgPHN0b3AKICAg ICAgICAgc3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6MTsiCiAgICAg ICAgIG9mZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1LTktOSIgLz4KICAgIDwvbGlu ZWFyR3JhZGllbnQ+CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAgIGlkPSJsaW5lYXJHcmFk aWVudDU0NDMtNi0yIgogICAgICAgb3NiOnBhaW50PSJzb2xpZCI+CiAgICAgIDxzdG9wCiAg ICAgICAgIHN0eWxlPSJzdG9wLWNvbG9yOiNiM2NjZjg7c3RvcC1vcGFjaXR5OjE7IgogICAg ICAgICBvZmZzZXQ9IjAiCiAgICAgICAgIGlkPSJzdG9wNTQ0NS0wLTMiIC8+CiAgICA8L2xp bmVhckdyYWRpZW50PgogICAgPGxpbmVhckdyYWRpZW50CiAgICAgICBncmFkaWVudFRyYW5z Zm9ybT0idHJhbnNsYXRlKC0xMC4wMjA5MjgsLTM2LjM2NTUwNikiCiAgICAgICB5Mj0iMTgx LjEwNTYyIgogICAgICAgeDI9IjIzMi4zMTQ3NyIKICAgICAgIHkxPSIxODEuMTA1NjIiCiAg ICAgICB4MT0iNzYuNzkxOTAxIgogICAgICAgZ3JhZGllbnRVbml0cz0idXNlclNwYWNlT25V c2UiCiAgICAgICBpZD0ibGluZWFyR3JhZGllbnQ1NDkzLTQtMSIKICAgICAgIHhsaW5rOmhy ZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMtMjctMSIKICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9 ImFsd2F5cyIgLz4KICAgIDxsaW5lYXJHcmFkaWVudAogICAgICAgaWQ9ImxpbmVhckdyYWRp ZW50NTQ0My0yNy0xIgogICAgICAgb3NiOnBhaW50PSJzb2xpZCI+CiAgICAgIDxzdG9wCiAg ICAgICAgIHN0eWxlPSJzdG9wLWNvbG9yOiNiM2NjZjg7c3RvcC1vcGFjaXR5OjE7IgogICAg ICAgICBvZmZzZXQ9IjAiCiAgICAgICAgIGlkPSJzdG9wNTQ0NS03LTMiIC8+CiAgICA8L2xp bmVhckdyYWRpZW50PgogICAgPGZpbHRlcgogICAgICAgY29sb3ItaW50ZXJwb2xhdGlvbi1m aWx0ZXJzPSJzUkdCIgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAg aWQ9ImZpbHRlcjU0NzMtMTItOCIKICAgICAgIHg9Ii0wLjEwMDQiCiAgICAgICB3aWR0aD0i MS4yMDA3OTk5IgogICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhlaWdodD0iMS4yOTgy MTc4Ij4KICAgICAgPGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9 ImFsd2F5cyIKICAgICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIiCiAgICAgICAgIGlk PSJmZUdhdXNzaWFuQmx1cjU0NzUtNjAtNyIgLz4KICAgIDwvZmlsdGVyPgogICAgPGxpbmVh ckdyYWRpZW50CiAgICAgICBncmFkaWVudFRyYW5zZm9ybT0idHJhbnNsYXRlKDQ2NS4xMDQy LC0zNi4zNjU0ODQpIgogICAgICAgeTI9IjE4MS4xMDU2MiIKICAgICAgIHgyPSIyMzIuMzE0 NzciCiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAgeDE9Ijc2Ljc5MTkwMSIKICAgICAg IGdyYWRpZW50VW5pdHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAgaWQ9ImxpbmVhckdyYWRp ZW50NTQ5My00MiIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMtMi03 IgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIiAvPgogICAgPGxpbmVhckdyYWRp ZW50CiAgICAgICBpZD0ibGluZWFyR3JhZGllbnQ1NDQzLTItNyIKICAgICAgIG9zYjpwYWlu dD0ic29saWQiPgogICAgICA8c3RvcAogICAgICAgICBzdHlsZT0ic3RvcC1jb2xvcjojYjNj Y2Y4O3N0b3Atb3BhY2l0eToxOyIKICAgICAgICAgb2Zmc2V0PSIwIgogICAgICAgICBpZD0i c3RvcDU0NDUtMy03IiAvPgogICAgPC9saW5lYXJHcmFkaWVudD4KICAgIDxmaWx0ZXIKICAg ICAgIGNvbG9yLWludGVycG9sYXRpb24tZmlsdGVycz0ic1JHQiIKICAgICAgIGlua3NjYXBl OmNvbGxlY3Q9ImFsd2F5cyIKICAgICAgIGlkPSJmaWx0ZXI1NDczLTEtOSIKICAgICAgIHg9 Ii0wLjEwMDQiCiAgICAgICB3aWR0aD0iMS4yMDA3OTk5IgogICAgICAgeT0iLTAuMTQ5MTA4 OSIKICAgICAgIGhlaWdodD0iMS4yOTgyMTc4Ij4KICAgICAgPGZlR2F1c3NpYW5CbHVyCiAg ICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIKICAgICAgICAgc3RkRGV2aWF0aW9u PSI2LjMzODcwNzIiCiAgICAgICAgIGlkPSJmZUdhdXNzaWFuQmx1cjU0NzUtNi0zIiAvPgog ICAgPC9maWx0ZXI+CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAgIGlkPSJsaW5lYXJHcmFk aWVudDU0NDMtMjEtOTgiCiAgICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAgPHN0b3AK ICAgICAgICAgc3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6MTsiCiAg ICAgICAgIG9mZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1LTQtNiIgLz4KICAgIDwv bGluZWFyR3JhZGllbnQ+CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAgIGlua3NjYXBlOmNv bGxlY3Q9ImFsd2F5cyIKICAgICAgIHhsaW5rOmhyZWY9IiNsaW5lYXJHcmFkaWVudDU0NDMt OCIKICAgICAgIGlkPSJsaW5lYXJHcmFkaWVudDU0NTEtMiIKICAgICAgIHgxPSI3Ni43OTE5 MDEiCiAgICAgICB5MT0iMTgxLjEwNTYyIgogICAgICAgeDI9IjIzMi4zMTQ3NyIKICAgICAg IHkyPSIxODEuMTA1NjIiCiAgICAgICBncmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIK ICAgICAgIGdyYWRpZW50VHJhbnNmb3JtPSJ0cmFuc2xhdGUoLTEwLjAyMDkxNSwxMzkuNTU0 NjEpIiAvPgogICAgPGxpbmVhckdyYWRpZW50CiAgICAgICBpZD0ibGluZWFyR3JhZGllbnQ1 NDQzLTgiCiAgICAgICBvc2I6cGFpbnQ9InNvbGlkIj4KICAgICAgPHN0b3AKICAgICAgICAg c3R5bGU9InN0b3AtY29sb3I6I2IzY2NmODtzdG9wLW9wYWNpdHk6MTsiCiAgICAgICAgIG9m ZnNldD0iMCIKICAgICAgICAgaWQ9InN0b3A1NDQ1LTYiIC8+CiAgICA8L2xpbmVhckdyYWRp ZW50PgogICAgPGZpbHRlcgogICAgICAgY29sb3ItaW50ZXJwb2xhdGlvbi1maWx0ZXJzPSJz UkdCIgogICAgICAgaW5rc2NhcGU6Y29sbGVjdD0iYWx3YXlzIgogICAgICAgaWQ9ImZpbHRl cjU0NzMtMCIKICAgICAgIHg9Ii0wLjEwMDQiCiAgICAgICB3aWR0aD0iMS4yMDA3OTk5Igog ICAgICAgeT0iLTAuMTQ5MTA4OSIKICAgICAgIGhlaWdodD0iMS4yOTgyMTc4Ij4KICAgICAg PGZlR2F1c3NpYW5CbHVyCiAgICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5cyIKICAg ICAgICAgc3RkRGV2aWF0aW9uPSI2LjMzODcwNzIiCiAgICAgICAgIGlkPSJmZUdhdXNzaWFu Qmx1cjU0NzUtMiIgLz4KICAgIDwvZmlsdGVyPgogICAgPGxpbmVhckdyYWRpZW50CiAgICAg ICBpZD0ibGluZWFyR3JhZGllbnQ1NDQzLTIxLTktOCIKICAgICAgIG9zYjpwYWludD0ic29s aWQiPgogICAgICA8c3RvcAogICAgICAgICBzdHlsZT0ic3RvcC1jb2xvcjojYjNjY2Y4O3N0 b3Atb3BhY2l0eToxOyIKICAgICAgICAgb2Zmc2V0PSIwIgogICAgICAgICBpZD0ic3RvcDU0 NDUtNC05LTYiIC8+CiAgICA8L2xpbmVhckdyYWRpZW50PgogICAgPGxpbmVhckdyYWRpZW50 CiAgICAgICB5Mj0iMTgxLjEwNTYyIgogICAgICAgeDI9IjIzMi4zMTQ3NyIKICAgICAgIHkx PSIxODEuMTA1NjIiCiAgICAgICB4MT0iNzYuNzkxOTAxIgogICAgICAgZ3JhZGllbnRUcmFu c2Zvcm09InRyYW5zbGF0ZSgtMTAuMDIwOTI4LC0zNi4zNjU1MDYpIgogICAgICAgZ3JhZGll bnRVbml0cz0idXNlclNwYWNlT25Vc2UiCiAgICAgICBpZD0ibGluZWFyR3JhZGllbnQxMTEy My05IgogICAgICAgeGxpbms6aHJlZj0iI2xpbmVhckdyYWRpZW50NTQ0My0yNy04LTAiCiAg ICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiIC8+CiAgICA8bGluZWFyR3JhZGllbnQK ICAgICAgIGlkPSJsaW5lYXJHcmFkaWVudDU0NDMtMjctOC0wIgogICAgICAgb3NiOnBhaW50 PSJzb2xpZCI+CiAgICAgIDxzdG9wCiAgICAgICAgIHN0eWxlPSJzdG9wLWNvbG9yOiNiM2Nj Zjg7c3RvcC1vcGFjaXR5OjE7IgogICAgICAgICBvZmZzZXQ9IjAiCiAgICAgICAgIGlkPSJz dG9wNTQ0NS03LTktMCIgLz4KICAgIDwvbGluZWFyR3JhZGllbnQ+CiAgICA8ZmlsdGVyCiAg ICAgICBjb2xvci1pbnRlcnBvbGF0aW9uLWZpbHRlcnM9InNSR0IiCiAgICAgICBpbmtzY2Fw ZTpjb2xsZWN0PSJhbHdheXMiCiAgICAgICBpZD0iZmlsdGVyNTQ3My0xMi0wLTYiCiAgICAg ICB4PSItMC4xMDA0IgogICAgICAgd2lkdGg9IjEuMjAwNzk5OSIKICAgICAgIHk9Ii0wLjE0 OTEwODkiCiAgICAgICBoZWlnaHQ9IjEuMjk4MjE3OCI+CiAgICAgIDxmZUdhdXNzaWFuQmx1 cgogICAgICAgICBpbmtzY2FwZTpjb2xsZWN0PSJhbHdheXMiCiAgICAgICAgIHN0ZERldmlh dGlvbj0iNi4zMzg3MDcyIgogICAgICAgICBpZD0iZmVHYXVzc2lhbkJsdXI1NDc1LTYwLTAt MSIgLz4KICAgIDwvZmlsdGVyPgogIDwvZGVmcz4KICA8c29kaXBvZGk6bmFtZWR2aWV3CiAg ICAgaWQ9ImJhc2UiCiAgICAgcGFnZWNvbG9yPSIjZmZmZmZmIgogICAgIGJvcmRlcmNvbG9y PSIjNjY2NjY2IgogICAgIGJvcmRlcm9wYWNpdHk9IjEuMCIKICAgICBpbmtzY2FwZTpwYWdl b3BhY2l0eT0iMC4wIgogICAgIGlua3NjYXBlOnBhZ2VzaGFkb3c9IjIiCiAgICAgaW5rc2Nh cGU6em9vbT0iMS4wMTY1MDU3IgogICAgIGlua3NjYXBlOmN4PSIzNTkuNDIyMDIiCiAgICAg aW5rc2NhcGU6Y3k9IjMyNS45Njc2OCIKICAgICBpbmtzY2FwZTpkb2N1bWVudC11bml0cz0i cHgiCiAgICAgaW5rc2NhcGU6Y3VycmVudC1sYXllcj0ibGF5ZXIxIgogICAgIHNob3dncmlk PSJmYWxzZSIKICAgICBpbmtzY2FwZTp3aW5kb3ctd2lkdGg9IjEyNzkiCiAgICAgaW5rc2Nh cGU6d2luZG93LWhlaWdodD0iMTA4MSIKICAgICBpbmtzY2FwZTp3aW5kb3cteD0iMjEyOSIK ICAgICBpbmtzY2FwZTp3aW5kb3cteT0iNDgiCiAgICAgaW5rc2NhcGU6d2luZG93LW1heGlt aXplZD0iMCIKICAgICBpbmtzY2FwZTpvYmplY3Qtbm9kZXM9InRydWUiIC8+CiAgPG1ldGFk YXRhCiAgICAgaWQ9Im1ldGFkYXRhNyI+CiAgICA8cmRmOlJERj4KICAgICAgPGNjOldvcmsK ICAgICAgICAgcmRmOmFib3V0PSIiPgogICAgICAgIDxkYzpmb3JtYXQ+aW1hZ2Uvc3ZnK3ht bDwvZGM6Zm9ybWF0PgogICAgICAgIDxkYzp0eXBlCiAgICAgICAgICAgcmRmOnJlc291cmNl PSJodHRwOi8vcHVybC5vcmcvZGMvZGNtaXR5cGUvU3RpbGxJbWFnZSIgLz4KICAgICAgICA8 ZGM6dGl0bGUgLz4KICAgICAgPC9jYzpXb3JrPgogICAgPC9yZGY6UkRGPgogIDwvbWV0YWRh dGE+CiAgPGcKICAgICBpbmtzY2FwZTpsYWJlbD0iTGF5ZXIgMSIKICAgICBpbmtzY2FwZTpn cm91cG1vZGU9ImxheWVyIgogICAgIGlkPSJsYXllcjEiPgogICAgPHJlY3QKICAgICAgIHN0 eWxlPSJmaWxsOiMxODAwODY7ZmlsbC1vcGFjaXR5OjAuMjMyODA0MjQ7ZmlsbC1ydWxlOm5v bnplcm87c3Ryb2tlOiMwMDI2MDA7c3Ryb2tlLXdpZHRoOjEuMDE5ODQ1MDE7c3Ryb2tlLWxp bmVjYXA6c3F1YXJlO3N0cm9rZS1saW5lam9pbjpiZXZlbDtzdHJva2UtbWl0ZXJsaW1pdDo0 O3N0cm9rZS1vcGFjaXR5OjAuNTUwMjY0NTU7c3Ryb2tlLWRhc2hhcnJheToxLjAxOTg0NTAx LCAyLjAzOTY5MDAxO3N0cm9rZS1kYXNob2Zmc2V0OjAiCiAgICAgICBpZD0icmVjdDM4NTIi CiAgICAgICB3aWR0aD0iNDE4LjA5ODk3IgogICAgICAgaGVpZ2h0PSIzNDQuODE2OCIKICAg ICAgIHg9IjI3NC45MDEzNyIKICAgICAgIHk9IjY2Ny45MzUwNiIKICAgICAgIHJ5PSIyMi4y MDgwODgiIC8+CiAgICA8cmVjdAogICAgICAgc3R5bGU9ImZpbGw6IzAwYmUwMDtmaWxsLW9w YWNpdHk6MC4xMjY5ODQxMjtmaWxsLXJ1bGU6bm9uemVybztzdHJva2U6IzAwMjYwMDtzdHJv a2Utd2lkdGg6MS42ODcxNTI2MjtzdHJva2UtbGluZWNhcDpzcXVhcmU7c3Ryb2tlLWxpbmVq b2luOmJldmVsO3N0cm9rZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MC41NTAyNjQ1 NTtzdHJva2UtZGFzaGFycmF5Om5vbmU7c3Ryb2tlLWRhc2hvZmZzZXQ6MCIKICAgICAgIGlk PSJyZWN0MTA0MzItNS0yLTUiCiAgICAgICB3aWR0aD0iMTUzLjg1MTc2IgogICAgICAgaGVp Z2h0PSIxMDguNDAzNTQiCiAgICAgICB4PSIyODMuMTkzNTEiCiAgICAgICB5PSI4OS4zNjMx NjciCiAgICAgICByeT0iMjEuMzUyMjA5IiAvPgogICAgPHJlY3QKICAgICAgIHN0eWxlPSJm aWxsOiMwMGJlMDA7ZmlsbC1vcGFjaXR5OjAuMTI2OTg0MTI7ZmlsbC1ydWxlOm5vbnplcm87 c3Ryb2tlOiMwMDI2MDA7c3Ryb2tlLXdpZHRoOjIuNTI2ODY2NDQ7c3Ryb2tlLWxpbmVjYXA6 c3F1YXJlO3N0cm9rZS1saW5lam9pbjpiZXZlbDtzdHJva2UtbWl0ZXJsaW1pdDo0O3N0cm9r ZS1vcGFjaXR5OjAuNTUwMjY0NTU7c3Ryb2tlLWRhc2hhcnJheTpub25lO3N0cm9rZS1kYXNo b2Zmc2V0OjAiCiAgICAgICBpZD0icmVjdDEwNDMyLTUtMi0zIgogICAgICAgd2lkdGg9IjE5 NC40MzMxNCIKICAgICAgIGhlaWdodD0iMTkyLjQxMTczIgogICAgICAgeD0iMjEuMjkxODEx IgogICAgICAgeT0iNDg4LjY3MDAxIgogICAgICAgcnk9IjM3Ljg5OTI3MyIgLz4KICAgIDxy ZWN0CiAgICAgICBzdHlsZT0iZmlsbDojMDBiZTAwO2ZpbGwtb3BhY2l0eTowLjEyNjk4NDEy O2ZpbGwtcnVsZTpub256ZXJvO3N0cm9rZTojMDAyNjAwO3N0cm9rZS13aWR0aDoxLjIxNDU1 MTY5O3N0cm9rZS1saW5lY2FwOnNxdWFyZTtzdHJva2UtbGluZWpvaW46YmV2ZWw7c3Ryb2tl LW1pdGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eTowLjU1MDI2NDU1O3N0cm9rZS1kYXNoYXJy YXk6bm9uZTtzdHJva2UtZGFzaG9mZnNldDowIgogICAgICAgaWQ9InJlY3QxMDQzMi01LTIt MiIKICAgICAgIHdpZHRoPSIxMTIuOTEyMzgiCiAgICAgICBoZWlnaHQ9Ijc2LjU0NjkwNiIK ICAgICAgIHg9IjI5LjQwNjc4MiIKICAgICAgIHk9IjEwNS4zMzIxMiIKICAgICAgIHJ5PSIx NS4wNzc0MTgiIC8+CiAgICA8cmVjdAogICAgICAgc3R5bGU9ImZpbGw6dXJsKCNsaW5lYXJH cmFkaWVudDExMTIzKTtmaWxsLW9wYWNpdHk6MTtmaWxsLXJ1bGU6bm9uemVybztzdHJva2U6 IzAzMDA3ODtzdHJva2Utd2lkdGg6NDtzdHJva2UtbGluZWNhcDpzcXVhcmU7c3Ryb2tlLWxp bmVqb2luOm1pdGVyO3N0cm9rZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MTtzdHJv a2UtZGFzaGFycmF5Om5vbmU7c3Ryb2tlLWRhc2hvZmZzZXQ6MDtmaWx0ZXI6dXJsKCNmaWx0 ZXI1NDczLTEyLTApIgogICAgICAgaWQ9InJlY3QzMDE5LTktMCIKICAgICAgIHdpZHRoPSIx NTEuNTIyODciCiAgICAgICBoZWlnaHQ9IjEwMi4wMjU0MSIKICAgICAgIHg9IjY4Ljc3MDk5 NiIKICAgICAgIHk9IjkzLjcyNzQxNyIKICAgICAgIHRyYW5zZm9ybT0ibWF0cml4KDAuNDIx MDY5NCwwLDAsMC4zNTAzOTE4MiwyNS4wMDQ3ODYsOTIuODg5ODEpIiAvPgogICAgPHJlY3QK ICAgICAgIHN0eWxlPSJmaWxsOiMwMGJlMDA7ZmlsbC1vcGFjaXR5OjAuMTI2OTg0MTI7Zmls bC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMDI2MDA7c3Ryb2tlLXdpZHRoOjEuOTA4MTQ1OTtz dHJva2UtbGluZWNhcDpzcXVhcmU7c3Ryb2tlLWxpbmVqb2luOmJldmVsO3N0cm9rZS1taXRl cmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MC41NTAyNjQ1NTtzdHJva2UtZGFzaGFycmF5Om5v bmU7c3Ryb2tlLWRhc2hvZmZzZXQ6MCIKICAgICAgIGlkPSJyZWN0MTA0MzIiCiAgICAgICB3 aWR0aD0iMTc1Ljg1ODQiCiAgICAgICBoZWlnaHQ9IjEyMS4zMTAxNyIKICAgICAgIHg9IjMw My43NDYwMyIKICAgICAgIHk9IjI3Ni43Nzc5NSIKICAgICAgIHJ5PSIyMy44OTQ0MjQiIC8+ CiAgICA8cmVjdAogICAgICAgc3R5bGU9ImZpbGw6dXJsKCNsaW5lYXJHcmFkaWVudDExMzI4 KTtmaWxsLW9wYWNpdHk6MTtmaWxsLXJ1bGU6bm9uemVybztzdHJva2U6IzAzMDA3ODtzdHJv a2Utd2lkdGg6NDtzdHJva2UtbGluZWNhcDpzcXVhcmU7c3Ryb2tlLWxpbmVqb2luOm1pdGVy O3N0cm9rZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtZGFzaGFycmF5 Om5vbmU7c3Ryb2tlLWRhc2hvZmZzZXQ6MDtmaWx0ZXI6dXJsKCNmaWx0ZXI1NDczLTktMCki CiAgICAgICBpZD0icmVjdDMwMTktNC0wIgogICAgICAgd2lkdGg9IjE1MS41MjI4NyIKICAg ICAgIGhlaWdodD0iMTAyLjAyNTQxIgogICAgICAgeD0iMzA4LjcxMDgyIgogICAgICAgeT0i MjY5LjY0NzUyIgogICAgICAgdHJhbnNmb3JtPSJtYXRyaXgoMC40NzQ2MTkzNSwwLDAsMC4z OTU0NzkwMiwtMjMuMTA0NzI2LDQwMC40ODQ1NCkiIC8+CiAgICA8cmVjdAogICAgICAgc3R5 bGU9ImZpbGw6IzAwYmUwMDtmaWxsLW9wYWNpdHk6MC4xMjY5ODQxMjtmaWxsLXJ1bGU6bm9u emVybztzdHJva2U6IzAwMjYwMDtzdHJva2Utd2lkdGg6MS4yMTQ1NTE2OTtzdHJva2UtbGlu ZWNhcDpzcXVhcmU7c3Ryb2tlLWxpbmVqb2luOmJldmVsO3N0cm9rZS1taXRlcmxpbWl0OjQ7 c3Ryb2tlLW9wYWNpdHk6MC41NTAyNjQ1NTtzdHJva2UtZGFzaGFycmF5Om5vbmU7c3Ryb2tl LWRhc2hvZmZzZXQ6MCIKICAgICAgIGlkPSJyZWN0MTA0MzItNS0yIgogICAgICAgd2lkdGg9 IjExMi45MTIzOCIKICAgICAgIGhlaWdodD0iNzYuNTQ2OTA2IgogICAgICAgeD0iNTk2LjYw NDI1IgogICAgICAgeT0iNTA5LjIzMDcxIgogICAgICAgcnk9IjE1LjA3NzQxOCIgLz4KICAg IDxyZWN0CiAgICAgICBzdHlsZT0iZmlsbDojMDBiZTAwO2ZpbGwtb3BhY2l0eTowLjEyNjk4 NDEyO2ZpbGwtcnVsZTpub256ZXJvO3N0cm9rZTojMDAyNjAwO3N0cm9rZS13aWR0aDoxLjIx NDU1MTY5O3N0cm9rZS1saW5lY2FwOnNxdWFyZTtzdHJva2UtbGluZWpvaW46YmV2ZWw7c3Ry b2tlLW1pdGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eTowLjU1MDI2NDU1O3N0cm9rZS1kYXNo YXJyYXk6bm9uZTtzdHJva2UtZGFzaG9mZnNldDowIgogICAgICAgaWQ9InJlY3QxMDQzMi01 LTUiCiAgICAgICB3aWR0aD0iMTEyLjkxMjM4IgogICAgICAgaGVpZ2h0PSI3Ni41NDY5MDYi CiAgICAgICB4PSI1OTYuNjA0MjUiCiAgICAgICB5PSI0MTAuMjM1NzgiCiAgICAgICByeT0i MTUuMDc3NDE4IiAvPgogICAgPHJlY3QKICAgICAgIHN0eWxlPSJmaWxsOiMwMGJlMDA7Zmls bC1vcGFjaXR5OjAuMTI2OTg0MTI7ZmlsbC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMDI2MDA7 c3Ryb2tlLXdpZHRoOjEuMjE0NTUxNjk7c3Ryb2tlLWxpbmVjYXA6c3F1YXJlO3N0cm9rZS1s aW5lam9pbjpiZXZlbDtzdHJva2UtbWl0ZXJsaW1pdDo0O3N0cm9rZS1vcGFjaXR5OjAuNTUw MjY0NTU7c3Ryb2tlLWRhc2hhcnJheTpub25lO3N0cm9rZS1kYXNob2Zmc2V0OjAiCiAgICAg ICBpZD0icmVjdDEwNDMyLTUiCiAgICAgICB3aWR0aD0iMTEyLjkxMjM4IgogICAgICAgaGVp Z2h0PSI3Ni41NDY5MDYiCiAgICAgICB4PSI1OTYuNjA0MjUiCiAgICAgICB5PSIzMDkuNzI1 NTkiCiAgICAgICByeT0iMTUuMDc3NDE4IiAvPgogICAgPHJlY3QKICAgICAgIHN0eWxlPSJm aWxsOiMwMGJlMDA7ZmlsbC1vcGFjaXR5OjAuMTI2OTg0MTI7ZmlsbC1ydWxlOm5vbnplcm87 c3Ryb2tlOiMwMDI2MDA7c3Ryb2tlLXdpZHRoOjEuMjE0NTUxNjk7c3Ryb2tlLWxpbmVjYXA6 c3F1YXJlO3N0cm9rZS1saW5lam9pbjpiZXZlbDtzdHJva2UtbWl0ZXJsaW1pdDo0O3N0cm9r ZS1vcGFjaXR5OjAuNTUwMjY0NTU7c3Ryb2tlLWRhc2hhcnJheTpub25lO3N0cm9rZS1kYXNo b2Zmc2V0OjAiCiAgICAgICBpZD0icmVjdDEwNDMyLTUtNyIKICAgICAgIHdpZHRoPSIxMTIu OTEyMzgiCiAgICAgICBoZWlnaHQ9Ijc2LjU0NjkwNiIKICAgICAgIHg9IjU5Ni42MDQyNSIK ICAgICAgIHk9IjEzOS41MTQ5MSIKICAgICAgIHJ5PSIxNS4wNzc0MTgiIC8+CiAgICA8cmVj dAogICAgICAgc3R5bGU9ImZpbGw6IzAwYmUwMDtmaWxsLW9wYWNpdHk6MC4xMjY5ODQxMjtm aWxsLXJ1bGU6bm9uemVybztzdHJva2U6IzAwMjYwMDtzdHJva2Utd2lkdGg6MS40NTQ3NTUx OTtzdHJva2UtbGluZWNhcDpzcXVhcmU7c3Ryb2tlLWxpbmVqb2luOmJldmVsO3N0cm9rZS1t aXRlcmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MC41NTAyNjQ1NTtzdHJva2UtZGFzaGFycmF5 Om5vbmU7c3Ryb2tlLWRhc2hvZmZzZXQ6MCIKICAgICAgIGlkPSJyZWN0MTA0MzItNS0yLTEi CiAgICAgICB3aWR0aD0iOTkuNjM4OTMxIgogICAgICAgaGVpZ2h0PSIxMjQuNDQ4MDEiCiAg ICAgICB4PSIzNi4wNDM1MDMiCiAgICAgICB5PSIyNzQuMzk5OTYiCiAgICAgICByeT0iMjQu NTEyNDg0IiAvPgogICAgPHJlY3QKICAgICAgIHN0eWxlPSJmaWxsOnVybCgjbGluZWFyR3Jh ZGllbnQ1NDUxKTtmaWxsLW9wYWNpdHk6MTtmaWxsLXJ1bGU6bm9uemVybztzdHJva2U6IzAz MDA3ODtzdHJva2Utd2lkdGg6NDtzdHJva2UtbGluZWNhcDpzcXVhcmU7c3Ryb2tlLWxpbmVq b2luOm1pdGVyO3N0cm9rZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2Ut ZGFzaGFycmF5Om5vbmU7c3Ryb2tlLWRhc2hvZmZzZXQ6MDtmaWx0ZXI6dXJsKCNmaWx0ZXI1 NDczKSIKICAgICAgIGlkPSJyZWN0MzAxOSIKICAgICAgIHdpZHRoPSIxNTEuNTIyODciCiAg ICAgICBoZWlnaHQ9IjEwMi4wMjU0MSIKICAgICAgIHg9IjY4Ljc3MDk5NiIKICAgICAgIHk9 IjI2OS42NDc1MiIKICAgICAgIHRyYW5zZm9ybT0ibWF0cml4KDAuNDIxMDY5NCwwLDAsMC4z NTAzOTE4MiwyNS4wMDQ3ODYsMjU1LjA0MzkpIiAvPgogICAgPHJlY3QKICAgICAgIHN0eWxl PSJmaWxsOnVybCgjbGluZWFyR3JhZGllbnQ1NDkzLTIpO2ZpbGwtb3BhY2l0eToxO2ZpbGwt cnVsZTpub256ZXJvO3N0cm9rZTojMDMwMDc4O3N0cm9rZS13aWR0aDo0O3N0cm9rZS1saW5l Y2FwOnNxdWFyZTtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6NDtz dHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6bm9uZTtzdHJva2UtZGFzaG9mZnNl dDowO2ZpbHRlcjp1cmwoI2ZpbHRlcjU0NzMtOSkiCiAgICAgICBpZD0icmVjdDMwMTktNCIK ICAgICAgIHdpZHRoPSIxNTEuNTIyODciCiAgICAgICBoZWlnaHQ9IjEwMi4wMjU0MSIKICAg ICAgIHg9IjMwOC43MTA4MiIKICAgICAgIHk9IjI2OS42NDc1MiIKICAgICAgIHRyYW5zZm9y bT0ibWF0cml4KDAuNDc0NjE5MzUsMCwwLDAuMzk1NDc5MDIsLTEwNS43ODgwNSw0NTkuMTgw MikiIC8+CiAgICA8cmVjdAogICAgICAgc3R5bGU9ImZpbGw6dXJsKCNsaW5lYXJHcmFkaWVu dDU0OTMpO2ZpbGwtb3BhY2l0eToxO2ZpbGwtcnVsZTpub256ZXJvO3N0cm9rZTojMDMwMDc4 O3N0cm9rZS13aWR0aDo0O3N0cm9rZS1saW5lY2FwOnNxdWFyZTtzdHJva2UtbGluZWpvaW46 bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNo YXJyYXk6bm9uZTtzdHJva2UtZGFzaG9mZnNldDowO2ZpbHRlcjp1cmwoI2ZpbHRlcjU0NzMt MSkiCiAgICAgICBpZD0icmVjdDMwMTktOCIKICAgICAgIHdpZHRoPSIxNTEuNTIyODciCiAg ICAgICBoZWlnaHQ9IjEwMi4wMjU0MSIKICAgICAgIHg9IjU0My44OTYwNiIKICAgICAgIHk9 IjkzLjcyNzQxNyIKICAgICAgIHRyYW5zZm9ybT0ibWF0cml4KDAuNTczNzM5MywwLDAsMC40 OTYyMTQ4OCw0LjU5NzUzNTgsNzEuNzQyNzQyKSIgLz4KICAgIDxyZWN0CiAgICAgICBzdHls ZT0iZmlsbDp1cmwoI2xpbmVhckdyYWRpZW50NTQ5My00KTtmaWxsLW9wYWNpdHk6MTtmaWxs LXJ1bGU6bm9uemVybztzdHJva2U6IzAzMDA3ODtzdHJva2Utd2lkdGg6NDtzdHJva2UtbGlu ZWNhcDpzcXVhcmU7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1taXRlcmxpbWl0OjQ7 c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtZGFzaGFycmF5Om5vbmU7c3Ryb2tlLWRhc2hvZmZz ZXQ6MDtmaWx0ZXI6dXJsKCNmaWx0ZXI1NDczLTEyKSIKICAgICAgIGlkPSJyZWN0MzAxOS05 IgogICAgICAgd2lkdGg9IjE1MS41MjI4NyIKICAgICAgIGhlaWdodD0iMTAyLjAyNTQxIgog ICAgICAgeD0iNjguNzcwOTk2IgogICAgICAgeT0iOTMuNzI3NDE3IgogICAgICAgdHJhbnNm b3JtPSJtYXRyaXgoMC40MjEwNjk0LDAsMCwwLjM1MDM5MTgyLDI1LjAwNDc4NiwyNTUuMDQz OSkiIC8+CiAgICA8cmVjdAogICAgICAgc3R5bGU9ImZpbGw6dXJsKCNsaW5lYXJHcmFkaWVu dDU0OTMtNDUpO2ZpbGwtb3BhY2l0eToxO2ZpbGwtcnVsZTpub256ZXJvO3N0cm9rZTojMDMw MDc4O3N0cm9rZS13aWR0aDo0O3N0cm9rZS1saW5lY2FwOnNxdWFyZTtzdHJva2UtbGluZWpv aW46bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1k YXNoYXJyYXk6bm9uZTtzdHJva2UtZGFzaG9mZnNldDowO2ZpbHRlcjp1cmwoI2ZpbHRlcjU0 NzMtMykiCiAgICAgICBpZD0icmVjdDMwMTktODgiCiAgICAgICB3aWR0aD0iMTUxLjUyMjg3 IgogICAgICAgaGVpZ2h0PSIxMDIuMDI1NDEiCiAgICAgICB4PSI1NDMuODk2MDYiCiAgICAg ICB5PSI2MTMuNjc5MjYiCiAgICAgICB0cmFuc2Zvcm09Im1hdHJpeCgwLjQ3NDYxOTM1LDAs MCwwLjM5NTQ3OTAyLC0xMzQuNzI4MTksMzgzLjY3Njc1KSIgLz4KICAgIDxyZWN0CiAgICAg ICBzdHlsZT0iZmlsbDp1cmwoI2xpbmVhckdyYWRpZW50NTQ5My04KTtmaWxsLW9wYWNpdHk6 MTtmaWxsLXJ1bGU6bm9uemVybztzdHJva2U6IzAzMDA3ODtzdHJva2Utd2lkdGg6NDtzdHJv a2UtbGluZWNhcDpzcXVhcmU7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1taXRlcmxp bWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtZGFzaGFycmF5Om5vbmU7c3Ryb2tlLWRh c2hvZmZzZXQ6MDtmaWx0ZXI6dXJsKCNmaWx0ZXI1NDczLTgpIgogICAgICAgaWQ9InJlY3Qz MDE5LTYiCiAgICAgICB3aWR0aD0iMTUxLjUyMjg3IgogICAgICAgaGVpZ2h0PSIxMDIuMDI1 NDEiCiAgICAgICB4PSI1NDMuODk2MDYiCiAgICAgICB5PSI0NDEuMzIzOTciCiAgICAgICB0 cmFuc2Zvcm09Im1hdHJpeCgwLjQ3NDYxOTM1LDAsMCwwLjM5NTQ3OTAyLC0xMzQuNzI4MTks MzkxLjI4NTc2KSIgLz4KICAgIDxwYXRoCiAgICAgICBzdHlsZT0iZmlsbDpub25lO3N0cm9r ZTojMDAwMDAwO3N0cm9rZS13aWR0aDowLjQzMzI0NTlweDtzdHJva2UtbGluZWNhcDpidXR0 O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxIgogICAgICAgZD0ibSA3 Ni42ODk5Miw1ODUuOTk0NTkgMCwwIgogICAgICAgaWQ9InBhdGg1NTk0IgogICAgICAgaW5r c2NhcGU6Y29ubmVjdG9yLXR5cGU9InBvbHlsaW5lIgogICAgICAgaW5rc2NhcGU6Y29ubmVj dG9yLWN1cnZhdHVyZT0iMyIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tc3RhcnQ9IiNy ZWN0MzAxOS00IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFydC1wb2ludD0iZDQi CiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLWVuZD0iI3JlY3QzMDE5LTQiCiAgICAgICBp bmtzY2FwZTpjb25uZWN0aW9uLWVuZC1wb2ludD0iZDQiIC8+CiAgICA8dGV4dAogICAgICAg eG1sOnNwYWNlPSJwcmVzZXJ2ZSIKICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMjkxNDY5 NTdweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0 OmJvbGQ7Zm9udC1zdHJldGNoOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O2xpbmUtaGVpZ2h0 OjEyNSU7bGV0dGVyLXNwYWNpbmc6MHB4O3dvcmQtc3BhY2luZzowcHg7d3JpdGluZy1tb2Rl OmxyLXRiO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6IzAwNDEwMDtmaWxsLW9wYWNpdHk6MTtz dHJva2U6bm9uZTtmb250LWZhbWlseTpQbGFudGFnZW5ldCBDaGVyb2tlZTstaW5rc2NhcGUt Zm9udC1zcGVjaWZpY2F0aW9uOlBsYW50YWdlbmV0IENoZXJva2VlIEJvbGQiCiAgICAgICB4 PSI1OC44NDExNDUiCiAgICAgICB5PSIzMzEuNzE0NzUiCiAgICAgICBpZD0idGV4dDEwMTc0 IgogICAgICAgc29kaXBvZGk6bGluZXNwYWNpbmc9IjEyNSUiCiAgICAgICB0cmFuc2Zvcm09 InNjYWxlKDEuMDk2MjI1NCwwLjkxMjIyMTE2KSI+PHRzcGFuCiAgICAgICAgIHNvZGlwb2Rp OnJvbGU9ImxpbmUiCiAgICAgICAgIGlkPSJ0c3BhbjEwMTc2IgogICAgICAgICB4PSI1OC44 NDExNDUiCiAgICAgICAgIHk9IjMzMS43MTQ3NSI+UmVzdWx0czwvdHNwYW4+PHRzcGFuCiAg ICAgICAgIHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAgICAgICAgIHg9IjU4Ljg0MTE0NSIKICAg ICAgICAgeT0iMzQ3LjA3OTEiCiAgICAgICAgIGlkPSJ0c3BhbjEwMTc4Ij5WaWV3ZXI8L3Rz cGFuPjwvdGV4dD4KICAgIDx0ZXh0CiAgICAgICB4bWw6c3BhY2U9InByZXNlcnZlIgogICAg ICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4yOTE0Njk1N3B4O2ZvbnQtc3R5bGU6bm9ybWFsO2Zv bnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0cmV0Y2g6bm9ybWFs O3RleHQtYWxpZ246Y2VudGVyO2xpbmUtaGVpZ2h0OjEyNSU7bGV0dGVyLXNwYWNpbmc6MHB4 O3dvcmQtc3BhY2luZzowcHg7d3JpdGluZy1tb2RlOmxyLXRiO3RleHQtYW5jaG9yOm1pZGRs ZTtmaWxsOiMwMDNmMDA7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6 UGxhbnRhZ2VuZXQgQ2hlcm9rZWU7LWlua3NjYXBlLWZvbnQtc3BlY2lmaWNhdGlvbjpQbGFu dGFnZW5ldCBDaGVyb2tlZSBCb2xkIgogICAgICAgeD0iNzguMDE1OTkxIgogICAgICAgeT0i Mzk5LjI5MzY0IgogICAgICAgaWQ9InRleHQxMDE4MCIKICAgICAgIHNvZGlwb2RpOmxpbmVz cGFjaW5nPSIxMjUlIgogICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjA5NjIyNTQsMC45MTIy MjExNikiPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBp ZD0idHNwYW4xMDE4MiIKICAgICAgICAgeD0iNzguMDE1OTkxIgogICAgICAgICB5PSIzOTku MjkzNjQiPkNvbnRyb2xsZXI8L3RzcGFuPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xl PSJsaW5lIgogICAgICAgICB4PSI3OC4wMTU5OTEiCiAgICAgICAgIHk9IjQxNC42NTc5OSIK ICAgICAgICAgaWQ9InRzcGFuMTAxODQiPkZyb250LUVuZDwvdHNwYW4+PC90ZXh0PgogICAg PHRleHQKICAgICAgIHhtbDpzcGFjZT0icHJlc2VydmUiCiAgICAgICBzdHlsZT0iZm9udC1z aXplOjE0LjkzOTk4NzE4cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1h bDtmb250LXdlaWdodDpib2xkO2ZvbnQtc3RyZXRjaDpub3JtYWw7dGV4dC1hbGlnbjpjZW50 ZXI7bGluZS1oZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29yZC1zcGFjaW5nOjBw eDt3cml0aW5nLW1vZGU6bHItdGI7dGV4dC1hbmNob3I6bWlkZGxlO2ZpbGw6IzQxMDAwMDtm aWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpQbGFudGFnZW5ldCBDaGVy b2tlZTstaW5rc2NhcGUtZm9udC1zcGVjaWZpY2F0aW9uOlBsYW50YWdlbmV0IENoZXJva2Vl IEJvbGQiCiAgICAgICB4PSIzMzQuODg5MzQiCiAgICAgICB5PSIxNTAuMjEyOTEiCiAgICAg ICBpZD0idGV4dDEwMTg2IgogICAgICAgc29kaXBvZGk6bGluZXNwYWNpbmc9IjEyNSUiCiAg ICAgICB0cmFuc2Zvcm09InNjYWxlKDEuMDc1MjgyMSwwLjkyOTk4ODUyKSI+PHRzcGFuCiAg ICAgICAgIHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAgICAgICAgIGlkPSJ0c3BhbjEwMTg4Igog ICAgICAgICB4PSIzMzQuODg5MzQiCiAgICAgICAgIHk9IjE1MC4yMTI5MSI+UmVzdWx0czwv dHNwYW4+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAgICAgICAgIHg9 IjMzNC44ODkzNCIKICAgICAgICAgeT0iMTY4Ljg4Nzg5IgogICAgICAgICBpZD0idHNwYW4x MDE5MCI+RGF0YXN0b3JlPC90c3Bhbj48L3RleHQ+CiAgICA8dGV4dAogICAgICAgeG1sOnNw YWNlPSJwcmVzZXJ2ZSIKICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMTMwODg0MTdweDtm b250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0OmJvbGQ7 Zm9udC1zdHJldGNoOm5vcm1hbDt0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxMjUl O2xldHRlci1zcGFjaW5nOjBweDt3b3JkLXNwYWNpbmc6MHB4O3dyaXRpbmctbW9kZTpsci10 Yjt0ZXh0LWFuY2hvcjptaWRkbGU7ZmlsbDojMDAwMDgyO2ZpbGwtb3BhY2l0eToxO3N0cm9r ZTpub25lO2ZvbnQtZmFtaWx5OlBsYW50YWdlbmV0IENoZXJva2VlOy1pbmtzY2FwZS1mb250 LXNwZWNpZmljYXRpb246UGxhbnRhZ2VuZXQgQ2hlcm9rZWUgQm9sZCIKICAgICAgIHg9IjY5 LjY5ODczIgogICAgICAgeT0iNjQ2LjE1ODIiCiAgICAgICBpZD0idGV4dDEwMTkyIgogICAg ICAgc29kaXBvZGk6bGluZXNwYWNpbmc9IjEyNSUiCiAgICAgICB0cmFuc2Zvcm09InNjYWxl KDEuMDk1NDk2NSwwLjkxMjgyODExKSI+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9 ImxpbmUiCiAgICAgICAgIGlkPSJ0c3BhbjEwMTk0IgogICAgICAgICB4PSI2OS42OTg3MyIK ICAgICAgICAgeT0iNjQ2LjE1ODIiPkNvbnRyb2xsZXI8L3RzcGFuPjwvdGV4dD4KICAgIDx0 ZXh0CiAgICAgICB4bWw6c3BhY2U9InByZXNlcnZlIgogICAgICAgc3R5bGU9ImZvbnQtc2l6 ZToxMy44NjM4Njg3MXB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7 Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0cmV0Y2g6bm9ybWFsO3RleHQtYWxpZ246Y2VudGVy O2xpbmUtaGVpZ2h0OjEyNSU7bGV0dGVyLXNwYWNpbmc6MHB4O3dvcmQtc3BhY2luZzowcHg7 d3JpdGluZy1tb2RlOmxyLXRiO3RleHQtYW5jaG9yOm1pZGRsZTtmaWxsOiM0MTAwMDA7Zmls bC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6UGxhbnRhZ2VuZXQgQ2hlcm9r ZWU7LWlua3NjYXBlLWZvbnQtc3BlY2lmaWNhdGlvbjpQbGFudGFnZW5ldCBDaGVyb2tlZSBC b2xkIgogICAgICAgeD0iMTQ1LjIyMDIiCiAgICAgICB5PSI2NDYuNzA5MTEiCiAgICAgICBp ZD0idGV4dDEwMTk2IgogICAgICAgc29kaXBvZGk6bGluZXNwYWNpbmc9IjEyNSUiCiAgICAg ICB0cmFuc2Zvcm09InNjYWxlKDEuMDk1NDk2NSwwLjkxMjgyODExKSI+PHRzcGFuCiAgICAg ICAgIHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAgICAgICAgIGlkPSJ0c3BhbjEwMTk4IgogICAg ICAgICB4PSIxNDUuMjIwMiIKICAgICAgICAgeT0iNjQ2LjcwOTExIj5FdmFsdWF0b3I8L3Rz cGFuPjwvdGV4dD4KICAgIDx0ZXh0CiAgICAgICB4bWw6c3BhY2U9InByZXNlcnZlIgogICAg ICAgc3R5bGU9ImZvbnQtc2l6ZToxMy44NjM4Njg3MXB4O2ZvbnQtc3R5bGU6bm9ybWFsO2Zv bnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0cmV0Y2g6bm9ybWFs O3RleHQtYWxpZ246Y2VudGVyO2xpbmUtaGVpZ2h0OjEyNSU7bGV0dGVyLXNwYWNpbmc6MHB4 O3dvcmQtc3BhY2luZzowcHg7d3JpdGluZy1tb2RlOmxyLXRiO3RleHQtYW5jaG9yOm1pZGRs ZTtmaWxsOiM0ODAwMDA7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6 UGxhbnRhZ2VuZXQgQ2hlcm9rZWU7LWlua3NjYXBlLWZvbnQtc3BlY2lmaWNhdGlvbjpQbGFu dGFnZW5ldCBDaGVyb2tlZSBCb2xkIgogICAgICAgeD0iMTQ1LjEzMDcxIgogICAgICAgeT0i NzA0LjI4MTAxIgogICAgICAgaWQ9InRleHQxMDIwMCIKICAgICAgIHNvZGlwb2RpOmxpbmVz cGFjaW5nPSIxMjUlIgogICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjA5NTQ5NjUsMC45MTI4 MjgxMSkiPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBp ZD0idHNwYW4xMDIwMiIKICAgICAgICAgeD0iMTQ1LjEzMDcxIgogICAgICAgICB5PSI3MDQu MjgxMDEiPkRhdGE8L3RzcGFuPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5l IgogICAgICAgICB4PSIxNDUuMTMwNzEiCiAgICAgICAgIHk9IjcyMS42MTA4NCIKICAgICAg ICAgaWQ9InRzcGFuMTAyMDQiPkNvbGxlY3RvcjwvdHNwYW4+PC90ZXh0PgogICAgPHJlY3QK ICAgICAgIHN0eWxlPSJmaWxsOnVybCgjbGluZWFyR3JhZGllbnQxMDMzOSk7ZmlsbC1vcGFj aXR5OjE7ZmlsbC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMzAwNzg7c3Ryb2tlLXdpZHRoOjQ7 c3Ryb2tlLWxpbmVjYXA6c3F1YXJlO3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2UtbWl0 ZXJsaW1pdDo0O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLWRhc2hhcnJheTpub25lO3N0cm9r ZS1kYXNob2Zmc2V0OjA7ZmlsdGVyOnVybCgjZmlsdGVyNTQ3My0zLTYpIgogICAgICAgaWQ9 InJlY3QzMDE5LTg4LTciCiAgICAgICB3aWR0aD0iMTUxLjUyMjg3IgogICAgICAgaGVpZ2h0 PSIxMDIuMDI1NDEiCiAgICAgICB4PSI1NDMuODk2MDYiCiAgICAgICB5PSI2MTMuNjc5MjYi CiAgICAgICB0cmFuc2Zvcm09Im1hdHJpeCgwLjQyMTA2OTQsMCwwLDAuMzUwMzkxODIsMTcx LjE2MjUyLDEzNC43MjYzNSkiIC8+CiAgICA8cmVjdAogICAgICAgc3R5bGU9ImZpbGw6dXJs KCNsaW5lYXJHcmFkaWVudDU0OTMtOC05KTtmaWxsLW9wYWNpdHk6MTtmaWxsLXJ1bGU6bm9u emVybztzdHJva2U6IzAzMDA3ODtzdHJva2Utd2lkdGg6NDtzdHJva2UtbGluZWNhcDpzcXVh cmU7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9w YWNpdHk6MTtzdHJva2UtZGFzaGFycmF5Om5vbmU7c3Ryb2tlLWRhc2hvZmZzZXQ6MDtmaWx0 ZXI6dXJsKCNmaWx0ZXI1NDczLTgtNikiCiAgICAgICBpZD0icmVjdDMwMTktNi01IgogICAg ICAgd2lkdGg9IjE1MS41MjI4NyIKICAgICAgIGhlaWdodD0iMTAyLjAyNTQxIgogICAgICAg eD0iNTQzLjg5NjA2IgogICAgICAgeT0iNDQxLjMyMzk3IgogICAgICAgdHJhbnNmb3JtPSJt YXRyaXgoMC40MjEwNjk0LDAsMCwwLjM1MDM5MTgyLDE3MS4xNjI1MiwxMzQuNzI2MzUpIiAv PgogICAgPHRleHQKICAgICAgIHhtbDpzcGFjZT0icHJlc2VydmUiCiAgICAgICBzdHlsZT0i Zm9udC1zaXplOjEyLjI5MTQ2OTU3cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50 Om5vcm1hbDtmb250LXdlaWdodDpib2xkO2ZvbnQtc3RyZXRjaDpub3JtYWw7dGV4dC1hbGln bjpjZW50ZXI7bGluZS1oZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29yZC1zcGFj aW5nOjBweDt3cml0aW5nLW1vZGU6bHItdGI7dGV4dC1hbmNob3I6bWlkZGxlO2ZpbGw6IzQx MDAwMDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpQbGFudGFnZW5l dCBDaGVyb2tlZTstaW5rc2NhcGUtZm9udC1zcGVjaWZpY2F0aW9uOlBsYW50YWdlbmV0IENo ZXJva2VlIEJvbGQiCiAgICAgICB4PSIzOTMuOTIyODgiCiAgICAgICB5PSIzNDEuMDE2NTEi CiAgICAgICBpZD0idGV4dDEwMTk2LTciCiAgICAgICBzb2RpcG9kaTpsaW5lc3BhY2luZz0i MTI1JSIKICAgICAgIHRyYW5zZm9ybT0ic2NhbGUoMS4wOTYyMjU0LDAuOTEyMjIxMTYpIj48 dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAgICAgaWQ9InRzcGFu MTAxOTgtOCIKICAgICAgICAgeD0iMzkzLjkyMjg4IgogICAgICAgICB5PSIzNDEuMDE2NTEi PkV2YWx1YXRvcjwvdHNwYW4+PC90ZXh0PgogICAgPHRleHQKICAgICAgIHhtbDpzcGFjZT0i cHJlc2VydmUiCiAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjI5MTQ2OTU3cHg7Zm9udC1z dHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdlaWdodDpib2xkO2ZvbnQt c3RyZXRjaDpub3JtYWw7dGV4dC1hbGlnbjpjZW50ZXI7bGluZS1oZWlnaHQ6MTI1JTtsZXR0 ZXItc3BhY2luZzowcHg7d29yZC1zcGFjaW5nOjBweDt3cml0aW5nLW1vZGU6bHItdGI7dGV4 dC1hbmNob3I6bWlkZGxlO2ZpbGw6IzQ4MDAwMDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9u ZTtmb250LWZhbWlseTpQbGFudGFnZW5ldCBDaGVyb2tlZTstaW5rc2NhcGUtZm9udC1zcGVj aWZpY2F0aW9uOlBsYW50YWdlbmV0IENoZXJva2VlIEJvbGQiCiAgICAgICB4PSIzOTMuODQz NTQiCiAgICAgICB5PSIzOTkuNDQ5MTMiCiAgICAgICBpZD0idGV4dDEwMjAwLTIiCiAgICAg ICBzb2RpcG9kaTpsaW5lc3BhY2luZz0iMTI1JSIKICAgICAgIHRyYW5zZm9ybT0ic2NhbGUo MS4wOTYyMjU0LDAuOTEyMjIxMTYpIj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0i bGluZSIKICAgICAgICAgaWQ9InRzcGFuMTAyMDItNyIKICAgICAgICAgeD0iMzkzLjg0MzU0 IgogICAgICAgICB5PSIzOTkuNDQ5MTMiPkRhdGE8L3RzcGFuPjx0c3BhbgogICAgICAgICBz b2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICB4PSIzOTMuODQzNTQiCiAgICAgICAgIHk9 IjQxNC44MTM0OCIKICAgICAgICAgaWQ9InRzcGFuMTAyMDQtOCI+Q29sbGVjdG9yPC90c3Bh bj48L3RleHQ+CiAgICA8cmVjdAogICAgICAgc3R5bGU9ImZpbGw6dXJsKCNsaW5lYXJHcmFk aWVudDEwNDAxKTtmaWxsLW9wYWNpdHk6MTtmaWxsLXJ1bGU6bm9uemVybztzdHJva2U6IzAz MDA3ODtzdHJva2Utd2lkdGg6NDtzdHJva2UtbGluZWNhcDpzcXVhcmU7c3Ryb2tlLWxpbmVq b2luOm1pdGVyO3N0cm9rZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2Ut ZGFzaGFycmF5Om5vbmU7c3Ryb2tlLWRhc2hvZmZzZXQ6MDtmaWx0ZXI6dXJsKCNmaWx0ZXI1 NDczLTktOCkiCiAgICAgICBpZD0icmVjdDMwMTktNC0yIgogICAgICAgd2lkdGg9IjE1MS41 MjI4NyIKICAgICAgIGhlaWdodD0iMTAyLjAyNTQxIgogICAgICAgeD0iMzA4LjcxMDgyIgog ICAgICAgeT0iMjY5LjY0NzUyIgogICAgICAgdHJhbnNmb3JtPSJtYXRyaXgoMC40MjEwNjk0 LDAsMCwwLjM1MDM5MTgyLDE5MC4zODk3NywyMjQuMDY2MTcpIiAvPgogICAgPHBhdGgKICAg ICAgIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjAuMzg0 MTA4NDJweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJv a2Utb3BhY2l0eToxIgogICAgICAgZD0ibSAzNTIuMjc5MjcsMzM2LjQyMjg5IDAsMCIKICAg ICAgIGlkPSJwYXRoNTU5NC04IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLXR5cGU9InBv bHlsaW5lIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMyIKICAgICAg IGlua3NjYXBlOmNvbm5lY3Rpb24tc3RhcnQ9IiNyZWN0MzAxOS00LTIiCiAgICAgICBpbmtz Y2FwZTpjb25uZWN0aW9uLXN0YXJ0LXBvaW50PSJkNCIKICAgICAgIGlua3NjYXBlOmNvbm5l Y3Rpb24tZW5kPSIjcmVjdDMwMTktNC0yIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1l bmQtcG9pbnQ9ImQ0IiAvPgogICAgPHRleHQKICAgICAgIHhtbDpzcGFjZT0icHJlc2VydmUi CiAgICAgICBzdHlsZT0iZm9udC1zaXplOjEwLjc1NTAzNTRweDtmb250LXN0eWxlOm5vcm1h bDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1zdHJldGNoOm5v cm1hbDt0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxMjUlO2xldHRlci1zcGFjaW5n OjBweDt3b3JkLXNwYWNpbmc6MHB4O3dyaXRpbmctbW9kZTpsci10Yjt0ZXh0LWFuY2hvcjpt aWRkbGU7ZmlsbDojMDAwMDgyO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFt aWx5OlBsYW50YWdlbmV0IENoZXJva2VlOy1pbmtzY2FwZS1mb250LXNwZWNpZmljYXRpb246 UGxhbnRhZ2VuZXQgQ2hlcm9rZWUgQm9sZCIKICAgICAgIHg9IjMyMS4wNDY0NSIKICAgICAg IHk9IjM3My4wNTQ3OCIKICAgICAgIGlkPSJ0ZXh0MTAxOTItMiIKICAgICAgIHNvZGlwb2Rp OmxpbmVzcGFjaW5nPSIxMjUlIgogICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjA5NjIyNTQs MC45MTIyMjExNikiPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAg ICAgICBpZD0idHNwYW4xMDE5NC0wIgogICAgICAgICB4PSIzMjEuMDQ2NDUiCiAgICAgICAg IHk9IjM3My4wNTQ3OCI+Q29udHJvbGxlcjwvdHNwYW4+PC90ZXh0PgogICAgPHJlY3QKICAg ICAgIHN0eWxlPSJmaWxsOnVybCgjbGluZWFyR3JhZGllbnQxMTA3Nyk7ZmlsbC1vcGFjaXR5 OjE7ZmlsbC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMzAwNzg7c3Ryb2tlLXdpZHRoOjQ7c3Ry b2tlLWxpbmVjYXA6c3F1YXJlO3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2UtbWl0ZXJs aW1pdDo0O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLWRhc2hhcnJheTpub25lO3N0cm9rZS1k YXNob2Zmc2V0OjA7ZmlsdGVyOnVybCgjZmlsdGVyNTQ3My0zLTcpIgogICAgICAgaWQ9InJl Y3QzMDE5LTg4LTEiCiAgICAgICB3aWR0aD0iMTUxLjUyMjg3IgogICAgICAgaGVpZ2h0PSIx MDIuMDI1NDEiCiAgICAgICB4PSI1NDMuODk2MDYiCiAgICAgICB5PSI2MTMuNjc5MjYiCiAg ICAgICB0cmFuc2Zvcm09Im1hdHJpeCgwLjQyMTA2OTQsMCwwLDAuMzUwMzkxODIsMzkyLjE0 MTYyLC01NS4xMTQyNikiIC8+CiAgICA8dGV4dAogICAgICAgeG1sOnNwYWNlPSJwcmVzZXJ2 ZSIKICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMjkxNDY5NTdweDtmb250LXN0eWxlOm5v cm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1zdHJldGNo Om5vcm1hbDt0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxMjUlO2xldHRlci1zcGFj aW5nOjBweDt3b3JkLXNwYWNpbmc6MHB4O3dyaXRpbmctbW9kZTpsci10Yjt0ZXh0LWFuY2hv cjptaWRkbGU7ZmlsbDojNDgwMDAwO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQt ZmFtaWx5OlBsYW50YWdlbmV0IENoZXJva2VlOy1pbmtzY2FwZS1mb250LXNwZWNpZmljYXRp b246UGxhbnRhZ2VuZXQgQ2hlcm9rZWUgQm9sZCIKICAgICAgIHg9IjU5NS40MjUzNSIKICAg ICAgIHk9IjE5MS4zNDEwMyIKICAgICAgIGlkPSJ0ZXh0MTAyMDAtNiIKICAgICAgIHNvZGlw b2RpOmxpbmVzcGFjaW5nPSIxMjUlIgogICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjA5NjIy NTQsMC45MTIyMjExNikiPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgog ICAgICAgICBpZD0idHNwYW4xMDIwMi0wIgogICAgICAgICB4PSI1OTUuNDI1MzUiCiAgICAg ICAgIHk9IjE5MS4zNDEwMyI+RGF0YTwvdHNwYW4+PHRzcGFuCiAgICAgICAgIHNvZGlwb2Rp OnJvbGU9ImxpbmUiCiAgICAgICAgIHg9IjU5NS40MjUzNSIKICAgICAgICAgeT0iMjA2Ljcw NTM3IgogICAgICAgICBpZD0idHNwYW4xMDIwNC05Ij5Db2xsZWN0b3I8L3RzcGFuPjwvdGV4 dD4KICAgIDx0ZXh0CiAgICAgICB4bWw6c3BhY2U9InByZXNlcnZlIgogICAgICAgc3R5bGU9 ImZvbnQtc2l6ZToxMi4yOTE0Njk1N3B4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFu dDpub3JtYWw7Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0cmV0Y2g6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7bGluZS1oZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29yZC1zcGFj aW5nOjBweDt3cml0aW5nLW1vZGU6bHItdGI7dGV4dC1hbmNob3I6c3RhcnQ7ZmlsbDojMDA0 MTAwO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OlBsYW50YWdlbmV0 IENoZXJva2VlOy1pbmtzY2FwZS1mb250LXNwZWNpZmljYXRpb246UGxhbnRhZ2VuZXQgQ2hl cm9rZWUgQm9sZCIKICAgICAgIHg9IjU4Ljg0MTE0NSIKICAgICAgIHk9IjE1My45NTc0NCIK ICAgICAgIGlkPSJ0ZXh0MTAxNzQtNyIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIx MjUlIgogICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjA5NjIyNTQsMC45MTIyMjExNikiPjx0 c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBpZD0idHNwYW4x MDE3Ni0yIgogICAgICAgICB4PSI1OC44NDExNDUiCiAgICAgICAgIHk9IjE1My45NTc0NCI+ UmVzdWx0czwvdHNwYW4+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAg ICAgICAgIHg9IjU4Ljg0MTE0NSIKICAgICAgICAgeT0iMTY5LjMyMTc4IgogICAgICAgICBp ZD0idHNwYW4xMDE3OC01Ij5WaWV3ZXI8L3RzcGFuPjwvdGV4dD4KICAgIDxwYXRoCiAgICAg ICBzdHlsZT0iZmlsbDpub25lO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDoxcHg7c3Ry b2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6 MTttYXJrZXItc3RhcnQ6dXJsKCNBcnJvdzFNc3RhcnQpO21hcmtlci1lbmQ6dXJsKCNBcnJv dzFNZW5kKSIKICAgICAgIGQ9Im0gMTQyLjMxOTE2LDE0My41OTcyMSAxNDAuODc0MzUsLTAu MDIwOSIKICAgICAgIGlkPSJwYXRoMTExODIiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3It dHlwZT0icG9seWxpbmUiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItY3VydmF0dXJlPSIz IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFydD0iI3JlY3QxMDQzMi01LTItMiIK ICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tc3RhcnQtcG9pbnQ9ImQ0IgogICAgICAgaW5r c2NhcGU6Y29ubmVjdGlvbi1lbmQ9IiNyZWN0MTA0MzItNS0yLTUiCiAgICAgICBpbmtzY2Fw ZTpjb25uZWN0aW9uLWVuZC1wb2ludD0iZDQiIC8+CiAgICA8cGF0aAogICAgICAgc3R5bGU9 ImZpbGw6bm9uZTtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MXB4O3N0cm9rZS1saW5l Y2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZS1vcGFjaXR5OjE7bWFya2Vy LXN0YXJ0OnVybCgjQXJyb3cxTXN0YXJ0KTttYXJrZXItZW5kOnVybCgjQXJyb3cxTWVuZCki CiAgICAgICBkPSJNIDEzNS42ODI0MywzMDEuNTU0MjQgMjkwLjUzMTg3LDE5Mi41NTAxMiIK ICAgICAgIGlkPSJwYXRoMTExODQiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItdHlwZT0i cG9seWxpbmUiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItY3VydmF0dXJlPSIzIgogICAg ICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFydD0iI3JlY3QxMDQzMi01LTItMSIKICAgICAg IGlua3NjYXBlOmNvbm5lY3Rpb24tc3RhcnQtcG9pbnQ9ImQ0IgogICAgICAgaW5rc2NhcGU6 Y29ubmVjdGlvbi1lbmQ9IiNyZWN0MTA0MzItNS0yLTUiCiAgICAgICBpbmtzY2FwZTpjb25u ZWN0aW9uLWVuZC1wb2ludD0iZDQiIC8+CiAgICA8cGF0aAogICAgICAgc3R5bGU9ImZpbGw6 bm9uZTtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MS4wMjk5MDgzcHg7c3Ryb2tlLWxp bmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MTttYXJr ZXItc3RhcnQ6dXJsKCNBcnJvdzFNc3RhcnQpO21hcmtlci1lbmQ6dXJsKCNBcnJvdzFNZW5k KSIKICAgICAgIGQ9Ik0gNDYzLjk4MjE1LDI5MC45NTg4MiA2MjEuMTU5NjEsMTk1LjY2Mjgi CiAgICAgICBpZD0icGF0aDExMTg4IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLXR5cGU9 InBvbHlsaW5lIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMyIgLz4K ICAgIDxwYXRoCiAgICAgICBzdHlsZT0iZmlsbDpub25lO3N0cm9rZTojMDAwMDAwO3N0cm9r ZS13aWR0aDoxO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0 cm9rZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtZGFzaGFycmF5OjEs IDI7c3Ryb2tlLWRhc2hvZmZzZXQ6MDttYXJrZXItc3RhcnQ6dXJsKCNBcnJvdzFNc3RhcnQp O21hcmtlci1lbmQ6dXJsKCNBcnJvdzFNZW5kKSIKICAgICAgIGQ9Im0gNDYzLjk4MjE1LDM2 NC43OTUxOCAxMzIuNjIyMSwtMTEuNzgxMDQiCiAgICAgICBpZD0icGF0aDExMTkwIgogICAg ICAgaW5rc2NhcGU6Y29ubmVjdG9yLXR5cGU9InBvbHlsaW5lIgogICAgICAgaW5rc2NhcGU6 Y29ubmVjdG9yLWN1cnZhdHVyZT0iMyIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tc3Rh cnQ9IiNyZWN0MzAxOS04OC03IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFydC1w b2ludD0iZDQiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLWVuZD0iI3JlY3QxMDQzMi01 IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQtcG9pbnQ9ImQ0IiAvPgogICAgPHBh dGgKICAgICAgIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRo OjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1p dGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6MSwgMjtzdHJv a2UtZGFzaG9mZnNldDowO21hcmtlci1zdGFydDp1cmwoI0Fycm93MU1zdGFydCk7bWFya2Vy LWVuZDp1cmwoI0Fycm93MU1lbmQpIgogICAgICAgZD0ibSA0NjMuOTgyMTUsMzc5LjMwNDk1 IDEzMi42MjIxLDQ4LjU0MDgzIgogICAgICAgaWQ9InBhdGgxMTE5MiIKICAgICAgIGlua3Nj YXBlOmNvbm5lY3Rvci10eXBlPSJwb2x5bGluZSIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rv ci1jdXJ2YXR1cmU9IjMiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLXN0YXJ0PSIjcmVj dDMwMTktODgtNyIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tc3RhcnQtcG9pbnQ9ImQ0 IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQ9IiNyZWN0MTA0MzItNS01IgogICAg ICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQtcG9pbnQ9ImQ0IiAvPgogICAgPHBhdGgKICAg ICAgIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjE7c3Ry b2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1pdGVybGlt aXQ6NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6MSwgMjtzdHJva2UtZGFz aG9mZnNldDowO21hcmtlci1zdGFydDp1cmwoI0Fycm93MU1zdGFydCk7bWFya2VyLWVuZDp1 cmwoI0Fycm93MU1lbmQpIgogICAgICAgZD0iTSA0NTQuMDQwMzIsMzg1LjUwMzQxIDYwNi45 NjAzLDUwOS45NzkwMyIKICAgICAgIGlkPSJwYXRoMTExOTQiCiAgICAgICBpbmtzY2FwZTpj b25uZWN0b3ItdHlwZT0icG9seWxpbmUiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItY3Vy dmF0dXJlPSIzIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFydD0iI3JlY3QzMDE5 LTg4LTciCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLXN0YXJ0LXBvaW50PSJkNCIKICAg ICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tZW5kPSIjcmVjdDEwNDMyLTUtMiIKICAgICAgIGlu a3NjYXBlOmNvbm5lY3Rpb24tZW5kLXBvaW50PSJkNCIgLz4KICAgIDxyZWN0CiAgICAgICBz dHlsZT0iZmlsbDp1cmwoI2xpbmVhckdyYWRpZW50MTEyMTUpO2ZpbGwtb3BhY2l0eToxO2Zp bGwtcnVsZTpub256ZXJvO3N0cm9rZTojMDMwMDc4O3N0cm9rZS13aWR0aDo0O3N0cm9rZS1s aW5lY2FwOnNxdWFyZTtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6 NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6bm9uZTtzdHJva2UtZGFzaG9m ZnNldDowO2ZpbHRlcjp1cmwoI2ZpbHRlcjU0NzMtMS02KSIKICAgICAgIGlkPSJyZWN0MzAx OS04LTkiCiAgICAgICB3aWR0aD0iMTUxLjUyMjg3IgogICAgICAgaGVpZ2h0PSIxMDIuMDI1 NDEiCiAgICAgICB4PSI1NDMuODk2MDYiCiAgICAgICB5PSI5My43Mjc0MTciCiAgICAgICB0 cmFuc2Zvcm09Im1hdHJpeCgwLjQ3NTIxMDc4LDAsMCwwLjM5MzAzMzczLC0yMTcuNzc4LDU4 OC41MjA1OSkiIC8+CiAgICA8dGV4dAogICAgICAgeG1sOnNwYWNlPSJwcmVzZXJ2ZSIKICAg ICAgIHN0eWxlPSJmb250LXNpemU6MTIuMTAwODU0ODdweDtmb250LXN0eWxlOm5vcm1hbDtm b250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1zdHJldGNoOm5vcm1h bDt0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxMjUlO2xldHRlci1zcGFjaW5nOjBw eDt3b3JkLXNwYWNpbmc6MHB4O3dyaXRpbmctbW9kZTpsci10Yjt0ZXh0LWFuY2hvcjptaWRk bGU7ZmlsbDojNDEwMDAwO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5 OlBsYW50YWdlbmV0IENoZXJva2VlOy1pbmtzY2FwZS1mb250LXNwZWNpZmljYXRpb246UGxh bnRhZ2VuZXQgQ2hlcm9rZWUgQm9sZCIKICAgICAgIHg9IjY5LjczMDMxNiIKICAgICAgIHk9 IjcwNi4zMTAzNiIKICAgICAgIGlkPSJ0ZXh0MTAxODYtOCIKICAgICAgIHNvZGlwb2RpOmxp bmVzcGFjaW5nPSIxMjUlIgogICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjA5OTU4MzYsMC45 MDk0MzUxOCkiPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAg ICBpZD0idHNwYW4xMDE4OC0zIgogICAgICAgICB4PSI2OS43MzAzMTYiCiAgICAgICAgIHk9 IjcwNi4zMTAzNiI+UmVzdWx0czwvdHNwYW4+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJv bGU9ImxpbmUiCiAgICAgICAgIHg9IjY5LjczMDMxNiIKICAgICAgICAgeT0iNzIxLjQzNjQ2 IgogICAgICAgICBpZD0idHNwYW4xMDE5MC01Ij5EYXRhc3RvcmU8L3RzcGFuPjwvdGV4dD4K ICAgIDxyZWN0CiAgICAgICBzdHlsZT0iZmlsbDp1cmwoI2xpbmVhckdyYWRpZW50MTEyNjEp O2ZpbGwtb3BhY2l0eToxO2ZpbGwtcnVsZTpub256ZXJvO3N0cm9rZTojMDMwMDc4O3N0cm9r ZS13aWR0aDo0O3N0cm9rZS1saW5lY2FwOnNxdWFyZTtzdHJva2UtbGluZWpvaW46bWl0ZXI7 c3Ryb2tlLW1pdGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6 bm9uZTtzdHJva2UtZGFzaG9mZnNldDowO2ZpbHRlcjp1cmwoI2ZpbHRlcjU0NzMtMTItMC01 KSIKICAgICAgIGlkPSJyZWN0MzAxOS05LTAtNCIKICAgICAgIHdpZHRoPSIxNTEuNTIyODci CiAgICAgICBoZWlnaHQ9IjEwMi4wMjU0MSIKICAgICAgIHg9IjY4Ljc3MDk5NiIKICAgICAg IHk9IjkzLjcyNzQxNyIKICAgICAgIHRyYW5zZm9ybT0ibWF0cml4KDAuNDc0NjE5MzUsMCww LDAuMzk1NDc5MDIsOC4wOTIwMzI3LDQ3MC4wNTcyNSkiIC8+CiAgICA8dGV4dAogICAgICAg eG1sOnNwYWNlPSJwcmVzZXJ2ZSIKICAgICAgIHN0eWxlPSJmb250LXNpemU6MTMuODYzODY4 NzFweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0 OmJvbGQ7Zm9udC1zdHJldGNoOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O2xpbmUtaGVpZ2h0 OjEyNSU7bGV0dGVyLXNwYWNpbmc6MHB4O3dvcmQtc3BhY2luZzowcHg7d3JpdGluZy1tb2Rl OmxyLXRiO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6IzAwNDEwMDtmaWxsLW9wYWNpdHk6MTtz dHJva2U6bm9uZTtmb250LWZhbWlseTpQbGFudGFnZW5ldCBDaGVyb2tlZTstaW5rc2NhcGUt Zm9udC1zcGVjaWZpY2F0aW9uOlBsYW50YWdlbmV0IENoZXJva2VlIEJvbGQiCiAgICAgICB4 PSI0OC4wMjcyMTQiCiAgICAgICB5PSI1NzMuNzQzMjMiCiAgICAgICBpZD0idGV4dDEwMTc0 LTctMCIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIxMjUlIgogICAgICAgdHJhbnNm b3JtPSJzY2FsZSgxLjA5NTQ5NjUsMC45MTI4MjgxMSkiPjx0c3BhbgogICAgICAgICBzb2Rp cG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBpZD0idHNwYW4xMDE3Ni0yLTUiCiAgICAgICAg IHg9IjQ4LjAyNzIxNCIKICAgICAgICAgeT0iNTczLjc0MzIzIj5SZXN1bHRzPC90c3Bhbj48 dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAgICAgeD0iNDguMDI3 MjE0IgogICAgICAgICB5PSI1OTEuMDczMDYiCiAgICAgICAgIGlkPSJ0c3BhbjEwMTc4LTUt NCI+Vmlld2VyPC90c3Bhbj48L3RleHQ+CiAgICA8dGV4dAogICAgICAgeG1sOnNwYWNlPSJw cmVzZXJ2ZSIKICAgICAgIHN0eWxlPSJmb250LXNpemU6MTMuODYzODY4NzFweDtmb250LXN0 eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1z dHJldGNoOm5vcm1hbDt0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxMjUlO2xldHRl ci1zcGFjaW5nOjBweDt3b3JkLXNwYWNpbmc6MHB4O3dyaXRpbmctbW9kZTpsci10Yjt0ZXh0 LWFuY2hvcjptaWRkbGU7ZmlsbDojMDAzZjAwO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25l O2ZvbnQtZmFtaWx5OlBsYW50YWdlbmV0IENoZXJva2VlOy1pbmtzY2FwZS1mb250LXNwZWNp ZmljYXRpb246UGxhbnRhZ2VuZXQgQ2hlcm9rZWUgQm9sZCIKICAgICAgIHg9IjE0NS4xMzA3 MSIKICAgICAgIHk9IjU3My43OTI5NyIKICAgICAgIGlkPSJ0ZXh0MTAxODAtNyIKICAgICAg IHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIxMjUlIgogICAgICAgdHJhbnNmb3JtPSJzY2FsZSgx LjA5NTQ5NjUsMC45MTI4MjgxMSkiPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJs aW5lIgogICAgICAgICBpZD0idHNwYW4xMDE4Mi0yIgogICAgICAgICB4PSIxNDUuMTMwNzEi CiAgICAgICAgIHk9IjU3My43OTI5NyI+Q29udHJvbGxlcjwvdHNwYW4+PHRzcGFuCiAgICAg ICAgIHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAgICAgICAgIHg9IjE0NS4xMzA3MSIKICAgICAg ICAgeT0iNTkxLjEyMjgiCiAgICAgICAgIGlkPSJ0c3BhbjEwMTg0LTEiPkZyb250LUVuZDwv dHNwYW4+PC90ZXh0PgogICAgPHRleHQKICAgICAgIHhtbDpzcGFjZT0icHJlc2VydmUiCiAg ICAgICBzdHlsZT0iZm9udC1zaXplOjE4cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJp YW50Om5vcm1hbDtmb250LXdlaWdodDpib2xkO2ZvbnQtc3RyZXRjaDpub3JtYWw7dGV4dC1h bGlnbjpjZW50ZXI7bGluZS1oZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29yZC1z cGFjaW5nOjBweDt3cml0aW5nLW1vZGU6bHI7dGV4dC1hbmNob3I6bWlkZGxlO2ZpbGw6IzAw NmYwMDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpSb2Q7LWlua3Nj YXBlLWZvbnQtc3BlY2lmaWNhdGlvbjpSb2QgQm9sZCIKICAgICAgIHg9IjY1Mi45NTgzNyIK ICAgICAgIHk9IjIzNS4xMzg0NyIKICAgICAgIGlkPSJ0ZXh0MTQ2MTciCiAgICAgICBzb2Rp cG9kaTpsaW5lc3BhY2luZz0iMTI1JSI+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9 ImxpbmUiCiAgICAgICAgIGlkPSJ0c3BhbjE0NjE5IgogICAgICAgICB4PSI2NTIuOTU4Mzci CiAgICAgICAgIHk9IjIzNS4xMzg0NyI+Q29tcHV0ZXI8L3RzcGFuPjx0c3BhbgogICAgICAg ICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICB4PSI2NTIuOTU4MzciCiAgICAgICAg IHk9IjI2Mi42Mzg0OSIKICAgICAgICAgaWQ9InRzcGFuMTQ2MjEiPih3L2FnZW50KTwvdHNw YW4+PC90ZXh0PgogICAgPHRleHQKICAgICAgIHhtbDpzcGFjZT0icHJlc2VydmUiCiAgICAg ICBzdHlsZT0iZm9udC1zaXplOjE4cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50 Om5vcm1hbDtmb250LXdlaWdodDpib2xkO2ZvbnQtc3RyZXRjaDpub3JtYWw7dGV4dC1hbGln bjpjZW50ZXI7bGluZS1oZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29yZC1zcGFj aW5nOjBweDt3cml0aW5nLW1vZGU6bHI7dGV4dC1hbmNob3I6bWlkZGxlO2ZpbGw6IzAwNmYw MDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpSb2Q7LWlua3NjYXBl LWZvbnQtc3BlY2lmaWNhdGlvbjpSb2QgQm9sZCIKICAgICAgIHg9IjY1Mi45NTgzNyIKICAg ICAgIHk9IjYwNy45ODQzOCIKICAgICAgIGlkPSJ0ZXh0MTQ2MjMiCiAgICAgICBzb2RpcG9k aTpsaW5lc3BhY2luZz0iMTI1JSI+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9Imxp bmUiCiAgICAgICAgIGlkPSJ0c3BhbjE0NjI1IgogICAgICAgICB4PSI2NTIuOTU4MzciCiAg ICAgICAgIHk9IjYwNy45ODQzOCI+Q29tcHV0ZXJzPC90c3Bhbj48dHNwYW4KICAgICAgICAg c29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAgICAgeD0iNjUyLjk1ODM3IgogICAgICAgICB5 PSI2MzUuNDg0MzgiCiAgICAgICAgIGlkPSJ0c3BhbjE0NjI3Ij4oYWdlbnRsZXNzKTwvdHNw YW4+PC90ZXh0PgogICAgPHBhdGgKICAgICAgIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlOiMw MDAwMDA7c3Ryb2tlLXdpZHRoOjFweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5l am9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxO21hcmtlci1zdGFydDp1cmwoI0Fycm93MU1z dGFydCk7bWFya2VyLWVuZDp1cmwoI0Fycm93MU1lbmQpIgogICAgICAgZD0iTSAyMDEuMzYx MSw0OTYuODE5NTUgMzM1LjQ2MTExLDM1NC4yOTczMyIKICAgICAgIGlkPSJwYXRoMTQ2MzUi CiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItdHlwZT0icG9seWxpbmUiCiAgICAgICBpbmtz Y2FwZTpjb25uZWN0b3ItY3VydmF0dXJlPSIzIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlv bi1zdGFydD0iI3JlY3QxMDQzMi01LTItMyIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24t c3RhcnQtcG9pbnQ9ImQ0IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQ9IiNyZWN0 MzAxOS00LTIiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLWVuZC1wb2ludD0iZDQiIC8+ CiAgICA8dGV4dAogICAgICAgeG1sOnNwYWNlPSJwcmVzZXJ2ZSIKICAgICAgIHN0eWxlPSJm b250LXNpemU6MThweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2Zv bnQtd2VpZ2h0OmJvbGQ7Zm9udC1zdHJldGNoOm5vcm1hbDt0ZXh0LWFsaWduOmNlbnRlcjts aW5lLWhlaWdodDoxMjUlO2xldHRlci1zcGFjaW5nOjBweDt3b3JkLXNwYWNpbmc6MHB4O3dy aXRpbmctbW9kZTpscjt0ZXh0LWFuY2hvcjptaWRkbGU7ZmlsbDojMDA2ZjAwO2ZpbGwtb3Bh Y2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OlJvZDstaW5rc2NhcGUtZm9udC1zcGVj aWZpY2F0aW9uOlJvZCBCb2xkIgogICAgICAgeD0iOTIuNDczNjQ4IgogICAgICAgeT0iNDIw Ljc4Njc3IgogICAgICAgaWQ9InRleHQxNTA0MSIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFj aW5nPSIxMjUlIj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAg ICAgaWQ9InRzcGFuMTUwNDMiCiAgICAgICAgIHg9IjkyLjQ3MzY0OCIKICAgICAgICAgeT0i NDIwLjc4Njc3Ij5BZG1pbmlzdHJhdG9yPC90c3Bhbj48dHNwYW4KICAgICAgICAgc29kaXBv ZGk6cm9sZT0ibGluZSIKICAgICAgICAgeD0iOTIuNDczNjQ4IgogICAgICAgICB5PSI0NDgu Mjg2NzciCiAgICAgICAgIGlkPSJ0c3BhbjE1MDQ1Ij5Xb3Jrc3RhdGlvbjwvdHNwYW4+PC90 ZXh0PgogICAgPHRleHQKICAgICAgIHhtbDpzcGFjZT0icHJlc2VydmUiCiAgICAgICBzdHls ZT0iZm9udC1zaXplOjE4cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1h bDtmb250LXdlaWdodDpib2xkO2ZvbnQtc3RyZXRjaDpub3JtYWw7dGV4dC1hbGlnbjpjZW50 ZXI7bGluZS1oZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29yZC1zcGFjaW5nOjBw eDt3cml0aW5nLW1vZGU6bHI7dGV4dC1hbmNob3I6bWlkZGxlO2ZpbGw6IzAwNmYwMDtmaWxs LW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpSb2Q7LWlua3NjYXBlLWZvbnQt c3BlY2lmaWNhdGlvbjpSb2QgQm9sZCIKICAgICAgIHg9Ijg5LjUyMjM3NyIKICAgICAgIHk9 IjIwMC40MjQwMSIKICAgICAgIGlkPSJ0ZXh0MTUwNDciCiAgICAgICBzb2RpcG9kaTpsaW5l c3BhY2luZz0iMTI1JSI+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAg ICAgICAgIGlkPSJ0c3BhbjE1MDQ5IgogICAgICAgICB4PSI4OS41MjIzNzciCiAgICAgICAg IHk9IjIwMC40MjQwMSI+TWFuYWdlcjwvdHNwYW4+PHRzcGFuCiAgICAgICAgIHNvZGlwb2Rp OnJvbGU9ImxpbmUiCiAgICAgICAgIHg9Ijg5LjUyMjM3NyIKICAgICAgICAgeT0iMjI3Ljky NDAxIgogICAgICAgICBpZD0idHNwYW4xNTA1MSI+V29ya3N0YXRpb248L3RzcGFuPjwvdGV4 dD4KICAgIDx0ZXh0CiAgICAgICB4bWw6c3BhY2U9InByZXNlcnZlIgogICAgICAgc3R5bGU9 ImZvbnQtc2l6ZToxOHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7 Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0cmV0Y2g6bm9ybWFsO3RleHQtYWxpZ246Y2VudGVy O2xpbmUtaGVpZ2h0OjEyNSU7bGV0dGVyLXNwYWNpbmc6MHB4O3dvcmQtc3BhY2luZzowcHg7 d3JpdGluZy1tb2RlOmxyO3RleHQtYW5jaG9yOm1pZGRsZTtmaWxsOiMwMDZmMDA7ZmlsbC1v cGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6Um9kOy1pbmtzY2FwZS1mb250LXNw ZWNpZmljYXRpb246Um9kIEJvbGQiCiAgICAgICB4PSIzNTYuMDkzMDIiCiAgICAgICB5PSIy MjAuMDk5MjciCiAgICAgICBpZD0idGV4dDE0NjI5IgogICAgICAgc29kaXBvZGk6bGluZXNw YWNpbmc9IjEyNSUiPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAg ICAgICBpZD0idHNwYW4xNDYzMSIKICAgICAgICAgeD0iMzU2LjA5MzAyIgogICAgICAgICB5 PSIyMjAuMDk5MjciPkRhdGFiYXNlPC90c3Bhbj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6 cm9sZT0ibGluZSIKICAgICAgICAgeD0iMzU2LjA5MzAyIgogICAgICAgICB5PSIyNDcuNTk5 MjciCiAgICAgICAgIGlkPSJ0c3BhbjE0NjMzIj5TZXJ2ZXI8L3RzcGFuPjwvdGV4dD4KICAg IDx0ZXh0CiAgICAgICB4bWw6c3BhY2U9InByZXNlcnZlIgogICAgICAgc3R5bGU9ImZvbnQt c2l6ZToxOHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9udC13 ZWlnaHQ6Ym9sZDtmb250LXN0cmV0Y2g6bm9ybWFsO3RleHQtYWxpZ246Y2VudGVyO2xpbmUt aGVpZ2h0OjEyNSU7bGV0dGVyLXNwYWNpbmc6MHB4O3dvcmQtc3BhY2luZzowcHg7d3JpdGlu Zy1tb2RlOmxyLXRiO3RleHQtYW5jaG9yOm1pZGRsZTtmaWxsOiMwMDZmMDA7ZmlsbC1vcGFj aXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6Um9kOy1pbmtzY2FwZS1mb250LXNwZWNp ZmljYXRpb246Um9kIEJvbGQiCiAgICAgICB4PSIxMjAuMDE5IgogICAgICAgeT0iNzAwLjE3 NTI5IgogICAgICAgaWQ9InRleHQxNTA1MyIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5n PSIxMjUlIj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAgICAg aWQ9InRzcGFuMTUwNTUiCiAgICAgICAgIHg9IjEyMC4wMTkiCiAgICAgICAgIHk9IjcwMC4x NzUyOSI+SW5kZXBlbmRlbnQ8L3RzcGFuPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xl PSJsaW5lIgogICAgICAgICB4PSIxMjAuMDE5IgogICAgICAgICB5PSI3MjIuNjc1MjkiCiAg ICAgICAgIGlkPSJ0c3BhbjE2NDkzIj5Xb3Jrc3RhdGlvbjwvdHNwYW4+PC90ZXh0PgogICAg PHBhdGgKICAgICAgIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdp ZHRoOjFweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJv a2Utb3BhY2l0eToxO21hcmtlci1zdGFydDp1cmwoI0Fycm93MU1zdGFydCk7bWFya2VyLWVu ZDp1cmwoI0Fycm93MU1lbmQpIgogICAgICAgZD0iTSAxMTcuNzYzNzksMzYzLjY5MTMzIDMy MC4zNzg0NSwzNDAuMTMyMTgiCiAgICAgICBpZD0icGF0aDE1MDY1IgogICAgICAgaW5rc2Nh cGU6Y29ubmVjdG9yLXR5cGU9InBvbHlsaW5lIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9y LWN1cnZhdHVyZT0iMyIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tc3RhcnQ9IiNyZWN0 MzAxOSIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tc3RhcnQtcG9pbnQ9ImQ0IgogICAg ICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQ9IiNyZWN0MzAxOS00LTIiCiAgICAgICBpbmtz Y2FwZTpjb25uZWN0aW9uLWVuZC1wb2ludD0iZDQiIC8+CiAgICA8dGV4dAogICAgICAgeG1s OnNwYWNlPSJwcmVzZXJ2ZSIKICAgICAgIHN0eWxlPSJmb250LXNpemU6MThweDtmb250LXN0 eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1z dHJldGNoOm5vcm1hbDt0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxMjUlO2xldHRl ci1zcGFjaW5nOjBweDt3b3JkLXNwYWNpbmc6MHB4O3dyaXRpbmctbW9kZTpsci10Yjt0ZXh0 LWFuY2hvcjptaWRkbGU7ZmlsbDojMDA2ZjAwO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25l O2ZvbnQtZmFtaWx5OlJvZDstaW5rc2NhcGUtZm9udC1zcGVjaWZpY2F0aW9uOlJvZCBCb2xk IgogICAgICAgeD0iMzkyLjUyMTE1IgogICAgICAgeT0iNDE2Ljg1MTcyIgogICAgICAgaWQ9 InRleHQxNTY3MyIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIxMjUlIj48dHNwYW4K ICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAgICAgaWQ9InRzcGFuMTU2NzUi CiAgICAgICAgIHg9IjM5Mi41MjExNSIKICAgICAgICAgeT0iNDE2Ljg1MTcyIj5Bc3Nlc3Nt ZW50PC90c3Bhbj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAg ICAgeD0iMzkyLjUyMTE1IgogICAgICAgICB5PSI0MzkuMzUxNzIiCiAgICAgICAgIGlkPSJ0 c3BhbjE1Njc3Ij5TZXJ2ZXI8L3RzcGFuPjwvdGV4dD4KICAgIDxwYXRoCiAgICAgICBzdHls ZT0iZmlsbDpub25lO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDoxcHg7c3Ryb2tlLWxp bmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MTttYXJr ZXItc3RhcnQ6dXJsKCNBcnJvdzFNc3RhcnQpO21hcmtlci1lbmQ6dXJsKCNBcnJvdzFNZW5k KSIKICAgICAgIGQ9Im0gMzUzLjAwNTkxLDMxOC41NDg0NiA0LjkxMDA2LC0xMjAuNzgxNzUi CiAgICAgICBpZD0icGF0aDE2MDg3IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLXR5cGU9 InBvbHlsaW5lIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMyIKICAg ICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tc3RhcnQ9IiNyZWN0MzAxOS00LTIiCiAgICAgICBp bmtzY2FwZTpjb25uZWN0aW9uLXN0YXJ0LXBvaW50PSJkNCIKICAgICAgIGlua3NjYXBlOmNv bm5lY3Rpb24tZW5kPSIjcmVjdDEwNDMyLTUtMi01IgogICAgICAgaW5rc2NhcGU6Y29ubmVj dGlvbi1lbmQtcG9pbnQ9ImQ0IiAvPgogICAgPHJlY3QKICAgICAgIHN0eWxlPSJmaWxsOiMw MGJlMDA7ZmlsbC1vcGFjaXR5OjAuMTI2OTg0MTI7ZmlsbC1ydWxlOm5vbnplcm87c3Ryb2tl OiMwMDI2MDA7c3Ryb2tlLXdpZHRoOjAuOTc5NDkwNTI7c3Ryb2tlLWxpbmVjYXA6c3F1YXJl O3N0cm9rZS1saW5lam9pbjpiZXZlbDtzdHJva2UtbWl0ZXJsaW1pdDo0O3N0cm9rZS1vcGFj aXR5OjAuNTUwMjY0NTU7c3Ryb2tlLWRhc2hhcnJheTpub25lO3N0cm9rZS1kYXNob2Zmc2V0 OjAiCiAgICAgICBpZD0icmVjdDEwNDMyLTUtMi01LTMiCiAgICAgICB3aWR0aD0iOTIuNzA1 OTI1IgogICAgICAgaGVpZ2h0PSI2MC42MzU5NTYiCiAgICAgICB4PSI0MjcuMjg4NzYiCiAg ICAgICB5PSI2ODguMzgwNDkiCiAgICAgICByeT0iMTEuOTQzNDQzIiAvPgogICAgPHJlY3QK ICAgICAgIHN0eWxlPSJmaWxsOiMwMGJlMDA7ZmlsbC1vcGFjaXR5OjAuMTI2OTg0MTI7Zmls bC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMDI2MDA7c3Ryb2tlLXdpZHRoOjAuNzA1MTE4MTI7 c3Ryb2tlLWxpbmVjYXA6c3F1YXJlO3N0cm9rZS1saW5lam9pbjpiZXZlbDtzdHJva2UtbWl0 ZXJsaW1pdDo0O3N0cm9rZS1vcGFjaXR5OjAuNTUwMjY0NTU7c3Ryb2tlLWRhc2hhcnJheTpu b25lO3N0cm9rZS1kYXNob2Zmc2V0OjAiCiAgICAgICBpZD0icmVjdDEwNDMyLTUtMi0yLTki CiAgICAgICB3aWR0aD0iNjguMDM3MjE2IgogICAgICAgaGVpZ2h0PSI0Mi44MTY4MTgiCiAg ICAgICB4PSIzMDIuMzY1NDIiCiAgICAgICB5PSI2OTcuMzEyODEiCiAgICAgICByeT0iOC40 MzM2MTM4IiAvPgogICAgPHJlY3QKICAgICAgIHN0eWxlPSJmaWxsOnVybCgjbGluZWFyR3Jh ZGllbnQxMTEyMy05KTtmaWxsLW9wYWNpdHk6MTtmaWxsLXJ1bGU6bm9uemVybztzdHJva2U6 IzAzMDA3ODtzdHJva2Utd2lkdGg6NDtzdHJva2UtbGluZWNhcDpzcXVhcmU7c3Ryb2tlLWxp bmVqb2luOm1pdGVyO3N0cm9rZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MTtzdHJv a2UtZGFzaGFycmF5Om5vbmU7c3Ryb2tlLWRhc2hvZmZzZXQ6MDtmaWx0ZXI6dXJsKCNmaWx0 ZXI1NDczLTEyLTAtNikiCiAgICAgICBpZD0icmVjdDMwMTktOS0wLTMiCiAgICAgICB3aWR0 aD0iMTUxLjUyMjg3IgogICAgICAgaGVpZ2h0PSIxMDIuMDI1NDEiCiAgICAgICB4PSI2OC43 NzA5OTYiCiAgICAgICB5PSI5My43Mjc0MTciCiAgICAgICB0cmFuc2Zvcm09Im1hdHJpeCgw LjI1MzcyMjMzLDAsMCwwLjE5NTk5MzA2LDI5OS43MTI5MSw2OTAuMzUzMTEpIiAvPgogICAg PHJlY3QKICAgICAgIHN0eWxlPSJmaWxsOiMwMGJlMDA7ZmlsbC1vcGFjaXR5OjAuMTI2OTg0 MTI7ZmlsbC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMDI2MDA7c3Ryb2tlLXdpZHRoOjEuMTA3 Nzg5OTk7c3Ryb2tlLWxpbmVjYXA6c3F1YXJlO3N0cm9rZS1saW5lam9pbjpiZXZlbDtzdHJv a2UtbWl0ZXJsaW1pdDo0O3N0cm9rZS1vcGFjaXR5OjAuNTUwMjY0NTU7c3Ryb2tlLWRhc2hh cnJheTpub25lO3N0cm9rZS1kYXNob2Zmc2V0OjAiCiAgICAgICBpZD0icmVjdDEwNDMyLTQi CiAgICAgICB3aWR0aD0iMTA1Ljk2NjM4IgogICAgICAgaGVpZ2h0PSI2Ny44NTUzMzEiCiAg ICAgICB4PSI0MzkuNjczMDMiCiAgICAgICB5PSI3OTMuMjExNjciCiAgICAgICByeT0iMTMu MzY1NDQxIiAvPgogICAgPHJlY3QKICAgICAgIHN0eWxlPSJmaWxsOiMwMGJlMDA7ZmlsbC1v cGFjaXR5OjAuMTI2OTg0MTI7ZmlsbC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMDI2MDA7c3Ry b2tlLXdpZHRoOjAuNzA1MTE4MTI7c3Ryb2tlLWxpbmVjYXA6c3F1YXJlO3N0cm9rZS1saW5l am9pbjpiZXZlbDtzdHJva2UtbWl0ZXJsaW1pdDo0O3N0cm9rZS1vcGFjaXR5OjAuNTUwMjY0 NTU7c3Ryb2tlLWRhc2hhcnJheTpub25lO3N0cm9rZS1kYXNob2Zmc2V0OjAiCiAgICAgICBp ZD0icmVjdDEwNDMyLTUtMi02IgogICAgICAgd2lkdGg9IjY4LjAzNzIxNiIKICAgICAgIGhl aWdodD0iNDIuODE2ODE4IgogICAgICAgeD0iNTk2LjEzOTY1IgogICAgICAgeT0iOTIzLjIz NTExIgogICAgICAgcnk9IjguNDMzNjEzOCIgLz4KICAgIDxyZWN0CiAgICAgICBzdHlsZT0i ZmlsbDojMDBiZTAwO2ZpbGwtb3BhY2l0eTowLjEyNjk4NDEyO2ZpbGwtcnVsZTpub256ZXJv O3N0cm9rZTojMDAyNjAwO3N0cm9rZS13aWR0aDowLjcwNTExODEyO3N0cm9rZS1saW5lY2Fw OnNxdWFyZTtzdHJva2UtbGluZWpvaW46YmV2ZWw7c3Ryb2tlLW1pdGVybGltaXQ6NDtzdHJv a2Utb3BhY2l0eTowLjU1MDI2NDU1O3N0cm9rZS1kYXNoYXJyYXk6bm9uZTtzdHJva2UtZGFz aG9mZnNldDowIgogICAgICAgaWQ9InJlY3QxMDQzMi01LTUtMCIKICAgICAgIHdpZHRoPSI2 OC4wMzcyMTYiCiAgICAgICBoZWlnaHQ9IjQyLjgxNjgxOCIKICAgICAgIHg9IjU5Ni4xMzk2 NSIKICAgICAgIHk9Ijg2Ny44NjE4OCIKICAgICAgIHJ5PSI4LjQzMzYxMzgiIC8+CiAgICA8 cmVjdAogICAgICAgc3R5bGU9ImZpbGw6IzAwYmUwMDtmaWxsLW9wYWNpdHk6MC4xMjY5ODQx MjtmaWxsLXJ1bGU6bm9uemVybztzdHJva2U6IzAwMjYwMDtzdHJva2Utd2lkdGg6MC43MDUx MTgxMjtzdHJva2UtbGluZWNhcDpzcXVhcmU7c3Ryb2tlLWxpbmVqb2luOmJldmVsO3N0cm9r ZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MC41NTAyNjQ1NTtzdHJva2UtZGFzaGFy cmF5Om5vbmU7c3Ryb2tlLWRhc2hvZmZzZXQ6MCIKICAgICAgIGlkPSJyZWN0MTA0MzItNS02 IgogICAgICAgd2lkdGg9IjY4LjAzNzIxNiIKICAgICAgIGhlaWdodD0iNDIuODE2ODE4Igog ICAgICAgeD0iNTk2LjEzOTY1IgogICAgICAgeT0iODExLjY0MTExIgogICAgICAgcnk9Ijgu NDMzNjEzOCIgLz4KICAgIDxyZWN0CiAgICAgICBzdHlsZT0iZmlsbDojMDBiZTAwO2ZpbGwt b3BhY2l0eTowLjEyNjk4NDEyO2ZpbGwtcnVsZTpub256ZXJvO3N0cm9rZTojMDAyNjAwO3N0 cm9rZS13aWR0aDowLjcwNTExODEyO3N0cm9rZS1saW5lY2FwOnNxdWFyZTtzdHJva2UtbGlu ZWpvaW46YmV2ZWw7c3Ryb2tlLW1pdGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eTowLjU1MDI2 NDU1O3N0cm9rZS1kYXNoYXJyYXk6bm9uZTtzdHJva2UtZGFzaG9mZnNldDowIgogICAgICAg aWQ9InJlY3QxMDQzMi01LTctNiIKICAgICAgIHdpZHRoPSI2OC4wMzcyMTYiCiAgICAgICBo ZWlnaHQ9IjQyLjgxNjgxOCIKICAgICAgIHg9IjU5Ni4xMzk2NSIKICAgICAgIHk9IjcxNi40 MzMwNCIKICAgICAgIHJ5PSI4LjQzMzYxMzgiIC8+CiAgICA8cmVjdAogICAgICAgc3R5bGU9 ImZpbGw6IzAwYmUwMDtmaWxsLW9wYWNpdHk6MC4xMjY5ODQxMjtmaWxsLXJ1bGU6bm9uemVy bztzdHJva2U6IzAwMjYwMDtzdHJva2Utd2lkdGg6MC44NDQ1NzAyODtzdHJva2UtbGluZWNh cDpzcXVhcmU7c3Ryb2tlLWxpbmVqb2luOmJldmVsO3N0cm9rZS1taXRlcmxpbWl0OjQ7c3Ry b2tlLW9wYWNpdHk6MC41NTAyNjQ1NTtzdHJva2UtZGFzaGFycmF5Om5vbmU7c3Ryb2tlLWRh c2hvZmZzZXQ6MCIKICAgICAgIGlkPSJyZWN0MTA0MzItNS0yLTEtMSIKICAgICAgIHdpZHRo PSI2MC4wMzkwODIiCiAgICAgICBoZWlnaHQ9IjY5LjYxMDQ4OSIKICAgICAgIHg9IjMwNi4z NjQ0NyIKICAgICAgIHk9Ijc5MS44ODE1OSIKICAgICAgIHJ5PSIxMy43MTExNTUiIC8+CiAg ICA8cmVjdAogICAgICAgc3R5bGU9ImZpbGw6dXJsKCNsaW5lYXJHcmFkaWVudDU0NTEtMik7 ZmlsbC1vcGFjaXR5OjE7ZmlsbC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMzAwNzg7c3Ryb2tl LXdpZHRoOjQ7c3Ryb2tlLWxpbmVjYXA6c3F1YXJlO3N0cm9rZS1saW5lam9pbjptaXRlcjtz dHJva2UtbWl0ZXJsaW1pdDo0O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLWRhc2hhcnJheTpu b25lO3N0cm9rZS1kYXNob2Zmc2V0OjA7ZmlsdGVyOnVybCgjZmlsdGVyNTQ3My0wKSIKICAg ICAgIGlkPSJyZWN0MzAxOS04NCIKICAgICAgIHdpZHRoPSIxNTEuNTIyODciCiAgICAgICBo ZWlnaHQ9IjEwMi4wMjU0MSIKICAgICAgIHg9IjY4Ljc3MDk5NiIKICAgICAgIHk9IjI2OS42 NDc1MiIKICAgICAgIHRyYW5zZm9ybT0ibWF0cml4KDAuMjUzNzIyMzMsMCwwLDAuMTk1OTkz MDYsMjk5LjcxMjkxLDc4MS4wNTQ2NSkiIC8+CiAgICA8cmVjdAogICAgICAgc3R5bGU9ImZp bGw6dXJsKCNsaW5lYXJHcmFkaWVudDU0OTMtNDIpO2ZpbGwtb3BhY2l0eToxO2ZpbGwtcnVs ZTpub256ZXJvO3N0cm9rZTojMDMwMDc4O3N0cm9rZS13aWR0aDo0O3N0cm9rZS1saW5lY2Fw OnNxdWFyZTtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6NDtzdHJv a2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6bm9uZTtzdHJva2UtZGFzaG9mZnNldDow O2ZpbHRlcjp1cmwoI2ZpbHRlcjU0NzMtMS05KSIKICAgICAgIGlkPSJyZWN0MzAxOS04LTYi CiAgICAgICB3aWR0aD0iMTUxLjUyMjg3IgogICAgICAgaGVpZ2h0PSIxMDIuMDI1NDEiCiAg ICAgICB4PSI1NDMuODk2MDYiCiAgICAgICB5PSI5My43Mjc0MTciCiAgICAgICB0cmFuc2Zv cm09Im1hdHJpeCgwLjM0NTcxNjEsMCwwLDAuMjc3NTU5NzgsMjU5LjQxNjE5LDY3OC41MjQ0 MikiIC8+CiAgICA8cmVjdAogICAgICAgc3R5bGU9ImZpbGw6dXJsKCNsaW5lYXJHcmFkaWVu dDU0OTMtNC0xKTtmaWxsLW9wYWNpdHk6MTtmaWxsLXJ1bGU6bm9uemVybztzdHJva2U6IzAz MDA3ODtzdHJva2Utd2lkdGg6NDtzdHJva2UtbGluZWNhcDpzcXVhcmU7c3Ryb2tlLWxpbmVq b2luOm1pdGVyO3N0cm9rZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2Ut ZGFzaGFycmF5Om5vbmU7c3Ryb2tlLWRhc2hvZmZzZXQ6MDtmaWx0ZXI6dXJsKCNmaWx0ZXI1 NDczLTEyLTgpIgogICAgICAgaWQ9InJlY3QzMDE5LTktMyIKICAgICAgIHdpZHRoPSIxNTEu NTIyODciCiAgICAgICBoZWlnaHQ9IjEwMi4wMjU0MSIKICAgICAgIHg9IjY4Ljc3MDk5NiIK ICAgICAgIHk9IjkzLjcyNzQxNyIKICAgICAgIHRyYW5zZm9ybT0ibWF0cml4KDAuMjUzNzIy MzMsMCwwLDAuMTk1OTkzMDYsMjk5LjcxMjkxLDc4MS4wNTQ2NSkiIC8+CiAgICA8dGV4dAog ICAgICAgeG1sOnNwYWNlPSJwcmVzZXJ2ZSIKICAgICAgIHN0eWxlPSJmb250LXNpemU6Ny4x MzU5MTUyOHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9udC13 ZWlnaHQ6Ym9sZDtmb250LXN0cmV0Y2g6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7bGluZS1o ZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29yZC1zcGFjaW5nOjBweDt3cml0aW5n LW1vZGU6bHItdGI7dGV4dC1hbmNob3I6c3RhcnQ7ZmlsbDojMDA0MTAwO2ZpbGwtb3BhY2l0 eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OlBsYW50YWdlbmV0IENoZXJva2VlOy1pbmtz Y2FwZS1mb250LXNwZWNpZmljYXRpb246UGxhbnRhZ2VuZXQgQ2hlcm9rZWUgQm9sZCIKICAg ICAgIHg9IjI4NC4zMzY5MSIKICAgICAgIHk9IjkxOC45MzM3OCIKICAgICAgIGlkPSJ0ZXh0 MTAxNzQtOSIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIxMjUlIgogICAgICAgdHJh bnNmb3JtPSJzY2FsZSgxLjEzNzc4MTgsMC44Nzg5MDMxNCkiPjx0c3BhbgogICAgICAgICBz b2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBpZD0idHNwYW4xMDE3Ni0xIgogICAgICAg ICB4PSIyODQuMzM2OTEiCiAgICAgICAgIHk9IjkxOC45MzM3OCI+UmVzdWx0czwvdHNwYW4+ PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAgICAgICAgIHg9IjI4NC4z MzY5MSIKICAgICAgICAgeT0iOTI3Ljg1MzciCiAgICAgICAgIGlkPSJ0c3BhbjEwMTc4LTMi PlZpZXdlcjwvdHNwYW4+PC90ZXh0PgogICAgPHRleHQKICAgICAgIHhtbDpzcGFjZT0icHJl c2VydmUiCiAgICAgICBzdHlsZT0iZm9udC1zaXplOjcuMTM1OTE1MjhweDtmb250LXN0eWxl Om5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1zdHJl dGNoOm5vcm1hbDt0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxMjUlO2xldHRlci1z cGFjaW5nOjBweDt3b3JkLXNwYWNpbmc6MHB4O3dyaXRpbmctbW9kZTpsci10Yjt0ZXh0LWFu Y2hvcjptaWRkbGU7ZmlsbDojMDAzZjAwO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2Zv bnQtZmFtaWx5OlBsYW50YWdlbmV0IENoZXJva2VlOy1pbmtzY2FwZS1mb250LXNwZWNpZmlj YXRpb246UGxhbnRhZ2VuZXQgQ2hlcm9rZWUgQm9sZCIKICAgICAgIHg9IjI5NS40NjkwMiIK ICAgICAgIHk9Ijk1OC4xNjcyNCIKICAgICAgIGlkPSJ0ZXh0MTAxODAtNSIKICAgICAgIHNv ZGlwb2RpOmxpbmVzcGFjaW5nPSIxMjUlIgogICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjEz Nzc4MTgsMC44Nzg5MDMxNCkiPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5l IgogICAgICAgICBpZD0idHNwYW4xMDE4Mi05IgogICAgICAgICB4PSIyOTUuNDY5MDIiCiAg ICAgICAgIHk9Ijk1OC4xNjcyNCI+Q29udHJvbGxlcjwvdHNwYW4+PHRzcGFuCiAgICAgICAg IHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAgICAgICAgIHg9IjI5NS40NjkwMiIKICAgICAgICAg eT0iOTY3LjA4NzE2IgogICAgICAgICBpZD0idHNwYW4xMDE4NC04Ij5Gcm9udC1FbmQ8L3Rz cGFuPjwvdGV4dD4KICAgIDx0ZXh0CiAgICAgICB4bWw6c3BhY2U9InByZXNlcnZlIgogICAg ICAgc3R5bGU9ImZvbnQtc2l6ZTo4LjY3MzUzMzQ0cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9u dC12YXJpYW50Om5vcm1hbDtmb250LXdlaWdodDpib2xkO2ZvbnQtc3RyZXRjaDpub3JtYWw7 dGV4dC1hbGlnbjpjZW50ZXI7bGluZS1oZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7 d29yZC1zcGFjaW5nOjBweDt3cml0aW5nLW1vZGU6bHItdGI7dGV4dC1hbmNob3I6bWlkZGxl O2ZpbGw6IzQxMDAwMDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpQ bGFudGFnZW5ldCBDaGVyb2tlZTstaW5rc2NhcGUtZm9udC1zcGVjaWZpY2F0aW9uOlBsYW50 YWdlbmV0IENoZXJva2VlIEJvbGQiCiAgICAgICB4PSI0MjQuMzgzIgogICAgICAgeT0iNzk5 LjY4NDM5IgogICAgICAgaWQ9InRleHQxMDE4Ni00IgogICAgICAgc29kaXBvZGk6bGluZXNw YWNpbmc9IjEyNSUiCiAgICAgICB0cmFuc2Zvcm09InNjYWxlKDEuMTE2MDQ0NiwwLjg5NjAy MTU0KSI+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAgICAgICAgIGlk PSJ0c3BhbjEwMTg4LTAiCiAgICAgICAgIHg9IjQyNC4zODMiCiAgICAgICAgIHk9Ijc5OS42 ODQzOSI+UmVzdWx0czwvdHNwYW4+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9Imxp bmUiCiAgICAgICAgIHg9IjQyNC4zODMiCiAgICAgICAgIHk9IjgxMC41MjYzMSIKICAgICAg ICAgaWQ9InRzcGFuMTAxOTAtNyI+RGF0YXN0b3JlPC90c3Bhbj48L3RleHQ+CiAgICA8cmVj dAogICAgICAgc3R5bGU9ImZpbGw6dXJsKCNsaW5lYXJHcmFkaWVudDEwMzM5LTUpO2ZpbGwt b3BhY2l0eToxO2ZpbGwtcnVsZTpub256ZXJvO3N0cm9rZTojMDMwMDc4O3N0cm9rZS13aWR0 aDo0O3N0cm9rZS1saW5lY2FwOnNxdWFyZTtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tl LW1pdGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6bm9uZTtz dHJva2UtZGFzaG9mZnNldDowO2ZpbHRlcjp1cmwoI2ZpbHRlcjU0NzMtMy02LTEpIgogICAg ICAgaWQ9InJlY3QzMDE5LTg4LTctMCIKICAgICAgIHdpZHRoPSIxNTEuNTIyODciCiAgICAg ICBoZWlnaHQ9IjEwMi4wMjU0MSIKICAgICAgIHg9IjU0My44OTYwNiIKICAgICAgIHk9IjYx My42NzkyNiIKICAgICAgIHRyYW5zZm9ybT0ibWF0cml4KDAuMjUzNzIyMzMsMCwwLDAuMTk1 OTkzMDYsMzU5Ljc4MjY3LDcxMy43NTQ1NSkiIC8+CiAgICA8cmVjdAogICAgICAgc3R5bGU9 ImZpbGw6dXJsKCNsaW5lYXJHcmFkaWVudDU0OTMtOC05LTIpO2ZpbGwtb3BhY2l0eToxO2Zp bGwtcnVsZTpub256ZXJvO3N0cm9rZTojMDMwMDc4O3N0cm9rZS13aWR0aDo0O3N0cm9rZS1s aW5lY2FwOnNxdWFyZTtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6 NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6bm9uZTtzdHJva2UtZGFzaG9m ZnNldDowO2ZpbHRlcjp1cmwoI2ZpbHRlcjU0NzMtOC02LTYpIgogICAgICAgaWQ9InJlY3Qz MDE5LTYtNS05IgogICAgICAgd2lkdGg9IjE1MS41MjI4NyIKICAgICAgIGhlaWdodD0iMTAy LjAyNTQxIgogICAgICAgeD0iNTQzLjg5NjA2IgogICAgICAgeT0iNDQxLjMyMzk3IgogICAg ICAgdHJhbnNmb3JtPSJtYXRyaXgoMC4yNTM3MjIzMywwLDAsMC4xOTU5OTMwNiwzNTkuNzgy NjcsNzEzLjc1NDU1KSIgLz4KICAgIDx0ZXh0CiAgICAgICB4bWw6c3BhY2U9InByZXNlcnZl IgogICAgICAgc3R5bGU9ImZvbnQtc2l6ZTo3LjEzNTkxNTI4cHg7Zm9udC1zdHlsZTpub3Jt YWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdlaWdodDpib2xkO2ZvbnQtc3RyZXRjaDpu b3JtYWw7dGV4dC1hbGlnbjpjZW50ZXI7bGluZS1oZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2lu ZzowcHg7d29yZC1zcGFjaW5nOjBweDt3cml0aW5nLW1vZGU6bHItdGI7dGV4dC1hbmNob3I6 bWlkZGxlO2ZpbGw6IzQxMDAwMDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZh bWlseTpQbGFudGFnZW5ldCBDaGVyb2tlZTstaW5rc2NhcGUtZm9udC1zcGVjaWZpY2F0aW9u OlBsYW50YWdlbmV0IENoZXJva2VlIEJvbGQiCiAgICAgICB4PSI0NTQuMjYyMDIiCiAgICAg ICB5PSI5MjQuMzMzOTgiCiAgICAgICBpZD0idGV4dDEwMTk2LTctNyIKICAgICAgIHNvZGlw b2RpOmxpbmVzcGFjaW5nPSIxMjUlIgogICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjEzNzc4 MTgsMC44Nzg5MDMxNCkiPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgog ICAgICAgICBpZD0idHNwYW4xMDE5OC04LTMiCiAgICAgICAgIHg9IjQ1NC4yNjIwMiIKICAg ICAgICAgeT0iOTI0LjMzMzk4Ij5FdmFsdWF0b3I8L3RzcGFuPjwvdGV4dD4KICAgIDx0ZXh0 CiAgICAgICB4bWw6c3BhY2U9InByZXNlcnZlIgogICAgICAgc3R5bGU9ImZvbnQtc2l6ZTo3 LjEzNTkxNTI4cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250 LXdlaWdodDpib2xkO2ZvbnQtc3RyZXRjaDpub3JtYWw7dGV4dC1hbGlnbjpjZW50ZXI7bGlu ZS1oZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29yZC1zcGFjaW5nOjBweDt3cml0 aW5nLW1vZGU6bHItdGI7dGV4dC1hbmNob3I6bWlkZGxlO2ZpbGw6IzQ4MDAwMDtmaWxsLW9w YWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpQbGFudGFnZW5ldCBDaGVyb2tlZTst aW5rc2NhcGUtZm9udC1zcGVjaWZpY2F0aW9uOlBsYW50YWdlbmV0IENoZXJva2VlIEJvbGQi CiAgICAgICB4PSI0NTQuMjE1OTciCiAgICAgICB5PSI5NTguMjU3NTEiCiAgICAgICBpZD0i dGV4dDEwMjAwLTItNyIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIxMjUlIgogICAg ICAgdHJhbnNmb3JtPSJzY2FsZSgxLjEzNzc4MTgsMC44Nzg5MDMxNCkiPjx0c3BhbgogICAg ICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBpZD0idHNwYW4xMDIwMi03LTIi CiAgICAgICAgIHg9IjQ1NC4yMTU5NyIKICAgICAgICAgeT0iOTU4LjI1NzUxIj5EYXRhPC90 c3Bhbj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAgICAgeD0i NDU0LjIxNTk3IgogICAgICAgICB5PSI5NjcuMTc3NDMiCiAgICAgICAgIGlkPSJ0c3BhbjEw MjA0LTgtNiI+Q29sbGVjdG9yPC90c3Bhbj48L3RleHQ+CiAgICA8cmVjdAogICAgICAgc3R5 bGU9ImZpbGw6dXJsKCNsaW5lYXJHcmFkaWVudDEwNDAxLTYpO2ZpbGwtb3BhY2l0eToxO2Zp bGwtcnVsZTpub256ZXJvO3N0cm9rZTojMDMwMDc4O3N0cm9rZS13aWR0aDo0O3N0cm9rZS1s aW5lY2FwOnNxdWFyZTtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6 NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6bm9uZTtzdHJva2UtZGFzaG9m ZnNldDowO2ZpbHRlcjp1cmwoI2ZpbHRlcjU0NzMtOS04LTIpIgogICAgICAgaWQ9InJlY3Qz MDE5LTQtMi0wIgogICAgICAgd2lkdGg9IjE1MS41MjI4NyIKICAgICAgIGhlaWdodD0iMTAy LjAyNTQxIgogICAgICAgeD0iMzA4LjcxMDgyIgogICAgICAgeT0iMjY5LjY0NzUyIgogICAg ICAgdHJhbnNmb3JtPSJtYXRyaXgoMC4yNTM3MjIzMywwLDAsMC4xOTU5OTMwNiwzNzEuMzY4 MzcsNzYzLjcyNzEzKSIgLz4KICAgIDxwYXRoCiAgICAgICBzdHlsZT0iZmlsbDpub25lO3N0 cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDowLjIyMjk5NzM1cHg7c3Ryb2tlLWxpbmVjYXA6 YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW9wYWNpdHk6MSIKICAgICAgIGQ9 Im0gNDY4LjkxNzU3LDgyNi41NzQzMSAwLDAiCiAgICAgICBpZD0icGF0aDU1OTQtOC0xIgog ICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLXR5cGU9InBvbHlsaW5lIgogICAgICAgaW5rc2Nh cGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMyIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24t c3RhcnQ9IiNyZWN0MzAxOS00LTItMCIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tc3Rh cnQtcG9pbnQ9ImQ0IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQ9IiNyZWN0MzAx OS00LTItMCIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tZW5kLXBvaW50PSJkNCIgLz4K ICAgIDx0ZXh0CiAgICAgICB4bWw6c3BhY2U9InByZXNlcnZlIgogICAgICAgc3R5bGU9ImZv bnQtc2l6ZTo2LjI0MzkyNTU3cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5v cm1hbDtmb250LXdlaWdodDpib2xkO2ZvbnQtc3RyZXRjaDpub3JtYWw7dGV4dC1hbGlnbjpj ZW50ZXI7bGluZS1oZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29yZC1zcGFjaW5n OjBweDt3cml0aW5nLW1vZGU6bHItdGI7dGV4dC1hbmNob3I6bWlkZGxlO2ZpbGw6IzAwMDA4 MjtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpQbGFudGFnZW5ldCBD aGVyb2tlZTstaW5rc2NhcGUtZm9udC1zcGVjaWZpY2F0aW9uOlBsYW50YWdlbmV0IENoZXJv a2VlIEJvbGQiCiAgICAgICB4PSI0MTEuOTUzMDMiCiAgICAgICB5PSI5NDIuOTM0MDgiCiAg ICAgICBpZD0idGV4dDEwMTkyLTItNiIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIx MjUlIgogICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjEzNzc4MTgsMC44Nzg5MDMxNCkiPjx0 c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBpZD0idHNwYW4x MDE5NC0wLTUiCiAgICAgICAgIHg9IjQxMS45NTMwMyIKICAgICAgICAgeT0iOTQyLjkzNDA4 Ij5Db250cm9sbGVyPC90c3Bhbj48L3RleHQ+CiAgICA8cmVjdAogICAgICAgc3R5bGU9ImZp bGw6dXJsKCNsaW5lYXJHcmFkaWVudDExMDc3LTEpO2ZpbGwtb3BhY2l0eToxO2ZpbGwtcnVs ZTpub256ZXJvO3N0cm9rZTojMDMwMDc4O3N0cm9rZS13aWR0aDo0O3N0cm9rZS1saW5lY2Fw OnNxdWFyZTtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6NDtzdHJv a2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6bm9uZTtzdHJva2UtZGFzaG9mZnNldDow O2ZpbHRlcjp1cmwoI2ZpbHRlcjU0NzMtMy03LTIpIgogICAgICAgaWQ9InJlY3QzMDE5LTg4 LTEtNyIKICAgICAgIHdpZHRoPSIxNTEuNTIyODciCiAgICAgICBoZWlnaHQ9IjEwMi4wMjU0 MSIKICAgICAgIHg9IjU0My44OTYwNiIKICAgICAgIHk9IjYxMy42NzkyNiIKICAgICAgIHRy YW5zZm9ybT0ibWF0cml4KDAuMjUzNzIyMzMsMCwwLDAuMTk1OTkzMDYsNDcyLjkzNzI5LDYw Ny41NjY0NCkiIC8+CiAgICA8dGV4dAogICAgICAgeG1sOnNwYWNlPSJwcmVzZXJ2ZSIKICAg ICAgIHN0eWxlPSJmb250LXNpemU6Ny4xMzU5MTUyOHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2Zv bnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0cmV0Y2g6bm9ybWFs O3RleHQtYWxpZ246Y2VudGVyO2xpbmUtaGVpZ2h0OjEyNSU7bGV0dGVyLXNwYWNpbmc6MHB4 O3dvcmQtc3BhY2luZzowcHg7d3JpdGluZy1tb2RlOmxyLXRiO3RleHQtYW5jaG9yOm1pZGRs ZTtmaWxsOiM0ODAwMDA7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1mYW1pbHk6 UGxhbnRhZ2VuZXQgQ2hlcm9rZWU7LWlua3NjYXBlLWZvbnQtc3BlY2lmaWNhdGlvbjpQbGFu dGFnZW5ldCBDaGVyb2tlZSBCb2xkIgogICAgICAgeD0iNTUzLjY2Nzg1IgogICAgICAgeT0i ODM3LjQzODY2IgogICAgICAgaWQ9InRleHQxMDIwMC02LTUiCiAgICAgICBzb2RpcG9kaTps aW5lc3BhY2luZz0iMTI1JSIKICAgICAgIHRyYW5zZm9ybT0ic2NhbGUoMS4xMzc3ODE4LDAu ODc4OTAzMTQpIj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAg ICAgaWQ9InRzcGFuMTAyMDItMC00IgogICAgICAgICB4PSI1NTMuNjY3ODUiCiAgICAgICAg IHk9IjgzNy40Mzg2NiI+RGF0YTwvdHNwYW4+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJv bGU9ImxpbmUiCiAgICAgICAgIHg9IjU1My42Njc4NSIKICAgICAgICAgeT0iODQ2LjM1ODU4 IgogICAgICAgICBpZD0idHNwYW4xMDIwNC05LTEiPkNvbGxlY3RvcjwvdHNwYW4+PC90ZXh0 PgogICAgPHRleHQKICAgICAgIHhtbDpzcGFjZT0icHJlc2VydmUiCiAgICAgICBzdHlsZT0i Zm9udC1zaXplOjcuMTM1OTE1MjhweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6 bm9ybWFsO2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1zdHJldGNoOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O2xpbmUtaGVpZ2h0OjEyNSU7bGV0dGVyLXNwYWNpbmc6MHB4O3dvcmQtc3BhY2lu ZzowcHg7d3JpdGluZy1tb2RlOmxyLXRiO3RleHQtYW5jaG9yOnN0YXJ0O2ZpbGw6IzAwNDEw MDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpQbGFudGFnZW5ldCBD aGVyb2tlZTstaW5rc2NhcGUtZm9udC1zcGVjaWZpY2F0aW9uOlBsYW50YWdlbmV0IENoZXJv a2VlIEJvbGQiCiAgICAgICB4PSIyODQuMzM2OTEiCiAgICAgICB5PSI4MTUuNzM1MjkiCiAg ICAgICBpZD0idGV4dDEwMTc0LTctMiIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIx MjUlIgogICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjEzNzc4MTgsMC44Nzg5MDMxNCkiPjx0 c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBpZD0idHNwYW4x MDE3Ni0yLTAiCiAgICAgICAgIHg9IjI4NC4zMzY5MSIKICAgICAgICAgeT0iODE1LjczNTI5 Ij5SZXN1bHRzPC90c3Bhbj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIK ICAgICAgICAgeD0iMjg0LjMzNjkxIgogICAgICAgICB5PSI4MjQuNjU1MjEiCiAgICAgICAg IGlkPSJ0c3BhbjEwMTc4LTUtMCI+Vmlld2VyPC90c3Bhbj48L3RleHQ+CiAgICA8cGF0aAog ICAgICAgc3R5bGU9ImZpbGw6bm9uZTtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MC41 ODA1NTgzNnB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0 cm9rZS1vcGFjaXR5OjE7bWFya2VyLXN0YXJ0OnVybCgjQXJyb3cxTXN0YXJ0KTttYXJrZXIt ZW5kOnVybCgjQXJyb3cxTWVuZCkiCiAgICAgICBkPSJtIDM3MC40MDI2Myw3MTguNzE1NTgg NTYuODg2MTMsLTAuMDA5IgogICAgICAgaWQ9InBhdGgxMTE4Mi0xIgogICAgICAgaW5rc2Nh cGU6Y29ubmVjdG9yLXR5cGU9InBvbHlsaW5lIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdG9y LWN1cnZhdHVyZT0iMyIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tc3RhcnQ9IiNyZWN0 MTA0MzItNS0yLTItOSIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tc3RhcnQtcG9pbnQ9 ImQ0IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQ9IiNyZWN0MTA0MzItNS0yLTUt MyIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tZW5kLXBvaW50PSJkNCIgLz4KICAgIDxw YXRoCiAgICAgICBzdHlsZT0iZmlsbDpub25lO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0 aDowLjU4MDU1ODM2cHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0 ZXI7c3Ryb2tlLW9wYWNpdHk6MTttYXJrZXItc3RhcnQ6dXJsKCNBcnJvdzFNc3RhcnQpO21h cmtlci1lbmQ6dXJsKCNBcnJvdzFNZW5kKSIKICAgICAgIGQ9Im0gMzY2LjIwMjAyLDgwMy4y MjczMyA2OS41NTI3NiwtNTQuNzIxMDciCiAgICAgICBpZD0icGF0aDExMTg0LTQiCiAgICAg ICBpbmtzY2FwZTpjb25uZWN0b3ItdHlwZT0icG9seWxpbmUiCiAgICAgICBpbmtzY2FwZTpj b25uZWN0b3ItY3VydmF0dXJlPSIzIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFy dD0iI3JlY3QxMDQzMi01LTItMS0xIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFy dC1wb2ludD0iZDQiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLWVuZD0iI3JlY3QxMDQz Mi01LTItNS0zIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQtcG9pbnQ9ImQ0IiAv PgogICAgPHBhdGgKICAgICAgIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlOiMwMDAwMDA7c3Ry b2tlLXdpZHRoOjAuNTk3OTIxODVweDtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5l am9pbjptaXRlcjtzdHJva2Utb3BhY2l0eToxO21hcmtlci1zdGFydDp1cmwoI0Fycm93MU1z dGFydCk7bWFya2VyLWVuZDp1cmwoI0Fycm93MU1lbmQpIgogICAgICAgZD0ibSA1MzYuMjI1 OTgsODAxLjE0MzggOTQuNzA5ODgsLTUzLjMwNDIiCiAgICAgICBpZD0icGF0aDExMTg4LTYi CiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItdHlwZT0icG9seWxpbmUiCiAgICAgICBpbmtz Y2FwZTpjb25uZWN0b3ItY3VydmF0dXJlPSIzIiAvPgogICAgPHBhdGgKICAgICAgIHN0eWxl PSJmaWxsOm5vbmU7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjAuNTgwNTU4MzY7c3Ry b2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlLW1pdGVybGlt aXQ6NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1kYXNoYXJyYXk6MC41ODA1NTgzNCwgMS4x NjExMTY3O3N0cm9rZS1kYXNob2Zmc2V0OjA7bWFya2VyLXN0YXJ0OnVybCgjQXJyb3cxTXN0 YXJ0KTttYXJrZXItZW5kOnVybCgjQXJyb3cxTWVuZCkiCiAgICAgICBkPSJtIDUzNi4yMjU5 OCw4NDIuMTY0MzEgNTkuOTEzNjcsLTUuODEzNzciCiAgICAgICBpZD0icGF0aDExMTkwLTAi CiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItdHlwZT0icG9seWxpbmUiCiAgICAgICBpbmtz Y2FwZTpjb25uZWN0b3ItY3VydmF0dXJlPSIzIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlv bi1zdGFydD0iI3JlY3QzMDE5LTg4LTctMCIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24t c3RhcnQtcG9pbnQ9ImQ0IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQ9IiNyZWN0 MTA0MzItNS02IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQtcG9pbnQ9ImQ0IiAv PgogICAgPHBhdGgKICAgICAgIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlOiMwMDAwMDA7c3Ry b2tlLXdpZHRoOjAuNTgwNTU4MzY7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpv aW46bWl0ZXI7c3Ryb2tlLW1pdGVybGltaXQ6NDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1k YXNoYXJyYXk6MC41ODA1NTgzNCwgMS4xNjExMTY3O3N0cm9rZS1kYXNob2Zmc2V0OjA7bWFy a2VyLXN0YXJ0OnVybCgjQXJyb3cxTXN0YXJ0KTttYXJrZXItZW5kOnVybCgjQXJyb3cxTWVu ZCkiCiAgICAgICBkPSJtIDUzNi4yMjU5OCw4NTEuNzE0OTIgNTkuOTM1NzIsMjMuOTYzMDki CiAgICAgICBpZD0icGF0aDExMTkyLTciCiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItdHlw ZT0icG9seWxpbmUiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3ItY3VydmF0dXJlPSIzIgog ICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFydD0iI3JlY3QzMDE5LTg4LTctMCIKICAg ICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tc3RhcnQtcG9pbnQ9ImQ0IgogICAgICAgaW5rc2Nh cGU6Y29ubmVjdGlvbi1lbmQ9IiNyZWN0MTA0MzItNS01LTAiCiAgICAgICBpbmtzY2FwZTpj b25uZWN0aW9uLWVuZC1wb2ludD0iZDQiIC8+CiAgICA8cGF0aAogICAgICAgc3R5bGU9ImZp bGw6bm9uZTtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MC41ODA1NTgzNjtzdHJva2Ut bGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2UtbWl0ZXJsaW1pdDo0 O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLWRhc2hhcnJheTowLjU4MDU1ODM0LCAxLjE2MTEx Njc7c3Ryb2tlLWRhc2hvZmZzZXQ6MDttYXJrZXItc3RhcnQ6dXJsKCNBcnJvdzFNc3RhcnQp O21hcmtlci1lbmQ6dXJsKCNBcnJvdzFNZW5kKSIKICAgICAgIGQ9Im0gNTI4LjI0NzkzLDg1 NC4wMjc3IDc3LjgzMzU0LDY5LjIwNzQxIgogICAgICAgaWQ9InBhdGgxMTE5NC0xIgogICAg ICAgaW5rc2NhcGU6Y29ubmVjdG9yLXR5cGU9InBvbHlsaW5lIgogICAgICAgaW5rc2NhcGU6 Y29ubmVjdG9yLWN1cnZhdHVyZT0iMyIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tc3Rh cnQ9IiNyZWN0MzAxOS04OC03LTAiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLXN0YXJ0 LXBvaW50PSJkNCIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tZW5kPSIjcmVjdDEwNDMy LTUtMi02IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQtcG9pbnQ9ImQ0IiAvPgog ICAgPHRleHQKICAgICAgIHhtbDpzcGFjZT0icHJlc2VydmUiCiAgICAgICBzdHlsZT0iZm9u dC1zaXplOjEwLjQ1MDA1MDM1cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5v cm1hbDtmb250LXdlaWdodDpib2xkO2ZvbnQtc3RyZXRjaDpub3JtYWw7dGV4dC1hbGlnbjpj ZW50ZXI7bGluZS1oZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29yZC1zcGFjaW5n OjBweDt3cml0aW5nLW1vZGU6bHItdGI7dGV4dC1hbmNob3I6bWlkZGxlO2ZpbGw6IzAwNmYw MDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpSb2Q7LWlua3NjYXBl LWZvbnQtc3BlY2lmaWNhdGlvbjpSb2QgQm9sZCIKICAgICAgIHg9IjYwNy4wODMxOSIKICAg ICAgIHk9Ijc5OS4xMDcxMiIKICAgICAgIGlkPSJ0ZXh0MTQ2MTctMiIKICAgICAgIHNvZGlw b2RpOmxpbmVzcGFjaW5nPSIxMjUlIgogICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjAzNzkw ODYsMC45NjM0NzU5NykiPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgog ICAgICAgICBpZD0idHNwYW4xNDYxOS02IgogICAgICAgICB4PSI2MDcuMDgzMTkiCiAgICAg ICAgIHk9Ijc5OS4xMDcxMiI+Q29tcHV0ZXI8L3RzcGFuPjx0c3BhbgogICAgICAgICBzb2Rp cG9kaTpyb2xlPSJsaW5lIgogICAgICAgICB4PSI2MDcuMDgzMTkiCiAgICAgICAgIHk9Ijgx Mi4xNjk2OCIKICAgICAgICAgaWQ9InRzcGFuMTQ2MjEtNiI+KHcvYWdlbnQpPC90c3Bhbj48 L3RleHQ+CiAgICA8dGV4dAogICAgICAgeG1sOnNwYWNlPSJwcmVzZXJ2ZSIKICAgICAgIHN0 eWxlPSJmb250LXNpemU6MTAuNDUwMDUwMzVweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZh cmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1zdHJldGNoOm5vcm1hbDt0ZXh0 LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxMjUlO2xldHRlci1zcGFjaW5nOjBweDt3b3Jk LXNwYWNpbmc6MHB4O3dyaXRpbmctbW9kZTpsci10Yjt0ZXh0LWFuY2hvcjptaWRkbGU7Zmls bDojMDA2ZjAwO2ZpbGwtb3BhY2l0eToxO3N0cm9rZTpub25lO2ZvbnQtZmFtaWx5OlJvZDst aW5rc2NhcGUtZm9udC1zcGVjaWZpY2F0aW9uOlJvZCBCb2xkIgogICAgICAgeD0iNjA3LjA4 MzE5IgogICAgICAgeT0iMTAxNS41NjYyIgogICAgICAgaWQ9InRleHQxNDYyMy0wIgogICAg ICAgc29kaXBvZGk6bGluZXNwYWNpbmc9IjEyNSUiCiAgICAgICB0cmFuc2Zvcm09InNjYWxl KDEuMDM3OTA4NiwwLjk2MzQ3NTk3KSI+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9 ImxpbmUiCiAgICAgICAgIGlkPSJ0c3BhbjE0NjI1LTMiCiAgICAgICAgIHg9IjYwNy4wODMx OSIKICAgICAgICAgeT0iMTAxNS41NjYyIj5Db21wdXRlcnM8L3RzcGFuPjx0c3BhbgogICAg ICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICB4PSI2MDcuMDgzMTkiCiAgICAg ICAgIHk9IjEwMjguNjI4OCIKICAgICAgICAgaWQ9InRzcGFuMTQ2MjctOCI+KGFnZW50bGVz cyk8L3RzcGFuPjwvdGV4dD4KICAgIDx0ZXh0CiAgICAgICB4bWw6c3BhY2U9InByZXNlcnZl IgogICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC40NTAwNTAzNXB4O2ZvbnQtc3R5bGU6bm9y bWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0cmV0Y2g6 bm9ybWFsO3RleHQtYWxpZ246Y2VudGVyO2xpbmUtaGVpZ2h0OjEyNSU7bGV0dGVyLXNwYWNp bmc6MHB4O3dvcmQtc3BhY2luZzowcHg7d3JpdGluZy1tb2RlOmxyLXRiO3RleHQtYW5jaG9y Om1pZGRsZTtmaWxsOiMwMDZmMDA7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7Zm9udC1m YW1pbHk6Um9kOy1pbmtzY2FwZS1mb250LXNwZWNpZmljYXRpb246Um9kIEJvbGQiCiAgICAg ICB4PSIzMjcuOTM1NyIKICAgICAgIHk9IjkwNi44ODY4NCIKICAgICAgIGlkPSJ0ZXh0MTUw NDEtMSIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIxMjUlIgogICAgICAgdHJhbnNm b3JtPSJzY2FsZSgxLjAzNzkwODYsMC45NjM0NzU5NykiPjx0c3BhbgogICAgICAgICBzb2Rp cG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBpZD0idHNwYW4xNTA0My0yIgogICAgICAgICB4 PSIzMjcuOTM1NyIKICAgICAgICAgeT0iOTA2Ljg4Njg0Ij5BZG1pbmlzdHJhdG9yPC90c3Bh bj48dHNwYW4KICAgICAgICAgc29kaXBvZGk6cm9sZT0ibGluZSIKICAgICAgICAgeD0iMzI3 LjkzNTciCiAgICAgICAgIHk9IjkxOS45NDk0IgogICAgICAgICBpZD0idHNwYW4xNTA0NS01 Ij5Xb3Jrc3RhdGlvbjwvdHNwYW4+PC90ZXh0PgogICAgPHRleHQKICAgICAgIHhtbDpzcGFj ZT0icHJlc2VydmUiCiAgICAgICBzdHlsZT0iZm9udC1zaXplOjEwLjQ1MDA1MDM1cHg7Zm9u dC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdlaWdodDpib2xkO2Zv bnQtc3RyZXRjaDpub3JtYWw7dGV4dC1hbGlnbjpjZW50ZXI7bGluZS1oZWlnaHQ6MTI1JTts ZXR0ZXItc3BhY2luZzowcHg7d29yZC1zcGFjaW5nOjBweDt3cml0aW5nLW1vZGU6bHItdGI7 dGV4dC1hbmNob3I6bWlkZGxlO2ZpbGw6IzAwNmYwMDtmaWxsLW9wYWNpdHk6MTtzdHJva2U6 bm9uZTtmb250LWZhbWlseTpSb2Q7LWlua3NjYXBlLWZvbnQtc3BlY2lmaWNhdGlvbjpSb2Qg Qm9sZCIKICAgICAgIHg9IjMyNi4yMjIyOSIKICAgICAgIHk9Ijc3OC45NTMzNyIKICAgICAg IGlkPSJ0ZXh0MTUwNDctMCIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5nPSIxMjUlIgog ICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjAzNzkwODYsMC45NjM0NzU5NykiPjx0c3Bhbgog ICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBpZD0idHNwYW4xNTA0OS05 IgogICAgICAgICB4PSIzMjYuMjIyMjkiCiAgICAgICAgIHk9Ijc3OC45NTMzNyI+TWFuYWdl cjwvdHNwYW4+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAgICAgICAg IHg9IjMyNi4yMjIyOSIKICAgICAgICAgeT0iNzkyLjAxNTkzIgogICAgICAgICBpZD0idHNw YW4xNTA1MS00Ij5Xb3Jrc3RhdGlvbjwvdHNwYW4+PC90ZXh0PgogICAgPHRleHQKICAgICAg IHhtbDpzcGFjZT0icHJlc2VydmUiCiAgICAgICBzdHlsZT0iZm9udC1zaXplOjEwLjQ1MDA1 MDM1cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdlaWdo dDpib2xkO2ZvbnQtc3RyZXRjaDpub3JtYWw7dGV4dC1hbGlnbjpjZW50ZXI7bGluZS1oZWln aHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29yZC1zcGFjaW5nOjBweDt3cml0aW5nLW1v ZGU6bHItdGI7dGV4dC1hbmNob3I6bWlkZGxlO2ZpbGw6IzAwNmYwMDtmaWxsLW9wYWNpdHk6 MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpSb2Q7LWlua3NjYXBlLWZvbnQtc3BlY2lmaWNh dGlvbjpSb2QgQm9sZCIKICAgICAgIHg9IjQ1NC4wMDQ5MSIKICAgICAgIHk9Ijc5MC4zNzYw NCIKICAgICAgIGlkPSJ0ZXh0MTQ2MjktNyIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFjaW5n PSIxMjUlIgogICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjAzNzkwODYsMC45NjM0NzU5Nyki Pjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBpZD0idHNw YW4xNDYzMS04IgogICAgICAgICB4PSI0NTQuMDA0OTEiCiAgICAgICAgIHk9Ijc5MC4zNzYw NCI+RGF0YWJhc2U8L3RzcGFuPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5l IgogICAgICAgICB4PSI0NTQuMDA0OTEiCiAgICAgICAgIHk9IjgwMy40Mzg2IgogICAgICAg ICBpZD0idHNwYW4xNDYzMy0zIj5TZXJ2ZXI8L3RzcGFuPjwvdGV4dD4KICAgIDxwYXRoCiAg ICAgICBzdHlsZT0iZmlsbDpub25lO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDowLjU4 MDU1ODM2cHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ry b2tlLW9wYWNpdHk6MTttYXJrZXItc3RhcnQ6dXJsKCNBcnJvdzFNc3RhcnQpO21hcmtlci1l bmQ6dXJsKCNBcnJvdzFNZW5kKSIKICAgICAgIGQ9Ik0gMzU1LjYwNjM4LDg0MS4zODg2OCA0 NDkuNjk1Miw4MjkuMDg3NDUiCiAgICAgICBpZD0icGF0aDE1MDY1LTEiCiAgICAgICBpbmtz Y2FwZTpjb25uZWN0b3ItdHlwZT0icG9seWxpbmUiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0 b3ItY3VydmF0dXJlPSIzIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFydD0iI3Jl Y3QzMDE5LTg0IgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFydC1wb2ludD0iZDQi CiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLWVuZD0iI3JlY3QzMDE5LTQtMi0wIgogICAg ICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1lbmQtcG9pbnQ9ImQ0IiAvPgogICAgPHRleHQKICAg ICAgIHhtbDpzcGFjZT0icHJlc2VydmUiCiAgICAgICBzdHlsZT0iZm9udC1zaXplOjEwLjQ1 MDA1MDM1cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdl aWdodDpib2xkO2ZvbnQtc3RyZXRjaDpub3JtYWw7dGV4dC1hbGlnbjpjZW50ZXI7bGluZS1o ZWlnaHQ6MTI1JTtsZXR0ZXItc3BhY2luZzowcHg7d29yZC1zcGFjaW5nOjBweDt3cml0aW5n LW1vZGU6bHItdGI7dGV4dC1hbmNob3I6bWlkZGxlO2ZpbGw6IzAwNmYwMDtmaWxsLW9wYWNp dHk6MTtzdHJva2U6bm9uZTtmb250LWZhbWlseTpSb2Q7LWlua3NjYXBlLWZvbnQtc3BlY2lm aWNhdGlvbjpSb2QgQm9sZCIKICAgICAgIHg9IjQ3NS4xNTM1OSIKICAgICAgIHk9IjkwNC42 MDIyOSIKICAgICAgIGlkPSJ0ZXh0MTU2NzMtNiIKICAgICAgIHNvZGlwb2RpOmxpbmVzcGFj aW5nPSIxMjUlIgogICAgICAgdHJhbnNmb3JtPSJzY2FsZSgxLjAzNzkwODYsMC45NjM0NzU5 NykiPjx0c3BhbgogICAgICAgICBzb2RpcG9kaTpyb2xlPSJsaW5lIgogICAgICAgICBpZD0i dHNwYW4xNTY3NS00IgogICAgICAgICB4PSI0NzUuMTUzNTkiCiAgICAgICAgIHk9IjkwNC42 MDIyOSI+QXNzZXNzbWVudDwvdHNwYW4+PHRzcGFuCiAgICAgICAgIHNvZGlwb2RpOnJvbGU9 ImxpbmUiCiAgICAgICAgIHg9IjQ3NS4xNTM1OSIKICAgICAgICAgeT0iOTE3LjY2NDg2Igog ICAgICAgICBpZD0idHNwYW4xNTY3Ny0wIj5TZXJ2ZXI8L3RzcGFuPjwvdGV4dD4KICAgIDxw YXRoCiAgICAgICBzdHlsZT0iZmlsbDpub25lO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0 aDowLjU4MDU1ODM2cHg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0 ZXI7c3Ryb2tlLW9wYWNpdHk6MTttYXJrZXItc3RhcnQ6dXJsKCNBcnJvdzFNc3RhcnQpO21h cmtlci1lbmQ6dXJsKCNBcnJvdzFNZW5kKSIKICAgICAgIGQ9Im0gNDY5LjM1NTQxLDgxNi41 NzYxNyAyLjk1ODYxLC02Ny41NTk3MiIKICAgICAgIGlkPSJwYXRoMTYwODctNiIKICAgICAg IGlua3NjYXBlOmNvbm5lY3Rvci10eXBlPSJwb2x5bGluZSIKICAgICAgIGlua3NjYXBlOmNv bm5lY3Rvci1jdXJ2YXR1cmU9IjMiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLXN0YXJ0 PSIjcmVjdDMwMTktNC0yLTAiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLXN0YXJ0LXBv aW50PSJkNCIKICAgICAgIGlua3NjYXBlOmNvbm5lY3Rpb24tZW5kPSIjcmVjdDEwNDMyLTUt Mi01LTMiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0aW9uLWVuZC1wb2ludD0iZDQiIC8+CiAg ICA8cGF0aAogICAgICAgc3R5bGU9ImZpbGw6bm9uZTtzdHJva2U6IzAwMDAwMDtzdHJva2Ut d2lkdGg6MXB4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0 cm9rZS1vcGFjaXR5OjE7bWFya2VyLXN0YXJ0OnVybCgjbWFya2VyMzI3Mik7bWFya2VyLWVu ZDp1cmwoI21hcmtlcjMyNzYpIgogICAgICAgZD0iTSA0MzguOTAxNTIsNjY3LjkzNTA2IDM1 Ni45NDk3NiwzNTQuMjk3MzMiCiAgICAgICBpZD0icGF0aDQ4MDgiCiAgICAgICBpbmtzY2Fw ZTpjb25uZWN0b3ItdHlwZT0icG9seWxpbmUiCiAgICAgICBpbmtzY2FwZTpjb25uZWN0b3It Y3VydmF0dXJlPSIzIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFydD0iI3JlY3Qz ODUyIgogICAgICAgaW5rc2NhcGU6Y29ubmVjdGlvbi1zdGFydC1wb2ludD0iZDQiCiAgICAg ICBpbmtzY2FwZTpjb25uZWN0aW9uLWVuZD0iI3JlY3QzMDE5LTQtMiIKICAgICAgIGlua3Nj YXBlOmNvbm5lY3Rpb24tZW5kLXBvaW50PSJkNCIgLz4KICAgIDx0ZXh0CiAgICAgICB4bWw6 c3BhY2U9InByZXNlcnZlIgogICAgICAgc3R5bGU9ImZvbnQtc2l6ZTozNnB4O2ZvbnQtc3R5 bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0 cmV0Y2g6bm9ybWFsO3RleHQtYWxpZ246Y2VudGVyO2xpbmUtaGVpZ2h0OjEyNSU7bGV0dGVy LXNwYWNpbmc6MHB4O3dvcmQtc3BhY2luZzowcHg7d3JpdGluZy1tb2RlOmxyLXRiO3RleHQt YW5jaG9yOm1pZGRsZTtmaWxsOiM2NTAwMDA7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlOm5vbmU7 Zm9udC1mYW1pbHk6Um9kOy1pbmtzY2FwZS1mb250LXNwZWNpZmljYXRpb246Um9kIEJvbGQi CiAgICAgICB4PSI0MjcuMzg0NTIiCiAgICAgICB5PSI5NDkuNzkxMDgiCiAgICAgICBpZD0i dGV4dDUyOTQiCiAgICAgICBzb2RpcG9kaTpsaW5lc3BhY2luZz0iMTI1JSI+PHRzcGFuCiAg ICAgICAgIHNvZGlwb2RpOnJvbGU9ImxpbmUiCiAgICAgICAgIGlkPSJ0c3BhbjUyOTYiCiAg ICAgICAgIHg9IjQyNy4zODQ1MiIKICAgICAgICAgeT0iOTQ5Ljc5MTA4Ij5TdWJkb21haW48 L3RzcGFuPjwvdGV4dD4KICA8L2c+Cjwvc3ZnPgo= --------------010902070800010109090005-- From ietfdbh@comcast.net Fri Jul 12 09:03:15 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016C911E811A for ; Fri, 12 Jul 2013 09:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.118 X-Spam-Level: X-Spam-Status: No, score=-100.118 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMRU04BzQQ5z for ; Fri, 12 Jul 2013 09:03:08 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 1389E21F9A18 for ; Fri, 12 Jul 2013 09:03:07 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA11.westchester.pa.mail.comcast.net with comcast id zPNL1l00117dt5G5BU37Nm; Fri, 12 Jul 2013 16:03:07 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta13.westchester.pa.mail.comcast.net with comcast id zU361l01M2yZEBF3ZU37Hj; Fri, 12 Jul 2013 16:03:07 +0000 From: "ietfdbh" To: "'Gunnar Engelbach'" , "'David Harrington'" References: <20130711162658.7093.66495.idtracker@ietfa.amsl.com> <51DEDDE5.2070101@ieca.com> <012d01ce7f09$0fc8bc90$2f5a35b0$@comcast.net> <51E01C90.1040403@ThreatGuard.com> In-Reply-To: <51E01C90.1040403@ThreatGuard.com> Date: Fri, 12 Jul 2013 12:02:33 -0400 Message-ID: <013a01ce7f19$38d55ca0$aa8015e0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHznD1rOpqPCNVF4Uo3EJCv58gmKAINk8g2AjtcOjgBb90cjJjpM36A Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373644987; bh=NzRi8a2EcE+LQXUCCruDN4UdlCeOKxH+VSmHklsgYkQ=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=PmJsxCLDTKXEKYjY8ipTIsfFG7TWjYs72/EVl6Ya7pLxM5KhKQdMvx710sUtV8H4v SFJvYbvWbMkNrBc5gakMU4b0X2HrfZ4r6DMihO8jXiC8/ijckm1y2PhjPhF8hjLBxC IVzsGghQYXhLslsVBOHIe+ZjtIuQG5o2JD0Z8OwybP9LIC5WFlDPifhawBoIfNkSOb ZrqlLiogYLGD9D/UOkEOT1m+AM0zw06LYheii0J3QT+9+kI/ZT1FFI2+3dhUcKkRZi 8CPnF33CZWHFUJuL3hyCwBk2r/7ZYHy380sJu8rWDArvcRDFbMolfjyRxfJZQy1ahM 1HdedR7x0m7mQ== Cc: 'Sean Turner' , sacm@ietf.org Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 16:03:15 -0000 I can't read your svg files. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Gunnar Engelbach > Sent: Friday, July 12, 2013 11:11 AM > To: David Harrington > Cc: 'Sean Turner'; sacm@ietf.org > Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate- > architecture-00.txt > > > I like the original. It's only concerned with the logical components that make > up SACM -- the flexibility in how they are mixed and match to solve real > problems is one of its big strengths. > > But it's also apparent that this is not being effectively communicated. > > I sent some (lousy) drawings to the mailing list a while back trying to capture > that flexibility -- attached here again for your amusement/befuddlement. > > > Do very specific use cases help people understand how these standards can > be applied? > > > --gun > > > > On 7/12/2013 10:06 AM, David Harrington wrote: > > Hi, > > > > While I don't fully agree with the original architecture, I find it easier > > to understand the intended functionality than in the alternate architecture. > > > > I understand the goal here of showing where the on-the-wire protocols > > operate between entities. > > The data flows in the Waltermire architecture do not clearly capture the > > on-the-wire-ness of the flows, and what sits where in the network. > > It might be helpful to use both diagrams, combined, to show the network > > entities and on-the-wire data flows, and then show within the entity > boxes, > > the expected functionality provided by each. > > > > The new architecture seems focused on a combination firewall/IDS box; > that > > seems like a particular use case. > > As you all know already, I think the scope of the sacm work needs to be > > narrowed, but this might narrow it too much. > > > > (Sean, can you write up a firewall/IDS use case that I can put into the > > use-cases document for this usage?) > > > > David Harrington > > dbharrington@comcast.net > > +1-603-828-1401 > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of > >> Sean Turner > >> Sent: Thursday, July 11, 2013 12:32 PM > >> To: sacm@ietf.org > >> Subject: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture- > >> 00.txt > >> > >> Food for thought. > >> > >> spt > >> -------- Original Message -------- > >> Subject: I-D Action: draft-handt-sacm-alternate-architecture-00.txt > >> Date: Thu, 11 Jul 2013 09:26:58 -0700 > >> From: internet-drafts@ietf.org > >> Reply-To: internet-drafts@ietf.org > >> To: i-d-announce@ietf.org > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >> > >> > >> Title : sacm: Alternate Architecture > >> Author(s) : Russ Housley > >> Sean Turner > >> Filename : draft-handt-sacm-alternate-architecture-00.txt > >> Pages : 5 > >> Date : 2013-07-11 > >> > >> Abstract: > >> This document proposes and alternate architecture for sacm (a > >> proposed working group at the time this draft was submitted). > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-handt-sacm-alternate-architecture > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-handt-sacm-alternate-architecture-00 > >> > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> > >> > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > From iesg-secretary@ietf.org Fri Jul 12 10:05:37 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB0821F9E97; Fri, 12 Jul 2013 10:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHUZoYVmEsX8; Fri, 12 Jul 2013 10:05:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E373F21F9FA1; Fri, 12 Jul 2013 10:05:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130712170535.9173.9328.idtracker@ietfa.amsl.com> Date: Fri, 12 Jul 2013 10:05:35 -0700 Cc: sacm WG Subject: [sacm] WG Action: Formed Security Automation and Continuous Monitoring (sacm) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 17:05:37 -0000 A new IETF working group has been formed in the Security Area. For additional information please contact the Area Directors or the WG Chairs. Security Automation and Continuous Monitoring (sacm) ------------------------------------------------ Current Status: Proposed WG Chairs: Dan Romascanu Adam Montville Assigned Area Director: Sean Turner Mailing list Address: sacm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm/ Charter: Securing information and the systems that store, process, and transmit that information is a challenging task for organizations of all sizes, and many security practitioners spend much of their time on manual processes. Standardized protocols to collect, verify, and update system security configurations would allow this process to be automated, which would free security practitioners to focus on high priority tasks and should improve their ability to prioritize risk based on timely information about threats and vulnerabilities. Because this is a broad area of work, this working group will first address enterprise use cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). The working group will, whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models. Of particular interest to this working group are existing industry standards, preferably IETF standards, that could support automation of asset, change, configuration, and vulnerability management. The working group will define: 1. A set of standards to enable assessment of endpoint posture. This area of focus provides for necessary language and data format specifications. An example of such an endpoint posture assessment could include, but is not limited to, the following general steps: 1. Identify endpoints 2. Determine specific endpoint elements to assess 3. Collect actual value of elements 4. Compare actual element values to expected element values 5. Report results This approach to endpoint posture collection enables multiple policies to be evaluated based on a single data collection activity. Policies will be evaluated by comparing available endpoint posture data according to rules expressed in the policy. Typically, these rules will compare the actual value against an expected value or range for specific posture elements. In some cases, the posture element may pertain to software installation state, in which case the actual and expected values may be "installed" or "not installed." Evaluation of multiple posture elements may be combined using Boolean logic. 2. A set of standards for interacting with repositories of content related to assessment of endpoint posture. Repository protocols are needed to store, update, and retrieve configuration checks and other types of content required for posture assessment (see step 2 above). A content repository is expected to house specific versions of checklists (i.e. benchmarks), may be required to satisfy different use cases (i.e. asset inventory, configuration settings, or vulnerabilities). In addition, content repositories are expected to store up-to-date dictionary of specific enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. This working group will produce the following deliverables: - A document or documents describing the SACM Architecture. This will include protocol requirements and their associated use cases as well as a description of how SACM protocols fit together into a system. This may be a single standards-track document, or may be split up as the WG sees fit. - A standards-track document specifying the informational model for endpoints data posture. - A standards-track document specifying a protocol and data format for retrieving configuration and policy information for driving data collection and analysis - A standards-track document specifying a protocol and data format for collecting actual endpoint posture The working group will create an Internet-Draft documenting the existing work in the IETF and in other organizations that might be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. The working group will work in close coordination with other WGs in the IETF (including, but not limited to MILE and NEA) in order to create solutions that do not overlap and can be used or re-used to meet the goals of more than one working group. The working group will communicate with non-IETF organizations working on related specifications and will encourage industry participation in the development of the WG's documents. Other organizations involved in the sacm space include ISO/IEC and TCG, as well as government agencies such as NIST. SACM-related efforts are largely aligned, and may overlap, with other IETF (and non-IETF) standardization efforts. There are common "problems" found in SACM, that may be addressed by the work done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular interest to SACM is understanding and respecting the distinctions between itself and NEA and MILE. One way the NEA protocols can be used is as the transport for data collected on the endpoint to an external service or data repository for further analysis and action. NEA may also serve the purpose of carrying data-collection instructions. The MILE data formats provide a format to describe incident, threat-related incident, and indicator information. SACM data formats provide ways to understand what endpoints are in your environment, whether they meet policy requirements, and their current configuration state. The data exchanged in MILE, supplementing the SACM data, creates enhanced situational awareness, thus enabling increased understanding of current threats and mitigations. The combined SACM and MILE data sets become a powerful tool to automate security with descriptions of endpoints, known vulnerabilities to those endpoints, and their configurations along with an understanding of layered defenses. Transports from MILE may be used by SACM. This charter will expire in July 2016. If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Oct 2013 - Initial submission of SACM Architecture Internet-Draft Nov 2013 - Initial submission of SACM Information Model Internet-Draft Jan 2014 - Initial submission of protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft Jan 2014 - Initial submission of protocol and data format for collecting endpoint posture Internet-Draft May 2014 - Submit SACM Architecture Internet-Draft to the IESG for consideration as Informational RFC Sep 2014 - Submit protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft to the IESG for consideration as Proposed Standard Sep 2014 - Submit protocol and data format for collecting endpoint posture Internet-Draft to the IESG for consideration as Proposed Standard From gunnar.engelbach@threatguard.com Fri Jul 12 10:39:30 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A72A21F9E22 for ; Fri, 12 Jul 2013 10:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiNaOof-W2-d for ; Fri, 12 Jul 2013 10:39:25 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4A09611E80FB for ; Fri, 12 Jul 2013 10:39:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=kOS3d6oZ/v7ZcN6QD4SzQTZa9nzxDToNP8zq6uRT0IYD+3jeNLwZHHSWXUhSWAwyjIIpCVnFQCefXys4n3L3r6jf6mjbzklV8M0CnW5EIsEh1UzybsFSsfCjOkkfESg/; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; Received: (qmail 21511 invoked from network); 12 Jul 2013 10:37:14 -0700 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Jul 2013 10:37:11 -0700 Message-ID: <51E03F4D.1060302@ThreatGuard.com> Date: Fri, 12 Jul 2013 13:39:25 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ietfdbh References: <20130711162658.7093.66495.idtracker@ietfa.amsl.com> <51DEDDE5.2070101@ieca.com> <012d01ce7f09$0fc8bc90$2f5a35b0$@comcast.net> <51E01C90.1040403@ThreatGuard.com> <013a01ce7f19$38d55ca0$aa8015e0$@comcast.net> In-Reply-To: <013a01ce7f19$38d55ca0$aa8015e0$@comcast.net> Content-Type: multipart/mixed; boundary="------------090301090900080605040005" Cc: 'David Harrington' , 'Sean Turner' , sacm@ietf.org Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 17:39:30 -0000 This is a multi-part message in MIME format. --------------090301090900080605040005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Try these. They're just not scalable. On 7/12/2013 12:02 PM, ietfdbh wrote: > I can't read your svg files. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Gunnar Engelbach >> Sent: Friday, July 12, 2013 11:11 AM >> To: David Harrington >> Cc: 'Sean Turner'; sacm@ietf.org >> Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate- >> architecture-00.txt >> >> >> I like the original. It's only concerned with the logical components that > make >> up SACM -- the flexibility in how they are mixed and match to solve real >> problems is one of its big strengths. >> >> But it's also apparent that this is not being effectively communicated. >> >> I sent some (lousy) drawings to the mailing list a while back trying to > capture >> that flexibility -- attached here again for your amusement/befuddlement. >> >> >> Do very specific use cases help people understand how these standards can >> be applied? >> >> >> --gun >> >> >> >> On 7/12/2013 10:06 AM, David Harrington wrote: >>> Hi, >>> >>> While I don't fully agree with the original architecture, I find it > easier >>> to understand the intended functionality than in the alternate > architecture. >>> >>> I understand the goal here of showing where the on-the-wire protocols >>> operate between entities. >>> The data flows in the Waltermire architecture do not clearly capture the >>> on-the-wire-ness of the flows, and what sits where in the network. >>> It might be helpful to use both diagrams, combined, to show the network >>> entities and on-the-wire data flows, and then show within the entity >> boxes, >>> the expected functionality provided by each. >>> >>> The new architecture seems focused on a combination firewall/IDS box; >> that >>> seems like a particular use case. >>> As you all know already, I think the scope of the sacm work needs to be >>> narrowed, but this might narrow it too much. >>> >>> (Sean, can you write up a firewall/IDS use case that I can put into the >>> use-cases document for this usage?) >>> >>> David Harrington >>> dbharrington@comcast.net >>> +1-603-828-1401 >>> >>>> -----Original Message----- >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> Of >>>> Sean Turner >>>> Sent: Thursday, July 11, 2013 12:32 PM >>>> To: sacm@ietf.org >>>> Subject: [sacm] Fwd: I-D Action: > draft-handt-sacm-alternate-architecture- >>>> 00.txt >>>> >>>> Food for thought. >>>> >>>> spt >>>> -------- Original Message -------- >>>> Subject: I-D Action: draft-handt-sacm-alternate-architecture-00.txt >>>> Date: Thu, 11 Jul 2013 09:26:58 -0700 >>>> From: internet-drafts@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>> >>>> >>>> Title : sacm: Alternate Architecture >>>> Author(s) : Russ Housley >>>> Sean Turner >>>> Filename : draft-handt-sacm-alternate-architecture-00.txt >>>> Pages : 5 >>>> Date : 2013-07-11 >>>> >>>> Abstract: >>>> This document proposes and alternate architecture for sacm (a >>>> proposed working group at the time this draft was submitted). >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> > https://datatracker.ietf.org/doc/draft-handt-sacm-alternate-architecture >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-handt-sacm-alternate-architecture-00 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>>> >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>> >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>> > --------------090301090900080605040005 Content-Type: image/png; name="BasicEntities.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="BasicEntities.png" iVBORw0KGgoAAAANSUhEUgAAAukAAAQdCAYAAADjF9Y+AAAABmJLR0QA/wD/AP+gvaeTAAAg AElEQVR4nOzde3wU9dn///eGhATKSaDa0EQOQSHFG5EgRgyIFhuoEm4DLUar9itirVCUg1ix 9saf9QjEgmC9oeAJBZU7lGALqdoiEAxCQFIREEEQAZWInAnksL8/4qy7s4dswmZnknk9Hw8e 7e7Ozl6zEPPez15zjcvtdrsFAAAAwC4SY6yuAAAAAIAvQjoAAABgM4R0AAAAwGYI6QAAAIDN ENIBAAAAmyGkAwAAADZDSAcAAABshpAOAAAA2AwhHQAAALAZQjoAAABgM4R0AAAAwGYI6QAA AIDNENIBAAAAmyGkAwAAADZDSAcAAABshpAOAAAA2AwhHQAAALAZQjoAAABgM4R0AAAAwGYI 6QAAAIDNENIBAAAAmyGkAwAAADZDSAcAAABshpAOAAAA2AwhHQAAALAZQjoAAABgM4R0AAAA wGYI6QAAAIDNENIBAAAAmyGkAwAAADZDSAcAAABshpAOAAAA2AwhHQAAALAZQjoAAABgM4R0 AAAAwGYI6QAAAIDNENIBAAAAmyGkAwAAADZDSAcAAABshpAOAAAA2AwhHQAAALAZQjoAAABg M4R0AAAAwGYI6QAAAIDNENIBAAAAmyGkAwAAADZDSAcAAABshpAOAAAA2AwhHQAAALAZQjoA AABgM4R0AAAAwGYI6QAAAIDNENIBAAAAmyGkAwAAADZDSAcAAABshpAOAAAA2AwhHQAAALAZ QjoAAABgM4R0AAAAwGYI6QAAAIDNENIBAAAAmyGkAwAAADZDSAcAAABshpAOAAAA2AwhHQAA ALAZQjoAAABgM4R0AAAAwGYI6QAAAIDNENIBAAAAmyGkAwAAADZDSAcAAABshpAOAAAA2Awh HQAAALAZQjoAAABgM4R0AAAAwGYI6QAAAIDNENIBAAAAmyGkAwAAADZDSAcAAABshpAOAAAA 2AwhHQAAALAZQjoAAABgM4R0AAAAwGYI6QAAAIDNENIBAAAAmyGkAwAAADZDSAcAAABshpAO AAAA2AwhHQAAALAZQjoAAABgM7FWF2AXR46UacMH+6wuAw5xWe8Oat/+B1aXAQBRdeZMhVa/ 95nVZcAhuqeer+Tk1laXUWeE9O98vPUrDclcYHUZcIj8t27Xz6/vbnUZABBVpaWn+F2LqJk1 O0v3jLnS6jLqjHYXAAAAwGYI6QAAAIDN0O4SxA9aJqjrT35sdRloJD7bcVDHjpyyugwAsJW4 prH6yWUdrS4DjcT+PYdU+tUxq8uIGEJ6EMmdf6hH5txqdRloJB6991UVF+60ugwAsJWWrZvx uxYR879P/V0r3txgdRkRQ7sLAAAAYDOEdAAAAMBmCOkAAACAzRDSAQAAAJshpAMAAAA2Q0gH AAAAbIaQDgAAANgMIR0AAACwGUI6AAAAYDOEdAAAAMBmCOkAAACAzRDSAQAAAJshpAMAAAA2 Q0gHAAAAbIaQDgAAANgMIR0AAACwGUI6AAAAYDOxVhcAGIp3FGjqX4cFfGx01nRl9R8b5YoA AACsQUi3yMHSXbrrqR51eu7yaWURrsYeOrTranUJAAAAtkC7i0US26do+bQyLZ9WpsHpowJu M/eBrZ5tRmdN99w/9P4ETZ49MEqVRo/3e5LaMd3qcgAAACxDSLeBMcPn+N2X2jFdie1TPLez +o/1Cerb9hY1yqBuyLh0hNUlAADQaO1ZV6A96wqsLgMh0O5iE4PTR2ll0fyQ21yeOkTz8id5 bm/bW6TiHQVK65ZZ3+XZ2tD7EyRVv4eBPvAAAOBtz7oC5Y0LfA5UMNmzlqlTv4b5+zbY8Xbo md5gj8kJWElvQLxX1g1FH+VbUIl9HCzdZXUJAIAGplO/TE3YWKYJGwOf42U85v143rhhyu2T EK0SI8o43uxZy6wuBbVASEeDtmHbCqtLAAA0YAMnTve53aGn7zlRdyzd6nN78R0D67mi+tOp X6bf8cG+COlosIp3FPi0/wAAUFtdMoaEfLxNcopPsD1QUtToe7nfeXyMcvskNOgPJI0BPekN SKDWjvRLskI+J9Ts8VCjHIM9z5i6sm1vkeY+sFUbtq0IGpS995+/ZnbA7VI7puvpsatCHULY ta0smu/T12/ed7jHFKitCADgXO279tCBkiLP7cN7dzbqXu6SvNDnyCE6COkNiLm1I7VjetCT Rs1z2KfeuUxp3TJ97h96f0LAky2NEzEl34sIzfm/MZ4QbEyfyeo/Vln9xwYN4QZjO+991FVa t0wtn1bmF7pDnTham2MCAMCp3nl8jNUl4DuEdJvatrfI53agEBxsBTpYQJeqTz6deucyT7hd WTRfyeen+oRWw+D0UT5X+TQCcKCQndV/bFitJ9lXTzjnkF5bdT0mAAAkqfRT3770th0vCrrt kX27tOBG/4sVduiZrpsWrPK7f/EdA31W6b31zB6ltp1TtWqG/+9X72kzgfYR7PWCeefxMX4r 6AdKinxOlq3pNb3rHjSFaWvnip50Gxt6f4Lnj3cANi74E8wzi30vjmRebU/rlulzsSDvfdcU Vmtqr7GjxnhMAIDoOLJvl08YDTW28J3Hx3gC+sCJ030mqhiB98i+XZ795vZJ0IGSInXome6Z JuN9ImvbzqnqnTNWEzaWqWd24AsfStJNC1b5neBaW4OmzNGEjWU+/ffedU3YWKZO/TLDrhvn jpBuY4Guvjn1ztDjk4p3FPiswge7mmmg55mtLJrvd8EkI/CbV/obisZ4TACA+mNeFQ+2Ou29 Et0ze5R651R/a9upX6ZPgDX2t/J/vv/9PPiR7xeTeueMDRjIuw4MvaBkPsG1vtS2btQdId2m vIP502NXeW5P/euwkFcaNc9NX1k032dF3vgTLJCaQ/22vUWe5+SvmS2p5pV8u2mMxwQAqB/G irfxx3DH0q1B56rvWVfg0ypiDtTmCTKbX38uaKtIoOfbhflbBTO71t1QEdIbiPE3ff/Dv21v kU+fdSiD00d5AmioP8Zqcqgrds7Ln6Sh9yeE/dp20RiPCQBQP4wWDu/2kQ4909UmOfhggU9X +S6QtUnuGvI1vt270+f2ght7+JywaVx8yFiNt6uGWndDQUhvIBLbp/isrq8smh+wRWXvwXPr SZNqXlU2VucbksZ4TACA+tMmOcUT1M395GbmE0sX3NjDZzXe3DJTVXHWrzWkJG++Z/tNi2ZH 8Egip01ySoOsu6EipDcgHRN9f8hff/uJGrc5l9BuBNvRWdMDPt4QV58b4zEBAOqHuc870NQW SX4tIN4nWwb6M2jKHA2aMidoD/eqGZOU2yfBlhdNaqh1N0SE9AbEPIUkUF95ONuEYvRqe8vq P1bLp5X59Xabp6Z4r/RLgS++ZIVzOSYAgLNdfN0In9uBVovNJ2wGW3E3MyaqBJvMkjduWNj7 iqaGWndDQ0i3qUDhOtCFi8wtL+FsE4oRtAM9J1Rvd11FY6JKtI8JANB4mE/6/OTtJX7btO/q u8J+ZN+ntXqNNskpnlV2s91rVwR4hj001LobCkK6TQRqSwm0Em1erd7/dfXJJ5NnD/RMfTGP afS+Kme4ArXSmJlXoTMu9V1tOPBNeP+RquuKe4d2vifm1NTaU5djAgA4m/mE0UDTTcxTTcwn kpoZs8YX3zHQ77Fgq9M1nYwaDXWpG3VHSLeB/DWzA64o3/VUD78Aaw7Ca7cs8cxG37a3SAdL dymtW6ZfUB96f4LfSvLB0l2eVhDzY8aYQm/mfm3zKrT3lTwl/w8Hk2cP9LkSqvdxmmtYu8V3 pcJ8W/I/mXbb3iLPPvLXzPYZsVjXYwIANG7mVe9AIdzcg23uue7UL9On5aUkb37Idg8j+B8o KaqxLcRYyTd/WDhsmhBjFmpUYl3VpW7UXazVBThZONNEjFCb2jFdT49d5QnCxlVCt+0t8oRh 7+klad0ytXxamfLXzPZsG2hF3dhvbWqceueygG01Rg2TZw/0fOgwP3/uA1sDBnVJOlC6S1P/ Gvg98Q7Y3sf59NhVPq/nfYyD00cpq/9Yv4Bf22MCADReRX/1/5Z18R0DfS5a1HVgls8c9E9X 5evTVfkqyZuvgROnq3fOWN20YJUW3zHQE44X3NhD2bOW+Vyd1LjgUc/sUerQM10HSor8ttv4 Sq5n+57Zo3zCec/sUZ46Vs2YpC4ZQ9QmOUVH9u0KeFJrbp8Ev1YU7/AeKMhffN0Iz/0HSoq0 Z12BOvXL9PTi16Vu1I3L7Xa7rS7CDtYV7tWAjOc9t7v3TNaTC2h9QGQ8eu+rKi78ftUj/63b 9fPru1tYEQBE3/79x9Qx6ftQ3PaHLbVgxURLavG+UFEoRhDdtGi2Vs2Y5POYEdC9BQvM5v3V 9Pp3LN0aMOgGqkOqDs/tu/bw+TBhuHFWvpaOC32hIe/X8756qreBE6cHfO1w6o6G/33q71rx 5gbP7Vmzs3TPmCstqSUCEllJBwAAjhPs6qHB9M4ZG9ZFeoyTKSP9+uHWMWhK4LbN2ryeMSIy 2OsjOgjpgM2UlpaqoKBArVq10tChQ60uBwAAWIATRwGLVVVVaf369frDH/6g7t276/zzz9fS pUs1ZAgn3QCwh7KyMj355JNaunSpTpw4YXU5gCOwkg5Y4OjRw1q4cKFeffVVrVmzRlVVVSor K1NMTIxuuOEGLVq0SLGx/HgCsIeEhATddNNNysjI0JdffqnevXtr5MiRGjp0qC6++GKrywMa JVIAEAVud4Xc2iO3dsitT/Tr//dnNWni0unTpz3btGjRQjfccIMWLlyoJk2aWFgtAPjr1KmT 1qxZo/T0dBUXF2vz5s166KGH1KpVK91www0aOXKkrr76aiUkhHdCJoDQCOlAPTl6+JA2Fb2t VSsXa/P778qtKknVw5TOnvXdNjY2Vs2aNdOhQ4c0ePDgsPbfrFmziP8yjI2NVcuWLSO6T0lq 06aNXC5XRPfZokULxcXFRXSf8fHxat68eUT3GRMTo9atW0d0n5LUqlWriH+Ya968ueLj4yO6 z7i4OLVo0SKi+5Sk8847L+L7rI9/U41N586dtXHjRl1xxRU6dOiQzpw5o0OHDumFF17QkiVL VFZWposvvlg333yzMjMzlZaWZnXJQINFSAfqQelXX2j5689p3b/+pi+/2C3JJSOgB1JRUaFD hw7p3XffjVqNAOpffXzwa9KkiVq1ahXRfUpS69atFRMT3qlq7dq106FDh+RyuWRMcj5+/Lgk aevWrXr44Yf18MMPq02bNsrJydEvfvEL9evXL+I1A40ZIR2oB+0vSNL/G/e4/t+4x3X021L9 /s5x2r/3A7n1paQYNWlSqcrKSp/nxMfH6/HHH1fPnj3Deo3Tp0+rrKxuI7yCqaio8PyijaRv v/024vs8ceKEysvLI7rPM2fO6NSpUxHdZ1VVlY4ePRrRfUrSsWPH/P4NnatTp07pzJkzEd1n eXl5vZxo2JD+TUX6PZWqp0DZWVVVlaTqf6dz587VJ598opycHF17rf9F9QAERkgH6lnr89qr Q9L1Orj3YkluufWVRoyI16ZN/9IXX3yhuLg4HTt2TGfOnNHDDz+sFStWaMCAAVaXDSACysrK fM49iYTKykodO3YsovuUpKNHj3rCdU2vf//99+uDDz7wWyho1aqVzpw5owsuuECDBg3SzTff rIEDB3pas/bvj3zdQGNFSAeiyiWXfqTbbr1dixc/r+3bt+vvf/+78vLytHHjRp09e1ZDhgzR 6tWr6eUEGoGEhIR6OZGyffv2Ed9nOCoqKpSdna0NGzaorKxM8fHxio+PV0VFhTIzM5WTk6Or r75a559/viX1AY0JIR2wUPfu3dW9e3dNnDhRx48f19tvv638/HzdfvvtevXVV3XppZdaXSIA SKpuYcnJydHy5csVGxurCy+8UMOGDdP111/PVBegHhDSAZto2bKlsrOzlZ2dLbfbrf3791td EgBIqm5xGTdunE6ePKnZs2dr8ODBSklJsbosoFEjpAM25HK5lJSUZHUZACCpus1l1qxZXMMB iCJCOgAACCnS8/MB1Cy8gagAAAAAooaQDgAAANgM7S4AAKBB2rOuQHnjaneBpJ7ZozRoypx6 qgiIHFbSAQBAg9SpX6YmbCzTHUu3+j3WoWe6Jmws8/wZOHG6JKkkb75y+yQotw8jI2FvrKRb YPLsgdq2tyisbUdnTVdW/7Ge2/lrZmte/qRaPQcAgMasTXKKBk6crlUzgv9+7J0zVr1zxmrT otme7XL7JCh71jJ16pcZrVKBsBHSLfD02FWSggfu1I7pnm3MsvqP9QTwoff7rgJMvXOZ0rp9 /x8a78dD7RMAgIaubceLwtqud07171AjqOeNGxbRoP7O42NUkjdfHXqm66YFqyKyz4ZcB+qO dhcLZfUfq6l3LvO7v2Nij7Cen9ox3fP/zQE9f81sn2237S3SwdJddawUAAB7a5PcNexte+eM VYee3/8OzRs3TEf2ReZ3ZEne/Ijs51zZpQ7UHSHdYmndMn3CtiStLArvB8tomUntmO4T0CX5 tbukdkxXYnuuDgcAgCRdfN0In9sbX8k9532+8/iYc95HJNilDpwb2l1sYOR1D2rqX33PTi/e UeAXvL15r4qPvO7BgNssn1YWmQIBAGhkumQM8elhL8mbrz63TlCb5OoFrSP7dmnBjYG/2Ta3 xxitJd4OlBT5nJzq/Zza7Nvb4jsG6kBJ4HPaemaP8hxHuHUYalNPsIk62bOWBbx/wsbvs0iw 16ElJzBW0m0gUBgv+ig/5HM2bFsR8vkAACA4I4x7O7LvU0nVodsIk9mzlvlNkMkbN8xntXrQ lDmasLHMp4XGPF3GCLq13Xd1XbuU2ydBB0qKfPZrTKyRpLadU2tVh2HxHQM99Xhva4T+vHHD fEJ+m+SuumPpVp/XNraT5DdpZ8+6Ar/jHjhxuiZsLFP2rOqWX+ODRKRajhoLQrpNDE4f5XO7 ppaXtVuWBHweAACom8N7d2rPugLPanSHnumeUNsmOcUTKqXqFevahsq67nvl/3z/u37wI9/n g945Yz1hui68V+bNq9mDpszxCftGUG+TnKI2ySnqkjHEZ19GwG+TnOJ5nnGM3t809Mwe5Tl5 t1O/TJ+wH2w136lod7GJ7Ksn+AXzYC0vB0t3efrRs6+eEHSf5ukxcx/YGrQvvXhHgV/LjcG7 bcY8UcZscPoojRk+x1PnXU/18JssE2of5hadcOuqadu5D2zVM4tH+Y2+9K4XAOBshz/b5nP7 QEmRjuzb5Vl1N5+cunvtCk/gDGv/e3fWet9H9u0K2uIiSV0HZtXpJNE96wp89mvu0Zek9Dsf 9Glh2bRotud4zd9EtO/6fcD2DvveH0yMer2Z2472rCtgJOZ3WEm3icT2KX4nkL7+9hMBt817 r/rklkAngxbvKNDQ+xM09P6EGuepS9VBeuj9CZ5wO/XOZVo+rUxzH/j+66qh9ydozv9Vf/W2 fFpZwIk0qR3TtXxamU/gNVpytu0tUvGOAs/95v17v25d65Kq234C7VuS7nqqh7btLfJ7LNyT dAEAzuA9yrFDz3SfMBqoRSba+15wYw+fdhjjgk61+bAgSZ+u8m2rNa+MV9fk+8Hhk7eX1Oo1 Ar1OTVN4vD/IOB0h3UYyLvX9FBtsbKIRLAOdMGoE1UBB2sxY6TZ4j3FMbJ/is4+VRfM9Yx3T umVqdJZvL1qgsZHeHxLMHzi8P1yMzpru841BXevy3re5Dcj4EGF+jHYhAIChbedUT+idsLHM 72TGc+2Zrsu+2ySn+LW0eF81ddOi2QGfV5PST/0XtOqD+XUW3NjDU3tunwS/FhfztxlORruL jWT1H+u3+r1h2wqfcYreK9KhThg1RjuGurLpM4t9f+jN+zPvY17+JE8tl6cO8al1ZdF8n1V0 7zql71fTjdfw/vBxearvp/dzqcuQfH6qz23vDxFjhs+hxQUAHC5QKDZfEMn76qSRVpt9D5pS /TsrUFvLqhmTtGrGpFpfkMncQhNoJd98X6i2m3Bfx3vaC0JjJd1mzCu75tBurEibV7Jrq3hH gU+AD3dF2QjfgdpzvIN3oFYd74k1RiuMuWXnXOsKxhzaAQDOtnvtCr/7vCew5PZJ8AnRxgr4 uarrvo3JLebpKYbaXpDJ+6RQKfCHFvN95udE6nUQGCHdZgKdCGoEUO8TRs2rz7VlHvG4smi+ p5fd+0+olXhze44RvL3r9A7yK4vme4L8vq+3BdxHJOoCAKAm5v5qY8rIpkWzfVasjXGBkRCJ fbdJTgka6gN98AjG+0TPaD7HGHOJmtHuYjNGz7T3CY2vv/2E0rplekLw4PRREb96aF2mnJhb XtZuWaKs/mM9J7aOzpquH59/kc/Elbz3cjVm+BzP8dX0YYPpKwCASDNPNpHkOfHSO7x36Jle 6xMyQ6nLvo0LAAW64M8dS7fWeWyheSpMoEk15kBtnsxSl9f5dFU+01vCxEq6DaVf4vtDYPRz G4HY/Hhd7D147ieMmFtejBNdvQO40T9uWFk03/PNQKDpNJGoCwDgPOZAGax/+si+XX5XxrRz n7TRF26MbAwl0ISWYDr1y/RpRQk0uaXor9+3rvbMHlWncG1+nbrMl3cqQroNmYOtJM9qdGrH 9IhcYdQ8jaWu4dg8YcaYyuK92m9uaTGOxXx/JOsCADhLoEvSm6/cuWnRbJ+VZ+MCPN6854Uf KCnyXDHTuOqnN/MkkmDP3bRotjYtml3nfRshd8GNPTzPkaSNr+R6/n/P7FGeQF9THQbvlfkD JUVafMdAz+13Hh/jc6Ej4+RVg3cdUnX4Nt/n/TreQd18HMbr5fZJ8Ps7czLaXWxq5HUPBrww T6BgWxfpl2T5tNTUtcc72AcG79X+QFNrpMCtLpGqCwDQ+BmtIMGU5M0POBFl4MTpQVtNjPuN Ezu9w3+Hnuk+F/jx3r8xq/zwZ9s893k/1/s1a7tvb4E+jNyxdKvPJJaa6vA2YWOZZ9LMgZIi vw8L5n3vWVcQsAbv1wn0/t60YJXP31egfdR2Qk1jR0i3qWDh91xPGA21/2BXOK2JuYc+0Gp/ oG0C9dVHsi4AQONmnEQZab1zxobsFw/1moOmzPFbdY7UvmujpjpqU5M3Y9Z7XdTX31djRbuL jZnHLJ7rCaMHvvHt1zNf8CjQyn04zD3ygVb7zVNrQn0jEKm6AAAAGipCuo2ZL9BTmxNGzfPG Jf/xhmndMv0C8dD7E/xmjh8s3eUZfRhoHrm5h95ct+R/kmmgbSJV18HSXX7tNfPyJ9U4Sx0A AMAuaHexOaNNJNwTRot3FARdeV5ZNF8ri+ZrdNZ0T0hO65ap5dPKlL9mtifYBnp+asd0PT12 VdDXzbh0hLbtLQp58SGjzz6cCxTVpa5Qx+79/JqOBQAAwGqEdJur7SXsjXBbW1n9x4Zc3Y7E 8+tSW23qquuxAwAA2A3tLgAAAIDNENIBAAAAmyGkAwAAADZDSAcAAABshpAOAAAA2AwhHQAA ALAZQjoAAABgM4R0AAAAwGYI6QAAAIDNENIBAAAAmyGkAwAAADZDSAcAAABshpAOAAAA2Awh HQAAALAZQjoAAABgM4R0AAAAG1v3r6VWlwALxFpdgF2dOnlGWzfttboMNBLHj522ugQAsJ2K 8sqQv2sPfblbcU0T1KZthyhWZT8L//KEXEpSqzbnW12KrR0+dNzqEiKKkB7E57u+1kN3vWB1 GQAANFrHjpwK8Lu2XG5tV5WK5VILxWiEJbXZx0lVqkRPTn5cLl1qdTGIIkI6AACwnFv75dZ6 ubVbUqWkZorRSKvLspxbOyS55NZ/COkOQ0gHAAAWOaIqbZJbJaoO5uXf3R+rGN0kqZl1pdmE W1skueXWfklV4nRC5yCkf6d16wT1H9DZ6jLgEO3aNbe6BACIuvj4Jup3VQd99fUH2n/g3zp9 +mu55Ja7qsKzjcsVo64pv9CPO1xhYaX24HZXaU3ht3JXSU2aNNV/XVKpNq1TrC6rwfjxj1tb XcI5IaR/p8clF+jf791ldRkAADRKa9eu1bx581S8eYliY2N18uQxv23i4uKUlZWlJUtes6BC +3n//fc1eHCCjh07K6lC11xbpdxcsopT8J0JAACoF4cPH9Zzzz2ntLQ09e/fX6+88opOnTql Y8f8A7rL5VL79u21YMECCyq1p+XLl+vkyZOSpMrKSi1dyihGJ3G53W631UUAAIDGx+12a//+ /fr000/16aef6qOPPlJJSYm2b9+u0tJSVVRUyIghzZs317p163TppZwcabj44ou1c+dOz+1m zZpp+/btuvDCCy2sClGSyEo6AACoFy6XS0lJSRo4cKDuvPNOPfLIIzp79qzKysqUlZXlE9Dn zZtHQPfy1Vdf6fPPP/e5LyYmRv/85z8tqgjRRkgHAABR0apVK7Vv314tWrTQxx9/LKl6dfjG G2/UzTffbHF19lJQUKCmTZv63Hfy5Em98cYbFlWEaKPdBQAA1JuKigpNmTJFlZWVmjFjho4c OaLKykp169ZNhw8fVteuXVVSUqKEhASrS7WV//7v/9ayZcskVX8j4f2tw9GjRxUby+yPRi6R kA4AAOrNhx9+qL59+0qSduzYoc6dO6usrEzNmzdXQkKCiouLlZqaanGV9lJVVaXWrVvrxIkT SkhIUFlZmZo0aaLKykq1atVKb731lvr37291mahf9KQDAIDI+/vf/669e/eqV69eev755/Xe e++pc+fq65Hs3r1bbrdb8+bNI6AHsGHDBlVWVqpFixa64YYb9Oabb+qxxx5Ts2bNdOLECc8K Oxo3VtIBAEBEvfzyy/r1r3+tK664QqtXr1ZcXJzP48uWLdPKlSv1l7/8xaIK7W3KlCl64okn 9Jvf/EZ/+ctf5HK5JEkrVqzQ0KFDlZycrM8++8ziKlHPWEkHAACRYcw/v+GGG5SSkqLhw4cH 7J1u2bKl/vznP0e7vAbjH//4h371q1/pueee07p16zR8+HA988wzGjJkiCWDCh0AACAASURB VF5//XXt379fBw4csLpM1DNCOgAAOGdvvfWWunTpouXLl6tt27b66KOPNGnSJM8qsLdrr71W 8fHxFlRpf4cOHVLfvn310ksvKSYmRvv27VNeXp7Wr18vSRo+fLgWLVqkd9991+JKUd84NRgA AJyzHTt26JtvvtGSJUs0dOhQQngduVwuPf/884qJqV5HzcjI0JIlS5ScnOzZZvjw4fr666+t KhFRQk86AACok88//1xPPfWU/vznPys2NlZ5eXnKzs4OuHoOoFboSQcAALXndrs1bNgwPffc c3ryySflcrk0fPhwAnqEFRYWenrS4SyEdAAAELby8nJ99NFHcrlceu6555Sdna0xY8ZYXVaj Ze5Jh3PQ7gIAAMJy5MgRDRkyRDt37tSmTZt04YUXWl1So/fFF19o/fr1Sk5O9lwUCo6QyImj AAAgLK1bt1b79u118OBBffPNN4T0KEhKSlJSUpLVZcACrKQDAICgysvL9fvf/16xsbF66qmn dPjwYUlS27ZtLa7MGQoLC5Wbm6uMjAyNHz/e6nIQPaykAwCA4EpKSvTss88qJiZG99xzjzp2 7Gh1SY5i9KSbr9qKxo+VdAAA4Gf58uXq1auXkpOTNW/ePPXs2VNXXHGF1WU5Dj3pjpVISAcA AD5eeOEFjRo1Sv369dOqVasUG8sX70CUMScdAABU+/LLLyVJWVlZ6ty5s4YPH64mTZpYXJWz MSfdufhoDAAA9Morr+i3v/2tFixYoF/+8pf6+OOPFR8fb3VZjkdPunOxkg4AAHT8+HGdPHlS a9eulSQCuk1kZGRoyZIlmjBhgtWlIMroSQcAwKE+/vhjPfbYY1qwYIHi4+P1r3/9S9dee63V ZQGgJx0AAGdyu93KycnRa6+9pmnTpkkSAd2G6El3LnrSAQBwkJMnT+qjjz7SFVdcoQULFuh/ //d/aaWwMXrSnYt2FwAAHOKbb77RgAEDtH//fhUXFyslJcXqklAD5qQ7FlccBQDACaqqqtSu XTv95Cc/kcvlUkVFhdUlIQxJSUlKSkqyugxYgJV0AAAasZMnT+qee+5Rq1at9Oyzz+rYsWOK jY1V8+bNrS4NYSgsLFRubq4yMjI0fvx4q8tB9LCSDgBAY/bJJ5/o9ddfV1xcnB544AFWZRsY etKdi5V0AAAaoRdffFEDBgxQly5dtGjRIvXq1UupqalWl4VaoifdsRIJ6QAANDJz5szR2LFj 1adPH73//vuKjeWLc6CBYU46AACNxZdffilJuuWWW/Rf//VfGjduHAG9gWNOunMR0gEAaARe fPFFpaSkKC8vT23atNGHH36oW2+91eqycI6MnvT169dbXQqijI/XAAA0AseOHdOpU6e0du1a ZWdnKyaGdbjGICMjQ0uWLFFycrLVpSDK6EkHAKCB+s9//qOnnnpKCxYsUFxcnFatWqVrrrnG 6rIAnDt60gEAaIiqqqp000036dVXX1Vubq5cLhcBvRGiJ925aHcBAKABOXHihD7++GP17dtX L7zwghYsWKB7773X6rJQT5iT7ly0uwAA0EAcOnRIAwYM0FdffaVNmzapU6dOVpeEesacdMfi iqMAADQEVVVVat++vbp3766mTZuqvLzc6pIQBUlJSVwl1qFYSQcAwMZOnDihu+++Wz/84Q/1 zDPP6OjRo2ratKmaNWtmdWmIgsLCQuXm5iojI0Pjx4+3uhxEDyvpAADY2fbt2/Xmm28qPj5e kydPVmJiotUlIYroSXcuVtIBALChBQsW6Nprr1WnTp306quvqk+fPurWrZvVZSHK6El3rERC OgAANjNz5kzdd999uuKKK1RYWKgmTZpYXRKA6GJOOgAAdvHll19Kkm677TZdcsklGjduHAHd 4ZiT7lyEdAAAbGD+/PlKSUlRfn6+zjvvPG3ZskU333yz1WXBYkZP+vr1660uBVHGiaMAANjA 0aNHderUKa1du1ZZWVmKiWEdDVJGRoaWLFmi5ORkq0tBlNGTDgCARbZs2aLp06drwYIFio2N 1apVq3TNNddYXRYA69GTDgCAFSorKzVy5EgtXLhQM2fOlMvlIqDDDz3pzkW7CwAAUXT8+HFt 375dl19+uV544QW98sorGjt2rNVlwaaYk+5ctLsAABAlX375pa6++mqVlpZq8+bNuvDCC60u CTbHnHTH4oqjAABEQ1VVlS644AJdfPHFat68ucrLy60uCQ1AUlKSkpKSrC4DFmAlHQCAenT8 +HHdddddSkpK0rRp03T06FHFx8crISHB6tLQABQWFio3N1cZGRkaP3681eUgelhJBwCgPn38 8cf6v//7PzVv3lyTJk3SBRdcYHVJaEDoSXcuVtIBAKgHf/3rX5WZmank5GS98sorSk9P10UX XWR1WWhg6El3rERCOgAAETZjxgxNmjRJ/fr105o1a7gwEYDaYk46AACR8uWXX0qSfv3rX6tH jx4aN24cAR3nhDnpzsV/OQAAiIC5c+eqS5cu+vvf/6527dqppKREI0eOtLosNHBGT/r69eut LgVRRkgHACAMBw8eDPn4kSNHdPr0aRUWFkoSK+iIiIyMDC1ZskQTJkywuhREGT3pAADUYPPm zXr77bc1efJkn/tXr16tGTNm6M0331RcXJxWrVqla665xqIqATQi9KQDABDK0aNHNWzYMCUn J/vcX1FRoTvvvFP5+fmaPXu2XC4XAR0RR0+6czEnHQCAINxut7KysrRv3z5dfPHFkqRDhw5p 69atGjhwoF566SW99tpruueeeyyuFI0Vc9Kdi3YXAACCeOqpp/TII4+ovLxchw4d0smTJ3XF FVfoxIkTKi4uVkpKitUlopFjTrpjccVRAAACWb16tR555BGdPn1aLVu21A9+8AO1adNGV155 pQ4dOqRmzZpZXSIcICkpSUlJSVaXAQvQkw4AgMnBgwc1bNgwnT59WlJ128v48eMlSS+++KLe ffdddejQwcoS4RD0pDsXK+kAAHipqqrSyJEjdfLkSc99J0+e1EsvvaSrrrpKvXv3VufOndWk SRMLq4RT0JPuXPSkAwDg5X/+5380ffp0nTp1yuf+2NhYNWvWTGfPntXZs2eVnJys66+/Xr// /e914YUXWlQtGjt60h0rkZAOAMB3/v3vf+v666/3tLmYtW7dWuXl5brxxht1991366qrrpLL 5YpylQAcgBNHDaWlJ/X2P3daXQYc4uqBXdShQyury2g0Dhw4pvdW7ba6DDRwhw9/pUn3D1dZ mW9Ab9o0XpKUknKJfnbdSN0/eZR+/OO2VpQIByosLFRubq4yMjI850XAGQjp3/lkR6luveV1 q8uAQ+S/dTshPYK2fHiQn1+co0pV6jlJRh+6S1JTSXGqONtbLv2XPtnWUp9sO6xf/OIYIR1R Q0+6cxHSAQCOV6X3JBk96DFyqbNc6i2Xuqg6sAPWyMjI0JIlS/yueIvGj5AOAHA0t3bLrQ2S WsmlborRlZKYgQ57YE66cxHSg2jVprkuvYIrySEytm7ao8OHjltdhmO0/WFL9ejdyeoy0ABU lJ/U53s+1g8v+P/UslWXgNuUfLBLR789FfAxoL7Rk+5chPQgOlzYThMfG251GWgkHr33VUJ6 FHW66Ef8/KIWbgv56O9HzSekwzL0pDsXIR0AAMCm6El3LkI6AACATdGT7lwxVhcAAACAwAoL CzV8+HA988wzVpeCKGMlHQAAwKboSXcuQjoAAIBN0ZPuXIR0AAAAm6In3bnoSQcAALApetKd i5V0AAAAm6In3bkI6QAAADZFT7pzEdIBAABsip5056InHQAAwKboSXcuVtIBAABsip505yKk AwAA2BQ96c5FSAcAALApetKdi550AAAAm6In3blYSQcAALApetKdi5AOAABgU/SkOxchHbZX vL1AU+cNC/jY6GHTlTVgbK22AwCgoaAn3bkI6XV0sHSX7nqiR8htCIaR0aF914huBwBAQ1FY WKjc3FxlZGRo/PjxVpeDKCKk19KcJWO08v35ntupndL19O9W+WyTv3q25i2b5PljGHzlKI0Z MSdapTYaie1TtHxGmSRp8rMDtW1P0TltBwBAQ0FPunMR0sMUaOV87oNbldg+xW/brAFjlTVg rF9QTL8kq97rbOwyLh0RVvgOdzsAAOyMnnTnYgRjGAIF9KmjlwUM6N6e/t0qpXZK99ze//XO eqkvkoZOTNDQiQmas2SM1aUAAOB4SUlJGj58uPr27Wt1KYgyQnoYzAF98JWjlNY9M6znjs+Z X/NGNnGwdJfVJQAAAC/MSXcuQnoN8lfP9rsve+CEsJ+f2D5Fg68cJUna9/W2iNVVHzZ8vMLq EgAAgBejJ339+vVWl4Iooye9Bt4nfkrVJ4rW1OZiln5Jlla+P197D26NZGkRVby9wO9YAQCA tehJdy5CegjF2wv87uuYGHrsYiBp3TM9U0eCvU6w+d41TYQxJskYls8o87vPEGgkZLDXXvn+ fL8pNiOvezBonXMf3KpnFo3yO1kzUP3ncrz1JVRN5r+7UNsGex/Ob3K1pCsjUisAwDmYk+5c tLuEEOhEz+TzUyO2/+LtBRo6McET+AZfOUrLZ5Rp+YwyTR29TFJ1WB46McGn7SZ/9WzPCZ7m MG7cN3rYdJ/9SNXfCphPCDU+QHhvZ65l+YwyPf27VZ5t5z7o/43AXU/00LY9RX6PeQf9uh5v fTpYusunpqmjl/kdo/lE2rq8D1+73qunIwAANGb0pDsXIT2E+uwhN6/GmleQ07pnavSw6Z7b 85ZN8gTXrAFjtXxGmc/j3pbPKPOsmKd1z/T0xEvVITjQNwS14d1nb0jtlK7lM8r8HjP+/7kc b30xT+2ZOnqZ54TgxPYpPh9cVr4/36+e2rwP57uvro9DAAA0cvSkOxch3SLmdolAJ6OaW1Pm LZvkM4El0NVMzSvikv989qKP8mtVayDmbxS824DGjJjjWSE3gngkjjfSnlnkG7DNE3vSumf6 jNAM1EIU7vvQqfK2SJQMAHAYoyd9woTwh1agcSCkW8C8kh3qZFTzSm3eqtyQ++7Qvuu5FVdH odqA6vN466p4e4FP37j5dUM9L5RItkMBAMCcdOfixFELmFeyQ52Mag59NU2ICWfyTLSnzNTn 8UaqJvOJsgAA2EFhYaFyc3OVkZGh8ePHW10OooiQHkKgVdG1W5YEbDOpydCJCZL8J4XAHqya KgMAQChGT3pcXJzVpSDKaHcJ4fKfDPG7zzxaLxzmvmo7z0uvD3Y8XjvWBACAGT3pzkVIDyGx fYrPiYOG2k5HMa7kaeyrLrPWDefyXKvY8XjN+yW0AwDsiJ505yKk12DkdQ/63ff620/Uah9r tyzxuW2ethIqIJrHQDbEExPteLzmmuryDQkAAPWNOenORUivgXnOuFQd6MKd4Z2/erZfADSP +tu2pyjoqEHzyYx16Ye3mh2P11yTVPtvSAAAqG/MSXcuQnoYxoyY49f2Es7Fdoq3F/jM1vYO 6+Z55oFGDZr3H2gGulld54qbRzdGuv2jvo43kjWZZ7kDAGA1etKdi5Aepqd/t8ov1M1bNskz tcVs8rMDQ4a+tO6Zfle09L70fP7q2T4B3/tqmIZAgdx8gR7Jf9xgoJVsc//9tj1FnpXl/NWz NXRigidEHyzd5Xdhn3nLJoVciY7E8Ur+rUPm27XZzlyTVD2Fx3wcB0t3aejEBL/H6vI+AABQ G/SkO5fL7Xa7rS7CDtYV7tWAjOc9t7v3TNaTC4Jf4CZYOPfmPdbP2H7ug1v9ZpnPWTIm6Izu QGG1eHtBjau+g68cpfRLsmrczjwScvKzAwP2Z4e7P6n6BNmnf7cq6OP1cbzGc8PZLtAYTPOH BDPvYwq3Hu/nPHrvqyou3Pn96711u35+ffca94HwrPjHDg29/kXP7d79LtIfZ91iXUFoVH4/ ar62b9nnuf3emt/oqoxO1hUER2FOumMlMie9jmo77zzU9mNGzKnVjO607plhv35t6wwVruuy v0DsdLyGrAFjw+5/r009AKTidbslSWn9upzTNoATMSfduQjpAGCSv6hY82a8G/TxqbNGECaD KF63W1PH+beXpfbs4HnPwtkGQDWjJz05OdnqUhBlhHQA+M6cxwu0Mm+L57Y5jBvh0hwwl2+c HLUa7S6tXxct3zg5aBAPdxsA1ZKSkpSUlGR1GbAAJ44CNlZZWant27dbXYYltm/frsrKyqi9 3tA+T/sE9OUbJ/ut6hrhcnD2pZ77Unt2iFqNDUlavy41vjfhbAM4HXPSnYuQDtjMoUOHtHDh Qg0bNkxdu3bVkSNHrC7JEkeOHFHXrl01bNgwLVy4UIcOHaq31xra52mf23OXjg65/ZgpmbYN l3MeL9DQPk9r8h0LrS4FQAQwJ925aHcBLFZVVaUNGzYoLy9PeXl52rNnj6qqqtS0aVO98847 Sk9Pr3knjVB6eroWLlyoQYMG6a233lJMTIw6deqk7OxsZWdn6/LLL1dMzLmvM8x53Hdk5uDs S5WYfF6Nzxt5Zz9NHbdE20oOnHMNkeT9bQCAho+edOcipAMWOHTooP7855VatGiRNm/erLi4 OJ0+fVput1sul0stW7bUv//9b/Xu3dvqUi111VVXad26dRo4cKCOHz+uTz/9VNOmTdPs2bNV Xl6uyy67TDk5OWp7Xq867f/gvm/9Qm32reHNIvZuhTm479uwgn19M3/gANDw0ZPuXIR0IArc 7gq5tUduFcutzzXqzmmKiYlReXm5JHn+1+VyKSEhQQ8++KB27typnTt3htqtY0yZMkWPPPKI ysrK5Ha7derUKUnSBx98oM2bN6uqqkqVipVLF8qlNLndncPa74a1u/3uq03YDnbC6MF93+qu G+cFfCzUZJjJdyz0rMxPnTVC+/d+6zdlJrVnBz294Fc+95lPeJWkbSUHfNp4ho7sreWvbwpY T6CTN72Pra7HE0nBajC/H8FORg3nOAE7Yk66cxHSgXp09PAhvTb3UW3+4FVV6aTn/spKBTwp 0u126/Tp03rwwQejWWaDZnzAkSrl1k65tVMfbliuvzxZrJvvelit2/4w6HP3fVbqczsSfebe Qds7QBpB2giKRjgMNu7R2G70xJ8qKyfNs18jfHuHyzFTMjVmSmbQ15aqQ+7Qm9K0Ye1un9cz Xmfu0tE+Ibh43W6l9etS6+OpD94fQoz3wwjjxvsxd+loJSafpw7J52nu0tG1Pk7ArpiT7lyE dKAetW77Q42eNEO7t7XUjq1r5FaJpDOKi4tTRUW5zBf8NVpdfvrTn/IfZC/l5eV69913dfz4 8YDvWWxs3HdhPV4u9VRKt/4aPWmqYmNDv4d7P/U9GbVj1+CBPhyhQvKYKZna++khz+NG0M7K SfMJ4Qbz88c/cr1PuMxfVKysnLSwazO+Ibg8o4tPePV+ndSeHbSt5IBnXnldjifSvAP64OxL Pcec1q+LRk/8qedY7rpxnpZvnFyn4wTsjJ505yKkA/UsNjZOrdr8RDGKk3StpFOaNLGzPt21 TitWrJBUHULPnDnjWUn/z3/+o6KiIrVr187S2u3gm2++UXp6uqdnX5Li4+M9H2KGDBmirl2v 0tNP7JbUXJLUqvVFNQb0SCtet9snZGdcl+q3jXGyqcE7aJsfMz/f3IZj/hYgXOb9eH8wMbeN nMvxRELxut0+bTzpAy/yedwcxL1XxcM9TsDu6El3LkYwAlHXXBkZg/XGG2+otLRUS5cu1Zgx Y9S5c2c1a9ZMrVq10q5du5SRkaGjR49aXayljh49qoyMDO3atUutWrVSs2bN1LlzZ40ZM0ZL ly5VaWmp3njjDfXPGCwjoJ8L88p6bRSt8j1/4PIM/xXaDqbguPbtbUH39+OO/r3x0Rz7GOnj iUQN5tcz27/324i+PmAHzEl3LlbSAQvFx8dr0KBBGjRokGbMmKG9e/dqxYoVysvL0+rVq3Xd ddfpnXfeUatWrawuNeqOHTum6667Tp999pkGDRqk7OxsDRkyRB07drS6tIDOJeDb8fWifTzh 1BDs5FVDXb9dAOyMnnTnIqQDNtKxY0fdfffduvvuu3XmzBmtWbNG77zzjrKzs60uLereeecd Pf744+rfv7/i4+Pr5TU6dv2hT0tHbWeeGyd9Tp01wu+5gabEmO+z24x1b3Y4HvP+mMQCJ6In 3blodwFsylhld2JAl6Ts7GwNGjSo3gK65N/jLFX3NYfLu73D3IpycJ9/64X5PrtetVSyx/GE UwPQ2CUlJWn48OHq2ze8azig8SCkA3CsQJM9Xv/rurCee3Dft56V3g7J59VpMsy5TpOpT3Y4 HvP+DhDS4UD0pDsXIR2Ao02dNcLn9raSA2Gtpue98oHPbfOqfKALJZlDZqCVfLuww/GY92c+ kRRwAqMnff369VaXgigjpANwNGPetrep45aEbK0wjwY8sO9bpfXr4tOeEWjSifcq/eDsS209 o9sOx2OuYWXeFlpe4DhGT/qECROsLgVRRkgHzlH+6tkaOjFBQycmqHh7gdXloA6yctL8VtTv unGe5jzu//c55/GCgJeXl3znb28rOaDJdyz0eZ73hYHGTMn0ea55fKC57ca7vcbYv5n3LHPv bwTyFxUrf1GxJP+e+5V5W4J+c3Aux2OuMdhJpTVt8/SCX/kE9btunOdX75zHCzS0z9M+f1+1 OU7AzuhJdy6X23z5PodaV7hXAzKe99zu3jNZTy4Y5bk9dGLCOb/G6GHTlTVg7DnvpzFpiO9r /urZmrdsUq1qefTeV1Vc+P1X9flv3a6fX9+93mp0mhX/2KGh17/oud2730X646xb6rSvg/u+ rXHUn3FpemO6i3HbYNwfiHH5+nC2lapXqCX5rNx7M18J1PsKnd56X9lZm97/LKzjMqvN8YTz /k2d9QtNHfdmyG1qu9+ps0YorV8XFa/bHfRDlCHYcQbz+1HztX3LPs/t99b8RldldAr7+cC5 KCwsVG5urjIyMjR+/Hiry0H0JDKCMUzLZ5RJCh7Qpo5eprTu/itJc5aM0cr359d7fQ2V8b4G e5/mPrhVie1T/O638n3NGjBWWQPGqnh7gabOG2ZJDag/icnnhT3qLysnLWDYC3Z/bfZhFmil Oth24W4brtocT7jvX23HKYa737R+XRjViEaFOenORbtLLWUNGKvUTul+9wcK6JI0ZsSc+i6p UQj2PgUK6KG2j6a07pkafOWomjcEAKCO6El3LkJ6HWRcOqLmjbw05iBn9GLPWTLmnPdV2/fJ Du9r8vmpNW8EAEAd0ZPuXIT0KGisQe5g6S5LX7+xvq8AABiYk+5c9KRHgdHD3Nhs+HhFRPdX 29DdWN9XAAAM9KQ7FyEddVK8vSDohJP6crB0l+56ooek7084BQCgMTN60pOTk60uBVFGSK8n xmhB7+kkoaaBzH1wq55ZNErb9hT53D/4ylF+J0mG2k+g7b2Zp9Msn1EWdGJNoHGCwV575fvz faatpHZK19O/WxW0jro4UPqpZ9+hnOsxBsIkFwCAFZKSkpSUlGR1GbAAIb0eBOvVTuueqeUz ynxWhA3G7bkPbvV5bOX78z2h2xwUvQO58ZgRlr3DZ6i53saHCWN779eYt2yS9n29zSf0G8cQ qpb6cLB0V8iQHMljNL+u99+H96jNUK8JAEAkMCfduThxtB48s+j7qSOBRggmtk/xm0yS2ild y2eU+T1m/P+aQnFa90yNHjbdc3vesknKXz1bUnXv9vIZZT6Pe1s+o8wT6M1jBVe+P9/Sq2ga 02O8g3LHxB5+29XHMYYK6MZrBns9AAAiwehJX79+vdWlIMoI6RFihMmhExP8WlYCMZ8k6R08 x4yYo+UzyrR8RpkniJtXkbMH+s9LNbdtzFs2yWdVP1Bbx9TRy/zuS78ky+d20Uf5wQ6j3hnv g3cP+t6DW4NuH8lj9A7oqZ3Sg87CBwCgvjAn3bkI6RHiHSZr6pkOJNRkE/Mqb2qn9KAX+TGv 0Oetyg35uh3adw2zQusFCtvhqMsxGt9CGAKt3gMAUN+Yk+5chPR6MD7n+xMoIzFL3LzKGyow msN+qFVnKfgVPWuzj2gxwnY431R4q8sx7vt6m89tZrIDAKzAnHTn4sTRehBOKHSCmiai1HYC TGL7lKiNXrTLBxMAgLMxJ925COn1JJJhsqEGxv1f7wz5uJ1bSGq7Wg8AQH1gTrpzEdIbgI6J PeocGq0Mwg35iqCpndIJ6gAAyzEn3bnoSW8AzJNIQq2sO62Xunh7gYZOTNDkZwdGdL/mDzfm 9xUAgGigJ925COkNgHn037Y9RUFPSPW+6qcUeCShXdUlCBsn1Ub6GwPzByPz+woAQDQwJ925 COl1EChM1vcFf8zjBwONVjSPDQxnZGFdp8+YxxpGom8+0D5C1XewdFdY4bkux5jWPdNvlKb5 /ZX8/y2w4g4AiCTmpDsXIb2WircXBAyGU+cNCzsMHizd5Xc5+XnLJoUM+mndM31C98r352vO kjGe2+ZL1Juvjmm8rpn31VEN5pGPgVbuE9un+ITYbXuKPPXnr56toRMTAobaYOYsGROwB9z7 gkLe8lfP9nnMaOuJ5DGaJ8+Y/46GTkzw+7fAijsAIJKYk+5cLrfb7ba6CDtYV7hXAzKe99zu 3jNZTy74PtxNfnZgrU4knPvgVr9RjDWNJDTUNJpwzpIxQcNgoHAezusOvnKU0i/JqnE789Sa YO/L4CtHea6WGkpt39dgene7Tpt2vB1ym7oeo/kDULi8/w08eu+rKi78ftpN/lu36+fXd6/1 PhHYin/s0NDrX/Tc7t3vIv1x1i3WFYRG5fej5mv7ln2e2++t+Y2uyuhkXUFwlMLCQuXm5ioj I0Pjx4+3uhxETyLTXcJUm3newaR1z4zIaMYxI+aEFYDr8rq1re9c35dIvK+1VdtjbMhTagAA DRtz0p2LkA4AAGBTzEl3LkI6AACATTEn3bk4cRQAAMCmmJPuXKykWTr9aAAAIABJREFUAwAA 2BQ96c5FSAcAALApetKdi5AOAABgU/SkOxc96QAAADZFT7pzsZIOAABgU/SkOxchHQAAwKbo SXcuQjoAAIBN0ZPuXPSkAwAA2BQ96c7FSjoAAIBN0ZPuXIR0AAAAm6In3bkI6QAAADZFT7pz 0ZMOAABgU/SkOxcr6QAAADZFT7pzEdKDOH70tNa9+7HVZaCR+PabE1aX4CjffnOCn1/UylcH tiuhWWu1Pi/R77ETR09bUBFQjZ505yKkB7F/b6mefuANq8sAUAef7TjIzy9q6Ywq9ZKkOMWo t1zqJinB6qIAetIdjJ50AAAUrxjdKKlUVVqpSs1UlV6TW7skVVldHByMnnTnYiUdAABJLv1Q MbpeVcqXJLn1udw6IMkll1LkUi+51MnSGuE89KQ7FyH9O+3aN1f28EusLgMOkZjYyuoSGpXE xJb8/CJCLlHxpuP6bM97crurJFVU3+3aoZgmexQTE6v5C47qgh9NUNeuXS2tFM5AT7pzudxu t9vqIgAAsIuKigpdddVV2rRpkyoqKvwej4+Pl8vlUnJysu655x796le/Uvv27S2oFEAjlkhP OgAAXmJjY7V06VK1aNEi4ONnzpxRVVWVdu/erfHjxyslJUWPPfaYTp06FeVK4QT0pDsX7S4A AJh06NBBf/vb3/Tzn//cL3wnJibq9ttvV69evdStWzd169ZNzZo1s6hSNHb0pDsX7S4AAAQx c+ZMPfTQQzp58qRcLpfi4uJ09uxZJScna+HChRowYIDVJaKR++KLL7R+/XolJyerb9++VpeD 6EkkpAMAEMLIkSP11ltv6dSpU7r66qt17Ngxbd68WU2aNNEf/vAHPfzww2rSpInVZQJoXOhJ BwAglBdffFFJSUmKiYnR559/rvfff1/jxo1TVVWVHnnkEf30pz/VF198YXWZaKToSXcuQjoA ACE0a9ZMf/vb3xQfH6/9+/eradOmmjlzplauXKkf/ehHeu+999SrVy/l5+dbXSoaIaMnff36 9VaXgiij3QUAgDC88cYbuummm/TZZ5+pY8eOkqSvvvpKt99+uwoKCiRJt956q55//nk1b97c ylLRiNCT7lj0pAMAEK5JkybpZz/7mX72s5957nO73Zo1a5buv/9+lZeXq0ePHlq8eLEuuYQL bAGoM3rSAQAI15NPPul34SKXy6V7771Xa9euVZcuXbR161b17dtXM2fOtKhKNCb0pDsXIR0A gDDFxsaqd+/eAR/r27evNm/erJtuukmnT5/WfffdpxEjRujbb7+NcpVoTOhJdy7aXQAAiLCX X35Z99xzj06ePKmOHTvqtddeU79+/awuCw0QPemORU86AAD1Ydu2bcrJydGWLVsUGxurhx56 SH/84x8VE8OX2ABqRE86AAD1ITU1VUVFRRo3bpwqKir0yCOP6LrrrtOBAwesLg0NCD3pzkVI BwCgniQkJGjmzJlaunSp2rZtq3/961/q1auX/vGPf1hdGhoIetKdi3YXAACiYN++fbrlllu0 Zs0auVwu/e53v9O0adPUtGlTq0uDjdGT7lj0pAMAEC2VlZV69NFH9ac//UmVlZXq06ePFi1a pK5du1pdGgB7oScdAIBoadKkiaZOnap3331XSUlJ2rhxo3r37q2FCxdaXRpsip505yKkAwAQ ZVdffbU+/PBDZWVl6fjx47r11lt122236cSJE1aXBpuhJ925aHcBAMBCL7/8sn7729/q1KlT 6tatmxYtWqTLLrvM6rJgE/SkOxY96QAAWG3r1q3KycnRf/7zH8XHx+upp57SuHHj5HK5rC4N gDXoSQcAwGo9evTQ+vXrNW7cOJ05c0b33XefBg8erK+++srq0mAxetKdi5AOAIANNGvWTDNn ztSSJUt03nnn6Z///KcuvfRS/fOf/7S6NFiInnTnot0FAACb2bt3r2655RYVFhZ6ZqpPnz5d cXFxVpeGKKMn3bHoSQcAwI4qKir0pz/9SY8++qiqqqrUt29fLVq0SF26dLG6NAD1j550AADs KDY2VlOnTtXbb7+tDh066IMPPlDv3r21ePFiq0tDFNGT7lyEdAAAbOzaa6/Vhx9+qOuvv15H jx5VTk6ObrvtNp06dcrq0hAF9KQ7F+0uAAA0AG63W7NmzdLkyZN19uxZpaamavHixerZs6fV paEe0ZPuWPSkAwDQkBQXFysnJ0c7d+5UQkKCnnzySd17771WlwUgsuhJBwCgIUlLS1NxcbFu vfVWlZWV6b777lN2drYOHz5sdWmoB/SkOxchHQCABqZly5Z6+eWX9dJLL6lFixZaunSpLrvs Mq1du9bq0hBh9KQ7F+0uAAA0YHv27FFOTo6KiooUGxurhx56SA8//LCaNGlidWmIAHrSHYue dAAAGrry8nI99thjnpnq11xzjV555RX9+Mc/tro0AHVDTzoAAA1dXFycpk6dqoKCAv3oRz/S v//9b/Xq1UtvvfWW1aXhHNGT7lyEdAAAGolBgwZpy5YtGjx4sEpLS5WVlaV7771XZ86csbo0 1BE96c5FuwsAAI2MeaZ67969tWjRIl188cVWl4ZaoifdsehJBwCgsdqwYYNycnK0a9cutWjR QjNmzNBdd91ldVkAakZPOgAAjdXll1+uTZs26eabb9aJEyf0m9/8Rr/85S915MgRq0tDmOhJ dy5COgAAjVirVq306quv6qWXXtIPfvADvfnmm7rsssv0/vvvW10awkBPunPR7gIAgENs375d OTk5+vDDDz0z1f/4xz8qJoY1O7uiJ92x6EkHAMBJysrK9MADD+jZZ5+V2+3WoEGD9PLLLysx MdHq0gB8j550AACcJCEhQTNnztTSpUvVrl07vfPOO+rVq5dWrlxpdWkIgJ505yKkAwDgQMOG DdOHH36oAQMG6Ouvv9bPf/5z3XvvvTp79qzVpcELPenORbsLAAAOVllZqenTp+vhhx9WeXm5 Lr/8ci1atEgpKSlWlwbRk+5g9KQDAABp/fr1ysnJ0WeffaZWrVrpL3/5i26++WarywKcip50 AAAgXXHFFdq8ebNGjhypY8eO6ZZbbtFtt92mkydPWl2ao9GT7lyEdAAAIElq3bq1Fi9erJde eknNmzfXK6+8oj59+ujDDz+0ujTHoifduWh3AQAAfj7++GPl5OSopKRECQkJevLJJzVu3Di5 XC6rS3MUetIdi550AAAQmDFTfdasWZKqJ8LMnz9f7dq1s7gyoNGjJx0AAARmzFTPy8tT27Zt tWzZMl122WVavXq11aU5Bj3pzkVIBwAAId14443avHmzMjIytG/fPv3/7d1/kJX1fejxz7Ir LEZdYkNvUBeJGKeGXBIT4mwIvSH+CHoVHdFG7WjSgSa5ySa2V5nkSu5UM9fRyUQcS6Ez6S3M 7WCLrXSp+eVF1DINd0PrjlFSEm8i0UoQU00E4+XHCrv3Dzwne86eXRbYPc9nd1+vGUfO2WfP +ezhn/c+fJ/vc9FFF8Wdd94Zhw8fLnq0Mc+a9PHLchcAYEgOHToUd911V9x1111x+PDh+OhH PxoPPPBAnHXWWUWPNmZZkz5uWZMOABybf/zHf4ybb745du3aFS0tLfEXf/EX8YlPfKLosWAs sSYdADg2H/vYx+Lpp5+OK6+8Mvbu3RvXX399fPKTn4x9+/YVPdqo98Ybb1Q8HmhNevVxjD0i HQA4Zu94xzvim9/8Ztx///0xadKkWLt2bVx44YXxwx/+sOjRRrW9e/fG7bffXn5ca036448/ Hh0dHUWMRx1Z7gIAnJDt27fHDTfcEP/6r/8akydPjnvuuSf+6I/+qN9xP/7xj+PMM8+M0047 rYApR4/3vve9cfHFF8ef/umf9luTvmnTpli4cGH85Cc/ienTpxc9KiPHchcA4MTMmjUr/uVf /iVuueWW2L9/f/zxH/9xXHfddfHaa69VHNfY2BiLFy8O5wcHd9VVV8WKFSviU5/6VJx55plx 7bXXxoUXXhgPP/xwXHbZZTFt2jSBPg44kw4ADJv169fHpz/96dizZ0+cffbZ8dd//dfxkY98 JCKO7A4zefLkuOuuu+LLX/5ywZPmtWXLlvj4xz8evb29ccUVV0Rvb29MnTo1/uqv/iq6u7vj i1/8Ytx///1Fj8nIsrsLADC8Xnjhhfj93//9+P73vx9NTU3xla98Jf7kT/4kJkyYEK2trfHS Sy/F448/HvPnzy961JQOHToULS0tsW/fvpg4cWJ0d3dHY2NjHD58OFpaWqKjoyMuuuiiosdk ZFnuAgAMrxkzZsQ//dM/xR133BE9PT3x1a9+NS699NJ46aWX4vzzz4+enp64+uqr4/nnny96 1JSamprKv8B0d3dHU1NT+cZR3d3dMW/evAKno15EOgAw7JqamuLOO++MRx99NKZNmxZPPPFE vP/9748pU6bEhAkTYt++fXHZZZfF/v37ix41peuvvz5OPfXUiDhyZr1k3rx5MXHixKLGoo5E OgAwYi6++OJ4+umn4/LLL49XXnkl1q9fH01NTXHo0KH4+c9/Hp/97GeLHjGlyy+/PLq7uyue O+WUU9w0ahwR6QDAiOju7o4f/ehHsWXLlpg3b15ccMEF5ecjIvbt2xcdHR2xdu3aIsdMaerU qf12cDl06FBcdtllBU1EvblwFAAYVt3d3bF69eq4884749///d9jwoQJcdJJJ8XBgwdrHn/y ySfH97///Zg9e3adJ81t2bJl8fWvf7283GXGjBnW8Y8fLhwFAIbXxIkT43Of+1zs3r07vve9 78WNN94YjY2NA97EaN++fXHxxRfHq6++WudJc1u4cGGcfPLJEXFkj/lFixYVPBH15Ew6ADDi 9u/fHw8++Pfx5S/dHb96bUdERBw+3HfNdUNMaWmNiy/6H9HQ4BxiRERvb0/8wzc/HYcPd0dj 40kx7yNfiqnv+J2ixxo1/vDTF8aCy84reozjZZ90AKA+du16Pc4+656I+HX0xrPRE09FxK8j 4je7lzTEBTEhFhQ1Yjo98b+iN16OiAnRGEvD5YRDt2LlVfH59g8XPcbxmtZU9AQAwHhzajTE h6IxPhS9sTN64+nojR9HRLz15/OiId5V8Iw5NMR7ojd+EQ3xH0Kgjy/+tgGAwjREa0yIhdEY t8aEWBgN0Ro98e2IeL3o0VJoiPe+9f/3FzwJ9eZMOgBQiFNPOzk+/9+v7Pf8/3vjV/HaL3fG WWe/r4Cp8ll9/8b4vT/4Ypw25Z1Fj5Lapn94Kp7qfK7oMYaNSAcACnHSpMb48EXvKXqM9Lq7 b4+PXnZR0WOkt+3JsbU9peUuAACJ/aePu8voeCTSAQASa5gg18Yjf+sAAJCMSAcAgGREOgAA JCPSAQAgGZEOAADJiHQAAEhGpAMAQDIiHQAAkhHpAACQjEgHAIBkRDoAACQj0gEAIBmRDgAA yYh0AABIRqQDAEAyIh0AAJIR6QAAkIxIBwCAZEQ6AAAkI9IBACAZkQ4AAMmIdAAASEakAwBA MiIdAACSEekAAJCMSAcAgGREOgAAJCPSAQAgGZEOAADJiHQAAEhGpAMAQDIiHQAAkhHpAACQ jEgHAIBkmooeAABgrHqhc2N03HJ1za/Nv+3e+MCNX6jzRIwWIh0ASOW+Oc0n/BpZAnhK67lF j8AoJdIBgFRu7ToQERGP3d0e2zpW9/v64g3bY0rrzH7PD3R8kaa0ziz/PA8unh8vbdta7ECM GtakAwApXbJsVc3nawX6YMdncd6l1xU9AqOISAcA0pq9aMmIHs/R3TenOe6b0xyP3d1e9Cjj ikgHAMaM0991ftEjjCl7du4oeoRxy5p0ACCtY43uD9z4hRQXjI4VP9vySNEjjFvOpAMAo9ae nTvKyzEYXi90bozNy5cWPca45Uw6ADBq7dn5XEREnDG7rebXjxbvZ8xuixvWbB50P/PZi5aU L0p9at3KAcP1RLZ9HOx1S7vDDHZc6ec41teuNfNAn8W2jtUVu+cM9J5D/SyHcvziDdvjf9+x pN+uOLVeZ6xxJh0AGJX27NwxYNyV3Np1IBateHjAr5Uic8bcBXFr14F+F57e2nUgLlm2Kl7o 3Bj3zWkux+6tXQfi1q4DsXjD9vKxm5cvPe4z+h+48Qtxa9eBmH/bvUM6bigXyB7vzKXPovpz m71oSfk1+n521e9X+jvpe3zptbZ1rI775jTHU+tW9nu/vnOVrLlmVry0bWu/r2XbanMkiHQA YFQpLW9Zc82s8nPvOHfWgMfPmLugX9QOFLl918D3DcO+vwz0jdcprTP7xeyJ7IIy1DPxc26+ 9ajH1GvmiP5nw6vPdM+Yu6DiF5DNy5dWhHppruq/lzNmt8WtXQf6fW087OIj0gGAUaXv2dyS V5/rfxa2r+qoHehM7E82rY+IIxFY2o/9hc6NFcds/ct7Kh7PmLtgSK9dT/WeufpfNGr9ElH9 C8jm5Uv77R5TfaFw31++Llm2qvz3PtaXukSIdABgFBtoKUu1Wmdpq8/k7tm5o7z2uW9kVgft aLgpUT1nrv6F4IzZbQPecKr676Br7X2DvvZ43lLThaMAwKg1pfXciIh+FxbWMufmWyvOGG9e vrTi7G5pu8Fakdn3rP1oUa+Zn9v8zYrHgy09qo7uo/0LyHgm0gGAUWtK68whx+iU1plxxuy2 iqB/oXNj+axz6QLLtj+8fdDXeXDx/CH9UpDJaJx5vLPcBQAYN6oDvLRWu7Rk44zZbf2WikRU 7sfeN3YXb9ie9ix7vWZ2NnxkiHQAYNyYMXdBxZ7qL23bGi90bizHeq2z6Ht27qjYSSbiyFr4 0q4jGdVz5sGWt4zk9451Ih0AGFNK+3U/uHh+za9Xh3jHLVeXzzTXOotefXHj7EVLah43XKpv zFS9A8pQ1HPmc+dfVfF4sDPrv3r+xxWPx/OFoUcj0gGAtKqjbihKFzIOdJa2+mx6yUA3EqqO zoxhWb3evJ4zV8f/S9u2DviLRfVWj8d7h9bxQKQDAGnVOis72JnlPTt3DGnP71rLWgYKxuNZ knE8Z79LqrdL3LPzuWN+z+GYubRzTslgZ8irt8KstbVi9ZaXQ90+c7wS6QBASo/d3V5zR5Lq tdYlT61bWfG1wc4eV59NH+gsekT/G/P0vQlPaWlNtVphXbpR0kCPS6p/Wai+UdCDi+fX/AzW XDMr7pvTHC90bhyWmUu74ZSU1u9HHPms75vTXA7vGXMXVET3to7VFXcxfWrdyvLuORFHAr36 DPyenTsqjinNXb0P+3jR0Nvb21v0EADA2Ldr1+tx9lm/ufPl6VNPjTWP3NbvuOHaLnD+bfcO upyi763sj7bbSa0LMUtmL1oSlyxbdUJz13r/wV5v8YbtA86zeMP2mNI687hnPmN2W9ywZvNR 5yi9RrXH7m4f8F8zasV537+HwVTPVe0bX/tOPPLQk+XHK1ZeFZ9v//BRXzepaSIdAKiLoUY6 HI+xFumWuwAAQDIiHQAAkhHpAACQjEgHAIBkRDoAACQj0gEAIBmRDgAAyYh0AABIRqQDAEAy Ih0AAJIR6QAAkIxIBwCAZEQ6AAAkI9IBACAZkQ4AAMmIdAAASEakAwBAMiIdAACSEekAAJCM SAcAgGREOgAAJCPSAQAgGZEOAADJiHQAAEhGpAMAQDIiHQAAkhHpAACQjEgHAIBkRDoAACQj 0gEAIBmRDgAAyYh0AABIRqQDAEAyIh0AAJIR6QAAkIxIBwBI7Nev/6roESiASAcASOzB/3l3 9PQcLnoM6qyp6AEAgPHpjdcPxPJlf1/0GMn1RufmtfHzn/12nNYys+hhUtvx7EtFjzCsRDoA UIjug2/G9x79YdFjpNYbL0dP7I0f/PMjMSE+WvQ41JHlLgAASfXG02/9f1vBk1BvIh0AIKne +Nlbf9r31n+MF5a7AAB1cfrpk+OBv7mh6DFGjTfe2Bv/5XP3xuHDEY2NjfHZz/x2/O7vXln0 WKPGB+ecWfQIJ0SkAwB1MXnySXHDje8reoxR42//9m9j4sSTYv/+Q3H48KHY+fN/jhtu/ErR Y1EnlrsAACS0fv362L9/f/nxE088EYcP24pxvBDpAADJ9Pb2xqZNmyqea2xsjCeffLKgiag3 kQ4AkMwPfvCD6OnpqXhu//798a1vfaugiag3kQ4AkMx3v/vdOHjwYMVzb775ZnR0dBQ0EfUm 0gEAknnooYeiu7u7/LihoSEiIp5//vl49dVXixqLOhLpAACJ7NmzJ5599tmIiJg0aVJERLzt bW+LiRMnxkknnRSPPvpokeNRJyIdACCRxx57LHp6euJtb3tbfOlLX4qIiEsuuSSmT58e+/bt i7/7u78reELqQaQDACTy0EMPxYQJE+Lb3/52vOc974mII2fUOzs745xzzoknnnii30WljD0i HQAgid7e3ujq6oqNGzfG/PnzK742derU6OzsjOnTp0dXV1cxA1I3Ih0AIImf/vSnsXbt2n6B XjJ16tTYsmVLvPzyy/UdjLprKnoAAACOePe73x3nnXfeoMdMmTIlFi5cWKeJKIoz6QAASZS2 Whyu4xi9RDoAACQj0gEAIBmRDgAAyYh0AABIRqQDAEAyIh0AAJIR6QAAkIxIBwCAZEQ6AAAk I9IBACAZkQ4AAMmIdAAASEakAwBAMiIdAACSEekAAJCMSAcAgGREOgAAJCPSAQAgGZEOAADJ iHQAAEhGpAMAQDIiHQAAkhHpAACQjEgHAIBkRDoAACQj0gEAIBmRDgAAyYh0AABIRqQDAEAy Ih0AAJIR6QAAkIxIBwCAZEQ6AAAkI9IBACAZkQ4AAMmIdAAASEakAwBAMiIdAACSEekAAJCM SAcAgGREOgAAJCPSAQCSePbZZ2PTpk2DHrN79+548MEH6zQRRRHpAABJnHfeefGZz3wmNm/e XPPrr7zySixYsCBaW1vrOxh111T0AAAAHDFhwoT44Ac/GAsWLIiNGzdWfO2VV16Jtra2+MUv fhFtbW0FTUi9OJMOAJDItddeGz09PXHFFVfEj370o4iIOHjwYLS1tcXzzz8fH/vYx6KxsbHg KRlpDb29vb1FDwEAwBG//OUv48wzz4yDBw/GpEmT4uDBg3HKKafEwYMHo7m5Of7sz/4sPvWp TxU9JiNrmjPpAACJ/NZv/VbMnDkzIo6cQY+I2LdvX7z55pvx5ptvxoIFC4ocjzoR6QAAyVx3 3XUxadKk8uOenp6IiGhtbY13vvOdRY1FHYl0AIBkrr766pg4cWLFcxMnToxPfOITBU1EvYl0 AIBkLrjggn4XhzY3N8eVV15Z0ETUm0gHAEimoaEhLr300mhoaCg/19PTEx/60IcKnIp6EukA AAlde+210dzcXH5s68Xxxc2MAIC6OHDgUDzy3f9b9BijRvfB6dHd/WZERDQ2NsU575obGzq2 FzzV6PG+90+Lc845vegxjpt90gGAuti16/U4+6x7ih5jVDkcfx4Rr0dEQzTGLRExueCJRo8V K6+Kz7d/uOgxjpd90gEAsmqIGW/9aXII9PFFpAMAJNUQH3jr/+8veBLqzZp0AKAQEyc2xQc+ 8u6ix8it93fin//P+jj/P14Up7X4rAbzwk9ejpd3vVb0GMNGpAMAhTilZXL8t69fX/QY6a25 /+n4g1tujwkT7OwymG987TvxyENPFj3GsLHcBQAgsd9b/CWBPg6JdACAxE49bfRuI8jxE+kA AJCMSAcAgGREOgAAJCPSAQAgGZEOAADJiHQAAEhGpAMAQDIiHQAAkhHpAACQjEgHAIBkRDoA ACQj0gEAIBmRDgAAyYh0AABIRqQDAEAyTUUPAACQ1d6dO+KBa2Yd1/cuXPFwTJ+7YJgnYrwQ 6QAAA2hpnRntXQciIqJj8fzYvW1rv2NKXy9ZNac5IiK+dcvVERExbXZbLFqzeUTnZOyx3AUA YAhqhfa02W39nmvvOhDtXQfKX9u9bWusmtMcz6xbOdIjMoaIdACAIZq1aMmQj120ZnPF8VuW Lx3RUF81pzlWzWmOzXe3j9h7UD8iHQBghMxftqri8UiF+t6dO4b9NSmWSAcAGEHzbru34vGW 5UuHPapf2PLIsL4exRPpAAAjaMa8y/s994O19w3b67/YuTG2LF86bK9HDnZ3AQAYQS2tM2Pa 7LaKnWG2d6zutxQmIuKZdSsHDO55t90b77vxC+XHL3ZuLO8g09f2jtWxvWN1+XGt3WWO5X0o hjPpAAAj7PRz+++1/mLnxoo/r5rTXA7n0g4xN23YXj5my/Kl5e0dIyKmz10Q7V0HYuGKhyte d9aiJeXvb+86UBHox/M+FEOkAwAU4LV/+2n5z33PiPeN7pbWmf0i/ER2b6nX+3DiRDoAQIH6 nlGPiOj6y3sqHlfftbTvUpaM78PwEOkAAAWqjuOZl143qt+H4eHCUQCAArz97HeX/9zedaAu 71mv9+HEiXQAgBH2q+e293uupfXcmsd2LJ5fsRPMSKnX+3B8RDoAwAirFcMtrTPLf967c0c8 cE3/HWBu2rA9WlpnDttuK/V6H06cSAcAGEHVF2xGVN6FtFY4L1zxcL815CeqXu/D8HDhKADA CKreRSUiKm4WVH330VmLloxIONfrfRgeIh0A4DgdbU33i50b+x1TvR959Xr1t7/r/OEZrkq9 3ofhIdIBAIao1gWge3fuqHns3p07Km4eFHFk7Xf12etadyM9mr7vWX0Baq0Zh+N9qC+RDgAw BJvvbq955vzxO5bUPLbv+u9ps9uivetAxcWiJRfcfGvF4y3Ll5bj+MXOjTUv5ty787nyn1ta Z8a02W3lx7u3bS2vg39m3cpYNac5nlm38oTfh/pq6O3t7S16CABg7Nu16/U4+6zfrM8+feqp seaR2wqcaGhOZMeT0q4pRzPQrisRR9aOz1+2quaWidNmt8WiNZsjYuAtFUvfP1zvk9U3vvad eOShJ8uPV6y8Kj7f/uECJzoh0+zuAgAwiHrcAKildeZR3+dgNU8bAAANkUlEQVRokTyUiB6O 96E+LHcBAIBkRDoAACQj0gEAIBmRDgAAyYh0AABIRqQDAEAyIh0AAJIR6QAAkIxIBwCAZEQ6 AAAkI9IBACAZkQ4AAMmIdAAASEakAwBAMiIdAACSEekAAJCMSAcAgGSaih4AAGA0erFzY3zr lqtrfm3ebffG+278wjEdB32JdABgVNq7c0c8cM2sQY8ZyQhuaT13WI+DvkQ6ADCqbL67PbZ3 rC4/nja7LRat2VxxzDPrVsaW5UvL/5XMWrQk5i9bNSxztLTOjPauAxER0bF4fuzetvWEjoO+ rEkHAEaFvTt3xKo5zRWBftOG7f0CPSLifTd+Idq7DsS02W0Vz58z/6oRmW3mpdcN63Eg0gGA 9GotbVm44uFoaZ056PctWrO5ItRf+7efjsh8Y82qOc2xak5zbL67vehRxi2RDgCkVx3osxYt ielzFwzpey/+6uqjH0TZ3p07ih6BEOkAQHLPrFvZ77kLbr51yN/f0jozZi1aEhERrz3/42Gb a6x6YcsjRY9AiHQAILm+F35GHLlQ9GjLXKqV1qL/6rntwzbXWPRi58Z+nzfFsLsLAJDWi50b +z13+rmDb7tYy/S5C8o7rAz0PgPtZT6cO8Icq8HmGuznKRlsm8q+P9dA77O9Y/VRd9I51s9u sONv2rA9Hr9jSb8dcIr8OyiKM+kAQFq1LvR8+7vOH7bXf7FzY6ya01yOxlmLlkR714Fo7zoQ C1c8HBFHQnXVnOaay25GSmknm9JcC1c8HO1dB+KmDb/5l4DBLuwsfX8p0KfNbiv/XKXXKP1c e3fuKP8SU/qZS/p+Hu1dByoC/Xg/u9J79f1ZSh64Zlbs3ra139f6/qIwXoh0ACCtkVxDXn1G t/ps7fS5C2LebfeWH29ZvrQuoV599nvhiofLF8m2tM6sCOntHav7zfRi58aK75+1aElFXLe0 zqzY8ebxO5Yc84zD8dn1vVagpPTLRPXXqo8bD0Q6ADAuVS+5qHUxavXdSrcsXzriu59UR3P1 LjbT5y6oiOzqNeRH+7n27txRsZzkeG6uNFyfXfW/ivRdyjR/2arymfnxttQlQqQDAONQ9Vr3 wS5GrT6L+4O1943oXH2jeahnkEs/T/XZ6lo/V/WZ9L5nvI/lvQZ7j5Jj/eyGcynTaOfCUQBg 3PnZ5m9WPB7sYtTqcBzJHWKq56q+cPNoqpcHDfRz1bpL61Bl/ezGGpEOAKRV68zqjk3r+y2l GIpVc5ojYmi7omRxrLuaVEewM9Ojl+UuAEBaM+Zd3u+541lDXb0WOusZ3axz9TUaZhwLRDoA kFb1+umSWvunD6Z0F83Sax3PXuslJ/K9x/raxxrE1d8/ErvjZP3sxhqRDgCkNucPb+/3XNdf 3nNMr7Fj0/qKx6U7kJYMFsPVoTuSS0iq5zrWfzWonm0k9hfP+tmNNSIdAEht+twF/XYJ2b1t 65D3LH9m3cp+sVu9reHubVsH3FqxOnSPZz38UFXPFXFs/2pQa7bh3ts962c31oh0ACC9+ctW 9Vv2MpSbC73YubFiH/G+sV59d81a2wNWv37194yE6veo3pP8WL//WPZ2b2k9t+LxQGfJs352 Y4lIBwBGhUVrNtcM0NKuLdU6Fs8fNHCnz13Q7+6dm+9uLz9+Zt3KisDve+fPatXLaaofH8tx 1XNFHNmZpvqM+t6dO2LVnOZ+X5s+d0HctKEyrh+4ZlbFzxZx5OcrfX8p4quvAdi9bWvFHuyr 5jTHM+tWDstnt3fnjn43YtqyfOkxX28wVjX09vb2Fj0EADD27dr1epx91m/Wkp8+9dRY88ht x/16A8V5X323MCwdf9OG7f1uvrP57vYB128PFOcvdm4c0lnuhSseHtJxtbaGrI7datNmtw26 5/nRZpx32701l6B0LJ5fcz18rS0hj/WzG+rndrSfrdo3vvadeOShJ8uPV6y8Kj7f/uEhf38y 00Q6AFAXwx3p0NdYi3TLXQAAIBmRDgAAyYh0AABIRqQDAEAyIh0AAJIR6QAAkIxIBwCAZEQ6 AAAkI9IBACAZkQ4AAMmIdAAASEakAwBAMiIdAACSEekAAJCMSAcAgGREOgAAJCPSAQAgmaai BwAAxqc3Dx6Oru/9pOgxGCNe2b236BGGlUgHAArx69f3xV3/9W+KHgNSstwFAACSEekAAJCM 5S4AQF1MntwU//mK3yl6DMaJGTPeXvQIJ6Sht7e3t+ghAACAsmmWuwAAQDIiHQAAkhHpAACQ jEgHAIBkRDoAACQj0gEAIBmRDgAAyYh0AABIRqQDAEAyIh0AAJIR6QAAkIxIBwCAZEQ6AAAk I9IBACAZkQ4AAMmIdAAASEakAwBAMiIdAACSEekAAJCMSAcAgGREOgAAJCPSAQAgGZEOAADJ iHQAAEhGpAMAQDIiHQAAkhHpAACQjEgHAIBkRDoAACQj0gEAIBmRDgAAyYh0AABIRqQDAEAy Ih0AAJIR6QAAkIxIBwCAZEQ6AAAkI9IBACAZkQ4AAMmIdAAASEakAwBAMiIdAACSEekAAJCM SAcAgGREOgAAJCPSAQAgGZEOAADJiHQAAEhGpAMAQDIiHQAAkhHpAACQjEgHAIBkRDoAACQj 0gEAIBmRDgAAyYh0AABIRqQDAEAyIh0AAJIR6QAAkIxIBwCAZEQ6AAAkI9IBACAZkQ4AAMmI dAAASEakAwBAMiIdAACSEekAAJCMSAcAgGREOgAAJCPSAQAgGZEOAADJiHQAAEhGpAMAQDIi HQAAkhHpAACQjEgHAIBkRDoAACQj0gEAIBmRDgAAyYh0AABIRqQDAEAyIh0AAJIR6QAAkIxI BwCAZEQ6AAAkI9IBACAZkQ4AAMmIdAAASEakAwBAMiIdAACSEekAAJCMSAcAgGREOgAAJCPS AQAgGZEOAADJiHQAAEhGpAMAQDIiHQAAkhHpAACQjEgHAIBkRDoAACQj0gEAIBmRDgAAyYh0 AABIRqQDAEAyIh0AAJIR6QAAkIxIBwCAZEQ6AAAkI9IBACAZkQ4AAMmIdAAASEakAwBAMiId AACSEekAAJCMSAcAgGREOgAAJCPSAQAgGZEOAADJiHQAAEhGpAMAQDIiHQAAkhHpAACQjEgH AIBkRDoAACQj0gEAIBmRDgAAyYh0AABIRqQDAEAyIh0AAJIR6QAAkIxIBwCAZEQ6AAAkI9IB ACAZkQ4AAMmIdAAASEakAwBAMiIdAACSEekAAJCMSAcAgGREOgAAJCPSAQAgGZEOAADJiHQA AEhGpAMAQDIiHQAAkhHpAACQjEgHAIBkRDoAACQj0gEAIBmRDgAAyYh0AABIRqQDAEAyIh0A AJIR6QAAkIxIBwCAZEQ6AAAkI9IBACAZkQ4AAMmIdAAASEakAwBAMiIdAACSEekAAJCMSAcA gGREOgAAJCPSAQAgGZEOAADJiHQAAEhGpAMAQDIiHQAAkhHpAACQjEgHAIBkRDoAACQj0gEA IBmRDgAAyYh0AABIRqQDAEAyIh0AAJIR6QAAkIxIBwCAZEQ6AAAkI9IBACAZkQ4AAMmIdAAA SEakAwBAMiIdAACSEekAAJCMSAcAgGREOgAAJCPSAQAgGZEOAADJiHQAAEhGpAMAQDIiHQAA khHpAACQjEgHAIBkRDoAACQj0gEAIBmRDgAAyYh0AABIRqQDAEAyIh0AAJIR6QAAkIxIBwCA ZEQ6AAAkI9IBACAZkQ4AAMmIdAAASEakAwBAMiIdAACSEekAAJCMSAcAgGREOgAAJCPSAQAg GZEOAADJiHQAAEhGpAMAQDIiHQAAkhHpAACQjEgHAIBkRDoAACQj0gEAIBmRDgAAyYh0AABI RqQDAEAyIh0AAJIR6QAAkIxIBwCAZEQ6AAAkI9IBACAZkQ4AAMmIdAAASEakAwBAMiIdAACS EekAAJCMSAcAgGREOgAAJCPSAQAgGZEOAADJiHQAAEhGpAMAQDIiHQAAkhHpAACQjEgHAIBk RDoAACQj0gEAIBmRDgAAyYh0AABIRqQDAEAyIh0AAJIR6QAAkIxIBwCAZEQ6AAAkI9IBACAZ kQ4AAMmIdAAASEakAwBAMiIdAACSEekAAJCMSAcAgGREOgAAJCPSAQAgGZEOAADJiHQAAEhG pAMAQDIiHQAAkhHpAACQjEgHAIBkRDoAACQj0gEAIBmRDgAAyYh0AABIRqQDAEAyIh0AAJIR 6QAAkIxIBwCAZEQ6AAAkI9IBACAZkQ4AAMmIdAAASEakAwBAMiIdAACSEekAAJCMSAcAgGRE OgAAJCPSAQAgGZEOAADJiHQAAEhGpAMAQDIiHQAAkhHpAACQjEgHAIBkRDoAACQj0gEAIBmR DgAAyYh0AABIRqQDAEAyIh0AAJIR6QAAkIxIBwCAZEQ6AAAkI9IBACAZkQ4AAMmIdAAASEak AwBAMiIdAACSEekAAJCMSAcAgGREOgAAJCPSAQAgGZEOAADJiHQAAEhGpAMAQDIiHQAAkhHp AACQjEgHAIBkRDoAACQj0gEAIBmRDgAAyYh0AABIRqQDAEAyIh0AAJIR6QAAkIxIBwCAZEQ6 AAAkI9IBACAZkQ4AAMmIdAAASEakAwBAMiIdAACSEekAAJCMSAcAgGREOgAAJNMUEZ8seggA AKBsz/8HL9Be5HxfNFIAAAAASUVORK5CYII= --------------090301090900080605040005 Content-Type: image/png; name="BasicGroupedEntities.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="BasicGroupedEntities.png" iVBORw0KGgoAAAANSUhEUgAAAukAAAQdCAYAAADjF9Y+AAAABmJLR0QA/wD/AP+gvaeTAAAg AElEQVR4nOzdeXxU9b3H/3dCIEExgAIaJICCLGJBiZWwKFTRQIVQIhXiQn8XRH0UilZQq/f6 M/zuQ6soVil0gRJ7L1jUS6GA9wKKFUEhCAFEaUAWCWFRQPYlbMnvDzzjmTNn1szMOTN5PR8P H+1sZz5nMiHv+c7nfE5KdXV1tQAAAAC4RVaq0xUAAAAA8EZIBwAAAFyGkA4AAAC4DCEdAAAA cBlCOgAAAOAyhHQAAADAZQjpAAAAgMsQ0gEAAACXIaQDAAAALkNIBwAAAFyGkA4AAAC4DCEd AAAAcBlCOgAAAOAyhHQAAADAZQjpAAAAgMsQ0gEAAACXIaQDAAAALkNIBwAAAFyGkA4AAAC4 DCEdAAAAcBlCOgAAAOAyhHQAAADAZQjpAAAAgMsQ0gEAAACXSXO6AMApXxUX+1zXsH17Xdmz Z8TbPLl7t/a8/77P9e1GjIh4mwBqZtd776ly/36/t1991126tEWLOFYEAMER0gGTo1u21Cik nygvj2I1QPI6vGmTjn/9tVoOGBCT7fv7wGzHfL9k+kAd69cYQGwR0gGLk7t3R7yqdnTLlihX AySXs8eOaeecOZKkjGbNYvIc3376acS/i18VFyf8yno8XmMAsUdPOmAR6Wr4yd27o1wJkHy+ Wb48ptuvSUA37Hn//YT+fY71awwgPlhJBywibXmh1QVw1tljx2wDerCVcbue9T3vv59UrS8A Eg8r6YAuHjBqFskqmjkcWLcHIPYOf/GF1+Wm3bqp3YgRQVtXWg4YYBvID2/aFNX6ACAchHTg e+ZgHe6quDnUE9ABZ5g/KGc0a6bGnTqF9fjWQ4Z4XT7+9ddRqQsAIkFIB77XoFUrz/8Pt6fV HOrN2wEQH2ePHfO6fNk114S9jXqZmV4HWgYa2wgAsUZPOvA961fi4Ux5MYf6S1u0iLg/PdhB b6FOnTi8aZMOrF4tyXv2u3nqg1lN5sNHq2arYHPsrSP2Wg8ZonqZmUG3G2g0Xzi1mreT0ayZ 15g78+sf6vbt9te63XDrCuf5zaL9/vH3elTu3++13zWZqhLKzz4U/l5v676HU6u5571pt25+ V/j9vU6hPF+0XuNk//0AEgkhHTBp2L69J3CeKC8P6Q9SNFpd7P4A2TH+6AX6Q+9PoBO6HN2y RUe3bAlru7GqOZQ6r77rrpCe2yyUudnG7ZGGxWDPsef9932CRaAPOUbACuW1i/X+Rfv9EwsZ zZp5ajywerUuzc6OWng3VtmN7Yf678PZY8e8XrdLs7N97hMonBtq8rsfimT//QASEe0ugEkk LS81aXU5uXt3yGHX7MDq1WEd1PZVcXFIX90fWL066EGzsaw51Dr3vP9+WN9WHN60KeQT2xjb //bTT0O+fzjPUbl/v3a9956ki8E3lPdZsJ9LrPcvmu+fWLK2uOycMyfsn2Oo2w/134eTFRWe /5/RrJnPh4ZQArpZuL/7oUj23w8gUbGSDphE0vJibXUJh/WPVqC2AetK5oHVq0NaPbIeTGf9 etgauL/bsCHgfsSqZuMPs5l14oZ5VS3UkGQXguxW3qyrfEe3bFG9Ro1Ceo0r9+/32k9r6411 29YWBLvX0Pra+fu5xHr/ovH+adypk+d5zPsV7XaFxp06+bwWxiq/IdS2KDuXZmd7bf/wpk1B Xz/zwafWDxFnjx3zqdeuPuvP2O5bgkhf42T//QASGSvpgEU4U15q0upiXQ27+q67Avb1thww QE27dfO6znqwXCBNu3Wz/WPdbsQIn4Pl/G03VjWf3L3b6w9uw/btbUfiXdmzp88EjkCsISij WTO1GzHCNlhc2qKF2o0Y4fVzPLB6dVivsbF9a8i6tEULvy06/l7DlgMGBP25xHP/ovH+iYdg 74+dc+boq+Jir/9CZT2wNNj0F2uri0/wNa2yS/4/QDTu1Mnn/WN9bCSS/fcDSHSEdMAinJaX mrS6mP/AZzRrFtIqkLWf9VyIf5SCjaO74sYbQ9purGr+bsMGr8uBgn+9zEyf4O+PdW52KKu2 1ucOJwxdddttfm+ze62adusW8DUM9nOJ1/5F6/0TD/UyM8M+CVE4gd28Gh4sGJp/PnYf4s8e OeL5/3atMGaXtmjhFUrNj41Usv9+AImOdhfAIpyWl5q0usRzKkGwcXR1LeHg7NGjtvsTi5qt q42hBHC7tgY75p9PqMHeuK+x/eNffx3SV/oN27cP2kZhPvBQsj+I0Mz6c7GK1/5F6/0TT+1G jPA7jSaQr4qLA7aIWN97JysqVM/P62f++QT7EG8E/kDvoWj//iX77weQ6FhJB2yE0vIS7xMY 7XrvvbADhyHYH7tYCaVm6+pXqLUGe82tK5zhvAb1Gjb0/P9Qv0av16hR0PukN27s/ZgahIx4 7p9T75+aMlbVjf9CZe2JtjK/9/y1vFgPZLT70GIN7tE+0DWQZP/9AJIBK+mAjQatWnkdoGjX fhGLExhFsvIXDTUNizWp+ezRoxHVYv4Z2bGG/5rUeC7ICqfkHVxCYW5diES89y+QRAlT1qAe aKykcbvd6rX5vedvBdz874O/D5RGC4u5hmge6BpIsv9+AMmAkA7YCKXlpSatLmbxCObR/iMf zZqtfbnRYg3/ySae+5coITxc5gBuN8O7cv9+2999n38fbFpeQm11aTlgQMBVe/PvWTTngSf7 7weQDGh3AfwI1PISrVaXw5s2hRx2r77rrrAmm8RKItYMBGM3vUTy3+4WqOUllFYXs3YjRoTU E35g9Wp9VVwc9TnpANyJlXTAj0AtL9FodTm5e7ftwY+BDlpzesRYItZsCHfiR6JJ9v0LRyjn N/Dnyp49vVbBzxw+bHu/QC0v5n8fQj0g0zznPNBZNqXvRx8eORJwClK4eP8A7kNIB/wI1PIS jVYX61frseo9jaZY1xzKWS0jFWxyRqJL9v0LxNp+1bB9+xq1oDVs3z7o+NVALS9e/z5EcNDt lT17egVwu3aYo1u2qPGPfhS1n3ltfv8AbkW7CxCA+Stto4czGq0u1q/Dm3brFtIfSCfnAMeq ZuvUh1BX3oP11FoPVIvGyV/cJNn3LxzW92GoZ6OtKfMqudHyYv49CTb7PFTGdBrrvzc1+Znz /gHcj5AOBGBuZTH+CMdiqkuoq23BzoAaT9Gq2bqdUMNCsLM9Wlc6g90/0ST7/oXLGmAjHWV4 9tgxr5BvHQtoZn7vGi0v5vd7sPny5pMohdJnbm1vqckJjXj/AO5HuwsQgPkPmfFHOFpTXcJl fe5EEErNxqnWjVaXUE6OcnL37pBaY8xtC/4mddg5vGmTV++9W1uRkn3/wmEdyXl0yxadOXw4 rBMA2U0tCvRB3PrePVlREVarS7jve5/nD2H2eCC8fwB3YyUdCMK8QvfN8uW214fLeqY86+m5 rfyNPIznGLVY1mw+vXfl/v0BV0HPHjvm0xvvT+Mf/cjr8p733/dp27GyHhwbypkSnZLs+xeO S1u08PmdNE5K9FVxccA2qrPHjumr4mKf92sove3m1XLzanQorS7mx1bu3x90Nd16e7izx614 /wDuxko6EIR1ioP5+khZV+ACrfoFO+FKvMSyZiNgmafpHN2yxWfihHUFL5Sazacwly4GEX/T aOzqjuYEjWhLxP1Lb9zYU4O/EwFFyjqZxSySuf6hvDaXZmd7Xn/zaxus1UW6ONHF/LM7sHq1 jn/9te3PzjrxJaNZM78fIEJ9jRPx/QPUJoR0IAh/fwhr2upyxY03eq0IBzsVuXTxQLXjX3/t +UNZk57USMSyZruAFWjb1nDhT+NOnXT2yBGvbYdSt6SEmPGeaPtnbdEwh+er77qrxr9X7UaM iMoH21BHElo/vBpCbV1pPWSI12sQ6s/uqttu819TGK9xor1/gNqEdhcgBNav0WvS6mK4tEUL XX3XXSHfv92IEWrcqZPXgWz+ZjjHSqxrbjdiREhnHW09ZEhYX/Vf2bNnyPOqzbUkytf4ibR/ gcJrtNq3Wg4YENb71Kxpt25hzwy3rpqH8+9DvczMsMNusJ9duK9xIr1/gNqElXQgBNaD0qI2 1eX7sxz6O3mJ3dfOgU6iEg+xrtl4rN1Knvm06NYpMMFeA+NkMXanfw9Ue6JIpP3z9/6J5jdD xvtUCq1NqiYn87G2rYT770O9zEy1GzHC73EcUvg/u3Bf40R6/wC1RUp1dXW100UAQLiswYsz JsIp1nDNexFAFGSxkg7AUdaAE2pfsnlFMJQWGSBWzN/qRKMVDgAketIBuEyoJ2wK9YQzQKyZ Ry9axxoCQKQI6QAcZXdK90AzraWLo+DMonWMABCus8eOeSa7hDIbHQBCRUgH4DjrZImdc+bY ntjFOOmMedxdKCecAWLB2qplPikXANQUB44CcIVIZlszbQLx5u99ynsRQJRlsZIOwBVaDhgQ 1kF3Ddu3JxTBNXgvAog2VtIBuI6/GeyS96x0IN6s782G7dvryp49HawIQJLKIqQDAAAA7kK7 CwAAAOA2hHQAAADAZQjpAAAAgMsQ0gEAAACXIaQDAAAALkNIBwAAAFwmzekCInFi1y7t++c/ VV1V5XQpAAAASGL1GjVSdv/+qlO/flyfN+HmpB/fvl37li+XEqtsAAAAJKi0Bg3U8qc/VVqD BvF6ysSak05ABwAAQLydP3FCFf/3fzp3/HjcnjNhQvqxbdsI6AAAAHDEuRMntHvRorgF9YQI 6VXnz+vbTz4hoAMAAMAx506c0IE1a+LyXAkR0lVdzUGiAAAAcF6cMmlihHQAAACgFiGkAwAA AC6TkHPS7TRo2VIZzZo5XQYAAAAS2NHNm3XuxAmny0iekH5J8+ZqdP31TpcBAACABHZy1y5X hHTaXQAAAACXIaQDAAAALkNIBwAAAFyGkA4AAAC4DCEdAAAAcBlCOgAAAOAyhHQAAADAZQjp AAAAgMsQ0gEAAACXIaQDAAAALkNIBwAAAFyGkA4AAAC4TJrTBbjFkSOVWvNZhdNloJa4qWtz NWlyqdNlAEBcnTlzXss//trpMlBLdOjYTNnZDZ0uI2KE9O/9a9O36p9X7HQZqCUWvPcL/fTu Dk6XAQBxdfDgKf7WIm4mT8nXL0d3d7qMiNHuAgAAALgMIR0AAABwGdpd/Lj0sgy1vf5qp8tA kvh6yz4dO3LK6TIAwFXq1kvT9Te1croMJIk9Ow/o4LfHnC4jagjpfmRf01QTpj7odBlIEv/5 2Fsq/XSr02UAgKtc1rA+f2sRNX9++X+16H/WOF1G1NDuAgAAALgMIR0AAABwGUI6AAAA4DKE dAAAAMBlCOkAAACAyxDSAQAAAJchpAMAAAAuQ0gHAAAAXIaQDgAAALgMIR0AAABwGUI6AAAA 4DKEdAAAAMBlCOkAAACAyxDSAQAAAJchpAMAAAAuQ0gHAAAAXIaQDgAAALhMmtMFAIbSLUtU 9JdBtreNyn9V+beOiXNFAAAAziCkO2Tfwe16+OVOET124SuVUa7GHZpf0dbpEgAAAFyBdheH ZDVpo4WvVGrhK5XqlzvS9j7Tnt7kuc+o/Fc91w98MkNPTekTp0rjx/yadGyV63Q5AAAAjiGk u8Doe6b6XNexVa6ymrTxXM6/dYxXUC8rL0nKoG7o1WWI0yUAAJC0dq5cop0rlzhdBgKg3cUl +uWO1OKSGQHv8+OO/TV9wXjP5bLyEpVuWaKc9nmxLs/VBj6ZIenia2j3gQcAALOdK5do7lj7 Y6D8KZg8X617JObfW3/727xzbsLuU23ASnoCMa+sG0q+XOBAJe6x7+B2p0sAACSY1j3y9MTa Sj2x1v4YL+M28+1zxw7SazdnxKvEqDL2t2DyfKdLQRgI6Uhoa8oWOV0CACCB9Rn3qtfl5p29 j4kaMW+T1+W3R/SJcUWx07pHns/+wb0I6UhYpVuWeLX/AAAQrmt79Q94e6PsNl7Bdu/GkqTv 5V764mi9dnNGQn8gSQb0pCcQu9aO3BvyAz4m0OzxQKMc/T3OmLpSVl6iaU9v0pqyRX6Dsnn7 C1ZMsb1fx1a5mjhmWaBdCLm2xSUzvPr6rdsOdZ/s2ooAALVXk7adtHdjiefyofKtSd3LvXFu 4GPkEB+E9ARibe3o2CrX70Gj1jnsRQ/NV077PK/rBz6ZYXuwpXEgpuR9EqGpfx/tCcHG9Jn8 W8co/9YxfkO4wbifeRuRymmfp4WvVPqE7kAHjoazTwAA1FZLXxztdAn4HiHdpcrKS7wu24Vg fyvQ/gK6dPHg06KH5nvC7eKSGcpu1tErtBr65Y70OsunEYDtQnb+rWNCaj0p6P1EjUN6uCLd JwAAJOngNu++9MtbXef3vkcqtqt4sO/JCpt3ztWw4mU+1789oo/XKr1Z54KRuvyajlo2yffv q3najN02/D2fP0tfHO2zgr53Y4nXwbLBntNcd99nmbZWU/Sku9jAJzM8/5kDsHHCH39+97b3 yZGsq+057fO8ThZk3nawsBqsvcaNknGfAADxcaRiu1cYDTS2cOmLoz0Bvc+4V70mqhiB90jF ds92X7s5Q3s3lqh551zPNBnzgayXX9NRXQvH6Im1lepcYH/iQ0kaVrzM5wDXcPV9dqqeWFvp 1X9vruuJtZVq3SMv5LpRc4R0F7M7+2bRQ4HHJ5VuWeK1Cu/vbKZ2j7NaXDLD54RJRuC3rvQn imTcJwBA7FhXxf2tTptXojsXjFTXwovf2rbukecVYI3tLX7+h7/P/Sb8sJjUtXCMbSBv2yfw gpL1ANdYCbduRI6Q7lLmYD5xzDLP5aK/DAp4plHr3PTFJTO8VuSN//wFUmuoLysv8TxmwYop koKv5LtNMu4TACA2jBVv4z/DiHmb/M5V37lyiVeriDVQWyfIrH/nD35bRewe7xbWbxWs3Fp3 oiKkJ4hfD/vhl7+svMSrzzqQfrkjPQE00H/GanKgM3ZOXzBeA5/MCPm53SIZ9wkAEBtGC4e5 faR551w1yvY/WGDbMu8FskbZbQM+x+HyrV6Xiwd38jpg0zj5kLEa71aJWneiIKQniKwmbbxW 1xeXzLBtUSnfV7OeNCn4qrKxOp9IknGfAACx0yi7jSeoW/vJrawHlhYP7uS1Gm9tmak6f9an NWTj3Bme+6+bPSWKexI9jbLbJGTdiYqQnkBaZXn/kr/zwW+D3qcmod0ItqPyX7W9PRFXn5Nx nwAAsWHt87ab2iLJpwXEfLCl3X99n52qvs9O9dvDvWzSeL12c4YrT5qUqHUnIkJ6ArFOIbHr Kw/lPoEYvdpm+beO0cJXKn16u61TU8wr/ZL9yZecUJN9AgDUbu3uHOJ12W612HrApr8Vdytj ooq/ySxzxw4KeVvxlKh1JxpCukvZhWu7ExdZW15CuU8gRtC2e0yg3u5IxWOiSrz3CQCQPKwH fX71wRyf+zRp673CfqRiW1jP0Si7jWeV3WrHJ4tsHuEOiVp3oiCku4RdW4rdSrR1tXrP/osH nzw1pY9n6ot1TKP5rJyhsmulsbKuQvfq4r3asPe70P6RinTFvfkV3gfmBGvtiWSfAAC1m/WA UbvpJtapJtYDSa2MWeNvj+jjc5u/1elgB6PGQyR1I3KEdBdYsGKK7Yrywy938gmw1iD8yedz PLPRy8pLtO/gduW0z/MJ6gOfzPBZSd53cLunFcR6mzGm0Mzar21dhTafyVPy/XDw1JQ+XmdC Ne+ntYZPPvdeqbBelnwPpi0rL/FsY8GKKV4jFiPdJwBAcrOuetuFcGsPtrXnunWPPK+Wl41z ZwRs9zCC/96NJUHbQoyVfOuHhUOWCTFWgUYlRiqSuhG5NKcLqM1CmSZihNqOrXI1ccwyTxA2 zhJaVl7iCcPm6SU57fO08JVKLVgxxXNfuxV1Y7vh1Fj00Hzbthqjhqem9PF86LA+ftrTm2yD uiTtPbhdRX+xf03MAdu8nxPHLPN6PvM+9ssdqfxbx/gE/HD3CQCQvEr+4vst69sj+nidtKht n3yvOejbli3QtmULtHHuDPUZ96q6Fo7RsOJlentEH084Lh7cSQWT53udndQ44VHngpFq3jlX ezeW+Nxv7czXPPfvXDDSK5x3LhjpqWPZpPG6tld/NcpuoyMV220Pan3t5gyfVhRzeLcL8u3u HOK5fu/GEu1cuUSte+R5evEjqRuRSamurq52uohgqs6d07aZMwPep1lurhpdf33Ez7Hy03Ld 1utPnssdOmfrpWJaHxAd//nYWyr99IdVjwXv/UI/vbuDgxUBQPzt2XNMrVr8EIovb3qZiheN c6QW84mKAjGC6LrZU7Rs0niv24yAbuYvMFu3F+z5R8zbZBt07eqQLobnJm07eX2YMAyevEDz xgY+0ZD5+cxnTzXrM+5V2+cOpe54+PPL/6tF/7PGc3nylHz9cnT3sLdT8d57Or1/v9/bG7Rs qeZ9+0ZUYxiyWEkHAAC1jr+zh/rTtXBMSCfpMQ6mjPbzh1pH32ft2zbDeT5jRKS/50d8ENIB lzl48KCWLFmizMxMDRw40OlyAACAAzhwFHBYVVWVVq9erf/4j/9Qhw4d1KxZM82bN0/9+3PQ DQB3qKys1EsvvaR58+bpxIkTTpcD1AqspAMOOHr0kGbNmqW33npLK1asUFVVlSorK5WamqoB AwZo9uzZSkvj1xOAO2RkZGjYsGHq1auXvvnmG3Xt2lVDhw7VwIED1a5dO6fLA5ISKQCIg+rq 86rWTlVri6r1lf6ff3tddeqk6PTp0577NGjQQAMGDNCsWbNUp04dB6sFAF+tW7fWihUrlJub q9LSUq1fv17//u//rszMTA0YMEBDhw5V7969lZER2gGZAAIjpAMxcvTQAa0r+UDLFr+t9as+ VLWqJF0cpnT2rPd909LSVL9+fR04cED9+vULafv169eP+h/DtLQ0XXbZZVHdpiQ1atRIKSkp Ud1mgwYNVLdu3ahuMz09XZdccklUt5mamqqGDRtGdZuSlJmZGfUPc5dcconS09Ojus26deuq QYMGUd2mJDVu3Djq24zFeyrZXHPNNVq7dq26deumAwcO6MyZMzpw4IDefPNNzZkzR5WVlWrX rp3uu+8+5eXlKScnx+mSgYRFSAdi4OC3u7XwnT9o5T//oW9275CUIiOg2zl//rwOHDigDz/8 MG41Aoi9WHzwq1OnjjIzM6O6TUlq2LChUlNDO1Ttiiuu0IEDB5SSkiJjkvPx48clSZs2bdJz zz2n5557To0aNVJhYaF+/vOfq0ePHlGvGUhmhHQgBppc2UL/NvZF/dvYF3X08EH95qGx2lP+ mar1jaRU1alzQRcuXPB6THp6ul588UV17tw5pOc4ffq0KisjG+Hlz/nz5z1/aKPp8OHDUd/m iRMndO7cuahu88yZMzp16lRUt1lVVaWjR49GdZuSdOzYMZ/3UE2dOnVKZ86cieo2z507F5MD DRPpPRXt11S6OAXKzaqqqiRdfJ9OmzZNX331lQoLC3X77b4n1QNgj5AOxFjDxk3UvMXd2lfe TlK1qvWthgxJ17p1/9Tu3btVt25dHTt2TGfOnNFzzz2nRYsW6bbbbnO6bABRUFlZ6XXsSTRc uHBBx44di+o2Jeno0aOecB3s+Z988kl99tlnPgsFmZmZOnPmjK688kr17dtX9913n/r06eNp zdqzJ/p1A8mKkA7EVYpSdJWGP/gLvf32n7R582b97//+r+bOnau1a9fq7Nmz6t+/v5YvX04v J5AEMjIyYnIgZZMmTaK+zVCcP39eBQUFWrNmjSorK5Wenq709HSdP39eeXl5KiwsVO/evdWs WTNH6gOSCSEdcFCHDh3UoUMHjRs3TsePH9cHH3ygBQsW6Be/+IXeeustdenSxekSAUDSxRaW wsJCLVy4UGlpaWrZsqUGDRqku+++m6kuQAwQ0gGXuOyyy1RQUKCCggJVV1drz549TpcEAJIu triMHTtWJ0+e1JQpU9SvXz+1adPG6bKApEZIB1woJSVFLVq0cLoMAJB0sc1l8uTJnMMBiCNC OgAACCja8/MBBBfaQFQAAAAAcUNIBwAAAFyGdhcAAJCQdq5corljwztBUueCker77NQYVQRE DyvpAAAgIbXukacn1lZqxLxNPrc175yrJ9ZWev7rM+5VSdLGuTP02s0Zeu1mRkbC3VhJd8BT U/qorLwkpPuOyn9V+beO8VxesGKKpi8YH9ZjAABIZo2y26jPuFe1bJL/v49dC8eoa+EYrZs9 xXO/127OUMHk+WrdIy9epQIhI6Q7YOKYZZL8B+6OrXI997HKv3WMJ4APfNJ7FaDoofnKaf/D PzTm2wNtEwCARHd5q+tCul/Xwot/Q42gPnfsoKgG9aUvjtbGuTPUvHOuhhUvi8o2E7kORI52 Fwfl3zpGRQ/N97m+VVankB7fsVWu5/9bA/qCFVO87ltWXqJ9B7dHWCkAAO7WKLttyPftWjhG zTv/8Dd07thBOlIRnb+RG+fOiMp2asotdSByhHSH5bTP8wrbkrS4JLRfLKNlpmOrXK+ALsmn 3aVjq1xlNeHscAAASFK7O4d4XV4787Uab3Ppi6NrvI1ocEsdqBnaXVxg6J3PqOgv3kenl25Z 4hO8zcyr4kPvfMb2PgtfqYxOgQAAJJlre/X36mHfOHeGbn7wCTXKvrigdaRiu4oH23+zbW2P MVpLzPZuLPE6ONX8mHC2bfb2iD7au9H+mLbOBSM9+xFqHYZw6vE3Uadg8nzb659Y+0MW8fc8 tOTYYyXdBezCeMmXCwI+Zk3ZooCPBwAA/hlh3OxIxTZJF0O3ESYLJs/3mSAzd+wgr9Xqvs9O 1RNrK71aaKzTZYygG+62L9a1Xa/dnKG9G0u8tmtMrJGky6/pGFYdhrdH9PHUY76vEfrnjh3k FfIbZbfViHmbvJ7buJ8kn0k7O1cu8dnvPuNe1RNrK1Uw+WLLr/FBIlotR8mCkO4S/XJHel0O 1vLyyedzbB8HAAAic6h8q3auXOJZjW7eOdcTahtlt/GESuniinW4oTLSbe8eo4cAACAASURB VC9+/oe/9f0m/JAPuhaO8YTpSJhX5q2r2X2fneoV9o2g3ii7jRplt9G1vfp7bcsI+I2y23ge Z+yj+ZuGzgUjPQfvtu6R5xX2/a3m11a0u7hEQe8nfIK5v5aXfQe3e/rRC3o/4Xeb1ukx057e 5LcvvXTLEp+WG4O5bcY6UcaqX+5Ijb5nqqfOh1/u5DNZJtA2rC06odYV7L7Tnt6k37090mf0 pbleAEDtdujrMq/LezeW6EjFds+qu/Xg1B2fLPIEzpC2X7417G0fqdjut8VFktr2yY/oINGd K5d4bdfaoy9JuQ8949XCsm72FM/+Wr+JaNL2h4BtDvvmDyZGvWbWtqOdK5cwEvN7rKS7RFaT Nj4HkL7zwW9t7zv344sHt9gdDFq6ZYkGPpmhgU9mBJ2nLl0M0gOfzPCE26KH5mvhK5Wa9vQP X1cNfDJDU/9+8au3ha9U2k6k6dgqVwtfqfQKvEZLTll5iUq3LPFcb92++XkjrUu62PZjt21J evjlTiorL/G5LdSDdAEAtYN5lGPzzrleYdSuRSbe2y4e3MmrHcY4oVM4HxYkadsy77Za68r4 xZq8Pzh89cGcsJ7D7nmCTeExf5Cp7QjpLtKri/enWH9jE41gaXfAqBFU7YK0lbHSbTCPccxq 0sZrG4tLZnjGOua0z9OofO9eNLuxkeYPCdYPHOYPF6PyX/X6xiDSuszbtrYBGR8irLfRLgQA MFx+TUdP6H1ibaXPwYw17ZmOZNuNstv4tLSYz5q6bvYU28cFc3Cb74JWLFifp3hwJ0/tr92c 4dPiYv02ozaj3cVF8m8d47P6vaZskdc4RfOKdKADRo3RjoHObPq7t71/6a3bs25j+oLxnlp+ 3LG/V62LS2Z4raKb65R+WE03nsP84ePHHb0/vdekLkN2s45el80fIkbfM5UWFwCo5exCsfWE SOazk0ZbONvu++zFv1l2bS3LJo3Xsknjwz4hk7WFxm4l33pdoLabUJ/HPO0FgbGS7jLWlV1r aDdWpK0r2eEq3bLEK8CHuqJshG+79hxz8LZr1TFPrDFaYawtOzWtyx9raAcA1G47Plnkc515 AstrN2d4hWhjBbymIt22MbnFOj3FEO4JmcwHhUr2H1qs11kfE63ngT1CusvYHQhqBFDzAaPW 1edwWUc8Li6Z4ellN/8XaCXe2p5jBG9zneYgv7hkhifIV+wvs91GNOoCACAYa3+1MWVk3ewp XivWxrjAaIjGthtlt/Eb6u0+ePhjPtAzno8xxlwiONpdXMbomTYf0PjOB79VTvs8Twjulzsy 6mcPjWTKibXl5ZPP5yj/1jGeA1tH5b+qq5td5zVxZe7Hr2n0PVM9+xfswwbTVwAA0WadbCLJ c+ClObw375wb9gGZgUSybeMEQHYn/Bkxb1PEYwutU2HsJtVYA7V1Mkskz7Nt2QKmt4SIlXQX yr3B+5fA6Oc2ArH19kiU76v5ASPWlhfjQFdzADf6xw2LS2Z4vhmwm04TjboAALWPNVD6658+ UrHd58yYbu6TNvrCjZGNgdhNaPGndY88r1YUu8ktJX/5oXW1c8HIiMK19XkimS9fWxHSXcga bCV5VqM7tsqNyhlGrdNYIg3H1gkzxlQW82q/taXF2Bfr9dGsCwBQu9idkt565s51s6d4rTwb J+AxM88L37uxxHPGTOOsn2bWSST+Hrtu9hStmz0l4m0bIbd4cCfPYyRp7czXPP+/c8FIT6AP VofBvDK/d2OJ3h7Rx3N56YujvU50ZBy8ajDXIV0M39brzM9jDurW/TCe77WbM3x+ZrUZ7S4u NfTOZ2xPzGMXbCORe0O+V0tNpD3e/j4wmFf77abWSPatLtGqCwCQ/IxWEH82zp1hOxGlz7hX /baaGNcbB3aaw3/zzrleJ/gxb9+YVX7o6zLPdebHmp8z3G2b2X0YGTFvk9cklmB1mD2xttIz aWbvxhKfDwvWbe9cucS2BvPz2L2+w4qXef287LYR7oSaZEdIdyl/4bemB4wG2r6/M5wGY+2h t1vtt7uPXV99NOsCACQ34yDKaOtaOCZgv3ig5+z77FSfVedobTscweoIpyYzY9Z7JGL180pW tLu4mHXMYk0PGN37nXe/nvWER3Yr96Gw9sjbrfZbp9YE+kYgWnUBAAAkKkK6i1lP0BPOAaPW eeOS73jDnPZ5PoF44JMZPjPH9x3c7hl9aDeP3NpDb61b8j3I1O4+0apr38HtPu010xeMDzpL HQAAwC1od3E5o00k1ANGS7cs8bvyvLhkhhaXzNCo/Fc9ITmnfZ4WvlKpBSumeIKt3eM7tsrV xDHL/D5vry5DVFZeEvDkQ0affSgnKIqkrkD7bn58sH0BAABwGiHd5cI9hb0RbsOVf+uYgKvb 0Xh8JLWFU1ek+w4AAOA2tLsAAAAALkNIBwAAAFyGkA4AAAC4DCEdAAAAcBlCOgAAAOAyhHQA AADAZQjpAAAAgMsQ0gEAAACXIaQDAAAALkNIBwAAAFyGkA4AAAC4DCEdAAAAcBlCOgAAAOAy hHQAAADAZQjpAAAAgMsQ0gEAAACXSXO6ALc6dfKMNq0rd7oMJInjx047XQIAuM75cxcC/q09 8M0O1a2XoUaXN49jVUhUhw4cd7qEqCKk+7Fr+379+8NvOl0GAABJ69iRUzZ/a8+pWptVpVKl qIFSNcSR2gCnEdIBAIDjqrVH1Vqlam3//pr6StVQR2sCnERIBwAADjmiKq1TtTZKuiDp3PfX pyhVwyTVd640wGGE9O81bJihW2+7xukyUEtcccUlTpcAAHGXnl5HPXo217f7P9OevR/p9On9 SlG1qqvOe+6TkpKqa68ZrOwW3RysFMng6qsbOl1CjRDSv9fphiv10ccPO10GAABJ6ZNPPtH0 6dNVun6O0tLSdPLkMZ/7pKWladCgQZozZ44DFQLuQkgHAAAxcejQIb399tuaMWOG1q1bp5SU FFVXV9veNyUlRU2bNlVxcXGcqwTciZAOAABionHjxsrPz9f111+vbdu26csvv9Tnn3+utWvX 6sSJE173rV+/vhYtWqTMzEyHqgXchZAOAABiIiUlRS1atFCLFi3Up08fbd++XUOHDtWJEyeU mpqqqqoqSdIll1yi6dOnq0uXLg5XDLgHZxwFAAAx984776hr164qLS1VmzZt1L59e0kXV9AH Dx6s++67z+EKAXchpAMAgJg5c+aMHnnkEQ0bNkzHjh3T0KFDtW7dOu3fv9+z0v6Xv/zF6TIB 1yGkAwCAmNi2bZt69OihadOmKT09XX/+85/19ttvq169ejp06JAyMjI0f/58ZWRkOF0q4Dr0 pAMAgKh7++239cgjj+jYsWNq27atp91Fknbs2KHq6mpNnz5dHTt2dLhSwJ1YSQcAAFFz+vRp DR8+XIWFhTp27JiGDRumdevWeQK6JG3dulWPPvqo7r//fgcrBdyNlXQAABAV27Zt07333qv1 69erfv36+tOf/qThw4f73O+yyy7T66+/7kCFQOIgpAMAgBqbPXu2HnnkER0/flzXXXed3nnn Hd10002297399tvjXB2QeGh3AQAAETt16pSGDx+u++67T8ePH1dhYaFKS0v9BnQAoWElHQAA RGTTpk2699579a9//UuXXHKJ/vjHP9q2twAIHyEdAACE7W9/+5seffRRHT9+XJ06ddK7776r 66+/3umygKRBuwsAAAiZ0d5y//336/jx47rvvvu0atUqAjoQZaykAwCAkNDeAsQPIR0AAAT1 1ltv6dFHH9WJEyd0ww036N133+VEREAM0e4CAAD8OnnypIYPH64HHnhAJ06c0P33369Vq1YR 0IEYYyUdAADY+vLLL3XvvfeqrKxMl156qf7whz/Q3gLECSvpAADAx/Tp03XLLbeorKxMN9xw g9asWUNAB+KIkA4AADyM9paHH35Yp0+f1qhRo/TZZ5/R3gLEGe0uAABAkvTFF1/o3nvv1ebN m2lvARzGSjoAANC0adPUrVs3bd68WT/60Y+0du1aAjrgIEI6AAC1mNHe8sgjj+j06dMaO3as Vq9erQ4dOjhdGlCr0e4CAEAttXHjRg0dOlSbN29WgwYN9Ic//EEPPvig02UBECvpAADUSm+8 8YanvaVz585au3YtAR1wEUI6AAC1yIkTJ/Tggw/q8ccfV2Vlpae9pX379k6XBsCEdhcAAGqJ zz//XEOHDtWWLVvUoEED/fGPf9QDDzzgdFkAbLCSDgBALfDGG28oNzdXW7ZsUZcuXbR27VoC OuBihHQAAJLY0aNHNWTIEK/2lpKSEtpbAJej3QUAgCS1YcMGDR06VF999ZUaNmyoGTNm6J57 7nG6LAAhYCUdAIAk9MYbb6h79+766quvdOONN+qzzz4joAMJhJAOAEASOXLkiO655x6v9pZV q1apXbt2TpcGIAy0uwAAkCQ2bNige++9V1u3blWjRo00Y8YMFRQUOF0WgAiwkg4AQBIwprds 3bpV3bp10/r16wnoQAIjpAMAkMCOHDmigoICPf744zpz5ozGjh2rjz/+WK1bt3a6NAA1QLsL AAAJavXq1Ro6dKjKy8vVqFEjFRcXa/DgwU6XBSAKWEkHACDBVFdX64033lDv3r1VXl6u3Nxc bdiwgYAOJBFCOgAACeTw4cOe9pazZ89q7NixWrZsmVq1auV0aQCiiHYXAAASRElJiYYNG6by 8nI1btxYxcXF+tnPfuZ0WQBigJV0AABcrrq6Wi+//LJuu+02r/YWAjqQvAjpAAC42OHDhzV4 8GD95je/0fnz5/X0009rxYoVatmypdOlAYgh2l0AAHCpVatWadiwYdq1a5cuv/xyFRcXa9Cg QU6XBSAOWEkHAMBlzO0tu3btUvfu3bV+/XoCOlCLENIBAHCRQ4cO6Wc/+5l+85vf6MKFC3r6 6ae1fPly2luAWoZ2FwAAXGLlypUaNmyYKioqdPnll+vNN99Ufn6+02UBcAAr6QAAOKyqqkpF RUXq3bu3Kioq1KNHD23YsIGADtRihHQAABxktLdMmDBBVVVVev755/Xxxx8rOzvb6dIAOIh2 FwAAHPLpp5+qsLBQFRUVuuKKK/TXv/5VAwYMcLosAC7ASjoAAHFmtLf06dNHFRUV6tmzp9av X09AB+DBSjoAAHH07bff6oEHHtDSpUuVmpqq559/Xv/xH/+htDT+JAP4Af8iAAAQJ5988okK Cwu1e/duXXnllZo1a5b69u3rdFkAXIh2FwAAYsxob/nJT36i3bt3q1evXlq7di0BHYBfrKQD ABBD33zzjR544AF9+OGHtLcACBn/QgAAECMrVqxQYWGh9uzZo6uuukqzZs3SHXfc4XRZABIA 7S4AAESZub1lz549uvXWW7V27VoCOoCQsZIOAEAUffPNN7r//vv1z3/+09Pe8txzz6lOnTpO lwYggRDSAQCIkg8++EAPPPCA9u/fr6uuukpvvfWWbr/9dqfLApCAaHcBAKCGjPaW/v37a//+ /brzzjv1+eefE9ABRIyQDgBACPbt2+f3+r59+2rChAmSpOeff16LFi1Ss2bN4lkegCRDSAcA IIj169dr5syZPte///77uvHGG/XRRx8pKytLH3zwgYqKiug/B1BjhHQAAAI4evSoBg0apOzs bM91Fy5cUFFRkX76059q//79uuuuu7Rhwwb95Cc/cbBSAMmEA0cBAPCjurpa+fn5qqioULt2 7SRdbG+57777tGzZMtWpU0cvvfSSnnrqKaWkpDhcLYBkQkgHAMCPiRMnas2aNUpLS1ObNm20 ZMkSPfjggzpw4ICysrL0t7/9TX369HG6TABJiHYXAABsLF++XBMmTNDp06dVv359vfTSS+rf v78OHDigvLw8ff755wR0ADFDSAcAwGLfvn0aNGiQTp8+LeniiMWXX35Zqampeumll7Ro0SI1 bdrU4SoBJDNCOgAAJlVVVRo6dKhOnjzpue7kyZPKzMzUCy+8oJ/97Gc6d+6cgxUCqA0I6QAA mEyYMEGlpaU+QfzUqVN64YUX1KVLF2VkZKhVq1b65S9/qV27djlUKYBkxoGjAAB876OPPtLE iRNVWVnpc9v58+eVmpqqOnXq6L777tOjjz6qnj17MtUFQEwQ0r938OBJffD+VqfLQC3Ru8+1 at480+kyksbevcf08bIdTpeBBHfo0LcaN36wzpzxDuj16qVLktq0uUF33TlUTz41UldffbkT JQKoRQjp3/tqy0E9eP87TpeBWmLBe78gpEfR5xv28fuLGrqgC/qDpNOm6+pJqqfzZ7sqRT/S V2WX6auyQ/r5z48R0gHEHCEdAFDrVeljSae+v5SqFF2jFHVViq6VRDsLgPgjpAMAarVq7VC1 1kjKVIraK1XdJdV3uiwAtRwh3Y/MRpeoS7c2TpeBJLFp3U4dOnDc6TJqjcubXqZOXVs7XQYS wPlzJ7Vr57/U9Mr/T5dlXmt7n42fbdfRw6dsbwOAWCGk+9G85RUa98I9TpeBJPGfj71FSI+j 1tddxe8vwjA84K2/GTmDkA4g7piTDgAAALgMIR0AAABwGUI6AAAA4DKEdAAAAMBlCOkAAACA yxDSAQAAAJchpAMAAAAuQ0gHAAAAXIaQDgAAALgMIR0AAABwGUI6AAAA4DKEdAAAAMBlCOkA AACAyxDSAQAAAJchpAMAAAAuQ0gHAAAAXIaQDgAAALhMmtMFAMGUbl6ioumDbG8bNehV5d82 Jqz7AQAAuB0hPUL7Dm7Xw7/tFPA+BMPoaN6kbVTvBwAA4HaE9DBNnTNai1fN8Fzu2DpXE3+1 zOs+C5ZP0fT54z3/Gfp1H6nRQ6bGq9SkkdWkjRZOqpQkPfX7PirbWVKj+wEAALgdPekh2ndw uwaOy/AK6NOe2eQT0CUp/7YxWjipUh1b53pdn3tDfqzLTHq9ugyJ6v0AAADciJAeArvWlqJR 85XVpE3Ax0381TKvoL5n/9aY1BdNA8dlaOC4DE2dM9rpUgAAAGotQnoIrAG9X/eRyumQF9Jj f104I/idXGLfwe1OlwAAAAAR0oNasHyKz3UFfZ4I+fFZTdqoX/eRkqSK/WVRqysW1vxrkdMl AAAAQIT0oMwHfkoXDxQN1uZiZfSil+/bFLW6oq108xKffQUAAIAzmO4SQOnmJT7XtcoKPHbR Tk6HPM/UEX/P42++d7CJMMYkGcPCSZU+1xnsRkL6e+7Fq2b4TLEZeuczfuuc9swm/W72SJ+J Knb112R/YyVQTdafXaD7+nsdmtXpLal7VGoFAADJj5X0AOwO9Mxu1jFq2y/dvEQDx2V4Al+/ 7iO1cFKlFk6qVNGo+ZIuhuWB4zK82m4WLJ/iOcDTGsaN60YNetVrO9LFbwWsB4QaHyDM97PW snBSpSb+apnnvtOe8f1G4OHfdlLZzhKf28xBP9L9jSVjao9RU9Go+T77aD2QNpLXYX/KxzHa AwAAkIwI6QHEsofcuhprXUHO6ZCnUYNe9VyePn+8J7gaIx7Nt5stnFTpWTHP6ZDn6YmXLoZg u28IwmHuszd0bJ2rhZMqfW4z/n9N9jdWrFN7ikbN9xwQnNWkjdcHl8WrZvjUE87r0Ky6dyx2 AQAAJClCukOs7RJ2B6NaW1Omzx/vNYHF7mym1hVxyXc+e8mXC8Kq1Y71GwVzG9DoIVM9K+RG EI/G/kbb72Z7B2zrxJ6cDnleIzTtWohCfR1aXxgejZIBAEAtQUh3gHUlO9DBqNaV2rnLXgu4 7eZN2tasuAgFagOK5f5GqnTzEq++cevzBnpcINFshwIAALUXB446wLqSHehgVGvoCzYhJpTJ M/GeMhPL/Y1WTdYDZQEAAJxESA/AblX0k8/n2LaZBDNwXIYk30khcAenpsoAAADYod0lgB9f 39/nOutovVBY+6rdPC89Fty4v26sCQAAwEBIDyCrSRuvAwcN4U5HMc7kaWwrklnrhpo81ilu 3F/rdgntAADATQjpQQy98xmf69754LdhbeOTz+d4XbZOWwkUEK1jIBPxwEQ37q+1pki+IQEA AIgVQnoQ1jnj0sVAF+oM7wXLp/gEQOuov7KdJX5HDVoPZoykH95pbtxfa01S+N+QAAAAxAoh PQSjh0z1aXsJ5WQ7pZuXeM3WNod16zxzu1GD1u3bzUC3inSuuHV0Y7TbP2K1v9GsyTrLHQAA wCmE9BBN/NUyn1A3ff54z9QWq6d+3ydg6MvpkOdzRkvzqecXLJ/iFfDNZ8M02AVy6wl6JN9x g3Yr2db++7KdJZ6V5QXLp2jguAxPiN53cLvPiX2mzx8fcCU6Gvsr+bYOWS+Hcz9rTdLFKTzW /dh3cLsGjsvwuS2S1wEAACAUKdXV1dVOFxFM1blz2jZzZsD7NMvNVaPrr4/4OVZ+Wq7bev3J c7lD52y9VOz/BDf+wrmZeayfcf9pz2zymWU+dc5ovzO67cJq6eYlQVd9+3Ufqdwb8oPezzoS 8qnf97Htzw51e9LFA2Qn/mqZ39tjsb/GY0O5n90YTOuHBCvzPoVaj/kx//nYWyr9dOsPz/fe L/TTuzsE3QZCs+j/tmjg3X/1XO7a4zr9v5Pvd64gJJXfjJyhzZ9XeC5/vOIR9ezV2rmCAMRU xXvv6fT+/X5vb9CypZr37RvrMrKYkx6hcOedB7r/6CFTw5rRndMhL+TnD7fOQOE6ku3ZcdP+ GvJvGxNy/3s49QCQSlfukCTl9Li2RvcBgNqEkA4AFgtml2r6pA/93l40eQhh0o/SlTtUNNa3 vaxj5+ae1yyU+wBAbUdIB4DvTX1xiRbP/dxz2RrGjXBpDZgL1z4VtxrdLqfHtVq49im/QTzU +wBAbceBo4CLXbhwQZs3b3a6DEds3rxZFy5ciNvzDbx5oldAX7j2KZ9VXSNc9ivo4rmuY+fm casxkeT0uDboaxPKfQCgtiKkAy5z4MABzZo1S4MGDVLbtm115MgRp0tyxJEjR9S2bVsNGjRI s2bN0oEDB2L2XANvnuh1edq8UQHvP/rZPNeGy6kvLtHAmyfqqRGznC4FAFADtLsADquqqtKa NWs0d+5czZ07Vzt37lRVVZXq1aunpUuXKjc3N/hGklBubq5mzZqlvn376r333lNqaqpat26t goICFRQU6Mc//rFSU2u+zjD1Re+Rmf0Kuigru3HQxw19qIeKxs5R2ca9Na4hmszfBgAAEhch HXDAgQP79PrrizV79mytX79edevW1enTp1VdXa2UlBRddtll+uijj9S1a1enS3VUz549tXLl SvXp00fHjx/Xtm3b9Morr2jKlCk6d+6cbrrpJhUWFuryxjdGtP19FYd9Qm3Bg7eE9FhzK8y+ isMhBftYs37gAAAkLkI6EAfV1edVrZ2qVqmqtUsjH3pFqampOnfunCR5/jclJUUZGRl65pln tHXrVm3dujXQZmuNZ599VhMmTFBlZaWqq6t16tQpSdJnn32m9evXq6qqSheUphS1VIpyVF19 TUjbXfPJDp/rwgnb/g4Y3VdxWA8Pnm57W6DJME+NmOVZmS+aPER7yg/7TJnp2Lm5JhY/4HWd 9YBXSSrbuNerjWfg0K5a+M4623rsDt4071uk+xNN/mqwvh7+DkYNZT8BwE0I6UAMHT10QH+b 9p9a/9lbqtJJz/UXLsj2oMjq6mqdPn1azzzzTDzLTGjGBxzpgqq1VdXaqg1rFuqPL5Xqvoef U8PLm/p9bMXXB70uR6PP3By0zQHSCNJGUDTCob9xj8b9Ro27Q/mFOZ7tGuHbHC5HP5un0c/m +X1u6WLIHTgsR2s+2eH1fMbzTJs3yisEl67coZwe14a9P7Fg/hBivB5GGDdej2nzRikru7Ga ZzfWtHmjwt5PAHAbQjoQQw0vb6pR4ydpR9ll2rJphaq1UdIZ1a1bV+fPn5P1hL9Gq8sdd9yh unXrOlO0C507d04ffvihjh8/bvuapaXV/T6spytFndWm/a0aNb5IaWmBX8Pybd4Ho7Zq6z/Q hyJQSB79bJ7Ktx3w3G4E7fzCHK8QbrA+/tcT7vYKlwtmlyq/MCfk2oxvCH7c61qv8Gp+no6d m6ts417PvPJI9ifazAG9X0EXzz7n9LhWo8bd4dmXhwdP18K1T0W0nwDgRoR0IMbS0uoqs9H1 SlVdSbdLOqXx467Rtu0rtWjRIkkXQ+iZM2c8K+lffPGFSkpKdMUVVzhauxt89913ys3N9fTs S1J6errnQ0z//v3Vtm1PTfztDkmXSJIyG14XNKBHW+nKHV4hu9edHX3uYxxsajAHbett1sdb 23Cs3wKEyrod8wcTa9tITfYnGkpX7vBq48ntc53X7dYgbl4VD3U/AcCtGMEIxN0l6tWrn959 910dPHhQ8+bN0+jRo3XNNdeofv36yszM1Pbt29WrVy8dPXrU6WIddfToUfXq1Uvbt29XZmam 6tevr2uuuUajR4/WvHnzdPDgQb377ru6tVc/GQG9Jqwr6+EoWeZ9/MCPe/mu0Da3BMdPPijz u72rW/n2xsdz7GO09ycaNVifz2pP+eGoPj8AOImVdMBB6enp6tu3r/r27atJkyapvLxcixYt 0ty5c7V8+XLdeeedWrp0qTIzM50uNe6OHTumO++8U19//bX69u2rgoIC9e/fX61atXK6NFs1 CfhufL54708oNfg7eNUQ6bcLAOBGhHTARVq1aqVHH31Ujz76qM6cOaMVK1Zo6dKlKigocLq0 uFu6dKlefPFF3XrrrUpPT4/Jc7Rq29SrpSPcmefGQZ9Fk4f4PNZuSoz1OrfNWDdzw/5Yt8ck FgC1Ce0ugEsZq+y1MaBLUkFBgfr27RuzgC759jhLF/uaQ2Vu77C2ouyr8G29sF7n1rOWSu7Y n1BqAIBkRUgHUGvZTfZ45y8rQ3rsvorDnpXe5tmNI5oMU9NpMrHkhv2xbm8vIR1ALUJIB1Cr FU0e4nW5bOPekFbT5878zOuydVXe7kRJ1pBpt5LvFm7YH+v2rAeS95gZxwAAIABJREFUAkAy I6QDqNWMedtmRWPnBGytsI4G3FtxWDk9rvVqz7CbdGJepe9X0MXVM7rdsD/WGhbP/ZyWFwC1 BiEdqKEFy6do4LgMDRyXodLNS5wuBxHIL8zxWVF/ePB0TX3R9+c59cUltqeXl7znb5dt3Kun Rszyepz5xECjn83zeqx1fKC17cbcXmNs38o8y9z8jcCC2aVaMLtUkm/P/eK5n/v95qAm+2Ot 0d9BpcHuM7H4Aa+g/vDg6T71Tn1xiQbePNHr5xXOfgKAGzHdJUQDx2XUeBujBr2q/NvGRKGa 5JGIr+uC5VM0ff5429v27N+qnA6+YQXul9PjWi1c+5T2VRz2jPpbPPdzrxVzg3FqemO6y57y w8rpcfG2hWuf8lxvnLLezDh9vcG4r5Xx2H4FXTy1WA28eaLXmTTzC3NU8fVBz33NHya6dr/G 9nnM9zP2yyzc/TG/fnb1SlLR5J+raOz/BLyPebsTix/w2q7dh6SiyUOU0+Nala7c4fdDVKD9 BAC3IaSHaOGkSkn+A1rRqPm24WzqnNFavGpGzOtLVMbr6u91mvbMJmU1aeNzvZOva/5tY5R/ 2xiVbl6ioumDHKkBsZOV3TjkUX/5hTm2Yc/f9eFsw8pupdrf/UK9b6jC2Z9QX79wxymGul3j wxYAJDraXcKUf9sYdWyd63O9v9XT0UOmxrqkpODvdbIL6IHuH085HfLUr/tIp8sAAABJiJAe gV5dhgS/k0kyBzmjF3vqnNE13la4r5MbXtfsZh2D3wkAACBMhPQ4SNYgt+/gdkefP1lfVwAA AHrS48DoYU42a/61KKrbCzd0J+vrCgAAwEo6IlK6eYnfCSexsu/gdk97DQAAQDJjJT1GjCBp nk4SaBrItGc26XezR6psZ4nX9f26j/Q5SDLQduzub2adTrNwUqXfiTV2ow39PffiVTO8pq10 bJ2rib9a5reOSOw9uM2z7UBquo92mOQCAADiiZAeA/56tXM65GnhpErtO7hdD/+2k9dtxuVp z2zyum3xqhme0G0NiuZAbtxmhGVz+Aw019v4MGHc3/wc0+ePV8X+Mq/Qb+xDoFpiYd/B7QFD cjT30fq85p+HedRmoOcEAACoCdpdYuB3s3+YOmI3QjCrSRufySQdW+dq4aRKn9uM/x8sFOd0 yNOoQa96Lk+fP14Llk+RdLF3e+GkSq/bzRZOqvQEeutYwcWrZjh6Fk2jvcUclFtldfK5Xyz2 MVBAN57T3/MBAADUBCE9SowwOXBchk/Lih3rQZLm4Dl6yFQtnFSphZMqPUHcuopc0OcJn21a 2zamzx/vtapv19ZRNGq+z3W5N+R7XS75coG/3Yg543UwTnokSeX7Nvm9fzT30RzQO7bO5Uyi AAAgbgjpUWIOk8F6pu0EmmxiXeXt2DrX70l+rCv0c5e9FvB5mzdpG2KFzrML26GIZB+NbyEM dqv3AAAAsUJIj4FfF/5wAGU0ZolbV3kDBUZr2A+06iz5P6NnONuIFyNsh/JNhVkk+1ixv8zr MjPZAQBAPHHgaAyEEgprg2ATUcKdAJPVpI1X20ssueWDCQAAqJ0I6TESzTCZqIFxz/6tAW93 cwtJuKv1AAAA0URITwCtsjpFHBqdDMKJfEbQjq1zCeoAAMAx9KQnAOskkkAr67Wtl7p08xIN HJehp37fJ6rbtX64sb6uAAAAsURITwDW0X9lO0v8HpBqPuunZD+S0K0iCcLGQbXR/sbA+sHI +roCAADEEiE9AnZhMtYn/LGOH7QbrWgdGxjKyMJIp89YxxpGo2/ebhuB6tt3cHtI4TmSfczp kOczStP6+kq+7wVW3AEAQDQQ0sNUunmJbTAsmj4o5DC47+B2n9PJT58/PmDQz+mQ5xW6F6+a oalzRnsuW09Rbz07pvG8VuazoxqsIx/tVu6zmrTxCrFlO0s89S9YPkUDx2XYhlp/ps4ZbdsD bj6hkNmC5VO8bjPaeqK5j9bJM9af0cBxGT7vBVbcAQBANHDgaIie+n2foAcSmkPjtGc2+Yxi DDaS0LjN32jCnA55WjipUlPnjNbiVTM8/3ltwyacB3resp0lGjguQ/26j1TuDfl+72fsm3lq zcRfLfN6XcyP7dd9ZEitNqG8rgPHZQTdTunmJT4ffAw12ceFkyq9PgAF+vlZ67V7DwAAAISC kB6icOZ5+2OE7JoaPWSqRg+ZGpPnDbe+mr4u0XhdwxXuPibylBoAAJCYaHcBAAAAXIaQDgAA ALgMIR0AAABwGUI6AAAA4DKEdAAAAMBlCOkAAACAyxDSAQAAAJchpAMAAAAuQ0gHAAAAXIaQ DgAAALgMIR0AAABwGUI6AAAA4DKEdAAAAMBlCOkAAACAyxDSAQAAAJchpAMAAAAuk+Z0AW51 /OhprfzwX06XgSRx+LsTTpdQqxz+7gS/vwjLt3s3K6N+QzVsnOVz24mjpx2oCEBtR0j3Y0/5 QU18+l2nywAQga+37OP3F2E6owv6L0l1laquSlF7SRlOFwWgFqPdBQAApStVgyUdVJUW64Le UJX+pmptl1TldHEAaiFW0gEAkJSipkrV3arSAklStXapWnslpShFbZSiG5Wi1o7WCKD2IKR/ 74oml6jgnhucLgO1RFZWptMlJJWsrMv4/UWU3KDSdcf19c6PVV1dJen8xatTtii1zk6lpqZp RvFRXXnVE2rbtq2jlQJIbinV1dXVThcRTNW5c9o2c2bA+zTLzVWj66+PU0UAgGR1/vx59ezZ U+vWrdP58+d9bk9PT1dKSoqys7P1y1/+Ug888ICaNGniQKUAYqHivfd0ev9+v7c3aNlSzfv2 jXUZWfSkAwBgkpaWpnnz5qlBgwa2t585c0ZVVVXasWOHfv3rX6tNmzZ64YUXdOrUqThXCiCZ 0e4CAIBF8+bN9Y9//EM//elPfcJ3VlaWfvGLX+jGG29U+/bt1b59e9WvX9+hSgEkK1bSAQCw 0bt3b7344ou69NJLJUkpKSmqV6+e9u3bp7feektZWVm68cYbCegAYoKQDgCAH4899pjuvvtu XXLJJaqurlb37t110003qaKiQrfffruKiop04cIFp8sEkIQI6QAABPDXv/5VLVq0UGpqqnbt 2qVVq1Zp7Nixqqqq0oQJE3THHXdo9+7dTpcJIMkQ0gEACKB+/fr6xz/+ofT0dO3Zs0f16tXT G2+8ocWLF+uqq67Sxx9/rBtvvFELFixwulQASYSQDgBAEB07dtRf//pXnTt3Trt27ZIk3XXX XdqwYYPy8vL03XffadCgQRo+fDhTXgBEBSEdAIAQ3HvvvXriiSe0ZcsWz3VXXnmlFi1apNdf f11169bVzJkzdcstt+jLL790sFIAyYCQDgBAiF566SWfExelpKToscce0yeffKJrr71WmzZt 0i233KI33njDoSoBJANCOgAAIUpLS1PXrl1tb7vlllu0fv16DRs2TKdPn9bjjz+uIUOG6PDh w3GuEkAyIKQDABAlmZmZmj17tv7rv/5Ll156qf7+97/rpptu0sqVK50uDUCCIaQDABBlw4cP 15o1a9SlSxeVl5erd+/eKioqUlVVldOlAUgQaU4XEC1njx7Vqb17nS4DAABJUquGDfXRvHl6 4YUXNGPGDL0xYYLWLl2q3//+97ryyiudLg+AHxfOnnW6BElSSnV1dbXTRQRTde6cts2c6XQZ AABEZP369XrzzTd18uRJXXbZZRoxYoQ6d+7sdFkAItCgZUs179s31k+TRbsLAAAxdtNNN6mo qEjt2rXT8ePHNXnyZM2ePVvnz593ujQALkVIBwAgDi6//HI9+eSTys/PV0pKipYuXarf/va3 2r9/v9OlAXAhQjoAAHGSmpqqQYMGafz48WrcuLF27typCRMmaNWqVU6XBsBlEqInXZIOf/GF DqxZ43QZAABExYkTJ/Tmm29qw4YNkqTu3bvrwQcfVHp6usOVAfCnTnq6WvTvr/TLL4/1U2Ul TEiXCOoAgOSzcuVKzZw5U2fPntVVV12lRx55RC1btnS6LAAWddLT1aJfP6VfcUU8ni6xQrok fbd+vb5bv97pMgAAiJq9e/fqz3/+s3bv3q20tDT9/Oc/1x133KGUlBSnSwOguAd0KRFDukRQ BwAkn7Nnz+rvf/+7li5dKknq1KmTHnroIWVmZjpcGVC7ORDQpUQN6ZJ05tAhVXPmNgBAknnv vff061//WkeOHFHTpk01depU/eQnP3G6LKDWqpORoboNGsT7aRM3pAMAkKzKy8t1//3369NP P1VKSop+9atf6dVXX1XdunWdLg1AfHAyIwAA3KZVq1ZatmyZnn/+eaWkpGjy5Mnq1auXduzY 4XRpAOKElXQAAFzsn//8px588EHt3btXDRs21J/+9CcNGzbM6bIAxBYr6QAAuNntt9+uDRs2 6O6779bRo0dVWFio4cOH69SpU06XBiCGCOkAALhc06ZNtXDhQr3++uuqV6+eZs6cqZtvvlkb N250ujQAMUJIBwAgAaSkpOixxx7TypUrdd1116msrEzdunXTG2+84XRpAGKAkA4AQALJyclR aWmpHnzwQVVWVurxxx9XQUGBDh065HRpAKKIA0cBAEhQ//3f/63Ro0frxIkTatmypd566y31 6tXL6bIA1BwHjgIAkKiGDx+uL774Qrm5udq1a5d+8v+3d/fBVtX3/eg/PIhQlSeVnxgPgqjE EFETbJDw82J9wLQ+TAi/NGZifp1DE5uQ0Vad9NZ7O+rcOzZN1UkYmP7aW2kbM5FUgpeE6gWp wxikUqkPdE4iUYoCCkUjD4ZH5XD/IPtk77X3Pmefc/be63vOeb1mnJy99zrf9dmLNTnv/d3f 9VlXXRX33XdfHDt2LO/SgF4S0gGgD5s4cWI8++yzce+990Z7e3vcf//9ce2118Zbb72Vd2lA L1juAgD9xJo1a+LWW2+NXbt2xRlnnBF///d/HzfccEPeZQHdZ7kLAPQX11xzTbzyyitx/fXX x7vvvhs33XRT3HHHHXHkyJG8SwO6SUgHgH5k3Lhx8eSTT8Z3vvOdOOmkk2LhwoUxc+bM+MUv fpF3aUA3COkA0M8UeqqvW7cuJk+eHC+++GJ88pOfjL/927/NuzSgRkI6APRTl19+ebz44ovx xS9+MX71q1/FbbfdFp///Odj7969eZcGdMGFowAwAHzve9+Lr3/963HgwIGYOHFi/OAHP4gr rrgi77KAylw4CgADwZe//OXYuHFjXHrppfHGG2/ElVdeGffdd1+0t7fnXRpQgZAOAAPERz/6 0fjXf/3XuP322+PYsWNx//33x5w5c2Lnzp15lwZkWO4CAAPQihUrYv78+fHLX/4yxo0bF//4 j/8Y119/fd5lASdY7gIAA9HNN98cL7/8clx55ZWxe/fu+N3f/d2444474ujRo3mXBoTlLgAw YJ1zzjnxzDPPxLe+9a0YOnRoLFy4MGbNmhVbtmzJuzQY8Cx3AQBiw4YNccstt8TWrVtj5MiR 8dd//dfxxS9+Me+yYKAaL6QDABERsW/fvrjtttvihz/8YURE3HrrrXHvw/fGgUEHcq4Mmm/I oCFx0ZiLYvCgXBaeCOkAQKnvfe978bWvfS0OnnIwxs8aH1+97asxYcKEvMuCpvvIKR+Ja1qu iSGDhjR710I6AFBu1Yur4ivf+kps37E9TjrppJg3b15cffXVMWjQoLxLg6bKKagL6QBAqdf3 vR4/ffuncfSDo7Fs2bJYs2ZNRERcdtll8Qd/8Adx6qmn5lwhNNdHTv1IXHNOU4O6kA4A/Mae I3tixdYV0X78N3ciffHFF+Mf/uEf4sCBAzF27Nj4yle+EhdeeGGOVULzfWzsx2LGf5vRrN3p kw4A/MaRY0dKAnpExCc+8Ym477774oILLoj33nsv/uqv/ipWrFgR7e3tVUaB/ufQh4eauj8h HQDo0tixY+Ob3/xm3HTTTRER8eMf/zgefPDB2LNnT86VQf8kpAMANRk8eHDcfPPNcdddd8WY MWNi8+bN8ed//ufxwgsv5F0a9DtD8y4AAOg7zht5Xlx/3fXx5elfjj/5kz+JNWvWxP/69/8V 7857N771rW/FiBEj8i4ReuTwscOx9q21eZfRQUgHAGp26kmnxtmnnB1nn3J2rH58dSxcuDD+ 9E//NJY9six+/vzP47HHHouLL7447zKh2w5+eDDvEkpY7gIA9MigQYPijjvuiH//93+Pj3/8 49HW1haf+tSn4rvf/W7F7X/+85/H/v37m1wl9E1COgDQK1OnTo1/+7d/i9tvvz0OHToUf/zH fxzz5s0ru6h0yJAh0draGro/Q9eEdACg10aMGBHf/e534/HHH4/Ro0fHj370o7jsssviueee 69jmvPPOixUrVsS3v/3tHCuFvkFIBwDqZt68efHSSy/FFVdcEW+++WbMnj077rvvvmhvb4+h Q4fGWWedFffcc0+sXbs271IhaUI6AFBXEydOjGeffTbuvffeaG9vj/vvvz+uvfbaePvtt+Oi iy6K9vb2uPnmm2Pr1q15lwrJEtIBgLobOnRo3HfffbF69eoYP358PPPMM3HppZfG6NGjY/Dg wXHw4MG4/vrr49Ch5t7FEfoKIR0AaJirr746Xn755fjMZz4T77zzTixbtiyGDh0aH374YezY sSNuu+22vEuEJAnpAEBDHD16NH72s5/FunXrYtasWXHZZZd1PB8RcfDgwVi+fHk8+uijeZYJ SXIzIwCgro4ePRqPPPJI3HfffbF79+4YPHhwnHTSSXHkyJGybQ8cOBB/9Ed/FJdccklMmzYt h2ohTWbSAYC6GjZsWHzta1+LnTt3xk9/+tO45ZZbYsiQITFy5MiK2x88eDCuvvrqePfdd5tc KaTLTDoA0BCDBw+OWbNmxaxZs+LQoUOxdOmP4k+/+UC8t2dLREQcO3a0Y9t33/1lXHD+J+Pq 3/m/YtAgc4j03h9+5bdjzvUX5l1GjwnpAEDDjRgxIq677qb4SmtbRLwfx+PViHgxIt6PiA8j 4njs3bctlj/xnRgcc3Ktlf7hqt+ZnHcJvSKkAwBNdloMistjSFwex2N7HI+X43j8PCLi1z9f GINiUs41Qr6EdAAgN4OiJQZFS0R8Jo7Ha3E8Xor2WBlD4n9GROU17DAQCOkAQC5OG/lb8fX/ 84ay5w/86r3Y88vtcc65l+RQFX3V0//vi/Hi+tfzLqNuhHQAIBcnnTwkrvidj+VdBv3Ephe2 5l1CXbl8GgAAEiOkAwBAYoR0AABIjJAOAACJEdIBACAxQjoAACRGSAcAgMQI6QAAkBghHQAA EiOkAwBAYoR0AABIjJAOAACJEdIBACAxQjoAACRGSAcAgMQI6QAAkBghHQAAEiOkAwBAYoR0 AABIjJAOAACJEdIBACAxQjoAACRGSAcAgMQI6QAAkBghHQAAEiOkAwBAYoR0AABIjJAOAACJ EdIBACAxQjoAACRGSAcAgMQI6QAAkBghHQAAEiOkAwBAYoR0AABIjJAOAACJGZp3AQAA/dUb 61fF8ttvrvja7LsejE/c8o0mV0RfIaQDAEl5ePrwXo+RSgAe3XJ+3iXQRwnpAEBS7tx4OCIi 1jywIDYtf6Ts9dYn2mJ0y+Sy56ttn6fRLZM73s/S1tnx9qbn8y2IPsOadAAgSdfcs7ji85UC emfbp+LCa+flXQJ9iJAOACRr2tz5Dd2erj08fXg8PH14rHlgQd6lDChCOgDQb4yddFHeJfQr e7dvybuEAcuadAAgWd0N3Z+45RtJXDDaX/znuqfyLmHAMpMOAPRZe7dv6ViOQX29sX5VrH3o 7rzLGLDMpAMAfdbe7a9HRMTZ02ZUfL2r8H72tBnxhSVrO+1nPm3u/I6LUl98bFHV4Nqbto+d jVvoDtPZdoX30d2xK9Vc7VhsWv5ISfecavus9VjWsn3rE23x/907v6wrTqVx+hsz6QBAn7R3 +5aq4a7gzo2HY+7CFVVfK4TMiTPnxJ0bD5ddeHrnxsNxzT2L4431q+Lh6cM7wu6dGw/HnRsP R+sTbR3brn3o7h7P6H/ilm/EnRsPx+y7Hqxpu1oukO1pzYVjkT1u0+bO7xij+Nhl91f4Nyne vjDWpuWPxMPTh8eLjy0q219xXQVLPjs13t70fNlrqbXabAQhHQDoUwrLW5Z8dmrHc2ecP7Xq 9hNnzikLtdVCbvEa+OJgWPxhoDi8jm6ZXBZme9MFpdaZ+Om33tnlNs2qOaJ8Njw70z1x5pyS DyBrH7q7JKgX6sr+u5w9bUbcufFw2WsDoYuPkA4A9CnFs7kF775ePgtbLBtqq83E/uLpZRFx IgQW+rG/sX5VyTbP/91flDyeOHNOTWM3U7Nrzn6jUelDRPYDyNqH7i7rHpO9ULj4w9c19yzu +Hfv70tdIoR0AKAPq7aUJavSLG12Jnfv9i0da5+LQ2Y20PaFmxI1s+bsB4Kzp82oesOp7L/B xkcf7nTsgdxS04WjAECfNbrl/IiIsgsLK5l+650lM8ZrH7q7ZHa30G6wUsgsnrXvK5pV8+tr f1zyuLOlR9nQ3dU3IAOZkA4A9FmjWybXHEZHt0yOs6fNKAn0b6xf1THrXLjAcsYf/lmn4yxt nV3Th4KU9MWaBzrLXQCAASMbwAtrtQtLNs6eNqNsqUhEaT/24rDb+kRbsrPszarZbHhjCOkA wIAxceackp7qb296Pt5Yv6ojrFeaRd+7fUtJJ5mIE2vhC11HUtTMmjtb3tLI3+3vhHQAoF8p 9Ote2jq74uvZIL789ps7ZporzaJnL26cNnd+xe3qJXtjpmwHlFo0s+bzZ99U8rizmfX3tv68 5PFAvjC0K0I6AJCsbKirReFCxmqztNnZ9IJqNxLKhs4Ug2V2vXkza86G/7c3PV/1g0W21WNP 79A6EAjpAECyKs3KdjazvHf7lpp6flda1lItMPZkSUZPZr8Lsu0S925/vdv7rEfNhc45BZ3N kGdbYVZqrZhteVlr+8yBSkgHAJK05oEFFTuSZNdaF7z42KKS1zqbPc7OplebRY8ovzFP8U14 CktrsioF68KNkqo9Lsh+WMjeKGhp6+yKx2DJZ6fGw9OHxxvrV9Wl5kI3nILC+v2IE8f64enD O4L3xJlzSkL3puWPlNzF9MXHFnV0z4k4EdCzM/B7t28p2aZQd7YP+0Ax6Pjx48fzLgIASMOu g7viyTefrPr6tNOnxfRx03s09ltv7Y9zz/nNnS/HnnlaLHnqrrLt6tUucPZdD3a6nKL4VvZd dTupdCFmwbS58+Oaexb3qu5K++9svNYn2qrW0/pEW4xumdzjms+eNiO+sGRtl3UUxsha88CC qt9mVArnxf8OncnWlfU3f/nP8dTjL3Q8Xrjopvj6giu6HLfg4IcHY+lrS6u+PmnkpLjqI1fV PF4vjRfSAYAOKYR06In+FtItdwEAgMQI6QAAkBghHQAAEiOkAwBAYoR0AABIjJAOAACJEdIB ACAxQjoAACRGSAcAgMQI6QAAkBghHQAAEiOkAwBAYoR0AABIjJAOAACJEdIBACAxQjoAACRG SAcAgMQI6QAAkBghHQAAEiOkAwBAYoR0AABIjJAOAACJEdIBACAxQjoAACRGSAcAgMQI6QAA kBghHQAAEiOkAwBAYoR0AABIjJAOAACJEdIBACAxQjoAACRGSAcAgMQI6QAAkBghHQAAEiOk AwAk7P397+VdAjkQ0gEAErb0/3kg2tuP5V0GTTY07wIAgIHpV/sPx0P3/CjvMhJ3PNavfTR2 /Oe4GDlqct7FJG3Lq2/nXUJdCekAQC6OHvkgfrr6P/IuI2nHY1e0x754acNTMTj+t7zLoYks dwEASNTxePnX/7sp50poNiEdACBRx+M/f/3TwV//x0BhuQsA0BRjx46I7//gC3mX0Wf86lf7 4o++9mAcOxYxZMiQuO2r4+K///cb8i6rz/jk9I/kXUKvCOkAQFOMGHFSfOGWS/Iuo8/44Q9/ GMOGnRSHDn0Yx459GNt3bIgv3PJ/5F0WTWK5CwBAgpYtWxaHDh3qePzMM8/EsWNaMQ4UQjoA QGKOHz8eTz/9dMlzQ4YMiRdeeCGnimg2IR0AIDEvvfRStLe3lzx36NCh+MlPfpJTRTSbkA4A kJgnn3wyjhw5UvLcBx98EMuXL8+pIppNSAcASMzjjz8eR48e7Xg8aNCgiIjYunVrvPvuu3mV RRMJ6QAACdm7d2+8+uqrERFx8sknR0TEKaecEsOGDYuTTjopVq9enWd5NImQDgCQkDVr1kR7 e3uccsop8c1vfjMiIq655pqYMGFCHDx4MP7pn/4p5wppBiEdACAhjz/+eAwePDhWrlwZH/vY xyLixIz6+vXr47zzzotnnnmm7KJS+h8hHQAgEcePH4+NGzfGqlWrYvbs2SWvnXnmmbF+/fqY MGFCbNy4MZ8CaRohHQAgEa+99lo8+uijZQG94Mwzz4x169bFrl27mlsYTTc07wIAADjhggsu iAsvvLDTbUaPHh033nhjkyoiL2bSAQASUWi1WK/t6LuEdAAASIyQDgAAiRHSAQAgMUI6AAAk RkgHAIDEaMFIctr2tMWG3Ruqvj5v0rwYOWxkEyuq7Lldz8XmfZsjImLciHFxw4QberQN+Vmy eUlElP/bFP+79cSnxn0qpo6Z2uv6ABi4hHSSsP/o/li2dVlN2xa2E4Ty07anLba+v7VPf+jY f3R/x89jho2p69gbdm+IDbs3xJRRU+LTZ326rmMDMDBY7kLuntv1XM0BvdiG3Rs6ZkJpjv1H 98eSzUs6/aajr9h+YHvHz+eedm5D9rF532bnKAA9IqSTqyWbl/RqWUFhDJrj2V3P5l1C3Wx9 f2vHz+ecck5D9/XcrucaOj4A/Y/lLuRm5baVVV9rndJa8fkdB3bE6h2rK47Vl5de0Hy7D+2O iBPr0TvT3WsJKp2jm/dtjnNPO7fhHwYA6D/MpJOL53Y91xG6idHAAAAeD0lEQVSSCsaNGBet U1qrBvSIEzOerVNa41PjPlXy/O5Du6NtT1tDaqX/2XFgR8fPk06bVNexC+do1pvvv1nX/QDQ vwnpNN3+o/vLlrhMGTWlW7OVU8dMLQvq/WGdNM1RHJhbTmlpyD6uO+e6kse9XdYFwMAipNN0 //Hef5Q8HjdiXI86YEwdMzWmjJpS8lzxDClUs+fono6fG9XO85xTzilbSlPcUQYAOmNNOk2X nVG88qwrezzWxWMvLhnvzfff7HLdb2d92FPpwV5t7X3EiRnanq5trvbeO2tnWe13dh/aXXLR bld11eO4Fx+X4vaGlS4erjbm/qP7O5ZaZT/k1duYYWPKlnUV1OO9FDTqnO7J+dKZep/Xnb3v FMarZdxmnvtA3yKk01TZme5xI8b16o/JyGEjO13DXqyrmyRF/KYHe2/+IPdGZyGmoPB6d2rs 6uY8hb7ejXjfjTzu3emvX9CM1osFxTP2XenJe2nUsa33+VLv87qW910Yr5YPFPUerzvjNvPc B/oWy11oquzFc/W+aK+aldtWdmvN+uodq5t+IWrbnrYug0yx1TtW19Tab+W2lTWvh169Y3Vd lww1+rhXCymdffhrZuvF7Cx6Zx9Iu/teGnVs632+1Pu8riX4Ftuwe0On77ve4xWkeO4DfYuZ dJoqO7PYqIv2iq3ctrIsLFWatcrOHm7YvSFGDRvVlBn1SkGh0oxddkZy877NMfrk0VVn9ip1 0cm+9+y+V+9YXfLtxNQxUzvGLz6WXbUmbPRxL/6d4nF3HNgR+47uq/p7tbZe7K1K3xpV0933 0qhjW4/zpVi9z+v9R/eXjVdpaUd2vxt2b4iWU1rKtqv3eAWpnvtA32ImnVw1esZnx4EdJX8s C20eK/0R/PRZn455k+aVPNedGcCeygaFQo2VgnehvV/xWuoNuzdUvCCxUhedSu996pipZZ1I evstQjOPezb8nHPKOVU/tDSy9WKx/Uf3l72HWvZXy3tp1LGt9/nSiPO6eKlSRPW115VqzP5u I8aLSPfcB/oeIZ2mqnYRXaO8/MuXSx531eZx5LCRdQ+sXcl2u6mlFWW2G06tAaSabCeS4iUh PdGs4z5uxLhufdPRjNaLK7etrLgUoav91fpeGnVs632+NOK83ntkb8fPXS3ryNZY/LuNGi8i 3XMf6Hssd6HfKu7iERFlfdWrKfwxLvzu1ve3NnR2qnj2stYaC9sWZior1VgcnKaMmtLltxaT TpvU8Z53H9od+4/u79E3Hc087t2dDe9J68VsF5ue+NS4T9V0/LvSyGNb7/OlUed1QS3naHfu vVCP8VI+94G+R0in38rOwnVn5rRegbUr2a/zu1PjqGGjOn7O1pgNC6NPHt3leMVrz3ujmce9 +Bh0pZmtF4tNGTWlpuNay3tp1LGt9/nSqPP63NPOLQn/y7YuK2lH2F31Hi/Vcx/om4R0mqp4 tigiGhZ+I8q/ju7OfrJ/APd/0KCQ/kFpmOlNS7XiGrPjNvMPeqrHvZmtFwvq3dKyUce23udL o87r7IxzxIkZ++Kg3Z0e4fUeL9VzH+ibhHSaqrObuzRSdzt5jDypOX8cm9WJoVnvJ6vRx707 2zez9WKtvfuLdfe9N/LY9vZ8aeR5fcOEGzpdflT8gaCWnub1Hq8gpXMf6JuEdJoq+zX69gPb Y+qw3i2x2H90f+z/YL+LqOhUT1svdtVqkuZrndJaU3/zwk2XugrX9R4PoB6EdJoq+5VuPS7K 3H5ge8kf17zuFloPPZmBpWvNar1IZY04r4vXxNdyh9S9R/Z2uta83uMB9JaQTlNlw3M9LsrM tn+rFNC7u8Qmu6a2WRp2gWpO61tTOe7NaL3YbI08tvU+Xxp57UnEidaNxYG50vKVzfs2x8Vj L66pjnqMl8q5D/Rd+qTTdNnOGs/uerbHY7XtaSv5Y1g8dnZpTaUb/lSTXVPbqPWf2W8Wqt0g pbuy9da6RnjltpWxZPOSWLJ5Sae3Zu9Mise9J60XU9SoY1vv86VR53WtWqe0lt0cqTd11Dpe iuc+0HcJ6TTdxWMvLnm8+9DuHgXCSrf0Lh47O2PanT/Q2dn5RgW77Kx/b28iVJCtt9qNV4r1 pA1fJakd97xaLzZCo45tvc+XRp3XhQ8ESzYvqemGP9nlKNn3Ve/xUjv3gb5NSKfpRg4bWRaW Nu/b3K0bxrTtaStr65a9AcvIYSNLLhLs6qKwguxtvRsd7IrH331od8n66c607WkrCRnZWbvi cTfv29zlrF5vejwXS+2459F6sVEaeWzrfb404rzu7V1xsx886z1eauc+0LcJ6eSi2gVX1QJn QeEPeKU/fpXGvPT0S8vG78yOAzti9Y7VJc9lZ/7rLTv+6h2ruww0Ow7sKDkGle4QmR23s2VF 2W8larnjZGdSOu7Fs539YQlBo45tvc+XRpzXxRf97j60u8vZ7+zr2WU49R4vIq1zH+jbhHRy 01nHh2Vbl5XMphX+qzYzNW/SvIrPF25WUmzJ5iUVw8Jzu54r+2NZy+3ce2vksJFltw9fvWN1 rNy2suL2K7etLKuz0geU7LiF29tnPwDtOLCj7FuJaiFhzLAxJeNV+zCV0nEvdOkYN2Jcv1hC 0KhjW+/zpRHndbYT1IbdG6qO99yu50r+/2LciHFly3DqPV5EWuc+0Lfp7kKuWqe0dmuZSyVd 3RHwhgk3xMptK0u+Ts7+Yaykmb2Qp46ZGnuP7C1p+1YISV2p9gGl2rhd3f3xunOuq3o8s1/v F4+VbX2ZwnHvr60XG3Vs632+NOK8njdpXklNtY535VlXNmW8iDTOfaDvM5NO7lqntJbNuNVi yqgp0TqltaZZpxsm3NCtdZ7zJs1r+h/LT5/16W4fh1ref3fG7arHfGfHpFJHkLyPe39svVjQ qGNbz/Olu+MVdHZejxw2stMPpnmPV5D3uQ/0fWbSSULxjUSyM1BZPb1ZUaH3cWd3FuxqVr7R Cseh0jrVgp7cAbMwbrWbtHRnBq91SmvFcap1BMnzuPeX1ovVNOrY1vN8KR6vXuf1yGEjo3VK a+w/ur/qTH+e4xX0hf/PAdI16Pjx48fzLgIASMOug7viyTefrPr6tNOnxfRx05tY0cC2dOnS uOWWW+L3f//3Y+nSpXmX068d/PBgLH2t+jGeNHJSXPWRq5pVznjLXQAAIDFCOgAAJEZIBwCA xAjpAACQGCEdAAASI6QDAEBihHQAgES8+uqr8fTTT3e6zc6dO7VjHACEdACARFx44YXx1a9+ NdauXVvx9XfeeSfmzJkTLS396y7KlHPHUQCARAwePDg++clPxpw5c2LVqlUlr73zzjsxY8aM +K//+q+YMWNGThXSLGbSAQAS8rnPfS7a29vj937v9+JnP/tZREQcOXIkZsyYEVu3bo2rrroq hgwZknOVNJqZdACAhFx33XUxZMiQOHjwYHz729+OiIg1a9bEkSNH4tRTT4158+blXCHNYCYd ACAhp59+ekyePDkiTsygR0QcPHgwPvjgg/jggw9izpw5eZZHkwjpAACJmTdvXpx88skdj9vb 2yMioqWlJc4666y8yqKJhHQAgMTcfPPNMWzYsJLnhg0bFp///OdzqohmE9IBABJz2WWXlV0c Onz48LjhhhtyqohmE9IBABIzaNCguPbaa2PQoEEdz7W3t8fll1+eY1U0k5AOAJCgz33uczF8 +PCOx1ovDixaMAIATXH48Ifx1JOb8y6jzzh6ZEIcPfpBREQMGTI0zps0M55Y3pZzVX3HJZeO j/POG5t3GT0mpAMATfHLXx6M//G57+ddRp9yLH4rIvbHsWPHYtHCXbFooeNXq4WLboqvL7gi 7zJ6zHIXAIBEDYqJv/5pxK//Y6AQ0gEAEjUoPvHr/70050poNstdAIBcDBs2ND7x6QvyLiNt xz8aG55bFhdd/DsxcpRj1Zk3frErdr21J+8y6kZIBwByceqoEfG//9Xv511G8pZ85+X4g9v/ LAYP1tmlM3/zl/8cTz3+Qt5l1I3lLgAACfsfrd8U0AcgIR0AIGGnjey7bQTpOSEdAAASI6QD AEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiM kA4AAIkR0gEAIDFCOgAAJEZIBwCAxAzNuwAAgFTt274lvv/ZqT363RsXrogJM+fUuSIGCiEd AKCKUS2TY8HGwxERsbx1duzc9HzZNoXXCxZPHx4RET+5/eaIiBg/bUbMXbK2oXXS/1juAgBQ g0pBe/y0GWXPLdh4OBZsPNzx2s5Nz8fi6cPjlccWNbpE+hEhHQCgRlPnzq9527lL1pZsv+6h uxsa1BdPHx6Lpw+PtQ8saNg+aB4hHQCgQWbfs7jkcaOC+r7tW+o+JvkS0gEAGmjWXQ+WPF73 0N11D9VvrHuqruORPyEdAKCBJs76TNlzLz36cN3G37Z+Vax76O66jUcadHcBAGigUS2TY/y0 GSWdYdqWP1K2FCYi4pXHFlUN3LPuejAuueUbHY+3rV/V0UGmWNvyR6Jt+SMdjyt1l+nOfsiH mXQAgAYbe355r/Vt61eV/Lx4+vCO4FzoEPOlJ9o6tln30N0d7R0jIibMnBMLNh6OGxeuKBl3 6tz5Hb+/YOPhkoDek/2QDyEdACAHe958rePn4hnx4tA9qmVyWQjvTfeWZu2H3hPSAQByVDyj HhGx8e/+ouRx9q6lxUtZUtwP9SGkAwDkKBuOJ187r0/vh/pw4SgAQA7GnHtBx88LNh5uyj6b tR96T0gHAGiw915vK3tuVMv5Fbdd3jq7pBNMozRrP/SMkA4A0GCVwvColskdP+/bviW+/9ny DjBfeqItRrVMrlu3lWbth94T0gEAGih7wWZE6V1IKwXnGxeuKFtD3lvN2g/14cJRAIAGynZR iYiSmwVl7z46de78hgTnZu2H+hDSAQB6qKs13dvWryrbJtuPPLtefcyki+pTXEaz9kN9COkA ADWqdAHovu1bKm67b/uWkpsHRZxY+52dva50N9KuFO8zewFqpRrrsR+aS0gHAKjB2gcWVJw5 /5d751fctnj99/hpM2LBxsMlF4sWXHbrnSWP1z10d0c43rZ+VcWLOfdtf73j51Etk2P8tBkd j3duer5jHfwrjy2KxdOHxyuPLer1fmguF44CAHSiq44nOzc9X3WbQteUzoxqmRxfeqKtJNQX /zx17vyYfc/ikpaJhRn68dNmxNwla2PukrUVXy/8fmENfG/3Q/MI6QAAnWjGDYBGtUzucj9d heRaQnQ99kNzWO4CAACJEdIBACAxQjoAACRGSAcAgMQI6QAAkBghHQAAEiOkAwBAYoR0AABI jJAOAACJEdIBACAxQjoAACRGSAcAgMQI6QAAkBghHQAAEiOkAwBAYoR0AABIjJAOAACJGZp3 AQAAfdG29aviJ7ffXPG1WXc9GJfc8o1ubQfFhHQAoE/at31LfP+zUzvdppEheFTL+XXdDooJ 6QBAn7L2gQXRtvyRjsfjp82IuUvWlmzzymOLYt1Dd3f8VzB17vyYfc/iutQxqmVyLNh4OCIi lrfOjp2bnu/VdlDMmnQAoE/Yt31LLJ4+vCSgf+mJtrKAHhFxyS3fiAUbD8f4aTNKnj9v9k0N qW3ytfPquh0I6QBA8iotbblx4YoY1TK509+bu2RtSVDf8+ZrDamvv1k8fXgsnj481j6wIO9S BiwhHQBIXjagT507PybMnFPT7159/yNdb0SHfdu35F0CIaQDAIl75bFFZc9dduudNf/+qJbJ MXXu/IiI2LP153Wrq796Y91TeZdACOkAQOKKL/yMOHGhaFfLXLIKa9Hfe72tbnX1R9vWryo7 3uRDdxcAIFnb1q8qe27s+Z23Xaxkwsw5HR1Wqu2nWi/zenaE6a7O6urs/RR01qay+H1V20/b 8ke67KTT3WPX2fZfeqIt/uXe+WUdcPL8N8iLmXQAIFmVLvQcM+miuo2/bf2qWDx9eEdonDp3 fizYeDgWbDwcNy5cEREnguri6cMrLrtplEInm0JdNy5cEQs2Ho4vPfGbbwI6u7Cz8PuFgD5+ 2oyO91UYo/C+9m3f0vEhpvCeC4qPx4KNh0sCek+PXWFfxe+l4PufnRo7Nz1f9lrxB4WBQkgH AJLVyDXk2Rnd7GzthJlzYtZdD3Y8XvfQ3U0J6tnZ7xsXrui4SHZUy+SSIN22/JGymratX1Xy +1Pnzi8J16NaJpd0vPmXe+d3u8Z6HLviawUKCh8msq9ltxsIhHQAYEDKLrmodDFq9m6l6x66 u+HdT7KhOdvFZsLMOSUhO7uGvKv3tW/7lpLlJD25uVK9jl32W5HipUyz71ncMTM/0Ja6RAjp AMAAlF3r3tnFqNlZ3JcefbihdRWH5lpnkAvvJztbXel9ZWfSi2e8u7OvzvZR0N1jV8+lTH2d C0cBgAHnP9f+uORxZxejZoNjIzvEZOvKXrjZlezyoGrvq9JdWmuV6rHrb4R0ACBZlWZWtzy9 rGwpRS0WTx8eEbV1RUlFd7uaZEOwmem+y3IXACBZE2d9puy5nqyhzq6FTnVGN9W6ivWFGvsD IR0ASFZ2/XRBpf7pnSncRbMwVk96rRf05ne7O3Z3A3H29xvRHSfVY9ffCOkAQNKm/+GflT23 8e/+oltjbHl6Wcnjwh1ICzoLw9mg28glJNm6uvutQba2RvQXT/XY9TdCOgCQtAkz55R1Cdm5 6fmae5a/8tiisrCbbWu4c9PzVVsrZoNuT9bD1ypbV0T3vjWoVFu9e7uneuz6GyEdAEje7HsW ly17qeXmQtvWryrpI14c1rN316zUHjA7fvZ3GiG7j2xP8u7+fnd6u49qOb/kcbVZ8lSPXX8i pAMAfcLcJWsrBtBC15as5a2zOw24E2bOKbt759oHFnQ8fuWxRSUBv/jOn1nZ5TTZx93ZLltX xInONNkZ9X3bt8Ti6cPLXpswc0586YnScP39z04teW8RJ95f4fcLIT57DcDOTc+X9GBfPH14 vPLYorocu33bt5TdiGndQ3d3+3qD/mrQ8ePHj+ddBACQhl0Hd8WTbz5Z9fVpp0+L6eOm92js t97aH+ee85u15GPPPC2WPHVXj8aKiKrhvFhxC8PC9l96oq3s5jtrH1hQdf12tXC+bf2qmma5 b1y4oqbtKrWGzIbdrPHTZnTa87yrGmfd9WDFJSjLW2dXXA9fqSVkd49drcetq/eW9Td/+c/x 1OMvdDxeuOim+PqCK2r+/YMfHoylry2t+vqkkZPiqo9cVfN4vTReSAcAOvSlkA7F+ltIt9wF AAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBi hHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASMzTvAgCAgemDI8di409/ kXcZ9BPv7NyXdwl1JaQDALl4f//B+L//5Ad5lwFJstwFAAASI6QDAEBiLHcBAJpixIih8bu/ 99G8y2CAmDhxTN4l9IqQDgA0xdixvxU/Xvk/8y4D+gTLXQAAIDFCOgAAJEZIBwCAxAjpAACQ GCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAzNuwAAoO842n403v/g /bzLgLo79OGhvEsoIaQDADV7dc+r8eqeV/MuA/o9y10AACAxQjoAACRGSAcAOgwZNCTvEiBJ g5scm4V0AKDDmSPOjMvHXZ53GZCUM0acETPOmtHUfQrpAECJi0+/WFCHXztj+Bkxp2VOnDzk 5KbuV0gHAMpcfPrF8dv/7bfzLgNydcbwM+L6c69vekCP0IIRAKji42M/HkMGDYn3Dr+XdynQ dIMHDY7Lzrwshg0elsv+Bx0/fvx4LnsGAAAqGW+5CwAAJEZIBwCAxAjpAACQGCEdAAASI6QD AEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiM kA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEA IDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZI BwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQ GCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QD AEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiM kA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEA IDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZI BwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQ GCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QD AEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiM kA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEA IDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZI BwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQ GCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QD AEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiM kA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEA IDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZI BwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQ GCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QD AEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiM kA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEA IDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZI BwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQ GCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QD AEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiM kA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEA IDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZI BwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQ GCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QD AEBihHQAAEiMkA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiM kA4AAIkR0gEAIDFCOgAAJEZIBwCAxAjpAACQGCEdAAASI6QDAEBihHQAAEiMkA4AAIkR0gEA IDFDI+LLeRcBAAB02Pv/A+QuZWJdbkGoAAAAAElFTkSuQmCC --------------090301090900080605040005 Content-Type: image/png; name="EntitiesInUse.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="EntitiesInUse.png" iVBORw0KGgoAAAANSUhEUgAAAukAAAQdCAYAAADjF9Y+AAAABmJLR0QA/wD/AP+gvaeTAAAg AElEQVR4nOzde1xU9bo/8M9wEbwCIirgDQUNQVDQojGTLDOvqZW7tkRtS9iBCrXz7L07WtbR bloHTNs/KDsnL6XWltQCNTVNnVAxEQVU8IqKAl5SQe7r9wdnLWeGAQEHvmuGz3u/fG2YWbPW A4nz4VnP+i6NJEkSiIiIiIhILdxtRFdARERERESGGNKJiIiIiFSGIZ2IiIiISGUY0omIiIiI VIYhnYiIiIhIZRjSiYiIiIhUhiGdiIiIiEhlGNKJiIiIiFSGIZ2IiIiISGUY0omIiIiIVIYh nYiIiIhIZRjSiYiIiIhUhiGdiIiIiEhlGNKJiIiIiFSGIZ2IiIiISGUY0omIiIiIVIYhnYiI iIhIZRjSiYiIiIhUhiGdiIiIiEhlGNKJiIiIiFSGIZ2IiIiISGUY0omIiIiIVIYhnYiIiIhI ZRjSiYiIiIhUhiGdiIiIiEhlGNKJiIiIiFSGIZ2IiIiISGUY0omIiIiIVIYhnYiIiIhIZRjS iYiIiIhUhiGdiIiIiEhlGNKJiIiIiFSGIZ2IiIiISGUY0omIiIiIVIYhnYiIiIhIZRjSiYiI iIhUhiGdiIiIiEhlGNKJiIiIiFSGIZ2IiIiISGUY0omIiIiIVIYhnYiIiIhIZRjSiYiIiIhU hiGdiIiIiEhlGNKJiIiIiFSGIZ2IiIiISGUY0omIiIiIVIYhnYiIiIhIZRjSiYiIiIhUhiGd iIiIiEhlGNKJiIiIiFSGIZ2IiIiISGUY0omIiIiIVIYhnYiIiIhIZRjSiYiIiIhUhiGdiIiI iEhlGNKJiIiIiFSGIZ2IiIiISGUY0omIiIiIVIYhnYiIiIhIZRjSiYiIiIhUhiGdiIiIiEhl GNKJiIiIiFSGIZ2IiIiISGUY0omIiIiIVIYhnYiIiIhIZRjSiYiIiIhUhiGdiIiIiEhlGNKJ iIiIiFSGIZ2IiIiISGUY0omIiIiIVIYhnYiIiIhIZRjSiYiIiIhUhiGdiIiIiEhlGNKJiIiI iFSGIZ2IiIiISGUY0omIiIiIVIYhnYiIiIhIZRjSiYiIiIhUhiGdiIiIiEhlGNKJiIiIiFSG IZ2IiIiISGUY0omIiIiIVIYhnYiIiIhIZRjSiYiIiIhUhiGdiIiIiEhlGNKJiIiIiFSGIZ2I iIiISGXsRBdARNRQN2/fRMHVAlz74xrKystwp/QOKiorRJdFTWBrYwtHB0c4OjjCuZMz3Dq7 waWTC2xs2DsiIgIY0olIxSoqK3D0xFGcOHMCJ8+cxPXb11EtVUPS+x9ZNg00sIENNBoNOjh2 QL+e/dDfqz8G+w5Gh3YdRJdHRCSMRpIkvssRkarcvH0Tvx78Fb+l/4ZbpbdQKVXCycUJnu6e 6OLaBa6dXWFvZw9bO1vY29mLLpeaoKqqChUVFaiqrsKNP26g8Goh8vPzUVhYCBvJBm3t22Lw gMEY9fAouLu5iy6XiKiluTOkE5FqVFRW4Od9P2Pn/p24U3kHzq7OGDRwEPx9/dGhA7uqrUF5 eTmO5xzH0cyjuHjhIhxsHBDsG4xJj09Cpw6dRJdHRNRSGNKJSB1yzuZgbfJaXL5xGZ3dOuNR 7aPw7usNjUYjujQS5HLBZezR7cGZU2fg5OiECaETMDx4uOiyiIhaAkM6EYklSRK267YjZW8K ylCGUSNHISgwiOGcFGfOnsFP235C+e1yDBs4DNPGTYNDGwfRZRERNSeGdCISp7q6Gt+lfAdd hg4dOnfAlAlT0MW1i+iySIXu3LmDH7f+iHOnz6F/j/549blX0a5tO9FlERE1F4Z0IhJDkiR8 l/Id9qbvRbce3fDc5OfQpk0b0WWRikmShB27duDw4cPo79kff33hr+yoE5G1cueCtEQkxM/7 fsbeI3vh3ssdzz/zPAM63ZNGo8ETjz2BocOG4uSFk1j1wypUV1eLLouIqFkwpBNRi8vKzULK 3hQ4dXHCM5Oega2treiSyIKEPhKKB/wewJHcI9i2d5vocoiImgVDOhG1qNslt/HtT9+i2r4a zzz9DDvo1GgajQbjRo+Di5sLtum24dT5U6JLIiIyO4Z0ImpRybuSca34Gp58/Ek4d3IWXQ5Z KFtbW0yeMBllKEPSz0kceyEiq8OQTkQt5nLhZaQeTYW7pzsGDhgouhyycJ1dOmNo8FCcu3IO B48eFF0OEZFZMaQTUYvZrtuOO5V3MOrRUVwHncxi+EPDoWmjwba921BVVSW6HCIis2FIJ6IW cav4Fg4fPwwPTw94uHuILoesRJs2bTAkcAgKbxbi+OnjosshIjIbhnQiahFpR9NQVlWG4CHB okshKxMUGIRKqRIHMg6ILoWIyGzsRBfQENXV1fjj1h+4efsmiu8Uo6KyQnRJVsGhjQM6tu8I p45O6NCug+hyyMpl5WZBY6dB/379RZdCVsapkxO6d++O42eOo7KqEna2FvHWRkRUL9X+S3bz 9k38nvk7MnMzkXsxF5WVlahGNWxtbWFnr9qyLUp5WTkkSYINbNC+bXv49vZFwAMB8O/vD3s7 e9HlkRUpLSvFmUtn0MOzB+zs+PNL5tevbz8cuHIAZy+chXdvb9HlEBHdN9W9W94qvoWte7di 7+G96OjcEQMGDMDkYZPh2tkVHTqw22tuVVVVuHnrJgoLC3E27yzWbFkDh20OeOqRp6AdouVN ZsgsLl65iIqqCvTo0UN0KWSlenj2gE7S4dylcwzpRGQVVBXS9x7ai027NqGDSwdMeWYKevfs Lbokq2drawsXZxe4OLugv09/PD7ycRw5dgSb923G7oO7ETYpDH08+4gukyxcwdUCVElV6Nql q+hSyEp1c+uGaqkaBVcLRJdCRGQWqgjpVVVV+Pe2f0N3TIfHH38c/r7+XJ5NEFtbWwQFBmHQ wEHYtWcX4lfHI2x8GIL9ebEfNd21P66hWqqGi7OL6FLISjk6OsKhrQOuXr8quhQiIrMQHtKr qqrwxXdf4EzhGbzw/Avo5tZNdEkEwN7eHqNHjUa3bt2w6qdVuHn7Jh4LeUx0WWShSstKIUGC o4Oj6FLIijm0cUBpeanoMoiIzEJ4SP/3tn/jbOFZhP85HO3btxddDhkJ8AtAx/Yd8cPGH+Dq 4oqAAQGiSyILVF5RDqBmTWui5mLfxp4hnYishtB10nW/6/Dbsd8wZfIUBnQV8+rjhRGPjsDK TStxufCy6HLIAlVXV0OCBBsb3pqBmo+tjS2qq6pFl0FEZBbC3jFL7pRg0+5NeGzUYxxxsQBD hwyFZx9PbNq5SXQpRERERFZPWEjfuncrHDs6YtDAQaJKoEYaNXIUMs9m8tbbRERERM1MSEgv vlOMPb/vwfCHh3MVFwvi1MkJA/0HYtvebaJLISIiIrJqQkJ6elY6HDs4wrsvbzhhaYIHByP3 Yi6u3uAyZ0RERETNRUhIzz6dDW9vb3bRLVAX1y5w6uyEE6dPiC6FiIiIyGoJWYLx1MVTeMyX a25bKk9PT5y9dBbaIK3oUogabN1Xx/Htl1miy7BqgcO64t34R0SXQURkFVo8pBffKcbtktvo 4tqlpQ9NZuLa2RV5J/NEl0HUKFfyi3HscKHoMqxaJxeug09EZC4tHtJvF9+GBAkd2ndo6UOT mXRo3wE3i2+KLoOoSXp6uSH2vSmiy7AqP6z+DXu2HhVdBhGRVWnxkF5ZVQkJEuzshN/slJrI 3t5euYMkkaVp42iPfr4eosuwKi6uvBkdEZG5tfiFo5IktfQhycw0Gg0k8L8jERERUXPhPbqJ iIiIiFSGIZ2IiIiISGUY0omIiIiIVMYqr958tP8aXMq7LboMoab95QG8//lI0WUQERERURNY ZUgHALfuTnh2xqOiy2hxpXfK8T//vVV0GURERER0H6w2pHd0bocxU4NFl9Hibt4oYUgnIiIi snCcSSciIiIiUhmGdCIiIiIilWFIJyKycGtnhOLToY74dKgjfv92mehyiIjIDKx2Jp2IqLn8 /u0y7PrkzTqf9wgIwfNf7WqxWi5lpLbIsYiIqOWwky7Q8n9HY+JcR/zHslDRpRBRIwS9MAtv pJUaPPZGWilmJGUCAC5lpGL7+9HCapGtnRGKtTNCW6QOIiIyL3bSUROWt6SuMPnczElLMGnE LLMfc9OeZXUek4gsg0dAiEEX27lnP+XjotxMESUpzuq24lJGKjwCQoTWQURETcOQDiD6meUI 8Z+EBV8+DQBI/HsmLl3NxYIvn8YXm97EMN+xcO/S7x57aZxJI2bBs6uPckygJrh/selNLHh1 I4IHjDHr8Yio+d3IO6V8HPLqPw2eWzsjtNZYitwB3/5+NDI21P9L+xtppbW2q6uDrr/dpYxU fDrUER4BIeji7VfrOKF/W4KgF8zfiCAiovvDkN4Ih05sNQjVALDg1Y21Hps5aQn2Hvke2edS lc/zCrKVzrmp7rx+N994f/r7bY6uPhHdv0+HOgIwPY8uPxcw9RU88dZyZaZ97YxQ9B/9rBKc 5XGZr6b4IfRvSwDAYPb9ibeWo7OXb73z8PJ2AJCxYYVSj/4cvf5xiIhInTiTbkLER35Y8OXT eCrkFWxeXAr3Lv0MAvrmxaWYOanmDVR+7KmQV5D495o3Ps+uPvh41i749r57mjn6meUGnxvT f37BqxuV/Rvvl4jUSe5qy51r2Vnd3ZuLZWxYgU+HOiph+VJGqkH3/aspfvhqih88AkKatbvd UschIqKmY0g3QQ7FW1JXKBd1XizIUZ6fONcRX2yqeZP17R2CBa9uxJbUFYj4qKYrZY5RlUkj ZjXLfomo+UxdulH52NRSiFOXbsQbaaUGf0b9x3/XGlu5lJFq9gs+TV1g2hzHISIi8+C4Sx1m TlqCLza9iexzqZg41xETh0cpzyX+PVOZUd+0ZxkuFuRg8+JSZab8P5aF4uNZu9Db3Q/Z51KR V5Dd6ONv2lPzBm9qv0SkPjfyTqGP9u4v0id//h7Xzhj+7Kd++YHBNsDd5RynLt2IPtoxyjz5 pYxUg7n2s7qt6KMdU2uf9yLPwdd3HCIS507pHVRWVaK8olx0KVbB3s4e9nb2cHRwhEajEV3O fWFIR+3VXSI+8qs1mhLsOwbdXfvii01vKp1tfXJnHQB6u9c8H+I/CVtSVyh/9LfV317+ReCp kFeQfS7VYCbd1H6JSCxT66TL4yMBU19Rwu+ljFTMSMrEE28tVy4c1R+FAYDB014DAGyYY3gt yoykTDj37KesIGP8PFAz6z7kT1E4vO5z5bFdn7yJkz9/j5BX/6nMuusf09RxiKjlXC68jKzc LGSdysKFwgsovlMMAJAgCa7MOmhQE8zbOrSFh5sHfL18MdB7IHp072FxoZ0hHTXz4NHPLL/n dsEDxjTqws3gAWOwebHp1Rfqq4WI1C3ohVn1znLLF27qq+/mRqP+47/rfK4hN0V6bO6nJh+v a/UXImp5x08fx+ZfNuPclXNw6+YG737eeCDoAXR26Qw7Ozu0sW8jukSrUFFRgcqqSty4cQNX Cq8g7XQaftz7I7q7dMf4keMR+ECgxYR1hnQyi1OnTuHLL7+Eq6srXn/9ddja2oouiQQ4ceIE lixZgjFjxmDChAlwdHS894uIiKxY4bVCfL/1e2Sfz0ZgYCBGTxwN507OosuyWvL7jouzC7z6 eCFkWAhu376NwxmH8b8//S96H+iN58Y8hx7dewiu9N4Y0qlJKisr8c0332Dt2rU4fvw48vLy MHToUGzbto0BvRUbMGAAnnrqKbz22muIjo6Gt7c3goOD0fOBnqJLIyJqcdmnsvH1pq/h5umG GX+ZwXAuSIcOHTBCOwJBgUHYtWcXPv36U0wfPx3B/sGiS6sXQzo1ypX8K1j4t4XY8/MeVFVW KY/b2Njg2LFj8PT0FFgdqUVpaSlKS0tRUFAAnU4HAGjXoR0e8HwAk6ZNgo0NF5YiIuu279A+ fLf9OzwY8iAefvBhixmxsGbt27fH+KfG40iPI1j500oUXC3A2JFjRZdVJ4Z0apRu7t0w75N5 +PZ/v4WHgwcOHDiA3NxcXLhwASNHjsSKFSsYwFq5Q4cO4cUXX0THjh3Rp08f+Pr6olPXTih2 LMaEZyfw7wcRWb3jp4/ju+3fYcxTY+A7wFd0OWQk0D8Qzk7O2LBhA1xdXPFgwIOiSzKJIZ2a xM3dDe/FvgcAuHHjBn744QesXbsW//rXv/Cf//mf7Bi0Urm5ufj4448xbdo0hIeHIygoCBqN Bms2rcGeo3tEl0dE1OwKrxXifzf+Lx4MeZABXcV69+yNJ0Y/gW9TvkU3127o7dlbdEm1MKTT fXN2dsbLL7+Ml19+GZIkQZIkhvRWysvLC9u2bRNdBhGRMP/e9m+4ebhB+5BWdCl0D4MGDkL+ 5XysS1mHua/MVV12afUh/dCJrQbrkgM1dxF9/fkVtdZDn6B9DT/q/gUAjV5asbXQaDSq+0tO LYcXDRNRa3bizAlkn8vGX/7yF9GlUAM9qn0UX/zPFzh49KDqxl5afUiX1zL/j2WhyD6XiqdC XlHWKpcfB6Dc6TNySt3rGRORdTB1syJjXIOciIxt3bMV/oP8uYqLBXF0dMTQ4KHYsncLhg0a pqpGY6sP6bI/jf4nFnz5NLakrsDUkW/AvUs/HDqxFdnnUpH498xaHffNi0tNduHrsuDVjQbb Lnh1Y83/G71+5qQlBncZ1d8+eMCYWo8TkfnJNyvSv1OnHMrlAP/pUEd4BIQ06GZDsrUzQgE0 7AZFIvZHRE137Y9ryLmQg5cef0l0KdRIgwcNhk6nw7lL59DHs4/ochRcZuH/BA8YA9/eIQCA /177CgAg9dgmPBXyCty79EPwgDFKsAYMx2Q2Ly7FzElLAABPhbyibLPg1Y3KPhd8+fTdYG4U 0PVfvz/rR4O65P1dLMgx41dLRA3hERBS67GgF2Zh6tKan+FLGanY/n50g/Z1VrcVlzJSzVab ufdHRPcnOzcbTi5O6OLaRXQp1Eht27aFh4cHsnKzRJdigJ10PfIceva5VEycW9NBS/x7pslt 9UOzvC0AnMvPVLrhxl3yBV8+jZmTliB4wBhs2rPM5OsrKkqV1/v2DkH0M8uV8RsiUoc+2rtn tTI2rMDQF9/AjbxcbJhT+8zajKRMpK36FBkbVgCoCfZyFz7k1X/W+Rrnnv2w/f1o5XWy0L8t wbUz2Sb39/xXu7B2Rmit8B76tyUIemGWyf3Jpi7diNQvP6j1Wo71EDXMibMn0Lu3+lYIoYbp 27cvsk5mYdzIcaJLUbCTrse9Sz+DTvjMSUvg3qWfyW09u/ooHyf+PRObF5di8+JSfDxrFyaN mKU891TIKwYd+Ia8nojUT7/Lfj3vlBK2py7diDfSShEwtebfki3vvIIn3lqufO4REII30krx 1Lsr6n3N798uUwL1jKRMzEi62zAwtb/nv9qFT4c64lJGqvKY/Jpdn7yJ7e9H44m3litnAQAg YOorytexYc7TuJSRioCpr+CNtFKE/q3m7J48UkNE9btUeAndu3UXXQY1UTe3brh89TIkSRJd ioKddCPRzyzHltSaN0b9sG08f77u5w+Ujrf+KjC+vUPw8axdynPyfLs89iLvM3jAGJOv1yd3 9BP/nlnnLwtEJJ4GEt5IK8WnQx1NdsZNce7Zr8Gv+WpKzb8RHgEhCHphlsltzuq2Kh+HvPpP 5RgeASG4lJGKjA0r8MRby+Hc01vZzjt0Ep54aznO6rYqNWRsWGHQbb+UkYobeafg3JP/BhHV 52bxTXTs0FF0GdREnTp1QllFGUrLStHWsa3ocgAwpJtkanlFeRUYY/pB3vhx/edMdciNtyEi y6A/D+4REALnnt7KRaby2El9oyUAcCPvlEH4Nn6NqYtXL2WkYu2M0CZdKGpqvt6UqUs3Gozz EFHDlFeUw97eXnQZ1ERt7NsAqPnvqJaQznEXIqI66M9n38g7pfy/fuf7qXdX4EZervK53MW+ 1z7v9Zrfv12GT4c61hqFMZ4Zlz/XD9apX36g1Co/33/0s3XWZOq1RNQ41VK1qpbvo8aR/9tV V1cLruQudtKJiIyYWidd7nrL5IsxAcOxEuPRFfnCziF/ilIe0++OAzD5GjlcGz8nz5l7h05S uu7y/qYu3ajMlusfo64LR+V9v5FWijfSSpWLTo3rky9kJSKilsOQTkRkRB41aYyGjKA8NvfT JlZUWx/tGJMrr9S3GssTby3HE2/VvVoU11snIlIPjrsQEREREakMO+lEREREKvfhP3/Db7vz RZchlPcAZ3zyP6NEl9FirDakl5aU48iB06LLaHElt3njESIiImtz/vQtZB4uxJipwaJLEeLX LUcBFa1h3hKsNqRfOn8V70StFF0GERERkdn89Z8TWuUqMr/rcu+9kZWxypC+dsfTqKxUzxI6 InTo2EZ0CURERETURFYZ0j16dhBdAhERERFRk3F1FyIiIiIilWFIJyIiIiJSGYZ0IiIiIiKV afGZdDtbO2igQWVlJdq04cWNlqiiogJt7PnfjixTRXklLl+8LroMq1LMpV+JiMyuxUN6u7bt oIEGd0rvMKRbqJI7JWjn0E50GURNcv5UAf76dLzoMoiIhNn1fjQyN6ww+Zx7QAimfrWrZQsi k1o8pHds3xFtHdri2rVrcOrk1NKHJzO4evUqurt2F10GUaM4OTugl1cn0WVYta7d+cs7kSUI fWs5+oZOwuY5TwMAwpIy4dSznxLelw91xMSlG9FLO6bOfRz5dhn2fvLmPbejpmvxkK7RaNC7 e29czL8Irz5eLX14MoPzeefxxJAnRJdB1CgvRfvjpWh/0WUQEalW6FvLAQCZG1Zg85ynEZ1W ig0zQpGfkWqwnd/UV5ROvBz069o2Oo3jcE0l5MLRAV4DcPr0aRGHpvt0/cZ13Lh6A/79GXaI iIisjYuXr/JxxrrPkZ+RCveAEESnlcI9IAQA0Dd0kvLxxKUbEZ1WivO6rSa3Pa/b2vJfhJUQ EtKHDByCosIi5F/OF3F4ug+Z2Zno2bUnXJ1dRZdCREREZnb9TLbyccCfouA39RXkZ6Ri+VDH Wl1yfb20Yxq8LTWMkJDu6uyKEL8Q/PLrLyIOT01UUlKCtLQ0PB7yuOhSiIiIyEz+yMsFUNP1 lsdYHvnbEhz5dhkyN6yo1R03pTHbUsO0+Ey6bMyIMViYuBDnzp9D7169RZVBjZCalgoPFw8E +QWJLoWIiIiayHh1F3muXCZfSPpH3ins/eRNpTtuanv54xFzPwUAk9s+8rclCHxhVrN8LdZM WEh3dXbFY0MfQ/LWZIT/ORzt27cXVQo1wJmzZ5D+ezpmPz8bGo1GdDlERETURKFvLVcuEq2P U89+jbrwM+BPUfdTFhkResfRCaET4OXmhfUb1qOyslJkKVSPwqJCbPpxE6aEToFPHx/R5ZAF 0mg00ECD6upq0aWQFauWqqGxYROBiKyD0JBuY2OD8KfDYVdphw0bN6C0lMv0qM2VwivY8MMG BHkHIfShUNHlkIVyaOMAoOZutUTNpaK8Am0d2ooug4jILISGdKDmDqSzp8+GXYUdVn+7GoVF haJLov+TeTwTa9euxZC+Q/DCxBc45kJN5tDGARqNBmXlZaJLIStWVlam/EJIRGTphM2k63Pu 5IzZYbPx/ZbvsWr1Kgz0H4gRD4/gnLog+Zfz8cuvv6DochGee+I5aIO0oksiC+fq7Aob2ODa 9Wvo7NJZdDlkhUpLS1F6pxRdXLqILoWIyCxUEdIBwN7OHi9MeAEPBT6ETTs34YsVX8C7vzce 6P8Aenr2hIMDuyPN6dr1aziRcwKnT59GweUCPOT/EKImR8G5k7Po0sgKuHV2g43GBkVXi+Dd 11t0OWSFrl67ChuNDUM6EVkN1YR0Wd+efRETHoOcszk4cPQAtm/djtt3bqNd+3bo2Kkj7O3t RZdoVe6U3MGtW7dQUVYBd1d3BPYPRPD4YLi7uYsujaxIT/eecLBzwPkL5xEyjGvnkvmdyzsH W40tentwSV+ixpKXZHQPCMHUr3bV+pzEUF1IB2pWgujv1R/9vfqjuroal4suo+h6Ea5evyq6 NKtjY2ODbl26oatrV3R24hgCNQ+HNg7o0bUHTl86jaqqKtja2oouiazMubxzcLBzQJ8efUSX QtTizuu21lrrvKEBW74JUV2fkziqDOn6bGxs4NHVAx5dPUSXQkT3wc/HDycvnsSpM6fQ37u/ 6HLIihQXFyMvLw/B3sFoY99GdDlELUr/xkT6NyFaPcUPy4c63vNGQoEvzIJLbx8l5Bt/3lRH vl2GvZ+8iYlLN6KXdsx97au1Un1IJyLrEOQXhOQ9yUg/ms6QTmaVkZkBW8mWd0OmVuePvFNK QH/kb0vg1LMfgJqbEIUlZWL1FD8AdwOzvsbcBdRUp16+yZGp5zp064HbVy4AuHtH0ui00jrr AFDrcQCtPuALX4KRiFqHzk6d4dfXD2fPnOVSq2Q2VVVVOHjoIFw7uMK/v7/ocoha1B95ucrH Lr0NbzYo3y3UpbePEoDDkjIRlpQJoCYUn9dtvecx9EN4dFqpEqp3vR9t8FxYUqbyXO/hY+Ae UHP90cSlGxGdVorzuq111qGxMYyjflNfAQBcP5fT0G+FVWJIJ6IW87j2cdhr7LF7327RpZCV OPj7QZTfKUfoQ6Gwt+PCAtR6mQq0u96PVkK0e0AInHr2U7rtdb2mvv0uH+qoBO1ruZnKc/K+ +zwyFmFJmQh9a3md+zFVh1RdrQR894AQhL61HNFppQ3u9FsrhnQiajF9PPtgcP/BOH3qNHJO te4OCd2/m7duQpeqQ3eX7hgePFx0OUQtrpf2bsfauDMuz6p36NYDAJCfkYo/8k7hj7xTyjZ9 Hhl7z2Pod+jDkjIRnVaK6LRSTP1ql/JcfkYqzuu21grfpvbT1DpaI86kE1GLevqJp3H8zHFs +XkLPN090a5dO9ElkQWqrq7GpuRN0FRq8PSop9lFp1ZLf8lEUxd7Dg6LBQYMnKsAACAASURB VFAT4uUZdaBmDMWpZz+DOfH8jFQsH+qobJOfkYrNc57GI39bUuv18uoxE5duxOY5Txsc2z0g BJ29/ZTXy8cztZ+JSzfi7N6UWjXIF8G2ZhpJkiTRRRBR67L/yH58k/wNuvfsjmlTpnFJRmq0 X/b8gkMHD2FE4Aj8afyfRJdDhDkfzMHzzz8PD/fmWY0u6k/bsG3TGSQdfAcajaZZjqFmMyf8 N7p2t8fG355plv0XFxfj/yX8P7wX/R5cnFya5RiN5G514y7D44dDE6tR/uQW5Ro8H7k+st7n iaj5PRT4EIYHDsel85eQ/HMy2Cugxvj9yO84eOAg+rr3xdQxU0WXQ0TULKwupO+L2Qetl1b5 fPHOxcrHuUW5SNQlKp8nRybDuwtvUU4kwjNjnkGgdyBOZJ1A0o9J+G33bwzrdE9ph9Owfcd2 eHb2xMxpMznmQkRWy2pn0rVeWujO6JCoS8TcUXPh3cXbILDri98dj9ik2Fqv3xezT/lcE1v/ qaWceTm1An9D9isbHj8cujM6k1+DTIqrCTCR6yMNftmoa7/6NWu9tJg2eJpBPXFT4hAzMqbe r4uouVRVVcH+jj02Jm7ElfwrCIsNQ8DQALRv3150aaRCVVVV2Ll7Jw4fPoxebr0wc9pMdGzf UXRZRETNxuo66frkjvrinYsNuuj6nfbh8cOV4CrFSZDiJMRNiYPujA7D4++uFiDFSQavy5mX AylOQnJkMgDAZ6GPwehMQ/cL1IRp3Rkd4qbEQYqTkDOvZtULOaDLj8vbJuoSofXS1tqv8fiO vC857Mv1yPuPTYrluA+1qOLiYixfvhxarRb9+vXDX/7yF1zKu4Rxk8ahk3MnrFi5AqfPnhZd JqlM0dUifP3N1ziafhQDew3E7Bdnw9XZVXRZRETNymo76QAw78l5GJcwDom6RBzLPwYAiNBG KB8DMNnVHu83HrFJsbU62zL9MZmxvmMRoY1Aoi4ROYV3u+kN3W/k+kgAhl1t7y7ekOKkWt17 eVvjrrn8utikWCzeuRgJ0xIMXqcf9uVt5dBP1FIKCwvx9ttvY+vWrSgvL0d+fj4AYOrUqfju u++w/8h+bNyxEf/e8G/09e6L4SHD0b1rd8FVk0g3b93E/oP7kZ6RDkcbR4wOGY1xI8fxQmNq xapx6kQWunv0FV1Ii2uN45BWHdJ93HyUAC0H1bmj5uKlNS8p2+QW5cJnoU9du2iyhu73WP4x aL20GO83vtZzcu0y+eN5T86rtW3MyBjEJsUiUZdYK6TLZwA42kIiubm5IT4+HnPnzsX333+P jh07YtCgQVizZg2AmotJffv5YtOOTUjLSsPXOV+jV+9eGBIwBD79fFpNMJPfiFrj6g1Azdef dzEP6UfTceLECdhJdhjgOQDPjHkGnt08RZdH1OKOHzuOdf+7Dru2b0YVSvFm2E0AzqLLEqKb exfRJbQoqw7pQE0ol8NthDbCYG48fnc8th6vWfhff6b8foO7/iy6Ofcrj62MSxhX73a5Rbm8 IJZUJyMjA9OnT8egQYPw8ccfY+7cuVi3bh3atGmjbNOpQyeEPR2GR4c9il/2/4IjJ45g8/nN kGwkeHp4onfP3nBzdUPnzp1hZ2+d/3ylH0iHi6sLevfrLbqUFiFVS7h+4zqKrhYh72Iezl84 j6qyKthr7DHAcwBGhYyCn49fq/2lhVqfK/lXsHn9ZuxM2YnzZ87jyqUrqKysRNt27TH7H+/A d1Cw6BKFcXJ2EF1Ci7LOdzk98uiIKXJAN/cqL+vT1zd4v/7u/kjUJeKnzJ9qdbqNLw6dNnga dGd0SI5Mxlhf3p2LLIMkSVi6dCkWLVqEJUuWIDw8HB9++CHWrFkDDw/T6wn38uiFl6a8hD9u /YGMExk4kn0EZ/PPouBiAaqlalRL1ZA01nnq86evf4JrN1eEPBUiupTmJ9WcMdBAA1uNLWxg g15de8Hfxx+DfQejuxvHnah1qaqsQsahDBxJO4Jbf9xC4ZVCVFZWwrWrK+K+isMjjz8iukRq QVYf0uvT07kn8m7k4YejPyih1xzjL/7u/tCd0TVovwnTEpCoS0RsUiyyrmQhYVpCndvKIy3j EsbVWpmlru49kUiXLl3Cyy+/jNLSUhw4cAB9+vQBALz88svo3v3eAcypoxNGDB2BEUNHoKy8 DPmF+Si4WoBrN66htKwUlVWVzfwVtCxJkrDyg5WwqbTBqKBRostpdjY2NnB0cIRTByd0de0K 967u6NCug+iyiISxtbOFdqQWul067Nu5D27d3FBZWYlFny1iQG+FrO6Oo6aWSpRDq6mlCxti 1ohZWLZnmcFjEdoIJExLqLV0ohyeTS2paEw/aNe3BKNxIK9r3/oXlJpa/tFU/UTNZePGjYiK isKcOXPw5ptvtpqZ8vuxd+9ehIaGwtPTE+fOnRNdDhE1gjnuOLphzQYsfnsxHg59GLP/ORtT Hp2CNxe8ibCIMDNWSqao8Y6jVhfSrYn8SwXHW8iS3L59G1FRUdi/fz9Wr16NYcOGiS7JYoSH h2PVqlXo1KkT0tPT4eXlJbokImqg+wnpp06cwtuxb6OooAjvxb2Hh0Y8hF+2/IL0A+l4/e3X m6FaMqbGkG7V66Rbsvjd8UrXnwGdLMW+ffsQEBAAFxcXpKenM6A30rFjx2Bra4ubN2/ixx9/ FF0OETWCra0tqqqrGvWastIyfDTvIzz72LN4YvwT+Cn1Jzw04iEAgP8Qfwb0FiSPT9rZqWcS XD2VtHJ13dGU65mTJaioqMD8+fOxZs0afPHFF3jqqadEl2Rx0tLScPbsWXh6eqJNmzb4+eef MXv2bNFlEVEDtW3TFqWlpQ3efmfKTrz7t3cR/HAwUtJS0N3D8Dodt25u5i6R6lFaVgqNRgNH B0fRpSgY0lWCYZwsVU5ODl588UV07doVhw4dQteuXUWXZJGSkpKQmJiI9957D5988gneeust 0SURUSO4ubjhxh837rndhXMX8M4b7+DcqXN4f/n7GP7Y8Hu+hprf9evX4dTBCfZ29qJLUXDc hYiaLDExEY8++ihmzJiBjRs3MqDfhzlz5uDZZ59FSUkJ+vbtizVr1jSqK0dEYvXq3gvnztd9 wXd5WTniFsZh4sMTMWjIIPz4248M6Cpy/sJ59HHvI7oMA+ykE1GjFRUVITIyEufOncMvv/yC Bx54QHRJFq9bt24AgJKSErRr1w7u7u6CKyKixhjUfxD2fLcHFRUVsLc37Mb++vOveOeNd+Dl 7YUf9v6A3n1bx83KLIUkScjNycWzjz0ruhQD7KQTUaP89NNPCAwMxKBBg5CamsqAbmbFxcVo 37696DKIqJH69eoHBzsHnD5zWnks/0I+XnnmFbw16y3M+3Aevkr6igFdhfIv56OspAy+/XxF l2KAnXQiapCSkhK8/vrr2LlzJ77//ns8/PDDokuySnInnYgsi62tLR4e9DB0qTp49fbC54s/ x9eff42Xol7CslXL0LZdW9ElUh32/rYXQx4Ygo7tO4ouxQA76UR0T4cPH1aWUzx06BADejMp Ly+HjY2NqpYAI6KGGzNiDE4fO40xw8bg9/2/I+nXJMTOi2VAV7FTZ07h8oXLmDRqkuhSamFI J6I6VVdXY8GCBRg7dizeffddJCQkoFOnTqLLUhVNrAaaWA1yi3Lve18jPhmBck05NLEaDI/n BWVElqSgoACREZHYtn4bhowcgmXfLEMf7z6iy6J6lJaWYscvO/DIkEfQ2amz6HJqYUgnIpPy 8vIwevRo/Prrrzh48CCefVZdF9Q0RvzueCVMm/oTuT5SdIkAgA3hG+Dq7Cq6DCJqhKqqKsTH x8PPzw8eHh44lXsK48eMx/p/r+cKTSpWVVWF75O+R7cO3VTZRQcY0luF3KJcs3b7yPqtXr0a Q4cOxaRJk7Bjxw707NlTdEn3JWZkDOKmxAEAIrQRkOIk5Y/WS4tEXaIqOtfFxcVwcHQQXQYR NVBqaiqGDRuG7777Dtu3b8eHH36IDh064M8T/ox2mnb44ccfGNRVqKqqCj9u+RFlt8rw0uSX YGerzhFDdVbVQlKyUzAuYZzyec68HHh38Tbb/uW7iFrKfomuX7+OyMhInDx5Ejt37oSfn5/o kprdvph9GB4/HLozOsTvjkfMyBgANd332KRYg221Xlrsi9kHoPZdgn0W+tTat/FNyu61z5KS Eji2vXu3O7kufXFT4pQaG7pffab2KUuOTMZY37HK55HrI5GoS2zQfolak6KiIrzxxhvYtm0b Pv74Y7z44ovQaO7+m9DWsS2i/xyNFd+vwJq1azB18lS4OLsIrJhkxcXF2LBxA2zKbTB7+mw4 d3IWXVKdhHXSI9dH1jrlnJKdcs/nzGms71ilk6b10pp9/2rh3cVb6Roy1FNddu/ejaCgIPTt 2xepqamtIqDLvp7+NbReWqxPXw+gJsjKoVf+2YmbEgfdGZ3ScZcfl+XMyzHo0BsH9Ibss6Sk BA5tazrpujM66M7oEDclzmB/sUmxBuM5Ddmv/rbG+5TPMBjTxGqQqEuE1ktba788K0etVXV1 NeLj4zFw4EC4uLjg+PHjCA8PNwjoMqeOTpj94mx4d/XGytUrsUe3B+Xl5QKqJqCme37g0AF8 tfIruDq64vWXXkdXV3XfgE9YJz1hWgKO5R8DUPMGqR8eE6YlIGFagtIdipsSZ9DdISLzKS8v x9y5c5GUlISvvvoKTzzxhOiShNDvLpvqFI/3G4/YpNg6u9D30pB9FhcXG3TSjTvbUpyE4fHD kahLxORBkzHWd+x91xozMqZWZ17+JcC4ay5vF5sUi8U7FyNhWsI9909kLQ4ePIioqCjY2tpi y5YtCAoKuudr7O3sET4lHINPDMbmXzYjIyMDvgN94dPPB57unrCx4dRxc5IkCVcKruBk7klk Z2fDXrLHtFHTMGzQMIv43gsdd/F390eiLhE5hTVjG/Lp4whtBBKmJSDrShYAoH/X/sprTJ3W BWqPfuifitZ6aTFt8DSD15k6ZVzX/vW3bcip4uY4DW78NTVkv6b2afymX9+2gOH31fj49W1L luHo0aOYPn06/P39kZGRAWdn9Z72a0m5Rbkmf76ae58lJSXKTLrWS2vyZ3Xa4GnQndHhh6M/ YKzv2EbVKo/2xCbF1vp51//5lUdc5j05r9Y+YkbGIDYpFom6RIZ0ahVu3ryJ+fPnY/369fjo o48QFhbWqICn0WgQ+EAg/H38cSjzEH7P+h0b0jfAzt4OXbp2QYcOHSwiMFoSSZJw+/ZtFBUW obSkFN49vDH+4fF4MOBBtLFvI7q8BlPFTPrJgpMGn8v/+Muddpl+QJbDqDxX7rPQxyBMS3ES coty8dKal5TTxkDNG5HPQh/EJsVivN/4WqFS7kABtQOt/qni+uZW5doaOjtu6uuS9zs8frgS 1Bu7X/0OWX2/XDT0+yp38fS/l95dvA22ZVC3DJIkYenSpVi0aBGWLFmC8PBw0SUJlVOYA6Am GOv/TOv/fb6f4N7QfRp30s21X33GnXd5W5+FPsq/eVovLXRndAbX7JiSW5TLn3eyWpIkYdWq VfjnP/+JZ599FpmZmejcuenL9Nna2uLBgAfxYMCDKLlTgpNnT6LwWiH+uPUH7pTeMWPl5NDG Af169kOXgC7w6eODTh0sc+lgoSF9YLeBAICsK1lK11yWkp2ihEEfNx/E746H7oyuVnd5rO9Y g+Bt3B2X92Ec4E35KfMnk2949TF1qrixmuPUekM19fuaHJmsfH/G+o5FhDbC4KwIqdelS5fw l7/8BXfu3MGBAwfQp08f0SUJt3DbQgA1XWp5Ll3/7/j9aug+jWfSU7JTanXT5X1NHjRZqbsh tcq/TBv/rHt38UZyZDLGJYxTuvNyt76uM29E1i4zMxPR0dG4fv061q1bh0ceecSs+2/Xth0G +w426z7J+gg9vyKPsRzLP6acXo3QRgC4+6YJ1LyJyCHe1OlX7y7eyoWfxheYyheF3itI687o 7hnQ98Xsg9ZLi9ik2FoXtt7PRVT6SyTKf8x9qr0uTf2+kmXauHEjhg0bhlGjRmHnzp0M6Kg5 MyX/ohozMgb+7v4AgB+O/qBsU19nWv4ZWbxzsfKY/rrsuUW5Dd5nSUkJHB3vdtLHJYwz+NmT a43QRmCs79hG1wpAWcVGf3u5Yz550GQAd2fPxyWMM9jW1NdGZE1u3bqFmJgYjBw5ElOmTMGh Q4fMHtCJGkpoJ93HzUc5rQrUvNnNHTUXibpE5U1ThPq6wQ05VdwYzXFqncjY7du3ERUVhf37 9yMpKQkPPvig6JJalP7PWaIusdaygvpn2uRRO1PbyTSxGuU1+2L2KSuh6G+v37Fu6D5xEEAF AC3qHDlpaq361/bcayYduHuRqqltuQwjWaOVK1firbfewqhRo3D06FG4u7uLLolaOeEz6frj HNMGT1O6t/IcuRzU5dGYhdsW1grCuUW5yn6aempW66XF19O/hs9CH4xLGKdcvCprzKnixmiO U+uN0dzfVxJv3759CA8Px4QJE5Ceno62bduKLqnFNXYsrbEBtK4Rusbuc/78+WjTpg3mz5/f 4GM3ptaG1NnUfRNZquPHjyM6OhpXrlzB6tWrERoaKrokIgCCx12MQ6nc6Zk2eJrymHw6N2Zk jBLe9VcZSclOUTrOyZHJ912TFCcp89WmVjNpyKlimTlPgzd2vw3VUt9XanlVVVVYsGABnn32 WXzyySeIj49vlQHdkpSUlKB9+/aiyyBqFUpLS/GPf/wDw4cPx6RJk3D48GEGdFIVjSRJjWut mFl9K4sAtZdKbMhSgXVtI5O75HXdcdTUXfZmPzobn/36WZ37rGuO3VTQN+7G17fyisz4+3Cv /TZkXEb/bMG9vq+m9ie/3rj+upa3pJaTm5uLsLAwuLm5YcWKFejaVd03bKAar732GgIDA/HX v/5VdClEVi05ORlz5syBVqvFBx98AE9PT9ElERlzFx7Sici8EhMT8c477+Ddd9/FzJkzTd4J j9QpPDwco0ePxosvvii6FCKrdPbsWcyePRu5ublYtmwZHn/8cdElEdXFnavnE1mJq1ev4pln nkFCQgJ27tyJiIgIBnQLU1JSgnbt2okug8jqlJWVYcGCBQgODkZwcDB+//13BvQWxBWhmkb4 haNEdP+Sk5Mxc+ZMzJw5E2vXroW9vb3okqgJiouLGdKJzGzr1q2YPXs2fHx8cODAAfTr1090 SXWqb1xXXuCC9yJpPRjSiSxYSUkJXn/9dezYsQPff/89Hn74YdEl0X3ghaNE5pOXl4eoqCgc PXoUn332GSZOnCi6pHqZukYPuHsNWnPf3JDUhyGdyEKlp6dj+vTpyqnbTp0s87bHdBfHXYju X3l5Od5//3189tlnmD17NtatW6f6n6u67v4N3L1ngfH29S320JAFKYCaBSCO5R8zuF8NUPsX AnlBCOPjyveHMT6e/LjxIhemFrQwXhrW1OIdxt8X/f1qvbSYNniaQV1Ws4CFREQWpaqqSvrw ww8ld3d3af369aLLITPy9fWVsrKyRJdBZLH27NkjBQQESE8++aR04sQJ0eU0mDZOKyEGUnJW coO3RczdCJeclaw8FrcrTpIkSYpYF2Gwnfyx8efJWckGr9ffh/52Eesi7llvXY/L+8gpzKn3 a5O308ZplcfidsWZfH1OYY7B90J+vqHHsgDdeeEokQW5cOECRo8ejS1btiA1NRXPPfec6JLI jNhJJ2qagoIChIeHY/r06Vi4cCG2bt2K/v373/uFKiF3oX3c6l86Wb/jrt+BHus7FjnzcgCg VoddvtdJhDbC5OfGkiOTDbrQUpwErZcWibpEpGSnNObLapTI9ZEAanfNY0bGIG5KHADD+8MA d79vcVPiIMVJ8O7iDSlOUj62dAzpRBZizZo1CA4OxqRJk7Bz50706tVLdElkZrxwlKhxqqqq EB8fDz8/P3h4eCArK0v1s+f3I+tKFgBg3pPzaj0n37EdQJPDtNZLa/IO4/JNJvVvvGhu8oiL qa9N/qXB1BiM1ktrHaMtJnAmnUjlrl+/jsjISJw4cQI7duyAv7+/6JKomfDCUaKGS01NRVRU FNq1a4ft27cjMDBQdElNJt/5O6fQ9I0RWwP5e6B/k0lTcotyW833iJ10IhX79ddfERwcjL59 +2L//v0M6FZMkiSUlpaibdu2okshUrWioiKEh4dj8uTJiI2NxZ49eyw6oAN3u8d1BdTh8cOh idXg5xM/AwAWbltYa5vcolxl/MNUN7whdGd0Jrvw8gjN5EGTm7TfhpC79cmRycrIiqk/rSWg AwzpRKpUXl6OmJgYTJ8+HQkJCfjwww/h6OgouqxWJXJ9pHIDDuM/8uykOd25cweOjo68ARVR HaqrqxEfH4+BAwfCxcUF2dnZCA8Pt4qfmbG+Y5W5a+Ob/mhiNdCd0SFCG4HT808rHWf9FU5S slOUlVPkmfOmGpcwziCoy8eJ0EYo4d/fvaZhpD/+Erk+ss4VZeQxHP2Z8vjd8QY3OZJHVsYl jEP87niD1xtv21poJEmS7r0ZEbWUEydOICwsDD169MAXX3yBLl26iC6p1ZGXANO/gCklO0Xp ckVoI5AwLcGsxywsLISfnx8KCgrMul8ia3Dw4EFERUXB1tYWn3/+OYKCgkSX1Cxyi3JNLlNo vKRgY5dgjJsSh6wrWcpMt/HnyZHJGJcwTvkF4F7HB1BreUVjxv9Omtre1JKTdS0fKW9b3w2f TB3XgrkzpBOphCRJWLp0KRYtWoQlS5YgPDxcdEmtlvxmIr/hyeQ3B/03gYas6au/T/l543V9 39a+jWVzluHa89cMXicfy9QbnLy6g7lqsJq1hclq3Lx5E/Pnz8e6devw8ccfIywsDDY2HAIw N7kJYerfDRLGnX/TiVTg0qVLGDt2LL7//nscOHCAAV0w+dTsS2teMng8ZmQMpDhJCeiaWI3S cZfnJeOmxCmnovVPy0pxEnLm5SidKjkcy8umvffje3BxcjFYVi1nXo5yLHnfQE1wl7czZw2x SbGt6lQyqZckSVi5ciV8fX0BAFlZWQgPD2dAp1aFf9uJBNu0aROGDRuGxx57DL/88gv69Okj uqRWb1/MPoOgq/9HntVsypq+QN3r+h6ccxAunVyU50y9Xg7Vc0fNbZYaWttFWaROmZmZeOyx x7BkyRKsW7cO8fHx6Ny5s+iyrNbw+OHKKJ/+v3n8hV08jrsQCXL79m1ERUUhNTUVq1evxoMP Pii6JLoH/Quo9Gc5Ta2kIG+r3xnPLcpVuvPGp5R//fVXzJ8/H7t37zZ4vTxyY2rURt7GXDUQ iXTr1i3MmzcPa9aswfz58xEdHQ07O64UTa0Wx12IRNDpdAgMDISLiwvS09MZ0C2EPBYij5cA NSsRmFoBRtbQblRxcbHBGunGnfD16esBGC6BZu4aiESRR1uuX7+Oo0ePIiYmhgGdWj3+BBC1 oKqqKvzXf/0XEhIS8Pnnn2PKlCmiSyIj8gVU91ohYNrgadCd0dXZxW6skpISg7uNxoyMQWxS LBJ1iRjYbaByK3D9Y5m7BqKWdvz4cURHR+Py5ctYvXo1QkNDRZdEpBrspBO1kNzcXDzyyCNI S0tDeno6A7rKJeoSDdZD118aTX8VFHOt6VtcXGwQ0uXjAHdn0eWbfci4rjBZqtLSUvzjH//A 8OHDMWnSJKSnpzOgExnhTDpRC0hMTMQ777yDd999FzNnzrSKm29YK/310E0x7lrfa01foO41 jWUR2ggMuTYER44cwb/+9S+D5/THVvRny/WZqwYrWVuYVC45ORlz5syBVqvFBx98AE9PT9El EakR10knak5Xr15FZGQkTp8+jTVr1ijLiREZ+/TTT3Hx4kV88sknokshahZnz57F7NmzkZOT g+XLl+Pxxx8XXRKRmvHCUaLmkpKSgoCAAPj7+2P//v0M6FQv4wtHiaxFWVkZFixYgODgYAQH B+Pw4cMM6EQNwAtHicyspKQEr7/+Onbs2IHvvvsOWq1WdElkAUpKStCpUyfRZRCZ1datWzF7 9mz4+PjgwIED6Nevn+iSiCwGQzqRGaWnpyMsLAxDhgzBoUOH4OTkJLokshAlJSVwd3cXXQaR WeTl5SEqKgpHjx7FZ599hokTJ4ouicjicNyFyAyqq6vx0UcfYdy4cXjnnXewatUqBnRqFOMl GIksUXl5ORYsWIDBgwcjODgYWVlZDOh031rrSlXspBPdpwsXLuDll19GVVUVUlNT0atXL9El kQXiTDpZun379iEqKgrdu3fHb7/9hv79+4suiciisZNOdB+++eYbBAcHY+LEidi5cycDOjUZ O+lkqQoKChAeHo4///nPWLhwIbZu3cqA3giR6yOhidXUuteBOcgdaP17Pli7lOwUaGI1GB4/ XHQp942ddKImuHHjBiIiInDixAls374dgwYNEl0SWThTNzMiUrOqqiosW7YMCxcuxJ///Gdk ZGRwzK+R5HscRGgjlJuTATXBPVGXqHyufx8DU/dyMHUPBf3QP3fUXJPPG987Qf/eCqbqNN5W /zEpTqpVt6l96t/7wZSceTnw7uJtclv5hnL6jL/2sb5jETclDrFJsdDEauq8v4RFkIioUXbv 3i316dNHmjNnjnTnzh3R5ZCV0Gq10r59+0SXQdQgv/32mzRkyBBJq9VK6enposuxSHG74iTE QEKM6SgWsS5CQgyk5Kxkk8/X91pJkiRtnFZCDKSIdRF1Pqf/erkebZzW5HHidsVJkiRJOYU5 ymP6j8uf679e/2vMKcwxeXz58eSsZJPb6u/b+PH61Pf1W4juHHchaqDy8nL84x//QFhYGBIT ExEfHw9HR0fRZZGV4LgLWYKioiKEh4dj8uTJiI2Nxd69exEYGCi6LIskd7EjtBEmnx/YbSAA 4IejPyC3KFcZXYnfHY+U7BQANV1qU1KyU5Qu9+RBk2s9vy9mH6Q4V0eKdAAAIABJREFUyaDL PN5vPAAYdMflMZm4KXFKp9+7i3et7rS8nXHXPGZkDOKmxAEAFu9cXKuO5MhkpWs+1nes8r3I Kcwx+XU1xrTB0wAAibpEi73glCGdqAFOnDiBRx55BMePH8ehQ4cwevRo0SWRleGFo6Rm1dXV iI+Px8CBA+Hi4oLs7GyEh4dDo6l/dIFMa0hoHO83HlovLY7lH8NPmT8pj69PX4+TBScB3A2i xhZuWwigJjSP9R1r8vhy6Jf/mBolOZZ/DFovrRLg9en/ciGPuMx7cl6t7eRwbzwG09z6d717 XYT+98+ScCadqB6SJGHp0qVYtGgRlixZgvDwcNElkZViJ53UKi0tDa+99hpsbW2xZcsWBAUF iS7J4ul3iuWOuTHvLt615sABw063fhCV6XfRTYVm/Vl0/fnv3KJck0G9IeT5dONZeWO5RbnK 8eje2EknqkN+fj7Gjh2L7777Dvv372dAp2bFC0dJbW7evImYmBhMnDgRs2fPhk6nY0BvYXK3 Wg7dxp/7uNUO1ffqoq9PXw/AcNSkLv7u/tCd0ZnsROt3xuWOfnJksjJGY+oPA3rjMKQTmbB5 82YMGzYMjz32GHbt2gUvLy/RJZGVKykp4bgLqYIkSVi5ciUeeOABlJaWIjMzE+Hh4bCxYWQw F/1wnXUlq87t9LvsEdoIzB01V5lD13ppa4Xe3KLcervoQE3wBmpm3fVfZ6qLLq8oE5sUq8yd y6My+uSRlnEJ42otJRm/O/6+b0Ykf836c+3m2K/aaSRJsuC1aYjMq7i4GK+99hpSU1OxatUq PPTQQ6JLolagsrISbdu2RUVFhehSqJXLzMxEdHQ0rl27huXLl2PEiBGiS7Ja8rKGdS17CBiG 5+TIZIz1HWuwbKMcohuzT/3t6qN/sWh9SzDeazt5230x+0z+MiB/Hcav1d8vYHrpxvq+zrrG eiyIO0M60f85dOgQwsLC8Oijj2LJkiXo2LGj6JKolbh58yZ69uyJP/74Q3Qp1ErdunUL8+bN w5o1azB//nxER0fDzo6XrTUn/RBpiWt5y2uiy788qE19v8xYCHeeu6JWr6qqCgsWLMCECROw aNEiJCQkMKBTi+LKLiTSypUr4evri+vXr+Po0aOIiYlhQG8BMSNjlDGO5rjbaHOK3x2vzKSr MaDrXzxroQEdAFd3oVbu1KlTCAsLg6urK9LT09GtWzfRJVErxJVdSITjx49j1qxZyM/Px+rV qxEaGiq6pFZnX8w+DI8frnTU9cc71KSuu4Sq8QyA/h1Z1VhfY3DchVqtxMREvPPOO3j33Xcx c+ZMrvdLwmRkZCAsLAwZGRmiS6FWoLS0FAsWLMAXX3yBt99+G1FRUbC3txddFhEZcmcnnVqd a9euITIyEqdOncKOHTswcKDpNWqJWgpXdqGWkpycjDlz5kCr1SIjIwOenp6iSyKiOnAmnVqV lJQUDBo0CH5+fti/fz8DOqkCx12ouZ09e1ZZ7zwuLg4rV65kQCdSOYZ0ahXKysoQExODv/71 r1i1ahUWLFjA07ukGryRETWXsrIyLFiwAMHBwQgODsaxY8cwYcIE0WURUQNw3IWs3pEjRzB9 +nQMGTIEGRkZcHJyEl0SkQGOu1Bz2LZtG2bNmgVvb28cOHAA/fr1E10SETUCQzpZrerqaixe vBjx8fGIj4/Hc889J7okIpPYSSdzysvLQ1RUFI4ePYrPPvsMEydOFF0SETUBx13IKl28eBFj xoxBSkoKUlNTGdBJ1dhJJ3OorKzERx99hMGDByM4OBhZWVkM6EQWjCGdrM63336LoKAgTJgw Ab/88gt69eoluiSievHCUbpf+/btQ3BwMHbu3InffvsNCxYs4N8pIgvHcReyGrdu3UJ0dDTS 09Oxfft2DBo0SHRJRA3CkE5NVVBQgDfffBO7d+/GsmXL2DknsiLspJNV2LNnDwICAuDi4oL9 +/czoJNF4Uw6NVZVVRXi4+Ph5+cHFxcXZGRkMKATWRl20smilZeX4+2338Y333yDL7/8Ek8+ +aTokogajTPp1BipqamIjo6Go6Mjtm/fjsDAQNElEVEzYEgni3Xy5EmEhYXBw8MDhw4dgpub m+iSiJqEnXRqiKKiIrzxxhvYtm0bPv74Y7z44ovQaDSiyyKiZmL1IV2SJNy8fRMFVwsAABWV FaiorBBclXk4tHGArY0t7Ozs0M21G9q1bR1v8pIkYenSpVi0aBGWLFmC8PBw0SUR3RfOpFN9 qqur8dlnn2HRokV44YUXkJ2dDRcXF9FlEVEzs7qQXlFZgcycTOSey8WZi2dw5eoVlFeVo1qq hgRJdHlmp/m//9lobNC+bXt0d+0O717eGOA1AH179rW6Lkt+fj5mzJiBW7duYf/+/fDy8hJd EtF947gL1SUjIwPR0dGoqKjAli1bEBQUJLokImohVhPSc87mIO1YGtJPpKO4rBjtOrSDh6cH Ar0C0cW1C5ydnNGmTRu0sW9jNbeDLy0vRUV5BcrKy3D12lVcvXoVRVeLsO3ANqTsS4GbkxuC /YLxYMCD/5+9O4+Lqt4fP/5iHUBkE1BAAUFMRDHFlHDD3BfcbTWzEr3fi2ku1ddu3cu9de2W 2vbVFpe6mWWWaUi57wuigSaKuIEsCoooiOwwM78/+DGBgoICZxjez8fDhzNzzvmc9wieec/7 fBacHJp+V5DIyEhmzpzJjBkzeOuttzA1NZhfX6FHCosKKSktoai4qNHuut3Mvkl+UT6Xr15u lPOJ+zM2NkZlrsLKwgpzM3NMTEwa9fy5ubm8/fbbrF+/ng8++IApU6ZgbCxzPQjRnDT5LCch MYGdUTu5kHYBq5ZWdO7Wmc6dOuPk2PST0vuxsLDQPW7r2lb3WKPRkJqWyumE0+z4fQe7ju6i l18vBgcNbpLJen5+PvPmzWPv3r1s2rSJ3r17Kx2SMBDXb17n/KXzJKYmkpWdRVZ2FkWlRWi1 5XfdGuvu26XUS2zcs5Go81GNcj5RO0ZG5XcqTYxNcLBxoJV9KzxcPejg0YH2bds3SNKs1Wr5 9ttvWbhwIaNHj+bMmTM4ODjU+3mEEPqvySbp2bey2bhjIycvnMTeyZ4Ro0bQyaeTVBoorwB5 enji6eFJUXARsSdjiTkeQ8yZGIY+PpQnHn8CM9OmcTfh+PHjPPfcc/Tv35/Y2FhatmypdEii icsryONkwkli42NJTk+mTFNGmbYMNWrMzM2wtbdFZa5CZa7C3Ny8cYIyAndvd1zauTTO+cR9 lanLKCkpobikmLy8PJJvJJN6I5VTiacwOWRCK5tWdO/cnR5+PXB1dq2Xc8bHxxMWFsbNmzf5 4Ycf6NevX720K4Romoy0FSWjJiTmVAw/bf+JUuNS+vfrT7cu3Qyu73V9Kyoq4kDUAeLi4nCz d+OF8S/U2wdLQ1Cr1bzzzjt88cUXLF++nIkTJyodkmjibuffZs+RPUSfjCa/OJ8SbQnWLa3p 2KEjnu6euLm4KdYvvL9vf9ZuWYt7e1kdV1+VlpaSeT2T5NRkEpMSSb+ajimmmBub49velyF9 h+Dp5vlAbefl5fG3v/2N7777jrfffpuwsDDpzieEcGlSSbpGo+Hn7T9z8I+DuLq7MmbEGJkR oY6upF8h4rcINIUanhv9HN07d1c6pLskJiby/PPPY29vz1dffUXr1q2VDkk0YRqNhiMnjrDt 4DZyCnIoMyrDz9ePrp274t7OXS++4D/m8Rhbf9+Ko7Oj0qGIWsq+lU38mXiOnzxOcUExFiYW 9OrSi1EDR2FtZV3rdtasWcObb77JE088wfvvv4+Li9xNEUIATSlJL1OX8W3Et8ScjSGoTxBB vYL04sO1KSoqKmLz1s1cSbnC5CGT6RvQV+mQdFasWME//vEP/vnPfxIaGio/Y/FQcnJz+D7y e86lnqOEEh7t9ihBjwXpXbcpPyc/jiUdo0VLmeGlqVGr1Zw8fZKDUQcpLSzF0dqRp0Y9ha+3 7z2PO3v2LLNmzSIjI4Ply5cTHBzcOAELIZqKppGkq9VqVv20itMppxk6ZChdO8uS7w9Lo9Gw dedWzsWf46lhT9EnoI+i8dy8eZO//OUvXLhwge+++47OnTsrGo9o+s5fOs/azWu5kX8Du1Z2 jBk5htZO+nlXpoN1B87dOtfoM4iI+lNUVMSufbs4HX8aKxMrBgUOYuSAkXcVGoqKivjPf/7D Z599xt/+9jf++te/GsyMY0KIeuWi96MstVotP279kVPJpxg9YrQk6PXE2NiYkUNH4tvVlx93 /sgfCX8oFsvevXsJCAjAy8uL6OhoSdDFQztx5gSrNqziet51uvh34cXnXtTbBL24qBhTM1NJ 0Js4CwsLRg8fTcioEMpMy9h5ZCffR36PWq3W7bNlyxa6dOlCUlISJ06cYM6cOZKgCyFqpPcj Uw78foDDcYcZNHgQj3R8ROlwDIqRkRHDBg2joLCAtZFrcW7l3KiDSYuLi3n99df55Zdf+Prr r3niiSca7dzCcP2R8AdrI9dSqClkyOAh9Oim34u/FBQUYGlpqXQYop74dfLD2dGZH37+gWPx x1Cr1fTv3p9XXnmF+Ph4Pv30U0aPHq10mEKIJkCvK+mXr14mYl8Evn6+dPfXvwGOhsDY2JiQ 4SGYtTBjTcSaRlu85eTJk/Ts2ZMbN24QFxcnCbqoFxdTLvL9r9+Tr85nxLARep+gAxQVFGFh ZXH/HUWT4eToxAvPvoCJhQmfLf+Mrv5dCQgIID4+XhJ0IUSt6W2SrtFo+HHrj1hYWzD0iaFK h2PQzM3NGTNqDJdvXGbn4Z0Nei6NRsP777/PiBEj+Pvf/87atWuxtbVt0HOK5iEnN4c1v6wh tySXQcGDmkzXuMKCQqxayCxVTZ1arSZq35+LUZ08epKf/+9nrl65yuSZkxk1cZTcMRFC1Ine JulRJ6JIzEhk2OBh0mevEbi0caH7o93ZdXQX17KuNcg5rly5wrBhw9iyZQtHjhxh8uTJDXIe 0fyo1Wq+jfiWG/k3ePTRR3msx2NKh1Rr0t2l6dNqtUwNmcrVy1fJuJzByxNfZmHYQv6++O/8 95f/orJX8fP2n8m4nqF0qEKIJkQv+6SXlJaw7eA2fDr64OHuUefjnxoUQWZ6QQNE1kQYwaiJ 3ix4p1edDusX1I+EswlsO7CNFya8UK8hrVu3jldffZU333yTV155RVaGFfXqUOwhLl6+iIOT A0OChygdTp0UFRRh2UKS9KZszgtzSIhLIDkwmXdef4cX/voCy75dhqVV+c81KDCI6OhoNmzb wKwps2RqWSFErehlkh51PIqcohwm9n2wVSYz0vIoyNcyKKT59WMvLi7l1x+OcvNGYZ2PNTc3 J7B3IIf2H2Lo9aG4OD38ohq3b98mLCyMY8eO8dtvv9GzZ8+HblOIynLzctlxeAcllDBq2Kgm N0tKQX6BLplrSqL2XCH1Uq7SYSjKzsGCmOjv2LF5BxqthgO7DvDj7h/x8fWpsl9Q7yDOXjjL xcsXiTkdw2Ndm86dHiGEcvQuSddqtRw6foj2Xu2xt7N/4HYcnG14/pXB9RhZ05CbU8CvPxx9 4OO7denG4SOHOXLiCBOGTnioWA4ePMgLL7xASEgIJ06ckFv6okHsO7qP3MJcunXrRhvnNkqH U2eFhYVN8v/GD18lsOXnRKXDUJSd41Fybx2itLR8wP35+POM7z+emfNmMn3OdN2XLxMTE4YO HMq6n9ax49AOenTu0eS+TAohGp/eJelJaUlcy7nGuOBxSofSLJmZmeHbyZeYMzGMGTQGU5O6 /4qUlpby9ttv8/3337Ny5UqGDRvWAJEKAQWFBUSfjEZtrKZvb/1ZObcumvrA0Q1H3sbUrPkl nM89MZYbWXtpYd2Czt0606FTB0aMH8HjAx6v9ufp4e5Bu3btyLySyYkzJ+jZVe4qCiHuTe+S 9LhzcZhbmOPp7ql0KM1W506difsjjgvJF+67tPWdzp8/z/PPP0+bNm2IjY3FycmpgaIUAo7F HSOvKI8uXbpgbW2tdDgPpDC/UKZgbGIunImhpCSJVo4DiDj8b9zc3Wp1XJ/efVi/YT2Hjx+W JF0IcV96N3ovITEBD08PuRWoIDcXN1SWKs5fOl+n4z755BP69u1LWFgYERERkqCLBvf7qd8p 0ZY0ifnQa1JYWIiVVdOtpDdHPp174ugYinObUbVO0KG8mt7StiUpGSky04sQ4r70qpKem5fL texr+PX0UzqUZs3IyAhXN1cupl6s1f5ZWVmEhoaSmZlJdHQ0Xl5eDRyhEHAt6xoZWRnY2dvR pnXT64teoakOHBV1Z2RkhF8nP2KOxXDq3Kl6GZwvhDBcelVJT89MR61V49JGLlxKc23jSnpW Omq1+p77/frrr/j7+9OtWzf2798vCbpoNBdSLlCmLaOjd0elQ3koxYXF0t2lGenYoSNl2jIu JF9QOhQhhJ7Tq0p65o1MtGhxsHNQOpRGsfznMLZFr8bXI5APZu1TOpwqWjm0orSslBs5N3Bu 5QxATk4OdnZ2AOTn5zNv3jz27t3Lxo0bCQwMVDJc0QxdSrtEmbaMdm3bKR3KQynIL8CulZ3S YYhG0tq5NaYqU1IzUilTlz3Q4HwhRPOgV1eH7FvZWFpZYmrauGFVJMvVCR2zhDH9ZtX7OTcf XFbjOfWBnZ0dGjRk52bj3MqZ7Oxs3nrrLZYvX87x48eZMmUK/fr1IyYmBhsbG6XDFc3Q1ayr qLVq3Fxq3ydYH0mf9ObF2NiYNs5tyLqSxfWb16XLixCiRnrV3aWouAiVharRzxs2cTnh0yN0 z1e8Ea97vnLzAjKy6n8u4DH9ZlU5J5Qn7iGvWRB7bnu9n6+uLFQWaNFSVFyEWq1m5MiR5OXl ER4ezsiRI3nnnXf48ssvJUEXitBoNGRlZ6GyUDX5BLcwv1D6pDczrVq1QoOGzBuZSocihNBj elVJLyktwdzcXOkwahR7bjvhq8ZWeS18esRdr4WOWcKhkxtISInWPU/LTNBVzqurzleu5t/Z XuV2G6KqXx1zs/KfQ3FJMS+88ALHjh0jKyuL69ev88cff9CmTdMdqCeavtv5tylVl2JrZ6t0 KA+tsECmYGxubFvaotFqyMnNUToUIYQe06tKulqjxggjpcNgxvt+hK8ay/DAl4lcXISLo3eV BD1ycRGhY5YAfybUwwNfZsUb8QC4Ofvwwax9+Hr82U87bOLyKs/vVHl7+PQIXft3tttYTExM 0Gq1rP9+PRs3bkSj0ZCfn09OTg7/+Mc/SExs3isNCmUVlxSjRYvKvPHvvNU36e7S/KhUKrRo KS4pVjoUIYQe06tKur5Y8UY8M973Y1v0alIy4vlg1j6uZP45Ej/ktT+rXr4egTw1ZCHhq8bq KuEBjzz8Cptj+s3Czdmn3tuti+SEZHb/tJuSkhJat25N586dGTlyJC+99JJuAKkQSigpLUGr 1WJmZqZ0KA9NpmBsfszMzCRJF0Lcl15V0vVJRSU7ISWakNcsuHojSbdtxRvxRC4uInJxEX27 TeJK5oUq1fXXlwUD4OFSPt97WmZCnc+/+eCyGtttDDeu32D3z7tp2bIlc+bMITo6ml27djFv 3jxJ0IXitFotUD7vdFNXVFCEZQtJ0psTY+Pyj96K32MhhKiOVNK5e3aXGe/73dU1JcB3GG1a ebFy8wJmvH/3YksrNy/QPa5IzgO7jGFb9Grdn8r7Vt6/4ovA8MCXSUiJrtInvbp2G8PZ02cZ P308s1+cTVCPoEY7rxDNTUFBAZaWkqQLIYSoSpJ0yvuDh01cft/9Ah4ZVqeBmwGPDCNycVGd Y9EHfQb24dipY0qHIYTBKyyQ2V3uZ9eiMOI2rsbVP5Cnv9qndDhCCNEoJEkXQggFGUp3l+So 7WycXf3MVMADJ9jH1y0jbqP+rikhhBANRfqkCyGEggylu4tn0DDmxfx55zB4/hLmxRQxL6YI /wkv49jhwbrr9XhmFhM+jbj/jrV0fN0yPuxpQXKU8utRCCHEvUglXQghFKJWqykrLVNkEbfG UFFdn/BpBBtnj62xIu7qXz4GKD0uusrrlZP+Cj+8FKzbL3j+Em5eStC1Gzx/CT2emVVln8pt VXSbAXRV/+D5S9i3dEGVfYPnlw/Wv/N1gAmfRuAZ1LgzbQkhmieppAshhEKKC4tRWaoMYpaa O+1bukCXCNu161Al4Z7waYSuwu4/4WUCpy8kPS4aV/9A5sUU6ZL26qrdT3+1T7cdYPCby6s8 T47aXmNblfed8GkEEz6N0CXiL22K56VN8brYjYyrfjz6T3gZgJspFxBCiMYgSboQQijEULq6 VCd4/hJdN5WctIsAuufRq94jOWo7cRtX0/P5eXgGDcN/wsukx0XzYU+Lu6rgdVGXtioSblf/ QOzaeWPXzlu3TavR6Crqrv6BDH5zOfNiiujxTOOs+iyEENLdRQghFGLoM7tU9FM/vm6ZrtuL q38g6XHRbJw9luD5S7Br560bHFoxuLS67iqVOXbwIz0umpuX7l6Doi5tOXiUr+KcHhdNTlrV VZS9+o4g6dDWB37vQtRErVaTmJrI2aSzXMm8wo2cG5SoSygpLVE6NINgZmqGuak59i3tcWvt RkfPjnRs3xEz06a3+F2zT9Jjz22vMi85lK8iOvfp1XfNhz466H/4NepzgDpPrSiEEHcqLCjE qoWV0mHUiztnd9m3dEG1fbqH/3M1X40vv7Z69R2h+3vf0gW66neFjbPHYuvqya30ZADd9gmf RhC3cbXuT+VztnssuMq+ldsKnr9El+BXxOr5+BCSj+zUxQTlFf+kQ1t18Ve09dKm+CrVdiHq Iic3h+2HtnP87HEKSwtxa+uGs7Mzvu19admiJebm5kqHaBBKSksoKCzg1q1bJF5PZN+JfZgZ meHfwZ/h/Yfj3MpZ6RBrrdkn6RVzmb++LJiElGiGB76sm6u84nWAD2btA2Dm+I8UilQIYSgK 8gpQWagoLCjEwrI8kSwrLcPUrOleku+c3eVe7tzPrp13rY+tqY26GPzm/dej8AwaJl1bRL0o LilmZ9ROdh/djWMbR4IHBePl6YVKZZgDxvVNWVkZSclJnDx1kndXvkv/R/szvP9wrK2slQ7t vpruJ0I9e2rIQsJXjWVb9GomDJiHi6M3see2k5ASzYo34u+quEcuLqq2Cl+T8OkRVfYNn17e N/PO40PHLKmyymjl/QMekRkFhDAEpmamvDnrTcY9Mw6rFlYkX0xm77a9vDjrRaVDE0LUo6zs LFZtWEWeOo+Ro0fi4+2jdEjNjqmpKR07dKRjh46kXk5l7/69nP76NNMnTqdtm7ZKh3dPMnD0 /wt4ZBi+HuWj/j/6oXwUf/TpzQwPfBkXR28CHhmmS6yhajeZyMVFhI4pH2A0PPBl3T7h0yN0 bYavGvtnYn5Hgl75+KNnfq0SV0V7VzJlRgEhDIW5ypxTx0/x+eLPKSstY/yA8XTt0VXpsIQQ 9SgxNZHF/12Myk7FC8+9IAm6HnBv686Up6fg4unCh2s+JO5cnNIh3ZMk6ZXMfbq8b2NCSjQh r1noqurVqZw0h7xmoat+p2TE6xLu8FVjSUj5c8BS+KqxhI5ZQsAjw2o8vrT0z4Td1yOQsInL iVxcxJh+cttVCEPStXtXfo/6ndN/nKa1S2sCHg9QOiQhRD25fvM6qzauolOXTowbPQ4zs6Y3 aNFQmZiYMGzQMIL6BfH1L1+Tmp6qdEg1ku4ulbg4ejM88GW2RZcn66FjluDiWP0gITfnP78R r3gj/q79KpLu4YEvE9hlzF3dWu51/OaDyx7ujQgh9N7w8cPZ8N0GNGoNnbp2Msi50oVojgqL Clnx0wpat21NcN9g+b+tp3p270lOTg4rNqxgwbQF2NnYKR3SXaSSfoeKQaNAler1nf3P1+98 T1fxnvG+HyGvWRDymoVuoGnFtgkD5um60vh6BOraDHhkWLXHV66qV1T0M7KqTg0mhGj6evfr jY2tDaZmpjw3/TmlwxFC1JOI3RGUGJUwevhoSdD13BMDnsDawZr1W9crHUq1pJJejeqmV6yY BeZONXVDGdNvVpVtFbPD3GsfIUTjuX6tgGvp+YrGoFJZotUYYWHpwekT1xWJwe9RR0kkhKgn 6ZnpRMVF8fTTT2NqKimWvjM2Nmb40OF89fVXnL90no7tOyodUhXyGySEaJY2rj3P4reOKhqD GnPAjPF9NikWQ8KtUMzMJUkXoj7sPLyTdh7tcHVxVToUUUt2NnZ09uvM1oNbJUkXQgh9Mvsf 4/DooMziFsePtKFFSwce6dK30c+9ZtluTh6VrnRC1Jei4iL+uPAH4yeMVzoUUUe9H+vN6tWr ycrOwtHeUelwdCRJF0I0a24ejnj7KlP1cvOYgsrCCiPjxh8eZG1j2ejnFMKQnbl4BlNzU9q5 tVM6FFFH9rb2ODo5curcKQYGDlQ6HB0ZOCqEEAqxsLJWJEEXQtS/hKQEPDw9ZIxHE9W+fXvi L8YrHUYVBltJV6s15OUWKh1Go8u//eBLZQshhBDiwaRdS6NjV/3q0yxqz83VjZ1xO5UOowqD TdJTLlxjyhPvKx2GEEIIIZqBnNs52Nnq31zbonZsbWwpLC6kuKQYlblK6XAAA03SP/rvIIqL 1EqHoShnVyulQxBCNANfvv8bxsbN7/b+rex8Wtq1UDoMoUeKSoowNzdXOgzxgCxUFmi1WknS G1pAUBulQxBCCIPm3t4Gv+5OpCenKR2KItr72ODZwUbpMIQe0Wg0GBvJGJOmyvj/jw9Sq/Wn yGuQSboQQoiGteCdXix4p5fSYQghhMGSr3xCCCGEEELoGUnShRBCCCGE0DOSpAshhBBCCKFn JEkXQgghhBBCz0iSLoQQQgghhJ6RJF0IIYQQQgg9I1MwCiFENTavi2Xl0t1VXgv/dBIBQV6N GkdsVBLhszcA4OvvylPTg6o8/+CrKY0ajxBCiMYhlXQhhLjoCm32AAAgAElEQVTD6y+t1SXo kTGvExnzOsMndCN89gZef2ntA7W5eV0sIT0/IDYqqU7HBQR5Ef7ppBqfCyGEMExSSRdCiEpi o5JIiEsHqJIMh705jHbtHYHqq+y+/q664yoLnT+ItEtZbNt4srzN/18Fr07o/EF3tRsZ8/p9 Y74zntautlxLv3XXfrVpSwghhH6QSroQQlRyJSVb99i1nX2VbWOeCcDNw75KlT10/iDddl9/ V4Dyqvv/T/BXLt1N2JvDdNvCP51U5Thff1fdturavV/lPjYqiZVLd+Pr70pkzOv4+rtyLf0W o5/scVf7GWnZ92pKCCGEHpFKuhBCVOLm8Wdinp6WjUulRH3zulg2r4sByhPxyvsnxKXrkuHA YJ+7EvyaeHRwIuzNYbpqeHXt3kvFl4qEuHRCen5QJfbK7QshhGhapJIuhDBo58+c55vPv+HE sRPk5ebdd//KA0PDZ2/QVZ8z0rJZuXS3rhtJRfeViiS5Irl+UBVJeV3brTiuopJe8aexB7gK IYSoX1JJF0IYtI6dO7Jn6x6mjZmGmcoMO3s7Wli3IOeGGg0tSL7YA69OTpiZq3THRMa8zusv rSUhLp0Z41dWaS/800lE77vAto0ndZXrigq6ri/7Hf3OX39pLR4dnEiIS79r27aNJ9m28aRu cOqd7QYG++iOubNanhCXzvpVUXcdV1P7Qgghmg5J0oUQBkOtVnP92nWupF4hPS2djMsZpF9O 50rqFexb2ZN6KZUbmTcAMDExRUsr1GWlVRL0Cvea2jAgyKvaLiT361ZSm+3V7VObBFu6tAgh hGGRJF0I0SSo1WpSUlJISkri9JnTxOyPoWxXGZtXbSYzI5PMjExKSkpo69EWZxdn3Nu7497e Hf8e/gweOZiP3/2Y9MvpePl4MXTsUExNAvn0nVN4d+qt9FsTQggh7iJJuhBCL+Tk5JCYmEhS UhLp6elkZGSQlJSke56dnY2rqysuLi7YOdhRXFSMu487I4ePxNm1PCm3tbOttu0vl35Jfl4+ 73/xPmOfGouxsTFfLv2jkd+hEEIIUXuSpAshGlxpaSlpaWlVku47k3Bzc3N8fHxwcXHB1dUV Ly8vJk+erHvu5uaGSlXeLSUtI42l/12Kq6crg0YNuue51Wo1IyeOZOb8mY3xVoUQQoh6IUm6 EOKhaLVaLl26VG3iXfH89u3buLu74+XlhZeXFy4uLgQEBFRJwu3tazdlYV2ZmJjQzrNdg7Qt hBBCNBRJ0oUQ93T79m3Onz9fYxKenp6Ovb29rvrt5eVF586dGTx4sO55QyXgQgghhKGSJF2I ZqzyYMyakvCSkhI8PDyqJOGjR4/WPXd1dcXCwkLptyKEEEIYFEnShTBglRPv+w3GrEi6AwIC qiThUgUXQgghGp9BJunnT9+kpFStdBiKsm9liZu7tdJhiAZUUFDApUuXauwHnp6ejkqlokOH Drp+4K6urlX6gbdt2xZzc3Ol34oQQggh7mCQSfr0CVtJT7v/8t+G7MkXO7HoswFKhyEekEaj ITk5uc6DMfv27VvluaWlpdJvRRio2VN2seXnRKXDUFTHLg5s+X2y0mEIIQyUQSbpAG09HZn7 zgSlw2h0+beL+ftfv1E6DHEfubm5XLhwQQZjiiZv5hujMDYxVjqMRvf957uVDkEIYeAMNkk3 tzDD29dV6TAaXW5OgdIhNHtlZWWkpqbeczBmaWkp7u7uMhhTNHlDxvXA1MxE6TAa3S9rDisd glBAdnY2b7zxBmVlZQwdOpS+ffvStm1bpcMSBspgk3QhGsq9uqAkJSWRm5uLh4dHlX7gjTUn uGhcWq0WIyOjemvv5vUMHJxc6q09IUT9sre3Z9GiRYwYMYI1a9Zga2uLs7MzlpaW3My/ibWx NZOfn4y9g1zjxcOTJF2ISvLz80lOTr7nYEwLCwu8vb2rJOEVfcFdXFxwdHSUwZhNyL6tJzl9 IrnOx104sxVjEzO8Hxlcb7Ec2fsxfj2exMa24e8CXk6+3uDnEKIpKSwspLi4GDs7O06dOkVZ WRndu3dn06ZNAIwfP57FixdjYmLCnj17aN++PTdu3CAnJ4fWrVtjpDLCpZ2LJOii3kiSLpqN 2gzGzMvLo127djIYsxlQqUywsVNxeGdcnY5Tq6+Rl78erTYfW5sFnD52sN5iun37Dy6eOYKN zax6a/NebO1UjXIeIZRSWFiIpaUlycnJ3L59m65du7J3715ycnIYP348X331FTdv3mTBggV8 /vnnqNVqXnvtNS5evAhA9+7d8fT0xNS0PF0KDQ3F3NyccePGATBgwADGjh3L9OnT+duyvxHw eIBi71UYHknShcG4desWFy9erLb6XTEY8845wWUwZvM1bVZXps3qWuv9s29ms/CvCzm85zBa bT7T50znzfdC6zWmp4ZsJSYqhvCPHRjz1Jh6bVsIQ5KZmUlOTg4dO3YkNjaW9PR0QkJC2LRp E4mJiSxYsIBPPvmEK1eu8MEHH3DixAlu3rxJ165dadmyJWZmZgCMHj1a12Vt3rx5uvbHjx+v e9y9e3fdYzs7O7744gscHR05cOAAnTt3bqR3LJojSdL1wPINYWw7shpfz0A+eGXfXc9F1cGY NQ3INDMzo2PHjlWS8Mr9wN3c3FCppHIo6m7NF2v4evnXJF9MBsCroxfz/zG/3s/T0qYlGo2G Ze8vY/i44ZirpNuUaB5u375NdnY27u7unD17luTkZIYPH86ePXs4efIkc+fOZe3atezfv5+V K1cSGxvLmTNnmD9/PmZmZrpKd69evXj00UcBmDNnjq79ykl3z549dY+dnZ3rHOuMGTP4y1/+ 8qBvVYhaM/gkPfbsdsJXjq3ymj4lv5sPLGPbkdU1Pm8OtFotGRkZMhhT6KX9O/bzx+9/4Obu RlpyGmhh4nMTUVnU/xc+rVYLwMWzF1n6z6UsXLSw3s+hj/YtCiN+Y/XXPRf/QCZ8ta9xAxIP LS8vj4KCApydnUlMTCQ5OZlBgwYRFRXFsWPHePXVV9m4cSO//fYbq1evJioqiv3797No0SKK i4u5efMmAJ07d8bJyQmAKVOmMGXKFABGjBjBiBEjAPD398ff3x8ANze3Bn9vxsbNb8pRoQyD TtIrKtIAKxbG4+LoTUZWIjPe8yNkvgWhY5cwpv/D9f3cfGAZKyMWEB4aQUCnYXU+fkz/Wbg5 ++i+SNz53BDk5eWRkpJyz8GYlpaWVfp93zkY08nJSXd7UojGNGDoACwsLZg9dTaDRgwiLTmN mfNnNsi5NBoNtna2qCxVbPxuI9PnTMeptVODnEufBL+5HK/gMUTOLr/uTdkUj207b13yvryn BSGfRuAeVPM19uS6ZRxauuC++4kHU1paSnFxMdbW1mRkZJCYmEjfvn2Ji4vj4MGDhIWFsWfP HtatW8fKlSs5duyY7nF+fj5nz55l0KBBeHp6otFoAAgJCWHo0KEADBs2jGHDyn9u3bp1o1u3 bgC0adOGNm3aKPOmhVCYwSbppSZZugQ9dOwSXBy9AXBx9GbFwnhmvOen27ci0a4sdOwSDp3c QEJydLXtRy4tqvIl4F5JdXhoBFcyL1R7jtp+SajujkDo2CV3tQlg7PAk0KlW7T4stVpNSkrK PecELy4uxtPTU9cFRQZjiqbk1PFTzJ46m8/WfcaWn7cQ2D8QE5OGmRc8NyeX4GHBnIk7w7PT n+XzxZ/z9yV/b5BzNQXBby4HIH7jaiJnjyUspoiNLwWTEVf1uuw34WVdJb4i0a9p37CYogaP u6nJzs4mKSmJgIAAEhMT2bNnD6GhocTExLBq1Sq++OILoqOjWbx4MZs3b+bmzZvs3r2bvn37 4ujoiIeHBwCPP/44vr6+ADzxxBM88cQTQNVKt6urK66u5bMXmZmZSfFFiHsw2CS9xDRT99jN 2afKNhdHbyKXll+oY89u1yW6KxbGAzDjPT9ddXz9zvdISI7WdZEJmV++wMzmA8sIm7SclIx4 EpKjCQ+NwNWxQ5Xkf/jjL7PtyGo2H1jG8XM7qz3HnbFVp3KCHrm0SPel4uiZX6vsV3E+LG/e 1YZWq+XowaM8+tijWFjWfpGcvNt5xMbG1piEZ2dn3zUYMyAgoMrCPNINRTRVFxIuEDoplKWr lhIQGEBBXgFBA4Ma7HztO7TnX5/8iz4+fRg5YSTW1tZoNJpmfXvdvr2v7nHc+s/IiIvWdYGp SMK9gsdw82I8GXHRukp6atT2avdNjdpu8JX2/Px80tLS6NSpExkZGezcuZOpU6dy9uxZli1b xrJlyzh27BivvPIKR48e5dq1a3z99dcEBARgZWWlG7vj6+vLq6++CkC/fv3o168fAH5+fvj5 lX/WVU66LS0tpeAiRD0y2CS9siuZF+7qirJ8QxgA7ZzLPwB8PQN11fbKx1Xo222Sbr+aqusu jt666ravZyBhk5YTNmm5Lkmv6Rz3S9Qrx1HxJQGgtLTorvM9P3gxUwd/oNvnVs4tVn28ioj1 ETz14lME9g/UbSsrLSP9cjppl9JIvZTKtYxrZF7NJPVSKqlJqaRfTmeNag2dOnWSwZii2UlL TmPa2GmEfxRO30F9Aeg3uF+DnvONf7+BVQsrevfrTdS+KMY9Pa5Bz9cUZF9K0D32f+qv3EyM 13WBuRf3oGG6Cvv99q1PGo2GWzm36nWu7JKSEjIzM2nbti3Z2dns2rWLyZMnc/nyZT788EM+ /PBDzp49y0svvURUVBTXrl3j73//Oz/++CPGxsbcuHEDgHbt2vHcc88B5QMsjx49CkCnTp1Y tmwZAC4uLkydOhWAFi1a0KlT49yVFULczWCT9BbFnXUJdUXFuiJRr+imMvzxl3UJckJyNBlZ iVXaeKzzCA6d3PDQsdzvHOlZF2t1PPzZt77C5gPLqj0m40ocTw/9nItnL3Iz6yadunQiKzOL sOfCdEl5Xl4ebu3caNe+Hc5tnGnt0pqu3bsyasIo7B3t+Xnzz7w84WWCejRc5VAIfXQt4xrP j36eeX+fx/CxwxvtvBX9z4MGBhG1t/km6bfSLmLbzpvUqO26bix95y/h5LplxG9cfVd1vDp1 2bc+pF5K5culX3L6j9Os+XXNPffVarSUFJUAUFBQwN69exk1ahQ3btxg6dKlLFq0iCtXrvDM M89w4MABrl+/zrPPPsuBAwfQaDScOHGCyZMnY29vz6BBgwDo2LEjW7duBcDLy4sff/wRgNat WzN37lygPOl+/PHHG+qfQAhRzww2SQeqTGdYXZ/xds6+BHQapqtGV+6qEh4awcZ9H+qq5isj FlTp/12R+Hu4+JV3d7mj/YTkaELmW7BiYfw9z/H7ma26diuOubONyKVF1R5f3fmmdHsXNZ+x f+dt3UwRJiYmFBcXY2NrQ6cunXBt64pLWxfc3N2wtKr+1mRpaSmqnVIhF81P9s1spoZM5cW/ vsjEKRMViaHPwD58+eGXipxbCXfO7lLRr7xCxUDSW2mJHFq6gIy46CrV8cr7Vzzu99qHANXu 23f+Ero98/ALRqnVBXzy70/Yv2M/yYnJWLe05r8R/+XsqbP07tebgvwCVn+6mlcWvkLurVz+ +sxfWbtlLXm38/jps58IGRBCWVkZGzduZNSoUVUq123atOHbb78FymcsOXDgAACtWrVi0aJF QHnSPWrUKKB8xhFbW9uHfk9CCP1h0Ek6oOtyci9j+s+qdgBnQKdh9z22Nvvc7xy1GTxa0/F3 ys66xbpPk+gakM8jXSDrehY3Mm+QcSWDAzsP8E3kN9jY2ty3HSGao9xbuUwZMYXhY4fzwl9f UCwO70e80Wg0pCSl4OHloVgcjSX4zeW6QaL3YtvOu04DP/2f+uvDhFWjC2diyMpaTUn6JZa9 r6GstAyAnkE9aevRlnffeJfe/XqjUqmwsCr/gmDd0pqF75VPqdnStiXPzSvvdmJjY8Pq1eVf UCwsLHRdTUxMTHQDMoUQzZPBJ+nNjYmpGeCMb9dOLPpsgO71stIyLl28REZahiTpQlSjIL+A l8a9RJ+BfZj79lylw+HxAY8TtTeqWSTpTY2Htx82NkMpKT1G8HAXrqWXj+eJiYph2rhp/PeX /wJgYmpC6JzyVWmNjY3x61b9nVAhhKiOJOnNhKmZKT6+959JRojmqKS4hJlPzaSDbwddtVNp QcFB7Nu+j2defkbpUMQdzFWWmJu3o5VzOz76ajJQXgg5n3CeqL1RbN+8nZDJIQpHKYRo6iRJ F0I0a+oyNXNemIOdvR3//r9/Y2RkpHRIQHm/9EX/u6jZT8HYVJiamdLZvzOd/TsrHYoQwkDI lV8I0WxptVre+J83KC4u5qOvPmqwRYoehEtbF2wdbDl3+pzSoQghhFCAJOlCiGbrX6/9i7Tk ND77/jNMzfTvxmKfgX04vO+w0mEIIYRQgCTpQohm6f/e+z9ij8Sy+ufVdVqFtzH1GdiHqL1R SofR6PYtCmN5Tws2vhRc7XMhhGgO9K90VM82H1hWZX7zO925OFBDiz27vdo52yv4egbywSv7 atXWne8tcmntpyYTojlb+clKIn+KZP3O9VjbWCsdTo0CBwTy+l9ep6y0TC8r/TVJjdp+11zn FYsK3U/FIkQ1PRdCXxkbG6PRapQOQzwgjab8Z6dP3R4NvpI+pv8sViyM1z0PD43QLQ7UUDYf WEbIfAtiz26/a1tAp2FVkunQsUuIXFpE5NIihj/+Mh4utZ+ia0z/WYSHRtRLzEI0F+u/Xs/a L9ey5tc12Leqv6XbG4K9gz0e7T34I+YPpUOptX2LwnQJ+pRN8YTFFDFlU7xuUaGT66pfJblC t2dmEfJpRI3PH9TJdctY3tOC1Ki7r8tC1AcLcwtKSkqUDkM8oKLiIoyMjFCZ689Cjk2nNFOP Nh8o/5AIHbuk2hU8w0MjuJJ54a4KfOjYJRw6uUG3CumdIpcW6VY4BXQV8/tVuCuq6+GhEazf +V6VVUfvbL/y/kKIuvl1w698/O+P+WHHD7RxbaN0OLUSNDCII/uO0PPxnkqHcl+30hJ1Ve++ 85dg2678LqVtO2+mbIpn7fjy6+3Jdcs4tLTq9bUuq4BWV6mvWOSoum3WrduSd+0y8OeKpGEx RTXGAdz1OkDIpxG4Bw2rVYyi+XGwcSA7J1vpMMQDyrmVQwvLFnqVpOtVJd3YyBgaePaz8JVj WRmxgEMnN/BY5xFVtg1//GWgajeSFQvjdZX4lRELeGrIQnw9A4HyrimVE/DNB5YRNmm5bntF 1f5eVkYs0CXcro4d+OCVffdsv3KCHrm0qMEq6RqNBiMjI5n6Teilit9LrUZb62P2btvLvxb8 i28ivmlSCwT1GdiHw3ubxuDRW2kXdY/tPaquy1CxWqi9h48uAZ6yKZ4pm8qvr4eWLqhVlbty Eh4WU6RLqvctCquybcqmeN02jz7DcPEvv66GfBpBWEwRqVHba4zD6I7rnt+E8s+G7JQLtf2n uCeNuvy2ulxfDUvb1m3JuJqhdBjiAaVnpNPWqa3SYVShV1cIc3PzBr9VFB4aQejYJfTtNgkX R29dtxdfz0DCJi0ncmkRAZ2G6V5zcfSu0mf9SuafF+m+3Sbp9qvJ6/8XTMh8C92fjKzEKttD xy7RJdrpWRerbKuu/Yrz3+uc9aHi56BP3yiFqGBuZo6RkRHFJcW12v/YoWO8PvN1Vv28io5+ HRs4uvrVq28vTp04RUF+gdKh1El1CW3lrjAu/oHYtvPWVdtrOuZe7S7vaaFLtG9ejNdtq2jb s+8IpmyKJ/jN5TW2U10cWo1Gl+C7+AcS/OZywmKKal3pv5/ikmKM0K/b6uLh+XXw49KlS7q+ zaJpuXjxIl18uigdRhV61d3F3MycspKyBj/PmP73vtC6OZdXgBKSo+9Kqh/rPIJDJzfU+ly1 GQRa0U9984Flte7GUl1s9Uk+RIQ+U5mrMKJ2SfqpE6d45flX+GL9F/gH+DdCdPXL0soSv25+ xB6Jpd/gfkqHc0/uQeUV64y4aA4tXYC9h4+ue8i+RWHEb1yt63qSERfNrbSq1zDPviOqa7aK yhX6KZviqyTXFZX4jLhoUqO237NrSkU7NcWRfGjrfWN5UBXXVwuVfs4qJB7MI+0fQVOq4XL6 ZdzbuisdjqiD7FvZ5NzMwc+n9uMCG4ORVqut/f3iBrbnyB42HtjI3FlzH2p0bf+O32HRoiUf rp1Z4+wuFUnxndsqZnupblt4aATRpzfr+pxXp7p9wkMjdNX5h+1Pfr8Yvnv7JlMHf8CTL3Zi 0WcDHvg8iZcSifglgv99+X9xdXZ94HaEaAharZa3PnqLnLIcFryyoMZVQi8kXGDq6Kl88OUH ep/g3svH735MUWER//vv/1U6FJ3ZU3ax5edENhx5G1OzqtfrioS8OjX1+a7o711dP/Hq2rhz n4rZY2qaWcahg1+VmEI+jSA75UK1cVT3+p1fCP5n3Ke0tIMtv0++Z6zV+XXbr1xIuMDMyTPp 3EFWKDUk32z6hszCTCZPqPvvhVDOtl3bKL5ZzJypc5QOpTIXvUrST58/zecbPuflF1/Gwd7h gdupnKQ3N7k5BfWSpP9+/HcOHzjM4gWLMTM1q8cIhagfH371IeczzhM2I4yWLVvetT0tOY2n hz7N24vfZvjY4QpEWH9+P/w777z2DpujNisdis69knRDd+l8HP+avRJrG3O+2/YsdvZ2WFlb 1fr4Nd+vITszm4WhC3Fu5dyAkYrGdvPWTd758h3GjRuHh3vTGfvSnF3Pus63a79lwdQFuLvq 1R0QF73qk97GqQ0mRiZczbyqdCjN3tXMqzjaOEqCLvSWa2tXTIxMuJx++a5t1zKu8fzo55n7 9twmn6ADPPrYo1xKvEROdo7SoQjA1b0Dt2/vJTnpM8b0GcPg7oMZ0HkAg7oNoo9PH75e/jUl xdWPr1Kr1VzNvIqVuRWt7Fo1cuSioTnYOtCnWx/27N9DWVnDd98VD0ej0bB7324e9XlU3xJ0 QM8GjjraO+LQ0oHklGSlQ2n2UpJT6OjZtAbYiebFq50XJpiQcjmlyuvZN7OZGjKVaf8zjUnP T1IouvplZm5GQGAA0Qeqn/5VNC6VhRVOTjNo4zoeqxZWZFzO4ErqFdp3aM83kd/wYtiLmKvM qz32cvplUIOnm6deLZoi6s+oAaNQaVT8tu039KizgqjGnv17KLhZwIQhE5QOpVp6laQDdGjX gdTUVPnFVlDWjSwKCwrxdm+8lViFqKsOHh0wMzHjYuJF3fUi/3Y+08ZMY2jIUKaFTVM2wHrW Z2Afjuw7onQYohJ7h0B+3vczgf0DMTYx5tHHHiUmKob33nwPKK+a3+n8hfOYGpvi4+lz1zZh GCwtLAmdHMq1y9fYvX+35DN6Kvr3aM6cOsP0SdOxs7FTOpxq6V2S3q1TN/Jy86q9hS0ax6kz p7Ays9K7Uc5CVOZg64B3W2/yb+eTnJJMUWER0ydNp3ff3sz/x3ylw6t3QQODmsx86c2JU2sn 1v62lql/mcqP3/zIk9OeZM7fygef/XP+P4lY/+daFmq1mjPnzqAyUdHDr4dSIYtG4OTgxMzJ M0k5l8LPET/LSqR6RK1Ws2X7Fk4cO0HoxFC97OZSQe+SdN8OvthY2XD6zGmlQ2mWNBoNZ8+e xc/bT6YHE3qve+fumBubE3M8hhlPzsDD24OF7y1UOqwG4dvVl+wb2Vy9ImN29I2JqQlvvf8W //nsP5w6fgqrFuWDSN98702GjBoCwAtjXmD7lu0UFxTj3c4bG2sbJUMWjcDDzYO50+aiydOw 5vs1XEisn8WwxINLvZzKt+u+JetKFq9OfRVfb1+lQ7onvZonHcDUxJRefr3Yc3wP/YP606JF iwdq59bNPH7+5lA9R6f/SgpLH+r4hPMJFNwuIPDRhl0sSYj68Jj/Y2zbv43PF32Ot5c3//6/ f9c4HWNTZ2xsTO9+vTmy/wjjnx2vdDg6SWczMDHVu3rPA7mVfY3UpDi69BiEkdG931NpaRl3 foQGDQyq8tzC8s9Cx8f//Zgff/kRM60ZH/3zI6aETMHa2rreYhf6ycHWgTlT57ArahfbfttG TJsYHu32KF6eXqhUsg5JYygrKyMpOYm403FcTrlM3259GTFgBC0sHyy/bEx6l6QDBPcO5uCJ g0T/Hs2g4EF1Pt7a1py8y/lEfHuwAaLTfzZ2Kiyt6v6j1Wg0HDl6BC9XLzp5dWqAyISoXybG JkTviEZTqmHI00MMfiBen4F9OLz3sF4l6a+/uErpEOqVhvVoeQUjumPM40DNdxQdnGo/VXDG 9QxysnPwdvFm+7btWFtbk5yczMyZM9m+fXs9RC70lcpcxajgUfTp0Yfth7azb/c+tpZuxa2t G87Ozti0tMHKsvZTeIr7Ky4p5tatW1y/fp20tDTMjMzw7+DP1OlTm9S0p3o1T3plG3dsZO+J vbz0wkvY29krHU6zEPtHLPv37ud/nvwfvb8FJATAnDlzOH78OMHjg8kqzGLi+Il08OqgdFgN 5tKFSzw7/FmOJCo/gDT1Ui65Ofdf8bWpKSooYNbUZ7mWnk5rV1fc23sxacoLdO7W7a59VRam +Pje//OpuLiYL7/+EoogdHKo7vqq0WhITk7Gy8uL3377jV27dvHRRx/V+3sS+kWtVpOYmsi5 S+fIvJlJzu0c8gvzlQ7LoFioLLBvaY+TvRM+nj50bN+xKU4prV+LGVVWUFjAf1b+hxatWvDk hCcN9ha2vigoKGDVf1fR1aMrL058UelwhLivd999l19++YU9e/aQdCWJbyK+wdjSmOlTp2Np aal0eA0myCeI77Z8R3uf9kqHYrCi9kYx+4XZ3Lh+AyMjI1ratMTdy51/LPkHPYN61rm9yG2R nDtzjl6+vZg6fmq1+xQVFZGamkrHjh35/PPPadGiBVOnVr+vEKJZ0K/FjCqzsrRi/ODxXEm9 wu/Hf1c6HIOm1WqJ2BKBykjFuMHjlA5HiPtaunQp6+3ivHkAACAASURBVNatY9u2bdjY2PCo 76P06NSDkvwSIrdFGvSUZ0HBMstLQwsaGMSI8SMwNjZm5ISR/HLwFzbs2fBACfqp+FOciT+D o7Uj44fW3E3JwsKCjh3L16YYN24cAwcOBGDBggVERUU92BsRQjRpepukQ/nMDX38+3Dg4AFS 0lLuf4B4IPsP7ScjNYNnRj6Dva10LRL6bfXq1Xz22Wfs2LEDR0dH3euTR0zGxd6F5EvJ7Nq7 S8EIG1afgX2I2idJW0MLXxpOt57dMDI2IjY6lmX/WVbnNlJSU9i6YytWplY8G/IsLVu0rNVx Li4utGvXDoDQ0FD8/Px0jzMyMuochxCiadLrJB1gwrAJeDl7sTFiI9euX1M6HIMTcyKGmN9j GBI4BP9H/JUOR4h7+vHHHwkPD2fHjh24ublV2WahsuDFSS/SyqoVx08cZ+/BvQpF2bCCBgYR vT8ajUajdCgGzcTUhMUrFlNWWsbYp8by0uyXgPIFs2oj7UoaG37ZgAoVYwaOoWP7B1vB+ZFH HsHW1haAyZMn07p1awoKCnj66aerXSxJCGE49D5JNzM1I/SpUFq3bM1PP/9EZlam0iEZjLj4 OPbu3cvjXR5n9MDRSocjxD1t3bqVOXPmsHXrVry9q18N18XJhWkTpmFjbsOxY8fYsmOLwXV9 ae3SGgcnBxJOJSgdisHzfsSbuW/NxczcDHsHe65fu86EgRPumxyfv3ieH376ARO1CQN7DWRA rwH1Es/QoUMxNjbGxMSEGTNmYGJiQmJiIv/85z/rpX0hhH4xCQ8PD1c6iPtRmavw8/Ej4XwC R2KP4NLGBTtb/VzCtak4HH2YA/sP0Ltzb54Z/QzGxnr/fU00YwcOHGDKlCls3ryZ7t2733Nf B1sHvN29OX/xPCmXU7icfpn2Hu0xNzdvpGgbXuK5RG5l3yIgMEDpUAxeK+dWusctrFsw4ZkJ qCxUXL92nRbWVedZ1mg0RB2NYsfuHahQMbzPcEYGj6z3iQ9MTU1p37584HBZWRkqlQovLy92 7txJVFQU3aqZiUYI0eQsbRJJOoClhSXdO3cnOSWZQ78fwsjYiLaubWXWlzoqKipi85bNxJ+M Z0jvIUweMVkSdKHXYmNjGT9+POvWraNv3761Osbe1h5fb1+SU5JJv5bOH6f/wMrKCmcnZ4O4 ZpSUlLBl4xbGPSMDvRubuar8y96caXPwfsQb5zblcy5fu36NjZs3cjbhLC3NWjJx6EQGBg5s 8N+3Fi1a4OXlBZR/SbC2tsbNzY0ffviBvLw82rZt26DnF0I0mKV6OwVjTcrUZfy651f2xuzF sY0jw4cMx8nRSemwmoSEcwns3rsbU7UpTw5/kh5+PZQOSYh7OnPmDIMHD+bLL78kJCSkzscX lxSzaecmjp46SpG6CFc3V57o/wRurm73P1iP5d7KpU/HPsSmxuqSRtG4NBoNxsbGXE69TNSx KC6lXcIcc9o6tWXK2Cm4OLkoGt+uXbto27YtnTp14qOPPmL8+PF4enoqGpMQok70d570+4m/ EM/PO37m+u3rdO7SmaBeQdja2Codll5KvZzKoahDZFzOwNfTl8nDJ+PkIF9shH67dOkSwcHB fPjhh0ycOPGh2jqbdJZNOzZxNfsqxZpi3Nzc8O/iTyefTk12ae4xfcbw9gdv81ifx5QOpdnR arWkpKZwOuE0m9dvJi87j/6D+zPo8UEMDByIqYl+Leb97bffEhISgp2dHYsXLyYsLAwrK1nh Ugg913STdICS0hJ2R+1mf8x+8svyad++PV18u+Dt5W3wy4PfT0FBAWfOneHM2TNkZmTSxq4N o4JH0b3zvfvzCqEPMjIy6N+/P3/729+YNm1avbSp0WiIOR3DrsO7yMzJpFRbitZYi6eHJ57u nji1csKxlSMtW9Zumjylvf/W+6gsVLz61qtKh2LwSkpKyLqRRdbNLNIup5GUnERBXgFmRmZY mVsR1D2I4N7BxByL4YknnlA63BqVlJTw4Ycf8sYbb5Cfn8+KFSuYN2+e0mEJIarXtJP0CoVF hRyKPUTUH1Fk5WZhbGZM27Zt8XT3pE3rNjg6OBr0CoQAt3JvkXUjiyvpV0hOSebatWuYYoqn iyfBvYLp1qmb9D0XTcKNGzcIDg5m+vTpzJkzp97b12g0nE8+T+zpWOLOxVFcVkyZtgwNGtRa NaampqhUKkxN9asaeqfks8kc2XaEZ159RulQDJZWq6WouIiS4hKMMcbYyBhTI1NMjExo79ae nl160q1TN6wsrbh69SoLFy5k9erVTeJae+3aNX755RdmzpzJuXPnSEhIYNw4GeMghB4xjCS9 glarJTE1kbNJZzmffJ60zDTK1OUfvlq0mJqaYmyi/xfPulCXqlGr1RgZGWFiZILKVEUH9w74 uPvQpWMXnFs5Kx2iELV2+/ZtBg8ezJAhQ3j33Xcb/HylZaWkpqeSmJpIemY6N7JvcCvvFsUl xZSpyxr8/A+jrLSMz9/9nL/87S+YmZspHY7BsrKwwsrCCgc7B5xbOePt7o2nmyc21jY1HrNh wwYGDx6MnV3TmIXs+PHjnD59mqlTp3LkyBHMzMzo2bPuq6sKIeqVi36XiurIyMiIDh4d6ODR ASj/AL6WdY3MG5ncul3+wavWGNbiD2amZqjMVTjYOtDGqQ2t7Fo1iSqOEHcqKipi7Nix9O3b t1ESdCj//+Pt7o23e/Xzruu7k7tPMrLXSIYPH650KKKShIQEevfu3WSS9B49etCjR/lEAjdu 3MDCwgKALVu24O/vLzPECKEQg6qkCyGaptLSUiZOnIizszMrV640iGkSG8M777xDbm4uixcv VjoUUY3Dhw+Tm5vLiBEjlA7lgXz00UcMHjyYrl27snnzZgYOHNhkxmwIYQBcpOQqhFCUWq3m mWeewcLCgi+//FIS9DoYNGgQu3fvVjoMUQMzMzPMzJpuV6S5c+fStWtXtFot27ZtA8q7la5f vx6NRqNwdEIYPknShRCK0Wq1TJ8+nYKCAtauXdvsZ2Wqq169enHp0iWysrKUDkVUo1evXgwe PJjr16/zyiuv0FRvXBsZGfHZZ5/RsmVLcnJy2LVrF8bGxuTm5hIVFaV0eEIYLEnShRCKmTt3 LomJiWzYsAFzc1mUp65MTU3p06cP+/btUzoUcQ8tW7Zk2LBhBnGXyN7enpUrVwKQnJzMr7/+ qnt89uxZJUMTwuBIki6EUMSiRYs4dOgQkZGRsrDKQ5AuL/rPwsKC0aNHAzBlyhTOnz+vcET1 w9/fn0WLFgFw6tQp9u/fD8CFCxfIzs5WMjQhDIIMHBVCNLoPP/yQVatWsX//fpycZPXbhxEX F8ekSZMMJvEzdCdOnMDf39+gu3YtWrSIrl27EhISQlxcHB07dtTNGCOEqDXDmiddCKH/Vq9e zb///W8OHDggU7vVA61Wi4uLC0ePHsXDw0PpcPSG0avlXUsuvHWBDo4dFI7mbsuWLaO0tJS5 c+cqHUqDmjp1Km+//TY+Pj5cvHiRDh3072chhJ6S2V2EEI3np59+Ijw8nB07dhhcgr41YStG rxrd9WfmjzMb9LxGRkYMGDCAvXv3Nuh5RP2aNm0aU6ZMAaC4uFjhaBrOmjVr8PHxobi4mClT plBQUIBGoyEpKUnp0ITQe5KkCyEaxdatW5k9ezZbtmwxyGraCN8RaD/Wov1Yy4ygGbrXV0St 4GLWxQY996BBg9izZ0+DnkPUL2tra5ycnEhKSmLgwIFNduaX2lKpVERHR2NlZUVSUhKzZ88G oKCggLy8PIWjE0I/NavuLhezLuLzrg9Qf7dAG6JNIQzNwYMHmTRpEpGRkfTq1UvpcBpU5WvC jKAZrIhawYygGXz55Jd37dvnkz5EXap+CrstM7cwwndErfZdPXI1b7/4NleuXAFg5o8zWRG1 oso+Qe2DODzncIPFUFt3/lvUJtaKris1qXztvd++ANqP9etj79atW9ja2ur+bk4iIyOJjIxk xYoVZGdnY21t3aTnlq+L0rJSrl6/SnZuNmVlZZSUligdkkEwMzXD1NQUu5Z2tHZsjYWqyY6H cDFVOoL7qXzBremDztAo3ZdS6fMLw3L8+HEmT57MDz/8YPAJOsBv8b8B5dercV3HsSJqBSui Vtx17apIeD8e/zFzBswB4JP9n/DqplfvavN++7q0c8Hc3JyzZ8/i+4UvUDXRrdjX6FWjKv+v 6zOGLTO38MupX3QJt/ZjbZXrd8XzFVErGNd1HCN8R+i23y9W7cfaKl8QKl7fmrCVkV+OxOdd nyr7QtO6jtna2qLVahk9ejRfffUVPj4+SofUaEJCQggJCQFgxYoVqFQqXn31VfLz82nRooXC 0dW/7FvZHD15lFMXTnEl6wpqrfr/sXfvcVHV+f/AXzNcxQuIqIESIKDihTQ1cbwho6J4N1Nr rexr6q+0dLtZrZVbba2aLZa2idXWrq1mpnnJu4QXkEzTvKEBApkiiqCoMNzm/P5gz3EGhqsz 85kZXs/Hg8cDZs6cz2tGGd7nM+/zOWjatCmcnZ0bzcGJpZWXl6OstAy3bt+CWlLDr7UfOgd2 Rr+e/dCmVRvR8erFokW6/AZaWX2KbSlWqvaPRn0ZvoGbiyX2SeQoUlJSMHr0aKxevRpDhgwR Hccq5Peql6NeRohPCDRBGiRlJGH5/uVKcVudeYPn1bpNddtGRUXh6aVPA82rzkTL283fNB9L 45fW+P57Lxm+P/U9gIqCHbj7SULlnwEovfr1zbp99nal6B4ZNlLZZ+o12y/Ga6JSqbB37164 ubkhNze3YibQy0t0LKtasGCB8v0TTzyBOXPmICoqyiEK9lt3bmFP0h4cPH4Qni090alTJwwc NhA+3j5wdrb5+VK7VF5ejrz8PGT+nonTv51G/NF4RHSPQPSAaHh7eouOVycW7UkX2aNJRGJl ZmZixIgR+OCDD5SZMke3I2UHgIrCUy4YFw5fCABYf2K90baJ8xKhCdIos8aGX5XfH+uyrVar ReL+RKMxDcnFr2Fribkz1Ieco65ZGwM3NzcAwLp16/DVV18JTiPWt99+i8jISEiShD59+iAn JwcAUFRUJDhZ/R0+fhiLPlmE0xdPY+zYsZj++HT0e6gf7mtzHwt0C3JyckJrn9bo82Af/Gnq nzB58mRk5WfhnU/fwZ7EPXZxHohV/nek5aYpb7byrEd1szm19TzWtSfScLbe1Ex85V7L+vQ8 1nWfdc0tP65yBrmv1ZDhrL3h9pogDSb3mGyUyfBj6eoyG85i1Xf86vYJVH296puV7Ft2djaG DRuGV199FY899pjoOFbz7u53AQBJGUlVfp+SMpKwI2WH0XtE5R5xuZ899N3QKu8ntW2r1Wrh PNMZZVKZyU8wKz9W/v00Z4b6kD9hqE/WxmLu3LkAKmYCk5OT0b9/f8GJrE+tvjuHePLkSTg7 O+PatWvo16+f0TUBDLezNXq9Hpv3bUbC8QQMHToU3cK6OcRVZ+1VO792mDppKtIupGH7zu24 knsFU0dNhYuz7bYZWeV/d+UeTcD0DIlqvgpJGUmYpZmlzMBXljgv0WhWvvI28s9xSXHKrNa8 wfOU/WmCNCYzVr4vdWEqpFhJ+cMT+m6o0WxRXfYpM+zllB8TOyHWZAbD5yNnMPyqvH3qwlTl j51c9KYuTAVQ8XGxnLn/8v7K/YYZkjKS0H95/waNb2qfhq/X8v3LG5SV7FteXh6io6MxZ84c PPPMM6LjWM2OlB3KgXjl3xv5PUtuB5GXa5R/92QhPiHK71B9t23bti182vgAVysO/CtnMPyS +7nNnaE+JveYDKBuWRurrKwsfPHFF3Yx42dJ8mxz69at8euvv0KtVuPQoUOYOHEigIqDGVsj SRLWbF6Dw2cPY+rkqejepTsLdBsR0iEE0x6dhnOXz2HVulU2+f9HZpUi3bBHc2TYSKWoNSzi 5P7E2AmxRjPsNRXBhn2Opn5uKFM9jwCQei31nvZryLDIr272va7kwkA+CJD75A3/wCXOS6xS aI/qOsro8fWxfP9yJGUkQROkMdrnyLCRRoV3Q7KS/bp16xZGjhyJ0aNHY/78ez+PxJ7IRaqp A3D5Pa1yq5/cqy5Ly01TZpblCY36bDt57GTgIhCzKsZoW6Did9ZUe4q5M9SV/MlZfbLWh/x3 Y2n8UrPu15o6dOiAzz//HCqVClu2bEFhYaHoSMLJvemDBg3C119/DQBYuXIl/vrXv4qMVcXe pL04kXECUydPhe99vqLjUCXeLb3x2OTHcDHvIjbu2Sg6TrUs3u5SXY9mzKoYrD+xXnmjPp19 GpogjVI4GprcY/I9L/slUuK8RGXWuXLhao6VB+Q/RjW1ixguC2cOZ3POAjDdT2p4slzlj/fr kpXsk06nw7hx49C/f3+89957ouNYlWFri/x7Lh+8Vl5iMPTdUER3jq6yvaHq3hdq2zYqKgrn zp3D7aDbJrc1bG8znHQwR4Ynv35SeZ+OWRVjdLBi6mf54Ly690Y5a1pumtHrG7MqRmlnNGwj lMeQ31sS5yUqq8kYvv7VLUVpyyRJQkJCAvr27QsPDw/RcWyGXLDPnTsXBQUFAIBnnnkG0dHR GD++fgeN5pSSnoIfDv2A8ePHw7ulfZyg2Bg1bdoUEydMxLpv1iHALwAPhdve6mMWL9Lr26Pp qOrT92luhn3jhn94zV24U+NVWlqKKVOmoEOHDli2bJnoOFZX0wpPqyavuqelY+UT8OsiMjIS jz/+OK5tuaachGiO/dZl2+oK38rPvfLPtRXMNa2gVdtjHWXlLZVKhQ8//BAAkJCQADc3N/Tr 109wKtuhVquVlXA++OAD5fYhQ4Zg5cqV6NKli9Wy6PV6bNq7CT179URgQKDVxqWGadu6LQYM GIAtP25BeKdwm1tT3aLtLvXp0ezm2w1JGUlK/7qhyqsi2BNL9HLWl/z6Gbbx3KsubSve9OSD MENpuWnKv3tjOABr7PR6PZ566im4ublh1apV7LsUyNPTE2FhYUhOThYdhSyktLQUpaWlomPY rKZNmyoz7P/5z3/QqVMn6HQ6REREQKfTWXz8w8cP44buBjR9az5XjWxHz/CeUDdRIz7Z9q7a bNEivT49mvLP8zfNV/rTAfNc4c4W1KeX09y9lN18uwEwPhioaRa9LuPPGzxPaWkx/IRkR8oO Zb/1Xe2B7I8kSZg7dy6uX7+ONWvWwMnJSXSkRk+r1WLfvn2iY5CFDBs2DIMGDcKlS5dsrg/b 1rRv3x5OTk5wd3fHmjVr4O7ujvPnz2Ps2LEWGU+SJOz7aR/69OnDCxPZEbVaDU2EBglHE2zu qq8qyUKnjZta0rC6Hk3g7hJ89S3KYyfE4mzOWWV/lX9OXZhaa0tHVGgU4lONj6BM9TzK+x/V dVSt+5QfX90FnWTV9X2aev1MXZWvtvFldXldDfs5axtfVpclGOublezHn//8Zxw7dgw7d+5k r6yN2LdvH958800kJtpX3zXVT0FBAXbu3InJkyeLjmJX9Ho9MjMz0aFDB2zfvh3Hjh3DG2+8 YZZ9p/+ejo/WfoRnZj8Dd3fbapugmun1evxz1T/xWPRj6Nmlp+g4Ml+LFelE5Njef/99bNiw AfHx8fD09BQdh/5Hp9OhTZs2+OOPP9CiRQvRccjC9Ho9ZsyYgXfeeQft27cXHceu3LhxA1ev XkXHjh2xfPlytG3bFlOnTm3w/rb9uA1ns89i8kQeONmjH3b9AE94Ytq4aaKjyHxt9yoARGSz /vGPf+A///kPdu7cyQLdxri7u6NPnz44ePCg6ChkBWq1Gk8++ST8/PxER7E7Xl5e6NixIwBg 0qRJGDhwIADgjTfewPHjx+u9v9+zf4efL/8d7FX7du2RmZ0pOoYRFulEVC9ffPEFPv74Y+ze vRutW7cWHYdMYF964xIZGQm1Wo333nsPX331leg4dqldu3Zo164dAGDUqFEICgoCAEyfPh25 ublVtv/mm29QVlZmdNuVvCto5d3K8mHJIny8fZB7Mxd6vV50FAWLdCKqs2+//RZvvfUWdu/e zY/WbRiL9MZp1qxZykmRtlRo2JuIiAh4eXlBkiQ89thjaNWqFe7cuYNnnnlGufrrjRs30LFj R/z222/K4+4U3eG5OXbMo6kHysvLUVRcJDqKgkU6EdXJzp078fzzz2P79u0ICeHVYW1Z7969 cfHiReTk5IiOQlbk4+ODli1b4uTJk4iJqX7BAqoblUqF4cOHQ6VSQZIkjBgxAiqVCmfPnkVu bi5atGgBrVaLt956C0DF8pguzlzVxV65OrsCgE0tccoinYhqdfDgQTz55JP4/vvv0b17d9Fx qBZOTk4YOHAg9u/fLzoKCRAeHo5///vfAIBbt24JTuMYmjVrhnHjxgEAWrZsCW9vb5SXl+OP P/7A0qVL8fDDD9tUcUcNZ0vrqbBIJ6Ia/fLLL3jkkUewdu1a9O3bV3QcqqOoqCi2vDRibdq0 gV6vR2RkJC5fviw6jsNIT0/Hs88+i7/85S8oKCiAt7c3JEnCxo0bsSZ2DU7/clp0RHIgzqID EJHtSklJwejRoxEXF4eoqCjRcagetFotPv74Y9ExSCC1Wo2kpCS4ubkhLy8PzZo1g6urq+hY di04OBibNm0CUNGXnpubi7y8POTk5GDxp4tx9tezGDB4ADyasTed7h2LdCIyKTMzEyNGjMDS pUstdoU+qjtTF4GTmbogWNeuXXHnzh1kZmYiMDDQCgnJFrm5uQEAPvroI7Rv3x5PP/204ESO w8vLC15eXsrPe07vweSpk1mgk9mw3YWIqrhy5QqGDRuGV199FX/6059Ex2n05AJdE6SBFCtB ipWwffb2Gh+jUqkwZMgQxMfH17gdNQ5vvfUWZsyYgbKyMpw5c0Z0HCKqA86kNzJpuWkIfTcU AJC6MBUhPlylg4zl5eVh+PDhmDFjBp555hnRcQhQZtC/+tPdNbBHho1E7IRYzN80v8r2yqz7 NWDtkrWYcXIGNEEaJM5LNNpONV+lfK8J0mByj8lG+4udEAsAVcaQZ+4NHy+TYiWTs/4NHX/e 4HlVxqD6U6kqXuszZ87gH//4B7788kuxgYioVpxJ/58dKTugmq9SvtJy08y6f3vbLzVOt2/f RkxMDEaNGoVXX31VdBz6H02QBgDw5NdPGt0+b/A8SLGSUauLar5KmXXP/CwTbW+0xT/G/wNJ GUlV3iukWAmpC1OhCdIgKSNJKZBTF6YCqCjOR3UdBSn27moHqQtTlfGkWEkp5GdpZkGKlYzG l2f9YyfENnh8vreZ1wMPPKAU6Nu2bUN5ebnYQERULZso0mevn21UIKvmq7AjZUet95nTyLCR kGIlaII0yh9ERxTiE6L84eQsOhnS6XQYN24c+vXrh/fff190HDKQOC/RqNCt7v1w9vrZAO7O WgcEBKBp06YY1nqYUkwvjV9aZf9JGUkAKmau5feGyu8T1T1eLqxfjnq5yviyeYPn3fP4ZF5l ZWVYv3498vPzRUchomrYRJG+avIqpThOXZgKKVbCyLCRyn2GszWxE2KV+4jIPMrKyjBlyhQE Bgbiww8/FB2HTJBnzQ2/ACBmVYxSHMstJguHL1Qep9VqER8fr7SNmDr5VH7/ram1xPDx8uz2 8v3LAVTMoof4hJgc39TjGzI+mZezszP+/e9/w8fHB/Hx8Th9mksHEtkam+lJ7+bbDXFJcUi9 VtEnLfcqyr2PZ3POAgA6tumoPGb5/uUm+zEr91o3tO/R1P4Nt+2/vL8yA1TZ9tnbMTJsZJWe Tbkf3JDhR8nVjVt5Zqq++zW1TzljZXV5XU31ola3Ldk2vV6P6dOnw9XVFXFxcUrvKtm+1IWp CH03FHFJccpkR1JGEmJWGVxt8g8A+4Dn059XbkrLTWvQ76fcA780filWTV6F9SfWAwDGdx8P AKbHN6Gh45NlXLt2De7u7qJjEFElNjGTbui3q78ZfXwrz7qczjY+yu+/vL9SSFZe7SD03VBl hke+vyF9j6O6jlK+3z57O6RYqUqBLn88azjbb8hwxkse09RsWE3PS/6Yu//y/g3er+EsXE3t PHV9XSvvRx7fcFv2ktqHuXPn4vr16/j666/h5OQkOg5VIp8vI8+W12Ryj8kA7r5fSbEScr7M gVeeF8qWld1zC4nhbPjy/cuRlJEETZBGOdg3Nb6pLxbotmXKlCnQaDT4/fff+UkakQ2xmSK9 S9suAICzOWfx/anvje7bkbJDmbEObR1q9MfBsBgdGTbSqPCurD59jz+c+cFoFZS6tNgYFsIN bclJnJdYpciWDxaqm7U3l4a+rttnb1dev5FhIzFLMwsAkHot1aJ56d69/vrrOHXqFL777jte 5MTGxSXFGRXqhis1yRMEchEdsypGOaBu06YN/P398crqV8xyonnlFV/kwry68WXL9y/nie42 zsXFBf7+/qJjENH/2Ey7i9zGcjr7tFKMztLMQlxSHN7d/a6yXYhPiNL6YqrvMcQnRJkx35Gy w6hYlmd+a+t7TMpIUjJU17aROC9RmXWuXLjeS6uH4R9ea2vo60r26e9//zt27dqF+Ph4eHjw 4hv2IC4prkpPd+W2NSlWqvre5Ayc+s8paCbfbZsz1dZm2MZm6gJJQMX7p+HjKr+fmhz/fwzb 9ho6PlmOr68vHnnkEZSWluL555/Hu+++i1atWomORdRo2UyRHto6VCkCgYo385ejXkZcUpwy uyuC3CNvSuU1f+UCO/Td0Gr7vWti+EfLsNAXWbiTY4qNjcVXX32FAwcOwNPTU3QcqoG88lR9 VH5v2rZtG2JjY7F33l7ltnmD5zX4RM3a8lQe35R7GZ8sy8XFBSNGjIC3t7foKESNms20uwDG 7RyTe0xWZm8r3ye3xhjOsMvSctOUbRs62yuvMgMYr5wgk3tEDXvEgYrZZrknu3LLTl3IJ2EZ to9Yk6VfV7INX3zxBT766CPs2bMHrVu3Fh2HaW4NxAAAIABJREFUrGDw4ME4cuQIioqKREch OzFu3DioVCq8/fbb2LZtm+g4RI2SzRTplYtSuf3FsN+xm283ABUzMPKsu+HHoztSdigzzrVd MrsupFhJabkxtZpJUkaSUd9lWm6asqqBvNqBTD7YMFwjuHKPpvz8DAv82mbR67LfurLW60ri bNiwAW+++SZ2796N9u3bi45DVtK8eXN069YNhw8fFh2F7My0adOg0TjutUOIbJlKkqT6fY5q QYZLGsofp+5I2aEUvpWXSqzLUoHVbSOT+x4NxzHch6nLWz836Dl8fODjavdZXU+6qUK/8tKK NS3rKKv8OtS237q0yxj2f9b2upran/z4yvl5WW/bsXPnTjz11FPYvXs3unfvLjoOWdkbb7wB SZLw7rtVPykjqs3hw4fxySef4D//+Y/oKDbr+fefx9SpU+Hn6yc6CjXAnTt38OmqT/H2nLfR 0rOl6DgA4GtTRToRWcahQ4fw8MMPY8uWLejbt6/oOCRAQkICXnvtNc6mU4Po9XpcvHgRAQEB KC4uhpubm+hINodFun2zxSLdZtpdiMgyjh8/jkmTJmHt2rUs0BsxjUaDlJQU3Lx5U3QUskNq tRoBAQEoKSlB7969kZ+fLzoSkcNjkU7kwM6dO4fRo0cjLi4OUVFRouOQQK6urnjooYdw4MAB 0VHIjrm6uiIxMREtW7bE9evXUV5eLjoSkcNikU7koDIzMxEdHY3Fixdj7NixouOQDYiKisK+ fftExyA716JFCwDAO++8g02bNglOQ+S4bGaddCIynytXrmD48OFYsGABpk2bJjoO2QitVov/ +7//Ex2DHMSHH34ItVqN0tJSXLp0CYGBgaIjETkUzqQTOZi8vDwMHz4c06dPx7PPPis6DtmQ Bx98EJcvX8aVK1dERyEHoFZXlBBHjhzB22+/LTgNkeNhkU7kQG7fvo2YmBjExMTg9ddfFx2H bIyTkxMGDRqEH3/8UXQUciD9+/fHF198AQA854HIjFikEzkInU6HcePGoWfPnnj//fdFxyEb pdVq2ZdOFqHT6bBixQoUFBSIjkLkEFikEzmAsrIyTJkyBQEBAfjkk0+gUlW9wBURUFGkx8fH i45BDsjd3R3r169HixYtcPDgQVy6dEl0JCK7xiKdyM7p9Xo89dRTcHV1xerVq1mgU43CwsJQ UlKCjIwM0VHIgR0/fhwXL14UHYPIrrFIJ7Jzzz33HK5du4avv/4aTk5OouOQHRgyZAhbXsii nn/+eURERCArKwtffvml6DhEdolFOpEd+8tf/oKTJ09i48aNcHV1FR2H7AT70sladDod3Nzc RMcgskss0ons1OLFi7Fjxw5s27YNHh4eouOQHZH70iVJEh2FHFynTp3w6KOPQqfT4bnnnsPt 27dFRyKyGyzSiezQp59+ii+//BI7d+6Ep6en6DhkZ/z9/eHp6YnTp0+LjkKNhKurKwYNGoSm TZuKjkJkN1ikE9mZf/3rX1i8eDF2796NNm3aiI5DdioqKootL2Q1arUajzzyCFQqFd58802u p05UByzSiezId999hzfeeAO7d++Gv7+/6Dhkx9iXTqI8/PDDeOCBB0THILJ5LNKJ7MSuXbsw d+5cbN++HaGhoaLjkJ2LiorCwYMHUVpaKjoKNTIPPPAAPD09sXv3bjz33HOi4xDZLGfRAYio docOHcITTzyBzZs3Izw8XHQccgCtWrVCUFAQjh49in79+omOQ41QZGQkOnXqBKDieg9qNecN iQzxN4LIxh0/fhyTJk3Cf//7X0RERIiOQw6EVx8lkVxdXREQEIDbt2+jV69eKCwsFB2JyKaw SCeyYefOncPo0aOxatUqaLVa0XHIwbAvnWxBs2bNsGvXLnh4eKCgoEB0HCKbwSKdyEZlZWUh Ojoaixcvxrhx40THIQc0aNAgHDt2DEVFRaKjUCMnr1Q1Z84c7Nq1S3AaItvAIp3IBl25cgXD hg3DggULMG3aNNFxyEE1bdoU4eHhSExMFB2FCADw2WefITo6GjqdDpcvXxYdh0goFulENiY/ Px/R0dF48skn8eyzz4qOQw6OLS9kS9zc3AAA8fHxeP/99wWnIRKLRTqRDbl9+zZiYmIwcuRI /OUvfxEdhxoBXtSIbFFMTAw+/vhjAMCxY8cEpyESg0U6kY3Q6XQYP348evTowRkkspqIiAic P38e+fn5oqMQVVFQUIC33noLOp1OdBQiq2ORTmQDysrKMHXqVLRp0wYrV66ESqUSHYkaCVdX V/Tr1w/79+8XHYWoihYtWmDbtm1wd3fH/v37cePGDdGRiKyGRTqRYHq9Hk899RTKy8vx1Vdf 8YIeZHVcL53swYEDB5CRkSE6BpHVsBogEuy5557DtWvX8N1338HFxUV0HGqEePIo2YM33ngD PXv2RFpaGrZv3y46DpHFsUgnEmjhwoX49ddfsXHjRri6uoqOQ41Ujx49cO3aNWRnZ4uOQlSr mzdv4vr166JjVCWJDkDmYEvtpizSiQRZsmQJtm/fjm3btsHDw0N0HGrE1Go1Bg0axJYXsgu9 evXC448/Dp1OhzfffBMlJSWiIwEAXF1cUVpWKjoGNVBJWcX/I1v6RJtFOpEAq1atwr/+9S/s 3LkTXl5eouMQseWF7NL9999vM0VVE/cmKCwsFB2DGqjwTiGcnJzg7uouOoqCRTqRla1duxaL Fy/G7t27lUthE4nGIp3sjbu7O55++mmoVCosWLAAx48fF5rHt5UvrufZYBsO1UluXi58PH3g 5OQkOoqCRTqRFW3duhWvvPIKdu3aBX9/f9FxiBQdO3aEJElIS0sTHYWo3qKjoxEcHCw0Q8fA jsjMzBSagRruwoUL6BzYWXQMIyzSiaxk165dmDVrFn744QeEhoaKjkNUBa8+SvYqKioKLVq0 wKZNm/D2228LydA1tCtyruTgzp07QsanhisvL8fvv/+OrqFdRUcxwiKdyAoSExPxxBNPYNOm TQgPDxcdh8ikqKgonjxKdm3YsGH405/+BKDiGhTWdJ/PffDx9MHZ82etOi7du9T0VDjDGSEB IaKjGGGRTmRhx48fx8MPP4yvv/4aERERouMQVWvo0KGIj4+3enFDZC7NmjVDcHAwcnNz0bdv X5SWWm+1FZVKhWERw3D48GEUFRVZbVy6N+Xl5UjYnwDtQ1q4ONvGScgyFulEFnT+/HmMHj0a n376KYYOHSo6DlGN/Pz80KpVK5w6dUp0FKJ74uPjgy1btsDFxQXFxcVWG7fvA33RqmkrHDl2 xGpj0r05ceoE1OVqDH5osOgoVbBIJ7KQrKwsREdH4+9//zvGjx8vOg5RnXCVF3IUvr6+AIBH HnkEycnJVhnTyckJE4dNxC/HfkFmVqZVxqSGy7mWg0OHDmF81Hg0cW8iOk4VLNKJLCAnJwfD hw/Hyy+/jMcff1x0HKI6Y5FOjkZuNdTpdCgoKLD4eGHBYRg9YDS2bNuCvPw8i49HDXPnzh1s +n4TNF01eCj8IdFxTGKRTmRm+fn5GD58OKZNm4Y5c+aIjkNUL1FRUUhMTLRqLy+RJTVv3hwA sGHDBvztb3+zyphDNUPRo0MPrFu/DtlXsq0yJtVdXn4e/rv+v2jfsj0mDp8oOk61VJIkSaJD EDmK27dvY9iwYRg0aBAWL14sOg5Rg/Tu3RvLly9H//79RUchMiu9Xg+1Wo2TJ09afKUtvV6P Lfu2YP/x/YgaGoVuYd2gUqksOibVLu1CGnbs2IEeIT0wddRUmztZ1IAvi3QiMykuLsbo0aMR HByMf/7zn3wzJru1YMECNG3aFG+++aboKERmd+XKFUydOhV79+6Fs7Ozxcc7fPwwNuzdAM9W nhioGYigwCCLj0lVXbp8CQeTDiLnUg5iBsRgqGaorf+dZpFOZA5lZWV45JFH0KRJE6xZswZq NTvJyH7t3r0bf/vb37B//37RUYgsKjExET179oSHh4dFx7l15xb2JO3BweMH4enlieCQYISG hKKNTxv+vbAQSZKQez0XaRfSkJ6ejms51xDRPQLRA6Lh7ektOl5dsEgnuld6vR7Tp09Hfn4+ Nm7cCBcXm/3ojKhOCgsLcd999yE7OxtNmzYVHYfIYubPn4/Zs2cjLCzMKuPdvHUTJ8+fxKnf TuG3i79BDz08PDzgpHayyviNhSRJuHPnDiS9hA7tOiA8NBzhncPh09JHdLT6cLwiXa/XI78g H7n5ubhRcAOlZaUoLimGrlgHXbEODvZ0CRUXkHB3c4e7mzvcXN3g4uwCrxZe8Gnpg5YtWlp8 lmLu3Lk4c+YMtm/fjiZNbG8JJ6KGiIyMxOuvv47hw4eLjkJkcSkpKcjPz4dGo7HamEW6IuRc z0HB7QLWJhbQolkLtPZujWYezURHaShfyzdjWdidojtI/z0d6b+nIzUzFddvXEd5eTkAoFwq B1RQ/vNL4C+Bo1Khoq9MpVIBEuCkqpiVcHJyQiuvVggJCEFIQAiC7w9G0ybmmxl88803ceLE CezatYsFOjmUqKgo7Nu3j0U6NQpXrlzBlStXrFqkN3FvgsB2gVYbj+yPXc6k593Mwy9nfsGv Kb/iSu4V6CU9yqQylEvl0Et6lKPc5FGpq6srVGqbPkmAGkDSSygpKalyu0qlghOcoFap4aRy grPKGWqVGvf53IfwzuHo1a3XPfWlLVmyBGvXrsWPP/4ILy+ve3kKRDYnMTER8+bNw9GjR0VH IbKa27dv45NPPsGLL74IJye2oJBQ9jOTLkkSTv12Cgd/PojMS5kol8pRqi9VinMXFxe0b9ce 3t7e8PH2gY+3D1p5t4KzszNcXFz4y9YIlJeXo7S0FGVlZbiedx25ebnIzctFXl4e/rj0B4pK i+CkckJmTiYuXbuE3Yd2I7BdIAb2GYjuHbvXepb3rVu38Pvvv6Nr165YtWoV/vWvf2H//v0s 0Mkh9e3bF+np6cjLy4O3t12cZEV0z/R6PZo0acKagWyCzc+k6/V6HD97HPHJ8cjJzUGJvgSl UinKpXJ4eXmhW1g3BAUGwe8+P/5SUbXKy8uRnZONCxkXcDrlNG7cuAEnlRNc1C5wVbmirU9b REVEoWeXntX2sD/77LMYPXo0bt68ib/85S/Yv38//P39rfxMiKxn1KhRmDFjBiZOtN2LfRBZ yhtvvIHp06cjODhYdBRqnGz7xNHzGefx/Z7vcTXvKkr0JSiRSuDq5oounbuge5fuaOfbztbX uCQbJEkSLmVfwumU0ziTcgbFumK4qd3gqnZFG+82GD9sPDoFdTJ6zLVr19C9e3c8/vjjWLdu HeLj4xEaGiroGRBZx4cffoj09HSsXLlSdBQiq9u2bRuGDBnCFY5IFNss0vNv5mNL/BacOn8K JVIJivXFaNKkCfr27otePXrB1dVVdERyECUlJTh24hiOHDuCwsLCimJd5YrunbpjbNRYtPRs CaBiFv2f//wn3N3d8fTTT8Pf3x99+/bF4MGDBT8DIsv59ddfMWXKFJw7d050FCJh/v3vf+PG jRt4/vnnRUehxsX2ivRjp4/hu13fobCkEDq9Di6uLugf0R+9e/a2ypXBqHEqKyvD0eNHkZic iNKSUrir3eHh6oGJwyci4L4APPDAA8jOzoZKpUJgYCD+/Oc/Y+7cufwkhxyaJElo27Ytfvnl F7Rv3150HCIhrly5goKCAnTs2FF0FGpcbKdILy0rxabdm3Dk5BHo9DqUSCXo1qUbogZGoVkz u13jkuzM7du3EX8wHqfPnoaryhXuanckfJ+AYz8dQ8uWLTFlyhQsW7bM4lenI7IVU6ZMwahR o/DEE0+IjkIk1MWLFzF9+nTs2bOHVwkla7CNIv1GwQ18/u3nuHT1Egr1hXBv4o5xMeMQFBgk Oho1UhcyL2DL9i24nnMd/132X7TyaYWNGzdigGaA6GhEVhUXF4ekpCR8+eWXoqMQCZeWloaQ kBAUFxfDzc1NdBxybOKL9KvXryLumzjk3sxFYXkh/Nv7Y8LoCZw9J+Fu3bqF52Y8h5LyEjzU /yH4ePlg1pRZaNOqjehoRFaTlpaGyMhI/PHHH6KjENmMqKgorFixAl26dBEdhRyX2CL9YvZF fLb+M9wovIGi8iL07NET0VHR/BiJbEZRYRESEhNw/NfjaOLUBF4eXpjxyAzc73e/6GhEVhMU FIRdu3axJ5fof27evAlPT0/odDqo1WouaEGW4CusGr589TJWrVtVUaDri9A/oj9GDh3JAp1s ShOPJhg5bCT6R/RHkb4INwpvIO6bOFy+ell0NCKrGTJkCPbt2yc6BpHN8PT0BACsXr0aS5Ys EZyGHJWQmfTrN65jxX9WIO92Hor0RRgeNRy9e/a2dgyiejl6/Ch2x+9GE3UTeDfzxtzH56KV VyvRsYgs7uuvv8amTZuwYcMG0VGIbIokSSgtLYWrqysyMjIQFMRz6chsrD+TXlhUiLh1cci/ nY8ifRGiBkWxQCe70Ltnb0QNikKRvgj5t/MRty4OhUWFomMRWdzQoUORkJAAvV4vOgqRTVGp VHB1dUVmZiZmzZoFG1iLgxyIVYt0SZKw7od1uJp/FYX6QvTp2QcRfSKsGYHonkT0iUCfnn1Q qC/E1fyrWPfDOr4pk8Nr27Yt2rZtixMnToiOQmSTAgMDsWfPHqhUKhw/fhzl5eWiI5EDsGqR nvBTAs6knUGRvggdQzpi6JCh1hyeyCyGDhmKjiEdUaQvwpm0M0j4KUF0JCKL02q17EsnqoMl S5YgMzPT6Lbi4mIxYciuWa1Iz7qUhR0HdkCn16F5i+YYHT2aV2sku6RSqTA6ejSat2gOnV6H HQd2IOtSluhYRBal1WoRHx8vOgaRzVu7di2Cg4ORkpKC06dPAwA++OADzq5TvVmlSNfr9fhu 13coLi9GuaocE0ZPgLu7uzWGJrIId3d3TBg9AeWqchSXF+O7Xd+xX5ccWmRkJJKSkjgjSFRH p0+fxtmzZwEAiYmJeOmllwQnInvjbI1BEn9JxKWrl6DT6xDxUAT8fP3q9LjMtJtY9tYRC6ez f/2j2mPqjLAat9m8LhV7t2ZaJ5Ade3bBgwgLr9uKLX6+fujbuy+SjyTj0tVLSPwlEQN7D7Rw QiIxPD090blzZxw5cgQDB/L/OVFtHnnkEQBAQUEBbt68iTVr1mDs2LEYMmSI4GRkLyxepBfc LsCug7tQrC9GixYtMLBf3d/cb+TpsGPjBbg3cUXLVk0tmNI+6XSlyM+9DS/v2j+V+O10HnZs vAAv76Zo4sGLLlR2I/8Oiu6U4JEnO9e5SAeAgf0G4uy5syi6VYRdB3fhgc4PoEWzFhZMSiSO 3JfOIp2odocOHcInn3yC69evIyMjA7m5uXjhhReQlJSEJk2aiI5HdsDiRfrepL0oLC5EiVSC 8drxcHau/5A9+wVjwZIpFkhn334+cB5/e2FtvR4zfX40ImPCLZTIfq14ezP2bjle78c5Ozsj WhuN9ZvWo7C4EHuT9mLi8IkWSEgkXlRUFP76179i0aJFoqMQ2bwBAwagZcuWWLRoEZycnAAA J06cwKOPPorvv/8eRboi5FzPQcHtApSVlaGktERwYsfg4uwCZ2dnNG/aHG1atUEzj2aiIzWY RYv0W3du4civR1CsL4Z/O3+EdAix5HBEQoR0CIF/O39cuXwFR349gmH9h6F50+aiYxGZ3YAB A3Dy5Encvn0bzZrZ7x8+Imvp2rUrvv32W+Tk5OC9997Dpk2bsHfvXkz7f9PQKrAVJJUEDw8P ODs7w8XFRXRch1BeXo6y0jLcuXMHkl6CX2s/hAWGoV/PfmjTqo3oePVi0SI94acElJSXoFRf ikGaQZYcikioQf0H4etvvkZxWTF+TP4RY7VjRUciMjt3d3f06tULBw8exMiRI0XHIbIbHs08 MHj0YOA+IPVUKo4fOY7YObEIDg6GWm3160o2CpIkIf9GPtIz0nH6t9OIPxqPiO4RiB4QDW9P b9Hx6sRiRXppWSl++vUnFOuL4efrh4D7Ayw1FJFwAf4BaOfXDlevXMWRk0cwcvBIuDhzVoQc j9yXziKdqG4OHz+MDXs3wLOVJ8ZPGI+gPwcBAEpLSlmgW5BKpYJ3S294t/RGnwf74NLlSziY dBDvfPoOYgbEYKhmqM0vBW6x/x2nfzuNouIilOpL8VDvhyw1DJHNeKjXQyjVl6KouAinzp8S HYfIInhRI6K60ev12LRnE9btWYdIbSQef/RxBAUGKfe7uHIix5ra+bXD1ElTMWrMKOz4aQfW bFmD0rJS0bFqZLEi/edTP6NMKoObuxs6hXSy1DBENqNjSEe4N3FHmVSGn0/9LDoOkUX07t0b mZmZyM3NFR2FyGZJkoQ1m9fg8NnDmDp5Krp36W7zs7aNRUiHEEx7dBrOXT6HVetW2fRFpixS pN+6cwtpWWko0Zegc2hn5axmIkfm5OSEzqGdUaIvQfrv6Si4XSA6EpHZOTs7Y+DAgUhISBAd hchm7UncgxMZJzB18lT43ucrOg5V4t3SG49NfgwX8y5i4+6NouNUyyI96ecunEO5vhzlUjm6 delmiSFqtOXgCqzeUv2VvcICIrBkboLVxp859gOMHTjXYuM11JYDK7B6c9XXadHMzejVOVpA oppVzjtz3AcAUOW2sYPEvdbdunTDiZMnUK4vx/mM8+jTvY+wLESWIre8TJo0SXQUIpuTkp6C HxJ/wITxE+Dd0j5OUGyMmjZtiokTJmLdN+sQ0C4AD4XbXmu2RWbSUzNTK1pd3Nzg387fEkPU aOzAudi6VGd029alOsQtOAMASMlKxsrv5lh1fFsz5kV3pbhdNHMzti7TYesyHUb0m4FFq8dh zIvuOHZul+CUxsYOmouty3S13iZSe7/2cHN3Q5lUht8yfhMdh8gi2JdOZJper8fGvRvxYK8H ERgQKDoO1aJt67YYMGAANv+4Gbpi26klZGYv0iVJQlpWGsqkMrRv117omcthARFGP/v6BCvf Z2WfsXYcZOemY8zL7nhlRaTVxzb0ysd3x688az5n0kplhtocsnPTMeZFd6MxHZlarYZ/O3+U SWVIzUyFJEmiIxGZXdeuXXHr1i1kZWWJjkJkUw4fP4ybupvQ9NWIjkJ11DO8J9Tuauw7bHsT D2Zvd7l+4zoKbhegXCrH/e3vN/fu70l2brry/ZRhrynfv7IiEilZyUbbbl2qw8rv5mBn8uc1 7tPUdqZm0Q23SclKxpiX3REWEIEA365VxrB0e0xKZsVzDQuMMNnWMnbQXPTpUrG82isfRyrb K/nGfYCLV1Ow83D1r03ca2ewMeFDZZuUzGSMedG9xlzyAUN1Y9a3jcXUfkb0m1FtbrX35Hrt vzr3t78fFy5cwO3C28jNz0Vr79Zm2S+RrVCpVIiMjMSPP/6I6dOni45DZBMkScLen/aiT58+ vDCRHVGr1ejfrz/i98RjWP9hcHVxFR1JYfZp7ivXrkCCBL2kRzu/dubefYONedkdsxZ3RVhA BLYu1aFXp2jl9pSsZIyImIGtS3WYOfYD5Xa5eI5bcEZplZk59gNlG9mch1dWua2yOQ+vxIiI GQCgZBjwwCSTY9gCX59gzHq/K1IykxEWGIGty3SIe60in9wmYzjjPqLfDGxdpkNYYMWnF/9Y OwNzJq3EiH7/e87/28fWZTosmrnZ6HHyYy5dTcWYF92rHXPlhrq3KMn7kXPJWbOyz1Q7Pprk 1es1qk47v3bQS3pIkJB9Ldss+ySyNWx5ITKWlpWGvFt56N6lu+goVE8dQzpCUks4k2o7dRhg gSL96vWr0EMPAPDx9jH37htMnt2WZ7EB4Nj5uz3XO5M/x5iX3U2ecDprcVelwLfUDLc1xqis 8iyzoafeCVG+lz918PUJVgrayrPRcyatBAAE+HatdVw/n7v7jug2FkueS8DWZTq0axNarzGr Y9hLv/Pw50b99xXP+e4yWPL40Z7fQHWpd532X5tW3q0AAHrocfX6VbPsk8jWyEU6W7qIKpzP OI92/u3g7l7zp8Zke9RqNQI7BDp+kX4t7xr0kh5u7m7w8PAw9+7vyaKn786gbjm4osp9W5fq qnwZSslKNms/uakTTM09Rm1MnRx67Nwu5N74o8bHKbPPVtSQMQ1PipW//AzOTbAEjyYecG/i Dr2kR24+15ImxxQUFAR3d3ecO3dOdBQim/B79u/w8/UTHYMaqH279sjMzhQdw4jZi/TrN65D Dz28vWxr2aHs3HSlxQUADv26AZeupio/f7PnfaPttxxcgTEvuyvFu9yqkpKVbDTjK8/GX7ya Uucscv97TWNYkmG7x6LV44wK9ezcdCxaPc5oe/m1yc5NV2bfBzxQv6XXapq1lxn2x9/LmKb2 Y23eXt7QS3pcz78uZHwia9BqtYiPjxcdg8gmXMm7onySSvbHx9sHuTdzodfrRUdRmP3E0SJd ESRJEjqLbmqddLmVZETEDOxM/hwpWclIyUpG3IIz+Me6GUZtMIYWfWZcsMYtOFPRghEQgZSs 5Cr3A6iyn9VbXsKhXzdgyrDXlB50w21MjWFJvTpHY+synXJiZeWiPCwwQimIV29+qcpJn6ZO HK18Uqj8mEUzNyvbmTpxVB5bXkZx6zKd0k9eecx2bUKNblu9+aUq67yv3lzxWhs+v5pOWJXH j/b8ptptGsLDwwO5yEWhrtCs+yWyJVqtFuvXr8ecOZZb0pbIXtwpumNzHQRUdx5NPVBeXo6i 4iI0bdJUdBwAFijSi0uKIUGCm6ubuXddZ2MHzq2xr3vOwyuNfm7IhY0aejEkW1o/fclzCbVu U9OKKnIfem3qu455TdvXZ191eX6yFW9vrn2jenB1dYUECcUlxWbdL5EtiYqKwrPPPovy8nJe WZoavdLSUrg4c1UXe+XqXLGqS2lpKdBEcJj/MXu7i66koohydbWdJWyIrM3NreIglUU6ObI2 bdqgffv2OH78uOgoROKpat+EbJ8tnQx0I0AeAAAgAElEQVRv9iK9tLQUEiQeTVKj5ubiBkmS UFJaIjoKkUVxKUYiIsuwyBVHIUHolUaJhPvfjIotHZETWUJUVBSLdCIiC2AlTUREDRYZGYmf fvoJxcVs7SIiMicW6URE1GDNmzdHly5dcPjwYdFRiIgcCot0IiK6J1wvnYjI/My+BKNox87v Mrl2eVhABJbMTcDK7+Yoa5XLFj292ehCR47u2LldVdZGN6W+SyeaU3ZuOma937XW7WaO+6DG ZSIrk9dOly2audno4kdEVH9arRYLFy7E22+/LToKEZHDcLiZ9F6doo2u3glUFOHyuuZzHl6J RU9XrIkdFhCBRU9vxqLPxmHMy+7YcnCFiMhWJ1/MKCwwQrkt7rUz2LpMh63LdBjRbwZG9JtR wx4sz9cnWMkiWzRzs5LR8Kqp9bHkuYQGP5aITNNoNDh16hQKCgpERyEichgOV6TLJg5+Qfk+ +fQWo/vkn/889XOlqN+6VFfjBZAckXxV0cr824TBv02YRcfOzk3HmBfd8crHkTVuV12OXp2j MXPcBxZIRkT15ebmhr59++LgwYOioxAROQyHa3eR+foEY0TEDOxM/hw7kz/HxMEvwNcnGNm5 6diZ/Lky0z7mZYNLz4/9AGMHzsUrKyKRkpVstL+tS3VG2wIVM/F/nvo5Zi3uihERM+DfJgyr t7xktL9Dv26osi85lykiW2/kNpiZ4z7AxaspGPOiu8ntFs3cjG/2vG/UNgJAedzOw6afG1Ax Y78x4UNlm5TMZIx50R1hgRF1ukKo3AYjz7DvPPw5Vm9+yeS2ca+dga9PMICqbS5EZF7yeumj Ro0SHYWIyCE47Ew6YDybvnH/hwCAn1N2KPf5+gRj61LjvusxL7sjJSsZIyJmYOtSHWaOrZit fWVFJLYu1SEsoKJFRO5xl/e7M/lz9AkbqWy/6OnNWL3lJZP7yso+o7TcABVFu7zfS1dTzf46 1MWs97sqfert2oRizqSVRm0hI/rNUNpjFq0eh5TMZIQFRmDrMh3iXjsDAEqxbDjDPaLfDKPW mn+snYE5k1YqRba8j7oU6ItWj1P61P3bhGHOpJW1jgUAY150R0pmsnI/212IzI8XNSIiMi+H LtLl2XSgoojOzk3HxaspGBExQ5lhNXTs/C7l+53Jn2PMy+7KzHhKVjKyc9MxZdhrys9jXnY3 mhHfuP9DZf+GTO0L0t3rB0d0G4slcxOEttzEvXamSvHq5xOifB/RbWyVfm75tfD1CVYK48qz 6HMmrQQABPjWfhJobeSe9BH9ZuDi1ZQq95sa69i5u/+mEd3G3nMGIjLtwQcfxB9//IGcnBzR UYiIHILDtrvI5jy8UimkZy2uKN7iFpyp9XHVtZ34+gQjLCBCaWEZETEDEd3GYtFn45Rx5Bnz mvaVnZte/ydjYb06Ryuz4g1leDJqfZhqR6ludRm5GD92ble1rS4yUZ9MEDU2Tk5OGDRoEBIS EjBlyhTRcYiI7J5Dz6TLDIvm6mbRARgV0t/seb/a/ckzyEBF20WvTtFKuwoAjB04t877Eslw NvpybhqAioOQ6l4fAEbLFcrPKzs3XSmwqzsZtTry45Y8l6Cs3CJ/Vc5YWV1e1z5dRtZreyJq uKioKLa8EBGZicPPpAMVRbPcajLn4ZXK7ZXXVF+95SWMiJiBrOwzSjuLobgFFSciGhblcnvK lGGvYdFn44wOCLYu1SknoVbelyE5Q+X+eEsxtQa53I8un2y5csMco9YV+X65gJb7vA1PLjV1 4mjlk0/lxyyauVnZTt7GcM3ymjJWx9RYs97vikUzNyt99JW3WbR63P/644fXuG8iqp1Wq8Xy 5ctFxyAicgiNokgHTBfA8vKLDSGvu17bvipvZwvkNchrMmfSSqWtxJSaHl/T4+q6j7pkrI/a 9rXibZ5MSnSvwsLCUFhYiMzMTAQGBoqOQ0Rk1xpFuwsREVmeSqVCVFQU4uPjRUchIrJ7LNKJ iMhsuBQjEZF5sEgnIiKzkYt0SZJERyEismss0omIyGzuv/9+NG/eHGfPnhUdhYjIrrFIJyIi s2LLCxHRvbOL1V1yc24hce+9XWTHEV1Iya73Y1JP/wEXVycLpLFvOZfzRUcgchharRZr1qzB 888/LzoKEZHdsosiPfXMH1j66reiYziEH9YfwQ/rj4iOQUQOLCoqCrNnz0ZZWRmcne3izwwR kc2x6XfPjl298X3SRNExbJ63T5Nat3n82W4Y+XAHK6Sxb4HBXqIjENm9Vq1a4f7778exY8fQ t29f0XGIiOySTRfpHk1d0K1na9ExHMJ9fk1xn19T0TGIqJHQarWIj49nkU5E1EA8cZSIiMyO J48SEd0bFulERGR2gwYNwpEjR1BUVCQ6ChGRXWKRTkREZtesWTOEh4fj8OHDoqMQEdklFulE RGQRbHkhImo4FulERGQRLNKJiBqORToREVlEREQEUlJScOPGDdFRiIjsDot0IiKyCFdXV/Tr 1w8HDhwQHYWIyO6wSCciIouJiopCfHy86BhERHaHRToREVkM+9KJiBqGRToREVlMz549kZ2d jStXroiOQkRkV1ikExGRxajVagwePBg//vij6ChERHaFRToREVkUW16IiOqPRToREVmUVqvF 3r17RccgIrIrLNKJiMiiOnXqhPLycly4cEF0FCIiu8EinYiILC4qKootL0RE9eAsOkBNThzJ waTB34uOYfMefboL3vl4YI3bLF34E1YtO2GlRPbri80xGDTcX3QMIoej1WqxY8cOzJw5U3QU IiK7YNNFuqytnxd6RASLjmFzrmbfxPHDafV6TPfegfC7v5WFEtmv08eycCkrV3QMIoc1dOhQ vPzyy5AkCSqVSnQcIiKbZxdFeofOvnjm9TGiY9icnw+cr3eRrh37ICJjwi2UyH6teHszi3Qi C/Lz80PLli1x+vRpdO/eXXQcIiKbx550IiKyCvalExHVHYt0IiKyCq6XTkRUdyzSiYjIKoYM GYKDBw+itLRUdBQi85NEByBzsKVzZlikExGRVXh7eyM4OBhHjx4VHYXI7FxdXFFaxgNQe1VS VgKg4t/RVrBIJyIiq2HLCzkqjyYeKCwsFB2DGqjwTiGcnJzg7uYuOoqCRToREVkNi3RyVPd5 34fc61wlzF7l5uXCx9MHarXtlMa2k4SIiBzewIED8csvv6CoqEh0FCKz6hjYEZmZmaJjUAOl X0hH58DOomMYYZFORERW4+HhgR49eiAxMVF0FCKz6hraFVdzruLWrVuio1A9lZWVISszC11D u4qOYoRFOhERWRVbXsgR3edzH1p7tkbKbymio1A9paanws3JDSEBIaKjGGGRTkREVsWLGpEj UqlUGDFgBJJ/SmY7lx0pLy/HgYMHMCxiGFycXUTHMcIinYiIrKpv37747bffkJ+fLzoKkVn1 7tYbPk198PMvP4uOQnV04tQJOJU7YWDvgaKjVMEinYiIrMrFxQUajQb79+8XHYXIrNRqNSYM nYBfjv6CzKxM0XGoFjnXcnDo0CGMHTLWppZelLFIJyIiq2NfOjmqsOAwjBowClt/2Iq8/DzR cagad+7cwabvN0HTVYOHwh8SHcckZ9EBSJwbF9PxxYTaz2SOfPEDPPjo3Hrv/5e1K5Cw7KV7 3g8ROR6tVovHHntMdAwiixiqGYrsq9lYt34dJoybAN/7fEVHIgN5+Xn47vvv0L5le0wcPlF0 nGpxJt3CVr63C2N6L8Er/7fG5M8iefkH44WjOoRPnKHcNvGjzXjhqA4vHNVh4keb72n/Dz46 Fy8c1d1rTCJyQA888AByc3Nx6dIl0VGIzE6lUmHauGnQdNFg/fr1OHX2FCRJEh2LAKRdSMPX //0anf06Y/bU2XBychIdqVp2P5N+LOkCFj2/wei2sHA/LPlimqBEd21Zeww7N/5a7c+2wjso zOTtgZpoRL74gZXT1E7+BMAvPAJTv0gQHYeIGkClUiEyMhI//vgjpk0T/35NZG5qtRrjh41H W5+22LB3A46fOI6BmoEICgwSHa1RunT5Eg4mHUTOpRzEDIjBUM1QqFQq0bFqZNdF+sr3dilF b9ymmfD1b4nsi/mYNWE1xvRegpkvajH20V4N3v+Wtcewetk+LPpoEnppOtT78WMf7YV2AS2V g4jKP9squQgOnzgDJzd+DgBGbSuGt1fn/zadgZd/cJXb9743x+ixLxzVmbwtM2kXNj4/rsrj /ftE4uLPCQCAyyeT8WFvd6VYX/d/kbh8Mtloe7nFpvIYhu71EwMiahitVov4+HgW6eTQ+vXs h24du2FP0h5s2bIFnl6eCA4JRmhIKNr4tLGpy9A7EkmSkHs9F2kX0pCeno5rOdcQ0T0Cs8bM grent+h4dWK3RXr2xXylQJ/5oha+/i0BAL7+LRG3aSZmTVgN4G6hbWjmi1oc2pOClJOXTe57 69FXjA4AaiqqF300CZey8k2OUZcDBFOfBGw9+orJ3PJ4DTlgqCvDwtg7KAwvHNUpxa/hzHVu 2hmjgnjiR5sRqIlWtt351gyTs9xDX18J76Awo6K/8m03LqYrOSrvt7xYpxwkGOb5sHfFWdny bfKBRsKyl5CXkYKhr69ESORYZb/hE2cozyEvKxWAv1lePyKqO61Wi/fee090DCKLa960OSYO mwhthBYnz5/Eqd9OYd3P66CHHh4eHnBS227LhT2SJAl37tyBpJfQoV0HaDprED4+HD4tfURH qxe7LdIvX7y7vm67gJZG9/n6t8TWo68YFcBxm2YCAGZNWK3Mjn/zWRJSTl5W2mPG9F4CoKKw n/N6NLLSriHl5GUs+mgS/PxbKoU/AIyY+AB2bvwVW9Yewy+HM0yOUTlXZYb5DAvzle/twsTH HzIq0uXxLmXlo5emQS9ZnchF8d735iAvo+KqaRFPv4aNz4/D5ZPJ+GXtCngHhOLyyWRllvrG xXTl8T4hXavMZteX3Ctf1/1mJu1Svo94+jVlH37hEbh8MhknN36Ooa+vhJf/3SuJhUSOxdDX Vyo/J73N2XQiawsJCYFarUZaWhpCQmzrSn9EluDZ3BMDew/EwN4DUaQrQs71HBTcLmC/ugW0 aNYCrb1bo5lHM9FRGsxui3RDpgpXw5nwsHA/Zabd8DGyAcPClO2qm1339W+JmS9qsXrZPoSF +2HO69GY83q0UqRXN0ZNhbphBvkAAQCy0q5VO561yAWs3HbSvG173Mr5Q5nt9guPwIOPzq22 LeVemXO/fuERZtkPEZnfkCFDsG/fPhbp1Og0cW+CwHaBomOQDbPbRqhemg4IC/cDAKxetg/H ki4o98kFuk/b5gCAlJOXkX0xH9kGs+99BpinZUQuwhsyhmEBH7dpJrYefQVbj75i9ZNe5Rlz U5I/ex8A8Minu4xuj3j6NaNCWl4VxnClmOp4B4Qq38uz4IYZ6rpfeWY9UHP34EXOe+NiunJ/ x2GTas1ERGJERUVxvXQiIhNUkpk/Y3l16asoKClAr169oI3U3tO+ThzJwaTB36NfVBgWLJli chvDGfPKZr5YMX7l3u5FH01CckJqjSut1GUb+WRVU/3j1fWqm8pYeZuwcD8MGBZW5XZ5PNnP B87jby+sxaNPd8E7H9d8OdulC3/CqmUnMP/tiYiMCQdQ93XSAeOTOcMnzlBm2uVe8Lqq6STP ezHxo80mZ95rO3FUXiJyxdubsXfLcXyxOQaDht97f3r8gXgc/fkomrk0w5JXltT+AKJGKjs7 G+Hh4cjJyeEJdEREd/nafbtLXdpATJ3A2UvTodbH1WUbef+mxzA9dl3y1XS7uci933UVqImu sn1D10G3xNKJNWUZ+vpKox50IrINvr6+aN26NU6ePIkePXqIjkNEZDM4bUFEREJptVq2vBAR VcIinYiIhJLXSyciortYpBMRkVCRkZFISkpCaWmp6ChERDaDRToREQnl5eWF0NBQHDlyRHQU IiKbwSKdiIiEY186EZExFulERCQci3QiImMs0omISLgBAwbgxIkTuHPnjugoRNRAqvkqqOar kJabJjqKQ2CRTkREwrm7u+PBBx/EoUOHREchsrjl+5crBW3lr/7L+7PIJQCA3V/MiIiIHIPc 8hIdXftF5IjsVf/l/ZGUkQQAkGLvXvRdNV8FAMp9RCzSiYjIJmi1Wjz33HOiYxBZzPL9y5GU kQRNkAaJ8xKN7pNiJfRf3t/kY+Zvml/l9tSFqQjxCTEq+msySzMLp7NPK9tqgjQAqh4UxE6I xbzB86qMu332dowMG1llvO2ztyNmVYzRPkLfDa0yvuEBCQDMXj8bcUlxRreZel3kgxf5/sk9 JhvlkvPKano95OdgL9juQkRENqFPnz64cOEC8vLyREchsoj1J9YDABYOX2jy/sR5iUicl4gQ nxAAFQWnXJBKsRKkWAnbZ28HUFEIL9+/HInzEjFLM0vZR+ViWP45LikOC4cvVB6flJGEpIwk xE6IVfYNAPM3zcfs9bMxb/A8SLGSUswbZqx8u+HjgYoDCPm2yvcBFYV3XFIcNEEa5f7YCbFI ykiq0tMuxUpIXZgKTZAGSRlJyuuRujBVyStvLxfohs8pdkKsydfaHrBIJyIim+Ds7Iz+/fsj ISFBdBQii5BneENbV51prsxw1t2wyB0ZNtKoQDUkF+By0V7558q2z95uNAstF99xSXHYkbKj rk+rXmavnw2g6qz5vMHzlIJ6afzSKo+TXzu5AA/xCVEKcfmgxhT5YEOKlexqFh1gkU5ERDaE SzESVTibcxaA6Vn3EJ8QZSa7ocW0Jkhjsmid3GMyAOD7U983aL+1kVtcTD0v+YChchsMUJFX E6QxOqioLHFeIjRBGszfNL/KCbn2eDIui3QiIrIZLNLJkcmFdeq1VMFJxJFfg5hVMSZXt5E1 tKiW23HkL/lTh9B3Qy326YCl2MWJo7+d/gNLX/1WdAybc/1aQb0f88M3R/DzgfMWSGPf0s5e Eh2BiAB069YNN2/exB9//IH27duLjkNkVguHL0TMqhjErIqp0qcNGPdUd2nbBQDw7u53q8x4 p+WmKe0fI8NGNmjWOykjCTtSdlTZt9xCM777+Hrvsy4m95iMpIwks5/EuSNlB2JWxVRpownx CVFObv3+1Pd21fJi00W6s7Manl5uKC0pwamj9vcxhTV4ermhSZPa/xndmjjD08sNOZeuIefS NSsksz+eXm5wduGHS0QiqVQqREZGIj4+Hk888YToOERmNTJsJGInxCrtGPIKLcDdVUxmaWYp LR3rT6xXTqaUi3q5GAXu9pw3VMyqGKNi2TCDfFs3325IykgyKnBnr59tcgUV+eTOpfFLsWry KgDGq9OkLkzFvMHzMH/TfMSsiqmyMkvlbWvqNa9OUkYSlu9fruw3LTdNeb0sdeBhKSpJkqoe yt2DV5e+ioKSAvTq1QvaSK05d01kN+IPxOPoz0fRzKUZlryyRHQcIruyevVqHDp0CF999ZXo KEQWkZabZnKZwspFK1D/JRhjJ8TibM5Zpa+78s/yrLJcUNclg2EbiimzNLOUotzUtqaWVqxu qUTDbat77qbGNTx4MaWhRb9AvizSiSyARTpRw124cAEDBw7EpUtsQyMyt+raQsjm+PKzfSIi sikdOnSAm5sbzp/n+TNE1HixSCciIpsTFRWF+Ph40TGIHEr/5f2VlhC5191elydsDGz6xFEi ImqctFotvvvuOzzzzDOioxA5DLa32BfOpBMRkc3RarVISEj4/+zdeVyTV74/8E8SSEB2BJRV QFAWxQ0VwQW3WmxdoK3WLrNoq/fW3kqtnTvtr3Pr3Pa2c2+rRUenIzM6M13GqW1Bbau1dcEt oiIisqissu97ICHb7w98HhMIyJLkScL3/XrxkiTnOef7RAjfnHyfc6BSqbgOhRBCOEFJOiGE EJPj4eEBT09PZGVlcR0KIYRwgpJ0QgghJol2HyWEjGaUpBNCCDFJlKQTQkYzStIJIYSYpNjY WKSnp0Mmk3EdCiGEGB0l6YQQQkySg4MDQkNDcfXqVa5DIYQQo6MknRBCiMmi9dIJIaMVJemE EEJMFtWlE8K9wWx6tOf8HrYd83Uy/6QRo7Q8lKQTQggxWdHR0cjOzkZHRwfXoRBCBrBt0Tao k9RQJ6kRHRDNdTgWgZJ0QgghJsvGxgazZ8/GxYsXuQ6FkEHbcmQLeIk87Dm/h+tQyABO5p8E L5GHmD0xXIeikxXXARBCCCEDYUpe4uLiuA6FkEeK2RMDcYkYm6M3Y9uibTrb7Dm/B4mpiVr3 RQdE4/K2y/3217ut5n3qJDWAnjcHyeLkAfvlJfIGjL/gnQIEuQXpbBv8fnCf9szYQzWYWBm6 ngPGiS0nEBcaN6y2caFxSIpPQmJqIniJvGGfi6HQTDohhBCTRnXpxFzsOb+HTRAPrDugs03M nhg2QWfKQ5LikyAuEfeZ0eUl8iAuESMpPgnqJDUK3ikAAHYM5n6mbbI4GdEB0X361awn712O UvBOAdRJapzYcgJATyKu2VYzcWXaan4Nx2BjZZ4vzeeAadvfczvYtoxti7axz8eWI1uGdT6G YtIz6ZVlHfj+6/4vUiA9JoW6YvFKP67DIIQQg5g1axbKyspQX18Pd3d3rsMhpF9M8r05enO/ bXTNFD8R/gQSUxO1ZoCZhDEpPomdkQ9yC4I6Sd1nhptp23smmjkuMTURH539qM8bhxNbTrCz 5nGhcdgcvRnJ4mQU1D+cTde34caqaduibf1+SjGctuumr4O4RIxkcTLeXPKmwc59qEw6Sb9f 1IqP3qH1cR9lzYbgRybpVy9UIet6nZEiMl8rn5oIX38HrsMghGgQCARYsGAB0tLS8Mwzz3Ad DiE6DbTySe92uspGesupzkF0QDSeCH+iz2NMMs1gvn/nsXf6tN22aBsSUxORLE4eMPE1lqHG ennbZfbTh94lQpqlOUNtq2mSxyT2+x9yfxj0GwBDM+kknTE3NgS/fn0F12GYnLvZ5fjkdymD anvhp3Ic2JVl4IjMX+jUsZSkE2KCmJIXStKJqSqoL2C/DxsXprONZi26ZtI42MS9P0yN+soD KwdsV9hQyPks8XBi7f3pA/N8Bb8f3KfOfChtTZ1ZJOm2Y4QY7+3CdRgmp76qZcjH/Pr1FZgb G2KAaMzb5388jcunc7kOgxDSjyVLluCPf/wj12EQMiJHso4A0C4z6c8UzylIFifrnNntfcEl U65hDknoUGI9mX8SKw+s7FMaE+QWhBNbTmDlgZU4evso4kLjhtTWXJhFkk70x8nFjt7w6GA7 Rsh1CISQAYSFhaGjowP379/HhAkTuA6HkD6C3R/OhOfV5ulsM8VzCsQlYq1ksb9Z9APrDiBZ nIzE1ETk1ebhwLoD/bZlykRWHlipVcMO9D97PxTM7Ldmrfhw+x1KrAxxiRh7zu9h2xY2FLIz 8WunrtXqfyhtTR2t7kIIIcTk8Xg8LF68GOfOneM6FEJ0CnILYlcJyanO0dnmwLoDiA6IRrI4 md2Vs3fSrbm+OrMSC9OeaatrsyCmLbOcIPOVmJrIrqLC9M9coLrywEr2Qs6YPTHsDP3KAyu1 1nhnZqY149bVL/Ol2T9zn+bKKYOJtXfSr9mWeR4K3inQOTM+lLYAcK/uHvu9rmsAuEIz6YQQ QswCU5f+q1/9iutQCNGJKeXob51uQPfqLgPR1X7LkS0Ql4i1LngcTN/M6jDDiWug5RYH6rc/ g3ke4kLjBt3vUNr2xpQhbY7ezHnNviaaSSeEEGIWli1bhrNnz0KtNq0NRwhhaK65bajdRvec 38POeJtTfbWpOpl/8pFr23OFZtIJIYSYBT8/P9ja2uLOnTsIDQ3lOhxCdNJcBhDAiJfz62+H UFPbHdMcMRebAqb5fFKSTgghxGwwJS+UpBNTNtSSloGYYvJoKUZSImMMlKQbwOkPtiI75SC8 IqLw7KE0rsMxmFuH9+HSrh0DttmaITVSNISQ0WDp0qU4fPgwXn31Va5DIYQQg7LomvTTH2zF 7kgbnV+Zh/cZZMzMw/uQnXLQIH2bmmkbXu2ThG/NkGJrhhTz3/gYALA/0gYpG2ONHxwhxCIt XboU58+fh1Kp5DoUQggxKItO0pe9vR8Je4+xtzem5rK303btQEt5kd7HnLnhVa0xgZ7EfXek DUrFp/Q+ninwjIjqc9+0Da9i1YPnoTo7HWkfbH1kP63lRZTUE0IGNHbsWPj5+SEzM5PrUAgh xKCo3AVAqfgUUl5bo3Xf9gypzvs1xb7xMZpK8tmZ89g3PsbMDdofwTKlLwDYvhL2HuvTr65j zZ1f9Ar2+9yUg5jx4na0lhfiOx3PqffsWFReTwPQk9Tvj7SBZ0QUIl96S2f7F1Jz4eQ70WCx E0JM19KlS3H27FnMnj2b61AIIcRgLHomvbdD8eFIeW0NIhI2YXuGFM6+E7US8e0ZUsQ+KNM4 /cFWNN3v2e0qImETNqb2bBmfsPcYvDRmjpe9vV/rdm+ajyfsPYbtGVKd/bpO6LuDmCXQnGVv KS9iE+5Ve49ha4aUfVwlkyI8YRN7zNYMKZb+/mC/7c+8u8mYp0EIMSFLlizBmTNnuA6DEEIM alQl6UxCnJ1yEP/aGAsAbMIMALsjbZD24ELIhsJctnQlO+UgDsWHAwD8NWaHh8tQ/Zo6HtTY miF9MAves1mAa1B4v+2dfCcOqT0hZHRYuHAhrl27BplMxnUohBBiMKOu3CX2jY+RtmsHqrLT sTvSBjPWv8I+tjE1F84aJRTMxaXbM6TIPLwPabt24F8bY+EWFI6q7HQ0leQPK4b++rW0lWDK xKdQnZ0OoGd23C96BcrEp3SWrwzUx1DaE0Isn4ODA8LDw3HlyhXExsZyHQ4hhBiERc+kn/5g q1bt96H4cNz7+RutNgExK9gSl0Px4ezqL8xMe9quHVoz7G5B4QiKXQ2gZ0Z+d6QNqh4kokxb ZkzmjYDbg9nflNfWsBeQ6urXXPxiwTcAACAASURBVDGJONBz8Sfzr2ZyvfT3B7USbqZ8hSlx 0dXfYNsTQkYfZr10QgixVBY9k77s7f1Y9vb+R7bzj17R70Wb/d2/fYjrfw8mDnOja530L+K1 32zMf+NjTHvwHGpe6Nl7drw6O10r2d8faaP1uK72+yNtsGrvMa0LVAkho8PSpUvx1ltv4b33 3uM6FEIIMQi9J+l8Ph/gAUoVrWFr6aZteJVNwAdrtGxupFKqAAB8nkV/WEUIZ+bNm4e8vDy0 tbXB0dGR63AIIUTv9J5BiIQi8NQ8dHd367trQsyGrFsGHo8HkVDEdSiEWCShUIi5c+fiwoUL XIdCCCEGYZAkHTxQkk5GNebnn5J0QgyHWS+dEEIskWFm0sGDXC7Xd9eEmI3u7m7wQDPphBgS XTxKCLFkek/S7cbYgc/jo62jTd9dE2I22iXt4IEHezt7rkMhxGLNmDEDFRUVqK2t5ToUQgjR O70n6R6uHuCDj6amJqhUKn13T4jJU6vVaGpqAp/Hh8dYD67DIcRi8fl8LFq0CGlpaVyHQggh eqf31V3cXd3BBx9KpRKt7a1wcXLR9xB9nP5gK7JTDup8zCsiyuI2CSKmrbW9FQqFAjZWNnB3 dec6HEIsGlPysn79eq5DIYQQvdL7TLqbqxu77FxjY6O+u9dp2dv7kbD3GHt7Y2outmdIEZGw id1QqFR8asA+Mg/vG1Q7Qx1vCm4d3of9kTZ9vsoGeU69j/98dYjW7VsPdlq1dI2NjQAP4IMP Nxc3rsMhxKJRXTohxFLpfSbde5w3eDweBDwByivLERQYpO8hBo3ZQCg75SBSXlsDr4godndQ xvYMqdZMPLNbaH9tS8WntHYx7Y15bHuGFJmH97E7ijKY3U173w8AM9a/gptf/anPmMaguXmQ 5gZBaR9s1dr1c6CNg5h105m+InrdHi3KK8ohgAA8Hg/e47y5DocQixYSEoLu7m6UlJQgICCA 63AIIURv9D6Tbj/GHp7unhDwBCi9X6rv7ofMNSCU/b4qOx1eEVHYniGFV0QUAKBUfArL3t7P 3k7YewwJe4/127bpfgEAICJhEzam5rLHaB7PJPNMIr4xNZdtm7ZrB3h87ac94sFW90yCvj1D yibzpz/YqudnpK+UjbHs970T8di392P+g1hMQWt5EfZH2mjFbGpKy0oh4Akw3m08HOwcuA6H EIu3ePFiWoqREGJx9D6TDgBBE4JQVluGmroaSKVS2NhwN5PaVJLPfh+RsAnZKQex+xEzu/7R K/ptO3PDq3CdEIyU19aws+/+0SuQ/tcPtcd9kMx7RUTB2Xei1mNqlQqxb3yMtF074BURhWVv 74drQCib1GuO2VCYO8QzHrrqB58YeEZE6Zwpn7bhVfjPjwPQk9BX9/qEYf4bHw9551Fd/Wju Rqrr8d4x74+0gWdEFBIOpfUbV3NJPnL7uV7hUZ8MDIdMJkN1bTVsebYImsDdp0iEjCZLly7F Tz/9hE2bNnEdCiGE6I1B9iyf6DcRVjwrqFVqFN8vNsQQA2opLwTQM/PNJNJOXv7ITjnYZ3Zc l8zD+/ptm3l4H5ruF2jNdv9rY2yfPlwnBAPomb1vKS9CS3kR+1jgg4RXV3vgYU399gypyVz0 6uQ7EV/Eh6M6Ox2eEVHYmiHFCw8+Hbi0awfShjDjvz/SBtXZ6QhP2IStGVJ2pp6ZHWceZ8bR nMkPf/CpA/NYwqG0Pu014wJ6knHN4z0f/H82P3gjpU/FpcVQq9Sw4llhot/ERx9ACBmxZcuW 4cyZM1Cr1VyHQgghemOQmfTJgZNha2OLrs4uZN/ORtjkMEMMw+q9ukvvmnGm1ORQfDh7Ialm 29g3PoZbUM9jmsfqauvk5Y/WqlKtmnK3oHC2PXN8wt5j7Gz5ofhwtm3C3mMovnSSPZ4ZY2Nq rs72xlydZqCZ63888XBWOPKltwD0JO6eEVGozk5HbspBxD64BmAgmheh5qYc1Jrlrs5OR7ZG TT4zDlPrDqDPmwHN/vqLa8aL29k2gbGrBxXncGXnZMOaZw1bG1uETAwx2DiEkIe8vb3h5OSE vLw8hIeHP/oAQggxAwZJ0q0EVoiYHIHLWZdRfL8Y7e3tcHAwXG3usrf3sxeJDuRRF2EOpo+h HO8fvQIzdZSB9Hf/zA2v6rzfmMrEp/qUgJSJT6GjtmLA4zwH+GSiP7rKTfS9Asxw4hqujo4O FN8vhi3fFlMnTYWVwCC/XoQQHZhVXihJJ4RYCoOUuwDAzPCZsOJZgQce8u7mGWoYogea5SDf vbZGa3a6tbyIXd2FkfGg/r61vIidfZ+4/OlBjaWZlGf0quMHoFXb/t1ra9CqUSakiRlXV3/D iUsf8u7mAWrAimeFmeEzjTYuIQRYsmQJLcVICLEoBpvqC/QNxFjnsZA1yXDtxjVEzoiEQCAw 1HBkBPyiV2BrhpS9+LJ3Uu4ZEcUmu5d27WAv2mQwF46WiU9pHXtp1w62Lpy5XfTzN1pj9V6e 8YXUXK3Hv4jXnhVb8OZu9nvm2FV7j+G719bojKu5JF8rBia+rXpe2lKpVOLajWsQ8oUY6zyW 6tEJMbLFixdj8+bNUCgUsLKiT7EIIebPYK9kPB4PS+YtwZGTR9De3o6s21mYNX2WoYYjepAw iNr3gVZxYZJ9fYw10OMR61/pc99A4xqyBp1xK+cW2tra4GDlgCXzloDH4xl8TELIQ2PHjoW/ vz9u3LiBuXPnch0OIYSMmMHKXQBg1pRZcLJ3gpAvRPr1dKhUKkMORwgnVCoV0q+nQ8gXwsne CbOm0JtRQrigufuoTCbjOBpCCBkZgybpVgIrLJy9ECK+CK1trbieed2QwxHCieuZ19HS2gIR X4RFcxbRBaOEcIRJ0qVSKfbu3ct1OIQQMiIGTdIBYOHshfBy94IN3wbnL51HS1uLoYckxGha 2lpw/tJ52PBt4OXuhQWRC7gOiZBRp6urC2+99RZCQkKQkZGB3/zmN7h27RrXYRFCyIgYPEnn 8/lYtWQVhDwh1Eo1zqbR1s3EcpxNOwu1Ug0hT4hVS1aBzzf4rxQhpBdbW1sEBgZizpw5sLe3 x1dffcXpTteEEKIPRvlcflLAJEwLmYbM/EzcuXcHWbezMH3q9EEfX1/Tisuncw0YoXkqK6rn OoRRLet2Fu7cuwM7gR2mhUzDpIBJXIdEyKj18ssv48svv8T58+cBgFYTI4SYPaMVz65ZtgZF ZUVQSpT46cxP8Pb0hrub+6COzc28j9zM+waOcHSQSbvR0dbFdRgmRy5XDql9fUM9fjrzE2wE NnCyc8LqpasNFBkhZLAOHDiA+fPno6GhAUKhkOtwCCFkRIyWpDvaO+K5Vc/hL0f+AqVCidTv U/Hi+hdha2vb7zHTIj1wVJxgrBDNlpPL4D/W/fSD7/HpB98bMBrL19XVhZTvUsBT8SASiPDc qufg5ODEdViEjHqTJ0/GqlWr8Le//Y2WQSWEmD2jLkMxKWASlscsx6lLp9DU2ISvU7/Gc+ue 63fjCTsHa0yZMbjZdjKwhY/5wtFFxHUYJi9gkvOAjysUCnyd+jWam5phJ7DD8pjlVOaiR1KZ FGVVZVCpVRjvNh7nrp6DXK6Ar6cvxrt54lr2NXi6j0eg70RczrwMNxc3TJk0BWlX0+Dk4IQ5 EXPw8+WfMcZ2DGLnxOLE+ROwtrLGytiVOHa6Z2fdp1Y8hZSfUqBWq7F66Wr8eOFHdMu7Ebcw DheuX4CkS4Jl0cuQkZOBlrYWLJqzCHmFuahvakD0zGiUVpSgqq4as6fORl1TLe5XlmFG2HS0 S9pReL8IUyaFQ6lUIr/oDiYHTIJIKEL23dsI9A2Ai5MLbuRkwtfTB14e3rh66yrGu49DkF8w Lt24hLHOYxEREoFz6efgaO+IqOlR+OnST7C1scWSqCX4Ie0HWAms8OTiJ3H09FEAQMJjCTh6 +ihUKhVWLVmFny79BFm3DI8vfByXMi6ho7MDS+ctxc28m2hqbcLC2Qtxt+QOahvqMG/GPJRV 3UdlbRUip0SiobkepZX3MT10GiRdEhSUFiI8OAxqtRp5hfmYFBAMW5Etbt3JRoCPP8a6jEXG 7RvwGe8Nn/G+SM9Kxzg3D0wOCMGF6xfg6uSKGWEzcObKGTjYOSB6ZjROXTwFG5ENlkUvw/fn vodAIMDqJauR+nMqACB+eTyOnz0OpVKJJxc/idPi05DKpFixYAXEmWK0S9q1zmdB5ALcK72L 2oY6RE2PwvpfPot//vOfqKqpwrVb11FSUYppIRHoknXhXkkBwoJCwePxkFuQh2D/INjZ2iEr /xb8vSfAzcUdGTkZ8B7nBT+vCbhy8wo8xrojJDAUF65fgIuTC2aGzcSZK2dgP8Ye8yPn48cL P0IkFOGx+Y/hu7Pfgc/nY+2ytUj5KQUAsHbZWnx/7nsolAo8EfsEzqafRZe0C4/NfwzpWelo 62jD4qjFyL6TjcaWRsyfNR+FZQWoqa/F3GlzUVVXifLqCsyaMhPNrc0oLi9BxOSp6JZ3407x XYRODIFAIEDOvVwETZgIBzsH3MzLwgRvP3i4jsP129fh5eEJf58AiDPFcHd1Q1hQOM5fOw9n R2dETonEafFp2NnaYeHshTh54SSE1kLELYrDsdPHwOPxkPBYAvs7s2bZGpxIOwG5Qo6Vi1Yi 7VoaOrs6sTxmOa5lX0Nreyti58Yi514OGpobEDMzBsXlRaiur8GciDmoaahGWVU5ZobPQFtH GwrvF2Hq5ClQKBTIL7qDkMDJsLa2xu27OZjoFwgnBydk5t6En5flvQZ4j/NBela6QV8DLt+4 3Od3xlCvAb6efrhy88ojXwN+unQKjvYOWB6z/MH5j6cNAPth9LXilkUvQ0VNBXILc1FZXYmj PxxFwqoEuuDOwOYu9MLchV5ch2HWVCoVjv5wFJXVlbAX2CM8KBzLopdxHZbZa2lrwcnzpyDp kCIiaC5OnP8e7k6eCA+chZr7cgitRaiWKtBR1wZJowi1UhXkrS2QNIqglqiR39UISaMIyg4e cpUNkDSK0G0lQPaNOkgaReDzBci6Vg1JY8+b1MyrVT3HqtW4db0GbXXWUKp4yM6sQ0utAN1y EXJvNqCpjoeubhHuZDehvgmQdIlwL6cVzW0qSCQiFOa3oaNTAUm7CMX5Esjk3ZC0inD/XheU KiUkzSKUKaWwslJC0ihCpUKOJmE7JI0iVMsUkNS39pxPlwpK9nyAfFnP+SjaechR1es8n5u9 zqejQQS1WoVbGT3no1ACtzPr0VzDR7dchLysRjTUA10yEe5kN6O+WQ1JlwgFOa1obldCIhGh 6E47OjrlPedzRwK5XNZzPuouqNVqSJpFKFdIYWWt6jkfuRzN1T3nUyNToqux53zqOtVQtzdD 0iiCqgPIlTc8OB8+cjJ7zkcmsEL2jVpIGkXg8fha53PzWjXa64VQq1XIvlGL1lorKJQi5Dw4 H1m3CLm3GtBQ9/B8GloenE9uKzo6bLEm/jnYCG1RWSKHpE2E4rsSKBRySFpEuK/qAo/Hg6RJ hAqFDNbW6Dmfbjlaax+cj1QJWVPP+dR3AuhgzoeHvO6e/x95Gx+32fOxxq2Mmgfnw2N/xtjz aRBCper5P2ytFUCu6DmfploeZN0i5N9qREMD0CkV4e7tFjS0qiDp7DmfNokCkg4RivLa0dUt h6RVhJJ7nVrnI+ALIGkUoULRDZG1BJJGEaq6FWirffg7093Scz7oBO50NvWcTzuP/f+RWwuQ ndnzMyblW7G/M8z5dDT0lA9lXatGW701VCo+sm/UoaWm53yY3xmp7MH5PPiduZvTgibmdyav De3s+XSwvzOldzsf/s6opBDw5ezvTIN1B/s7w7wG1HQph/EaUGO014DSu51QqVWPfA3obDD8 a0BTNa/nfHr9zhjmNaBlUK8BbXXWaKuTQqwswcVbWVCpu/HM4xvw1c+HMGVyGOIfW0OfhD3A U6vVamMPKlfIkfyvZBSVF0GikiA8LBxPPPYEXehDTJZSqcTRH47i7r27sLeyx0Sfidj87GZY W1lzHZpZUigVuHLzCjJu3cLiGatw6YYY/uOD4OHqyXVoxAKo1WoUFd9B0MRQrkMhhAyCSqVC XVMVGtvrERIUjJ+vpeDx2GWYEzGH69C45MlJkg4AXdIu/OnLP6GirgKdqk74T/DHU6ufoot9 iMmRyWT4+ujXKK8oxxj+GHh7eGPr81tha9P/9RREN7VajVt3bsF1jA+++i4Fk/2mYfxYb67D IoQQYiLUajUq68vQ2lmP6RGTIRDKETE5guuwuMBdkg4A7ZJ2HPz6IMpryiFRSuDu4Y5n1j4D RwdHrkIiREtbexu+Pvo16uvqMUYwBr7jfPHSupfgYOfAdWhm6dCRf6CgsAJLI9fA0W7g+n9C CCGjW3VDBS5ln8TqFY9hwZwYrsMxNm6TdACQdcvwWepnuFNyB53KTljbWGN13GoEBQZxGRYh KCwuxPGTxyGXyjFGMAYhASH4RfwvIBLSBbhDlV+Uj+zcAoy3nwQboR3VGxJCCBkUlUoJNZRI v3sCTz+xBr6evlyHZCyenF+tKRKKsPHpjYieEQ07gR3UMjWOpB7B2fNnoVAouA6PjEIKhQJn z5/FkdQjUMvUsBPYIWZmDDY+vZES9GFobm3Bnz/7O0Rqd9iK7ClBJ4QQMmh8vgACvhDjHCbj 0FeHwfHcslFxPpOu6WbeTXzz4zeQyCToUnXB0dERyxcvx6QgWuKOGMe9wnv4+dzPaGtrgy3f FnYiOzwT9wymhw5+h1zyUMbtDLQ38WGtdoLQmt7gEEIIGT61Wo28CjHmRk5FWFAY1+EYGvfl Lr3VN9Xjy+NfoqKmAjKVDDKVDIH+gVgYsxBenrSEIDGMquoqXLh8AcWlxRDxRRDxRfAZ74Pn Vz8Pd1daq384yqvLsevAfjw2Zx3cnDy4DocQQogFqG6owIXbx/H+jt9Z+gIOppekAz1L8aRn pePHiz+io6sDUpUUCpUC/hP8ETM3BhP8JnAdIrEQ98vv43L6ZZTeL4UV3wo2fBvY29rj8QWP I2p6FK3fP0wtbS2oq+nC/ZIGONm7cB0OIYQQC9Itl0Ho0IEpYcEYYzuG63AMxTSTdIakS4If L/yIa9nXIFfKIVPJIFfL4eLsgimhUzAlfApcnCgBIEPT3NqM3Lxc3M67jeaWZljzrCHii2At sMaciDl4fOHjsLO14zpMs6VWq7Hrr0lwtvZHRPBsrsMhhBBigS5mnYKzBx+bnvk116EYimkn 6YyWthacu3oOV7OuolvZDblKDrlaDhVU8Pb0RqB/ICb4TYC3pzdtiET6UCqVqKyuxP2y+ygp LUFFdQX44MOaZw1rvjWEAiHmTp+LxXMXw9mRlgUcqXZJBw5++TXmhS2ji0QJIYQYhEKpQEFl Jn7xbLyl/q0xjySd0S5pR3pWOm7k3EBDcwOUaiXkajmUaiWUUELAF8DZ2RluY93g6uIKN1c3 iEQiCK2FsLGx4Tp8YmBSqRTd8m7IZDI0NDWgqbkJDY0NaGlpgVKlhAACCHgCWPOsIeAJ4Obi hllTZmHutLlwtKe1+fVB1i3D4aOpCPWKsdQXTUIIISaiU9qBm6Wnse3Xr1hieap5Jema7lfe x43cG7hTdAdNrU1QQ92TrKuVUEEFlVoFFVSjaqke0oPH44EPPvg8PvjgQ8DrSc554MHVyRUh E0MwK3wWJnjTtQ36dkZ8FlfSc/HY3HiuQyGEEDIKpJz/OzYkrMK0kGlch6Jv5puka2pqbUJR WRHKq8vR0NyAhqYGtLS3QKVSsW3UMPvTJI/Aw8OZWz6fD2cHZ7i5umGs81j4evoiaEIQXJ1c OYzQ8t25W4qy0jY429PzTAghxPA6OtsxfZYfXF0t7loyy0jSdVEqlahrqoOsWwZZtwxSmZTr kIiB2YhsIBKKIBKK4OHqQdcnGNmd4jv46cwVRIUt5zoUQggho0jqpb8hcdNmjHMbx3Uo+uRp xXUEhiIQCODp7sl1GISMGpm3b0IocOA6DEIIIaOMh6MfcgtyLS1JN60dRwkh5qu4uAYVpe2w EVn05hKEEEJMjEKpQFCICzw8nLgORZ88Le5SWEKI8TW1NuGf3/+TEnRCCCGceP9P76Fb3s11 GHpFSTohZMRq6mugkNOHcoQQQozPSmAFO5ETGlsauQ5Fr6jchRAyYrJuGa5cKsYYEdWkE+7J FXJIZZ1QqVWPbjyK2AhtIRLSniHEMtmOscbUGRZVk265F44SQozn8g0xispaMC14NtehkFGo sbUeRZV3UFCZh/qWWqihgsjGBnwefVisSSaTQqlUwXGME4K8QjDROwQ+Hv608RixCKfEx9Gm CkPMrBiuQ9EbStKNgJf48AVwc/RmHFh3gMNo9IeL82LGLHinAEFuQQYfjwxOU2szVCr6UI4Y V3N7I8S3z+J+YxH8/AIRPn0Gxjq7w8rKmuvQTJZSpUR7eysqqkvxc/ZxCNUiLIhYjgnjJ3Id GiEjIuALIe22rOW2R22SHrMnBuIScb+Pn9hyAnGhcXoZS52kxp7ze5CYmqiX/kyFpZ4XGboF sxbijtCyagGJabtTehtnb53ApMlhWD3nWQgEo/bP2ZAI+AI4O7nC2ckVU0JmoqyyGD/dPIqJ HqGInbECfD7tL0HMU0zEUsyZ58N1GHo1al/VLm+7zH7PJOz6TMwJGU1u5meiqZ6HIJ9QrkMh o8CV22nIqczEsiVPwsHeopZcMzo/70B4j/eD+No5pFz4EmsXPAcresNDzFD67fNoVrlhxYIV XIeiN/Sb+AiaJR266Cq7eNQsvaYtR7YgWZysdV90QDT7JkKzr+iAaADo03dSfBK2Ldo2pH65 Pq+hxtC7bfD7wX3aq5Oo3IIrza3N6OwScR0GGQVyi2/iduUNrFgSD6G1kOtwLIJAYIX5Uctw JeMcfrp6FHHznqI6dUJMAF1V8wjqJDWbHAM9iaM6SY0TW04A6EkWCxsK2cd5iTyIS8TYHL0Z 6iT1gIkjL5GHZHEyogOi2bZJ8UkQl4jBS+ShsKEQl7ddZscSl4ghLhEjKT5Jq+/E1ERsObJl SP1yfV5DfW57j8m01fwi3FkStRTBfjSLTgyroaUWadk/YlHMCkrQ9YzH42HurEWo7axC1r1r XIdDyJBFhsVgybwlXIehV5SkD8GJLSfYmd240Dhsjt4MACioLwAANlFOik/SuoiydzKq2bb3 7PK2RduQFJ8EAPjo7Ec6Y9CcNWf6ThYn42T+yWH1ayrnNVAMxLTdvncbNY1VXIdBLNz5W6cw NSISjvbOXIdikQR8Qc+Men4apLIursMhZEhu3kvHhesXuA5DryhJ16Oc6hxEB0TjifAn+jy2 bvo6rdtMKcg7j73Tpy2ThOsqF9FVM8/0ffT20WH1+yiGPi9i/uqb6tAuaeU6DGLBahoq0CCp RdCEyVyHYtHs7Rzh6eODW4XXuQ6FkCFRKpRQKBRch6FXVJPOkeiAaIhLxFh5YOWA7TRLTrjs 1xDj0xKKlmNB5ALcyzGdJF2lUkGusJztoWkDGuBOWQ4C/CeBx6e5JUMLDgzD9asXMTd8Ideh EDJoMybPReRsb67D0CtK0vVoiucUJIuT8UPuD30u5DySdUTr9rrp6wa9ogxT8iEuEeNk/sk+ 7ZklENdOXYuwcWF6X6nGUOdFLEdxeQma2pSwH8PNjqNKlQJ5JbdQXHMPnXIJrKytLCaxVUMN mbQLSqUKLmPGYrLPFAR49b1w2tIVVd9BdIxl1ZuaKldnN3QpOtHa0QwnexeuwyFkUPJKbkFt X4WFsy3nzSUl6Xp0YN0BJIuTkZiaiLzaPLZ+W9eqKNsWbUNiaiJWHljZZ3UWzbXHC97Rrsle eWClVgLMrHqyOXoz4kLjEBcaN6x+uTiv4cykMzP1H539iI1DH/2SkamsrYCkXQS/8YFGH7ui thQXcn+Gj/8ETJ8916IvKOzs6sCdwtvILLyCxyLXwmGMI9chGYVSpUCHtA3OTq5chzIq8Hg8 uLq4obG1npJ0YjZk3VJ0SS3rWgqeWq0elctiDGYzo2D34D5L/TE7a/Y+XjMhHcxShUyi3V9b zQsvT+afxMoDK9kEtTddSzAO1O8/nv8H5+dV2FA4rBgA3Us39r5QlRhXcVkpivLbjf4HPbck C/k1tzAnciGsR9Euk+0drci4Icbyaavg7jKe63AMrk3SgsNpf8Xqlc9yHcqocfXmBUx0nIyp QbO4DoWQQZF1SxE5zxu2NrZch6IvnqM2STcnmkk6JaLEFF24dhl15UqjzqSX15ZAXHgOC+Yt H5VrOnd3y3D58hmsmfcc7GztuQ7HoOqba/B9xtd4fFk816GMGlk5V+FmNQ6zQ+dzHQohg3K7 8AbCIjwwb8Y8rkPRF0+6AocQMmKVtRVoaW8y2ngqlQqXcs8ges7iUZmgA4BQKELE9Nm4ePtn rkMxOLVaPWr/nznD44Hm8Ig5kXR1oK2jjesw9IqSdBMXsyeGXSmF2QxIc0MgQkzBzPCZ8PHw N9p4BRV5GO/jDatRVOKiy1gXd0iU7WjvtKw/TIQQMlRTg2ZZ0iw6ALpw1ORReQsxB82tLeiU dcMVbkYZ715lLqbMmGmUsUydj48/iirzMT14LtehmA2lUo2uTstaTxkAhEI+hCIB12EQwon7 NUWwL2nH7KmzuQ5FbyhJJ4SMWElFMSStIvh4TDDKeF3yTtiILObioBHxcPdE/q1bmA5K0gfr bk4TfvfqJa7D0LunXpyE5zaHch0GIZxo62hBU4tlpbWWdTaEEE5MmTQFZQXGW/pKDZXRxjJ1 IqENuro7uQ7DLO3+Ygs8vJy5DkMv3njhz1yHQAinQgMiMHOqF9dh6BUl6YSQEeuWy6FUGrF8 gC4iZPVcUEkX+A2HrZ0I9o6W8YkMX0CXmJHRrbK+DM7lUox1Hst1KHpDv9WEkBG7V3IXdc01 XIdBCCFklOopdzHeKmPGxcVFPgAAIABJREFUQDPphJARmxQwGZUqKddhPFJOZgO+/aIIgCnO xKvw+n/NhKOz5e6YSgghhhLsF4ZpIZ5ch6FXlKQTQkZMaG0NgcD0V8toaZLBZowDXns3getQ +nj16T+iu1vJdRiEEGKWGlvrUNPAw3h3y9mFmZJ0QsiI5dzLgaRRZBZb1FtbC0yyDplHxYeE EDJsTa0NqG3gOgr9oj8LxGAKGwpp86VRIsAnEK5O7lyHQYhZyTy8D7sjbVAqPsV1KISYvQDv YIQFhXEdhl7RTDpHTuafZHcSBYCCdwoQ5Bakt/55iTy992uIPollcHFyRotIwnUYhBjE6Q+2 IjvlYJ/7E/Yeg3/0imH1mXl4H9J27dAaAwCWvb1/eEESMspJujrQ1mFZuy+PuiR9y5EtSBYn a913YssJxIXGDfiYvsWFxkGdpEbMnhi9920qgtyCoE6ipeFGg8zcTEgaRXB1Ms6Oo4bym32x yL+frnXfzpeOYdbkwSdiTB+PR23C1qco4bIETOKcnXIQsW98DABI27UDTfcL4B+9Av/aGIuq 7PQBeugRkbCJTfa3Z0jRVJKP7JSD+Pl/tqK9toIdQ1PsGx9j5oZX9Xg2hFimuqZqVNTIER4c znUoejPqkvQD6w4gpzoHAPCP5/+hNSN8YN0BHFh3AHvO70FiaiKS4pMMkqATYmm8x/mgzgIu evy/V9Pwm32xAID5057GX47vQGVdAXb+dQ3b5snof8f34k/77SP5P3Ox+X97/kisetOmz+Oh E6Lwf6+m6TVuYjzM7HdEwibM3PAqMg/v05mgRyRsYpP73ZE9PwfL3t6vc0Z++f/bj5TX1rDH Zacc1DqeEPJofp6BmBRg+tdFDcWoS9IBYIrnFCSLk1FQ31O2wZRxbI7ejAPrDiCvNg8AMMlj EnsMk7j31rv0g+kLAKIDorFu+jqt45Lik7Bt0TadcekaQ7N9zJ4YiEvEOo9lZvw1xweA4PeD +7TVnN3WNWZ0QDQub7us85yG2+dAn0gM5rntHcNAbYnx+Yz3hqy5nesw9Cb/fjry76cjdEIU yuvyAfQk39fzT+Ivxx+WKGxeuxvJR7fj5dUf49Ktb/r0s/OlY1oJPgCsX/6WYYMnBhX7xsdI 27UD2SkH4RoQiqaSnp8PpvSlpbwIJeJTOPfRdjbZHoplb+9HUOxqpLy2hpJ1QoZAoZBDLpdz HYZejcoknXGv7p7W7WRxstZMO0MzOWaSUaamPPj9YK1EWp2kRmFDIX755S8hLhGzxxW8U4Dg 94ORmJqIJ8Kf0JlQPhH+BJus9k5qmRg0x9KV3DLxDaZ+XNd5MX3G7IlhE/Wh9AkA2xZtG9Qb i/5i0PXcMqVBms9nkFuQVltK1Llz9dZVSBpFiAiO5DqUEdn/7VatchcmWQfAzo5rSj66HQC0 E/cH7X5MPwhrgajPMTv/ugbffWT6a8qThzRr0jXryNN27WCTcGYmXBeviChUZaezM+oAtL7X PFbzfmLelCoFCsvv4G5FDqQKKQQCvmlu0TAMajWgVqmhVqswcfxkhPhFwM7WntOYqurL4VDR hUkBkx7d2EyMyiQ9bFzP1b95tXnsrDnjZP5JNhEMdg/GnvN7IC4R95ldjguN00q8e8+OM330 TuD780PuD2zCPdhkUzMZHg7N82EwbxQGSqz1ZbjP7YktJ9jnJy40DpujN2t9MkKMz93VA3wL yDu3PrVf73Xkm9fu1mt//VGr1biVfR03s9Lx7LpNsLW1M8q4hlJaWoAzaSfwRNxT4FsLOI1l 2dv7B5zNpplu0lthxR1cL7wET28fhM+YjjEcJ7CGolDIUVVbjh9ufA0fJ39EhS8Cn8/NwoFe 7r4I8KFyF7PHlLHkVOewySiT6L3/0/tsuyC3IDaJf+exd/r0E+QWhOiAaIhLxDiZf1Jr5js6 IBoABpVE955x15VoXt52GTF7YpCYmthn9ny4M8iFDYU6S1eMZbjPLTE9IYGTca+zleswRqWq inJ8tu9TfPrBR5BKuzA7cj5qaqu4DksvsrOv4+DfkmBv74BxEzyxKHoFbGxNb417QjRl3L2M spZiLFiwHAI+t28wDc3Kyhp+3oHw8w5EYWk+jov/hVXR6yDgGz+9tLKyhrW1tdHHNaRRmaQH uwezCSDQk1C/ueRNJIuT2Zldrgw0G9x75ptJsoPfDx7yKjSapTKaST7XiTsxTxczLlpEuYs5 8vLxxfpNv4JIYous7AzIu2XY8fp7Zv/Hqqy8CMUld7H6yfUIDZuGRut6StCJycsrvYXazirM m7OY61CMLsg/FHZj7HHq+lHEzXkKPJ5xa3vKqothW9KGAJ8Ao45rSKN2MyPNco5109exM7e9 H2NKYzRn2BmFDYVs25HM9EYHRKPgnQIAwMoDK7HlyBatx0/mnwQvkddnucYgtyCc2HICAHD0 9tEhjXkk6wgA7dIRYzPGc0uMw8XJBWPMvLzCnIlsbfFU/C/x3rt/xAfvfQq1WsV1SCPm4e6F v3yait+++QfMmxfL2UfohAyWVNaFW6XXMCNiLtehcMbTwxdWdlYoqrhj9LE9XD3hM97H6OMa 0qh81eudlDLlL+umr2Pvm+I5BUBPuQoz6665wsjJ/JPsjDOTKI+UOknNlt3oWs1EXCLGnvN7 2NuFDYXshkhrp67Vasu84fjo7EfsfXvO72F3ALWx6rk4STO5f9Qs+qP6HOquosZ8bolhzQid CW93P67DGJHqhiKsetOm36/jF/dxHeKg8PkCCIV9L1g1NzY23Myan/5gK3ZH2vT5yjzc//// 6Q+2spsRDXaMobQn5iHjnhghoRHgjfI3lGEh03Gj+IrRx7WztYejvaPRxzWkUVnuAkCr3IWZ qdVccpGZ5QV6ykyY8pDeybNmqYiu1VY02zNLPAJ9dxzVhTn2Pxb+B3vfYGvSL2+7DF4iD8ni ZK0NmjQv0ozZE9Pn8d7ja174Opg++0v0Nc9V83kYzHPbu8+VB1ayfWiu+LLywMoBl7gkhnM2 /YzZl7t4uk3Edx9JdW5oxOhv3fP1y99il1oMnRCldbyTvTtaO+rZ28n/mQtPt4l6jp7oS++N i2ZueBWnP9iKtF07cOOLJHbTIYbDOJ9+NyICAP95y1F65WedYw21PdCzUsyzh9IGezrEiMob SxA75XGuw+CcQGAFOwd7NLTWwc3Jw2jjllQWQOjcDF9PX6ONaWijNknXtbIJswuoLoNZSWUo q630NxazoVJvexP2DqpfTY/a7VPXczDSPoezy+ijnreB+hzOORD9c3FygbrTMtYWe/3Zg+wy ijtfOgavsUHY/L/h7DKLzHrpAFBel48f0w+yCfrOl44hPec48u+ns+2qG4rwvfhT2oHUjAXF rkZ2ykG011Zge0bPMkal4lNIeW0NAmJWaO0iymAeZxJuXZsbMWuux77xMQLnx+FQfDi6Je1a O5NOX/fvyDrycPOsqux0lIpPwT968LvgEsPrkknomgkNY909UNtYadQk3dXJDePcxhltPGMY tUk6IUR/5kTMRZ6qgesw9MLTbSIej9qEH9MPorKuAF/9/KHW40wC/3hU301qKusKEDVlNX5M P9hnXfUf0w/C1yMUqxfQFu/mpjDtOADA1tV9wHXMW8qLcChe+/89ImFTn82JGMxGSJqqstPh FtTTR8LeY+zYmpslEdMjkVKSrsnOxh5tbcZd8WuskwfGu9ESjIQQouXUxR/NvtxFk+Z66Y9K qnXNjtNmRear98ZFzOZFXhFRmLT8aa3NjADtkpXeCTrzuK6yFs1jNcfRnDlPeW0NEvYeQ3bK Qa0NjxL2HoOzL5VMmRKFQg6BwLKXWxwKK2sryBXG3f2zoCwPfIc6jHe3nESdknRCyIjZjbGD vI3+QBHz96iNi2ZuGPknIY/a/GjJbz7Ruq1ZRkMI0Y3KXQghRIel85Yh+0YN12EQQojZuXym Erczm7kOQycHBwGe/7dQrsMYlHGuXvD19OI6DL2iJJ0QMmLHzxwzm3KX3Mwy/Ncrh7gOo4+O VhnXIRBCOHA3twW29h5YFDeV61C0NNW348D/HjebJD2/JBuqMVVYscByLqqmJJ0QMmLWVtYQ CEz/5SRqkSemzzXeagNDMwV2dqb/HBJC9G/sOEdMDDWtWWB7pxauQxgSR3tnuDq7ch2GXtFf BELIiMUtWmkW5S5W1nzYW4/ujUYIIcQSTRg/EZMDTOuNzkjRXytCyIgdP3MMuUVZRhtPrR7a WvyWjp4OQshod7vwBq7cNP5Op4ZEM+mEELPDU1vGxkn6oFDIIbQSch2GWUp6NwUiG8v4M9hU 3w7AneswiBGkbIxFdbb2rsjhCZsQ+4hVgyydna09HO0duQ5Dryzj1YkQwqmnVjyNrOvVRhuP Dz7UKhV4fPowsK2jFU5jLKsO09A8fezwb29O4zoMvYpe5ISAYGeuwyBGkHAoDSkbY9nvbx3e h0u7dqC9ugxlD3a49YyI6pPIM/cnHEozXrBGNMkvHNNDvbkOQ68oSSeEjNi3p74x6uouPmMn oK6pBuPcLKv+cDiqqssQ6hnBdRhmxWWsDZav9uc6DEL0qqn44Q621dnpWPDmblz8aDsi1r+C 7K/+xN7fWl4EJwvcDOvm3avotHKzqNVdaBqKEGJ2wgNmoOBuHtdhcE6hkKOxpg5e7n5ch0II MRKm3KU6Ox37I21wadcOeEZEYUKMdnJ68aPtAMAm6Iwz724yVqhGJRLawNbGlusw9Ipm0gkh I7Z66Rqjru7iaOeMcQ5eKC0vgL9vsNHGNTWZt9IxN2QR+FT2Q8ioMVC5ymiuSw8LmIbIqZZV 7kKv7ISQETt5/gTulOYYdcz5U5eiqqQc1bXlRh3XVOTkZ2Ks0A0BXpb/JsVKYA2FQs51GKOK QimHtYAuSCbm4+bdq7hw/QLXYegVJemEkBGTK+RQKhVGHZPPF2BVzLOoKi7H7dwMo4/Plc6u DoivnYUDHBEzdRnX4RiF/RgHdHVJuA5jVJFKumA/xoHrMAgZNIGVAFZWllUgYllnQwjhxIoF jyMvq8Ho4wqthHgyeh2Kq+7h4oWfYetgBw8PT4hENkaPxZBUKhWk0k7UVFXCCtaInRqHsU6j Z7k9obUIUPPQLe+G0Jpmd41B0tkBB1vLWs6OWLYZk6Iwe7ZllbtQkk4IGbFLNy6ipUaAEP+p nIwf6DUJgV6T0NzWgLrmGrS3tFnUhkcCvgBeY3wxK3IextjYcx0OJwLGTUJ5ZTEm+odwHYrF 6+ySoLOjAx6utHoSF/ZH9p1keCE1V2tFFubi0fCETWgqzGW/H8016Rl5l9HOs6zVXShJJ4SM mKRTgm65iOsw4OLoBhdHN67DIAYw0WsysiquUpJuBGWVxQgYH0wXJHMg7YOtAIBVe4/BL/ph stlaXqSVvC94cze7DvrS3x/EF/Hh7GO6kvzemOUZ+/NCai4gGDvk+Il+0W8gIWTElkQtRbBf KNdhEAs2eUI4OtskqGs03qZZo5FcIUdeXhZmhy7gOhSi4ebnuwH0JM+eEVHIOPihznZMkv9C ai573wupuXghNRcL3uzpY9XeY2gqytXqz9a1p3wuPGETtmZIzXId9aipiyxqFh2gJJ0Qogc3 8zNRWV/GdRjEgvH5AkSHLUHmzXSoVSquw7FYuXcyMXH8ZLg5eXAdyqjElKt899oa7I+0Yb8E 1j2fVH4RH47q7HR0NdUDAHJTHs6i56Yc1GrH+CI+HF/Eh+P+pZNs3+3VZf32d+vwPiOcqf6l 3z6PUxdPcR2GXlG5CyFkxJpbm9HZxX25C7FsIf5TUViVj4xbYsyeMZ/rcCxORXUpKu+X4/nH NnMdyqi2NUOq835mJvxRBtuOmD6aSSeEjNiCyAUI9J7MdRiPNPdrX/aroqO03/uIaeLxeFgx Nx4tdU3IyrlqURcHc62iuhQZ1y9j7fwNsBWO4TocQoYsMiwGS+Yt4ToMvaIknRAyYneK76K+ xXg7jg7X9uk72e9/f/11fFVwkL29NvB5+Nj7Gz8oMiRCKyHWLf41JA0dOHfpBLqknVyHZNaU KiWycq7i5o10PL3wl3BzHsd1SIQMy8176Ra3mRGVuxBCRqy+qQ4SiXmVu2Q3ZCC7IQMAEOEW CQB4+Vw8ex/wMKnfnbWzz/FrA5/HW7P+oPOY9cGb8FXBQZ3H9efqM+V9+mJ8G3eR3kBosBHZ ImHRC0jPOY8ff0zBhIkTERwQhjE2dhCY0GYmarUaPB6P6zB06u6WobSiEHl5t+Dr6o8Xlv/b qF3ek3NqNcSnc1BVWjvirro661FSdAIurpPh6R01or46O7sBmM+nVUqFEgqFZW1qZzqvZoQQ szV32lwU5bdzHcagbZ++k02g1wY+j+K2uzha/GWfdsVtBXhr1h9wuuJ7ZDdksAn4y+fiUdx2 Fx/e+G2fpLq4rQAVHaU4XfE9Itwi8ZfFqQB6ymoG8vK5ePxlcSo+vPFbHC3+UutY0hefL0B0 xBJEBEXiz3//CH/8r//B4oQ4BAZPhlAkBF8g4DpEZF5Kx8z5I0uU9EoNyGRSSDo60N7WCv9x wUiIeQHjaD10Tq3eMBFtzbJhH9/dLcPZk0dw89p5NNZXw8PTFxs2/jusrKxHHFvCc+bzycqM yXMRSZsZEUKItoqaSrR2KOFk78J1KIPi6xCIq8+UAwAqOkrx0tl4AA9nx5lEWVOEWyTWB29i b5e3lz7yGE1rA59nH39UAh7hFol3Z38yrHMbLeRyOb44/Gcc/+4wqmsq8OLzr+DZNZvQ2tGM 9s5WKBRyTuMrLMjH5ZNn8eSSZziNQxOPz4ediz2c7Jzh4eoJPp/7NzIEcPOwhZuH7bCPr6+t hVzeDPdxbvAL8MNvP/hfWFuPPEE3N3klt6C2r8LC2Qu5DkVveGq68oYQMkKHv/sKkkYRIoIj uQ6lXxUdpXjq5MO1n7dP34kYz6Va9z1KhFsklvk8+cgyloHaRY1fhPSa833uj/SIQUbd5T73 f7LgM0SPXzzoGEeTs+d+wLdHP4e9nQP+94O/cB2Olv/b9f/w408pOPV99qhMmEabmsZKZNdk YGrYLKONKe3qwjef/x0ymQxrn30OPx5NxTO//DWEQqHRYuhPc2sDGu7XY+G05UYbM/32eUwO t6gdRz0pSSeEjFhxWSmK8tvNZiadC8xMOyXdI6dUKrD/z3+An28gxoyxw5zI+XB2Nq3dEV/8 9eNoaKjF7/9rD+ZY0Mwe0a2lowmX7p3GrBnRBh9LrVLh5++P43ZmJtY8uwFBIaHs/TwT2SW2 urYCqhYlIkNijDampKsDs6K84GjvaLQxDcyTyl0IISNW11iP9s5uStI19J65B3pm2ClBH5mm pgZ8sncnnn7ql5g2dbZJXpxZV1eN9U9vRHVNJZqbG7kOhxiBnY0DOrsMv9JQbtZNnEj5BrEr 4vDGzv/WesxUEnQAkHS2YdwY49aHF1fehU1BM+bNmGfUcQ2JknRCyIiVVBRD0iqCj8cErkMx GT72/mzdO9GP3Lyb+CblM2xP/D1cHsycm1qCDgAeHp4IDYmAXNGNFY/Fcx0OMQJrK2vwFT1L WgoMUOtfU1mJw4f+iqCQELz+u52wMvESqtrqakRGGm8WHeiZSW/rsDHqmIZGSTohZMRmhs9E yR0J12EQC3bsu8OoravCO299BIHA9P90dUk7YWtrx3UYxIgm+0xFceldBAeG6a1PSUcHjvz9 EHh8Pl56LREOTk5669tQOiRtEPJEsBUZ9+c/NCACM6da1kpFpv9KRwgxeR2dEnTLdW9lTchI yOVy7P/zhwgLnYbNm97gOpxB60nSaefO0SQ8YAaOnD8Eb88JGDPCN2gKuRzHj/wLtdVVWL1u A7z9/PQUpWGp1WrczErHsqmrjT52ZX0ZnMulGGti16eMBCXphJARu1dyF5JmEca7+XAdCrEg NTUV+OOfPsCvfvEqgoP0NzvZ35r1+tw06tXTGwArYO2YniU6ieXj8/l4bOZanLz6LaKjl8BG OLxlFS+fOwvxuTN4bPVaJDz/op6jNBy1Wo0bWWKEjI+Aq5Ob0cdv62hBU4tlpbWmc5UBIcRs TZk0BZ5GTtBfPhePuV/7Yu7Xvnj5XE/dL3N77te+qOgoHXRfFR2l7HEf3vitgSIefCwvn4tn z2m0upZxEX/77I94+z//T68JOtCzrCXQswzn1WfK8W3cRQAYcDlO5v9lsD8fr4e/iyC3kJEH S8yKq5MbVsxYi0sXT6O2oWpIx5YUFGD3f7+LbpkMO3a+h2mRsw0Upf51dklw4fJPmOA0ERFB 3CzFGxoQgcipprsM8HBY1lsOQggnuuVyKJXG3Y753dmf4PO7f0agYzCK2wow92tfbJ++E6cr vgeAIc2I+tj749u4i/j99deHFENFRyl+f/11BDpOHvRs6aOO8bH3H9U7jarVanx5+AB4PB5+ ++YfjHJhqI+9P7sLLfP/o7mTrJedL6okPRcBZzdkaG1axVwc/PK5eK1jZtVFg+/Kx9HiL/ts csXM2Pc+Zvv0nShuK9C5kdZfFqdCXHMOr1/8RZ/46QJl0+LmPA7PLPgVruSm4d6dHIz39oGT owtsRbrLn1qbm/Ht55/DxW0sfvHKKxDZ2KCj0/R3cO6Wd6ND0oaa6kpADiyLWAU3Jw/O4qlt qkJ5tZLKXQghRBNX5S7FbXdR3HaXvc0k6OXtpTpLGq4+U94nMWIkLfic/b737qH9bTTEGGzi 9qhk76uCg1obIGnuiqprlpdJLHtjdkE1N13STuzd9z4WxCxD9LwlnMTw4Y3f9vn5mDNuIV6c /G/9vrnSdUxdWzXKRSWA08MNqZj/x6dOLsDawOf7HFPcVqAzpkDHyf0m6EDPz9lofmNnimxE tlg8Mw7dim6UVhegvroWtdJqrTZyuRyXzv6M9rY2xC5/HI7OzqgureQo4qETWgnhYj8WS6c8 CYcx3K9N3tTagNoGrqPQL0rSCSEjNilgMipVxr1w1Mfev0+S0/s2M2PJJDhMMsMk4cwMJdCT CGc3ZLB9aCa6H974bZ8kfW3g80NO3B6V7K0P3oT1wZu0Sl00E/Te53O64ntEuEUiuyED26fv ZI/VfONiLkpLC5F8cBde2fKf8PHxN+rYFR2l7JudbpWM/b/v/WZNE/OGKtIjRucxqm4V8GCV PGZtfM1Pd4rb7uoc561Zf9D6ufjwxm9R3HYXsd6PI8Kt56N8SsjNh9BKiEm+4ZjkG87ep1Kp cPz7w8jIFOPF9f+OsNBpHEZoOYL9wjAtxJPrMPSKknRCyIgJra0hEBi33AUAm6ACumeVmaTI zz6ATXA0j3139id97gt0nAwAfZImXYlTea+690clbrowxwxm9ru/84lwi8T64E0DHmvKzp0/ iZtZ6dj5uyQIhSKDj8fMSO/O0v6ZYUqeepeoHC3+EsVtd9k3ccxjEW6R2L/oX3j5XHyfYypb 7rN/YXt/qvPJgs/wt/y9OsfR9XOyNvB5zBsfi7L2IuzO2tmnP3P95GQ0yrp1DUe++RviHk/A +zv3cx2ORWntaEZjixDj3cdzHYre8NRqtZrrIAgh5u3wd19B0ihCRLBxL9rpPSPOJC9R4xch veZ8n/ZJCz5H4sW+qyW8Mf2/sSvrvwA8nCEf6CJCpt1bs/7QJ2FiYumvrEbzjcVgj/lkwWc6 Sx00y3Ai3CKxzOdJNuk0h8RNpVLir4c+gYeHF9aufo7rcPRq956dSPyP34FvgI1tiPmpqLyP vxzchbDQaUhY+wtYm/hmROYo/fZ5TA53w4oFK7gORV88KUknhIxY+s3rqCrtph1HyaC1tbVg z/73sPqJZzEtwnxWsRisjz/5HXa8/h7XYRCOdXS04+DfPwGPx8cvX9gKJycXrkOyWLVNVZge 6QlfT91LrJohTyp3IYSMmIuTM1pEtOMoGZy8/Fv4JuUf+I9X3oaLi/HXUybE0JRKBb5J+Qfu 3M3BL1/cCv8JQexjui5qN4dPvkydpKsDbR1tXIehV7ROOiFkxDJzM1FRV8p1GMQMfPfDV7h8 5Qz+32//jxJ0YpHOnPsev9v5HwgImIR33/lEZ4L+yYLPcPWZcmyfvhMAjHqx91DX/DcXdU3V qKip4DoMvaKZdELIiHmP80Fdt5LrMIgJk8vl2PfpBwgLnYaXN27nOhxC9K6wKB+fffEnzJwR hfd2/hECgXaKJa45B6DnIndmxR9mRSeg/6VWR+LbuItafWpeYN97Gdj+rn0ZaOlafe7SO1J+ noGYFGA5F40ClKQTQvTAZ7w3ZM2mv/kG4UZDQy32ffohnt+wWe+7hxLCtcameiT/9WN4uHvi rd/8Aba2dkPuY6ClVhlMgr028Hn2GObC8d5r8QM9F5P72PuzSTbQ86YgxnNpn2VgB7MOv66l a02JQiGHXC7nOgy9oiSdEDJiV29d5WR1F2L6Mm5cxs9njuPN7e/Dzs6e63AGRdesIbMOPSEM mUyKz7/8FE3N9dj4q20Y5+E1YHtm9nx31k74OgSyt3vTXGrVReSGZlkDm5gDwCLvFThfeUpn 37pmtb8qOKhzFlzzcWZ2/VEJuK6la01FVX05HCq6MClgEteh6A2t7kIIGbHTl8+hsQoI8Arm OhRiQr7455/B4/Px3PqXwePxuA5nUJjZQs3NoTQ3ixosWt3FcqnVapw89S3EV85iw/rNCA+b PqTjdV04GuEWiV+HvtbvbLau9gMl3uNsvVDbVaXzOM3lajXv11zCVVN/Oy4zs/emoqymGBEz x1tSkk5LMBJCRq6iugr3clphP8aB61CICeiSdmLf/v9BTPRSRM9bwnU4Q8Ik6b0TkP7KAfqt 100DEPvwZu96X821+TX1l3yZUu3vaHYr+zqOfPM3LFm8Ektin+D0zWdFR2m/uxePRlUN5Zg2 azwCfAK4DkVfKEknhIwcV5sZEdNTUXkffz20Gy/9+nX4+PhzHc6w6Jrp7A8zM9m7XvfjT34H 3yf9sTtrJzsLz+xrUeXNAAAgAElEQVRUu9xntc4Enekv0HGySdf+jkaVVWVI/uvHmDgxBOuf 3giRyIbrkPr8nF59ppyjSEyDJW5mRDXphJD/z96dh8Vd3fsDf7Nvw76vARJCCGELECCBmE0T W02MVdPWLrcm6abVatVq76+39N7bauPWWu2iptfaetW6xrhFTUhCFmLIBmEPS9h3AszGNvP7 gzvjAAOBfGfmDMP79Tx5JPCd73kPweQzZ875HMl8vX2hVc6P5QxkPkcKD+DM2RP4xc/3wNnZ RXSca7K7YLt+3W2ELBrN8gbsOrQdfUPds16vq9GMwd7eHjviduLz5g/w9Pn8CSfBrg5dj8+a x1/QGrvfY2ceseq1vwuJ4WFE99+XDx9vP9GR9BZ6UT5ZkF8oIkKCRccwKc6kE5FkHV3dqCzt gZvL3Lsa0Pyn0Wjw4t6nEBwcjlu2flN0HEl0M+KT3b7k3/DmpZenfN7oet1hYFPHzfjNA3+a 0G3D8MAaw816V2Nta38XAt1hRBWVpfi3b9+D6OglV38QCWWLJ46ySCciybjcZeEaHOzHs8// N276yh1ISc4UHccq9PR24f39r+N73/2J6Ch0DY6d+BwffvwWtm+7E6syTNu3nMyHy12IiIzw cPfAyICD6BhkYbW1lfjna3/F3T98BAEBtvU2sxQqlRJubm6iY9AcGR5G9N/5z005jIism593 AIJt7O8h/gQSkWS56XkoP98tOgZZ0AcfvYm29ib8v0efYDEziVqthKuru+gYNEu9vd3460tP wNvbDw/97DfwlHmJjkTXwN87CCEBPHGUiGiCA4WfcLnLAjE6Ooo//uk3SFiWjN13PSA6jlVS KhVwc2ORbu2Gh4fwyj//hN6+Lnzvu/ciJDhcdCSSoKaxHPaenQgJtJ1C3V50ACKa/5wcnTib ugB093Tit797GDd95XZsuWG76DhWS61Wwf0ajoYny9Bqtfjok7fwn7+5HznZ6/Dwz35rkQK9 Wd6ArDcj59TiExjfZJz1ZiQeO/OImZJN1SxvwO6C7dOOqfv67gLr+XvAS+YDPx/r6b5jCtw4 SkSSKZRqlJxph4M9C3VbVXrxDN7/4HX85Mf/Di8vH9FxrNqRwgNwd/dAZnqu6Cg0yYXS0/jX m2IOI9IV52/fWKjv+KP7fYQsekLxrvucYXcgXcvFyYdn6frwz6VjkO5xc7neMAPwZYciw65F IvXL+7AyKwz+Pv6io5hKKGfSiUiy9w/uQ1ntedExyEz++b9/QcnFM/jFz/ewQJ8FlUoJN65J tyqtbU34zeMPoaSkGL/8xVPYuP4mixboJ9oL9B9HyKLxTN4rAMbbcn7t47wJBfoDqfn602X/ UfUX/eeA8Rahk0+krRuoQbO8AZ83f4DkgAycur1pVj3Uddfr7n/q9iYkB2QgOSADb99YiOSA DNwSe6f+fpPvuSZ0IwDgvbpX0SxvmP03w0wq6ktQXDr1tN75jNNeRCQZl7vYJrVahef+/Fvk ZK3DmtUbRceZN9RqFunWQqGQ45VX/wSVSokf7HpQWBeipsE6ANAXxatD1iM5IGNKT/7kgAzs iNsJYHxJie7rO+J2olnegLqBKv3M9XQ9/XVuib1T//XpDuLSHd6lG3M61jZrboyHmwxeNrbp l/+qEpFkWzduw/nTbaJjkAm1tjXhhZeewq7v/RQREdGi48wrSqUSrtw4KpRGM4Y3334ZFZWl +O6370ZMdJzQPJGesQAwYRZ8U8RNKOkuRnJABmK94vFe3auI9YrXf33yLLpudv29ulcnFOfv 1b2KuoEqbIq4CU+fz5+y5j075DoUtR+ZcS387oLt+jy6sUu6i1HSXTyh0LfWAh0AYsPjkRgX JjqGSXFNOhFJxsOMbEvRqSM4dfoIfrj7Ybi4uIqOM+/sffkPuHXbnfD1DRAdZUE6cfIQ9n/0 L6s7jEi3yfJXmc/oC25z0s20m+vE2hPtBbi/8DtWM7vOw4yIiMhmaTQavLj3KQQHh+O+e/5D dJx5S63iTLoItXVVePmVPyJ9ZQ7+61fPwdHRukqcX2U+g699nIevfZw3qzXjc2W4yVQnOSDD LAV6s7wB9xd+BwCsokAHbHO5C2fSiUiy4eExLneZ5wblA3juT7/BV7bchpTkTNFx5rWnfv8f uP/efNjbszeDJfT1deNvf38WHh4y3Pn1H8DT01t0JBJgaFiNjJxwuLnazGm/nEknIunePvAW l7vMY7V1VXj1tb/ixz/4ubCNdbZEq9WyQLeA4eEhvP7mXrS0XMa3vvlDREbEiI5EAp2rOgWl o00td+HGUSKihezzQ/vR2FSPf39kDzv00Lyg1Wrx8YG3cfzEIXxjxy58584fi45EVsDF2dWW ZtEB8MRRIjKBrRu3IXFxqugYNAejo6N45tlfY3R0FHd9914W6DQvlJQW4//96m64uLjiv3/9 PFYkrhQdiaxE0pJ05KTliI5hUvxbmYgk+/jIRxjsdkZiLAv1+aCntwt/+stj2HH7TiyNSxQd h+iq2tqasffl32NR1GL88hdPwdXGZkxJuuLy4xi043IXIqIJRkZHMDbGN+bmg4tlZ7Fv/2u4 757/4OmhZPV0hxGp1Sr8cPdD3DNB03JwdLC6jj5S2dazISIhNudtQfn5btExrmp4dBgdPS0Y VA5gQHEFCvUARPa3snewh6erD7w8vODt4YsgvzCzbjjct/81qFQK/OLneyx6JDrRXGk0Y3j/ g9dx5uxJfOubP0D80iTRkcjKZSbkYlVOhOgYJsUinYgkO3amEFfaHbAs2vr+IdVoxlDRUILK plL0KXsQFBQKd5kMrh6u8PH3BwQWqxrNGFRqJfoUXZC3D6Lni25E+C/C8kUpWBSy2GTjDA2p 8fxfHkNW5lqsWb3RZPe1FXLlIOTKfijUCqiGFJLv19PfhYu1Z02QbH5xcnSCzN0b7i7u8Jb5 XfMLzhNFBXjnvX9g283fwH/lP2filGSrikqPoE/D5S5ERBMolAoMj7iIjjFFTVM5jl08iKCw ECxPSYWPt5/oSDPSajTo7G1HUfURnKo4ivWpNyLQN0TSPdvamvHi357GXd+9FxER0aYJagO6 +tpRefki6toq0dXfAWcXF7i5usPF1RV2kPbCrXuwA+caT5ko6fwxMjoMlVIJtVoFdxcPxIYu xZKwBMRGxM/qnZu6+mr8z9+fRfrKHDz+3y/Y3NIForniYUZEJFlHVzcqS3vg5uIhOgqA8Rnq grMfoVPVgVXpuXB3k4mONGddPR04XXwM2UvXIjE27Zru8cXpQhwpPIB7fvQo3Nys489GtN7+ bpy8eAjVreWIjIpBeNgihAVHwdnJ2WRjvPj7p7D7pz8z2f3mG92LzZa2BjQ01MLT2Rt5ydcj JizO6PV9V3rwt5f/AJmHJ76xYzf3StA1W7XGppa7hLJIJyLJPjn6KXrb7LAkIkF0FIyMjuDd wn9C5u+J1BVZ83rt9fDIMI6d/BxRPtHIS7lh1o/TarV47Y2XIJN5YutNXzdjwvmlvP4CPi3e h6joGKQkZprlxdvY2Bhefv6P2HnvT01+7/loTDOGykulKC8/j/iwFdiUeRMc7MdnyIdHhvH6 v15CS0sj7vzG9xEVGSs4Lc1nRaVHEJ9oU8tdQtmOgYgk6+vvg1IlfS2vVFqtFh+dehuB4cFI S8qe1wU6ADg7OWN97ha0KVpwtrpoVo+Rywfx+BOPYnlCCgt0A8cuHMRn5/dhbd4NyMlYb7Z3 V4bUKri6sT2gjoO9AxKXpuKrm29HU3893jr0CoaG1ThY8AHy//M+JCak4tGHH2eBTmQEi3Qi kiwvIw+x4fGiY6Do4mHYuQLL4pJFRzEZO3t7rF61HiWNxWjqqJ/x2rr6ajzz7K+w63s/RWrK KgsltH5nK0+ipPE0tmy8FaHB5n07XK1Sw4U9vCfQarVwc3XHlg3b0dzZgJ33bINapcJ///p5 pK9cLToe2YiM5WuwIWeD6BgmxSKdiCSrrKtC15V2oRn65X0ob7mAjFTb+0ffwcERa7I34OC5 D6DRaIxeU3D4Ixw5egC/+PkeBAZK22xqSy631+Jo+WdYl7cFXp7mX+usVqvg6uZq9nHmC61W i7//+Xl0d3TgT3t+B5cxV+Rt2wSPEE+zthulhedcdRGOnj4qOoZJces0EUnW1dsJhUJsd5fC ks+QnJwBuxn+4T/2eQtefLoUweFeFkw2Ow2XevCnNzYhIMj4LKzMwwuBoSEorT2DlLhMAOMF obOzM/7n739EePgifO+7P7FkZKs3phnFp6f3IT01B77eARYZc0iltuhpmK3NcqgVoxYbby5c 3B3w1iu/x6XKcoyNjeKbu74P/8BAKJRyfPDxG0iITkawX5jomGQjxkbHMDpqnf8vXCsW6UQk WVZKFmorBoWNr1DJ0THYhvTQq8+ip2TF4KHHrW+t9ve27LnqNcuXpeJwwcdIicvE6eJjqK+v QtWlcuy47S4sjUu0QMr55VzlKTi6OWJx9DKLjalWq+BiwZn0l54pg4OjOwKCrauDUXfHICpL n4BCUQf/wCAMqYfg4jL+Qt7DXYb4+BUoOPsxdmy8a97vHSHrkBafhYzMcNExTIpFOhFJ1tze gn75GLxlvkLGr22uRETUIiFjW5KrsxtcXF3R1FqP3/7uYbi4uOK+e36J2Bjx+wGsjVarRXH1 caSvWm3RIlCtUll0Jh0AvrojB+lrjLc3FOWtl19FfU0Q/vMP/4GYuKnZlsen4b2aV9HR24oQ f9sqrEiM8voL0MpasTZzregoJsMFYUQkWUtHM64M9gobv7a9EpGh0cLGt6SQsHDc/+B3oVQq kJqSBQ8PTx76YkRbTzNGMILwEMu+eFOr2N0FAGKXZiEy+g6jBTow3rkoPCwKl5orLZyMbNXQ sBoqtUp0DJPi3+xEJNnKxJWorxTXgrF3sAc+Xv7Cxrekvo5eBIQE4+UXPoRM5ik6jtVqaL2E kNBwiy+lGFKrEBAUZNEx56vw8EWoKStHbspG0VHIBiQtSUd6mm3tcWCRTkSS9fVfgXJoGH6w zOa8yTTaUZMUYw8/tw4Vlyf2I8/ftQ/p8bM/HEN3jy3ZO3H3156XnGmypNSVgEbLAv0qugc6 4C+gWB5vwcjuLrMR4BuMooHD0Gq1XJdOktW1VMG1pg85aTmio5gMi3Qikqy+uQ6KfhdEBFl+ XfjI6AgcTLTcY889h/Hwc+sAALkpt+HF9x9ES2cN8l/apr/mptU/wgcn/jztPV74eRm+/7vx TZw3PzS1WEtYlI099xy+5ozubh5QqMVt0p0v5KpBBLpZvhUlDzOaPXc3D2i0Y1ANKeDual0b X2n+UajkGJDb1gtkrkknIslWLF2B0ADzHhIzHa1WA3t7B5Pes+JyEV58/0EkLMpGU2cFgPHi e/fWJycU6N+/5WkAwO6tTyJhUTYSFmVPuE/+rn1T7r3j+kclZbOzs4dGa7xXOn1JqZbDzcXy xbJKwMbR+cre3h6OTs5QDilFRyEbkBCTjIykDNExTIoz6UQk2fDICMbG5n9/2uffvnvCcpeK y0X63+tmxw298N4DAIAX339Q/znddZ8U7YWTw9Te8fkvbcP+J9QmzU1TaTA2Y898cxnixtE5 sbe3h3aaA7qI5qKlqxE+TWr4+9jO/iQW6UQkWXV9FRR9LggRNJtuKnd/7XmTryPXzbbTwjA8 PAQnZ2eLj/v6XevQWjJxP8Wtz+5D9Orp91PoHpN8605s+oXp908QWdKA/Ap6r9hWWWtbz4aI hFixdAUaa2yr9RXRtRKxCfLrfzuM1+9aBwDI3jW+pOqde7dNe31Ycja2/Hov/rZ9/J2f6Yp8 3T3CkrMnfH39Q0+j4IkHpr1/1i8/uoZnQXTt4qKWI2VZqOgYJsU16URERDaitaQI79y7Db2X a/BAsRphyV/uk1j/0NMTrutrqtX/fsuv9wIA1v3sSYQlZ094nO563eNvfXYfemrLAAB3vVuG sORsuPkFAgCSb92JB4rVcAuMMs8TJJpGT38n2rvbRccwKc6kE5FkF6svQtHjgkBfy3fTMJW2 7lqj6851dm99Elvz7rFgIqLZ+/y3d0+Y6T781IPora9A9q5H8c692xCWnK0vrHXevXcrAKDk nb3wX5yof5zO5Jl43cz5O/duQ3TO9QCgn4nXKXlnL/xiEoBFW0z0zOa3fnkf6tqq0d7bgqFR FWArrSa1Wjg5OMPb3RdLwpYhyC8M9gL2gBjq7e9GR7fQCCbHIp2IJFsaE48WzfzeDBkasBj7 n1Ab7ZWuM11LxR3XP6pv05iwKHvC471lgeiXd+l//8LPyxAasNjE6ckayAfHW2MOqS3fK33T L56fdl35A8XqCddNJ23Hj02W5+yJSya713zUN9iDoxc+xZjTGMLDo7A0KRFuru421Q9+eGQY /f29ON92Gj3nu5CTsA6x4UuF5eFyFyIiI2TuHnB2so3+tPd/fa/+4/xd+/DCz8dnH3UdXHSt GHdvfRJbsnei4nKRvkDP37UPi0ITJ1yXl3wbAGBL9k7sf0LNAt2GvfT7p9Hb3YW9f/yD6Cgk UEPbJXxU/BaWpSQhZ9U6RIXHwt3Nw6YKdABwdnJGYEAIUlZkIu+661HWcRaFFz6FVqsVkqdf 3oeeKz1CxjYXFulEJNnZsrNo7mwQHcMkQgMWY0v2TgBAS2cNnnl954Svf/93iXjx/Qf1/dMN tXTWIHvF1gnX6fqqf1K0F+8XPmfm9CRSUGgovjh+HBFRlj/Ui6xDe3czTtcew3Vrt8BL5iM6 jsU4OTohIy0XI26jKCo/IiRDZ28bmtubhYxtLlzuQkSSxUTEonV0WHQMkzFsxXi1dejGWjay D/rCtCJtJfa98Rquv3mr6CgkwJhmFIdKPsKa3E1wMPEBa/NFQlwyTn5xGO09LQjxD7fo2DHh cVi+xLaWu7BIJyLJfL19cMVFIToG0Zz99udfoKdrCPYO0t9Y1mrHYIcA/Md95yTfa3REg5R0 P/zbT6bfzEzWpaS2GNGLl8DZyfJ98q1JavIqnCg+hFvzvm3RcYeG1VCpbasVMIt0IpLsbNlZ KHpc4OcdIDoK0Zz0dKlxzy9vw5Llppn1a2v8KkKjlki+T8GHF3D22FkTJCJLqW4tR17uJtEx hHNzdQec7TCoHICnu5fFxm3taoJnswpLY8RtXjU1rkknIsnCgyPg4+knOgaRcKYo0Gn+GR4Z gr2jPewEtyG0FkFBwWjuaLDomFGhsTZVoAOcSSciE4gICcdQ36DoGFcl83JCW3MXHviW9W3g 9PV3haMj/4GnuWtr6kVtRavoGBO0NfeKjmBRcuUgPDxkomNYDZnMGwPdfaJjzHss0olIslMX TkHR44LkuAzRUWaUuioIqauCRMcgMpmV2UForKlBY02N6ChTpGcvnP/XhkeH4OjkJDqG1XB2 csbAcL9Fx2xsq4Nb/QBiImIsOq45sUgnIskC/YJgz4YmRBZ30+22U5AQSREWGImYiPl76rUx fG+ViCRbFhuPQB/b+suRiIjmD0dHJzjZ2LsZLNKJSLLC4kLUtVSJjkFERAtUY1sdquurRccw KS53ISLJfL19oVXa1pHXREQ0fwT5hSIiJFh0DJNikU5EkqUlrETlaI/oGEREtEB5uMngJbNc X3ZLYJFORJIdKjo4L7q7EM3k/dfO4MWnDup/n5Achj1/+9aMjzlzog4AkL46dtprHr7rn6go acUL7+7GM7/6UP9xaKSvaYITEepbauDs04fI0EjRUUyGRToRSebh7oGRAQfRMYgkOfZZxZTC /PnfHsAn71zQ/z4hOQwVJVN7kickhwGA0a/lP3sb8u99CwCwY9dq5N/7Fp777QGUnG40eu1M BT8RGefnHYDgAC53ISKaIDc9D+Xnu0XHILoqpUKO/3nuj3B2cYWntxcGB/qhVGwCEK4voG/O 2KO/Xld8T/5YZ2VODM6erEdFSavRryckh+GNl04AAN75xxe4fKkLAIwW6AnJYSzQia6Rv3cQ QgJsq8sYi3QikuxA4Sdc7kJWZ2R4GE0N9ehoa0VH6/gvpVKBIbUaRz//FE7OztCMhUGlHAAw vmRlf/HDglMT0bWoaSyHvWcnQgJtp1BnkU5Ekjk5OsHBgX+dkGWp1EpcvlyLltbLaGltREtL IwYHx085vNx5CS01jYhdvBTBYeHIyFkN/8AgODo54dUX/4pv3LUbX/nabXj0h0XwD4wS/EyI SCovmQ/8fPxExzAp/qtKRJLdeN1XUHKmXXQMsjEajQZt7c1oab2M1v8rwnt6u+Dk5AwA8PL0 Rnh4FMLCopC7ehMCA4Lh6ekNAHhh/5PIyrkOQf6hU+575+4fWPR5EJH5hQdGITZy6pKz+YxF OhFJ9v7BfVzuQtdELh9Ec0uDfja8ra0ZGo0GAODk5ISgoFCEh0VhWXwyNq6/SV+EExEZqqgv gca9FZvzNouOYjIs0olowbh8qR+Fn7fCDtZ48JIW27+9BO4etnWs9dCQGi2tjeju6dDPhvcP 9MHObvzAa8PZ8I3rb0JQYKjNHe1tTmdPdqCnSyU6hlF+ga5Iz7Gd9cFk3dgnnYjIiK9tvg3n T7eJjnFVTQ1yVJercMfu9aKjTPHkI//C5luj512RrtVq0drWNGFJSntHC8bGxgAAnv9XhHM2 3Dw+fOsyImIiEbk4SHSUCZrqOnHi8GUW6WQxseHxSIzjchciognePvDWvFnu4uPvgZRV1tfm ztHZXnSEaSmVcjQ21euXpLS2NkGr1QIAnJ2dERgYwiJcEC20SFsdh/Q1caKjTHD2xCU01k5t M2lLDny+D2UXzyJxeRoWx8eLjrPglV46g2GXy1zuQkREtkOjGUNbe8uE2fC+Kz36jj2Tl6QE BobA+f82b8537h5OePbXb8PJyboO41KrRrE8hS92rMHQkBrOzi7o6GxFgH8wqqovwt3dAwnx SXjt9Rfxxlt/g6+vP9Jys5AQlwxHLtcSwsXZFW6ubqJjmBSLdCKSbL4sd1nIWlob0dJ6Gd3d Heju6UR7ezPGxsY3aDo6OiI4OGxBzob/1x9zREcggdRqFdRDKgwMXEFgQDBOFx/H2rwbcKTw AGJjlmJwcAByxQCSVqSjo7MVwUFhCAgIgr9fEOrqq+Hj44d/f+QJpK/KQVnXeRboAi2PSUFG UrjoGCbFIp2IJHv/4D4MdjsjMTZVdJRZuflnrlM+98KjZQgNWGyS+z/8x3WoaCjClpyduNxW pv/47tueN8n9jTHWM3xoSI3h4SE4O7sgMCBYPxuekrwKwUFhcHTkPwELyTt3rUNbSdGEzyXe uhPrfmG+n0tR2jtaEBIcjqrqiwgPW4Sq6lJ4eHjCzzcA50u+wA2btuFI4QGsTM1Gb283fH38 4ODgiFWZeQCA64wsmUhJygQABAeNr3uOiY7D7598ZXy8nhYLPTOazrmqU1A6BnC5CxGRoZHR EYyNWe+aakM1Yy8DAPJ370P6si//Mm/rrjVavOtsydmJT07undUY39/+NCoaxouh+7+xF99/ LFH/NcMxvD0D0T84fkw8EoHO/n8gIGgJLp4/h5glcfCQyfTXajQadLW3oa2lGeVnL+D5+sfQ 29cFR8epPcM3rr8JgQHBcHZ2mVVeWhhu/dthvHPXOv3HF157DseeehCDbY1oPPkZACA0OXtC IZ+848coeeNP+q/d+rfDFk49UUdnK5ydnDEyMoL6hhqkJGfii9OFyMlej2PHP0N0dBwcHR3R 19eDoMBQeHv7wsNDhhWJK+HiMv7/3g2btgH4shC/1neN2IXIujg4OtjcxINtPRsiEmLrxm3z /jCjdw4/DWB8Rv2Z13aitacW/YNd+tnwy21lyN+9D/kvbkP+7n0IC1iC7z+WiC05OwEAn5zc q3/sG58/ZnSM59+6Wz/G6fKP0dZdiw+O/xlbcnai+KUInPz4M/wp///B288P6dk56Gxvg0Yz vkHTyckR/oFBCAoNRWBoML5z248XzJIUMq/eugr9x20lRch76GkUPvEAbn52HwDoi/S2kiL0 N9XCO3Ju7zgN9vej9OwZrF6/wejXVSolRmQjqKuvRPzSJBwt/BQJy5LR3HIZI6PDiFuyHKeL j+GGTdvQ3t6CpXHL4eDgiLTULDg6OmFt3g0AgPXrvqK/Z2REDAAgJHh8+YOuQCfblbY0G5mZ XO5CRDTBwZOf40q7A5ZFJ4mOclVxDv+GNs1h5L+4bcLnb879MQBMmPUGMGH2/P2jzwHAhMd+ cnIvVsZfP+1jdY//5OTe6cc4uhcOSj8c+UwLzdgoXNzcsCwpGZu3bZ8wmw6Mz6grPhtkgU5z Zrjc5fmM8aI1NDkbfksSUfbOlz/nhU88AADYf++2Kfc4+Kuds5pN12q16O05jafyP0BFaSl2 3vdTdLa3oarsInI3bMIXxwqRmJqG1vpG9C7phqebF1xcxjf9rcrMg6urGwIDv2zfqJv9Tkke X3LiZlv7A8kEisuPY9COy12IiCZQKBUYHpk/Syv2P6U2+vnvb3/a7GNPN8b3tuzB43/NhV+A C9pbWuDgYD+lQCeSYqbi2tTr0hvrzuFKXwlCw/3g5u6OmvJyrFqdi7yN4y9os/LWAgDCYqIQ Hh4FX98A+PoGAABcbaxDB1kGl7sQERmxOW8Lys93i45hE+zt7REWGSk6BpEkixavROySnXjk t1kAAKVCAY1WC+tqdEm2JDMhF6tyIkTHMKn5sdOLiKzasTOFqGupFh2DiKyUu4cHN1qSWRWV HsGBwgOiY5gUi3Qikmx8ucuQ6BhEREQ2g8tdiEiyDdkbUVnaIzrGrOn6mBua3JLREvc17KcO LJI0NhHw5YZQQ996t2xCRxbdBtLEW3ei91KZ/mNb7JduKU6OzhgdHREdw2qMjI7AxdmypxJn J12HVWtsa7kLi3QikuxcxVn0dtlhSUSC6Cizsucnh/HwH9cBAHZc/ygA4I3PHpvS8WU6k3um 6wrx2dxXd5Sc6jAAACAASURBVKjRTD3ZSTq7BfhG8eHfjrf4vPnZfYha/eULw/6m2gnFe95D T+u7vGz89V78c/t4tyHDa771bpn+85PpWjRO51vvls06s1arnfW11kzm5gmVQik6htVQKuXw dvWz6JinK45h0D4QG3M2WnRcc1p4f4sRkcn19fdBqVIIGdvJ0RkjI8PX9NiKhiLkv7gNLZ01 uP8b40X3lpyd+t7nLzxahoTobHh7Buq/lhCdre+ZDowX6G989hhu/pmrvvCe7r66x+r6pV8L 9ZAKbs7u1/z4hcLN2R1qtUp0DKtw7h/jHYW+9W4ZQpOzUbx3ah9/XQvGb71bhtyfPakv0L/1 bhm+9W4Z8h4av8fNz+5Db23ZhPu5+Y3//5F4607cXayedR91rUaDkeFhuLl4SHuCVsDF2RWj I6M286JDqo72NkQGx1h0zLHRMYyOjlp0THPjTDoRSZaXkYfqi/1Cxrazs4Od1m5Oj3n+rbsn LEvZuvYe/Qz41fqe6xj2TN+97Uns+clhPP/W3ROueXHfg3hx34NTHts7MPHgp09O7oWX7NsA cq+aXamSw8PNaxbPcmGTuXpCpVpYM5vrfvE8yt7ZO6W/efKO8f78k2fGy97ZO6E/uuE1suAI yDua9b+Pyhn/f2L/vdv0Hxu7n29MAlK+cc+s8qqGVLCzs4e76/wv0gFgUeBitLZfRnhotOgo Qg0PD2FENQxPd8v+PZWxfA0yc3iYERHRBJV1Vei5AsjcPYWM7+biDvWQCq4us+uvfPdtz+Pu 2yauv93zk8OScxi772x9b8ueWV0nVw7C28PnmsZYSLxlvhiUXxEdw+LuLjZ+BoBuJtyaDAxe gczVE/b2tvGm/sqlOXjr6MsICYqAg8PCLa9KLp5GVvxai497rroIKicudyEimqCrtxODCjEz 6QAQG7wUzW0Nwsa3pLbWJsQEx4mOYfViQpeiublRdIwF63LtWVyqeh7/fOEveOsff8fhA59A qZBPuKaxpRZLwpYJSmh6zo7OWJ2wASe/OAKtRiM6jhC19ZXwsPNCVEisxce2xeUuLNKJSLKs lCwsCp3dOlRzWBy+DG2tzcLGt5Txo9a7ERbIw46uJiI4GsNqNfr6eciWCIsWr4SPbyoOfvwh Dh/4BI6OjnBz+3IvhVarRWtLM2LClgpMaXrRoUuQHJGOY0UHoR5aOHsitBoNLlachbpXhXWp W4RkSIvPwtpMy8/gm9PCfT+GiEymub0F/fIxeMt8hYwf6BuCIYUaA/Ir8JLNvBTk8qVOvPLH Ty2UbPZUiqu3b6trqERsyFLY2/PcxqtxdHBEUkw6Si6ewXVrpLXWtHbnTlxCd8eARcfs7qyB Ut6LqNgso19vqutEQNAaPPSTW/DXp5+El48PtAC+OHYUWblrUdtQCWc4Y5GAGVdzi49aAT/P ABw9/SncvTwQGRkLH28/ONjY/7dajQYKlQLNrQ1ob21GSvQqLF+eIixPef0FaGWtNlWo22m5 FZmIJHpt/xtQ9LggOS5DWIbG9jqcuFQwY0HW16tGU92gBVPNzbJkfzg7G3+Dc3R0BAc+ew93 bvoBu7vMkkIlx96Pfo91192IQP9g0XHM4uzJDvR0W/4gMa1Wi9f+9jPIZH5YkXYDYpeumnKN X4Az0nNCMDw0BLVKBS8fHwwPD6OxvhbHvziIvOXXY02G7awfNqajtxWVTRfR1d+OMY2t9VG3 g7e7L5aEJiAmfAkc7MXO+xaVHkF8YgA259nMi/JQFulEJFlVXQ3qKxXw8w4QmuPNwy8jeukS RNhgd4UzJScQ6BSMrOXXiY4yrxSXH0dxwwncuPFWODu7iI5jU8rOn8N/Png/liUlIz1nNW66 7Y5ZbQI9fuogNAoNEkPTEBsTh3MXvsDq7PUWSEy2TKGSIz07DF4ym+l+Fco16UQkWV//FSiH xPRJN3Rzzg6UlZyzuXXIl+rLMTowilUJtvM2rqWkJ6xGpE8MCos+w5hmTHQcm5KYmoacdevx lVtvw9LlibMq0Msqz6Kvqwc3596BxOWpcHPzQPaqtSg6dQQKhRz1DTUWSE62qK6lCmU1sz9I az5gkU5EktU316G3v0t0DLi6uOHGVV/DiZMF6OvvER3HJC63XEJtdTW2rNoOO7u59YOn8T76 N6zaBqcRZ3xa8B5U6oXVO93cfvCzh7Bo8WLEJ67AqcKj016n1WjwxbmjqK4sxy2535xwgJG9 vQOys66Dh4cMANDYVIfyigsYG7OtTh1kXgqVHANyy+7NMDcudyEiyUqrytBYo0Kgb4joKADG 14F+eOpNLF+RgkURS0THuSYajQYl5cUY6LqCrWt22MSpjCKNaUbx2Rf7UdtZiZWp2VgUsYQv ekxMq9Gg9NxZJKWthJ3BrHrvlW4UnzsODAG35H1z1hvMPz+0HxvWfRVV1ReRsCzZXLHJRvTL +7AyKwz+Pv6io5gK16QTkXRnLp5HS60aIQERoqPoKVRyHDz7IfqHe5GavAoBfvNj46BWq8Xl 5ksoL7+A+LBErF6xgd1cTESr1eJi7VmcLCuAvasDEpalIDw4Ci4urqKj2QylQo4htRp29g5Q Dstxqb4CbU1NSF2chdXJ6+HsNLd9ARrNGLq6O9DR0YrQkAjIPL3g5sqN0zRVef0FJKYEITMp U3QUU2GRTkTSWUN3l+m097TgyIUDGNKoEBYRheDAMLi7yeDuZh0z07o2ZnLFAFo7mtDe0oww vyjkJm2y+LHaC8Xo2CguVH+B8sYL6Oxvg69vADw8ZHB1dYW9A18QXTMtMDSkRk9nJ64M9MHD 2QMJManITFgDLxOdknuk8ABWpuWgra0JS+MSTXJPsg3s7kJEZIQ1zqRPNqgcQF1LFZq66zGo GsDQsNoqljtotVp4uMng6eqNmJA4xITFzXm2ka6dXDmIpo56DCr7oRxSQDPGzaVSuLvK4Obq jiCfULQ2NSItNXtWG0rnYnR0FCq1EufPn0JW1nUYGlLD03Y6etA16unvQlpmKEICrWPZpQmw SCci6axtTToRWYdPP9+HGzZtM+sYJ08dRmhIBJycnBEeFmXWsch6VTeWYUVqMFITUkVHMRW2 YCQi6S5WX0Rbd7PoGERkZW7YtA1fFBeir898bVFzstYhMiIaQYGhOFTwIbRaLbq7O8w2Hlmn 3v5udNjYnztn0olIsvmw3IWIxFEo5LhYdhZZq8zf639oSI1LtRUYGlIjbslyeHp6m31MEq+j txWpGaGIDI0UHcVUOJNORNLJ3D3g7MQOGURknIeHDFmr1qLw2GdmH8vFxRWJy9OQmrIKnp7e OFTwIdRqFfqu2MbZCWScLfZJZ5FORJKdLTuL5s4G0TGIzK5Z3oCsNyMn/DrRXiA61ryRvjIH tXVVGB4ZNvtYutalG9Z/FeohFVQqJQoOfwSNRmP2scnyOnvb0NxuW8suudyFiCQrOncarQ3D iAhaJDoKkUW8UbMXT5/PBwAkB2TgxfXvig1kBs3yBvz69P2I9YrHo+mPm+y+7e3N8PUNwPDI sMW7smg0YwDscKTwAJISV8LF1c2sGbRaLTp6WtAz2I1+RR9GxkbMNpYlOdjZw9PNC94yP4QF RsHZ0Vl0JLR2NyElPQQxETGio5gKu7sQkXR1jQ2orRic9UmCc9Usb8DXPs6b8Lln8l7B6pD1 Ez732JlH8F7dq9N+3dh9f336fgCYdZF1LY8h22L4M7Ap4iY8fT4fD6Tmo26gRv/zp6Mr4A1/ Ng2/9r2Ee3F/4XemjHHq9qZpHxPrFW/08wBQ0l08p+fyQGq+/sXGbJ26vWlO1xtzpb8XV670 IjxsEZycnCTf71p0drbBw8MTJ04ewvWbtkKjGTPZwWGjY6M4f+kUqlvK4B8YCB8ff7i4usLR wdEk9xdNM6aBelgFhUKOzo42+Lj6YfXy9fD0ELf+v7G9DskrQ7A0ZqmwDCYWahs/LUQk1KkL p8x6mFGELBqnbm+aMHv5PxXPTinCH01/HLFecbMuOiJk0XMutOf6GFPORpprZpPm5h9Vf9EX w7r/Pn0+H7fE3jnl2liv+Gnv06FoNVqgA8Dugu1GHzvd/WK94vHt+B/qX8zqiu9bYu/EybYC dKhajT7u8+YPkByQgZLuYjyQmo8dcTuxu2A7AOBXmc+Y7efNx9sPPt5+OFTwITas/6pJ7z1b QUGhAIDrN23F4GA/ai6Vw9vLF5GRMXB2vvazCvrlffik+B1ELFqEdetutIrzGMxpWVwSevo6 8cHpfyFzSR6WRCwTkqO1qwmezSpbKtLBIp2IJAsPjkDnsHkPgWmWN+gLCt3s5Rs1ewHAaFE+ XfEDYMI9dCa/CDB0S+ydeDT98Slf180oTjfjaThGSXfxhGt0hdFkb99YiAhZNHYXbJ/w9TCP SLQqmoze69TtTUbfbZjNODQ3J9oL8F7dq/qfCeDLpS+xXnETZpkfO/MI6gaq0CxvwKPpj08o dB878wiOtByAr0sAIj2nf+E3+TF1A1X4VeYzRj/fJG/Qz7TrXBe+Gc3yBnSoWqddlrO7YDuS AzKwI27njM9d9zwNn7tUG9Z/FYePfoK1uTeY/NCjufD09MbKtBy0tzfDyckZn3z6Ljauvwn2 9nZwmMPst0Ilx4dfvIlVWWvh4S4zY2Lr4u8bhLV5m1F0+jAACCnUo0JjsTTGts7q4HIXIpKs ua0V1Rf7IXP3NNsYxgph4Mu3+XXFR9ab4+23fpb6n3jq/H8AmDirqKMrMnSzhrrH64rjybOK hsXN5M8Zy6YrZGaa/dY9bnLxNN39vh3/Q6P3MizQdcX3ifYC3F/4nQnLI2x17bSlTH4h9Eze K4iSxRh9caSj+3Mzds0tsXdO+85PRtAaFHcen/Xnb4m9E3UDVUZfkE33Qs3YdYYvLG+JvXPa 5TumVltbCUcnJyyKWmzye1+rltZGjIwMo7evGytTs696vVarxTvH/okVqWnwkvlYIKH10Wg0 OHrsAG7K3AFPd8vuN7DFNemcSSciyQqLC8263GWm2cuS7mJ9oQ5MLEiMzSoeaTlw1fFmM6to yNgsqW4GdTLD2UjdWL/KfEb/9WZ5A+oGqvTPdboXJ4b3yghao/+cbnY8ShYz5ftiOA7NnW7Z 1WSzWaM90zVz+VmzBMM8llpWtXjxMoyNjeJI4QFcl7fZImNeje70Um9vXwyPDOPUqSNIS82G u7uHftbfcB37pZYKePl7L9gCHQDs7e2RkpKJY6Wf48asWy06dmNbHdzqB2ypSOdMOhFJ9/nx AvS0AjFhcSa/97XMXs5EV8T7ugSgb2j6UxCNzSpON1NpjOELCt3svs50Y+s2u05e6jI5++TP vbj+Xf3M+WzMZlMtkQjDI8OoqLiAlORM0VGMqqgsQWhoBMrLz2N1zgY8/Yd87LhjJ8JDI/FO 4T+QmZ0LR0cxG2GtSeHxz3BL1jfh7HTta/vnyhY3jrJIJyLJLLHchYgWht7ebmihhafMS9IG TnNSqZWQDw7g5Vf+iOMnD+G+n/wSnfbtWJt7g+hoVqHq0kVEusVgccT0G6dNjSeOEhEZUVhc iLqWKtExiMgG+PkFQKmUY3h4GEqlXHQco1xd3HCiqAANjbWQyTzxp7/+DscPHBQdy2p4efrg isKyJ7zWt9Sg/FK5Rcc0N65JJyLJfL19oVXadpsxIrKcyIgYKJVyVFSWIH3latFxprCzs8O2 m7+BbTd/A8D4LO7ZppPQajSwE9ilxlq4urqiu6PLomMG+YUiIiTYomOaG3+SiEiytISVCA+M Eh2DiGyIu7sM6StXo+DwR6KjXJVWq4WDoyMLdIE83GTwsvAJtubGmXQikuxQ0UGzdnchsgXG NgTrWn3S9Nav+wqOFn6KzMxcuLm6i45DVqq+pQbOPn22tCadM+lEJJ2Hu4dFd/ETzTePnXlE 33//1O1NE9pj0tWtzbsBSqUCpRfPiI5CVsrPOwDBAba13IUz6UQkWW56HsrPT9/O0FwMZyZ1 rQgN2x3O9VRNw3aPpjxV8VroDkECwAOIbEikZyyAL/9MT7QXTGnRCYz3VZ+uFaehZ/JemdB6 0/AQL0O2cPKsv18gfH388cXpQqzKvLYWrGS7/L2DEBJgWyeOskgnIskOFH4iZLnLrzKfwT+q /oJYrzjUDdQg681IPJCaj8+bPwCAORcfEbJovH1job44nq2ZThW91sdEyKY/Kp7mn0fTH8d7 da/Oupf97oLteHH9u0ZPpdUdYvVAaj5Wh6zX9/C/PmKr0QJdR3eC6Hw+edbe3h6Jy9NQV1+N 6EVL9IcKEdU0lsPesxMhgbZTqLNIJyLJnByd4OAg5q+TuoEq1A182f5RV6ADUw9C0plplvL3 ef/Qfzz5tM/pjmTXKekunnC97pTJyWOFeUSiVdE07WN0Rdjk+0z3fB5IzTd6tLzodwPoS7sL tutPfY2QRaNZ3oBdh7ajb6j7qkXz5NNid8TtxOfNH+Dp8/kTDttaHboenzWPv1A2dr/Hzjxi EyfPenjIoNVqMTIyDDs7O6vtpU6W5SXzgZ+Pn+gYJsXDjIhIMoVSjZIz7XCwt3yhbmypADCx oNa9pa87lVNXFBmbpZxcCBsWupOLdt3Xvx3/w2lnxa/lMTq7C7YDGC+4DHMZez4A9Gued8Tt nPBYEs/YzwEA3L7k3/DmpZenfH66F4S602KnW5o1+QXeTOb7ybMtrY3QarUIC40UPqPe3tOC kvZiJC1PF5rDWvT1d6P7chfWplxvsTH75X1YmRUGfx9/i41pZqGcSSciyd4/uE9YdxfDtbbT zSjrlr1EyWKmbNgzNrOYHJCBWK/xk/J0hdWj6Y/rf+k8duYR1A1UoUneMOHxukIpI2gNhjVD +iJqukLN8DGzmf2e7vkkB2SwU4iVmvyzY+jBtP+a8/0iZNH6d1gM7YjbuWB+BsLDoqDRjOH4 iYPIy7VcMUjWqaK+BBr3VmzO2yw6islwJp2IJHtt/xvCivTJs+G6mfUHUvMR6RlrdA3w7/P+ gZ8WfnvK5w033elmu40tLzGkK6onz+jr8ky3rMbYRr6rPWbyJkEdw1nX5IAMbIq4acIyCC55 IVt34LP3sPn6W4SNz5n0iUTMpJdeOoPlyUHIScux2JhmFsoinYgkGx4ew/nTbaJjENECVlJa jLDQSAQIaMPHIn0iEUW6QiVHenaYLR1oFMpt0UQk2dsH3kJJzcyt4oiIzCk5KQMymReKz0y/ uZtsV+mlMzh57qToGCbFIp2IiIhsgqurG5KTMlBSykmDhcbF2RVurm6iY5gUi3Qikmzrxm1I XJwqOgYREZydXRAYEIK+vm5wRe/CsTwmBZlJmaJjmBSLdCKS7OMjH6Gy4aLoGEREAIDQ0Ah0 drVDPaTCyMiI6DhkAeeqTuHo6aOiY5gUi3QikmxkdARjY6OiYxAR6cUvXQG1SonqGk4gLAQO jg5wdLStzuIs0olIMi53ISJr5OsbgMTlaThU8KHoKGRmaUuzsTZzregYJsUinYgkO3jyc9Q0 VoiOQURk1Ib1X8XRwk/5jp8NKy4/jkMnD4mOYVIs0olIMoVSgeGRIdExiIimtTbvBjQ1N6C2 tlJ0FKJZsa3FO0QkxOa8LSg/3y06BhHRjKIiYzE6NooLJaeRkmxbnUAWuuyk67BqTYToGCbF mXQikuyLklNo7KgTHYOIaEb29vZwdnJGVGQMmlsui45DJlRUegQHCg+IjmFSLNKJSLK+/j4o VQrRMYiIZsXXNwBKpRwqtRIazZjoOERGsUgnIsk2ZG9EXFSC6BhERLO2NC4RjY216O7uFB2F TCA76TpsztssOoZJsUgnIslKq0vR3tMqOgYR0ZzEL02Ct7cvjp84KDoKSXS64hgOnrStP0cW 6UQkWVdvJwYV/aJjEBHNmYuLK9as3she6vPc2OgYRkdtq8Umi3QikiwvIw+x4fGiYxARXbMN 67+KE0UFkMsHRUeha5CxfA025GwQHcOkWKQTkWSVdVXoutIuOgYRkSTZq67D2NgoKqtK5/Q4 RwdHjI1yA6rO2NgYHO0t2+W79NIZnDx30qJjmhuLdCKSjMtdiMgW2Nvbw8vLB1GRMXM69Mjd 1QNqtcqMyeYXpVIBmZuXRcccGlZDZWN/BizSiUiyrJQsLApdLDoGEZFkdnZ2cHeXwcnZGX19 szukzc3FA0NqtZmTzR89vZ0I9Q+36Jhp8VlYm7nWomOaG4t0IpKsub0F/fI+0TGIiEwmKjIW 9Q01GB4ZhlarnfFaOzs7BMlC0NPXZaF01kuj0aC/9woCfIItOm51YxnOV5y36JjmxiKdiCRr 6WjGlcFe0TGIiExqZVoOOjvbUFt39aUvqxLWoqzsrAVSWbfqujIkL8qAnZ2dRcdVqOQYkA9Y dExzY5FORJKtTFyJiKBo0TGIiEwuInwRYmPi8enn+2a8TubuiaUhK1BWcc5CyaxPd28H+jv6 sDwmxeJjJy1JR05ajsXHNScW6UQkWV//FSiHFKJjEBGZhb29PW7YtA0HPntvxqUvaXFZsFc7 oLSs+KpLZGxNW0cTKi6W4MZVt1p8Fh0A6lqqUFZTZvFxzYlFOhFJVt9ch95+rsUkItu2+fpb UHOpHJ2dbdNes2HlVxDqHolDhz9CU2s9NBqNBRNaXu+Vbhw7eRDdTV24NffbcHF2FZLDFpe7 2GkX2ks9IjK50qoyNNaoEOgbIjoKEZFZjY6OQqMZQ21dFRKWJU973fDIEEpqi3G58xI0dloM jw1ZMKX52ds5wBGOCPQOQXJMBvy8A4Tm6Zf3YWVWGPx9/IXmMKFQy3aaJyKbNDwygrEx2zqO mYjIGEdHR2g09vD19Ud3dwcCAox3MXF2ckHGsjXIWLbGwgkXppauRvg0qW2pSOdyFyKSrrq+ Cp19PHGUiBYGe3t7hASHo7WtCSMjI6LjEIAB+RX0XrGtLmMs0olIsqUx8QjiUhciWmCSkzJQ Vn4Ogza2Fno+iotajpRllu8qY04s0olIMmcnJzg4cPUcES08qSmroBkbw8lTh0VHWdB6+jvR 3m1b7+iySCciyS5WX0Rbd7PoGEREQnh7+yInax0OFXwoOsqC1dvfjY7uDtExTIpFOhFJFhMR Cz/vQNExiIiE2rD+qzh+4iDXqQsQEx6H5UuWi45hUizSiUgyX28fuLt4iI5BRCRcTvY69PV1 o6HhkugoC4ot9klnkU5Ekp0tO4vmzgbRMYiIhLO3d4CPrz8CA0PQ3HJZdJwFo7O3Dc3ttrXs kkU6EUkWHhwBH08/0TGIiKyCs5Mz3N09oFTKoVTKAQADA1cEp7JtUaGxWBqzVHQMk2KRTkSS RYSEw1vmKzoGEZHVsLOzw9K4RJRePAuNZgxPPvNL0ZFs2ujoiM3tBWCRTkSSnbpwCpfbakXH ICKyOh4eMjz+xKMoKz+PfftfEx3HZrV2NaG+uV50DJNiY2Mikiw8OAKdw2OiYxARWZ0ViStx 5UoP2jta8OcX9iA5JQN+fgGiY0lib+8AV2c3ODk6iY6iFxYYiZgI2zpUz06r1WpFhyCi+a25 rRXVF/shc/cUHYWIyCoMKvpxtqYIjd31cHYZX6NedvY8FAMDWL1pg+h4kmi0WqiVCiiVSvjJ ApASk4mI4GihmVq7m5CSHoKYiBihOUwolEU6EUn22v43oOhxQXJchugoRERCabVanLx4GK2D jYiPXwF/3yDY2dmJjmU2SpUc1TVlGB4cxubMW+Dq4iYkR1HpEcQnBmBz3mYh45tBKNekE5Fk gX5B8PTwFh2DiEgorVaLT754D2oXFdbkbESAX7BNF+gA4O4mQ2pyFmKWLcW7x1+FQiUXkiPI LxQRIRFCxjYXFulEJFnS0iSE+IeJjkFEJNSJi4cgC5QhIS5ZdBSLC/QPxsqMbHz4xZvQaCy/ R8nDTQYvmZfFxzUnFulEJNmhooOoaawQHYPIZg00N+Cl3Ej9r6aiAtGRaJIr8l60DjZjSUyC 6CjCeHn6ICwqEhdqT1t87PqWGpRfKrf4uObE7i5EJJmvty+0Stt+S3c+eSk3csrngpMycPOf 37WKLACw61iThZMQmdfpymNYsTxNdAzhYhfF4/CRT5C6JMuiS33Gl7sEW2w8S2CRTkSSpSWs ROVoj+gYQgw0N+BfX8+b9fV3vF4Ir4ho8wXCxAJ4uiLZUgyz7P/RdnSUFgtMQ2QeWq0W3fJO rPBeKTqKcHZ2dvAPCEB7TwtCAyy3Rtxb5gt/H3+LjWcJLNKJSLJDRQcXZHcXwwJ42dY7kfvw 4/rfl725Fyf/kC8gFRFZmkIlh5uHu+gYVsPXLwCdfW0WLdJrGsth79mJkEDb6ZXOIp2IJPNw 98DIgIPoGBZlWKAbmx1PvH0nEm/fydljMgmviGguEbJiqiGFsNaD1sjdzQP9vVcsOqafdwCC A2xruQs3jhKRZLnpeYgNXyo6hsUc2/OI/uPNT74y4/IVEevAiciyxjRjsHdgSaVjb2+PMQt3 eAn2C0NkqNjlfabGnygikuxA4SeobCgVHcNiKt9/FcD4ZszI7PVXvX7Z1jvNHYmIaEGrqC9B sY29a8kinYgkc3J0goMDV89NxzcmTnQEIiKb5iXzgZ+Pn+gYJsV/VYlIshuv+wpKzrSLjmG1 dOvTjWkqKsCBB78z5fOTN6LOdC0wvuxmNrP6wMwdX+ZyH52ZNsley/10rtY5J+e+fKPf12N7 HtG/22GYw9j3TpfP2HOYbdvK2XT4mev34Wp7GWZ7P2PPS/ezNdMYluhCRGRK4YFRiI20rUP1 7LRarVZ0CCKa317b/8aC6u5iWARKKUInMyz2jBXpkxkWYNPl0BXkwUnjfza6ouxq3WhmU6RN fszkjY2TN9ce+c39+vFn2gQ5ueidXIxPfrEyXbE+U4FqrJDX5fSKiJ6Qfbqsk+9hLMe1fF+n M5s/7+lM90Ji8gsRw+c0m59BGtfe04KS9mIkLU8XHcUq9PV3o/tyF9amXG+xMYtKjyA+MQCb 8zZbrcSxpAAAGVxJREFUbEwzC+VyFyKiOTIsXA48+B0MNDeICzNLHaXF+gL5jtcLpxRfibfv xK5jTfpi/l9fz5vxVMtjex6ZUDAaK2R3HWvCHa8X6u83my43TUUF+mIyOCkDu441TSl8I7PX Y9exJuTcNz7+yT/kT9jMO52c+/L1z3vy81+29U7sOtakL6B1uYHx4tiY3Icfx65jTfpfxl4o 6L6vOnPpqW9um598Zco7BbkPP47NT74CYHzvxXTPncjaeLjJ4CXzEh3DpFikE5FkX9t824KZ RdeZXNDOl6ParzaTa1i0TfcCpOzNvbN+J8ErInpCwTuTgeYG/Qz5bJaaJN6+U1+oX62gXLb1 zilFtOGG3uRv/nBKbp26Qx/MJv6MdDkBWMXPyR2vF0775xaZvV7/s81e/zRfxIbHIzEuUXQM k2KRTkSSvX3gLZTU2Nau+tm4+c/vYtexJv3M44EHv4OXciMn/LKmmcic+/JntdRC93wAoOR/ /zLhawPNDfrCbdnWO2e15MIrInpCkTqdI7+5X//xbFtXJt6+c0JBOd27GovWin0L3CsyVv/x QFOdwCTjf25X+znwjYnXfzwf3ikiKr10BifPnRQdw6RYpBMRSaRbfmH4S1fonvxDvr5gFy0y Z+PsrjOYSZ28brvp5EH9x3MpfK829kBzw4T18nOR+t17jeYjooXDxdkVbq62daAUu7sQkWRb N25jd5dJdIU78OUGypdyI4V1zQhOypjTuL4x8fqieaC5Qf/Yvvoa/TVz2bjoFRGN4KSMadel X2vxDwDeETH6jw3zWcpMXXeIyDKWx6QgIylcdAyTYpFORJJ9fOQjDHY7IzE2VXQUq3TH64X6 DYMl//uXedExY7re7n31VRZOcnWGLz4smW9y55bpusxYw7soRLbuXNUpKB1tqrsLl7sQkXQj oyMYGxsVHcNq6WaRganLR6zVdDPShmuVrYXhmmlL5TPsbqPrDDNdL3zD5U9EZB4Ojg5wdLSt uWcW6UQk2ea8LVgWnSQ6hkUc2/PINa0xF70Rr6O0eE7jGs5IG85UG86wz6VLieGac2MM16xf Pnpg1vcFgP7meqP5zKWpqIC9xImsTNrSbKzNXCs6hkmxSCciyY6dKURdS7XoGBZhWLyaoui1 pNluqmwqKph2E+e1FtNXG1vKuw3n//6s0XzmYtidRXTXGCIaV1x+HIdOHhIdw6RYpBORZAql AsMjQ6JjWJwpil5D5i7eZ2pRaMhwE+TkWWLDdoqV7786q9l0w7aNM7nu35/Rf7z/R9uvej0w vi5c972dbYtJIqL5gEU6EUm2IXsj4qISRMewuJN/yL9qH3TDA3qAqUXvZLoivvL9V2csqJuK Cq7poJl/fT1vxvsaFsfTHUKUePtOfc4DD35nxkJ9uuPojfGKiNav3e4oLb5qoW64cdPYYUXm YjhbbziLPx12fyEyv+yk62xq0yjAIp2ITOBcxVm0dDWKjiGErg+6sUL1pdzIKUfcX41hEW+s uN3/o+14KTdyzkVfcFLGhBNSj+15ZMLXy97ci5dyI/Wz0ruONc04K5378OP6GXXdIU7Gsuqe wx2vF+rHn0lk9nr9i4OO0mKjB0I1FRXgpdxIfYGec1++RdeFT34x8VJupNEXPrq9CyzQicyv qPQIDhTObT+LtbPTarVa0SGIaH57bf8bUPS4IDnu6kXYfHdszyP6NdO7jjVN+L0x17qxcP+P tk+70VLX6m9yC0DdeMbyBCdl6E/xnGnT67X0cZ/pe2DYlnC65zTdmFebhZ+u5eFMeQz/PIxd t/nJV/T93419nya/0Lran78u43Sz6ZN/Pkwx6274/Zzp5wiY+Hyvdv10328C2ntaUNJejKTl 6aKjWIW+/m50X+7C2pTrLTZmUekRxCfaVAvGUBbpRCRZR1c3Kkt74ObiIToKEZHFsUifSESR Pjo2iszV4XBydLLYmGYWyuUuRCRZaXUp2ntaRccgIqIF6lx1EY6ePio6hknZVtd3IhKiq7cT CoWL6BhERLRAjY2OYXTUtg7VY5FORJLlZeSh+mK/6BhERLRApcVnISMzXHQMk+JyFyKSrK6p Hr0DXaJjEBHRAlVefwGnS0+LjmFSLNKJSLKWjmZcGewVHYOIiBaooWE1VGqV6BgmxeUuRCRZ VkoWaisGRccgIqIFistdiIiM6OzpwqByQHQMIiIh7OzsAHa01tNqAXs7O4uOWd1YhvMV5y06 prmxSCciyeqb69DbzzXpRLQwubm4Q61Wi45hNVRqJdxdLXtuhkIlx4DctiaLuNyFiCRbmbgS 9ZUK0TGIiITwcJNBpVKKjmE1BgavIEYWZ9Exk5akIz0tzKJjmhtn0olIsr7+K1AOsUgnooXJ wd4RznYuGB4eEh3FKnS2tyEiKNqiY15ur0VVfZVFxzQ3FulEJBmXuxDRQpcWm4XK6hLRMYTr 7u1AoEcwnBydLDrugPwKeq/YVpcxFulEJNmKpSsQGhAhOgYRkTDRYUug6lehu7dDdBRhRkZH UHKhGDmJ6yw+dkJMMjKSMiw+rjmxSCciyYZHRjA2ZlvHMRMRzdWWzO24eOEsevoW3juLw8ND OFF0CHnLr4e7q8zi47d0NaKuqc7i45oTi3Qikqy6vgqdfe2iYxARCeXq4oZbcu9EZWkJKi+V QqPRiI5kEe2dzSgs/BRrE25AVEiskAy2uNzFTqtlY08ikubMxfNoqVUjhEteiIig1WpRebkU pQ1n4CJzhae3N9xc3ETHMqmRkWEo5HL0X+lDhE80Vi3Pg7OTi7A8Pf1dSMsMRUhgiLAMJhbK FoxEJJmzkxMcHLjchYgIGD/cKCE6GQnRyeiX96GnvwtKtVx0LJNycnSGd4QvgpPDxg9zEqyn vxPt3Xa2VKSzTzoRSXex+iIUPS4I9LWdvxyJiEzBW+YLb5mv6Bg2r7e/Gx3dolOYFot0IpIs JiIWraPDomMQEdECFRMeh+VLQkXHMCluHCUiyXy9feDuYtkjoImIiHQUKjkG5AOiY5gUi3Qi kuxs2Vk0dzaIjkFERAtUZ28bmtubRccwKS53ISLJwoMj0Dk8JjoGEREtUFGhsVgaY1v7olik E5FkESHhGOobFB2DiMgqZb0ZOeVzt8TeiUfTHxeQxjaNjo5gZGREdAyT4nIXIpLs1IVTuNxW KzoGEZHV0RXoz+S9glO3N+GB1HwAQN1AlUXGb5Y3YHfBdjx25hGLjCdKa1cT/n97dxoU1b3m cfwHNGs3e7PJohARjRGJ4iWTlLlJza26ZdV9YcrxpibWZCplpW7NvJiqZN6YNxNn3piqqRtr 3s3cTCY3+zUJ7gY3REFRFGRREUShlX3fGpqlgXlh0VciJCY0nCN8P1VWwWk85/lL9+Hnw9Pn NDQ1GF2GV9FJBzBvMVGx8h0xugoAMJfitgJJ0rtZe/Vi/KuSpNfTd+v19N1qcjpm7bBn2rNV 1VX6i4+Zu61IO/K2Pra9qqtUh+u/9HxesrNRxW0FeqfozSeuIXdbkT6v/e8Z+5n++o9ePfSL a/aGFTHJSk1aWuMudNIBzNvatAzFRCytkyMALJQmp8MTpHO3FalkZ6P2b/1MktQ46PB83XTX fXvaLmXHvuTZPt2Vz91W5NmWac9Wpj1bSbZVKtnZ6Pk8d1uRMu3Z2p62SyU7Gz1/5gro07an 7fLsd/rvJNlWzfq1aWEZv+SfwassFn/5+/sbXYZX0UkHMG9FpUUa6g5UZnq20aUAgGlMd88/ rNir5NA0z+ePmg6+KbZUZdqz1TjoUKY9e0bw/XXib/Vl7f88tt+5QvOBuo/n7MYfqPtYH1bs VXbsS8q0Pzxnz9YF31e2R5n2bL2/Zf+M7e9t/mDGLP2+sj2qH6hVk9MxZz2L4UFrvYIbBpSa lGpYDd7mMzU1NWV0EQCebicLT6un1Uerk9YZXQoAmM5sYy1ziQy0q3f08VtnzrVdethZv9B8 6rExFGn20ZXp8ZTpwP4k9m/9TCm21FlHaczwJtj65jva8Hyc1qevN7QOL0ogpAOYt/bOLtXc 6FYwNzQCgAXR5HTo36+9o7SwDMMDsRm197QoKztByQlP/h8ik0tgJh3AvJ27kq+6B7eNLgMA lqwdeVs9b/78OZ355aKhuU7Vd6uNLsOrmEkHMG+R4ZGaGvYxugwAWLJKdjYaXYKpRYXbFWeP M7oMryKkA5i3X2XmqHpy9llJAAAWWnR4rOLtS+sqY4y7AJi3U0UnVeO4YXQZAIBlqu5BtSpr Ko0uw6sI6QDmzRpiVYB/oNFlAACWqTBbhKIioowuw6u4uguAeRsaHlFVWZv8fJmgAwAsvn5n rzblrFB0RLTRpXgLV3cBMH9H84/o1r0Ko8sAAPzAgbqPlfNtsufPUnW7oUqlN2a/gdPTipAO YN78Lf7y86OLDmB5a3I6DAvDTU6H3i54TfvK9szY/nr6bpXsbFSmPdtzh9GFruHtgtcW9Diz YdwFAGbBuAsA/PXOornbipRkW+XZ/nbBazPu+vlu1l5JmvNun/+a9R/6Y8W/PdExt6ftUlpY +pz7mr5043Rw/ujVQ57HitsK9E7Rm7Pu84d3L52+S+m+sj1zPibJcxfTxb4L6ZDLqc0vrFCY LWzRjrnAGHcBMH+MuwBY7orbCjwfPxrQ95XtmRHQJamw5YzONh1Xpj1bJTsbZ1wD/ffpb/1k QH83a6+nO14/UKvX03crd1uRMu3Z2p62y7PPH7u2+lwBXdJjIVyS0sIy5tzXo4+9lPC3nn00 OR0/ug5vunG3TJfLLy/a8RYDbS8AAIB5ahysl6QZIyVNTofqB2o9XeXZutDTprvXydZUzz4e 7XpLf+2Gv56++yfr+amOdopt7uP80L6yPaofqFWT06H3Nn8wY3+PPvbof04WmzXYtpS66JII 6QC8YMdv/04V11qNLgMADJMcmiZJM7rm06H1cP2XM8J5acclz8c/nF9PCl2l3yT9Th9W7J1z tv3tgtf0m6TfeY61r2yP3tv8gaq6SlXVVeo51nSn/dH9TH9csrPxJ4/zqO1pu2atd/oxIwO6 JKUnP6usdUmG1uBtzKQDmLcTBd+r5f6oNqZvMboUADDMdKf7/S37f3Zone6y79/6mV6Mf3UB qlsc02M0iz2TfrHitDZlp+mVnFcW7ZgLLIFOOoB58/Pz1cioy+gyAMBQ72/Zrx15W7Ujb+uP zoNLD0dhduRtnbEt0579VAf0JqfDM+e+mAFdkuTrI2uIdXGPucDopAOYN/eEWxWlLZp08150 AMDi8/Uf16bslfL1XTI/h7i6C4D5a+1oVV5xrtFlAACWqa9P/a96+nuMLsOrCOkA5s0eaVdn X7MmJt1GlwIAWGZGx0YUGOivqHBuZgQAj2lsaldzw+hS+lUjAOApMDLqUnbOSoVYA4wuxZsY dwHgHfeaa1RcddboMgAAy0xh5UlV1V03ugyvI6QD8Iq1aRlq7XOIX84BABbL5OSk5DeizIxM o0vxOsZdAHhNT49TldebZA22GV0KAGAZ6Oht0csvr1dY2NK6/KIYdwHgTR19TTpV8g3ddADA gnNPuHW27KAGXX1Gl7IgCOkAvCYjNUPxK6LU51xal8ECAJiPa9Spl3NeUGJcotGlLAjGXQB4 3aETZ2UPWaXAgCCjSwEALEG9g91qG6zVP+78vdGlLBTGXQB436RlQAXlxxl7AQB43dTUlM6X H1Nykt3oUhYUnXQAXueecOt61Q2N9IUoKGDJvZkHAGCgXmen1qyL0qrkFPn4+BhdzkKhkw7A +yx+Fm3JylLhrUO67ag0uhwAwBJRertIFQ35WpmUvJQDuiTeOApggfj4+OgPb+zWhKVXk1Nu o8sBADzFpqamNOp2KTElXP/8D39YFne3ZtwFwIL701efaKjfV3/z3Cvy9fUzuhwAwFNkzD2m C2UnFJtg09t//5bR5SwWxl0ALLw3tu9UdJyfpnxHuTwjAOCJdfW1y2rz0/oNK/XmjjeMLmdR 0UkHsGhaO1r1n3/6L61J2KRNa180uhwAgIlV3Lmsu20V+pe3/klJ8UlGl7PYEgjpABbVgHNA za2tqr3TqHpHozLTtyjMGmF0WQAAE+h39qrizhUlJcboxZzNio6MlC3EZnRZRkiwGF0BgOUl zBamsPQwxcXGaNLilL91WHUtDertcyoj5TlZg0Nl8ePUBADLgXvCrSHXoG7WX1eoLUibMjco wxKvV3J+rTBbmNHlGcpv7969e40uAsDyExwUrHWr12pVSqKsoRa5fQa1MjleJdUXdKbkiBLj 4uVou6PiG/kKC7Optee+iipPKyjYX31DnTp/PU9+/tLI+KDOlR7XhEbl4zehM1ePyOUeVEhw gE5eOaiBkW5FRoTrxKVv1TXYqhWx8Tpa9Be19tzXMyvTdOj8F7rffkfr09cr99ynutt0U5uf y9Y3Z/9PNQ8qlb1hiw6e+0zV98u1cV2W8oq/0436a1q3ep0Kyk6o8m6JVq98RpdvFuh67SWl JCarvO6yrt0uUkJsnGoeVOrKrQJFR0bI0Var4hv5Cg21qr23UUUVpxQUZFG/q0vnr38vX8uk RieGlF96TO4pl3wtUzpdcliu8QFZrUHKu5yr/uEu2aMjdfziN+oaaFFiwgodLfxaLd0OrV75 jA6d/0KOtlo9t2aDvjv3qeqabmrLhi064FlPtg4WfK5qR7k2rt2ok1cO6sa9a1r7TIbOX89T Rd0VPZOSppLq8yqrvaTkhERV1pXo2u1CxcfE6k7jDV2+eU5REeF60HFXl6rOymYLVmd/iwor TiowyE+DIz0qKPtePn4Tck+N6Oy1oxqfdMkSIJ0uOazhsX7ZQkOUV/yd+oY6FRMdreMXD6ij r0nJK5J0pPArNXXVa01qug6e/1wNbTXauDZT3+b/WbWNVcrJzHn4/blfoc3PbdaRwq90q+G6 NmRs0OmSw6q6d1UZaWtUWHFSFXVXlJaSqqvVhSqrvaikhERV3b2qq7cLFRtj192mW7p885wi IsLU1HlPF6vOyGoNUvdAqy6Un5R/gK+GRntVUHZC8nVrUqM6c+2oxiaGFRDgq1Mlh+Qc6VV4 mE3fF3+nXmeH4mLsOnbxgNr7GrUqKUWHL3ylxs57WpuWoYMFn6u+9bay1mXp2/w/q+ZBpXI2 vqBv8z/R7fsVev7ZTTp+8S+62VCm9enrdfbqUVXdu6o1qWt0sfK0yu9c1qrklSqruaTSmiIl JqxQdUOZSm6dV4w9WvUt1Sq+cU7h4aFq6WrQxcozCrEGqmewTRfKT8oS4KPhsX6dKzuhSZ8x yWdcZ64e0YjbqaAgi05eOahBV48iw0N1ovhbdQ+2KSEmVscuPnzNpKWk6vCFL/Wg466eXb1O uQWf6W7zLW1av1nfnP1ENQ8q9avMHH137lPdvl+urHXP68Slb3SzvlTPpj+r/GvHVHm3ROmp 6SquOqvrd4q1MilF5XcuPXzNxMXr9v1yldw6r+ioSDnaan7yHDDqdiq/9NiTnwPiEnS06Gu1 9jie/BzwyGsm73Lugp4DxiaHlX/tyc8BSQmJOlL41c86Bxw6/4WqHdeVuTbzic4B06+ZOHuM 6ppuzvsc4BofkNUWqANnP9Kwu1svbNmoKf9BvZD9vNalpysjLUOBAYFG/5gy2h8ZdwFgOgPO AQUGBGrINaRh17AiwiI0MTGhwaFBT2dlwDmgUGuo/Pz81DfQJ2uwVYEBgerp71FwULBCgkLU 3detoMAghVpD1dnTqQD/AEWGR6q9q10WP4vsUXa1dbbJz89PcdFxaulokY+Pj1bErlBze7Mk KTEuUS0dLZqamtKK2BVq727XxMSE4mPi1dXTJfeEW3H2OPX292psfEwxUTEaHBrUyOiIoiOi NTwyLNeIS5HhkRobG9OQa0jhoeGanJz80fWEBIcoKCDosfUEBgQqzBamzp5O+Vv8FRUR5VlP TFSMWjtb5evrq3h7vGc9iXGJampr8qyntbNVk5OTSohJUEdPh2c93b3dGnePKzY6Vv2D/Rod G5U90i7nsNOzHteoS8OuYUWGR2p8fFzOYedj6/Hx8VH/YL9sITZZLJZZ12MNtqqrt2vB1hNn j1NPX4/G3eOKiYrRgHPgsfVEhUdpZGzE8xxzu92e9UxNTXm+J76+vp71+Pv7q7e/VyHBIQoO DPY8x2whNs96wkPD1dHdIX+Lv6Ijoz3PsdioWM96EmISPM+xpPgkNbc3e55jbV1tnvV09nR6 nmNzrWfINSTXiGvB1/PD18z0ehbqNRMVHqXRsVENuYaWzTngx14zS+kcEBQYpIiwCI2NjSkk OGTBf6Y8pZhJBwAAAEyGSzACAAAAZkNIBwAAAEyGkA4AAACYDCEdAAAAMBlCOgAAAGAyhHQA AADAZAjpAAAAgMkQ0gEAAACTIaQDAAAAJkNIBwAAAEyGkA4AAACYDCEdAAAAMBlCOgAAAGAy hHQAAADAZAjpAAAAgMkQ0gEAAACTIaQDAAAAJkNIBwAAAEyGkA4AAACYDCEdAAAAMBlCOgAA AGAyhHQAAADAZAjpAAAAgMkQ0gEAAACTIaQDAAAAJkNIBwAAAEyGkA4AAACYDCEdAAAAMBlC OgAAAGAyhHQAAADAZAjpAAAAgMkQ0gEAAACTIaQDAAAAJkNIBwAAAEyGkA4AAACYDCEdAAAA MBlCOgAAAGAyFklvGl0EAAAAAI++/wd3IHskhwwnugAAAABJRU5ErkJggg== --------------090301090900080605040005-- From ietfdbh@comcast.net Sat Jul 13 08:17:29 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D61321F9E80 for ; Sat, 13 Jul 2013 08:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.135 X-Spam-Level: X-Spam-Status: No, score=-100.135 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY1gK0rrDt5Y for ; Sat, 13 Jul 2013 08:17:24 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id CA66D21F9E02 for ; Sat, 13 Jul 2013 08:17:10 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta13.westchester.pa.mail.comcast.net with comcast id zo3o1l0051ZXKqc5DrH9Tc; Sat, 13 Jul 2013 15:17:09 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta21.westchester.pa.mail.comcast.net with comcast id zrH81l00a2yZEBF3hrH8wp; Sat, 13 Jul 2013 15:17:09 +0000 From: "ietfdbh" To: "'Gunnar Engelbach'" References: <20130711162658.7093.66495.idtracker@ietfa.amsl.com> <51DEDDE5.2070101@ieca.com> <012d01ce7f09$0fc8bc90$2f5a35b0$@comcast.net> <51E01C90.1040403@ThreatGuard.com> <013a01ce7f19$38d55ca0$aa8015e0$@comcast.net> <51E03F4D.1060302@ThreatGuard.com> In-Reply-To: <51E03F4D.1060302@ThreatGuard.com> Date: Sat, 13 Jul 2013 11:16:35 -0400 Message-ID: <01bc01ce7fdb$f75dfb60$e619f220$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHznD1rOpqPCNVF4Uo3EJCv58gmKAINk8g2AjtcOjgBb90cjAFO6ToFAtWXVCOYyG8HkA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373728629; bh=cdjvRNTJ4PcjXFPATr90ox8wXlrVotW+NiFgBUC0N+s=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Q1EeQN1sKXGn7oKoKrYa+qQZZWFmycOm1t8jzZB9ACq/QP6jHvHiST5KNXj9TS1pO M5pni+Bqust6NahHFYd2ChPnYka8NNS9RwinO+94ldut/fLFPYQ0R0f7nfkfB/a2QJ veGZefBzos3RwO6GQVVopnbq5SpTNaeZ62dVsG0yRnjx9LKuSZOwXtj0KWz1JENXqT O4wvxem4JpCRBSPLdAz+N241v1Ghw3UxBHxmbAmckO4J/iys+iZMGdm/Kt+I6Azy1k JLWjCB2nER/cnH/vgvyeF8nCnmfLjR5RhC6cF+7rZF7PDyimr7Er4T1EhNfIUSGqX/ sU0NdN+cetvKQ== Cc: 'David Harrington' , 'Sean Turner' , sacm@ietf.org Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 15:17:29 -0000 Hi Gunnar, Thanks; that's much better. I think many people will have many different approaches to their architecture, but there will be quite a bit of commonality we can try to extract from them. Would you be willing to write some text quickly describing your collection, assessment, and management system, so we can add this to the use-cases document? The more we understand how people plan to gather and assess data, and turn the collected data into information that can then be used by humans, the better we can design a solution to meet the needs of multiple approaches. I have some questions, so I can better understand your architecture, and to make sure I don't make any unwarranted assumptions. Working from EntitiesInUse, 1) Do these diagrams represent a system you have already implemented? 2) Has it been deployed in real-world environments? 3) Has it been deployed in enterprise environments? Service provider environment? 4) What are you using for protocols between the assessment server and the computer with agent? 5) What are you using for protocols between the assessment server and the computers without agents? 6) When the valuator gathers data from agent-less computers, does it convert the data into the same format that is used to gather data from a computer with agent? 7) It appears the controller always talks to the evaluator, never directly to the data collector. I realize this is an architectural drawing, and in actual coding a direct-connect might be used to performance improvements. Is the intent that the controller always goes through the evaluator function? 8) when you have a subdomain, which entities in the super-domain communicate directly with entities in the subdomain? 8a) Is this a server-to-server sharing of information? 8b) Can server A directly access the evaluator function in the subdomain B? or does it proxy requests for evaluations via subdomain server B controller? 8c) Can server A directly query the data collector in subdomain B? does it us 9) Is it fair to assume that the Independent Workstation is equivalent to a subdomain, which just happens to support only the one workstation it is running on? More later ... Thanks, David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > Sent: Friday, July 12, 2013 1:39 PM > To: ietfdbh > Cc: 'David Harrington'; 'Sean Turner'; sacm@ietf.org > Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate- > architecture-00.txt > > > Try these. They're just not scalable. > > > > On 7/12/2013 12:02 PM, ietfdbh wrote: > > I can't read your svg files. > > > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > >> Of Gunnar Engelbach > >> Sent: Friday, July 12, 2013 11:11 AM > >> To: David Harrington > >> Cc: 'Sean Turner'; sacm@ietf.org > >> Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate- > >> architecture-00.txt > >> > >> > >> I like the original. It's only concerned with the logical components > >> that > > make > >> up SACM -- the flexibility in how they are mixed and match to solve > >> real problems is one of its big strengths. > >> > >> But it's also apparent that this is not being effectively communicated. > >> > >> I sent some (lousy) drawings to the mailing list a while back trying > >> to > > capture > >> that flexibility -- attached here again for your amusement/befuddlement. > >> > >> > >> Do very specific use cases help people understand how these standards > >> can be applied? > >> > >> > >> --gun > >> > >> > >> > >> On 7/12/2013 10:06 AM, David Harrington wrote: > >>> Hi, > >>> > >>> While I don't fully agree with the original architecture, I find it > > easier > >>> to understand the intended functionality than in the alternate > > architecture. > >>> > >>> I understand the goal here of showing where the on-the-wire > >>> protocols operate between entities. > >>> The data flows in the Waltermire architecture do not clearly capture > >>> the on-the-wire-ness of the flows, and what sits where in the network. > >>> It might be helpful to use both diagrams, combined, to show the > >>> network entities and on-the-wire data flows, and then show within > >>> the entity > >> boxes, > >>> the expected functionality provided by each. > >>> > >>> The new architecture seems focused on a combination firewall/IDS > >>> box; > >> that > >>> seems like a particular use case. > >>> As you all know already, I think the scope of the sacm work needs to > >>> be narrowed, but this might narrow it too much. > >>> > >>> (Sean, can you write up a firewall/IDS use case that I can put into > >>> the use-cases document for this usage?) > >>> > >>> David Harrington > >>> dbharrington@comcast.net > >>> +1-603-828-1401 > >>> > >>>> -----Original Message----- > >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > >>>> Behalf > >> Of > >>>> Sean Turner > >>>> Sent: Thursday, July 11, 2013 12:32 PM > >>>> To: sacm@ietf.org > >>>> Subject: [sacm] Fwd: I-D Action: > > draft-handt-sacm-alternate-architecture- > >>>> 00.txt > >>>> > >>>> Food for thought. > >>>> > >>>> spt > >>>> -------- Original Message -------- > >>>> Subject: I-D Action: draft-handt-sacm-alternate-architecture-00.txt > >>>> Date: Thu, 11 Jul 2013 09:26:58 -0700 > >>>> From: internet-drafts@ietf.org > >>>> Reply-To: internet-drafts@ietf.org > >>>> To: i-d-announce@ietf.org > >>>> > >>>> > >>>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>>> > >>>> > >>>> Title : sacm: Alternate Architecture > >>>> Author(s) : Russ Housley > >>>> Sean Turner > >>>> Filename : draft-handt-sacm-alternate-architecture-00.txt > >>>> Pages : 5 > >>>> Date : 2013-07-11 > >>>> > >>>> Abstract: > >>>> This document proposes and alternate architecture for sacm (a > >>>> proposed working group at the time this draft was submitted). > >>>> > >>>> > >>>> The IETF datatracker status page for this draft is: > >>>> > > https://datatracker.ietf.org/doc/draft-handt-sacm-alternate-architectu > > re > >>>> > >>>> There's also a htmlized version available at: > >>>> http://tools.ietf.org/html/draft-handt-sacm-alternate-architecture- > >>>> 00 > >>>> > >>>> > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> > >>>> _______________________________________________ > >>>> I-D-Announce mailing list > >>>> I-D-Announce@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>> Internet-Draft directories: http://www.ietf.org/shadow.html or > >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> sacm mailing list > >>>> sacm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sacm > >>> > >>> _______________________________________________ > >>> sacm mailing list > >>> sacm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sacm > >>> > > From gunnar.engelbach@threatguard.com Sat Jul 13 12:11:27 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8D521F8F38 for ; Sat, 13 Jul 2013 12:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQqXrx5MHWfS for ; Sat, 13 Jul 2013 12:11:23 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id EAD4C21F8E3D for ; Sat, 13 Jul 2013 12:11:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=RW5b3AzJyJucp695j4wd9PjZbP606PjM109OuA60Yo3PJjH66z0gdxw2tBTlFYD6X3jxs4dvO4362pRKYhoMUweRult+hllE1b553KrFTDSlcbOl4oJuBFrgu6gU4zTY; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 11583 invoked from network); 13 Jul 2013 12:09:15 -0700 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Jul 2013 12:09:15 -0700 Message-ID: <51E1A660.4090308@ThreatGuard.com> Date: Sat, 13 Jul 2013 15:11:28 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ietfdbh References: <20130711162658.7093.66495.idtracker@ietfa.amsl.com> <51DEDDE5.2070101@ieca.com> <012d01ce7f09$0fc8bc90$2f5a35b0$@comcast.net> <51E01C90.1040403@ThreatGuard.com> <013a01ce7f19$38d55ca0$aa8015e0$@comcast.net> <51E03F4D.1060302@ThreatGuard.com> <01bc01ce7fdb$f75dfb60$e619f220$@comcast.net> In-Reply-To: <01bc01ce7fdb$f75dfb60$e619f220$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'David Harrington' , 'Sean Turner' , sacm@ietf.org Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 19:11:27 -0000 Sure. I won't be able to get to it right away, though. On 7/13/2013 11:16 AM, ietfdbh wrote: > Hi Gunnar, > > Thanks; that's much better. > > I think many people will have many different approaches to their > architecture, but there will be quite a bit of commonality we can try to > extract from them. > Would you be willing to write some text quickly describing your collection, > assessment, and management system, so we can add this to the use-cases > document? > The more we understand how people plan to gather and assess data, and turn > the collected data into information that can then be used by humans, the > better we can design a solution to meet the needs of multiple approaches. > > > I have some questions, so I can better understand your architecture, and to > make sure I don't make any unwarranted assumptions. > Working from EntitiesInUse, > 1) Do these diagrams represent a system you have already implemented? > 2) Has it been deployed in real-world environments? > 3) Has it been deployed in enterprise environments? Service provider > environment? > 4) What are you using for protocols between the assessment server and the > computer with agent? > 5) What are you using for protocols between the assessment server and the > computers without agents? > 6) When the valuator gathers data from agent-less computers, does it convert > the data into the same format that is used to gather data from a computer > with agent? > 7) It appears the controller always talks to the evaluator, never directly > to the data collector. I realize this is an architectural drawing, and in > actual coding a direct-connect might be used to performance improvements. Is > the intent that the controller always goes through the evaluator function? > 8) when you have a subdomain, which entities in the super-domain communicate > directly with entities in the subdomain? > 8a) Is this a server-to-server sharing of information? > 8b) Can server A directly access the evaluator function in the subdomain B? > or does it proxy requests for evaluations via subdomain server B controller? > 8c) Can server A directly query the data collector in subdomain B? does it > us > 9) Is it fair to assume that the Independent Workstation is equivalent to a > subdomain, which just happens to support only the one workstation it is > running on? > > More later ... > > Thanks, > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > >> -----Original Message----- >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >> Sent: Friday, July 12, 2013 1:39 PM >> To: ietfdbh >> Cc: 'David Harrington'; 'Sean Turner'; sacm@ietf.org >> Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate- >> architecture-00.txt >> >> >> Try these. They're just not scalable. >> >> >> >> On 7/12/2013 12:02 PM, ietfdbh wrote: >>> I can't read your svg files. >>> >>> David Harrington >>> ietfdbh@comcast.net >>> +1-603-828-1401 >>> >>>> -----Original Message----- >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>>> Of Gunnar Engelbach >>>> Sent: Friday, July 12, 2013 11:11 AM >>>> To: David Harrington >>>> Cc: 'Sean Turner'; sacm@ietf.org >>>> Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate- >>>> architecture-00.txt >>>> >>>> >>>> I like the original. It's only concerned with the logical components >>>> that >>> make >>>> up SACM -- the flexibility in how they are mixed and match to solve >>>> real problems is one of its big strengths. >>>> >>>> But it's also apparent that this is not being effectively communicated. >>>> >>>> I sent some (lousy) drawings to the mailing list a while back trying >>>> to >>> capture >>>> that flexibility -- attached here again for your > amusement/befuddlement. >>>> >>>> >>>> Do very specific use cases help people understand how these standards >>>> can be applied? >>>> >>>> >>>> --gun >>>> >>>> >>>> >>>> On 7/12/2013 10:06 AM, David Harrington wrote: >>>>> Hi, >>>>> >>>>> While I don't fully agree with the original architecture, I find it >>> easier >>>>> to understand the intended functionality than in the alternate >>> architecture. >>>>> >>>>> I understand the goal here of showing where the on-the-wire >>>>> protocols operate between entities. >>>>> The data flows in the Waltermire architecture do not clearly capture >>>>> the on-the-wire-ness of the flows, and what sits where in the network. >>>>> It might be helpful to use both diagrams, combined, to show the >>>>> network entities and on-the-wire data flows, and then show within >>>>> the entity >>>> boxes, >>>>> the expected functionality provided by each. >>>>> >>>>> The new architecture seems focused on a combination firewall/IDS >>>>> box; >>>> that >>>>> seems like a particular use case. >>>>> As you all know already, I think the scope of the sacm work needs to >>>>> be narrowed, but this might narrow it too much. >>>>> >>>>> (Sean, can you write up a firewall/IDS use case that I can put into >>>>> the use-cases document for this usage?) >>>>> >>>>> David Harrington >>>>> dbharrington@comcast.net >>>>> +1-603-828-1401 >>>>> >>>>>> -----Original Message----- >>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >>>>>> Behalf >>>> Of >>>>>> Sean Turner >>>>>> Sent: Thursday, July 11, 2013 12:32 PM >>>>>> To: sacm@ietf.org >>>>>> Subject: [sacm] Fwd: I-D Action: >>> draft-handt-sacm-alternate-architecture- >>>>>> 00.txt >>>>>> >>>>>> Food for thought. >>>>>> >>>>>> spt >>>>>> -------- Original Message -------- >>>>>> Subject: I-D Action: draft-handt-sacm-alternate-architecture-00.txt >>>>>> Date: Thu, 11 Jul 2013 09:26:58 -0700 >>>>>> From: internet-drafts@ietf.org >>>>>> Reply-To: internet-drafts@ietf.org >>>>>> To: i-d-announce@ietf.org >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>>> >>>>>> >>>>>> Title : sacm: Alternate Architecture >>>>>> Author(s) : Russ Housley >>>>>> Sean Turner >>>>>> Filename : draft-handt-sacm-alternate-architecture-00.txt >>>>>> Pages : 5 >>>>>> Date : 2013-07-11 >>>>>> >>>>>> Abstract: >>>>>> This document proposes and alternate architecture for sacm (a >>>>>> proposed working group at the time this draft was submitted). >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> >>> https://datatracker.ietf.org/doc/draft-handt-sacm-alternate-architectu >>> re >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-handt-sacm-alternate-architecture- >>>>>> 00 >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sacm mailing list >>>>>> sacm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>> >>>>> _______________________________________________ >>>>> sacm mailing list >>>>> sacm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>> >>> > From michael.hammer@yaanatech.com Mon Jul 15 09:03:14 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03ED21E80A8 for ; Mon, 15 Jul 2013 09:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P93Yrkd8ibn1 for ; Mon, 15 Jul 2013 09:03:10 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id B55FB21E808C for ; Mon, 15 Jul 2013 09:03:10 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 15 Jul 2013 09:03:10 -0700 From: Michael Hammer To: "Gunnar.Engelbach@ThreatGuard.com" , "ietfdbh@comcast.net" Thread-Topic: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt Thread-Index: AQHOfybFfehWPl8LW0eVvtvvAwQaoJljLviAgABBoACAAncaAA== Date: Mon, 15 Jul 2013 16:03:09 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC165E9@EX2K10MB1.corp.yaanatech.com> References: <20130711162658.7093.66495.idtracker@ietfa.amsl.com> <51DEDDE5.2070101@ieca.com> <012d01ce7f09$0fc8bc90$2f5a35b0$@comcast.net> <51E01C90.1040403@ThreatGuard.com> <013a01ce7f19$38d55ca0$aa8015e0$@comcast.net> <51E03F4D.1060302@ThreatGuard.com> <01bc01ce7fdb$f75dfb60$e619f220$@comcast.net> <51E1A660.4090308@ThreatGuard.com> In-Reply-To: <51E1A660.4090308@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.65] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001E_01CE8153.456552E0" MIME-Version: 1.0 Cc: "dbharrington@comcast.net" , "turners@ieca.com" , "sacm@ietf.org" Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:03:15 -0000 ------=_NextPart_000_001E_01CE8153.456552E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Re: alternate architecture. If you don't understand why using logical functional elements is better than somebody's restrictive physical implementation, you will before long. Having been through a couple SDO's where weeks were wasted while one vendor tried to force others to adopt their implementation, I have no wish to repeat that. The big take-away I got from this alternate diagram was that you wanted the evaluator to directly access the sensor (asset) and prohibit other means of accessing the repository. I have to wonder is that is as scalable as the original architecture. Your simplified architecture would simply be: Sensor-Evaluator-Repository Adding in the firewalls seems an unnecessary distraction. Or, are those evaluators also? Also, I can guess what C is for, but that should be explained. Lastly, I don't see the need to insult the reader in section 2. Mike -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach Sent: Saturday, July 13, 2013 3:11 PM To: ietfdbh Cc: 'David Harrington'; 'Sean Turner'; sacm@ietf.org Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt Sure. I won't be able to get to it right away, though. On 7/13/2013 11:16 AM, ietfdbh wrote: > Hi Gunnar, > > Thanks; that's much better. > > I think many people will have many different approaches to their > architecture, but there will be quite a bit of commonality we can try > to extract from them. > Would you be willing to write some text quickly describing your > collection, assessment, and management system, so we can add this to > the use-cases document? > The more we understand how people plan to gather and assess data, and > turn the collected data into information that can then be used by > humans, the better we can design a solution to meet the needs of multiple approaches. > > > I have some questions, so I can better understand your architecture, > and to make sure I don't make any unwarranted assumptions. > Working from EntitiesInUse, > 1) Do these diagrams represent a system you have already implemented? > 2) Has it been deployed in real-world environments? > 3) Has it been deployed in enterprise environments? Service provider > environment? > 4) What are you using for protocols between the assessment server and > the computer with agent? > 5) What are you using for protocols between the assessment server and > the computers without agents? > 6) When the valuator gathers data from agent-less computers, does it > convert the data into the same format that is used to gather data from > a computer with agent? > 7) It appears the controller always talks to the evaluator, never > directly to the data collector. I realize this is an architectural > drawing, and in actual coding a direct-connect might be used to > performance improvements. Is the intent that the controller always goes through the evaluator function? > 8) when you have a subdomain, which entities in the super-domain > communicate directly with entities in the subdomain? > 8a) Is this a server-to-server sharing of information? > 8b) Can server A directly access the evaluator function in the subdomain B? > or does it proxy requests for evaluations via subdomain server B controller? > 8c) Can server A directly query the data collector in subdomain B? > does it us > 9) Is it fair to assume that the Independent Workstation is equivalent > to a subdomain, which just happens to support only the one workstation > it is running on? > > More later ... > > Thanks, > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > >> -----Original Message----- >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >> Sent: Friday, July 12, 2013 1:39 PM >> To: ietfdbh >> Cc: 'David Harrington'; 'Sean Turner'; sacm@ietf.org >> Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate- >> architecture-00.txt >> >> >> Try these. They're just not scalable. >> >> >> >> On 7/12/2013 12:02 PM, ietfdbh wrote: >>> I can't read your svg files. >>> >>> David Harrington >>> ietfdbh@comcast.net >>> +1-603-828-1401 >>> >>>> -----Original Message----- >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >>>> Behalf Of Gunnar Engelbach >>>> Sent: Friday, July 12, 2013 11:11 AM >>>> To: David Harrington >>>> Cc: 'Sean Turner'; sacm@ietf.org >>>> Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate- >>>> architecture-00.txt >>>> >>>> >>>> I like the original. It's only concerned with the logical >>>> components that >>> make >>>> up SACM -- the flexibility in how they are mixed and match to solve >>>> real problems is one of its big strengths. >>>> >>>> But it's also apparent that this is not being effectively communicated. >>>> >>>> I sent some (lousy) drawings to the mailing list a while back >>>> trying to >>> capture >>>> that flexibility -- attached here again for your > amusement/befuddlement. >>>> >>>> >>>> Do very specific use cases help people understand how these >>>> standards can be applied? >>>> >>>> >>>> --gun >>>> >>>> >>>> >>>> On 7/12/2013 10:06 AM, David Harrington wrote: >>>>> Hi, >>>>> >>>>> While I don't fully agree with the original architecture, I find >>>>> it >>> easier >>>>> to understand the intended functionality than in the alternate >>> architecture. >>>>> >>>>> I understand the goal here of showing where the on-the-wire >>>>> protocols operate between entities. >>>>> The data flows in the Waltermire architecture do not clearly >>>>> capture the on-the-wire-ness of the flows, and what sits where in the network. >>>>> It might be helpful to use both diagrams, combined, to show the >>>>> network entities and on-the-wire data flows, and then show within >>>>> the entity >>>> boxes, >>>>> the expected functionality provided by each. >>>>> >>>>> The new architecture seems focused on a combination firewall/IDS >>>>> box; >>>> that >>>>> seems like a particular use case. >>>>> As you all know already, I think the scope of the sacm work needs >>>>> to be narrowed, but this might narrow it too much. >>>>> >>>>> (Sean, can you write up a firewall/IDS use case that I can put >>>>> into the use-cases document for this usage?) >>>>> >>>>> David Harrington >>>>> dbharrington@comcast.net >>>>> +1-603-828-1401 >>>>> >>>>>> -----Original Message----- >>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >>>>>> Behalf >>>> Of >>>>>> Sean Turner >>>>>> Sent: Thursday, July 11, 2013 12:32 PM >>>>>> To: sacm@ietf.org >>>>>> Subject: [sacm] Fwd: I-D Action: >>> draft-handt-sacm-alternate-architecture- >>>>>> 00.txt >>>>>> >>>>>> Food for thought. >>>>>> >>>>>> spt >>>>>> -------- Original Message -------- >>>>>> Subject: I-D Action: >>>>>> draft-handt-sacm-alternate-architecture-00.txt >>>>>> Date: Thu, 11 Jul 2013 09:26:58 -0700 >>>>>> From: internet-drafts@ietf.org >>>>>> Reply-To: internet-drafts@ietf.org >>>>>> To: i-d-announce@ietf.org >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line >>>>>> Internet-Drafts >>>>> directories. >>>>>> >>>>>> >>>>>> Title : sacm: Alternate Architecture >>>>>> Author(s) : Russ Housley >>>>>> Sean Turner >>>>>> Filename : draft-handt-sacm-alternate-architecture-00.txt >>>>>> Pages : 5 >>>>>> Date : 2013-07-11 >>>>>> >>>>>> Abstract: >>>>>> This document proposes and alternate architecture for sacm (a >>>>>> proposed working group at the time this draft was submitted). >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> >>> https://datatracker.ietf.org/doc/draft-handt-sacm-alternate-architec >>> tu >>> re >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-handt-sacm-alternate-architectur >>>>>> e- >>>>>> 00 >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sacm mailing list >>>>>> sacm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>> >>>>> _______________________________________________ >>>>> sacm mailing list >>>>> sacm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>> >>> > _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_001E_01CE8153.456552E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcx NTE2MDMwOFowIwYJKoZIhvcNAQkEMRYEFOKNCCv2HfxSkbe+/MSB5IDNUZmQMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEANv/hoHf0fPMb5xxUmwQKyUwYp6S4n/+LyT1CNkl/ M9NYdFai10Ku6Y6A+uqaCmxwPbWI6jar3RA5pRmVcVdACN2wXpmv0bKM/txWIzElmltZCB7+aCdh kSaa1l8MsadnY6K1eNT1QS4rvuLNvEQYNsVmMHEsowrJAoZOdJaTIs8CnYDR5xRd9fp1I+mi6FFi SVWwpvyxL7wgzfql4YGFoZWXYsZFWwdunFeeL0XoEjrpd7CFNF9+8b/Pwf1052dtFkGmwk9p9fFS sgB9xvjVWU/TRPzWlQzVBQVqCMY3WsAxp3K+N+gOtE+nBy4mnUmES6UG8pWSsxYmhtEAg8YQgwAA AAAAAA== ------=_NextPart_000_001E_01CE8153.456552E0-- From ietfdbh@comcast.net Mon Jul 15 11:56:58 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2A411E8189 for ; Mon, 15 Jul 2013 11:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.179 X-Spam-Level: X-Spam-Status: No, score=-100.179 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id era8fHwru5eL for ; Mon, 15 Jul 2013 11:56:53 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id A65DE11E8202 for ; Mon, 15 Jul 2013 11:56:49 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta06.westchester.pa.mail.comcast.net with comcast id 0bZt1m0031GhbT856iwpMQ; Mon, 15 Jul 2013 18:56:49 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta07.westchester.pa.mail.comcast.net with comcast id 0iwo1m01N2yZEBF3TiwoXA; Mon, 15 Jul 2013 18:56:49 +0000 From: "ietfdbh" To: References: <20130715153634.17077.71272.idtracker@ietfa.amsl.com> In-Reply-To: <20130715153634.17077.71272.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 14:56:07 -0400 Message-ID: <00ea01ce818c$f6a2ec00$e3e8c400$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGQ83q+p8gR4nIGHKgVIDd7wdZLUZnhD6Pg Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373914609; bh=O9ga5Rvbm4BNhFI09gX7k9fJfsq1Y/jgzJcg2b4QjSc=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=T8Lz1Z/Ra9hL3DpljYsyRO7J0lZliIFFvXpp1e7keoF9LI2xX+MptQpQhnCMUXs2z 837rGAzMeh6ZFvAvg2ppZNhi/PrbSOCql4OCJAspSfbZlCZf0/q+OftaoMInnUd3CW 1Q1qdAG4X9hJk4+P0HKO8y4gMa9UfJQpSNcHvCMi0/4yIvNldf8amjznRc1GTSob5N f0f+VXK+Z1dqQ1XnZB7UKvJH0Pc5C1jU37V/zKHeVEdDFeGAxnorUa27ZdY6RK+hX7 ouPqv9oVcMO2mtu3R6hthatd2tbq/3mVMKpqJJWmhkzDd/7twRw+lXxAB6C0MHKhzu 1jVbm+AZ523qQ== Subject: [sacm] FW: I-D Action: draft-waltermire-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:56:58 -0000 Hi, I have edited the use cases draft and made substantial changes. The changes are summarized in a Change Log near the end of the document. The purpose and tenor of the document are now significantly different than earlier versions. The WG should look this over to see whether they think this is the direction we should be going with this document. My experience in the IETF is that "use cases" are simple English descriptions of what a technology will be used for (or how a technology will be used), so that readers of a use cases document can better understand the goals of doing the work in the first place. Because the IETF believes in rough consensus and running code, descriptions of existing uses of a proposed technology tend to be preferred. Vendors often solve problems that their customers are experiencing, but each vendor is likely to solve problems that are similar in different ways. But trends develop, and the proprietary solutions tend to use some similarity in their approaches. When customers deploy solutions from multiple vendors, lack of interoperability becomes the problem. That's when standardization is required. So what we should be looking at is, what similar problems have been getting addressed? And can we agree on a more standardized approach to solving those problems? First, we need to talk about our experiences ... I recommend you look at other "use cases" documents in the RFC series. I think the stage we are at is to talk together and compare what we think the problem is, and brainstorm a few ideas of what is needed (the architecture) to solve the problems. The goal at this point is to achieve consensus on what problems we will focus on solving, and get everybody working in the same direction. If we all go off to solve different problems (asset mgmt., vs config mgmt. vs vulnerability mgmt. vs firewalls vs IDS vs NEA vs incident sharing vs ... ), we'll never get consensus on a solution. I think the recent discussions about alternative architectures and various asset identifiers shows clearly we do not yet have agreement on the scope of the problems we will address. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Monday, July 15, 2013 11:37 AM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-waltermire-sacm-use-cases-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Using Security Posture Assessment to Grant Access to > Enterprise Network Resources > Author(s) : David Waltermire > Adam W. Montville > David Harrington > Filename : draft-waltermire-sacm-use-cases-05.txt > Pages : 20 > Date : 2013-07-14 > > Abstract: > This memo documents a sampling of use cases for securely aggregating > configuration and operational data and assessing that data to > determine an organization's security posture. From these operational > use cases, we can derive common functional capabilities and > requirements to guide development of vendor-neutral, interoperable > standards for aggregating and assessing data relevant to security > posture. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-waltermire-sacm-use-cases > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-waltermire-sacm-use-cases-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Adam.Montville@cisecurity.org Mon Jul 15 11:59:02 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E340E11E81D5 for ; Mon, 15 Jul 2013 11:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.823 X-Spam-Level: X-Spam-Status: No, score=-2.823 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65TqqT6i3H7O for ; Mon, 15 Jul 2013 11:58:57 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0D611E81BB for ; Mon, 15 Jul 2013 11:58:55 -0700 (PDT) Received: from [216.82.250.19:9786] by server-8.bemta-12.messagelabs.com id 14/6C-31440-C6644E15; Mon, 15 Jul 2013 18:58:52 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-8.tower-87.messagelabs.com!1373914725!16509378!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 25271 invoked from network); 15 Jul 2013 18:58:46 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-8.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 15 Jul 2013 18:58:46 -0000 Received: from CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c]) by CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3%14]) with mapi id 14.02.0342.003; Mon, 15 Jul 2013 14:58:45 -0400 From: Adam Montville To: Adam Montville , Sean Turner Thread-Topic: [sacm] Berlin Meeting Thread-Index: Ac54C8T0vI3rw79uRzyAYc89//zKvgAf9w0AAEruIsAB9SxKUA== Date: Mon, 15 Jul 2013 18:58:43 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D671EAF4@CISEXCHANGE2.msisac.org.local> References: <05BCCEB107AF88469B9F99783D47C1D67053C9@CISEXCHANGE1.msisac.org.local> <51D4F1D2.104@ieca.com> <05BCCEB107AF88469B9F99783D47C1D6705BF1@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6705BF1@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Berlin Meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:59:02 -0000 Stealing unabashedly from Brian Trammel's awesome example over on the MILE= list... If you'd like a slot to talk at the SACM WG meeting in Berlin, please let = us know at sacm-chairs@tools.ietf.org by end of day tomorrow! =20 Topics for discussion include any document or topic covered by the recentl= y approved charter (http://datatracker.ietf.org/wg/sacma/charter/). Priori= ty will be given to working-group drafts and discussion of significant pro= gress on previously presented documents. The meeting will take place in Tiergarten 1/2 on Friday, August 7, 11:20-1= 2:20 CEST. Regards, Adam > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Friday, July 05, 2013 12:44 PM > To: Sean Turner > Cc: sacm@ietf.org > Subject: Re: [sacm] Berlin Meeting >=20 > NOTE: Please ignore the confidentiality notice at the bottom of this e-m= ail > (and others) - it is added after I hit "send" and will be removed for IE= TF > correspondence sometime in the next week or two. >=20 >=20 > > -----Original Message----- > > From: Sean Turner [mailto:turners@ieca.com] > > Sent: Wednesday, July 03, 2013 8:53 PM > > To: Adam Montville > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Berlin Meeting > > > > On 7/3/13 12:51 PM, Adam Montville wrote: > > > All: > > > > > > While we are not yet an official WG, I'd like to try to get our > > > ducks in a row and progress as though we are a WG. I see some > > > important dates have passed, and that some are upcoming > > > (http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87). > > > > > > Notably: > > > > > > * 2013-07-05 (this Friday): Final agenda published > > > * 2013-07-15: Internet Draft submission cut-off (for all drafts, > > > including -00) > > > * 2013-07-17: Draft WG agendas due by UTC 24:00 > > > > > > Given the milestones listed in our charter, it seems that our agenda= > > > should contain a healthy dose of use case an discussion and possibly= > > > some requirements discussion. > > > > > > Proposed (loose) Agenda: > > > >=20> > * Note well + agenda bashing > > > * Charter and Milestone Review > > > > If it's chartered, then we can skip the charter review - it won't be > > up for discussion because it'll be approved ;) >=20 > Fair enough. Consider the two stricken from the proposed agenda. >=20 > > > > Normally, I'd suggest that sessions avoid summaries of the existing dr= afts. > > Participants (used this word on purpose) should read the drafts > > *before* they come to the session. I'd actually like presenters to > > ask before they start who has read their draft ;) > > > > But, being that this would be the first ever session it's probably > > okay to present what's in them. In the future, though we can push the= > > work forward and get to the point by only talking about open issues. >=20 > I would encourage everyone to read ahead even for this first session and= > would anticipate review of these to be minimal and only for those who ma= y > not otherwise have heard about SACM work before Berlin. >=20 > > > > > * Use Case Discussion > > > * Review of list > > > * Presentation on latest draft (if update submitted) > > > * Requirements discussion (time permitting) > > > * Administravia (new-WG-related stuff) > > > > > > Are there relevant drafts that we want to discuss in Berlin and can > > > be submitted before the 15 July deadline? At present, the following= > > > "related documents" show up on our Documents page > > > (http://datatracker.ietf.org/wg/sacm/): > > > > > > * draft-booth-sacm-vuln-model-02 > > > * draft-waltermire-sacm-architecture-00 > > > * draft-waltermire-sacm-use-cases-04 > > > > Ideally, all of these drafts would be updated before the meeting > > (hint) ;) >=20 > I am unsure as to the state of the vulnerability model and the architect= ure > document. I know that David Harrington has been working on trimming up > the use case document. >=20 > On that note, he has asked on several occasions for some more concrete u= se > case examples, but I haven't really seen many provided. It would be goo= d > for this community to throw a few out there. Remember that use cases > don't need to be comprehensive with respect to the requirements. They > should exemplify. >=20 > If there are use cases treated elsewhere, but to which access is limited= (i.e. > other organizations have published similar use cases but the documents > aren't free), then I suggest that we summarize them here without simply > referencing that work. >=20 >=20 > > > > > I'm looking forward to seeing you in Berlin! > > > > > > Regards, > > > > > > Adam > > > > > > > > > This message and attachments may contain confidential information. > > > If it appears that this message was sent to you by mistake, any > > > retention, dissemination, distribution or copying of this message > > > and attachments is strictly prohibited. Please notify the sender > > > immediately and permanently delete the message and any attachments. > > > > > > > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > ... >=20 > This message and attachments may contain confidential information. If i= t > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments i= s > strictly prohibited. Please notify the sender immediately and permanent= ly > delete the message and any attachments. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From dromasca@avaya.com Mon Jul 15 12:05:19 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E984411E824B for ; Mon, 15 Jul 2013 12:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.293 X-Spam-Level: X-Spam-Status: No, score=-103.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUp5w97FINww for ; Mon, 15 Jul 2013 12:05:14 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 9D50011E8242 for ; Mon, 15 Jul 2013 12:04:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsGAEBH5FGHCzI1/2dsb2JhbABagmUhNE+tU5QCgRMWdIIjAQEBAQIBAQEBDyg0CwUHBAIBCA0EAQMBAQEKFAkHJwsUAwYIAQEEAQ0FCAELDodoBgELmgSbYxeOLAaBATEHBoMFbQOZBYUdiweDEoFoCRcg X-IronPort-AV: E=Sophos;i="4.89,670,1367985600"; d="scan'208";a="16585735" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Jul 2013 15:04:28 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Jul 2013 14:58:28 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Mon, 15 Jul 2013 15:04:26 -0400 From: "Romascanu, Dan (Dan)" To: Adam Montville , Sean Turner Thread-Topic: [sacm] Berlin Meeting Thread-Index: Ac54C8T0vI3rw79uRzyAYc89//zKvgAf9w0AAEruIsAB9SxKUAAAdO8w Date: Mon, 15 Jul 2013 19:04:25 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128724B8@AZ-FFEXMB04.global.avaya.com> References: <05BCCEB107AF88469B9F99783D47C1D67053C9@CISEXCHANGE1.msisac.org.local> <51D4F1D2.104@ieca.com> <05BCCEB107AF88469B9F99783D47C1D6705BF1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D671EAF4@CISEXCHANGE2.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D671EAF4@CISEXCHANGE2.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Berlin Meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:05:20 -0000 > The meeting will take place in Tiergarten 1/2 on Friday, August 7, > 11:20-12:20 CEST. Actually we have a second one hour slot scheduled 12:30-13:30. We may decid= e to go without a break and finish earlier if so it happens, but we can pla= n for two hours.=20 Regards, Dan > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Monday, July 15, 2013 9:59 PM > To: Adam Montville; Sean Turner > Cc: sacm@ietf.org > Subject: Re: [sacm] Berlin Meeting >=20 > Stealing unabashedly from Brian Trammel's awesome example over on the > MILE list... >=20 > If you'd like a slot to talk at the SACM WG meeting in Berlin, please > let us know at sacm-chairs@tools.ietf.org by end of day tomorrow! >=20 > Topics for discussion include any document or topic covered by the > recently approved charter > (http://datatracker.ietf.org/wg/sacma/charter/). Priority will be given > to working-group drafts and discussion of significant progress on > previously presented documents. >=20 > The meeting will take place in Tiergarten 1/2 on Friday, August 7, > 11:20-12:20 CEST. >=20 > Regards, >=20 > Adam >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Friday, July 05, 2013 12:44 PM > > To: Sean Turner > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Berlin Meeting > > > > NOTE: Please ignore the confidentiality notice at the bottom of this > > e-mail (and others) - it is added after I hit "send" and will be > > removed for IETF correspondence sometime in the next week or two. > > > > > > > -----Original Message----- > > > From: Sean Turner [mailto:turners@ieca.com] > > > Sent: Wednesday, July 03, 2013 8:53 PM > > > To: Adam Montville > > > Cc: sacm@ietf.org > > > Subject: Re: [sacm] Berlin Meeting > > > > > > On 7/3/13 12:51 PM, Adam Montville wrote: > > > > All: > > > > > > > > While we are not yet an official WG, I'd like to try to get our > > > > ducks in a row and progress as though we are a WG. I see some > > > > important dates have passed, and that some are upcoming > > > > (http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87). > > > > > > > > Notably: > > > > > > > > * 2013-07-05 (this Friday): Final agenda published > > > > * 2013-07-15: Internet Draft submission cut-off (for all drafts, > > > > including -00) > > > > * 2013-07-17: Draft WG agendas due by UTC 24:00 > > > > > > > > Given the milestones listed in our charter, it seems that our > > > > agenda should contain a healthy dose of use case an discussion and > > > > possibly some requirements discussion. > > > > > > > > Proposed (loose) Agenda: > > > > > > > > * Note well + agenda bashing > > > > * Charter and Milestone Review > > > > > > If it's chartered, then we can skip the charter review - it won't be > > > up for discussion because it'll be approved ;) > > > > Fair enough. Consider the two stricken from the proposed agenda. > > > > > > > > Normally, I'd suggest that sessions avoid summaries of the existing > drafts. > > > Participants (used this word on purpose) should read the drafts > > > *before* they come to the session. I'd actually like presenters to > > > ask before they start who has read their draft ;) > > > > > > But, being that this would be the first ever session it's probably > > > okay to present what's in them. In the future, though we can push > > > the work forward and get to the point by only talking about open > issues. > > > > I would encourage everyone to read ahead even for this first session > > and would anticipate review of these to be minimal and only for those > > who may not otherwise have heard about SACM work before Berlin. > > > > > > > > > * Use Case Discussion > > > > * Review of list > > > > * Presentation on latest draft (if update submitted) > > > > * Requirements discussion (time permitting) > > > > * Administravia (new-WG-related stuff) > > > > > > > > Are there relevant drafts that we want to discuss in Berlin and > > > > can be submitted before the 15 July deadline? At present, the > > > > following "related documents" show up on our Documents page > > > > (http://datatracker.ietf.org/wg/sacm/): > > > > > > > > * draft-booth-sacm-vuln-model-02 > > > > * draft-waltermire-sacm-architecture-00 > > > > * draft-waltermire-sacm-use-cases-04 > > > > > > Ideally, all of these drafts would be updated before the meeting > > > (hint) ;) > > > > I am unsure as to the state of the vulnerability model and the > > architecture document. I know that David Harrington has been working > > on trimming up the use case document. > > > > On that note, he has asked on several occasions for some more concrete > > use case examples, but I haven't really seen many provided. It would > > be good for this community to throw a few out there. Remember that > > use cases don't need to be comprehensive with respect to the > > requirements. They should exemplify. > > > > If there are use cases treated elsewhere, but to which access is > limited (i.e. > > other organizations have published similar use cases but the documents > > aren't free), then I suggest that we summarize them here without > > simply referencing that work. > > > > > > > > > > > I'm looking forward to seeing you in Berlin! > > > > > > > > Regards, > > > > > > > > Adam > > > > > > > > > > > > This message and attachments may contain confidential information. > > > > If it appears that this message was sent to you by mistake, any > > > > retention, dissemination, distribution or copying of this message > > > > and attachments is strictly prohibited. Please notify the sender > > > > immediately and permanently delete the message and any > attachments. > > > > > > > > > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > ... > > > > This message and attachments may contain confidential information. If > > it appears that this message was sent to you by mistake, any > > retention, dissemination, distribution or copying of this message and > > attachments is strictly prohibited. Please notify the sender > > immediately and permanently delete the message and any attachments. > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > > ... >=20 > This message and attachments may contain confidential information. If > it appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments > is strictly prohibited. Please notify the sender immediately and > permanently delete the message and any attachments. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From Adam.Montville@cisecurity.org Mon Jul 15 13:57:00 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7312911E824D for ; Mon, 15 Jul 2013 13:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zef1yM424XbC for ; Mon, 15 Jul 2013 13:56:52 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.109]) by ietfa.amsl.com (Postfix) with ESMTP id C9B8021F9130 for ; Mon, 15 Jul 2013 13:56:51 -0700 (PDT) Received: from [216.82.253.243:21000] by server-13.bemta-7.messagelabs.com id AA/18-01054-21264E15; Mon, 15 Jul 2013 20:56:50 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-14.tower-171.messagelabs.com!1373921809!20878031!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 10138 invoked from network); 15 Jul 2013 20:56:50 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-14.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 15 Jul 2013 20:56:50 -0000 Received: from CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c]) by CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3%14]) with mapi id 14.02.0342.003; Mon, 15 Jul 2013 16:56:49 -0400 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Use Case Discussion: Suspicious Endpoint Behavior Thread-Index: Ac6BnRsvXB1G28Z8TkmYX8u/K3iDnw== Date: Mon, 15 Jul 2013 20:56:47 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D671F8AB@CISEXCHANGE2.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] Use Case Discussion: Suspicious Endpoint Behavior X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:57:00 -0000 So, the Use Case discussion has been ongoing. David Harrington submitted = a 05 draft (thank you!), so we have a lot to talk about. Steve Hanna was = going to craft some additional use cases, and I offered to help. Here's w= hat I've come up with after Steve asked for the assist. It's detailed, and there's another one coming after this one... But, I th= ink the detail might be useful. When I think "use case" and that we want = to get down to brass tacks, then this is the level of detail I think about= . At the very least, if it is found to be too detailed, then we have esta= blished some boundaries where we have examples of what may not be detailed= enough (the pre 05 versions of the use case draft) and this (and followin= g) example for what may be too detailed. Nevertheless, I think it's probably easier to summarize from the detail th= an it is to derive details from the summary... Use Case Name: Suspicious Endpoint Behavior Description:=20 This Use Case describes the collaboration between specific participants in= =20an information security system specific to detecting a connection attem= pt to a known-bad Internet host by a botnet zombie that has made its way o= nto an organization's Information Technology systems. The primary human a= ctor is the Security Operations Center Analyst, and the primary software a= ctor is the configuration assessment tool. Note, however, the dependencie= s on other tools, such as asset management, intrusion detection, and messa= ging. Actors:=20 * Security Operations Center (SOC) Analyst,=20 * Information Security Officer,=20 * System Owner * Organizational Unit Leader Preconditions: * Organizational Security Policy Exists * Security Policy specifies appropriate asset management capabilities (= i.e. categorization of endpoints) * Security Policy specifies endpoint configuration baseline for asset c= ategorization * The Organization keeps a list of known-bad Internet hosts * The Organization associates owners who are individuals with endpoints= * The Organization associates organizational units with endpoints Postconditions: * Endpoint configuration has been assessed [1] * Results have been conveyed to scan requester Primary Path: 1. At 03:46 UTC an organization's Network Intrusion Detection System (NI= DS) sees an IP packet with a destination IPv6 address existing on a blackl= ist of known botnet command and control (C2) servers. 2. The NIDS sends an alert to the SOC Analyst. 3. The SOC Analyst uses the information captured in the alert (IP packet= and reason for the flag) to look up the endpoint in the organization's as= set inventory system and discovers that the endpoint is a Windows Server 2= 008 R2 Member Server playing the role of a File Server 4. The SOC Analyst also verifies that the IPv6 address cited by the NIDS= is, in fact, on the blacklist for known C2 servers. 5. At this point, the SOC Analyst switches over to the organization's co= nfiguration assessment tool 6. The SOC Analyst locates the offending endpoint in the configuration a= ssessment tool's endpoint catalog [2] 7. The SOC Analyst then initiates an immediate and complete endpoint ass= essment to determine if the endpoint has experienced any configuration dri= ft [3]. 8. The configuration assessment tool: 9.=20 a. Performs a preliminary asset inventory scan on the offending endpoi= nt, which results in a list of installed software [4][5] b. Performs a comparison between the last known asset inventory and th= e present asset inventory and notes any differences c. Searches it's local content repository for appropriate configuratio= n baselines for the operating system of the offending endpoint and for eac= h installed piece of software d. Upon aggregating the set of applicable configuration baselines, the= configuration assessment tool then connects to and queries the organizati= on's configuration content repository for newer baselines that may exist. e. If a new baseline exists, then it is returned by the configuration = content repository. 10. The configuration management tool, having the set of updated baselin= es, initiates a scan against the offending host, which yields a result set= . 11. The configuration management tool displays scan results to the SOC A= nalyst, which show that three new pieces of software have been installed o= n the offending endpoint where one piece of software is not on the authori= zed software list, and that several configuration items were out of compli= ance with the organization's established baselines. 12. The SOC Analyst reviews the information for accuracy and to plan nex= t steps before sending the report to the responsible Information Security = Officer, accountable System Owner, and the Organizational Unit Leader. A Note On Alternative Paths, Preconditions, and Postconditions: There are likely to be many points of optimization and optional paths. Fo= r example, a configuration assessment tool might provide a "quick glance" = look at the most recent scan history for the offending endpoint. A SOC An= alyst might then elect not to run a new scan (i.e. the offending endpoint = is known to be out of compliance, so why run a new scan?). Another point = might be that the offending endpoint is, at present, not authorized to be = on the network, in which case it is very likely not to exist in the config= uration assessment tool's endpoint catalog. As with alternative paths, pre-/post-conditions can vary widely. Consider= that this description likely represents an organization on the mature sid= e of managing information security. Many organizations do not have a Secu= rity Operations Center, nor do they necessarily monitor their network. It= may be the case that a log management process has detected the blackliste= d connection attempt through audit trail monitoring. Or, it may be the c= ase that a shared indicator of compromise has been used to detect the offe= nding endpoint. ------------------- [1] I am assuming at this point that "configuration assessment" has been d= efined and will be understood by the reader. What I consider to be "asses= sment" is that the baseline has been obtained, send to the scanning implem= entation, endpoint configuration item values have been harvested, endpoint= configuration item values have been compared against baseline, and result= s stored/forwarded as appropriate for the use case. [2] An "endpoint catalog" is intended to convey nothing more than the noti= on that configuration assessment tools are likely to have some method of l= isting, enumerating, or aggregating endpoints under configuration manageme= nt.=20 [3] It may not be necessary to specify what we mean by "complete" or the o= rder in which scanning operations take place. In this particular scenario= , I thought it might be useful to illustrate that "scan levels" exist on a= continuum. =20 [4] Remember that the configuration assessment tool has knowledge of the o= ffending endpoint so running a preliminary inventory scan is reasonable at= this point. [5] The mechanism of scan could be agent-based or remote, so details of ho= w a scan happens are omitted here. A more granular partition of the proce= ss is required for further details. This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From turners@ieca.com Mon Jul 15 13:57:59 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B7911E824D for ; Mon, 15 Jul 2013 13:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEMJi-eootb8 for ; Mon, 15 Jul 2013 13:57:54 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.41.255.2]) by ietfa.amsl.com (Postfix) with ESMTP id C23EF21E8141 for ; Mon, 15 Jul 2013 13:57:54 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 9EA739EB5236E; Mon, 15 Jul 2013 15:57:45 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 8E5E69EB52340 for ; Mon, 15 Jul 2013 15:57:45 -0500 (CDT) Received: from [74.96.0.204] (port=56968 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UypqB-0000YR-In for sacm@ietf.org; Mon, 15 Jul 2013 15:57:51 -0500 Message-ID: <51E4624E.1060301@ieca.com> Date: Mon, 15 Jul 2013 16:57:50 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "sacm@ietf.org" References: <05BCCEB107AF88469B9F99783D47C1D67053C9@CISEXCHANGE1.msisac.org.local> <51D4F1D2.104@ieca.com> <05BCCEB107AF88469B9F99783D47C1D6705BF1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D671EAF4@CISEXCHANGE2.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D671EAF4@CISEXCHANGE2.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [74.96.0.204]:56968 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sacm] Berlin Meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:58:00 -0000 On 7/15/13 2:58 PM, Adam Montville wrote: > Stealing unabashedly from Brian Trammel's awesome example over on the MILE list... > > If you'd like a slot to talk at the SACM WG meeting in Berlin, please let us know at sacm-chairs@tools.ietf.org by end of day tomorrow! > > Topics for discussion include any document or topic covered by the recently approved charter (http://datatracker.ietf.org/wg/sacma/charter/). Priority will be given to working-group drafts and discussion of significant progress on previously presented documents. https://datatracker.ietf.org/wg/sacm/charter/ ;) > The meeting will take place in Tiergarten 1/2 on Friday, August 7, 11:20-12:20 CEST. > > Regards, > > Adam > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Adam Montville >> Sent: Friday, July 05, 2013 12:44 PM >> To: Sean Turner >> Cc: sacm@ietf.org >> Subject: Re: [sacm] Berlin Meeting >> >> NOTE: Please ignore the confidentiality notice at the bottom of this e-mail >> (and others) - it is added after I hit "send" and will be removed for IETF >> correspondence sometime in the next week or two. >> >> >>> -----Original Message----- >>> From: Sean Turner [mailto:turners@ieca.com] >>> Sent: Wednesday, July 03, 2013 8:53 PM >>> To: Adam Montville >>> Cc: sacm@ietf.org >>> Subject: Re: [sacm] Berlin Meeting >>> >>> On 7/3/13 12:51 PM, Adam Montville wrote: >>>> All: >>>> >>>> While we are not yet an official WG, I'd like to try to get our >>>> ducks in a row and progress as though we are a WG. I see some >>>> important dates have passed, and that some are upcoming >>>> (http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87). >>>> >>>> Notably: >>>> >>>> * 2013-07-05 (this Friday): Final agenda published >>>> * 2013-07-15: Internet Draft submission cut-off (for all drafts, >>>> including -00) >>>> * 2013-07-17: Draft WG agendas due by UTC 24:00 >>>> >>>> Given the milestones listed in our charter, it seems that our agenda >>>> should contain a healthy dose of use case an discussion and possibly >>>> some requirements discussion. >>>> >>>> Proposed (loose) Agenda: >>>> >>>> * Note well + agenda bashing >>>> * Charter and Milestone Review >>> >>> If it's chartered, then we can skip the charter review - it won't be >>> up for discussion because it'll be approved ;) >> >> Fair enough. Consider the two stricken from the proposed agenda. >> >>> >>> Normally, I'd suggest that sessions avoid summaries of the existing drafts. >>> Participants (used this word on purpose) should read the drafts >>> *before* they come to the session. I'd actually like presenters to >>> ask before they start who has read their draft ;) >>> >>> But, being that this would be the first ever session it's probably >>> okay to present what's in them. In the future, though we can push the >>> work forward and get to the point by only talking about open issues. >> >> I would encourage everyone to read ahead even for this first session and >> would anticipate review of these to be minimal and only for those who may >> not otherwise have heard about SACM work before Berlin. >> >>> >>>> * Use Case Discussion >>>> * Review of list >>>> * Presentation on latest draft (if update submitted) >>>> * Requirements discussion (time permitting) >>>> * Administravia (new-WG-related stuff) >>>> >>>> Are there relevant drafts that we want to discuss in Berlin and can >>>> be submitted before the 15 July deadline? At present, the following >>>> "related documents" show up on our Documents page >>>> (http://datatracker.ietf.org/wg/sacm/): >>>> >>>> * draft-booth-sacm-vuln-model-02 >>>> * draft-waltermire-sacm-architecture-00 >>>> * draft-waltermire-sacm-use-cases-04 >>> >>> Ideally, all of these drafts would be updated before the meeting >>> (hint) ;) >> >> I am unsure as to the state of the vulnerability model and the architecture >> document. I know that David Harrington has been working on trimming up >> the use case document. >> >> On that note, he has asked on several occasions for some more concrete use >> case examples, but I haven't really seen many provided. It would be good >> for this community to throw a few out there. Remember that use cases >> don't need to be comprehensive with respect to the requirements. They >> should exemplify. >> >> If there are use cases treated elsewhere, but to which access is limited (i.e. >> other organizations have published similar use cases but the documents >> aren't free), then I suggest that we summarize them here without simply >> referencing that work. >> >> >>> >>>> I'm looking forward to seeing you in Berlin! >>>> >>>> Regards, >>>> >>>> Adam >>>> >>>> >>>> This message and attachments may contain confidential information. >>>> If it appears that this message was sent to you by mistake, any >>>> retention, dissemination, distribution or copying of this message >>>> and attachments is strictly prohibited. Please notify the sender >>>> immediately and permanently delete the message and any attachments. >>>> >>>> >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>>> >>> >>> ... >> >> This message and attachments may contain confidential information. If it >> appears that this message was sent to you by mistake, any retention, >> dissemination, distribution or copying of this message and attachments is >> strictly prohibited. Please notify the sender immediately and permanently >> delete the message and any attachments. >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> >> ... > > This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. > From Adam.Montville@cisecurity.org Mon Jul 15 13:58:47 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9394E21E8147 for ; Mon, 15 Jul 2013 13:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.828 X-Spam-Level: X-Spam-Status: No, score=-2.828 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj4DB6NPY4Iw for ; Mon, 15 Jul 2013 13:58:38 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.207]) by ietfa.amsl.com (Postfix) with ESMTP id 25BBF21E8141 for ; Mon, 15 Jul 2013 13:58:38 -0700 (PDT) Received: from [216.82.241.211:10001] by server-15.bemta-8.messagelabs.com id 34/4B-14220-C7264E15; Mon, 15 Jul 2013 20:58:36 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-14.tower-85.messagelabs.com!1373921916!4217879!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 29690 invoked from network); 15 Jul 2013 20:58:36 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-14.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 15 Jul 2013 20:58:36 -0000 Received: from CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c]) by CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3%14]) with mapi id 14.02.0342.003; Mon, 15 Jul 2013 16:58:35 -0400 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Use Case Discussion: Vulnerable Endpoint Identification Thread-Index: Ac6Bnj6YfWpompnaTx+fZSs45OpjDg== Date: Mon, 15 Jul 2013 20:58:34 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D671F8C0@CISEXCHANGE2.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] Use Case Discussion: Vulnerable Endpoint Identification X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:58:47 -0000 And another... Use Case Name: Vulnerable Endpoint Identification Description:=20 In this use case a zero-day exploit has been discovered in the wild, which= is followed by a vulnerability identification entry and indicators of com= promise. A security engineer is responsible for that portion of a situati= onal response process that determines how exposed an organization is given= the new state of the world. Actors:=20 * System Administrator * Vulnerability Engineer * Security Engineer * System Owner * Information Owner Preconditions: * Organizational Security Policy exists * Security Policy specifies appropriate asset management capabilities (= i.e. categorization of endpoints) * Security Policy specifies endpoint configuration baseline for asset c= ategorization * Security Policy specifies configuration history retention requirement= s * The Organization associates owners who are individuals with endpoints= * The Organization associates organizational units with endpoints Postconditions: * Appropriate individuals in the organization have a clear understandin= g of the organization's exposure to and potential impact of the identified= 0-day * Appropriate individuals are taking action to further assess or mitiga= te the organization's posture regarding this 0-day Primary Path:=20 1. [External] 0-day exploit discovery [1] 2. Vulnerability Identification (Vulnerability ID) issued and associated= information published to an accessible content repository [2] 3. Indicators of Compromise (IoC) are identified and published to an acc= essible content repository [3] 4. Security engineer provides the Vulnerability ID to the Asset Manageme= nt System 5. The Asset Management System queries a configured Vulnerability Databa= se to obtain a list of affected endpoint classes [4] 6. The Asset Management System returns a list of specific endpoints that= can be classified according to the endpoint class list obtained in Step 5= , which either: 7.=20 a. Presently have affected software installed, or b. Have had affected software installed. 8. The Security Engineer exports the list of potentially affected endpoi= nts 9. The Security Engineer initiates a vulnerability scan based on IoCs, p= ublished vulnerability information, and the potentially affected endpoint = list. 10. The Vulnerability Scanner derives a set of vulnerability checks (i.e= . assessments) to perform on each listed endpoint based on information ass= ociated with the provided Vulnerability ID and IoCs. 11. The Vulnerability Scanner executes the check on each of the potentia= lly affected hosts which will return results effectively equivalent to "is= vulnerable," "is not vulnerable," "not checked," or "error" [5]. 12. The Security Engineer reviews the report then generates three additi= onal reports: 13.=20 a. The first report provides summary information for the Information S= ecurity Manager and/or higher levels of organizational management as appro= priate (i.e. Chief Information Security Officer) b. The second report is a list of all potentially effected endpoints f= or which no definitive answer could be obtained by the Vulnerability Scann= er (i.e. those endpoints for which neither an "is vulnerable" nor "is not = vulnerable" result is available) c. The third report is a list of all effected endpoints (i.e. those en= dpoints for which the checks resulted in "is vulnerable"). 14. The Security Engineer sends the first report to responsible Informat= ion Security Manager(s) using relationships tracked by the Asset Managemen= t System 15. The Security Engineer sends the second report to responsible Vulnera= bility Engineer(s) using relationships tracked by the Asset Management Sys= tem 16. The Security Engineer sends the third report to responsible System A= dministrator(s) using relationships tracked by the Asset Management System= 17. The Security Engineer issues an alert to affected System Owners, Inf= ormation Owners, and System Administrators using relationships tracked by = the Asset Management System A Note On Alternative Paths, Preconditions, and Postconditions: There are likely to be many points of optimization and optional paths pert= aining to this Use Case. For example, there may be greater degrees of int= eroperability between tools in a given organization, which would advance t= he state of automation in the "primary path" description herein provided. = =20 As with alternative paths, pre-/post-conditions can vary widely. Consider= that this description likely represents an organization on the mature sid= e of managing information security. Most organizations are unlikely to ha= ve separate roles for Security Engineer and Vulnerability Engineer, for ex= ample. =20 -------------- [1] The "[External]" notation is used to indicate that, while this step is= included in the primary path, it is out of the organization's locus of co= ntrol (i.e. the step is provided for additional context in the path throug= h the use case rather than being placed in the pre-conditions). [2] An "accessible" content repository may be internal or external. An in= ternal content repository may be a replication of an external content repo= sitory. [3] Often, an indicator of compromise involves assessing the state of some= observable object on the endpoint. For example, an indicator of compromi= se might be that a particular file path exists, a particular setting is co= nfigured in a specific manner, a set of settings are configured in a speci= fic manner, and/or specific log entries exist. [4] The Vulnerability Database may be combined with the content repository= , but is being called out separately here to assure that the reader knows = which type of data is being queried. [5] It is likely that additional result types will be required to convey d= ifferent reasons a result may not be available. This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From turners@ieca.com Mon Jul 15 14:15:02 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1A421E80C3 for ; Mon, 15 Jul 2013 14:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlDE1UzNT+Mx for ; Mon, 15 Jul 2013 14:14:55 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.82.4]) by ietfa.amsl.com (Postfix) with ESMTP id 728B721E8103 for ; Mon, 15 Jul 2013 14:14:52 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 0B77EB6C19A1B; Mon, 15 Jul 2013 16:14:39 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 4F4D3B6C197C6 for ; Mon, 15 Jul 2013 16:14:38 -0500 (CDT) Received: from [74.96.0.204] (port=57007 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Uyq6c-00064O-CB; Mon, 15 Jul 2013 16:14:50 -0500 Message-ID: <51E46649.20007@ieca.com> Date: Mon, 15 Jul 2013 17:14:49 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Harrington References: <20130711162658.7093.66495.idtracker@ietfa.amsl.com> <51DEDDE5.2070101@ieca.com> <012d01ce7f09$0fc8bc90$2f5a35b0$@comcast.net> In-Reply-To: <012d01ce7f09$0fc8bc90$2f5a35b0$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [74.96.0.204]:57007 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:15:02 -0000 On 7/12/13 10:06 AM, David Harrington wrote: > Hi, > > While I don't fully agree with the original architecture, I find it easier > to understand the intended functionality than in the alternate architecture. > > I understand the goal here of showing where the on-the-wire protocols > operate between entities. > The data flows in the Waltermire architecture do not clearly capture the > on-the-wire-ness of the flows, and what sits where in the network. > It might be helpful to use both diagrams, combined, to show the network > entities and on-the-wire data flows, and then show within the entity boxes, > the expected functionality provided by each. I could see using both some people like functional architectures some people like the more box + protocol architectures. Sometimes showing how one applies to other helps everybody get on the same page. That was my goal. Maybe it would have been better title additional architectural views. > The new architecture seems focused on a combination firewall/IDS box; that > seems like a particular use case. I figured (and stand ready to be corrected) that what we have is an asset, one or more evalators, one or more sensors, and ... > As you all know already, I think the scope of the sacm work needs to be > narrowed, but this might narrow it too much. > > (Sean, can you write up a firewall/IDS use case that I can put into the > use-cases document for this usage?) No worries I'll provide something. spt > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Sean Turner >> Sent: Thursday, July 11, 2013 12:32 PM >> To: sacm@ietf.org >> Subject: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture- >> 00.txt >> >> Food for thought. >> >> spt >> -------- Original Message -------- >> Subject: I-D Action: draft-handt-sacm-alternate-architecture-00.txt >> Date: Thu, 11 Jul 2013 09:26:58 -0700 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> >> >> Title : sacm: Alternate Architecture >> Author(s) : Russ Housley >> Sean Turner >> Filename : draft-handt-sacm-alternate-architecture-00.txt >> Pages : 5 >> Date : 2013-07-11 >> >> Abstract: >> This document proposes and alternate architecture for sacm (a >> proposed working group at the time this draft was submitted). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-handt-sacm-alternate-architecture >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-handt-sacm-alternate-architecture-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From turners@ieca.com Mon Jul 15 14:26:13 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570FF11E819D for ; Mon, 15 Jul 2013 14:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whxL9zKhslhg for ; Mon, 15 Jul 2013 14:26:08 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [64.5.52.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6F911E821A for ; Mon, 15 Jul 2013 14:25:55 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id E007FD40D8DF5; Mon, 15 Jul 2013 16:25:53 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id BB19ED40D8D65 for ; Mon, 15 Jul 2013 16:25:53 -0500 (CDT) Received: from [74.96.0.204] (port=57042 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UyqHJ-0002Z7-BK; Mon, 15 Jul 2013 16:25:53 -0500 Message-ID: <51E468E0.1@ieca.com> Date: Mon, 15 Jul 2013 17:25:52 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Hammer References: <20130711162658.7093.66495.idtracker@ietfa.amsl.com> <51DEDDE5.2070101@ieca.com> <012d01ce7f09$0fc8bc90$2f5a35b0$@comcast.net> <51E01C90.1040403@ThreatGuard.com> <013a01ce7f19$38d55ca0$aa8015e0$@comcast.net> <51E03F4D.1060302@ThreatGuard.com> <01bc01ce7fdb$f75dfb60$e619f220$@comcast.net> <51E1A660.4090308@ThreatGuard.com> <00C069FD01E0324C9FFCADF539701DB3BBC165E9@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC165E9@EX2K10MB1.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [74.96.0.204]:57042 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "Gunnar.Engelbach@ThreatGuard.com" , "dbharrington@comcast.net" , "ietfdbh@comcast.net" , "sacm@ietf.org" Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:26:13 -0000 On 7/15/13 12:03 PM, Michael Hammer wrote: > Re: alternate architecture. > > If you don't understand why using logical functional elements is better than > somebody's restrictive physical implementation, you will before long. > Having been through a couple SDO's where weeks were wasted while one vendor > tried to force others to adopt their implementation, I have no wish to > repeat that. Mike, Definitely stand ready to be corrected - seriously. I'm just looking at protocols and what flows where. > The big take-away I got from this alternate diagram was that you wanted the > evaluator to directly access the sensor (asset) and prohibit other means of > accessing the repository. That part, I have to admit wasn't fully baked. I could see that one might restrict access to the repository but with proper authentication/access control that's probably not necessary. In fact, it might be a bad idea because it might slow things down. > I have to wonder is that is as scalable as the original architecture. > Your simplified architecture would simply be: Sensor-Evaluator-Repository > Adding in the firewalls seems an unnecessary distraction. Or, are those > evaluators also? I was thinking the BPDs would evaluators/sensors. I don't think the evaluator would be looking at all the traffic as it flows out of the asset. There might be something on the asset that says hey this assets starting to act funny, but I would always think there would be a backstop at enterprise boundary that would also want to check that the asset is acting like it's supposed to be. > Also, I can guess what C is for, but that should be explained. Definitely need to explain that more and am hoping to have some more in the -03 draft. > Lastly, I don't see the need to insult the reader in section 2. Point taken. Apologies and it's removed. spt > Mike > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Gunnar Engelbach > Sent: Saturday, July 13, 2013 3:11 PM > To: ietfdbh > Cc: 'David Harrington'; 'Sean Turner'; sacm@ietf.org > Subject: Re: [sacm] Fwd: I-D Action: > draft-handt-sacm-alternate-architecture-00.txt > > > Sure. I won't be able to get to it right away, though. > > > > > On 7/13/2013 11:16 AM, ietfdbh wrote: >> Hi Gunnar, >> >> Thanks; that's much better. >> >> I think many people will have many different approaches to their >> architecture, but there will be quite a bit of commonality we can try >> to extract from them. >> Would you be willing to write some text quickly describing your >> collection, assessment, and management system, so we can add this to >> the use-cases document? >> The more we understand how people plan to gather and assess data, and >> turn the collected data into information that can then be used by >> humans, the better we can design a solution to meet the needs of multiple > approaches. >> >> >> I have some questions, so I can better understand your architecture, >> and to make sure I don't make any unwarranted assumptions. >> Working from EntitiesInUse, >> 1) Do these diagrams represent a system you have already implemented? >> 2) Has it been deployed in real-world environments? >> 3) Has it been deployed in enterprise environments? Service provider >> environment? >> 4) What are you using for protocols between the assessment server and >> the computer with agent? >> 5) What are you using for protocols between the assessment server and >> the computers without agents? >> 6) When the valuator gathers data from agent-less computers, does it >> convert the data into the same format that is used to gather data from >> a computer with agent? >> 7) It appears the controller always talks to the evaluator, never >> directly to the data collector. I realize this is an architectural >> drawing, and in actual coding a direct-connect might be used to >> performance improvements. Is the intent that the controller always goes > through the evaluator function? >> 8) when you have a subdomain, which entities in the super-domain >> communicate directly with entities in the subdomain? >> 8a) Is this a server-to-server sharing of information? >> 8b) Can server A directly access the evaluator function in the subdomain > B? >> or does it proxy requests for evaluations via subdomain server B > controller? >> 8c) Can server A directly query the data collector in subdomain B? >> does it us >> 9) Is it fair to assume that the Independent Workstation is equivalent >> to a subdomain, which just happens to support only the one workstation >> it is running on? >> >> More later ... >> >> Thanks, >> David Harrington >> ietfdbh@comcast.net >> +1-603-828-1401 >> >>> -----Original Message----- >>> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >>> Sent: Friday, July 12, 2013 1:39 PM >>> To: ietfdbh >>> Cc: 'David Harrington'; 'Sean Turner'; sacm@ietf.org >>> Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate- >>> architecture-00.txt >>> >>> >>> Try these. They're just not scalable. >>> >>> >>> >>> On 7/12/2013 12:02 PM, ietfdbh wrote: >>>> I can't read your svg files. >>>> >>>> David Harrington >>>> ietfdbh@comcast.net >>>> +1-603-828-1401 >>>> >>>>> -----Original Message----- >>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >>>>> Behalf Of Gunnar Engelbach >>>>> Sent: Friday, July 12, 2013 11:11 AM >>>>> To: David Harrington >>>>> Cc: 'Sean Turner'; sacm@ietf.org >>>>> Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate- >>>>> architecture-00.txt >>>>> >>>>> >>>>> I like the original. It's only concerned with the logical >>>>> components that >>>> make >>>>> up SACM -- the flexibility in how they are mixed and match to solve >>>>> real problems is one of its big strengths. >>>>> >>>>> But it's also apparent that this is not being effectively communicated. >>>>> >>>>> I sent some (lousy) drawings to the mailing list a while back >>>>> trying to >>>> capture >>>>> that flexibility -- attached here again for your >> amusement/befuddlement. >>>>> >>>>> >>>>> Do very specific use cases help people understand how these >>>>> standards can be applied? >>>>> >>>>> >>>>> --gun >>>>> >>>>> >>>>> >>>>> On 7/12/2013 10:06 AM, David Harrington wrote: >>>>>> Hi, >>>>>> >>>>>> While I don't fully agree with the original architecture, I find >>>>>> it >>>> easier >>>>>> to understand the intended functionality than in the alternate >>>> architecture. >>>>>> >>>>>> I understand the goal here of showing where the on-the-wire >>>>>> protocols operate between entities. >>>>>> The data flows in the Waltermire architecture do not clearly >>>>>> capture the on-the-wire-ness of the flows, and what sits where in the > network. >>>>>> It might be helpful to use both diagrams, combined, to show the >>>>>> network entities and on-the-wire data flows, and then show within >>>>>> the entity >>>>> boxes, >>>>>> the expected functionality provided by each. >>>>>> >>>>>> The new architecture seems focused on a combination firewall/IDS >>>>>> box; >>>>> that >>>>>> seems like a particular use case. >>>>>> As you all know already, I think the scope of the sacm work needs >>>>>> to be narrowed, but this might narrow it too much. >>>>>> >>>>>> (Sean, can you write up a firewall/IDS use case that I can put >>>>>> into the use-cases document for this usage?) >>>>>> >>>>>> David Harrington >>>>>> dbharrington@comcast.net >>>>>> +1-603-828-1401 >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >>>>>>> Behalf >>>>> Of >>>>>>> Sean Turner >>>>>>> Sent: Thursday, July 11, 2013 12:32 PM >>>>>>> To: sacm@ietf.org >>>>>>> Subject: [sacm] Fwd: I-D Action: >>>> draft-handt-sacm-alternate-architecture- >>>>>>> 00.txt >>>>>>> >>>>>>> Food for thought. >>>>>>> >>>>>>> spt >>>>>>> -------- Original Message -------- >>>>>>> Subject: I-D Action: >>>>>>> draft-handt-sacm-alternate-architecture-00.txt >>>>>>> Date: Thu, 11 Jul 2013 09:26:58 -0700 >>>>>>> From: internet-drafts@ietf.org >>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>> To: i-d-announce@ietf.org >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line >>>>>>> Internet-Drafts >>>>>> directories. >>>>>>> >>>>>>> >>>>>>> Title : sacm: Alternate Architecture >>>>>>> Author(s) : Russ Housley >>>>>>> Sean Turner >>>>>>> Filename : draft-handt-sacm-alternate-architecture-00.txt >>>>>>> Pages : 5 >>>>>>> Date : 2013-07-11 >>>>>>> >>>>>>> Abstract: >>>>>>> This document proposes and alternate architecture for sacm (a >>>>>>> proposed working group at the time this draft was submitted). >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> >>>> https://datatracker.ietf.org/doc/draft-handt-sacm-alternate-architec >>>> tu >>>> re >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-handt-sacm-alternate-architectur >>>>>>> e- >>>>>>> 00 >>>>>>> >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> I-D-Announce mailing list >>>>>>> I-D-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sacm mailing list >>>>>>> sacm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>> >>>>>> _______________________________________________ >>>>>> sacm mailing list >>>>>> sacm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>> >>>> >> > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From ietfdbh@comcast.net Mon Jul 15 14:59:41 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE18611E8217 for ; Mon, 15 Jul 2013 14:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.19 X-Spam-Level: X-Spam-Status: No, score=-100.19 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIP3dRaXNCoA for ; Mon, 15 Jul 2013 14:59:37 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 9924D21E816A for ; Mon, 15 Jul 2013 14:59:29 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta09.westchester.pa.mail.comcast.net with comcast id 0gtb1m0040cZkys59lzUen; Mon, 15 Jul 2013 21:59:28 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta10.westchester.pa.mail.comcast.net with comcast id 0lzU1m00L2yZEBF3WlzU97; Mon, 15 Jul 2013 21:59:28 +0000 From: "ietfdbh" To: "'Sean Turner'" References: <20130711162658.7093.66495.idtracker@ietfa.amsl.com> <51DEDDE5.2070101@ieca.com> <012d01ce7f09$0fc8bc90$2f5a35b0$@comcast.net> <51E46649.20007@ieca.com> In-Reply-To: <51E46649.20007@ieca.com> Date: Mon, 15 Jul 2013 17:58:46 -0400 Message-ID: <00fe01ce81a6$7b2a5850$717f08f0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHznD1rOpqPCNVF4Uo3EJCv58gmKAINk8g2AjtcOjgBf982kZjtwwLQ Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373925568; bh=3pF5r8DPTnDCbwPCJFRxebW46O26gQN0pxjLrKrecbw=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=oRWKKHY48uMRIt2v4myUzuJVyANtIdtp87K4KFIuiQPTk/KmJD9NyHH5YvzA/WZtf xSHQ+en5wFyVulMIyq1Gj5cHPI+xfswAVb2e/cRPrRiYWRqIJjvKe7c0kmhCz0bM2I bfLm0N3XOyeMGsx4NUge7EpUXO61gpfxYqLLKOf5T5KUtqNmz6TP7+4LlSI1uTaPBr EQOz+ZWjIiSHnNToXI+GTF02go64lQIknLud3MJ7t3/Pv4QJQVJIYs252jB7V79RNh rt01mKH+jL+fr0F2OogfvHgYuFGwhREIt6KqKyXsQQ2BCp7+T+bPxToJP7GymKaYK+ bHVBklvTg+YNg== Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:59:41 -0000 Hi, I like Gunnar's pictures better - not just cause they're prettier ;-) but because they mix the functional approach of the Waltermire architecture and the physical separation of the Turner/Housley architecture. s/ For those not in the know, it makes more sense to/Some people prefer to/ In the text it says " Lines marked A, flowing from the asset to the Evaluator," However, in figure 2, lines marked A are drawn as being bi-directional. I recommend removing the arrows going into the asset boxes. In the text, it says " Lines marked B, flowing from the client to the BPD", but there are no boxes labeled "client", and the lines marked B also appear to be bi-directional in the diagram. The lines marked B flow between the asset and the BPD. I guess I'm confused because you are mixing NEA terminology with the sacm terminology, and it's not clear to me where the NEA client server are in the diagram. The text says "The asset has an NEA client" and "the evaluator has an NEA server", but then you put lines marked B between the asset and the BPD. Then you go on to talk about doing NEA assessment before access, and monitoring after, which seems to be a whole different issue -temporal dataflows - than the actual boxes and protocols dataflows. This temporal dataflow seems better represented by a waltermire dataflow loop of DF2/DF1/DF2. The text says " Lines marked C, flowing from the BPD to the (Evaluator or Repository?) ensure that the BPDs know how the asset are supposed to be acting." So your combination of evaluator and repository also act as the policy server? In much of the discussions I have been in over the years about policy-based management and policy-based access control, we often talk about a policy decision point (PDP), where it is decided which policy applies to the asset, and a policy enforcement point (PEP), which enforces the policy. So if I were to use the terminology I am used to in describing your architecture, the evaluator/repository would be the PDP, and the BPD would be a PEP? [see RFC3198 " Terminology for Policy-Based Management"] David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Monday, July 15, 2013 5:15 PM > To: David Harrington > Cc: sacm@ietf.org > Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate- > architecture-00.txt > > On 7/12/13 10:06 AM, David Harrington wrote: > > Hi, > > > > While I don't fully agree with the original architecture, I find it > > easier to understand the intended functionality than in the alternate > architecture. > > > > I understand the goal here of showing where the on-the-wire protocols > > operate between entities. > > The data flows in the Waltermire architecture do not clearly capture > > the on-the-wire-ness of the flows, and what sits where in the network. > > It might be helpful to use both diagrams, combined, to show the > > network entities and on-the-wire data flows, and then show within the > > entity boxes, the expected functionality provided by each. > > I could see using both some people like functional architectures some people > like the more box + protocol architectures. Sometimes showing how one > applies to other helps everybody get on the same page. That was my goal. > Maybe it would have been better title additional architectural views. > > > The new architecture seems focused on a combination firewall/IDS box; > > that seems like a particular use case. > > I figured (and stand ready to be corrected) that what we have is an asset, > one or more evalators, one or more sensors, and ... > > > As you all know already, I think the scope of the sacm work needs to > > be narrowed, but this might narrow it too much. > > > > (Sean, can you write up a firewall/IDS use case that I can put into > > the use-cases document for this usage?) > > No worries I'll provide something. > > spt > > > David Harrington > > dbharrington@comcast.net > > +1-603-828-1401 > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > >> Of Sean Turner > >> Sent: Thursday, July 11, 2013 12:32 PM > >> To: sacm@ietf.org > >> Subject: [sacm] Fwd: I-D Action: > >> draft-handt-sacm-alternate-architecture- > >> 00.txt > >> > >> Food for thought. > >> > >> spt > >> -------- Original Message -------- > >> Subject: I-D Action: draft-handt-sacm-alternate-architecture-00.txt > >> Date: Thu, 11 Jul 2013 09:26:58 -0700 > >> From: internet-drafts@ietf.org > >> Reply-To: internet-drafts@ietf.org > >> To: i-d-announce@ietf.org > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >> > >> > >> Title : sacm: Alternate Architecture > >> Author(s) : Russ Housley > >> Sean Turner > >> Filename : draft-handt-sacm-alternate-architecture-00.txt > >> Pages : 5 > >> Date : 2013-07-11 > >> > >> Abstract: > >> This document proposes and alternate architecture for sacm (a > >> proposed working group at the time this draft was submitted). > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-handt-sacm-alternate-architect > >> ure > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-handt-sacm-alternate-architecture-00 > >> > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html or > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> > >> > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > From ietfdbh@comcast.net Mon Jul 15 15:35:06 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F48611E8167 for ; Mon, 15 Jul 2013 15:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.201 X-Spam-Level: X-Spam-Status: No, score=-100.201 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSdEZGvACGse for ; Mon, 15 Jul 2013 15:35:00 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 370C711E8243 for ; Mon, 15 Jul 2013 15:34:32 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta06.westchester.pa.mail.comcast.net with comcast id 0m7g1m0050cZkys56maWrr; Mon, 15 Jul 2013 22:34:30 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta10.westchester.pa.mail.comcast.net with comcast id 0maW1m00y2yZEBF3WmaWpe; Mon, 15 Jul 2013 22:34:30 +0000 From: "ietfdbh" To: Date: Mon, 15 Jul 2013 18:33:48 -0400 Message-ID: <00ff01ce81ab$602bb170$20831450$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6Bn+SjZJU/sGdFQne0jP4cUc2Tpg== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373927670; bh=+iF/oQwQh4vqdL+n8Qx+kJ4q1eDoDyoQXDe3aw2Onzw=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=s2TZ+3YC4uEOWnfp3F6vMJcJPUxf0SejJ9birAlrf15PKtkNEoh9Cig3KV8I1HEiF rfoGIaBYzNNt3DemYN8JrODFYpHG2kE0w9TjAM1mMoVzbtuplQ8KTIvAwe9STISlV1 HjVDjU2edGdCHCv9QaKhvpoiB0T516Vky8wATAGshBP9B6wHa2ZnCyE+8lwWw3txem +jCjf0LjGDHJuO7LEBuweZ6u2E1bXDf+90aX1upy+6G7Q5WMCQJDutGjKac5KiAuMJ BqZ6Is7W4ZPtEgy0eQJ+J6Lci1UNsOg5X9/iZMGo/1/eo9IyEaAgDLgKifzhjRJPS+ RlzfoS+jv0olA== Subject: [sacm] use cases versus requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:35:06 -0000 Hi, I looked up the BOF summaries from November and March. The summary from November says " The consensus was to start from requirements and then develop an architecture to explain how the use cases can be met. The group has a fairly good understanding of the problem space, but needs to document this and present it more clearly with the requirements, then the architecture. These steps need to happen to progress the work." Are we paying enough attention to the requirements stage? We don't have a requirements doc, and that might be helpful. The summary is unclear about which comes first - use cases or requirements. The -04- version of use cases had very high-level uses cases, and then defined concepts and requirements from the three abstract use cases, in a top-down approach that led to organizing the document by (theoretical) requirements and then finding use cases as supporting examples of the requirements. As I mentioned in my previous email, I think we should be working in the IETF bottom-up approach, looking at multiple real-world implementation/deployment use cases and deriving requirements from the aggregation of use cases. The -05- version of use cases shows the lack of clarity about how this should be approached (and the lack of time as the deadline approached). Comments welcome. David Harrington ietfdbh@comcast.net +1-603-828-1401 From dromasca@avaya.com Tue Jul 16 13:51:16 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A81E11E80F4 for ; Tue, 16 Jul 2013 13:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.825 X-Spam-Level: X-Spam-Status: No, score=-102.825 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-T3eBbvo00U for ; Tue, 16 Jul 2013 13:51:00 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF7C11E80F3 for ; Tue, 16 Jul 2013 13:50:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAB2x5VGHCzI1/2dsb2JhbABagmUhNE/BfIESFnSCJQEBAxIoUQEVFRRCJgEEGxqHbgELlRiEQpt7BI8ug0RtA54iiweDEoIo X-IronPort-AV: E=Sophos;i="4.89,679,1367985600"; d="scan'208";a="20316187" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 16 Jul 2013 16:50:54 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 16 Jul 2013 16:44:52 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Tue, 16 Jul 2013 16:50:53 -0400 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: SACM @ IETF-87 - draft agenda Thread-Index: Ac6CZb0fh6Yd4RHIQSSBt5zyPKQO9g== Date: Tue, 16 Jul 2013 20:50:52 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128742DC@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] SACM @ IETF-87 - draft agenda X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 20:51:17 -0000 We have posted the draft agenda for the first SACM WG meeting at https://da= tatracker.ietf.org/meeting/87/agenda/sacm/.=20 Comments and last minute requests for the agenda are welcome. The agenda al= so includes a reading list which will help everybody come prepared to the m= eeting. Although this is the first WG meeting we want to spend as little ti= me as possible with presentations and use at best the expensive face-to-fac= e meeting time for discussions about how to progress the items on the chart= er. Priority will be given to the use cases which drive the requirements, f= ramework, and other items on the agenda and working group path.=20 See you all in Berlin.=20 Regards, Adam and Dan From dromasca@avaya.com Tue Jul 16 13:59:45 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F8D21F93D4 for ; Tue, 16 Jul 2013 13:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.327 X-Spam-Level: X-Spam-Status: No, score=-103.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkMS1PfkI32w for ; Tue, 16 Jul 2013 13:59:39 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id A2A3921F99F7 for ; Tue, 16 Jul 2013 13:59:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAOuy5VGHCzI1/2dsb2JhbABagmUhgQPBfIESFnSCJQEBAxIoUQEVFRRCJgEEGxqHbgGVHIRCm32OLYEBg0RtA54iiweDEoFxNw X-IronPort-AV: E=Sophos;i="4.89,679,1367985600"; d="scan'208";a="16749915" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Jul 2013 16:59:22 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 16 Jul 2013 16:53:19 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Tue, 16 Jul 2013 16:59:19 -0400 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: SACM - welcome breakfast for first-time participants Thread-Index: Ac6CZwI3FGgA+N1OTWKNVX7x/ZHKoA== Date: Tue, 16 Jul 2013 20:59:18 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12874319@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] SACM - welcome breakfast for first-time participants X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 20:59:45 -0000 Hi,=20 Some of the attendees in the SACM WG meeting in Berlin will be first time p= articipants in the IETF. We would like to extend them a warm welcome and su= ggest that we meet for breakfast on Thursday 8/1, at 8AM. It would be a goo= d opportunity for us (SACM WG chairs) to meet and know you, hear from you w= hat are the your areas of interest and expectations from the IETF and from = the SACM WG. We will be glad to answer any questions related to the WG and = to the IETF.=20 Old timers who are interested to meet with the first-time participants are = also welcome.=20 The exact location of the breakfast gathering will be announced in a mail t= o the list the day before the meeting.=20 See you all in Berlin.=20 Regards, Adam and Dan From dromasca@avaya.com Tue Jul 16 14:15:26 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A7321F9FFC for ; Tue, 16 Jul 2013 14:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.851 X-Spam-Level: X-Spam-Status: No, score=-102.851 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FC7aaXNj2mDi for ; Tue, 16 Jul 2013 14:15:20 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id C86AE21F9F6E for ; Tue, 16 Jul 2013 14:15:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAHC35VGHCzI1/2dsb2JhbABagmUhNE/BfYESFnSCIwEBAQEDAQEBDyg0FwQCAQgNBAQBAQsUCQcnCxQJCAEBBBMIGoduAQuZU5tlEwSOLYEBOAaDBm0DniKLB4MSgXE3 X-IronPort-AV: E=Sophos;i="4.89,679,1367985600"; d="scan'208";a="20319740" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 16 Jul 2013 17:14:55 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 16 Jul 2013 17:08:54 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Tue, 16 Jul 2013 17:14:54 -0400 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: SACM - welcome breakfast for first-time participants Thread-Index: Ac6CZwI3FGgA+N1OTWKNVX7x/ZHKoAAAnrQg Date: Tue, 16 Jul 2013 21:14:53 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12874359@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA12874319@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12874319@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM - welcome breakfast for first-time participants X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 21:15:26 -0000 We forgot to mention - folks interested to attend, please send us a message= . > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Tuesday, July 16, 2013 11:59 PM > To: sacm@ietf.org > Subject: [sacm] SACM - welcome breakfast for first-time participants >=20 > Hi, >=20 > Some of the attendees in the SACM WG meeting in Berlin will be first > time participants in the IETF. We would like to extend them a warm > welcome and suggest that we meet for breakfast on Thursday 8/1, at 8AM. > It would be a good opportunity for us (SACM WG chairs) to meet and know > you, hear from you what are the your areas of interest and expectations > from the IETF and from the SACM WG. We will be glad to answer any > questions related to the WG and to the IETF. >=20 > Old timers who are interested to meet with the first-time participants > are also welcome. >=20 > The exact location of the breakfast gathering will be announced in a > mail to the list the day before the meeting. >=20 > See you all in Berlin. >=20 > Regards, >=20 > Adam and Dan >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From Adam.Montville@cisecurity.org Thu Jul 18 08:49:25 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC57111E8171 for ; Thu, 18 Jul 2013 08:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.813 X-Spam-Level: X-Spam-Status: No, score=-2.813 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjOrr92hAnmS for ; Thu, 18 Jul 2013 08:49:21 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1590611E8162 for ; Thu, 18 Jul 2013 08:49:21 -0700 (PDT) Received: from [216.82.250.179:54638] by server-7.bemta-12.messagelabs.com id 90/2E-12348-F7E08E15; Thu, 18 Jul 2013 15:49:19 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-6.tower-210.messagelabs.com!1374162558!7560218!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 11991 invoked from network); 18 Jul 2013 15:49:19 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-6.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 18 Jul 2013 15:49:19 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 18 Jul 2013 11:49:14 -0400 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Appropriate Level for Use Cases Thread-Index: Ac6Dy7kkNLNKfcfOQDiaN5MVEkQ9HQ== Date: Thu, 18 Jul 2013 15:49:14 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6732431@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] Appropriate Level for Use Cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:49:25 -0000 Greetings all, I'd like to start a discussion here on what we, as a community, believe is= the appropriate descriptive level for what we are calling a "use case." = >From my background - biased by computer science, electrical and computer e= ngineering, and years of working with software development groups - a "use= case" is something that looks a lot like the two I sent earlier this week= ([1] and [2]). =20 At that level of detail, we have a better understanding of who relying par= ties are on the capability being described and what pieces of data and/or = pre-requisites are otherwise needed for the capability to be successful, w= hich is one of the reasons I like that level of description. =20 To me, it makes sense to get what we are calling use cases to an appropria= te level of detail to act as representatives of requirements. Requirement= s can be derived from the use cases, and from non-use-case sources. Then,= once requirements are better known, we can move on to architectures. Additionally, David Harrington has asked whether we're paying enough atten= tion to requirements [3], and I agree that we may not be at this time. Bu= t, I would also ask whether we ought to be just yet, at least until a good= set of appropriately described use cases exists. =20 All that said, I think much of this work can be done in parallel or in qui= ck iterations, but I also think that, if parallel/iterative development of= use cases, requirements, and architecture is going to be successful, we n= eed to discuss more here - on the list. :-) That's my take on it anyway. I guess the bottom line is that we have an O= ctober milestone to have an initial I-D submission to IESG for the archite= cture, and there are two general steps that need to complete before we ca= n feel comfortable with the architectural direction - use cases and requir= ements. Thoughts? Adam [1] http://www.ietf.org/mail-archive/web/sacm/current/msg01282.html=20 [2] http://www.ietf.org/mail-archive/web/sacm/current/msg01284.html=20 [3] http://www.ietf.org/mail-archive/web/sacm/current/msg01288.html=20 This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From prvs=091148eb58=rainer.enders@ncp-e.com Thu Jul 18 09:08:09 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B69A21F9F00 for ; Thu, 18 Jul 2013 09:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WI9qlxQvsvw6 for ; Thu, 18 Jul 2013 09:07:48 -0700 (PDT) Received: from mail.ncp.de (mail.ncp.de [62.153.165.35]) by ietfa.amsl.com (Postfix) with ESMTP id E31A311E8175 for ; Thu, 18 Jul 2013 09:07:43 -0700 (PDT) Received: from viruswall.ncp.de (viruswall.ncp.de [62.153.165.41]) by mail.ncp.de (Postfix) with ESMTPS id 0BE3B3AE7E0 for ; Thu, 18 Jul 2013 18:17:23 +0200 (CEST) Received: from [172.16.11.201] (port=36946 helo=ex07.ncp.local) by viruswall.ncp.de with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) (envelope-from ) id 1Uzqjo-0005PL-1F; Thu, 18 Jul 2013 18:07:28 +0200 Received: from ex07.ncp.local ([172.16.11.201]) by ex07.ncp.local ([172.16.11.201]) with mapi; Thu, 18 Jul 2013 18:07:28 +0200 X-CTCH-RefID: str=0001.0A0C0205.51E812C0.00C1,ss=1,re=0.000,fgs=0 From: Rainer Enders To: Adam Montville , "sacm@ietf.org" Date: Thu, 18 Jul 2013 18:07:17 +0200 Thread-Topic: [sacm] Appropriate Level for Use Cases Thread-Index: Ac6D0OWW8X4eZN+GSCGDASACpnFNgg== Message-ID: In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6732431@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Appropriate Level for Use Cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 16:08:09 -0000 Hello Adam, I agree with your thinking and I found your presentation of use cases refreshing and promising. With my background as a research engineer it appears, at least to me, that at times researchers and scientists tend to overanalyze problems. Having said that I often look at use cases and wonder if the work that they are intending to support is worth the effort because they do not offer significant substantiation and differentiation. We have a large number of standards and if you have a good knowledge base of such standards you often can imagine simplistic use cases could easily be addressed by existing standards and wonder what the value add is of the work that is being proposed. So in that sense use cases are a critical element. Another related thought I have on this subject is that the lack of broad industry participation in standardization efforts is a limiting factor in the sense that there is a difference between practical issues and theoretical issues. Maybe a way to address this is to take discussions on standardization efforts into more public forums (trade shows, industry events)? Regards, Rainer On 7/18/13 8:49 AM, "Adam Montville" wrote: >Greetings all, > >I'd like to start a discussion here on what we, as a community, believe >is the appropriate descriptive level for what we are calling a "use >case." From my background - biased by computer science, electrical and >computer engineering, and years of working with software development >groups - a "use case" is something that looks a lot like the two I sent >earlier this week ([1] and [2]). > >At that level of detail, we have a better understanding of who relying >parties are on the capability being described and what pieces of data >and/or pre-requisites are otherwise needed for the capability to be >successful, which is one of the reasons I like that level of description. >=20 > >To me, it makes sense to get what we are calling use cases to an >appropriate level of detail to act as representatives of requirements. >Requirements can be derived from the use cases, and from non-use-case >sources. Then, once requirements are better known, we can move on to >architectures. > >Additionally, David Harrington has asked whether we're paying enough >attention to requirements [3], and I agree that we may not be at this >time. But, I would also ask whether we ought to be just yet, at least >until a good set of appropriately described use cases exists. > >All that said, I think much of this work can be done in parallel or in >quick iterations, but I also think that, if parallel/iterative >development of use cases, requirements, and architecture is going to be >successful, we need to discuss more here - on the list. :-) > >That's my take on it anyway. I guess the bottom line is that we have an >October milestone to have an initial I-D submission to IESG for the >architecture, and there are two general steps that need to complete >before we can feel comfortable with the architectural direction - use >cases and requirements. > >Thoughts? > >Adam > > >[1] http://www.ietf.org/mail-archive/web/sacm/current/msg01282.html >[2] http://www.ietf.org/mail-archive/web/sacm/current/msg01284.html >[3] http://www.ietf.org/mail-archive/web/sacm/current/msg01288.html > > >This message and attachments may contain confidential information. If it >appears that this message was sent to you by mistake, any retention, >dissemination, distribution or copying of this message and attachments is >strictly prohibited. Please notify the sender immediately and >permanently delete the message and any attachments. >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From Adam.Montville@cisecurity.org Thu Jul 18 10:28:53 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D8B21F8C4C for ; Thu, 18 Jul 2013 10:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xb25oJWiV+xh for ; Thu, 18 Jul 2013 10:28:48 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.194]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCE121F9B7F for ; Thu, 18 Jul 2013 10:28:14 -0700 (PDT) Received: from [216.82.241.211:49073] by server-2.bemta-8.messagelabs.com id 50/DE-07208-7A528E15; Thu, 18 Jul 2013 17:28:07 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-5.tower-85.messagelabs.com!1374168487!41366317!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 3856 invoked from network); 18 Jul 2013 17:28:07 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-5.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 18 Jul 2013 17:28:07 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 18 Jul 2013 13:28:03 -0400 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Meetecho support Thread-Index: AQHOg7eKN4tdu2rkTkKX1enG5VOIt5lqsXVA Date: Thu, 18 Jul 2013 17:28:03 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6733680@CISEXCHANGE1.msisac.org.local> References: <51E7E821.2050802@meetecho.com> In-Reply-To: <51E7E821.2050802@meetecho.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] FW: Meetecho support X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 17:28:53 -0000 FYI. I don't believe we have anyone requesting or planning for remote presentat= ion, but if we do, please speak up :-) Regards, Adam > -----Original Message----- > From: info@meetecho.com [mailto:info@meetecho.com] > Sent: Thursday, July 18, 2013 6:06 AM > Subject: Meetecho support >=20 > Dear chair(s), >=20 > we confirm Meetecho support for your WG meeting session at IETF-87. > The agenda of supported sessions is available at > http://ietf87.conf.meetecho.com. >=20 > If you plan to have remote presenters, you're kindly requested to inform= us > in proper advance, since this needs special set-up. >=20 > *The deadline for requesting remote presentation support is July 24.* >=20 > Thanks, > the Meetecho team >=20 > -- > Meetecho s.r.l. > www.meetecho.com >=20 > ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From Kent_Landfield@mcafee.com Thu Jul 18 10:32:22 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328DC11E81B1 for ; Thu, 18 Jul 2013 10:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVEphr6Bu5pr for ; Thu, 18 Jul 2013 10:32:18 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id CEC3A11E81A1 for ; Thu, 18 Jul 2013 10:32:16 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 1ac3_53a8_6069a294_6809_4939_8013_89783fec7e7c; Thu, 18 Jul 2013 12:32:16 -0500 Received: from MIVEXAMER2N3.corp.nai.org (10.48.48.23) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 18 Jul 2013 13:31:21 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXAMER2N3.corp.nai.org ([169.254.3.200]) with mapi id 14.02.0328.009; Thu, 18 Jul 2013 13:31:21 -0400 From: To: , Thread-Topic: [sacm] FW: Meetecho support Thread-Index: AQHOg7eKN4tdu2rkTkKX1enG5VOIt5lqsXVA///vkwA= Date: Thu, 18 Jul 2013 17:31:21 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF2D88C4@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6733680@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.48.48.242] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF2D88C4MIVEXAMER1N1corpn_" MIME-Version: 1.0 Subject: Re: [sacm] FW: Meetecho support X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 17:32:22 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF2D88C4MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, we should always have Meetecho support. I will not be able to make it= do to a family illness and was planning on attending remotely. Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Thursday, July 18, 2013 12:28 PM To: "sacm@ietf.org" > Subject: [sacm] FW: Meetecho support FYI. I don't believe we have anyone requesting or planning for remote presentati= on, but if we do, please speak up :-) Regards, Adam -----Original Message----- From: info@meetecho.com [mailto:info@meetecho.com= ] Sent: Thursday, July 18, 2013 6:06 AM Subject: Meetecho support Dear chair(s), we confirm Meetecho support for your WG meeting session at IETF-87. The agenda of supported sessions is available at http://ietf87.conf.meetecho.com. If you plan to have remote presenters, you're kindly requested to inform us in proper advance, since this needs special set-up. *The deadline for requesting remote presentation support is July 24.* Thanks, the Meetecho team -- Meetecho s.r.l. www.meetecho.com ... This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissemi= nation, distribution or copying of this message and attachments is strictly= prohibited. Please notify the sender immediately and permanently delete t= he message and any attachments. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_3CBA099FBA0AB843895D72474092B8CF2D88C4MIVEXAMER1N1corpn_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Yes, we should always have Meetecho support.  I will not be able = to make it do to a family illness and was planning on attending remotely.

Thanks.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: Adam Montville <Adam.Montville@cisecurity.org>= ;
Date: Thursday, July 18, 2013 12:28= PM
To: "sacm@ietf.org" <sacm@i= etf.org>
Subject: [sacm] FW: Meetecho suppor= t

FYI.

I don't believe we have anyone requesting or planning for remote prese= ntation, but if we do, please speak up :-)

Regards,

Adam


-----Original Message-----
Sent: Thursday, July 18, 2013 6:06 AM
Subject: Meetecho support
Dear chair(s),
we confirm Meetecho support for your WG meeting session at IETF-87.
The agenda of supported sessions is available at
If you plan to have remote presenters, you're kindly requested to info= rm us
in proper advance, since this needs special set-up.
*The deadline for requesting remote presentation support is July 24.*<= /div>
Thanks,
the Meetecho team
--
Meetecho s.r.l.
www.meetecho.com
...

This message and attachments may contain confidential information.&nbs= p; If it appears that this message was sent to you by mistake, any ret= ention, dissemination, distribution or copying of this message and attachme= nts is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachme= nts.
_______________________________________________
sacm mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF2D88C4MIVEXAMER1N1corpn_-- From Kent_Landfield@mcafee.com Thu Jul 18 10:33:26 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1702711E81B1 for ; Thu, 18 Jul 2013 10:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEgHrZvUG79I for ; Thu, 18 Jul 2013 10:33:22 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 01B1511E81A0 for ; Thu, 18 Jul 2013 10:33:21 -0700 (PDT) Received: from MIVEXAMER1N1.corp.nai.org (unknown [10.48.48.11]) by MIVWSMAILOUT1.mcafee.com with smtp id 1ac3_53c0_6ac57f5f_2441_4eea_8ae4_de5aaf6437ed; Thu, 18 Jul 2013 12:33:21 -0500 Received: from MIVEXAMER2N3.corp.nai.org (10.48.48.23) by MIVEXAMER1N1.corp.nai.org (10.48.48.11) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 18 Jul 2013 13:32:40 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXAMER2N3.corp.nai.org ([169.254.3.200]) with mapi id 14.02.0328.009; Thu, 18 Jul 2013 13:32:40 -0400 From: To: , Thread-Topic: [sacm] FW: Meetecho support Thread-Index: AQHOg7eKN4tdu2rkTkKX1enG5VOIt5lqsXVA///vkwCAAABdAA== Date: Thu, 18 Jul 2013 17:32:39 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF2D893A@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF2D88C4@MIVEXAMER1N1.corp.nai.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.48.48.242] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF2D893AMIVEXAMER1N1corpn_" MIME-Version: 1.0 Subject: Re: [sacm] FW: Meetecho support X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 17:33:26 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF2D893AMIVEXAMER1N1corpn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, maybe I misunderstood. I will not be presenting remotely but would = like to have the ability to participate via Meetecho. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Kent Landfield > Date: Thursday, July 18, 2013 12:31 PM To: Adam Montville >, "sacm@ietf.org" > Subject: Re: [sacm] FW: Meetecho support Yes, we should always have Meetecho support. I will not be able to make it= do to a family illness and was planning on attending remotely. Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Thursday, July 18, 2013 12:28 PM To: "sacm@ietf.org" > Subject: [sacm] FW: Meetecho support FYI. I don't believe we have anyone requesting or planning for remote presentati= on, but if we do, please speak up :-) Regards, Adam -----Original Message----- From: info@meetecho.com [mailto:info@meetecho.com= ] Sent: Thursday, July 18, 2013 6:06 AM Subject: Meetecho support Dear chair(s), we confirm Meetecho support for your WG meeting session at IETF-87. The agenda of supported sessions is available at http://ietf87.conf.meetecho.com. If you plan to have remote presenters, you're kindly requested to inform us in proper advance, since this needs special set-up. *The deadline for requesting remote presentation support is July 24.* Thanks, the Meetecho team -- Meetecho s.r.l. www.meetecho.com ... This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissemi= nation, distribution or copying of this message and attachments is strictly= prohibited. Please notify the sender immediately and permanently delete t= he message and any attachments. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_3CBA099FBA0AB843895D72474092B8CF2D893AMIVEXAMER1N1corpn_ Content-Type: text/html; charset="us-ascii" Content-ID: <764E9BE642F8334C8C90517A35758105@McAfee.com> Content-Transfer-Encoding: quoted-printable
Sorry, maybe I misunderstood.  I will not be presenting remotely = but would like to have the ability to participate via Meetecho.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: <Landfield>, Kent Landf= ield <Kent_Landfield@McAfee= .com>
Date: Thursday, July 18, 2013 12:31= PM
To: Adam Montville <Adam.Montville@cisecurity.org>,= "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] FW: Meetecho su= pport

Yes, we should always have Meetecho support.  I will not be able = to make it do to a family illness and was planning on attending remotely.

Thanks.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: Adam Montville <Adam.Montville@cisecurity.org>= ;
Date: Thursday, July 18, 2013 12:28= PM
To: "sacm@ietf.org" <sacm@i= etf.org>
Subject: [sacm] FW: Meetecho suppor= t

FYI.

I don't believe we have anyone requesting or planning for remote prese= ntation, but if we do, please speak up :-)

Regards,

Adam


-----Original Message-----
Sent: Thursday, July 18, 2013 6:06 AM
Subject: Meetecho support
Dear chair(s),
we confirm Meetecho support for your WG meeting session at IETF-87.
The agenda of supported sessions is available at
If you plan to have remote presenters, you're kindly requested to info= rm us
in proper advance, since this needs special set-up.
*The deadline for requesting remote presentation support is July 24.*<= /div>
Thanks,
the Meetecho team
--
Meetecho s.r.l.
www.meetecho.com
...

This message and attachments may contain confidential information.&nbs= p; If it appears that this message was sent to you by mistake, any ret= ention, dissemination, distribution or copying of this message and attachme= nts is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachme= nts.
_______________________________________________
sacm mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF2D893AMIVEXAMER1N1corpn_-- From Adam.Montville@cisecurity.org Thu Jul 18 11:25:37 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EF911E81C9 for ; Thu, 18 Jul 2013 11:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.784 X-Spam-Level: X-Spam-Status: No, score=-2.784 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGBJmGSk0yzw for ; Thu, 18 Jul 2013 11:25:33 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id C06BF11E81C5 for ; Thu, 18 Jul 2013 11:25:32 -0700 (PDT) Received: from [216.82.250.179:31500] by server-4.bemta-12.messagelabs.com id C4/9E-18579-91338E15; Thu, 18 Jul 2013 18:25:29 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-4.tower-210.messagelabs.com!1374171921!7584759!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 8977 invoked from network); 18 Jul 2013 18:25:21 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-4.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 18 Jul 2013 18:25:21 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 18 Jul 2013 14:25:16 -0400 From: Adam Montville To: "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Thread-Topic: [sacm] FW: Meetecho support Thread-Index: AQHOg7eKN4tdu2rkTkKX1enG5VOIt5lqsXVA///vkwCAAABdAIAAH/1A Date: Thu, 18 Jul 2013 18:25:16 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D67337B2@CISEXCHANGE1.msisac.org.local> References: <3CBA099FBA0AB843895D72474092B8CF2D88C4@MIVEXAMER1N1.corp.nai.org> <3CBA099FBA0AB843895D72474092B8CF2D893A@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF2D893A@MIVEXAMER1N1.corp.nai.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D67337B2CISEXCHANGE1msisa_" MIME-Version: 1.0 Subject: Re: [sacm] FW: Meetecho support X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 18:25:37 -0000 --_000_05BCCEB107AF88469B9F99783D47C1D67337B2CISEXCHANGE1msisa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Understood, Kent. Best wishes to you and your family. From: Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com] Sent: Thursday, July 18, 2013 10:33 AM To: Adam Montville; sacm@ietf.org Subject: Re: [sacm] FW: Meetecho support Sorry, maybe I misunderstood. I will not be presenting remotely but would= like to have the ability to participate via Meetecho. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Kent Landfield > Date: Thursday, July 18, 2013 12:31 PM To: Adam Montville >, "sacm@ietf.org" > Subject: Re: [sacm] FW: Meetecho support Yes, we should always have Meetecho support. I will not be able to make i= t do to a family illness and was planning on attending remotely. Thanks. Kent Landfield McAfee | An=20Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Thursday, July 18, 2013 12:28 PM To: "sacm@ietf.org" > Subject: [sacm] FW: Meetecho support FYI. I don't believe we have anyone requesting or planning for remote presentat= ion, but if we do, please speak up :-) Regards, Adam -----Original Message----- From: info@meetecho.com [mailto:info@meetecho.co= m] Sent: Thursday, July 18, 2013 6:06 AM Subject: Meetecho support Dear chair(s), we confirm Meetecho support for your WG meeting session at IETF-87. The agenda of supported sessions is available at http://ietf87.conf.meetecho.com. If you plan to have remote presenters, you're kindly requested to inform u= s in proper advance, since this needs special set-up. *The deadline for requesting remote presentation support is July 24.* Thanks, the Meetecho team -- Meetecho s.r.l. www.meetecho.com ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. --_000_05BCCEB107AF88469B9F99783D47C1D67337B2CISEXCHANGE1msisa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Understood, Kent. = Best wishes to you and your family.

 

From: Kent_= Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com]
Sent: Thursday, July 18, 2013 10:33 AM
To: Adam Montville; sacm@ietf.org
Subject: Re: [sacm] FW: Meetecho support

 

Sorry, maybe I misunder= stood.  I will not be presenting remotely but would like to have the = ability to participate via Meetecho.

 

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 <= br> Mobile: +1.817.637.8026
Web: www.mcafee.com

 

 

Yes, we should always h= ave Meetecho support.  I will not be able to make it do to a family i= llness and was planning on attending remotely.

 

Thanks.

 

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 <= br> Mobile: +1.817.637.8026
Web: www.mcafee.com

 

From: Adam Montville <Adam.Montville@cisecurity.org>
Date: Thursday, July 18, 2013 12:28 PM
To: "sacm@ietf.org" = <sacm@ietf.org>
Subject: [sacm] FW: Meetecho support

 

FYI.<= /p>

 

I don't believe we have= anyone requesting or planning for remote presentation, but if we do, plea= se speak up :-)

 

Regards,

 

Adam<= /p>

 

 

-----Original Message--= ---

Sent: Thursday, July 18= , 2013 6:06 AM

Subject: Meetecho suppo= rt

Dear chair(s),

we confirm Meetecho sup= port for your WG meeting session at IETF-87.

The agenda of supported= sessions is available at

If you plan to have rem= ote presenters, you're kindly requested to inform us

=

in proper advance, sinc= e this needs special set-up.

*The deadline for reque= sting remote presentation support is July 24.*

Thanks,

the Meetecho team<= /o:p>

--

Meetecho s.r.l.

...

 

This message and attach= ments may contain confidential information.  If it appears that = this message was sent to you by mistake, any retention, dissemination, dis= tribution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately a= nd permanently delete the=20message and any attachments.=

_______________________= ________________________

sacm mailing list<= /o:p>

 


...


This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments.
--_000_05BCCEB107AF88469B9F99783D47C1D67337B2CISEXCHANGE1msisa_-- From gunnar.engelbach@threatguard.com Thu Jul 18 14:55:23 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB57221E8110 for ; Thu, 18 Jul 2013 14:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pttBzVc1jEu3 for ; Thu, 18 Jul 2013 14:55:19 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5205121E808C for ; Thu, 18 Jul 2013 14:55:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=V2kzTwYSMsbLlv3j05J7q+miWj9PeA3oXwNJu78nCVqo5vW/74ANoMyPnogyli8qo329fR8aY6Z/DRMLaaTjZz4oJkhSal1q7xOVbcedRYk3lakp3w4VqEKe+VvB3eWk; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 26535 invoked from network); 18 Jul 2013 14:53:23 -0700 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Jul 2013 14:53:23 -0700 Message-ID: <51E86452.90505@ThreatGuard.com> Date: Thu, 18 Jul 2013 17:55:30 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ietfdbh References: <20130711162658.7093.66495.idtracker@ietfa.amsl.com> <51DEDDE5.2070101@ieca.com> <012d01ce7f09$0fc8bc90$2f5a35b0$@comcast.net> <51E01C90.1040403@ThreatGuard.com> <013a01ce7f19$38d55ca0$aa8015e0$@comcast.net> <51E03F4D.1060302@ThreatGuard.com> <01bc01ce7fdb$f75dfb60$e619f220$@comcast.net> In-Reply-To: <01bc01ce7fdb$f75dfb60$e619f220$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'David Harrington' , 'Sean Turner' , sacm@ietf.org Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 21:55:24 -0000 David, et al, Text to accompany the pretty pictures I sent out last week. I'm not even going to try turning them into ASCII diagrams right now. If you'd like more information on the alternate architecture I originally drew these to illustrate you can go back to these archive messages: http://www.ietf.org/mail-archive/web/sacm/current/msg00884.html http://www.ietf.org/mail-archive/web/sacm/current/msg00947.html but that's not really the focus I have at the moment. Plus, answers to your other questions inline below. ---------------------=========================--------------------- 1) BasicEntities: "Entities" are logical constructs that are defined by which of the SACM standards they implement. In this first diagram these entities have been broken out to their most primitive. The intention of this diagram is as a starting point in illustrating the flexibility of the architecture and not as a complete representation. For that reason the Content Repository entity has not been included, but the interaction points of the Results View and Controller Front-End (not currently covered by the SACM working group) have been added. This architecture and its data flows also differ from the waltermire-sacm-architecture. The purpose at this time is not to discuss the merits of either approach, but to show how the concept of these proposed standards gives the flexibility to solve a wide variety of real-world situations while also reaping the benefits of standardization. Taking the entity "Data Collector" as an example, what qualifies it as a Data Collector is the ability to receive requests to collect data and return the collected data where the request and response are done via the standards proposed by this working group. The Data Collector may have more capabilities, but without covering these at a minimum it would not qualify as a Data Collector. Similarly, the Evaluator receives/responds to marching orders from the controller, sends/receives data collection requests and (optional dotted line) interacts with the data store. ---------------=========================--------------- 2) Basic Grouped Entities The primitive entities from (1) have been grouped into two physical implementations. The Management System has the user interface (Results Viewer, Controller Front-End), the Controller, and the Results Data Store. It exposes no interfaces, but is able to query any number of Evaluators to performs assessments. The Collector/Processor has both the Data Collector and the Evaluator. The only line of communication exposed by the Collector/Processor is Evaluator requests/responses, so to an external entity it only qualifies as an Evaluator. However, it also has its own integrated Data Collector that operates at the local level of scope. This, then, is a smart agent that distributes the evaluation process. It could also easily expose the Data Collector interfaces making it accessible to other Evaluators. If the Collector/Process does not expose the Data Collector interfaces it could actually do collection via a proprietary means. This type of hybrid my be necessary to address cases that fall outside of these standards, but it can also be used to give access to existing proprietary solutions. ---------------=========================--------------- 3) Entities in Use Each of the green boxes represents a single computer, with the necessary interfaces exposed to qualify it for each of the role entities that it encloses. The Results Datastore, for example, is on a dedicated database server that can be optimized for database activity and may in fact be administered by separate personnel. The Assessment Server contains the entities necessary for performing the scheduled tasks, evaluating data collected from Data Collector agents, using its own Data Collector(s) to collect data agentlessly, and retrieving artifacts from a separate independent enclave. The Independent Workstation can perform and display self-assessments but can also be linked into the enterprise management system. On 7/13/2013 11:16 AM, ietfdbh wrote: > Hi Gunnar, > > Thanks; that's much better. > > I think many people will have many different approaches to their > architecture, but there will be quite a bit of commonality we can try to > extract from them. > Would you be willing to write some text quickly describing your collection, > assessment, and management system, so we can add this to the use-cases > document? > The more we understand how people plan to gather and assess data, and turn > the collected data into information that can then be used by humans, the > better we can design a solution to meet the needs of multiple approaches. > > > I have some questions, so I can better understand your architecture, and to > make sure I don't make any unwarranted assumptions. > Working from EntitiesInUse, > 1) Do these diagrams represent a system you have already implemented? > 2) Has it been deployed in real-world environments? > 3) Has it been deployed in enterprise environments? Service provider > environment? These diagrams are based primarily on what has been discussed so far on the SACM mailing list. I'm making an effort to ignore what has already been done and focus on what makes best sense based on my current understanding of the goals of this working group. But by some strange coincidence there are a lot of similarities between this and the products we currently build. Which includes enterprise environments. > 4) What are you using for protocols between the assessment server and the > computer with agent? Proprietary, but based on pretty standard things like XML and TLS. > 5) What are you using for protocols between the assessment server and the > computers without agents? Whatever makes sense for each asset type and doesn't create an additional security exposure. DCOM, NetBIOS, SSH, WBEM/WMI, telnet, ... > 6) When the valuator gathers data from agent-less computers, does it convert > the data into the same format that is used to gather data from a computer > with agent? In our current products, yes, the Evaluator in that case acts as a remote agentless Data Collector. For SACM that would only be necessary if the raw collected data was a product to be transferred. If the only product to be returned was the completed benchmark evaluation then there's no need to convert it to the SCAM Collected Data format. On the other hand, if you look at Dave Waltermire's architecture, the Controller is between the Sensor (Data Collector) and Evaluator, so the only way to get assessment results from the Evaluator is if it is fed a SACM standard data collection. It doesn't show up in my diagrams, but I think the Evaluator *should* be able to produce results when fed a diet of collected items. > 7) It appears the controller always talks to the evaluator, never directly > to the data collector. I realize this is an architectural drawing, and in > actual coding a direct-connect might be used to performance improvements. Is > the intent that the controller always goes through the evaluator function? I'm undecided on that. I'm wary of the bottleneck created being too reliant on the controller and I like being able to distribute the workload by possibly having evaluators local to the assets. At the same time it's also more complicated to determine if an assessment request failed to occur in a timely manner if each request isn't being actively monitored by the controller. There's also the problem of being able to authenticate to each asset to perform the collection/evaluation. The exposure to that kind of data needs to be kept to an absolute minimum. > 8) when you have a subdomain, which entities in the super-domain communicate > directly with entities in the subdomain? First, for clarity, the subdomain is just one category of subdividing an organization. "Enclave" would be a better label to put on that. Some entity that does its own security management, but is also part of a larger organization. Communication is at whatever level is needed to fulfill the needs of the implementing organization. That might be as informal as just doing database replication so that only results are available, or it might be all the way down to the level of direct data collection from individual assets. I think that level of detail would be a bad idea for general usage, but we're already dealing with auditors who need to do periodic spot checks on a random selection of assets at multiple remote locations. > 8a) Is this a server-to-server sharing of information? > 8b) Can server A directly access the evaluator function in the subdomain B? > or does it proxy requests for evaluations via subdomain server B controller? > 8c) Can server A directly query the data collector in subdomain B? does it > us Possibly any of the above. All it takes is access to the SACM interface at whatever level of access you are looking for, knowledge of what assets to access, and the ability to authenticate. Most of the time anything other than summary information would be a bad idea. Networks aren't built for the purpose of doing security audits on themselves after all. Which is why I showed the subdomain having its own controller and database. Distribute the workload and share the results -- which is a level not covered by SACM. Alternatively, somebody on Network A could use a Results Viewer to connect to the Results Datastore in the subdomain. This data flow is not currently covered in SACM so it would be proprietary, but there's no reason a Results Viewer couldn't connect to multiple Results Datastores and present the data as a single unified view. No data replication necessary. > 9) Is it fair to assume that the Independent Workstation is equivalent to a > subdomain, which just happens to support only the one workstation it is > running on? In many ways, yes. Being a local machine it poses no more cost in accessing at the data collection level than any other asset in the local domain and there are many benefits, from the enterprise level, in just treating it like another Collector or Evaluator. Not something you'd want to do for a subdomain. At the same time, we work with some multilevel organizations where security data for all assets must be collected but there is no single entity that has permissions to collect from all assets. In that case a self-assessment must be performed and the results pushed to the repository and that's one of the things I was attempting to show with the Independent Workstation. > > More later ... > > Thanks, > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > >> -----Original Message----- >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >> Sent: Friday, July 12, 2013 1:39 PM >> To: ietfdbh >> Cc: 'David Harrington'; 'Sean Turner'; sacm@ietf.org >> Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate- >> architecture-00.txt >> >> >> Try these. They're just not scalable. >> >> >> >> On 7/12/2013 12:02 PM, ietfdbh wrote: >>> I can't read your svg files. >>> >>> David Harrington >>> ietfdbh@comcast.net >>> +1-603-828-1401 >>> >>>> -----Original Message----- >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>>> Of Gunnar Engelbach >>>> Sent: Friday, July 12, 2013 11:11 AM >>>> To: David Harrington >>>> Cc: 'Sean Turner'; sacm@ietf.org >>>> Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate- >>>> architecture-00.txt >>>> >>>> >>>> I like the original. It's only concerned with the logical components >>>> that >>> make >>>> up SACM -- the flexibility in how they are mixed and match to solve >>>> real problems is one of its big strengths. >>>> >>>> But it's also apparent that this is not being effectively communicated. >>>> >>>> I sent some (lousy) drawings to the mailing list a while back trying >>>> to >>> capture >>>> that flexibility -- attached here again for your > amusement/befuddlement. >>>> >>>> >>>> Do very specific use cases help people understand how these standards >>>> can be applied? >>>> >>>> >>>> --gun >>>> >>>> >>>> >>>> On 7/12/2013 10:06 AM, David Harrington wrote: >>>>> Hi, >>>>> >>>>> While I don't fully agree with the original architecture, I find it >>> easier >>>>> to understand the intended functionality than in the alternate >>> architecture. >>>>> >>>>> I understand the goal here of showing where the on-the-wire >>>>> protocols operate between entities. >>>>> The data flows in the Waltermire architecture do not clearly capture >>>>> the on-the-wire-ness of the flows, and what sits where in the network. >>>>> It might be helpful to use both diagrams, combined, to show the >>>>> network entities and on-the-wire data flows, and then show within >>>>> the entity >>>> boxes, >>>>> the expected functionality provided by each. >>>>> >>>>> The new architecture seems focused on a combination firewall/IDS >>>>> box; >>>> that >>>>> seems like a particular use case. >>>>> As you all know already, I think the scope of the sacm work needs to >>>>> be narrowed, but this might narrow it too much. >>>>> >>>>> (Sean, can you write up a firewall/IDS use case that I can put into >>>>> the use-cases document for this usage?) >>>>> >>>>> David Harrington >>>>> dbharrington@comcast.net >>>>> +1-603-828-1401 >>>>> >>>>>> -----Original Message----- >>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >>>>>> Behalf >>>> Of >>>>>> Sean Turner >>>>>> Sent: Thursday, July 11, 2013 12:32 PM >>>>>> To: sacm@ietf.org >>>>>> Subject: [sacm] Fwd: I-D Action: >>> draft-handt-sacm-alternate-architecture- >>>>>> 00.txt >>>>>> >>>>>> Food for thought. >>>>>> >>>>>> spt >>>>>> -------- Original Message -------- >>>>>> Subject: I-D Action: draft-handt-sacm-alternate-architecture-00.txt >>>>>> Date: Thu, 11 Jul 2013 09:26:58 -0700 >>>>>> From: internet-drafts@ietf.org >>>>>> Reply-To: internet-drafts@ietf.org >>>>>> To: i-d-announce@ietf.org >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>>> >>>>>> >>>>>> Title : sacm: Alternate Architecture >>>>>> Author(s) : Russ Housley >>>>>> Sean Turner >>>>>> Filename : draft-handt-sacm-alternate-architecture-00.txt >>>>>> Pages : 5 >>>>>> Date : 2013-07-11 >>>>>> >>>>>> Abstract: >>>>>> This document proposes and alternate architecture for sacm (a >>>>>> proposed working group at the time this draft was submitted). >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> >>> https://datatracker.ietf.org/doc/draft-handt-sacm-alternate-architectu >>> re >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-handt-sacm-alternate-architecture- >>>>>> 00 >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sacm mailing list >>>>>> sacm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>> >>>>> _______________________________________________ >>>>> sacm mailing list >>>>> sacm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>> >>> > From dbharrington@comcast.net Sun Jul 21 12:37:41 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC2721F9D39 for ; Sun, 21 Jul 2013 12:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.146 X-Spam-Level: * X-Spam-Status: No, score=1.146 tagged_above=-999 required=5 tests=[AWL=-1.152, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmdFdjgV1Hco for ; Sun, 21 Jul 2013 12:37:28 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id DA81B21F889C for ; Sun, 21 Jul 2013 12:37:19 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta12.westchester.pa.mail.comcast.net with comcast id 36yz1m0021YDfWL5C7dKXQ; Sun, 21 Jul 2013 19:37:19 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta20.westchester.pa.mail.comcast.net with comcast id 37dJ1m00L2yZEBF3g7dJ8g; Sun, 21 Jul 2013 19:37:19 +0000 From: "David Harrington" To: Date: Sun, 21 Jul 2013 15:37:17 -0400 Message-ID: <005701ce8649$b5dd8010$21988030$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0058_01CE8628.2ECEED50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6GQp344HxcyhkLR3e12+XSKp8Zmg== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374435439; bh=urYkrcFX8Q/zmJ+RvfnR17ERSjhPCJAB1A3bolehZw8=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=DZYoxZSybzDG8Y8m4AnAWS5SrVUVLLTNCGPkJZnhJheK6yYUjkt/9OK2jfzq2WbMz eA1sS1oYpTLkrOqq0FFK+nHr0IPWo1KlrZ+6FHAldPxpWyntod7cEnwjzhEJXZWx0E DmMMHdwfEDwMzEpGGDgSk4CFqrI7kzmPwu24rTG23Xad7NVHjRr8LxuP9VBi8wbVTG GfUPeC5Y1K9qRMvxWbc4OMheW+nS7dBzVScQFBumiech4gFlbilNfMsIdFb0Rd52c5 CC/ZrMccigTEkG32ojh5ycv3EbtfktllCZUmxdHy74iypaKhWXI7A0LsmyBpNun3bV jFyt64AgMCcfQ== Subject: [sacm] Use Cases Style X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 19:37:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0058_01CE8628.2ECEED50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0059_01CE8628.2ECEED50" ------=_NextPart_001_0059_01CE8628.2ECEED50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, There has been some debate about the amount of detail and the formality of the format used in our use cases document. I have argued for IETF-style use cases; Adam has argued for a systems engineering style, recommending the Martin Fowler format. The IETF approach: I recommended that people look at other IETF Use Case documents to see what is "normal" for IETF use case documents. Knowing that everybody is busy, I assumed few if any would actually do so. So to move the discussion forward, I searched for RFCs with "Use Case" in the title. Then I looked at each, and copied a quote from the text about the purpose of each document (where available) I then copied in a sample use case from each document. I was planning to make these into a PowerPoint presentation (I expected that would be very hard to do, given the space limitations of a slide). So I chose short examples. Feel free to look at longer examples if you want. My samples of IETF use cases are in the attached file. The usability.gov approach (http://www.usability.gov/how-to-and-tools/methods/use-cases.html) Elements of a Use Case Depending on how in depth and complex you want or need to get, use cases describe a combination of the following elements: .Actor - anyone or anything that performs a behavior (who is using the system) .Stakeholder - someone or something with vested interests in the behavior of the system under discussion (SUD) .Primary Actor - stakeholder who initiates an interaction with the system to achieve a goal .Preconditions - what must be true or happen before and after the use case runs. .Triggers - this is the event that causes the use case to be initiated. .Main success scenarios [Basic Flow] - use case in which nothing goes wrong. .Alternative paths [Alternative Flow] - these paths are a variation on the main theme. These exceptions are what happen when things go wrong at the system level. How To Write a Use Case Write the steps in a use case in an easy-to-understand narrative. Kenworthy (1997) outlines the following steps: 1. Identify who is going to be using the website. 2. Pick one of those users. 3. Define what that user wants to do on the site. Each thing the use does on the site becomes a use case. 4. For each use case, decide on the normal course of events when that user is using the site. 5. Describe the basic course in the description for the use case. Describe it in terms of what the user does and what the system does in response that the user should be aware of. 6. When the basic course is described, consider alternate courses of events and add those to "extend" the use case. 7. Look for commonalities among the use cases. Extract these and note them as common course use cases. 8. Repeat the steps 2 through 7 for all other users. Middleweight Laundry Use Case Use Case 1: Do laundry Actor: Housekeeper Basic Flow: On Wednesdays, the housekeeper reports to the laundry room. She sorts the laundry that is there. Then she washes each load. She dries each load. She folds the items that need folding. She throws away any laundry item that is irrevocably shrunken, soiled or scorched. Alternative Flow 1: If she notices that something is wrinkled, she irons it and then hangs it on a hanger. Alternative Flow 2: If she notices that something is still dirty, she rewashes it. Alternative Flow 3: If she notices that something shrank, she throws it out. Adam's example use case: Use Case Name: Suspicious Endpoint Behavior Description: This Use Case describes the collaboration between specific participants in an information security system specific to detecting a connection attempt to a known-bad Internet host by a botnet zombie that has made its way onto an organization's Information Technology systems. The primary human actor is the Security Operations Center Analyst, and the primary software actor is the configuration assessment tool. Note, however, the dependencies on other tools, such as asset management, intrusion detection, and messaging. Actors: * Security Operations Center (SOC) Analyst, * Information Security Officer, * System Owner * Organizational Unit Leader Preconditions: * Organizational Security Policy Exists * Security Policy specifies appropriate asset management capabilities (i.e. categorization of endpoints) * Security Policy specifies endpoint configuration baseline for asset categorization * The Organization keeps a list of known-bad Internet hosts * The Organization associates owners who are individuals with endpoints * The Organization associates organizational units with endpoints Postconditions: * Endpoint configuration has been assessed [1] * Results have been conveyed to scan requester Primary Path: 1. At 03:46 UTC an organization's Network Intrusion Detection System (NIDS) sees an IP packet with a destination IPv6 address existing on a blacklist of known botnet command and control (C2) servers. 2. The NIDS sends an alert to the SOC Analyst. 3. The SOC Analyst uses the information captured in the alert (IP packet and reason for the flag) to look up the endpoint in the organization's asset inventory system and discovers that the endpoint is a Windows Server 2008 R2 Member Server playing the role of a File Server 4. The SOC Analyst also verifies that the IPv6 address cited by the NIDS is, in fact, on the blacklist for known C2 servers. 5. At this point, the SOC Analyst switches over to the organization's configuration assessment tool 6. The SOC Analyst locates the offending endpoint in the configuration assessment tool's endpoint catalog [2] 7. The SOC Analyst then initiates an immediate and complete endpoint assessment to determine if the endpoint has experienced any configuration drift [3]. 8. The configuration assessment tool: 9. a. Performs a preliminary asset inventory scan on the offending endpoint, which results in a list of installed software [4][5] b. Performs a comparison between the last known asset inventory and the present asset inventory and notes any differences c. Searches it's local content repository for appropriate configuration baselines for the operating system of the offending endpoint and for each installed piece of software d. Upon aggregating the set of applicable configuration baselines, the configuration assessment tool then connects to and queries the organization's configuration content repository for newer baselines that may exist. e. If a new baseline exists, then it is returned by the configuration content repository. 10. The configuration management tool, having the set of updated baselines, initiates a scan against the offending host, which yields a result set. 11. The configuration management tool displays scan results to the SOC Analyst, which show that three new pieces of software have been installed on the offending endpoint where one piece of software is not on the authorized software list, and that several configuration items were out of compliance with the organization's established baselines. 12. The SOC Analyst reviews the information for accuracy and to plan next steps before sending the report to the responsible Information Security Officer, accountable System Owner, and the Organizational Unit Leader. A Note On Alternative Paths, Preconditions, and Postconditions: There are likely to be many points of optimization and optional paths. For example, a configuration assessment tool might provide a "quick glance" look at the most recent scan history for the offending endpoint. A SOC Analyst might then elect not to run a new scan (i.e. the offending endpoint is known to be out of compliance, so why run a new scan?). Another point might be that the offending endpoint is, at present, not authorized to be on the network, in which case it is very likely not to exist in the configuration assessment tool's endpoint catalog. As with alternative paths, pre-/post-conditions can vary widely. Consider that this description likely represents an organization on the mature side of managing information security. Many organizations do not have a Security Operations Center, nor do they necessarily monitor their network. It may be the case that a log management process has detected the blacklisted connection attempt through audit trail monitoring. Or, it may be the case that a shared indicator of compromise has been used to detect the offending endpoint. ------------------- [1] I am assuming at this point that "configuration assessment" has been defined and will be understood by the reader. What I consider to be "assessment" is that the baseline has been obtained, send to the scanning implementation, endpoint configuration item values have been harvested, endpoint configuration item values have been compared against baseline, and results stored/forwarded as appropriate for the use case. [2] An "endpoint catalog" is intended to convey nothing more than the notion that configuration assessment tools are likely to have some method of listing, enumerating, or aggregating endpoints under configuration management. [3] It may not be necessary to specify what we mean by "complete" or the order in which scanning operations take place. In this particular scenario, I thought it might be useful to illustrate that "scan levels" exist on a continuum. [4] Remember that the configuration assessment tool has knowledge of the offending endpoint so running a preliminary inventory scan is reasonable at this point. [5] The mechanism of scan could be agent-based or remote, so details of how a scan happens are omitted here. A more granular partition of the process is required for further details. This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. My Comments: Executive Summary: The IETF format is what most IETF readers will expect. This format has the drawback of not being formal, and is not necessarily very complete. If we to derive requirements from this freehand format, it can be more difficult. But it is easily readable, so reviewers of our work can understand what we are trying to accomplish. Use cases of this form help to identify the nature of the stakeholders involved in our WG. Operators vs vendors, service providers vs enterprises, managed-device implementers vs management application developers, and so on. This can help to categorize requirements that exist for some stakeholders but not all stakeholders. I think the formal approach recommended in usability.gov would be more work for the editors to lay out the use cases in this formal format, and the ASCII text required for RFCs makes this much harder than, say Word or HTML formats. Usability.gov step 2 says "pick one of the users" to document as the actor. Each thing the user wants to do becomes a use case, and each possible alternative action becomes a use case. Adam's example for Actor includes multiple roles, and then describes a rather complex use case , including footnotes. Part of my concern is that we have WG contributors coming from multiple vendors, with possibly multiple products, representing customers from multiple industry segments. To fully detail each possible alternative would make it close to impossible to actually finish this document in a reasonable amount of time. I suspect Adam combined a number of use cases together in his example, to simplify things. However, I cannot figure out how to create English sentences from his example because he has multiple actors and multiple preconditions and multiple postconditions, and what seems to be a lot of irrelevant details in the Primary Path. Is the fact that this happens at 3:46 UTC an important detail in our design? Or is it an irrelevant detail? Or is it important for some use cases (such as trying to establish behavior anomalies based on when a user normally works, or when an attack normally happens?) but not others? I think the formal approach is over the top for our needs. The IETF approach seems more appropriate at this point in our work process. David Harrington dbharrington@comcast.net +1-603-828-1401 ------=_NextPart_001_0059_01CE8628.2ECEED50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

There = has been some debate about the amount of detail and the formality of the = format used in our use cases document.

I have argued for IETF-style use cases; Adam has = argued for a systems engineering style, recommending the Martin Fowler = format.

 

The IETF = approach:

 

I recommended that people look at other IETF Use = Case documents to see what is "normal" for IETF use case = documents.

Knowing that everybody = is busy, I assumed few if any would actually do so.

So to move the discussion forward, I searched for = RFCs with "Use Case" in the title.

Then  I looked at each, and copied a quote = from the text about the purpose of each document (where = available)

 

I then copied in a sample use case from each = document.

I was planning to make = these into a PowerPoint presentation (I expected that would be very hard = to do, given the space limitations of a slide).

So I chose short examples.

Feel free to look at longer examples if you = want.

 

My samples of IETF use cases are in the attached = file.

The usability.gov approach = (http://www.usability.gov/how-to-and-tools/methods/use-cases.html)

 

Elements of a Use Case

 

Depending on how in depth and complex you want or = need to get, use cases describe a combination of the following = elements:

•Actor – = anyone or anything that performs a behavior (who is using the = system)

•Stakeholder – = someone or something with vested interests in the behavior of the system = under discussion (SUD)

•Primary Actor – stakeholder who = initiates an interaction with the system to achieve a = goal

•Preconditions – = what must be true or happen before and after the use case = runs.

•Triggers – this = is the event that causes the use case to be initiated.

•Main success scenarios [Basic Flow] – = use case in which nothing goes wrong.

•Alternative paths [Alternative Flow] – = these paths are a variation on the main theme. These exceptions are what = happen when things go wrong at the system level.

 

How To = Write a Use Case

 

Write the = steps in a use case in an easy-to-understand narrative. Kenworthy (1997) = outlines the following steps:

1.       = Identify who is going to be using the = website.

2.       = Pick one of those users.

3.       = Define what that user wants to do on the site. = Each thing the use does on the site becomes a use case.

4.       For = each use case, decide on the normal course of events when that user is = using the site.

5.       = Describe the basic course in the description for = the use case. Describe it in terms of what the user does and what the = system does in response that the user should be aware = of.

6.       = When the basic course is described, consider = alternate courses of events and add those to "extend" the use = case.

7.       = Look for commonalities among the use cases. = Extract these and note them as common course use cases.

8.       = Repeat the steps 2 through 7 for all other = users.

 

Middleweight Laundry Use Case

 

Use = Case 1: Do laundry

Actor: = Housekeeper

Basic Flow: On = Wednesdays, the housekeeper reports to the laundry room.  She sorts = the laundry that is there.  Then she washes each load.  She = dries each load. She folds the items that need folding.  She throws = away any laundry item that is irrevocably shrunken, soiled or scorched. =

Alternative Flow 1: If she = notices that something is wrinkled, she irons it and then hangs it on a = hanger.

Alternative Flow 2: If = she notices that something is still dirty, she rewashes it. =

Alternative Flow 3: If she = notices that something shrank, she throws it out.

 

Adam's example use = case:

Use Case Name: Suspicious = Endpoint Behavior

 

Description:

This Use Case describes the collaboration between = specific participants in an information security system specific to = detecting a connection attempt to a known-bad Internet host by a botnet = zombie that has made its way onto an organization's Information = Technology systems.  The primary human actor is the Security = Operations Center Analyst, and the primary software actor is the = configuration assessment tool.  Note, however, the dependencies on = other tools, such as asset management, intrusion detection, and = messaging.

 

 

Actors:

 

   * Security Operations Center (SOC) = Analyst,

   * = Information Security Officer,

   * System Owner

   * Organizational Unit = Leader

 

Preconditions:

 

 

   * Organizational Security Policy = Exists

   * Security = Policy specifies appropriate asset management capabilities (i.e. = categorization of endpoints)

   * Security Policy specifies endpoint = configuration baseline for asset categorization

   * The Organization keeps a list of = known-bad Internet hosts

   * The Organization associates owners = who are individuals with endpoints

   * The Organization associates = organizational units with endpoints

 

Postconditions:

 

   * Endpoint configuration has been = assessed [1]

   * = Results have been conveyed to scan requester

 

Primary Path:

 

  = 1. At 03:46 UTC an organization's Network Intrusion Detection System = (NIDS) sees an IP packet with a destination IPv6 address existing on a = blacklist of known botnet command and control (C2) = servers.

 

  2. The NIDS sends an alert to the SOC = Analyst.

 

  3. The SOC Analyst uses the information = captured in the alert (IP packet and reason for the flag) to look up the = endpoint in the organization's asset inventory system and discovers that = the endpoint is a Windows Server 2008 R2 Member Server playing the role = of a File Server

 

  = 4. The SOC Analyst also verifies that the IPv6 address cited by the NIDS = is, in fact, on the blacklist for known C2 servers.

 

  = 5. At this point, the SOC Analyst switches over to the organization's = configuration assessment tool

 

  = 6. The SOC Analyst locates the offending endpoint in the configuration = assessment tool's endpoint catalog [2]

 

  = 7. The SOC Analyst then initiates an immediate and complete endpoint = assessment to determine if the endpoint has experienced any = configuration drift [3].

 

  = 8. The configuration assessment tool:

 

  = 9.

    a. = Performs a preliminary asset inventory scan on the offending endpoint, = which results in a list of installed software [4][5]

    b. Performs a comparison between = the last known asset inventory and the present asset inventory and notes = any differences

    = c. Searches it's local content repository for appropriate configuration = baselines for the operating system of the offending endpoint and for = each installed piece of software

    d. Upon aggregating the set of = applicable configuration baselines, the configuration assessment tool = then connects to and queries the organization's configuration content = repository for newer baselines that may exist.

    e. If a new baseline exists, = then it is returned by the configuration content = repository.

 

  = 10. The configuration management tool, having the set of updated = baselines, initiates a scan against the offending host, which yields a = result set.

 

  = 11. The configuration management tool displays scan results to the SOC = Analyst, which show that three new pieces of software have been = installed on the offending endpoint where one piece of software is not = on the authorized software list, and that several configuration items = were out of compliance with the organization's established = baselines.

 

  12. The SOC Analyst reviews the information = for accuracy and to plan next steps before sending the report to the = responsible Information Security Officer, accountable System Owner, and = the Organizational Unit Leader.

 

 

A Note = On Alternative Paths, Preconditions, and = Postconditions:

There are likely = to be many points of optimization and optional paths.  For example, = a configuration assessment tool might provide a "quick glance" = look at the most recent scan history for the offending endpoint.  A = SOC Analyst might then elect not to run a new scan (i.e. the offending = endpoint is known to be out of compliance, so why run a new = scan?).  Another point might be that the offending endpoint is, at = present, not authorized to be on the network, in which case it is very = likely not to exist in the configuration assessment tool's endpoint = catalog.

 

 

As = with alternative paths, pre-/post-conditions can vary widely.  = Consider that this description likely represents an organization on the = mature side of managing information security.  Many organizations = do not have a Security Operations Center, nor do they necessarily = monitor their network.  It may be the case that a log management = process has detected the blacklisted connection attempt  through = audit trail monitoring.  Or, it may be the case that a shared = indicator of compromise has been used to detect the offending = endpoint.

 

 

-------------------

[1] I am assuming at this point that = "configuration assessment" has been defined and will be = understood by the reader.  What I consider to be = "assessment" is that the baseline has been obtained, send to = the scanning implementation, endpoint configuration item values have = been harvested, endpoint configuration item values have been compared = against baseline, and results stored/forwarded as appropriate for the = use case.

 

 

[2] An = "endpoint catalog" is intended to convey nothing more than the = notion that configuration assessment tools are likely to have some = method of listing, enumerating, or aggregating endpoints under = configuration management.

 

 

[3] It = may not be necessary to specify what we mean by "complete" or = the order in which scanning operations take place.  In this = particular scenario, I thought it might be useful to illustrate that = "scan levels" exist on a continuum. 

 

 

[4] = Remember that the configuration assessment tool has knowledge of the = offending endpoint so running a preliminary inventory scan is reasonable = at this point.

 

 

[5] = The mechanism of scan could be agent-based or remote, so details of how = a scan happens are omitted here.  A more granular partition of the = process is required for further details.

 

This = message and attachments may contain confidential information.  If = it appears that this message was sent to you by mistake, any retention, = dissemination, distribution or copying of this message and attachments = is strictly prohibited.  Please notify the sender immediately and = permanently delete the message and any attachments.

 

My = Comments:

Executive = Summary:

The IETF format is what most = IETF readers will expect. This format has the drawback of not being = formal, and is not necessarily very complete. If we to derive = requirements from this freehand format, it can be more difficult. But it = is easily readable, so reviewers of our work can understand what we are = trying to accomplish. Use cases of this form help to identify the nature = of the stakeholders involved in our WG. Operators vs vendors, service = providers vs enterprises, managed-device implementers vs management = application developers, and so on. This can help to categorize = requirements that exist for some stakeholders but not all = stakeholders.

 

I think the formal approach recommended in = usability.gov would be more work for the editors to lay out the use = cases in this formal format, and the ASCII text required for RFCs makes = this much harder than, say Word or HTML formats.

Usability.gov step 2 says “pick one of the = users” to document as the actor. Each thing the user wants to do = becomes a use case, and each possible alternative action becomes a use = case.

Adam’s example for Actor = includes multiple roles, and then describes a rather complex use case , = including footnotes.

 

Part of my = concern is that we have WG contributors coming from multiple vendors, = with possibly multiple products, representing customers from multiple = industry segments.

To fully detail = each possible alternative would make it close to impossible to actually = finish this document in a reasonable amount of time.

I suspect Adam combined a number of use cases together = in his example, to simplify things.

However, I cannot figure out how to create English = sentences from his example because he has multiple actors and multiple = preconditions and multiple postconditions, and what seems to be a lot of = irrelevant details in the Primary Path. Is the fact that this happens at = 3:46 UTC an important detail in our design? Or is it an irrelevant = detail? Or is it important for some use cases (such as trying to = establish behavior anomalies based on when a user normally works, or = when an attack normally happens?) but not others?

 

I think = the formal approach is over the top for our needs.

The IETF approach seems more appropriate at this point = in our work process.

 

 

David = Harrington

dbharrington@comcast.net

+1-603-828-1401

 

------=_NextPart_001_0059_01CE8628.2ECEED50-- ------=_NextPart_000_0058_01CE8628.2ECEED50 Content-Type: text/html; name="A Review of Uses Cases in RFCs.htm" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="A Review of Uses Cases in RFCs.htm" =

A Review of Uses Cases in RFCs

RFC 3752
(draft= -ietf-opes-scenarios)

Open Pluggable Edge = Services (OPES) Use Cases and Deployment Scenarios

2004-04 =

RFC 3752 (Informational) =

Ned Freed =

RFC 4496
(= draft-ietf-opes-smtp-use-cases)

Open Pluggable Edge = Services (OPES) SMTP Use Cases

2006-05 =

RFC 4496 (Informational) =

Ted Hardie

RFC 5344
(draft-ietf-speermint-consolidated-presence-im-usecases) =

Presence and Instant = Messaging Peering Use Cases

2008-10 =

RFC 5344 (Informational) =

Jon Peterson =

RFC 6294
(draft= -hu-flow-label-cases)

Survey of Proposed Use = Cases for the IPv6 Flow Label

2011-06 =

RFC 6294 (Informational) =

Jari Arkko =

RFC 6341
(draft-ietf-siprec-req) =

Use Cases and Requirements = for SIP-Based Media Recording (SIPREC)

2011-08 =

RFC 6341 (Informational) =

Gonzalo Camarillo =

RFC 6394
(draft= -ietf-dane-use-cases)

Use Cases and Requirements = for DNS-Based Authentication of Named Entities = (DANE)

2011-10 =

RFC 6394 (Informational) =

Stephen Farrell =

RFC 6405
(draft-ietf-speermint-voip-consolidated-usecases)

Voice over IP (VoIP) SIP = Peering Use Cases

2011-11 =

RFC 6405 (Informational) =

Gonzalo Camarillo =

RFC 6461
(draft-ietf-drinks-usecases-requirements)

Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use = Cases and Protocol Requirements

2012-01 =

RFC 6461 (Informational) =

Gonzalo Camarillo =

RFC 6770
(draft= -ietf-cdni-use-cases)

Use Cases for Content = Delivery Network Interconnection

2012-11 =

RFC 6770 (Informational) =

1

Martin Stiemerling =

RFC 6789
(= draft-ietf-conex-concepts-uses)

Congestion Exposure (ConEx) Concepts and Use = Cases

2012-12 =

RFC 6789 (Informational) =

Wesley Eddy =

RFC 6907
(draft-= ietf-sidr-usecases)

Use Cases and = Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and = Relying Parties

2013-03 =

RFC 6907 (Informational) =

Stewart Bryant
Alexey Melnikov

RFC 6953
(draft-ietf-paws-problem-stmt-usecases-rqmts)

Protocol to Access = White-Space (PAWS) Databases: Use Cases and Requirements

2013-05 =

RFC 6953 (Informational) =

 

 

3752: open pluggable edge services

=A0=A0=A0=A0 "examples of = services in which Open Pluggable Edge Services (OPES) would be = useful"

=A0=A0=A0=A0 =

Sample text:

An OPES processor may modify a service request on behalf of the data = consumer for various reasons, such as:

o Owner = of a Web access device might need control over what kind of Web content can be = accessed with the device, parental control for example.

o = Organization may restrict or redirect access to certain web services based on various = criteria such as time of the day or the employee access privileges. =

o Hiding = the data consumer's identity, user agent, or referrer. o Adding user preferences or device profile to the service request to get = personalized or adapted services.

o = Blocking or redirecting a service request due to a corporate policy. An OPES = processor may also modify a service request on behalf of the data provider in several = ways, such as:

=A0o = Redirecting the request to a different server to reduce the server work load. o Redirecting image requests to improve access = time.

 

4496: OPES SMTP use cases

=93collection of some typical use cases describing different filtering areas and = different actions caused by those filters=94

4.1 Security Filters

=A0=A0 These filters concentrate on = the email message body and usually filter the email sections one by one. Email = sections (attachments)that violate the security policy = (e.g., because they contain a virus or contain an unwanted mime type) define an = event that can cause a combination of different actions to be = performed:

=A0=A0 o=A0 The attachment is replaced = by an error message.

=A0=A0 o=A0 The email is marked by = inserting a warning into the subject or the

=A0=A0=A0=A0=A0 email body.

=A0=A0 o=A0 An additional header is = added for post-processing steps.

=A0=A0 o=A0 The email storage is = advised to put the email into quarantine.

=A0=A0 o=A0 Notifications are sent to = sender, recipients, and/or

=A0=A0=A0=A0=A0 administrators.

=A0=A0 o=A0 The incident is reported to = other tools such as intrusion

=A0=A0=A0=A0=A0 detection applications.

 

4.4.=A0 Access Control Filters

 

=A0=A0 These filters operate on the = values of the MAIL FROM and RCPT TO

=A0=A0 commands of the SMTP dialog.=A0 They run an = access control policy to

=A0=A0 determine whether a sender is currently allowed to send a message to

=A0=A0 the = given recipients.=A0 The values of = HELO/EHLO, AUTH, and STARTTLS

=A0=A0 commands may also be applied.=A0 The result of = this filter has a direct

=A0=A0 influence on the SMTP response that the OPES processor has to send = to

=A0=A0 its = peer for the filtered SMTP command.

 

5344: Presence and Instant Messaging Peering Use Cases

=93captures = the way that presence and Instant Messaging are currently used within = enterprises and operator domains.=94

2.1.=A0 Simple Interdomain Subscription

 

=A0=A0 = Assume two Peer Networks, Peer Network A and Peer Network B.=A0 User =A0Alice@example.com (hosted in = Peer Network A) wants to subscribe to user Bob@example.net (hosted in Peer = Network B) and get his presence information.=A0 = In order to do so, Alice@example.com could connect = =A0directly to example.net and = subscribe to Bob's presence information. =A0However, Peer Network B is willing to accept subscriptions and route IMs only = when they are coming from its users or from other Peer Networks that Peer Network = B trusts.

 

=A0=A0 In reality, what will happen is Peer Network A will connect to Peer =A0Network B and send = Alice's subscription to Bob via Peer Network B. =A0When Peer Network B has new = information on Bob, it will send =A0=A0notifications to Peer Network A, which will pass them to Alice.

 

6341: = Use Cases and Requirements for SIP-Based Media Recording

Use Case 5: Real-time Recording Controls.

 

=A0=A0=A0=A0=A0 For an active = Recording Session, privacy or security reasons may

=A0=A0=A0=A0=A0 demand not capturing a specific portion of a conversation.=A0 An

=A0=A0=A0=A0=A0 example is for PCI (payment card industry) compliance where = credit

=A0=A0=A0=A0=A0 card information must be protected.=A0 One = solution is not to record

=A0=A0=A0=A0=A0 a caller speaking their credit card information.

 

=A0=A0=A0=A0=A0 An example of a = real-time control is Pause/Resume.

 

6394: Use = Cases and Requirements for DNS-Based Authentication of Named = Entities

=93describes a set of use cases in which the DNS and DNS Security Extensions (DNSSEC) = could be used to make assertions that support the TLS authentication = process.=94

3.2.=A0 Service Certificate Constraints

 

=A0=A0 Alice runs a website on = alice.example.com and has obtained a certificate from the well-known CA Charlie.=A0 She is concerned about additional, unauthorized certificates being issued by Charlie as well as by other = CAs.=A0 She would like to provide a way = for visitors to her site to know that they should expect alice.example.com to present = a specific certificate.=A0 In TLS terms, = Alice is letting Bob know that this specific certificate must be the first = certificate in the server Certificate message's certificate_list structure [RFC5246].

=A0=A0 When Bob connects to = alice.example.com, he uses this mechanism to verify that the certificate presented by the = server is the correct certificate.=A0 Bob = also performs the normal PKIX validation procedure for this certificate, in particular verifying that the certificate chains to a trust = anchor.

 

=A0=A0 The security implications for = this case are the same as for the "CA Constraints" case = above.

 

6405: = Voice over IP (VoIP) SIP Peering Use Cases

=93describes important Voice over IP (VoIP) use cases for SIP-based [RFC3261] = peering.=A0 These use cases are determined by = the Session PEERing for Multimedia INTerconnect (SPEERMINT) working group and will assist in identifying requirements = and other issues to be considered for future resolution by the working = group.=94

 

5.1.=A0 Static Peering Use Cases

 

=A0=A0 Static peering [RFC5486] = describes the use case when two SSPs form a

=A0=A0 peering relationship with some form of association established = prior

=A0=A0 to = the exchange of traffic.=A0 Pre-association is a prerequisite to

=A0=A0 static peering.=A0 Static peering is = used in cases when two peers want

=A0=A0 a = consistent and tightly controlled approach to peering.=A0 In this

=A0=A0 scenario, a number of variables, such as an identification method

=A0=A0 (remote proxy IP address) and Quality-of-Service (QoS) = parameters,

=A0=A0 can = be defined upfront and known by each SSP prior to peering.

 

6461: = (DRINKS) Use Cases and Protocol Requirements

=93captures the use cases and associated requirements for

=A0=A0 interfaces that provision session = establishment data into Session

=A0=A0 Initiation Protocol (SIP) Service Provider components to assist = with

=A0=A0 session routing.=A0 Specifically, this document = focuses on the

=A0=A0 provisioning of one such element = termed the "registry".

 

3.4.=A0 Category: SED Record Content

 

=A0=A0 UC SED RECORD #1=A0 SED Record Content: = Establishing interconnects

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 between SSPs involves, among other things,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 communicating points of ingress, the service types

=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0(SIP, SIPS, etc.) supported by each point = of

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 ingress, and the relative priority of each point of

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 ingress for each service type.

 

=A0=A0 UC SED RECORD #2=A0 Time-To-Live (TTL): For = performance reasons,

=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= querying SSPs sometimes cache SED that had been

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 previously looked up for a given public identifier.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 In order to accomplish this, SSPs sometimes specify

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 the TTL associated with a given SED record.

 

 

6770: = Use Cases for Content Delivery Network Interconnection

=93focuses on = use cases that correspond to identified industry needs and that are expected = to be realized once open interfaces and protocols supporting the =A0=A0interconnection of CDNs are = specified and implemented.=94

2.2.=A0 Inter-Affiliates Interconnection

 

=A0=A0 The previous section describes = the case of geographic extension between CDNs operated by different entities.=A0 A large CDN Provider may have = several subsidiaries that each operate their own CDN = (which may rely on different CDN technologies, see Section 4.2).=A0 In certain circumstances, the CDN = Provider needs to make these CDNs interoperate to provide consistent service to = its customers on the whole collective = footprint.

 

 

6789: = Congestion Exposure (ConEx) Concepts and Use = Cases

 

=93focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective = traffic =A0=A0management than what exists on = the Internet today.=94

 

Sample = text:

=93=A0 = By deploying a congestion policer at the BRAS = location, the network =A0=A0operator can = measure the congestion-volume created by users within the access nodes and police misbehaving users before their traffic affects others on the access network.=A0 The policer would be provisioned with a traffic management policy, perhaps directing = the BRAS to drop packets from users that exceed their congestion-volume quotas = during times of congestion.=A0 Those = users' apps would be likely to react in the typical way to drops, backing off = (assuming at least some use TCP), and thereby lowering the users' congestion-volumes = back within the quota limits.=A0 If = none of a user's apps responds, the policer would = continue to increase focused drops and effectively enforce its own congestion = control.=94

6007: Use = Cases for Resource Public Key Infrastructure

=93describes a number of use cases together with

=A0=A0 directions and interpretations for organizations and relying parties

=A0=A0 when creating or encountering Resource = Public Key Infrastructure

=A0=A0 (RPKI) = object scenarios in the public RPKI.=94

3.1.=A0 Single Announcement

 

=A0=A0 An organization (Org A with ASN = 64496) has been allocated the prefix

=A0=A0 10.1.2.0/24.=A0 It wishes to announce the /24 prefix from ASN = 64496

=A0=A0 such = that relying parties interpret the route as intended.

 

=A0=A0 The desired announcement (and = organization) would be:

 

=A0=A0=A0=A0=A0 +----------------------------------------------+=

=A0=A0=A0=A0=A0 | Prefix=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Origin = AS=A0=A0 | Organization = |

=A0=A0=A0=A0=A0 +----------------------------------------------+=

=A0=A0=A0=A0=A0 | 10.1.2.0/24=A0=A0=A0=A0 | AS 64496=A0=A0=A0 |=A0=A0 Org A=A0=A0=A0=A0=A0 = |

=A0=A0=A0=A0=A0 = +----------------------------------------------+=

 

=A0=A0 The issuing party should create = a ROA containing the following:

 

=A0=A0=A0=A0=A0 +----------------------------------------------+=

=A0=A0=A0=A0=A0 | asID=A0=A0=A0=A0 | address=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | maxLength=A0=A0=A0=A0 |

=A0=A0=A0=A0=A0 +----------------------------------------------+=

=A0=A0=A0=A0=A0 | 64496=A0=A0=A0 | 10.1.2.0/24=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0 24=A0=A0=A0=A0=A0=A0=A0=A0 |

=A0=A0=A0=A0=A0 +----------------------------------------------+=

 

6953: PAWS = Use cases

=93This document includes the problem statement followed by use cases and = requirements associated with the use of white-space spectrum by secondary users via a database query protocol.=94

4.1.=A0 Master-Slave White-Space Networks

 

=A0=A0 There are a number of common = scenarios in which a master white-space

=A0=A0 device will act as proxy or mediator for one or more slave devices

=A0=A0 using its connection to the Internet to query the database = for

=A0=A0 available spectrum for itself and for one or more slave devices.

=A0=A0 These slave devices may be = fixed or mobile, in close proximity with

=A0=A0 each = other (indoor network or urban hotspot), or at a distance (rural

=A0=A0 or = remote WAN).=A0 Once slave devices = switch to white-space spectrum

=A0=A0 for = their communications, they may connect through the master to = the

=A0=A0 Internet or use white-space = spectrum for intra-network communications

=A0=A0 only.=A0 The master device can continue to = arbitrate and control white-

=A0=A0 space communications by slave devices, and it may notify them = when

=A0=A0 they = are required to change white-space frequencies or cease white-

=A0=A0 space communications.

 

------=_NextPart_000_0058_01CE8628.2ECEED50-- From david.waltermire@nist.gov Tue Jul 23 11:08:53 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECBE11E82F5 for ; Tue, 23 Jul 2013 11:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTrIEWPqEiNa for ; Tue, 23 Jul 2013 11:08:47 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id DFD4B11E8291 for ; Tue, 23 Jul 2013 11:08:42 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 23 Jul 2013 14:08:24 -0400 Received: from wsget1.nist.gov (129.6.13.150) by WSXGHUB2.xchange.nist.gov (129.6.18.19) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 23 Jul 2013 14:08:39 -0400 Received: from WSGHUB2.xchange.nist.gov (129.6.42.35) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 23 Jul 2013 14:08:23 -0400 Received: from na01-bl2-obe.outbound.protection.outlook.com (207.46.163.209) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 23 Jul 2013 14:08:38 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB039.namprd09.prod.outlook.com (10.255.211.153) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 23 Jul 2013 18:08:29 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.86]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.51]) with mapi id 15.00.0731.000; Tue, 23 Jul 2013 18:08:29 +0000 From: "Waltermire, David A." To: Adam Montville , "sacm@ietf.org" Thread-Topic: Use Case Discussion: Vulnerable Endpoint Identification Thread-Index: Ac6Bnj6YfWpompnaTx+fZSs45OpjDgGE4lOA Date: Tue, 23 Jul 2013 18:08:28 +0000 Message-ID: <96625bc3e1154d47bdae1fdee7c1ec1e@BLUPR09MB038.namprd09.prod.outlook.com> References: <05BCCEB107AF88469B9F99783D47C1D671F8C0@CISEXCHANGE2.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D671F8C0@CISEXCHANGE2.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.225.46] x-forefront-prvs: 0916FC3A18 x-forefront-antispam-report: SFV:NSPM; SFS:(50944004)(13464003)(164054003)(15404003)(377454003)(199002)(189002)(51704005)(49866001)(74706001)(47976001)(74316001)(74662001)(19580405001)(74502001)(31966008)(66066001)(83322001)(63696002)(47736001)(19580385001)(50986001)(65816001)(79102001)(51856001)(59766001)(77982001)(76482001)(4396001)(54356001)(77096001)(56776001)(81542001)(33646001)(69226001)(74876001)(46102001)(16406001)(80022001)(83072001)(47446002)(74366001)(19580395003)(76576001)(81342001)(54316002)(76786001)(76796001)(53806001)(56816003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB039; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.225.46; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] Use Case Discussion: Vulnerable Endpoint Identification X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 18:08:53 -0000 Adam, A few comments. In general... if our current focus is on endpoint assessment, it seems like= much of this goes way beyond our initial scope of focus. Things like knowi= ng what organizational units have endpoints and who owns these endpoints is= important in the broader scope, but is not significant to our constrained = area of focus. This raises the questions... should our use cases be scoped to only the cur= rent area of focus for the working group, or should the use cases identify = the broader end goal for which our work will play a part? Other comments are inline. Thanks, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Monday, July 15, 2013 4:59 PM > To: sacm@ietf.org > Subject: [sacm] Use Case Discussion: Vulnerable Endpoint Identification >=20 > And another... >=20 >=20 > Use Case Name: Vulnerable Endpoint Identification >=20 > Description: > In this use case a zero-day exploit has been discovered in the wild, whic= h is > followed by a vulnerability identification entry and indicators of compro= mise. > A security engineer is responsible for that portion of a situational resp= onse > process that determines how exposed an organization is given the new stat= e > of the world. This seems like two use cases in one. Vulnerable Endpoint Identification: Typically vulnerability reports identif= y an executable or library that is vulnerable, or worst case the software t= hat is vulnerable. This information is used to determine if an organization= has one or more endpoints that have exposure to a vulnerability (i.e., wha= t endpoints are vulnerable?). It is often necessary to know where you are r= unning vulnerable code and what configurations are in place on the endpoint= and upstream devices (e.g., IDS, firewall) that may limit the exposure. Al= l of this information, along with details on the severity and impact of a v= ulnerability, is necessary to prioritize remedies. Compromised Endpoint Identification: Along with knowing if one or more endp= oints are vulnerable, it is also important to know if you have been comprom= ised. Indicators of compromise provide details that can be used to identify= malware (e.g., file hashes), identify malicious activity (e.g. command and= control traffic), presence of unauthorized/malicious configuration items, = and other indicators. While important, this goes beyond determining organiz= ational exposure. >=20 >=20 > Actors: >=20 > * System Administrator > * Vulnerability Engineer > * Security Engineer > * System Owner > * Information Owner >=20 >=20 > Preconditions: >=20 > * Organizational Security Policy exists > * Security Policy specifies appropriate asset management capabilities = (i.e. > categorization of endpoints) > * Security Policy specifies endpoint configuration baseline for asset > categorization > * Security Policy specifies configuration history retention requiremen= ts > * The Organization associates owners who are individuals with endpoint= s > * The Organization associates organizational units with endpoints >=20 > Postconditions: >=20 > * Appropriate individuals in the organization have a clear understandi= ng of > the organization's exposure to and potential impact of the identified 0-d= ay > * Appropriate individuals are taking action to further assess or mitig= ate the > organization's posture regarding this 0-day >=20 >=20 > Primary Path: >=20 >=20 > 1. [External] 0-day exploit discovery [1] >=20 > 2. Vulnerability Identification (Vulnerability ID) issued and associate= d > information published to an accessible content repository [2] This applies to Vulnerable Endpoint Identification. > 3. Indicators of Compromise (IoC) are identified and published to an > accessible content repository [3] This applies to Compromised Endpoint Identification. > 4. Security engineer provides the Vulnerability ID to the Asset Managem= ent > System >=20 > 5. The Asset Management System queries a configured Vulnerability > Database to obtain a list of affected endpoint classes [4] >=20 > 6. The Asset Management System returns a list of specific endpoints tha= t > can be classified according to the endpoint class list obtained in Step 5= , which > either: > > 7. > a. Presently have affected software installed, or > b. Have had affected software installed. This supports both. Potentially compromised endpoints are those that are vu= lnerable or may have been vulnerable historically. >=20 > 8. The Security Engineer exports the list of potentially affected endpo= ints >=20 > 9. The Security Engineer initiates a vulnerability scan based on IoCs, > published vulnerability information, and the potentially affected endpoin= t > list. Is a scan necessary for identification of vulnerable endpoints? If there is= datastore that contains the current software inventory of endpoint devices= , wouldn't it be possible to check the vulnerability information against th= at data? Use of a data store seems to be the only effective way of doing t= his for historically vulnerable software. Vulnerability scanning has had mixed success in the past. There has been l= ittle consensus in what is the best methodology for detecting vulnerable so= ftware using scans. Is the software vulnerable if the software is installe= d? Is the endpoint vulnerable if the software is uninstalled and a vulnera= ble library or other component is still present? > 10. The Vulnerability Scanner derives a set of vulnerability checks (i.= e. > assessments) to perform on each listed endpoint based on information > associated with the provided Vulnerability ID and IoCs. Again, I am not sure vulnerability checks are the best approach to identify= vulnerable endpoints. This is getting into architecture and implementatio= n details. It might be better for the endpoint to send file lists with hash= es which get stored is a data store. Deltas can be used to reduce the over= all volume. We need some discussion around the different approaches that c= an be used here. Do we support one approach? Multiple? File lists with hashes can be used to identify compromised endpoints for fi= le indicators. Checks or configuration setting publication are probably the= best way to deal with some indicator types that relate to configuration it= ems. > 11. The Vulnerability Scanner executes the check on each of the potenti= ally > affected hosts which will return results effectively equivalent to "is > vulnerable," "is not vulnerable," "not checked," or "error" [5]. What about "compromised" or "is not compromised"? > 12. The Security Engineer reviews the report then generates three > additional reports: I thought we are striving for automation. Why not automate the additional = report generation? > 13. > a. The first report provides summary information for the Information > Security Manager and/or higher levels of organizational management as > appropriate (i.e. Chief Information Security Officer) > b. The second report is a list of all potentially effected endpoints = for which > no definitive answer could be obtained by the Vulnerability Scanner (i.e. > those endpoints for which neither an "is vulnerable" nor "is not vulnerab= le" > result is available) s/effected/affected/ See above about alternate methods vs. using a vulnerability scanner. What a= bout unreachable endpoints? > c. The third report is a list of all effected endpoints (i.e. those e= ndpoints for > which the checks resulted in "is vulnerable"). s/effected/affected/ > 14. The Security Engineer sends the first report to responsible Informa= tion > Security Manager(s) using relationships tracked by the Asset Management > System >=20 > 15. The Security Engineer sends the second report to responsible > Vulnerability Engineer(s) using relationships tracked by the Asset > Management System >=20 > 16. The Security Engineer sends the third report to responsible System > Administrator(s) using relationships tracked by the Asset Management > System >=20 > 17. The Security Engineer issues an alert to affected System Owners, > Information Owners, and System Administrators using relationships tracked > by the Asset Management System Why can't 14-17 be automated alerts sent by the system implementing SACM sp= ecifications? > A Note On Alternative Paths, Preconditions, and Postconditions: > There are likely to be many points of optimization and optional paths > pertaining to this Use Case. For example, there may be greater degrees o= f > interoperability between tools in a given organization, which would advan= ce > the state of automation in the "primary path" description herein provided= . >=20 >=20 > As with alternative paths, pre-/post-conditions can vary widely. Conside= r > that this description likely represents an organization on the mature sid= e of > managing information security. Most organizations are unlikely to have > separate roles for Security Engineer and Vulnerability Engineer, for exam= ple. >=20 >=20 > -------------- > [1] The "[External]" notation is used to indicate that, while this step i= s > included in the primary path, it is out of the organization's locus of co= ntrol > (i.e. the step is provided for additional context in the path through the= use > case rather than being placed in the pre-conditions). >=20 >=20 > [2] An "accessible" content repository may be internal or external. An > internal content repository may be a replication of an external content > repository. >=20 >=20 > [3] Often, an indicator of compromise involves assessing the state of som= e > observable object on the endpoint. For example, an indicator of > compromise might be that a particular file path exists, a particular sett= ing is > configured in a specific manner, a set of settings are configured in a sp= ecific > manner, and/or specific log entries exist. >=20 > [4] The Vulnerability Database may be combined with the content repositor= y, > but is being called out separately here to assure that the reader knows w= hich > type of data is being queried. >=20 > [5] It is likely that additional result types will be required to convey = different > reasons a result may not be available. >=20 > This message and attachments may contain confidential information. If it > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments is > strictly prohibited. Please notify the sender immediately and permanentl= y > delete the message and any attachments. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Tue Jul 23 11:28:41 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B666A11E8341 for ; Tue, 23 Jul 2013 11:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DH607xbEyzal for ; Tue, 23 Jul 2013 11:28:35 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id AB9E921E80CB for ; Tue, 23 Jul 2013 11:28:33 -0700 (PDT) Received: from WSGHUB2.xchange.nist.gov (129.6.42.35) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 23 Jul 2013 14:28:16 -0400 Received: from wsget2.nist.gov (129.6.13.151) by wsghub2.xchange.nist.gov (129.6.16.197) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 23 Jul 2013 14:28:31 -0400 Received: from WSGHUB2.xchange.nist.gov (129.6.42.35) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 23 Jul 2013 14:28:30 -0400 Received: from na01-by2-obe.outbound.protection.outlook.com (207.46.163.240) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 23 Jul 2013 14:28:31 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB037.namprd09.prod.outlook.com (10.255.211.139) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 23 Jul 2013 18:28:28 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.86]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.51]) with mapi id 15.00.0731.000; Tue, 23 Jul 2013 18:28:27 +0000 From: "Waltermire, David A." To: Adam Montville , "sacm@ietf.org" Thread-Topic: Use Case Discussion: Suspicious Endpoint Behavior Thread-Index: Ac6BnRsvXB1G28Z8TkmYX8u/K3iDnwGMzikA Date: Tue, 23 Jul 2013 18:28:27 +0000 Message-ID: <936b0884768f41ca9f249a76365f63e3@BLUPR09MB038.namprd09.prod.outlook.com> References: <05BCCEB107AF88469B9F99783D47C1D671F8AB@CISEXCHANGE2.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D671F8AB@CISEXCHANGE2.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.225.46] x-forefront-prvs: 0916FC3A18 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(51704005)(15404003)(50944004)(13464003)(74876001)(46102001)(69226001)(54356001)(33646001)(81542001)(56776001)(81342001)(54316002)(76576001)(53806001)(56816003)(76796001)(76786001)(80022001)(16406001)(47446002)(83072001)(19580395003)(74366001)(77096001)(63696002)(83322001)(19580405001)(74662001)(74316001)(66066001)(31966008)(74502001)(65816001)(50986001)(47736001)(19580385001)(74706001)(49866001)(47976001)(76482001)(77982001)(4396001)(59766001)(79102001)(51856001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB037; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.225.46; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] Use Case Discussion: Suspicious Endpoint Behavior X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 18:28:42 -0000 Comments inline.=20 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Monday, July 15, 2013 4:57 PM > To: sacm@ietf.org > Subject: [sacm] Use Case Discussion: Suspicious Endpoint Behavior >=20 > So, the Use Case discussion has been ongoing. David Harrington submitted= a > 05 draft (thank you!), so we have a lot to talk about. Steve Hanna was g= oing > to craft some additional use cases, and I offered to help. Here's what I= 've > come up with after Steve asked for the assist. >=20 > It's detailed, and there's another one coming after this one... But, I t= hink the > detail might be useful. When I think "use case" and that we want to get > down to brass tacks, then this is the level of detail I think about. At = the very > least, if it is found to be too detailed, then we have established some > boundaries where we have examples of what may not be detailed enough > (the pre 05 versions of the use case draft) and this (and following) exam= ple > for what may be too detailed. >=20 > Nevertheless, I think it's probably easier to summarize from the detail t= han it > is to derive details from the summary... >=20 >=20 >=20 > Use Case Name: Suspicious Endpoint Behavior >=20 > Description: > This Use Case describes the collaboration between specific participants i= n an > information security system specific to detecting a connection attempt to= a > known-bad Internet host by a botnet zombie that has made its way onto an > organization's Information Technology systems. The primary human actor i= s > the Security Operations Center Analyst, and the primary software actor is= the > configuration assessment tool. Note, however, the dependencies on other > tools, such as asset management, intrusion detection, and messaging. >=20 >=20 > Actors: >=20 > * Security Operations Center (SOC) Analyst, > * Information Security Officer, > * System Owner > * Organizational Unit Leader >=20 > Preconditions: >=20 >=20 > * Organizational Security Policy Exists > * Security Policy specifies appropriate asset management capabilities = (i.e. > categorization of endpoints) > * Security Policy specifies endpoint configuration baseline for asset > categorization > * The Organization keeps a list of known-bad Internet hosts > * The Organization associates owners who are individuals with endpoint= s > * The Organization associates organizational units with endpoints >=20 > Postconditions: >=20 > * Endpoint configuration has been assessed [1] > * Results have been conveyed to scan requester >=20 > Primary Path: >=20 > 1. At 03:46 UTC an organization's Network Intrusion Detection System > (NIDS) sees an IP packet with a destination IPv6 address existing on a bl= acklist > of known botnet command and control (C2) servers. >=20 > 2. The NIDS sends an alert to the SOC Analyst. >=20 > 3. The SOC Analyst uses the information captured in the alert (IP packe= t and > reason for the flag) to look up the endpoint in the organization's asset > inventory system and discovers that the endpoint is a Windows Server 2008 > R2 Member Server playing the role of a File Server >=20 > 4. The SOC Analyst also verifies that the IPv6 address cited by the NID= S is, in > fact, on the blacklist for known C2 servers. >=20 > 5. At this point, the SOC Analyst switches over to the organization's > configuration assessment tool >=20 > 6. The SOC Analyst locates the offending endpoint in the configuration > assessment tool's endpoint catalog [2] >=20 > 7. The SOC Analyst then initiates an immediate and complete endpoint > assessment to determine if the endpoint has experienced any configuration > drift [3]. Wouldn't it be better if instead of requesting a batch assessment, that the= endpoint published configuration changes as they happened? This may detec= t compromise and may avoid the endpoint eventually lying about its configur= ation when the scan occurs. In this case the SOC Analyst can query a CMDB c= ontaining the current and historically related reported configurations for = the endpoint skipping to step 11. Extending this, if the system had a mecha= nism to determine what changes are authorized, unauthorized changes can be = routed to the SOC Analyst as a potential security event starting step 1. Performing scans in a periodic way is not continuous or very effective. Fo= r scanning to be effective here, the scanning rate needs to be twice as fre= quent as the rate of change to have a chance of detecting a sophisticated a= ttacker. Anything happening between samples/scans can compromise the endpoi= nts ability to give truthful answers. This is a good case for event-driven = data reporting where the changes is reported as soon as it happens. This ty= pe of reporting has a chance of occurring before the attacker can compromis= e the collector. > 8. The configuration assessment tool: >=20 > 9. > a. Performs a preliminary asset inventory scan on the offending endpo= int, > which results in a list of installed software [4][5] > b. Performs a comparison between the last known asset inventory and t= he > present asset inventory and notes any differences > c. Searches it's local content repository for appropriate configurati= on > baselines for the operating system of the offending endpoint and for each > installed piece of software > d. Upon aggregating the set of applicable configuration baselines, th= e > configuration assessment tool then connects to and queries the > organization's configuration content repository for newer baselines that = may > exist. > e. If a new baseline exists, then it is returned by the configuration= content > repository. >=20 > 10. The configuration management tool, having the set of updated > baselines, initiates a scan against the offending host, which yields a re= sult set. >=20 > 11. The configuration management tool displays scan results to the SOC > Analyst, which show that three new pieces of software have been installed > on the offending endpoint where one piece of software is not on the > authorized software list, and that several configuration items were out o= f > compliance with the organization's established baselines. >=20 > 12. The SOC Analyst reviews the information for accuracy and to plan ne= xt > steps before sending the report to the responsible Information Security > Officer, accountable System Owner, and the Organizational Unit Leader. >=20 >=20 > A Note On Alternative Paths, Preconditions, and Postconditions: > There are likely to be many points of optimization and optional paths. F= or > example, a configuration assessment tool might provide a "quick glance" l= ook > at the most recent scan history for the offending endpoint. A SOC Analys= t > might then elect not to run a new scan (i.e. the offending endpoint is kn= own > to be out of compliance, so why run a new scan?). Another point might be > that the offending endpoint is, at present, not authorized to be on the > network, in which case it is very likely not to exist in the configuratio= n > assessment tool's endpoint catalog. If the endpoint is joining the network for the first time, this may be the = case. In the future, historic info might be available. > As with alternative paths, pre-/post-conditions can vary widely. Conside= r > that this description likely represents an organization on the mature sid= e of > managing information security. Many organizations do not have a Security > Operations Center, nor do they necessarily monitor their network. It may= be > the case that a log management process has detected the blacklisted > connection attempt through audit trail monitoring. Or, it may be the ca= se > that a shared indicator of compromise has been used to detect the offendi= ng > endpoint. >=20 >=20 > ------------------- > [1] I am assuming at this point that "configuration assessment" has been > defined and will be understood by the reader. What I consider to be > "assessment" is that the baseline has been obtained, send to the scanning > implementation, endpoint configuration item values have been harvested, > endpoint configuration item values have been compared against baseline, > and results stored/forwarded as appropriate for the use case. >=20 >=20 > [2] An "endpoint catalog" is intended to convey nothing more than the > notion that configuration assessment tools are likely to have some method > of listing, enumerating, or aggregating endpoints under configuration > management. >=20 >=20 > [3] It may not be necessary to specify what we mean by "complete" or the > order in which scanning operations take place. In this particular scenar= io, I > thought it might be useful to illustrate that "scan levels" exist on a > continuum. >=20 >=20 > [4] Remember that the configuration assessment tool has knowledge of the > offending endpoint so running a preliminary inventory scan is reasonable = at > this point. >=20 >=20 > [5] The mechanism of scan could be agent-based or remote, so details of > how a scan happens are omitted here. A more granular partition of the > process is required for further details. >=20 > This message and attachments may contain confidential information. If it > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments is > strictly prohibited. Please notify the sender immediately and permanentl= y > delete the message and any attachments. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Tue Jul 23 12:22:53 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3709911E821E for ; Tue, 23 Jul 2013 12:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJ+I7TM+8ew6 for ; Tue, 23 Jul 2013 12:22:48 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id E081811E80A2 for ; Tue, 23 Jul 2013 12:22:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=dXSp9Ul2Wn1O1COkW0CAf5Ks+RDZa2H+D0bp0HszyAt43h2OqWYdqYbO85fYRPwcH3GrrGGcb5Dvw/358YSOYLBDATXtee27sctumiwTtsptbUrDVdmt81eV16nBiK9s; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 12359 invoked from network); 23 Jul 2013 12:21:04 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 23 Jul 2013 12:21:04 -0700 Message-ID: <51EED808.7000405@ThreatGuard.com> Date: Tue, 23 Jul 2013 15:22:48 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Waltermire, David A." References: <05BCCEB107AF88469B9F99783D47C1D671F8AB@CISEXCHANGE2.msisac.org.local> <936b0884768f41ca9f249a76365f63e3@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <936b0884768f41ca9f249a76365f63e3@BLUPR09MB038.namprd09.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] Use Case Discussion: Suspicious Endpoint Behavior X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 19:22:53 -0000 On 7/23/2013 2:28 PM, Waltermire, David A. wrote: > Comments inline. > > > Wouldn't it be better if instead of requesting a batch assessment, that the endpoint published configuration changes as they happened? This may detect compromise and may avoid the endpoint eventually lying about its configuration when the scan occurs. Yes, it would be better, but I think that's a different use case. It's the one I think we want to push for, but we have to first support the traditional periodic full and incremental assessments as a path to that. >> In this case the SOC Analyst can query a CMDB containing the current and historically related reported configurations for the endpoint skipping to step 11. Extending this, if the system had a mechanism to determine what changes are authorized, unauthorized changes can be routed to the SOC Analyst as a potential security event starting step 1. The data in the CMDB is only going to be as reliable as the collection method. The endpoint can still lie about a change (or fail to report a change). Further, the data in the CMDB is only as current as the last collection and might not represent the actual state of the endpoint. I definitely think leveraging a CMDB when available is a net positive and should be supported, but it also creates other problems and should not be *required*. > > Performing scans in a periodic way is not continuous or very effective. For scanning to be effective here, the scanning rate needs to be twice as frequent as the rate of change to have a chance of detecting a sophisticated attacker. Anything happening between samples/scans can compromise the endpoints ability to give truthful answers. This is a good case for event-driven data reporting where the changes is reported as soon as it happens. This type of reporting has a chance of occurring before the attacker can compromise the collector. Just to be clear, Dave, the rule you refer to here works for things like determining the sample rate for audio, but does not apply here. What we want to minimize is the window of opportunity to exploit an exposure, which is the amount of time between when a configuration item changed (or the announcement of a new vulnerability) and when it is detected and remediated. The *average* time between when an item changed and when it is detected would be 1/2 the sampling rate. If your "rate of change" is, for example, monthly, and you therefore set your periodic rescan for every two weeks, you still have an average time of exposure of a week and a worst case of two weeks. Which only supports further your focus on bottom-up change detection from the endpoints. From david.waltermire@nist.gov Tue Jul 23 14:21:02 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECDD11E8136 for ; Tue, 23 Jul 2013 14:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXwxo+b4ugB9 for ; Tue, 23 Jul 2013 14:20:55 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id B12CC11E82B1 for ; Tue, 23 Jul 2013 14:20:53 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 23 Jul 2013 17:20:49 -0400 Received: from wsget2.nist.gov (129.6.13.151) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 23 Jul 2013 17:20:50 -0400 Received: from WSGHUB2.xchange.nist.gov (129.6.42.35) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 23 Jul 2013 17:20:47 -0400 Received: from na01-bn1-obe.outbound.protection.outlook.com (207.46.163.158) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 23 Jul 2013 17:20:48 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 23 Jul 2013 21:20:46 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.86]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.51]) with mapi id 15.00.0731.000; Tue, 23 Jul 2013 21:20:46 +0000 From: "Waltermire, David A." To: Gunnar Engelbach Thread-Topic: [sacm] Use Case Discussion: Suspicious Endpoint Behavior Thread-Index: Ac6BnRsvXB1G28Z8TkmYX8u/K3iDnwGMzikAAAJsCwAAAKy10A== Date: Tue, 23 Jul 2013 21:20:46 +0000 Message-ID: <1130fe7ac042403d84991ff1f66db777@BLUPR09MB038.namprd09.prod.outlook.com> References: <05BCCEB107AF88469B9F99783D47C1D671F8AB@CISEXCHANGE2.msisac.org.local> <936b0884768f41ca9f249a76365f63e3@BLUPR09MB038.namprd09.prod.outlook.com> <51EED808.7000405@ThreatGuard.com> In-Reply-To: <51EED808.7000405@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.225.46] x-forefront-prvs: 0916FC3A18 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(51704005)(13464003)(85644002)(377454003)(51444003)(479174003)(189002)(199002)(74366001)(81342001)(81542001)(54356001)(47446002)(77096001)(74502001)(46102001)(76786001)(56816003)(65816001)(66066001)(80022001)(56776001)(76576001)(83072001)(74316001)(76796001)(53806001)(77982001)(59766001)(49866001)(33646001)(47736001)(50986001)(4396001)(74706001)(69226001)(47976001)(74876001)(54316002)(76482001)(74662001)(31966008)(63696002)(51856001)(19580405001)(19580395003)(83322001)(79102001)(16406001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB038; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.225.46; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Cc: Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] Use Case Discussion: Suspicious Endpoint Behavior X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 21:21:03 -0000 Comments inline. > -----Original Message----- > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > Sent: Tuesday, July 23, 2013 3:23 PM > To: Waltermire, David A. > Cc: Adam Montville; sacm@ietf.org > Subject: Re: [sacm] Use Case Discussion: Suspicious Endpoint Behavior >=20 > On 7/23/2013 2:28 PM, Waltermire, David A. wrote: > > Comments inline. > > >=20 > >=20 > > > > Wouldn't it be better if instead of requesting a batch assessment, that= the > endpoint published configuration changes as they happened? This may > detect compromise and may avoid the endpoint eventually lying about its > configuration when the scan occurs. >=20 >=20 > Yes, it would be better, but I think that's a different use case. It's t= he one I > think we want to push for, but we have to first support the traditional > periodic full and incremental assessments as a path to that. I disagree with this being a different use case. It is most certainly a di= fferent technique for achieving/implementing the use case, but the use case= "detecting suspicious endpoint behavior" is the same as are the desired ou= tcomes. I am not advocating that we drop support for periodic scanning. If fact, I= believe strongly that support for it is important for a variety of reasons= . My concern is that we rely too much on periodic scanning to detect things= that it is not well suited to address. Event-driven detection of changes, = both software and configuration, is critical for responding in a timely fas= hion to security relevant events such as those that relate to unauthorized = or malicious changes. We need to simultaneously support periodic and event-= driven approaches in the standards we produce. For this to work right, we c= an't bolt event-driven capabilities on after the fact. This needs to be co= nsidered as part of our architectural design and protocol adoption/design.= =20 > >> In this case the SOC Analyst can query a CMDB containing the current a= nd > historically related reported configurations for the endpoint skipping to= step > 11. Extending this, if the system had a mechanism to determine what > changes are authorized, unauthorized changes can be routed to the SOC > Analyst as a potential security event starting step 1. >=20 > The data in the CMDB is only going to be as reliable as the collection me= thod. > The endpoint can still lie about a change (or fail to report a change). = Further, > the data in the CMDB is only as current as the last collection and might = not > represent the actual state of the endpoint. This is all true for both event-driven and periodic techniques. ;-) Many or= ganizations are going to want a historic perspective regardless of the how = the data is collected. This does bring up the need to capture the context o= f collection, but that is a different discussion. Event-driven collection is better for things that the attacker cannot silen= ce, at least not initially until they achieve an appropriate level of privi= lege. For example, they may be able to write to configurations using applic= ation flaws, but they might not be able to prevent notifications of change = events. Another example might be detecting signs of malware persistency (e.= g., configuring it to load on boot) prior to a reboot. > I definitely think leveraging a CMDB when available is a net positive and > should be supported, but it also creates other problems and should not be > *required*. None of what we do will be required; it will all be voluntary. They key is = to enable the endpoint to publish changes based on events. How that publish= ed data gets processed and persisted is a downstream concern. The architect= ure should allow for a variety of solutions that handle the info in various= ways providing organizations and vendors with some flexibility in deployed= architectures. What we want is a reasonable degree of interoperability wit= h regards to the individual components. > > Performing scans in a periodic way is not continuous or very effective.= For > scanning to be effective here, the scanning rate needs to be twice as > frequent as the rate of change to have a chance of detecting a sophistica= ted > attacker. Anything happening between samples/scans can compromise the > endpoints ability to give truthful answers. This is a good case for event= -driven > data reporting where the changes is reported as soon as it happens. This > type of reporting has a chance of occurring before the attacker can > compromise the collector. >=20 > Just to be clear, Dave, the rule you refer to here works for things like > determining the sample rate for audio, but does not apply here. >=20 > What we want to minimize is the window of opportunity to exploit an > exposure, which is the amount of time between when a configuration item > changed (or the announcement of a new vulnerability) and when it is > detected and remediated. The *average* time between when an item > changed and when it is detected would be 1/2 the sampling rate. >=20 > If your "rate of change" is, for example, monthly, and you therefore set = your > periodic rescan for every two weeks, you still have an average time of > exposure of a week and a worst case of two weeks. It doesn't apply if you define the window as the organizational change wind= ow. It does apply if you think about it as the attack window. Most attacks= will go unnoticed if the scanning occurs hourly. In this scenario the att= acker can get in, make changes, exfiltrate information, and then cleanup re= storing things to the previous state within the hour period. > Which only supports further your focus on bottom-up change detection from > the endpoints. Yes. I want to make sure that the standards we produce don't expose organiz= ations unnecessarily if there is a more effective way. ;-) I am pushing to = expand the scanning mindset to think about how we can approach this problem= space in a way that enables a variety of techniques. The legacy work that = has been done in this space gets us a good way there. We have a variety of= mechanisms that enable classes of configurations that are security relevan= t to be identified and described. These can be used to identify relevant c= hange events. What is missing are the standards that describe how you imple= ment protocols that enable endpoint data exchange that support both scannin= g tasks and event driven publication. There are existing protocols such as = NEA that can enable both techniques if we do the work to identify the speci= fics of messaging. I would expect a similar approach would also enable incr= emental scan results as well. From gunnar.engelbach@threatguard.com Tue Jul 23 15:49:04 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72DA11E816E for ; Tue, 23 Jul 2013 15:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXZy-5KWldPJ for ; Tue, 23 Jul 2013 15:48:59 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB2C11E8166 for ; Tue, 23 Jul 2013 15:48:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=ZZghP7vMlfxPx88qicSyvgDGqy7rRw4Dzk4fj5TUu0aZrMy6Y7FJ1t9mtfTCykjtqVINORyZp69KV5hVXlzREb/3A3gVKmeSMB2ypwyEauTghgS2XHuEZMbQ436JFDnF; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 18158 invoked from network); 23 Jul 2013 15:47:17 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 23 Jul 2013 15:47:16 -0700 Message-ID: <51EF085C.5010105@ThreatGuard.com> Date: Tue, 23 Jul 2013 18:49:00 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Waltermire, David A." References: <05BCCEB107AF88469B9F99783D47C1D671F8AB@CISEXCHANGE2.msisac.org.local> <936b0884768f41ca9f249a76365f63e3@BLUPR09MB038.namprd09.prod.outlook.com> <51EED808.7000405@ThreatGuard.com> <1130fe7ac042403d84991ff1f66db777@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <1130fe7ac042403d84991ff1f66db777@BLUPR09MB038.namprd09.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] Use Case Discussion: Suspicious Endpoint Behavior X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:49:05 -0000 Alrighty, some semantic quibbles, but I think we're both on the same page. 1) Endpoint-originated event-driven assessments are the necessary end state. The solution needs to be designed for that up front. 2) CMDB's are good but not essential. 3) The standards describe a minimal set of data exchanges and operations, which can be organized into basic logical entities (such as Sensor or Evaluator), but in actual usage these can be mixed and matched to meet the actual needs. Does anybody have an appreciable difference from that? On 7/23/2013 5:20 PM, Waltermire, David A. wrote: > Comments inline. > >> -----Original Message----- >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >> Sent: Tuesday, July 23, 2013 3:23 PM >> To: Waltermire, David A. >> Cc: Adam Montville; sacm@ietf.org >> Subject: Re: [sacm] Use Case Discussion: Suspicious Endpoint Behavior >> >> On 7/23/2013 2:28 PM, Waltermire, David A. wrote: >>> Comments inline. >>> >> >> >> >>> >>> Wouldn't it be better if instead of requesting a batch assessment, that the >> endpoint published configuration changes as they happened? This may >> detect compromise and may avoid the endpoint eventually lying about its >> configuration when the scan occurs. >> >> >> Yes, it would be better, but I think that's a different use case. It's the one I >> think we want to push for, but we have to first support the traditional >> periodic full and incremental assessments as a path to that. > > I disagree with this being a different use case. It is most certainly a different technique for achieving/implementing the use case, but the use case "detecting suspicious endpoint behavior" is the same as are the desired outcomes. > > I am not advocating that we drop support for periodic scanning. If fact, I believe strongly that support for it is important for a variety of reasons. My concern is that we rely too much on periodic scanning to detect things that it is not well suited to address. Event-driven detection of changes, both software and configuration, is critical for responding in a timely fashion to security relevant events such as those that relate to unauthorized or malicious changes. We need to simultaneously support periodic and event-driven approaches in the standards we produce. For this to work right, we can't bolt event-driven capabilities on after the fact. This needs to be considered as part of our architectural design and protocol adoption/design. > >>>> In this case the SOC Analyst can query a CMDB containing the current and >> historically related reported configurations for the endpoint skipping to step >> 11. Extending this, if the system had a mechanism to determine what >> changes are authorized, unauthorized changes can be routed to the SOC >> Analyst as a potential security event starting step 1. >> >> The data in the CMDB is only going to be as reliable as the collection method. >> The endpoint can still lie about a change (or fail to report a change). Further, >> the data in the CMDB is only as current as the last collection and might not >> represent the actual state of the endpoint. > > This is all true for both event-driven and periodic techniques. ;-) Many organizations are going to want a historic perspective regardless of the how the data is collected. This does bring up the need to capture the context of collection, but that is a different discussion. > > Event-driven collection is better for things that the attacker cannot silence, at least not initially until they achieve an appropriate level of privilege. For example, they may be able to write to configurations using application flaws, but they might not be able to prevent notifications of change events. Another example might be detecting signs of malware persistency (e.g., configuring it to load on boot) prior to a reboot. > >> I definitely think leveraging a CMDB when available is a net positive and >> should be supported, but it also creates other problems and should not be >> *required*. > > None of what we do will be required; it will all be voluntary. They key is to enable the endpoint to publish changes based on events. How that published data gets processed and persisted is a downstream concern. The architecture should allow for a variety of solutions that handle the info in various ways providing organizations and vendors with some flexibility in deployed architectures. What we want is a reasonable degree of interoperability with regards to the individual components. > >>> Performing scans in a periodic way is not continuous or very effective. For >> scanning to be effective here, the scanning rate needs to be twice as >> frequent as the rate of change to have a chance of detecting a sophisticated >> attacker. Anything happening between samples/scans can compromise the >> endpoints ability to give truthful answers. This is a good case for event-driven >> data reporting where the changes is reported as soon as it happens. This >> type of reporting has a chance of occurring before the attacker can >> compromise the collector. >> >> Just to be clear, Dave, the rule you refer to here works for things like >> determining the sample rate for audio, but does not apply here. >> >> What we want to minimize is the window of opportunity to exploit an >> exposure, which is the amount of time between when a configuration item >> changed (or the announcement of a new vulnerability) and when it is >> detected and remediated. The *average* time between when an item >> changed and when it is detected would be 1/2 the sampling rate. >> >> If your "rate of change" is, for example, monthly, and you therefore set your >> periodic rescan for every two weeks, you still have an average time of >> exposure of a week and a worst case of two weeks. > > It doesn't apply if you define the window as the organizational change window. It does apply if you think about it as the attack window. Most attacks will go unnoticed if the scanning occurs hourly. In this scenario the attacker can get in, make changes, exfiltrate information, and then cleanup restoring things to the previous state within the hour period. > >> Which only supports further your focus on bottom-up change detection from >> the endpoints. > > Yes. I want to make sure that the standards we produce don't expose organizations unnecessarily if there is a more effective way. ;-) I am pushing to expand the scanning mindset to think about how we can approach this problem space in a way that enables a variety of techniques. The legacy work that has been done in this space gets us a good way there. We have a variety of mechanisms that enable classes of configurations that are security relevant to be identified and described. These can be used to identify relevant change events. What is missing are the standards that describe how you implement protocols that enable endpoint data exchange that support both scanning tasks and event driven publication. There are existing protocols such as NEA that can enable both techniques if we do the work to identify the specifics of messaging. I would expect a similar approach would also enable incremental scan results as well. > From athiasjerome@gmail.com Tue Jul 23 20:52:22 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7783B11E826A for ; Tue, 23 Jul 2013 20:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOIcPrOSU+0P for ; Tue, 23 Jul 2013 20:52:21 -0700 (PDT) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 91A7C11E8271 for ; Tue, 23 Jul 2013 20:52:21 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id c50so5070600eek.11 for ; Tue, 23 Jul 2013 20:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=8Gu8vtQudk3OeEYUAv70P0+Vm3ypGzA8OQBKNBkx5a0=; b=Bf+wCca/0Qm1UPWm+pWgbnyTb3SYlTNzRSSCLAI2QJ79uE2aettLIHd/5jBAZ/utej OdXJQ1Vkbcpo7LlCRl2lbX00WQ6+Pt8TC7CeV9hQCULbTlmH//djklq5xrgIYCX6BDgA XA1Y4wkkjnS6YBCbf1VKSdRZni+O4UI8Y1PtePX05eaFMwKXYqSqRbe1hvD3KH/V7cCQ JCdEGMIvT4Yu2WcZfz48WQe5gsgXAyDnI9UW1wTemnndn6UglL2o6jRINVpBLAvB9gWa NJz87OsyeZn9nwq5+mC7NJKumPp6I5Y11iyw3PHxQABO8UaUxG3bfup6TVSyI1+ql9cY F+3w== X-Received: by 10.15.67.140 with SMTP id u12mr35273679eex.90.1374637940579; Tue, 23 Jul 2013 20:52:20 -0700 (PDT) Received: from [192.168.1.114] ([91.73.38.83]) by mx.google.com with ESMTPSA id n5sm62943114eed.9.2013.07.23.20.52.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 20:52:19 -0700 (PDT) From: Jerome Athias Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <671E2522-6E51-4EC4-9549-92A8A0831CE0@gmail.com> Date: Wed, 24 Jul 2013 07:52:15 +0400 To: sacm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [sacm] Use Cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 03:52:22 -0000 Hi, What would you think about trying to define the Use Cases around the = SANS TOP20 Critical Security Controls? http://www.sans.org/critical-security-controls/ It could help to focus and prioritize. By the way, I found this an interesting reading = https://securosis.com/blog/continuous-security-monitoring-the-attack-use-c= ase Best regards /JA= From prvs=0917083de9=rainer.enders@ncp-e.com Wed Jul 24 09:46:36 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C6C11E8219 for ; Wed, 24 Jul 2013 09:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaRhzLx+9sMb for ; Wed, 24 Jul 2013 09:46:31 -0700 (PDT) Received: from mail.ncp.de (mail.ncp-e.com [62.153.165.35]) by ietfa.amsl.com (Postfix) with ESMTP id A86B511E8111 for ; Wed, 24 Jul 2013 09:46:30 -0700 (PDT) Received: from viruswall.ncp.de (viruswall.ncp.de [62.153.165.41]) by mail.ncp.de (Postfix) with ESMTPS id 863D53AE5E6 for ; Wed, 24 Jul 2013 18:56:59 +0200 (CEST) Received: from [172.16.11.201] (port=15316 helo=ex07.ncp.local) by viruswall.ncp.de with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) (envelope-from ) id 1V22Cl-00051c-0H; Wed, 24 Jul 2013 18:46:23 +0200 Received: from ex07.ncp.local ([172.16.11.201]) by ex07.ncp.local ([172.16.11.201]) with mapi; Wed, 24 Jul 2013 18:46:22 +0200 X-CTCH-RefID: str=0001.0A0C0204.51F004DF.0060,ss=1,re=0.000,fgs=0 From: Rainer Enders To: Gunnar Engelbach , "Waltermire, David A." Date: Wed, 24 Jul 2013 18:46:18 +0200 Thread-Topic: [sacm] Use Case Discussion: Suspicious Endpoint Behavior Thread-Index: Ac6IjVQS5I+hQusbQ62EEOgGmc6wfw== Message-ID: In-Reply-To: <51EF085C.5010105@ThreatGuard.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] Use Case Discussion: Suspicious Endpoint Behavior X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:46:36 -0000 IMHO it is important to have a self-contained endpoint approach in which the endpoint is capable of maintaining its own security. A part of this is that the endpoint should be able to collect and present security posture related information and ensure the integrity of such information. A remotely performed assessment/scanning process has significant issues such as availability of the endpoint. If I can assert that a certain endpoint is potentially vulnerable I can act on this information quickly once the endpoint is trying to get on the network again without any extensive scanning efforts during network admission. Off course one should argue that this kind of scanning/assessment is necessary to t0 when the endpoint joins the network for the very first time. However I see this as complementary to the endpoint self-contained approach. Also the methodology of the scan/assessment must be considered. How do you ensure the reliability and integrity of the information that is collected? NEA has been mentioned before. However NEA does not deal with detection and/or prevention of lying endpoints. Likewise it does not perform detection of malware that could report false endpoint information. So in that sense I disagree with point 2 that CMDBs are non-essential. Additionally in the spirit of minimal interactions between endpoints and network it appears that the endpoint itself knows best when and how things are changing. It is almost like you say the doctor should tell the patient when to visit the doctor office versus the patient seeing the doctor when the patient feels sick ;) Regards, Rainer On 7/23/13 3:49 PM, "Gunnar Engelbach" wrote: > >Alrighty, some semantic quibbles, but I think we're both on the same page. > >1) Endpoint-originated event-driven assessments are the necessary end >state. The solution needs to be designed for that up front. > >2) CMDB's are good but not essential. > >3) The standards describe a minimal set of data exchanges and >operations, which can be organized into basic logical entities (such as >Sensor or Evaluator), but in actual usage these can be mixed and matched >to meet the actual needs. > > >Does anybody have an appreciable difference from that? > > > > >On 7/23/2013 5:20 PM, Waltermire, David A. wrote: >> Comments inline. >> >>> -----Original Message----- >>> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >>> Sent: Tuesday, July 23, 2013 3:23 PM >>> To: Waltermire, David A. >>> Cc: Adam Montville; sacm@ietf.org >>> Subject: Re: [sacm] Use Case Discussion: Suspicious Endpoint Behavior >>> >>> On 7/23/2013 2:28 PM, Waltermire, David A. wrote: >>>> Comments inline. >>>> >>> >>> >>> >>>> >>>> Wouldn't it be better if instead of requesting a batch assessment, >>>>that the >>> endpoint published configuration changes as they happened? This may >>> detect compromise and may avoid the endpoint eventually lying about its >>> configuration when the scan occurs. >>> >>> >>> Yes, it would be better, but I think that's a different use case. >>>It's the one I >>> think we want to push for, but we have to first support the traditional >>> periodic full and incremental assessments as a path to that. >> >> I disagree with this being a different use case. It is most certainly >>a different technique for achieving/implementing the use case, but the >>use case "detecting suspicious endpoint behavior" is the same as are the >>desired outcomes. >> >> I am not advocating that we drop support for periodic scanning. If >>fact, I believe strongly that support for it is important for a variety >>of reasons. My concern is that we rely too much on periodic scanning to >>detect things that it is not well suited to address. Event-driven >>detection of changes, both software and configuration, is critical for >>responding in a timely fashion to security relevant events such as those >>that relate to unauthorized or malicious changes. We need to >>simultaneously support periodic and event-driven approaches in the >>standards we produce. For this to work right, we can't bolt event-driven >>capabilities on after the fact. This needs to be considered as part of >>our architectural design and protocol adoption/design. >> >>>>> In this case the SOC Analyst can query a CMDB containing the current >>>>>and >>> historically related reported configurations for the endpoint skipping >>>to step >>> 11. Extending this, if the system had a mechanism to determine what >>> changes are authorized, unauthorized changes can be routed to the SOC >>> Analyst as a potential security event starting step 1. >>> >>> The data in the CMDB is only going to be as reliable as the collection >>>method. >>> The endpoint can still lie about a change (or fail to report a >>>change). Further, >>> the data in the CMDB is only as current as the last collection and >>>might not >>> represent the actual state of the endpoint. >> >> This is all true for both event-driven and periodic techniques. ;-) >>Many organizations are going to want a historic perspective regardless >>of the how the data is collected. This does bring up the need to capture >>the context of collection, but that is a different discussion. >> >> Event-driven collection is better for things that the attacker cannot >>silence, at least not initially until they achieve an appropriate level >>of privilege. For example, they may be able to write to configurations >>using application flaws, but they might not be able to prevent >>notifications of change events. Another example might be detecting signs >>of malware persistency (e.g., configuring it to load on boot) prior to a >>reboot. >> >>> I definitely think leveraging a CMDB when available is a net positive >>>and >>> should be supported, but it also creates other problems and should not >>>be >>> *required*. >> >> None of what we do will be required; it will all be voluntary. They key >>is to enable the endpoint to publish changes based on events. How that >>published data gets processed and persisted is a downstream concern. The >>architecture should allow for a variety of solutions that handle the >>info in various ways providing organizations and vendors with some >>flexibility in deployed architectures. What we want is a reasonable >>degree of interoperability with regards to the individual components. >> >>>> Performing scans in a periodic way is not continuous or very >>>>effective. For >>> scanning to be effective here, the scanning rate needs to be twice as >>> frequent as the rate of change to have a chance of detecting a >>>sophisticated >>> attacker. Anything happening between samples/scans can compromise the >>> endpoints ability to give truthful answers. This is a good case for >>>event-driven >>> data reporting where the changes is reported as soon as it happens. >>>This >>> type of reporting has a chance of occurring before the attacker can >>> compromise the collector. >>> >>> Just to be clear, Dave, the rule you refer to here works for things >>>like >>> determining the sample rate for audio, but does not apply here. >>> >>> What we want to minimize is the window of opportunity to exploit an >>> exposure, which is the amount of time between when a configuration item >>> changed (or the announcement of a new vulnerability) and when it is >>> detected and remediated. The *average* time between when an item >>> changed and when it is detected would be 1/2 the sampling rate. >>> >>> If your "rate of change" is, for example, monthly, and you therefore >>>set your >>> periodic rescan for every two weeks, you still have an average time of >>> exposure of a week and a worst case of two weeks. >> >> It doesn't apply if you define the window as the organizational change >>window. It does apply if you think about it as the attack window. Most >>attacks will go unnoticed if the scanning occurs hourly. In this >>scenario the attacker can get in, make changes, exfiltrate information, >>and then cleanup restoring things to the previous state within the hour >>period. >> >>> Which only supports further your focus on bottom-up change detection >>>from >>> the endpoints. >> >> Yes. I want to make sure that the standards we produce don't expose >>organizations unnecessarily if there is a more effective way. ;-) I am >>pushing to expand the scanning mindset to think about how we can >>approach this problem space in a way that enables a variety of >>techniques. The legacy work that has been done in this space gets us a >>good way there. We have a variety of mechanisms that enable classes of >>configurations that are security relevant to be identified and >>described. These can be used to identify relevant change events. What >>is missing are the standards that describe how you implement protocols >>that enable endpoint data exchange that support both scanning tasks and >>event driven publication. There are existing protocols such as NEA that >>can enable both techniques if we do the work to identify the specifics >>of messaging. I would expect a similar approach would also enable >>incremental scan results as well. >> >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Wed Jul 24 10:30:51 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E23511E822D for ; Wed, 24 Jul 2013 10:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cImAaku1tuA for ; Wed, 24 Jul 2013 10:30:47 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 087BA11E81BA for ; Wed, 24 Jul 2013 10:30:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=eH/nOFdiZ7QVDosT1bQz/c9k6jdwrnSP1vPR8epXsJva53wkgPKKpFpMwV9IDhpbHOu4P1EPZnd2yxRjMAlxkUK15FCs5NibFNDf77TiAp55qLUshZ6loxZy8GV+C5e8; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 30180 invoked from network); 24 Jul 2013 10:29:06 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 24 Jul 2013 10:29:06 -0700 Message-ID: <51F00F49.1030207@ThreatGuard.com> Date: Wed, 24 Jul 2013 13:30:49 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rainer Enders References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Montville , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Use Case Discussion: Suspicious Endpoint Behavior X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 17:30:51 -0000 A) Self-contained endpoints Absolutely. The third diagram I sent has just such a thing, which can both self-evaluate and participate in the enterprise system. This isn't just a nifty application of the proposed standards, but a necessity that we have encountered at several customer engagements. B) The essential CMDB Whether it's for direct consumption or intermediate consumption via a CMDB there is always some sort of collection process needed to reap endpoint artifacts. Use of a CMDB does not eliminate the lying endpoint problem. And even if endpoint isn't lying, perhaps the CMDB is, so it's an additional link in that trust chain. There will also be some degree of lag between a change made on the endpoint and when that is reflected in the CMDB, so you just can't beat being able to directly query an endpoint. OTOH, a CMDB also has many benefits. I want to see them supported, I just don't think they should be required. Also, I am coming at this from the SCAP world, where it's not just a matter of collecting endpoint artifacts, but doing that collection in a manner that is verifiably correct (which is where OVAL comes in -- codifying vendor recommendations and/or best practices), and this is a very important factor. So there's two trust factors to deal with: is the endpoint lying, and was the artifact properly collected. There's nothing about the current architecture that says the only way to collect artifacts is directly from each endpoint, but I do think we need to include the full provenance as metadata to accompany artifacts. On 7/24/2013 12:46 PM, Rainer Enders wrote: > IMHO it is important to have a self-contained endpoint approach in which > the endpoint is capable of maintaining its own security. A part of this is > that the endpoint should be able to collect and present security posture > related information and ensure the integrity of such information. A > remotely performed assessment/scanning process has significant issues such > as availability of the endpoint. If I can assert that a certain endpoint > is potentially vulnerable I can act on this information quickly once the > endpoint is trying to get on the network again without any extensive > scanning efforts during network admission. Off course one should argue > that this kind of scanning/assessment is necessary to t0 when the > endpoint joins the network for the very first time. However I see this as > complementary to the endpoint self-contained approach. Also the > methodology of the scan/assessment must be considered. How do you ensure > the reliability and integrity of the information that is collected? NEA > has been mentioned before. However NEA does not deal with detection and/or > prevention of lying endpoints. Likewise it does not perform detection of > malware that could report false endpoint information. So in that sense I > disagree with point 2 that CMDBs are non-essential. Additionally in the > spirit of minimal interactions between endpoints and network it appears > that the endpoint itself knows best when and how things are changing. It > is almost like you say the doctor should tell the patient when to visit > the doctor office versus the patient seeing the doctor when the patient > feels sick ;) > > Regards, > Rainer > > > > On 7/23/13 3:49 PM, "Gunnar Engelbach" > wrote: > >> >> Alrighty, some semantic quibbles, but I think we're both on the same page. >> >> 1) Endpoint-originated event-driven assessments are the necessary end >> state. The solution needs to be designed for that up front. >> >> 2) CMDB's are good but not essential. >> >> 3) The standards describe a minimal set of data exchanges and >> operations, which can be organized into basic logical entities (such as >> Sensor or Evaluator), but in actual usage these can be mixed and matched >> to meet the actual needs. >> >> >> Does anybody have an appreciable difference from that? >> >> >> >> >> On 7/23/2013 5:20 PM, Waltermire, David A. wrote: >>> Comments inline. >>> >>>> -----Original Message----- >>>> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >>>> Sent: Tuesday, July 23, 2013 3:23 PM >>>> To: Waltermire, David A. >>>> Cc: Adam Montville; sacm@ietf.org >>>> Subject: Re: [sacm] Use Case Discussion: Suspicious Endpoint Behavior >>>> >>>> On 7/23/2013 2:28 PM, Waltermire, David A. wrote: >>>>> Comments inline. >>>>> >>>> >>>> >>>> >>>>> >>>>> Wouldn't it be better if instead of requesting a batch assessment, >>>>> that the >>>> endpoint published configuration changes as they happened? This may >>>> detect compromise and may avoid the endpoint eventually lying about its >>>> configuration when the scan occurs. >>>> >>>> >>>> Yes, it would be better, but I think that's a different use case. >>>> It's the one I >>>> think we want to push for, but we have to first support the traditional >>>> periodic full and incremental assessments as a path to that. >>> >>> I disagree with this being a different use case. It is most certainly >>> a different technique for achieving/implementing the use case, but the >>> use case "detecting suspicious endpoint behavior" is the same as are the >>> desired outcomes. >>> >>> I am not advocating that we drop support for periodic scanning. If >>> fact, I believe strongly that support for it is important for a variety >>> of reasons. My concern is that we rely too much on periodic scanning to >>> detect things that it is not well suited to address. Event-driven >>> detection of changes, both software and configuration, is critical for >>> responding in a timely fashion to security relevant events such as those >>> that relate to unauthorized or malicious changes. We need to >>> simultaneously support periodic and event-driven approaches in the >>> standards we produce. For this to work right, we can't bolt event-driven >>> capabilities on after the fact. This needs to be considered as part of >>> our architectural design and protocol adoption/design. >>> >>>>>> In this case the SOC Analyst can query a CMDB containing the current >>>>>> and >>>> historically related reported configurations for the endpoint skipping >>>> to step >>>> 11. Extending this, if the system had a mechanism to determine what >>>> changes are authorized, unauthorized changes can be routed to the SOC >>>> Analyst as a potential security event starting step 1. >>>> >>>> The data in the CMDB is only going to be as reliable as the collection >>>> method. >>>> The endpoint can still lie about a change (or fail to report a >>>> change). Further, >>>> the data in the CMDB is only as current as the last collection and >>>> might not >>>> represent the actual state of the endpoint. >>> >>> This is all true for both event-driven and periodic techniques. ;-) >>> Many organizations are going to want a historic perspective regardless >>> of the how the data is collected. This does bring up the need to capture >>> the context of collection, but that is a different discussion. >>> >>> Event-driven collection is better for things that the attacker cannot >>> silence, at least not initially until they achieve an appropriate level >>> of privilege. For example, they may be able to write to configurations >>> using application flaws, but they might not be able to prevent >>> notifications of change events. Another example might be detecting signs >>> of malware persistency (e.g., configuring it to load on boot) prior to a >>> reboot. >>> >>>> I definitely think leveraging a CMDB when available is a net positive >>>> and >>>> should be supported, but it also creates other problems and should not >>>> be >>>> *required*. >>> >>> None of what we do will be required; it will all be voluntary. They key >>> is to enable the endpoint to publish changes based on events. How that >>> published data gets processed and persisted is a downstream concern. The >>> architecture should allow for a variety of solutions that handle the >>> info in various ways providing organizations and vendors with some >>> flexibility in deployed architectures. What we want is a reasonable >>> degree of interoperability with regards to the individual components. >>> >>>>> Performing scans in a periodic way is not continuous or very >>>>> effective. For >>>> scanning to be effective here, the scanning rate needs to be twice as >>>> frequent as the rate of change to have a chance of detecting a >>>> sophisticated >>>> attacker. Anything happening between samples/scans can compromise the >>>> endpoints ability to give truthful answers. This is a good case for >>>> event-driven >>>> data reporting where the changes is reported as soon as it happens. >>>> This >>>> type of reporting has a chance of occurring before the attacker can >>>> compromise the collector. >>>> >>>> Just to be clear, Dave, the rule you refer to here works for things >>>> like >>>> determining the sample rate for audio, but does not apply here. >>>> >>>> What we want to minimize is the window of opportunity to exploit an >>>> exposure, which is the amount of time between when a configuration item >>>> changed (or the announcement of a new vulnerability) and when it is >>>> detected and remediated. The *average* time between when an item >>>> changed and when it is detected would be 1/2 the sampling rate. >>>> >>>> If your "rate of change" is, for example, monthly, and you therefore >>>> set your >>>> periodic rescan for every two weeks, you still have an average time of >>>> exposure of a week and a worst case of two weeks. >>> >>> It doesn't apply if you define the window as the organizational change >>> window. It does apply if you think about it as the attack window. Most >>> attacks will go unnoticed if the scanning occurs hourly. In this >>> scenario the attacker can get in, make changes, exfiltrate information, >>> and then cleanup restoring things to the previous state within the hour >>> period. >>> >>>> Which only supports further your focus on bottom-up change detection >>>> from >>>> the endpoints. >>> >>> Yes. I want to make sure that the standards we produce don't expose >>> organizations unnecessarily if there is a more effective way. ;-) I am >>> pushing to expand the scanning mindset to think about how we can >>> approach this problem space in a way that enables a variety of >>> techniques. The legacy work that has been done in this space gets us a >>> good way there. We have a variety of mechanisms that enable classes of >>> configurations that are security relevant to be identified and >>> described. These can be used to identify relevant change events. What >>> is missing are the standards that describe how you implement protocols >>> that enable endpoint data exchange that support both scanning tasks and >>> event driven publication. There are existing protocols such as NEA that >>> can enable both techniques if we do the work to identify the specifics >>> of messaging. I would expect a similar approach would also enable >>> incremental scan results as well. >>> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > From prvs=0917083de9=rainer.enders@ncp-e.com Wed Jul 24 11:10:28 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2B711E8233 for ; Wed, 24 Jul 2013 11:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=0.880, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+icTNM8Eas5 for ; Wed, 24 Jul 2013 11:10:22 -0700 (PDT) Received: from mail.ncp.de (mail.remote-access.de [62.153.165.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9810C11E8213 for ; Wed, 24 Jul 2013 11:10:21 -0700 (PDT) Received: from viruswall.ncp.de (viruswall.ncp.de [62.153.165.41]) by mail.ncp.de (Postfix) with ESMTPS id 4D4873AE5F7 for ; Wed, 24 Jul 2013 20:20:50 +0200 (CEST) Received: from [172.16.11.201] (port=15671 helo=ex07.ncp.local) by viruswall.ncp.de with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) (envelope-from ) id 1V23Vt-0006ek-0v; Wed, 24 Jul 2013 20:10:13 +0200 Received: from ex07.ncp.local ([172.16.11.201]) by ex07.ncp.local ([172.16.11.201]) with mapi; Wed, 24 Jul 2013 20:10:13 +0200 X-CTCH-RefID: str=0001.0A0C0207.51F01885.0099,ss=1,re=0.000,fgs=0 From: Rainer Enders To: Gunnar Engelbach Date: Wed, 24 Jul 2013 20:10:05 +0200 Thread-Topic: [sacm] Use Case Discussion: Suspicious Endpoint Behavior Thread-Index: Ac6ImQpsSvIr5P+ZSaGm87C67tVNJw== Message-ID: In-Reply-To: <51F00F49.1030207@ThreatGuard.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adam Montville , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Use Case Discussion: Suspicious Endpoint Behavior X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 18:10:28 -0000 This is an important discussion and I thought - in my mind at least - that Trusted Computing plays a relevant role here but let me explain in more detail what I am referring to. You are making good and relevant points see some more comments below in context. On 7/24/13 10:30 AM, "Gunnar Engelbach" wrote: > >A) Self-contained endpoints >Absolutely. The third diagram I sent has just such a thing, which can >both self-evaluate and participate in the enterprise system. This isn't >just a nifty application of the proposed standards, but a necessity that >we have encountered at several customer engagements. Good. > > >B) The essential CMDB >Whether it's for direct consumption or intermediate consumption via a >CMDB there is always some sort of collection process needed to reap >endpoint artifacts. Use of a CMDB does not eliminate the lying endpoint That is exactly the point. I did not imply CMDB is in any way linked to lying endpoints. What I am thinking is that emphasis must be put on securing the endpoint - and I am particularly thinking about mobile endpoints in that context. (mobile) Endpoints must be put into a position to protect themselves. This entails that the endpoint should be able to monitor and report on its identity and state in a trusted way. The elements of Root of Trust come into play here and my vision is that the endpoint would ideally monitor and measure its own integrity from birth to death. When in a network-linked relationship the endpoint should be able to report on itself and maybe even seek remediation assistance on its own. So very much endpoint driven vs. network driven. > >problem. And even if endpoint isn't lying, perhaps the CMDB is, so it's I agree with this statement. However I think the infrastructure components can be protected much easier as it will reside in a protected/controlled environment and hopefully the operating instance where this function is residing is mostly stable and controlled. As I pointed out above my foremost concern is around mobile endpoints vs. infrastructure endpoints. > >an additional link in that trust chain. There will also be some degree >of lag between a change made on the endpoint and when that is reflected >in the CMDB, so you just can't beat being able to directly query an >endpoint. This is exactly my point and goes back to David's comment about scanning interval. There is just no right or wrong scanning interval and even with "event-triggered" on-demand scanning you would need to establish event categories/classification and when and how what kind of event would trigger a query action. So I think it is much simpler to let the endpoint establish what is changing and report on that event. With that strategy you could hopefully have some assurance that your configuration database reflects actual endpoint state. This does not mean you could use on-demand query as a complementary action. > >OTOH, a CMDB also has many benefits. I want to see them supported, I >just don't think they should be required. > >Also, I am coming at this from the SCAP world, where it's not just a >matter of collecting endpoint artifacts, but doing that collection in a >manner that is verifiably correct (which is where OVAL comes in -- >codifying vendor recommendations and/or best practices), and this is a >very important factor. I must admit that I am not an SCAP expert however I think what you state sounds interesting to include some sort of baseline parameters - if I understand this correctly. I agree this can be an important factor. > >So there's two trust factors to deal with: is the endpoint lying, and >was the artifact properly collected. I think this is an important problem to solve! Either way you do it if endpoint identity and state cannot be asserted all bets are off no matter what you do. > >There's nothing about the current architecture that says the only way to >collect artifacts is directly from each endpoint, but I do think we need >to include the full provenance as metadata to accompany artifacts. > > > > >On 7/24/2013 12:46 PM, Rainer Enders wrote: >> IMHO it is important to have a self-contained endpoint approach in which >> the endpoint is capable of maintaining its own security. A part of this >>is >> that the endpoint should be able to collect and present security posture >> related information and ensure the integrity of such information. A >> remotely performed assessment/scanning process has significant issues >>such >> as availability of the endpoint. If I can assert that a certain endpoint >> is potentially vulnerable I can act on this information quickly once the >> endpoint is trying to get on the network again without any extensive >> scanning efforts during network admission. Off course one should argue >> that this kind of scanning/assessment is necessary to t0 when the >> endpoint joins the network for the very first time. However I see this >>as >> complementary to the endpoint self-contained approach. Also the >> methodology of the scan/assessment must be considered. How do you ensure >> the reliability and integrity of the information that is collected? NEA >> has been mentioned before. However NEA does not deal with detection >>and/or >> prevention of lying endpoints. Likewise it does not perform detection of >> malware that could report false endpoint information. So in that sense I >> disagree with point 2 that CMDBs are non-essential. Additionally in the >> spirit of minimal interactions between endpoints and network it appears >> that the endpoint itself knows best when and how things are changing. It >> is almost like you say the doctor should tell the patient when to visit >> the doctor office versus the patient seeing the doctor when the patient >> feels sick ;) >> >> Regards, >> Rainer >> >> >> >> On 7/23/13 3:49 PM, "Gunnar Engelbach" >> >> wrote: >> >>> >>> Alrighty, some semantic quibbles, but I think we're both on the same >>>page. >>> >>> 1) Endpoint-originated event-driven assessments are the necessary end >>> state. The solution needs to be designed for that up front. >>> >>> 2) CMDB's are good but not essential. >>> >>> 3) The standards describe a minimal set of data exchanges and >>> operations, which can be organized into basic logical entities (such as >>> Sensor or Evaluator), but in actual usage these can be mixed and >>>matched >>> to meet the actual needs. >>> >>> >>> Does anybody have an appreciable difference from that? >>> >>> >>> >>> >>> On 7/23/2013 5:20 PM, Waltermire, David A. wrote: >>>> Comments inline. >>>> >>>>> -----Original Message----- >>>>> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >>>>> Sent: Tuesday, July 23, 2013 3:23 PM >>>>> To: Waltermire, David A. >>>>> Cc: Adam Montville; sacm@ietf.org >>>>> Subject: Re: [sacm] Use Case Discussion: Suspicious Endpoint Behavior >>>>> >>>>> On 7/23/2013 2:28 PM, Waltermire, David A. wrote: >>>>>> Comments inline. >>>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Wouldn't it be better if instead of requesting a batch assessment, >>>>>> that the >>>>> endpoint published configuration changes as they happened? This may >>>>> detect compromise and may avoid the endpoint eventually lying about >>>>>its >>>>> configuration when the scan occurs. >>>>> >>>>> >>>>> Yes, it would be better, but I think that's a different use case. >>>>> It's the one I >>>>> think we want to push for, but we have to first support the >>>>>traditional >>>>> periodic full and incremental assessments as a path to that. >>>> >>>> I disagree with this being a different use case. It is most certainly >>>> a different technique for achieving/implementing the use case, but the >>>> use case "detecting suspicious endpoint behavior" is the same as are >>>>the >>>> desired outcomes. >>>> >>>> I am not advocating that we drop support for periodic scanning. If >>>> fact, I believe strongly that support for it is important for a >>>>variety >>>> of reasons. My concern is that we rely too much on periodic scanning >>>>to >>>> detect things that it is not well suited to address. Event-driven >>>> detection of changes, both software and configuration, is critical for >>>> responding in a timely fashion to security relevant events such as >>>>those >>>> that relate to unauthorized or malicious changes. We need to >>>> simultaneously support periodic and event-driven approaches in the >>>> standards we produce. For this to work right, we can't bolt >>>>event-driven >>>> capabilities on after the fact. This needs to be considered as part >>>>of >>>> our architectural design and protocol adoption/design. >>>> >>>>>>> In this case the SOC Analyst can query a CMDB containing the >>>>>>>current >>>>>>> and >>>>> historically related reported configurations for the endpoint >>>>>skipping >>>>> to step >>>>> 11. Extending this, if the system had a mechanism to determine what >>>>> changes are authorized, unauthorized changes can be routed to the SOC >>>>> Analyst as a potential security event starting step 1. >>>>> >>>>> The data in the CMDB is only going to be as reliable as the >>>>>collection >>>>> method. >>>>> The endpoint can still lie about a change (or fail to report a >>>>> change). Further, >>>>> the data in the CMDB is only as current as the last collection and >>>>> might not >>>>> represent the actual state of the endpoint. >>>> >>>> This is all true for both event-driven and periodic techniques. ;-) >>>> Many organizations are going to want a historic perspective regardless >>>> of the how the data is collected. This does bring up the need to >>>>capture >>>> the context of collection, but that is a different discussion. >>>> >>>> Event-driven collection is better for things that the attacker cannot >>>> silence, at least not initially until they achieve an appropriate >>>>level >>>> of privilege. For example, they may be able to write to configurations >>>> using application flaws, but they might not be able to prevent >>>> notifications of change events. Another example might be detecting >>>>signs >>>> of malware persistency (e.g., configuring it to load on boot) prior >>>>to a >>>> reboot. >>>> >>>>> I definitely think leveraging a CMDB when available is a net positive >>>>> and >>>>> should be supported, but it also creates other problems and should >>>>>not >>>>> be >>>>> *required*. >>>> >>>> None of what we do will be required; it will all be voluntary. They >>>>key >>>> is to enable the endpoint to publish changes based on events. How that >>>> published data gets processed and persisted is a downstream concern. >>>>The >>>> architecture should allow for a variety of solutions that handle the >>>> info in various ways providing organizations and vendors with some >>>> flexibility in deployed architectures. What we want is a reasonable >>>> degree of interoperability with regards to the individual components. >>>> >>>>>> Performing scans in a periodic way is not continuous or very >>>>>> effective. For >>>>> scanning to be effective here, the scanning rate needs to be twice as >>>>> frequent as the rate of change to have a chance of detecting a >>>>> sophisticated >>>>> attacker. Anything happening between samples/scans can compromise the >>>>> endpoints ability to give truthful answers. This is a good case for >>>>> event-driven >>>>> data reporting where the changes is reported as soon as it happens. >>>>> This >>>>> type of reporting has a chance of occurring before the attacker can >>>>> compromise the collector. >>>>> >>>>> Just to be clear, Dave, the rule you refer to here works for things >>>>> like >>>>> determining the sample rate for audio, but does not apply here. >>>>> >>>>> What we want to minimize is the window of opportunity to exploit an >>>>> exposure, which is the amount of time between when a configuration >>>>>item >>>>> changed (or the announcement of a new vulnerability) and when it is >>>>> detected and remediated. The *average* time between when an item >>>>> changed and when it is detected would be 1/2 the sampling rate. >>>>> >>>>> If your "rate of change" is, for example, monthly, and you therefore >>>>> set your >>>>> periodic rescan for every two weeks, you still have an average time >>>>>of >>>>> exposure of a week and a worst case of two weeks. >>>> >>>> It doesn't apply if you define the window as the organizational change >>>> window. It does apply if you think about it as the attack window. >>>>Most >>>> attacks will go unnoticed if the scanning occurs hourly. In this >>>> scenario the attacker can get in, make changes, exfiltrate >>>>information, >>>> and then cleanup restoring things to the previous state within the >>>>hour >>>> period. >>>> >>>>> Which only supports further your focus on bottom-up change detection >>>>> from >>>>> the endpoints. >>>> >>>> Yes. I want to make sure that the standards we produce don't expose >>>> organizations unnecessarily if there is a more effective way. ;-) I am >>>> pushing to expand the scanning mindset to think about how we can >>>> approach this problem space in a way that enables a variety of >>>> techniques. The legacy work that has been done in this space gets us a >>>> good way there. We have a variety of mechanisms that enable classes >>>>of >>>> configurations that are security relevant to be identified and >>>> described. These can be used to identify relevant change events. What >>>> is missing are the standards that describe how you implement protocols >>>> that enable endpoint data exchange that support both scanning tasks >>>>and >>>> event driven publication. There are existing protocols such as NEA >>>>that >>>> can enable both techniques if we do the work to identify the specifics >>>> of messaging. I would expect a similar approach would also enable >>>> incremental scan results as well. >>>> >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >> From dromasca@avaya.com Thu Jul 25 04:30:07 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3501A21F9A96 for ; Thu, 25 Jul 2013 04:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.919 X-Spam-Level: X-Spam-Status: No, score=-102.919 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drN9R4aoIzC3 for ; Thu, 25 Jul 2013 04:30:01 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id B2C0C21F9993 for ; Thu, 25 Jul 2013 04:30:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAIEL8VHGmAcV/2dsb2JhbABagmUhNVC9XYEYFnSCJgEBAxIoUQEVFRRCJgEEGxqHbgELmHKEQpt4EwSPTINKbgOeJYsHgxSCKg X-IronPort-AV: E=Sophos;i="4.89,742,1367985600"; d="scan'208";a="21514745" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 25 Jul 2013 07:30:01 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Jul 2013 07:27:26 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 07:29:59 -0400 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: SACM at IETF-87 Thread-Index: Ac6JJzBSce6/ymYGTkqKxM/WLPaAAg== Date: Thu, 25 Jul 2013 11:29:59 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128810ED@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] SACM at IETF-87 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 11:30:07 -0000 Hi,=20 IETF-87 is only a few days away. The SACM WG is scheduled to meet on Friday= , August 2. The agenda is available at https://datatracker.ietf.org/meeting= /87/agenda/sacm/. All presenters who plan to use slides - please send us your slides BEFORE t= he meeting, to allow remote and on-site participants to download and read t= hem in advance.=20 We will need two note-takers and one jabber scribe. Please volunteer in adv= ance so that we do not waste precious time in the meeting.=20 As announced we shall hold an informal welcome and introduction meeting for= the first time participants in the WG at breakfast time on Thursday, Augus= t 1st. Unless announced differently we shall meet at 8AM at the entry of th= e breakfast space at the Intercontinental (meeting hotel).=20 We are looking forward to see you in Berlin.=20 Regards, Adam and Dan =20 From athiasjerome@gmail.com Thu Jul 25 06:06:32 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F5621F97E6 for ; Thu, 25 Jul 2013 06:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shnvSN58rsGx for ; Thu, 25 Jul 2013 06:06:32 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 01AD121F96A8 for ; Thu, 25 Jul 2013 06:06:31 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id 6so685092bkj.31 for ; Thu, 25 Jul 2013 06:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=23LgQiUdAr5xYG4Lfa10Zn6neG1c9qlMAh6wT83nzNI=; b=vaFZLtDPUUpRAl7PdMvGE3vLVmXXWZrAix0UPCFy7bX8qe/lxDpCPJu4+K+MZWsJyf HDO5AP2Y3FYHe0ECl1WqG3S5rINcv/rke7YTUFjJLXE/PbfOUxRqOkKF/LntQy+Y33LC dpal7A0MA5Hae1NCkp3A+1ipAqTMrqXz6/kxkHHkoyiOiQajb5wevr5NJaMv9acDQPEC 9sSYuJS38qxLDEzE5t7cXflvU6/i5Wmn+ENIYD4wtjUeYWbyt00+jZXGCXmoBz+gEvgI zh6N2vlegnNhfWBse0abZQ6V4IGuFPwsQu2RRbJLQG8wuti3ytB9PU8HgfdwfmIfl9oF 1CPQ== X-Received: by 10.204.56.65 with SMTP id x1mr6335387bkg.152.1374757589694; Thu, 25 Jul 2013 06:06:29 -0700 (PDT) Received: from [192.168.1.114] ([91.73.38.83]) by mx.google.com with ESMTPSA id ps10sm11064037bkb.14.2013.07.25.06.06.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 06:06:28 -0700 (PDT) From: Jerome Athias Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <1EB459D8-8A8A-481B-9409-3537576ABA8E@gmail.com> Date: Thu, 25 Jul 2013 16:56:06 +0400 To: "sacm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [sacm] XORCISM eXtensible Open Research on Cyber Information Security Models X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 13:06:33 -0000 Hi, I would appreciate any feedback on this research. http://mcaf.ee/31d9q Thank you Best regards Jerome Athias From athiasjerome@gmail.com Thu Jul 25 06:07:02 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC3021F9AD8 for ; Thu, 25 Jul 2013 06:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACCWBQlbdU-f for ; Thu, 25 Jul 2013 06:07:01 -0700 (PDT) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CF02F21F96A8 for ; Thu, 25 Jul 2013 06:06:45 -0700 (PDT) Received: by mail-bk0-f43.google.com with SMTP id jm2so216180bkc.16 for ; Thu, 25 Jul 2013 06:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=23LgQiUdAr5xYG4Lfa10Zn6neG1c9qlMAh6wT83nzNI=; b=ZqbU+GJBA3f8uUm0Jhn/G9Tjn4YJtHA/jQNB3A4VkiUrizqpM4aGnofGXdajsJ9ygs 2+FhV8CD2tRGxUD35aUYWDApdY0PwXNjrV59/nlwyOJo9mUx94gn1dza9OC1i19zZHZq Pr5EbqxSNcqrkOW/jakZaei5XkqfFdsP9mddj9dk+7UpktK4znlzkUUxQ+wo5+GDTwj9 Lem4I3gt9MZjLXjEc+e6leEMQSvfB2kZCXew0C5JIyyA7UtZuXDa9udiNtiPvKeV5xkO vYkAH87npQnUohQey1v9FaC1Wfp04/KP1qr03U9SvynHikW/umROp8k/Iv0dO/Safp4+ u85A== X-Received: by 10.205.7.6 with SMTP id om6mr2834129bkb.18.1374757603690; Thu, 25 Jul 2013 06:06:43 -0700 (PDT) Received: from [192.168.1.114] ([91.73.38.83]) by mx.google.com with ESMTPSA id ps10sm11064037bkb.14.2013.07.25.06.06.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 06:06:42 -0700 (PDT) From: Jerome Athias Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <2D0355FA-CE08-40DD-8D3C-2B1021FCB675@gmail.com> Date: Thu, 25 Jul 2013 17:03:48 +0400 To: "sacm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [sacm] XORCISM eXtensible Open Research on Cyber Information Security Models X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 13:07:02 -0000 Hi, I would appreciate any feedback on this research. http://mcaf.ee/31d9q Thank you Best regards Jerome Athias From dromasca@avaya.com Thu Jul 25 06:41:13 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E37221F91CB for ; Thu, 25 Jul 2013 06:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.365 X-Spam-Level: X-Spam-Status: No, score=-103.365 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbz17zZNW-1d for ; Thu, 25 Jul 2013 06:41:05 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 22DA021F91BF for ; Thu, 25 Jul 2013 06:41:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8HAIsq8VGHCzI1/2dsb2JhbABQBwOCQiMhNVCpUpQMgRcWdIIkAQEBAQMSCBNcAgEIDQEDBAEBCxYBBgcyFAMBBQgBAQQBEggNDYdcAw8BC50Xkx8IiEwXjj0HEnYhCwsBBguDAW4DlAiFAIUdiweDFIIq X-IronPort-AV: E=Sophos;i="4.89,743,1367985600"; d="scan'208,217";a="20993004" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 Jul 2013 09:40:57 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Jul 2013 09:34:38 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 09:40:56 -0400 From: "Romascanu, Dan (Dan)" To: David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] Use Cases Style Thread-Index: Ac6GQp344HxcyhkLR3e12+XSKp8ZmgC+OvBQ Date: Thu, 25 Jul 2013 13:40:55 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12881204@AZ-FFEXMB04.global.avaya.com> References: <005701ce8649$b5dd8010$21988030$@comcast.net> In-Reply-To: <005701ce8649$b5dd8010$21988030$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA12881204AZFFEXMB04globa_" MIME-Version: 1.0 Subject: Re: [sacm] Use Cases Style X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 13:41:13 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA12881204AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am certainly culturally biased in this dispute for the very simple and ob= vious reason that I have spent too much time in the IETF and too little to = zero time in other security-oriented organizations, so I am familiar with t= he 'IETF approach' while the 'usability.gov approach' seems strange to me. I do have however one question that seems to me to go beyond the 'style' is= sues. The usability.gov examples include definition and actions (procedures= ) executed by actors who are I believe what we call in IETF terms 'human op= erators' using the network and the systems. It is very seldom that the IETF= defines anything that deals with human operators actions in standards-trac= k documents. At most we may make operational recommendations, never beyond = the BCP level. Maybe this discussion is useful to clarify the use cases, but I do not see = how the 'actors' actions fit into the current WG charter. Am I mistaken? Do= I miss something important? Thanks and Regards, Dan From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Dav= id Harrington Sent: Sunday, July 21, 2013 10:37 PM To: sacm@ietf.org Subject: [sacm] Use Cases Style Hi, There has been some debate about the amount of detail and the formality of = the format used in our use cases document. I have argued for IETF-style use cases; Adam has argued for a systems engin= eering style, recommending the Martin Fowler format. The IETF approach: I recommended that people look at other IETF Use Case documents to see what= is "normal" for IETF use case documents. Knowing that everybody is busy, I assumed few if any would actually do so. So to move the discussion forward, I searched for RFCs with "Use Case" in t= he title. Then I looked at each, and copied a quote from the text about the purpose = of each document (where available) I then copied in a sample use case from each document. I was planning to make these into a PowerPoint presentation (I expected tha= t would be very hard to do, given the space limitations of a slide). So I chose short examples. Feel free to look at longer examples if you want. My samples of IETF use cases are in the attached file. The usability.gov approach (http://www.usability.gov/how-to-and-tools/metho= ds/use-cases.html) Elements of a Use Case Depending on how in depth and complex you want or need to get, use cases de= scribe a combination of the following elements: *Actor - anyone or anything that performs a behavior (who is using the syst= em) *Stakeholder - someone or something with vested interests in the behavior o= f the system under discussion (SUD) *Primary Actor - stakeholder who initiates an interaction with the system t= o achieve a goal *Preconditions - what must be true or happen before and after the use case = runs. *Triggers - this is the event that causes the use case to be initiated. *Main success scenarios [Basic Flow] - use case in which nothing goes wrong= . *Alternative paths [Alternative Flow] - these paths are a variation on the = main theme. These exceptions are what happen when things go wrong at the sy= stem level. How To Write a Use Case Write the steps in a use case in an easy-to-understand narrative. Kenworthy= (1997) outlines the following steps: 1. Identify who is going to be using the website. 2. Pick one of those users. 3. Define what that user wants to do on the site. Each thing the use = does on the site becomes a use case. 4. For each use case, decide on the normal course of events when that= user is using the site. 5. Describe the basic course in the description for the use case. Des= cribe it in terms of what the user does and what the system does in respons= e that the user should be aware of. 6. When the basic course is described, consider alternate courses of = events and add those to "extend" the use case. 7. Look for commonalities among the use cases. Extract these and note= them as common course use cases. 8. Repeat the steps 2 through 7 for all other users. Middleweight Laundry Use Case Use Case 1: Do laundry Actor: Housekeeper Basic Flow: On Wednesdays, the housekeeper reports to the laundry room. Sh= e sorts the laundry that is there. Then she washes each load. She dries e= ach load. She folds the items that need folding. She throws away any laund= ry item that is irrevocably shrunken, soiled or scorched. Alternative Flow 1: If she notices that something is wrinkled, she irons it= and then hangs it on a hanger. Alternative Flow 2: If she notices that something is still dirty, she rewas= hes it. Alternative Flow 3: If she notices that something shrank, she throws it out= . Adam's example use case: Use Case Name: Suspicious Endpoint Behavior Description: This Use Case describes the collaboration between specific participants in = an information security system specific to detecting a connection attempt t= o a known-bad Internet host by a botnet zombie that has made its way onto a= n organization's Information Technology systems. The primary human actor i= s the Security Operations Center Analyst, and the primary software actor is= the configuration assessment tool. Note, however, the dependencies on oth= er tools, such as asset management, intrusion detection, and messaging. Actors: * Security Operations Center (SOC) Analyst, * Information Security Officer, * System Owner * Organizational Unit Leader Preconditions: * Organizational Security Policy Exists * Security Policy specifies appropriate asset management capabilities (i= .e. categorization of endpoints) * Security Policy specifies endpoint configuration baseline for asset ca= tegorization * The Organization keeps a list of known-bad Internet hosts * The Organization associates owners who are individuals with endpoints * The Organization associates organizational units with endpoints Postconditions: * Endpoint configuration has been assessed [1] * Results have been conveyed to scan requester Primary Path: 1. At 03:46 UTC an organization's Network Intrusion Detection System (NID= S) sees an IP packet with a destination IPv6 address existing on a blacklis= t of known botnet command and control (C2) servers. 2. The NIDS sends an alert to the SOC Analyst. 3. The SOC Analyst uses the information captured in the alert (IP packet = and reason for the flag) to look up the endpoint in the organization's asse= t inventory system and discovers that the endpoint is a Windows Server 2008= R2 Member Server playing the role of a File Server 4. The SOC Analyst also verifies that the IPv6 address cited by the NIDS = is, in fact, on the blacklist for known C2 servers. 5. At this point, the SOC Analyst switches over to the organization's con= figuration assessment tool 6. The SOC Analyst locates the offending endpoint in the configuration as= sessment tool's endpoint catalog [2] 7. The SOC Analyst then initiates an immediate and complete endpoint asse= ssment to determine if the endpoint has experienced any configuration drift= [3]. 8. The configuration assessment tool: 9. a. Performs a preliminary asset inventory scan on the offending endpoin= t, which results in a list of installed software [4][5] b. Performs a comparison between the last known asset inventory and the= present asset inventory and notes any differences c. Searches it's local content repository for appropriate configuration= baselines for the operating system of the offending endpoint and for each = installed piece of software d. Upon aggregating the set of applicable configuration baselines, the = configuration assessment tool then connects to and queries the organization= 's configuration content repository for newer baselines that may exist. e. If a new baseline exists, then it is returned by the configuration c= ontent repository. 10. The configuration management tool, having the set of updated baseline= s, initiates a scan against the offending host, which yields a result set. 11. The configuration management tool displays scan results to the SOC An= alyst, which show that three new pieces of software have been installed on = the offending endpoint where one piece of software is not on the authorized= software list, and that several configuration items were out of compliance= with the organization's established baselines. 12. The SOC Analyst reviews the information for accuracy and to plan next= steps before sending the report to the responsible Information Security Of= ficer, accountable System Owner, and the Organizational Unit Leader. A Note On Alternative Paths, Preconditions, and Postconditions: There are likely to be many points of optimization and optional paths. For= example, a configuration assessment tool might provide a "quick glance" lo= ok at the most recent scan history for the offending endpoint. A SOC Analy= st might then elect not to run a new scan (i.e. the offending endpoint is k= nown to be out of compliance, so why run a new scan?). Another point might= be that the offending endpoint is, at present, not authorized to be on the= network, in which case it is very likely not to exist in the configuration= assessment tool's endpoint catalog. As with alternative paths, pre-/post-conditions can vary widely. Consider = that this description likely represents an organization on the mature side = of managing information security. Many organizations do not have a Securit= y Operations Center, nor do they necessarily monitor their network. It may= be the case that a log management process has detected the blacklisted con= nection attempt through audit trail monitoring. Or, it may be the case th= at a shared indicator of compromise has been used to detect the offending e= ndpoint. ------------------- [1] I am assuming at this point that "configuration assessment" has been de= fined and will be understood by the reader. What I consider to be "assessm= ent" is that the baseline has been obtained, send to the scanning implement= ation, endpoint configuration item values have been harvested, endpoint con= figuration item values have been compared against baseline, and results sto= red/forwarded as appropriate for the use case. [2] An "endpoint catalog" is intended to convey nothing more than the notio= n that configuration assessment tools are likely to have some method of lis= ting, enumerating, or aggregating endpoints under configuration management. [3] It may not be necessary to specify what we mean by "complete" or the or= der in which scanning operations take place. In this particular scenario, = I thought it might be useful to illustrate that "scan levels" exist on a co= ntinuum. [4] Remember that the configuration assessment tool has knowledge of the of= fending endpoint so running a preliminary inventory scan is reasonable at t= his point. [5] The mechanism of scan could be agent-based or remote, so details of how= a scan happens are omitted here. A more granular partition of the process= is required for further details. This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissemi= nation, distribution or copying of this message and attachments is strictly= prohibited. Please notify the sender immediately and permanently delete t= he message and any attachments. My Comments: Executive Summary: The IETF format is what most IETF readers will expect. This format has the = drawback of not being formal, and is not necessarily very complete. If we t= o derive requirements from this freehand format, it can be more difficult. = But it is easily readable, so reviewers of our work can understand what we = are trying to accomplish. Use cases of this form help to identify the natur= e of the stakeholders involved in our WG. Operators vs vendors, service pro= viders vs enterprises, managed-device implementers vs management applicatio= n developers, and so on. This can help to categorize requirements that exis= t for some stakeholders but not all stakeholders. I think the formal approach recommended in usability.gov would be more work= for the editors to lay out the use cases in this formal format, and the AS= CII text required for RFCs makes this much harder than, say Word or HTML fo= rmats. Usability.gov step 2 says "pick one of the users" to document as the actor.= Each thing the user wants to do becomes a use case, and each possible alte= rnative action becomes a use case. Adam's example for Actor includes multiple roles, and then describes a rath= er complex use case , including footnotes. Part of my concern is that we have WG contributors coming from multiple ven= dors, with possibly multiple products, representing customers from multiple= industry segments. To fully detail each possible alternative would make it close to impossible= to actually finish this document in a reasonable amount of time. I suspect Adam combined a number of use cases together in his example, to s= implify things. However, I cannot figure out how to create English sentences from his examp= le because he has multiple actors and multiple preconditions and multiple p= ostconditions, and what seems to be a lot of irrelevant details in the Prim= ary Path. Is the fact that this happens at 3:46 UTC an important detail in = our design? Or is it an irrelevant detail? Or is it important for some use = cases (such as trying to establish behavior anomalies based on when a user = normally works, or when an attack normally happens?) but not others? I think the formal approach is over the top for our needs. The IETF approach seems more appropriate at this point in our work process. David Harrington dbharrington@comcast.net +1-603-828-1401 --_000_9904FB1B0159DA42B0B887B7FA8119CA12881204AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I am certainly cultura= lly biased in this dispute for the very simple and obvious reason that I ha= ve spent too much time in the IETF and too little to zero time in other sec= urity-oriented organizations, so I am familiar with the ‘IETF approach’ while the ‘usab= ility.gov approach’ seems strange to me= .

 

I do have however one = question that seems to me to go beyond the ‘style’ issues. The = usability.gov examples include definition and actions (procedures) executed= by actors who are I believe what we call in IETF terms ‘human operators’ using the network and the systems. It = is very seldom that the IETF defines anything that deals with human operato= rs actions in standards-track documents. At most we may make operational re= commendations, never beyond the BCP level.

 

Maybe this discussion = is useful to clarify the use cases, but I do not see how the ‘actors&= #8217; actions fit into the current WG charter. Am I mistaken? Do I miss so= mething important?

 

Thanks and Regards,

 

Dan<= /p>

 

 

 

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington
Sent: Sunday, July 21, 2013 10:37 PM
To: sacm@ietf.org
Subject: [sacm] Use Cases Style

 

Hi,

 

There has been some debate about the amount of de= tail and the formality of the format used in our use cases document.

I have argued for IETF-style use cases; Adam has = argued for a systems engineering style, recommending the Martin Fowler form= at.

 

The IETF approach:

 

I recommended that people look at other IETF Use = Case documents to see what is "normal" for IETF use case document= s.

Knowing that everybody is busy, I assumed few if = any would actually do so.

So to move the discussion forward, I searched for= RFCs with "Use Case" in the title.

Then  I looked at each, and copied a quote f= rom the text about the purpose of each document (where available)

 

I then copied in a sample use case from each docu= ment.

I was planning to make these into a PowerPoint pr= esentation (I expected that would be very hard to do, given the space limit= ations of a slide).

So I chose short examples.

Feel free to look at longer examples if you want.=

 

My samples of IETF use cases are in the attached = file.

The usability.gov approach (http://www.usability.gov/how-to-and-tools= /methods/use-cases.html)

 

Elements of a Use Case

 

Depending on how in depth and complex you want or= need to get, use cases describe a combination of the following elements:

•Actor – anyone or anything that perf= orms a behavior (who is using the system)

•Stakeholder – someone or something w= ith vested interests in the behavior of the system under discussion (SUD)

•Primary Actor – stakeholder who init= iates an interaction with the system to achieve a goal

•Preconditions – what must be true or= happen before and after the use case runs.

•Triggers – this is the event that ca= uses the use case to be initiated.

•Main success scenarios [Basic Flow] –= ; use case in which nothing goes wrong.

•Alternative paths [Alternative Flow] ̵= 1; these paths are a variation on the main theme. These exceptions are what= happen when things go wrong at the system level.

 

How To Write a Use Case

 

Write the steps in a use case in an easy-to-understa= nd narrative. Kenworthy (1997) outlines the following steps:

1.     &= nbsp; Identify who is going to b= e using the website.

2.     &= nbsp; Pick one of those users.

3.     &= nbsp; Define what that user want= s to do on the site. Each thing the use does on the site becomes a use case= .

4.     &= nbsp; For each use case, decide = on the normal course of events when that user is using the site.=

5.     &= nbsp; Describe the basic course = in the description for the use case. Describe it in terms of what the user = does and what the system does in response that the user should be aware of.=

6.     &= nbsp; When the basic course is d= escribed, consider alternate courses of events and add those to "exten= d" the use case.

7.     &= nbsp; Look for commonalities amo= ng the use cases. Extract these and note them as common course use cases.

8.     &= nbsp; Repeat the steps 2 through= 7 for all other users.

 

Middleweight Laundry Use Case

 

Use Case 1: Do laundry

Actor: Housekeeper

Basic Flow: On Wednesdays, the housekeeper report= s to the laundry room.  She sorts the laundry that is there.  The= n she washes each load.  She dries each load. She folds the items that= need folding.  She throws away any laundry item that is irrevocably shrunken, soiled or scorched.

Alternative Flow 1: If she notices that something= is wrinkled, she irons it and then hangs it on a hanger.

Alternative Flow 2: If she notices that something= is still dirty, she rewashes it.

Alternative Flow 3: If she notices that something= shrank, she throws it out.

 

Adam's example use case:

Use Case Name: Suspicious Endpoint Behavior<= /o:p>

 

Description:

This Use Case describes the collaboration between= specific participants in an information security system specific to detect= ing a connection attempt to a known-bad Internet host by a botnet zombie th= at has made its way onto an organization's Information Technology systems.  The primary human actor is the Secur= ity Operations Center Analyst, and the primary software actor is the config= uration assessment tool.  Note, however, the dependencies on other too= ls, such as asset management, intrusion detection, and messaging.

 

 

Actors:

 

   * Security Operations Center (SOC) A= nalyst,

   * Information Security Officer,=

   * System Owner

   * Organizational Unit Leader

 

Preconditions:

 

 

   * Organizational Security Policy Exi= sts

   * Security Policy specifies appropri= ate asset management capabilities (i.e. categorization of endpoints)

   * Security Policy specifies endpoint= configuration baseline for asset categorization

   * The Organization keeps a list of k= nown-bad Internet hosts

   * The Organization associates owners= who are individuals with endpoints

   * The Organization associates organi= zational units with endpoints

 

Postconditions:

 

   * Endpoint configuration has been as= sessed [1]

   * Results have been conveyed to scan= requester

 

Primary Path:

 

  1. At 03:46 UTC an organization's Network = Intrusion Detection System (NIDS) sees an IP packet with a destination IPv6= address existing on a blacklist of known botnet command and control (C2) s= ervers.

 

  2. The NIDS sends an alert to the SOC Anal= yst.

 

  3. The SOC Analyst uses the information ca= ptured in the alert (IP packet and reason for the flag) to look up the endp= oint in the organization's asset inventory system and discovers that the en= dpoint is a Windows Server 2008 R2 Member Server playing the role of a File Server

 

  4. The SOC Analyst also verifies that the = IPv6 address cited by the NIDS is, in fact, on the blacklist for known C2 s= ervers.

 

  5. At this point, the SOC Analyst switches= over to the organization's configuration assessment tool

 

  6. The SOC Analyst locates the offending e= ndpoint in the configuration assessment tool's endpoint catalog [2]

 

  7. The SOC Analyst then initiates an immed= iate and complete endpoint assessment to determine if the endpoint has expe= rienced any configuration drift [3].

 

  8. The configuration assessment tool:=

 

  9.

    a. Performs a preliminary= asset inventory scan on the offending endpoint, which results in a list of= installed software [4][5]

    b. Performs a comparison betwe= en the last known asset inventory and the present asset inventory and notes= any differences

    c. Searches it's local content= repository for appropriate configuration baselines for the operating syste= m of the offending endpoint and for each installed piece of software

    d. Upon aggregating the set of= applicable configuration baselines, the configuration assessment tool then= connects to and queries the organization's configuration content repositor= y for newer baselines that may exist.

    e. If a new baseline exists, t= hen it is returned by the configuration content repository.

 

  10. The configuration management tool, hav= ing the set of updated baselines, initiates a scan against the offending ho= st, which yields a result set.

 

  11. The configuration management tool disp= lays scan results to the SOC Analyst, which show that three new pieces of s= oftware have been installed on the offending endpoint where one piece of so= ftware is not on the authorized software list, and that several configuration items were out of compliance with the= organization's established baselines.

 

  12. The SOC Analyst reviews the informatio= n for accuracy and to plan next steps before sending the report to the resp= onsible Information Security Officer, accountable System Owner, and the Org= anizational Unit Leader.

 

 

A Note On Alternative Paths, Preconditions, and P= ostconditions:

There are likely to be many points of optimizatio= n and optional paths.  For example, a configuration assessment tool mi= ght provide a "quick glance" look at the most recent scan history= for the offending endpoint.  A SOC Analyst might then elect not to run a new scan (i.e. the offending endpoint is known to = be out of compliance, so why run a new scan?).  Another point might be= that the offending endpoint is, at present, not authorized to be on the ne= twork, in which case it is very likely not to exist in the configuration assessment tool's endpoint catalog.=

 

 

As with alternative paths, pre-/post-conditions c= an vary widely.  Consider that this description likely represents an o= rganization on the mature side of managing information security.  Many= organizations do not have a Security Operations Center, nor do they necessarily monitor their network.  It may be the= case that a log management process has detected the blacklisted connection= attempt  through audit trail monitoring.  Or, it may be the case= that a shared indicator of compromise has been used to detect the offending endpoint.

 

 

-------------------

[1] I am assuming at this point that "config= uration assessment" has been defined and will be understood by the rea= der.  What I consider to be "assessment" is that the baselin= e has been obtained, send to the scanning implementation, endpoint configuration item values have been harvested, endpoint configuration item= values have been compared against baseline, and results stored/forwarded a= s appropriate for the use case.

 

 

[2] An "endpoint catalog" is intended t= o convey nothing more than the notion that configuration assessment tools a= re likely to have some method of listing, enumerating, or aggregating endpo= ints under configuration management.

 

 

[3] It may not be necessary to specify what we me= an by "complete" or the order in which scanning operations take p= lace.  In this particular scenario, I thought it might be useful to il= lustrate that "scan levels" exist on a continuum. 

 

 

[4] Remember that the configuration assessment to= ol has knowledge of the offending endpoint so running a preliminary invento= ry scan is reasonable at this point.

 

 

[5] The mechanism of scan could be agent-based or= remote, so details of how a scan happens are omitted here.  A more gr= anular partition of the process is required for further details.=

 

This message and attachments may contain confiden= tial information.  If it appears that this message was sent to you by = mistake, any retention, dissemination, distribution or copying of this mess= age and attachments is strictly prohibited.  Please notify the sender immediately and permanently delete the message an= d any attachments.

 

My Comments:

Executive Summary:

The IETF format is what most IETF readers will expec= t. This format has the drawback of not being formal, and is not necessarily= very complete. If we to derive requirements from this freehand format, it = can be more difficult. But it is easily readable, so reviewers of our work can understand what we are trying to ac= complish. Use cases of this form help to identify the nature of the stakeho= lders involved in our WG. Operators vs vendors, service providers vs enterp= rises, managed-device implementers vs management application developers, and so on. This can help to categori= ze requirements that exist for some stakeholders but not all stakeholders.<= o:p>

 

I think the formal approach recommended in usability= .gov would be more work for the editors to lay out the use cases in this fo= rmal format, and the ASCII text required for RFCs makes this much harder th= an, say Word or HTML formats.

Usability.gov step 2 says “pick one of the use= rs” to document as the actor. Each thing the user wants to do becomes= a use case, and each possible alternative action becomes a use case.<= /o:p>

Adam’s example for Actor includes multiple rol= es, and then describes a rather complex use case , including footnotes.

 

Part of my concern is that we have WG contributors c= oming from multiple vendors, with possibly multiple products, representing = customers from multiple industry segments.

To fully detail each possible alternative would make= it close to impossible to actually finish this document in a reasonable am= ount of time.

I suspect Adam combined a number of use cases togeth= er in his example, to simplify things.

However, I cannot figure out how to create English s= entences from his example because he has multiple actors and multiple preco= nditions and multiple postconditions, and what seems to be a lot of irrelev= ant details in the Primary Path. Is the fact that this happens at 3:46 UTC an important detail in our design? = Or is it an irrelevant detail? Or is it important for some use cases (such = as trying to establish behavior anomalies based on when a user normally wor= ks, or when an attack normally happens?) but not others?

 

I think the formal approach is over the top for our = needs.

The IETF approach seems more appropriate at this poi= nt in our work process.

 

 

David Harrington

dbhar= rington@comcast.net

+1-603-828-1401

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA12881204AZFFEXMB04globa_-- From dromasca@avaya.com Thu Jul 25 07:04:53 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB3621F9AE7 for ; Thu, 25 Jul 2013 07:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.383 X-Spam-Level: X-Spam-Status: No, score=-103.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuhOT7oY6xRa for ; Thu, 25 Jul 2013 07:04:43 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 9E90721F9AAB for ; Thu, 25 Jul 2013 07:04:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsKAG8v8VGHCzI1/2dsb2JhbABXA4JlITVQvVoDAYEWFnSCJAEBAQEDAQEBDyg0BhEEAgEIDQQBAwEBCxQJBycLFAMGCAEBBAESCBEJh1wDDwELnSeTHwiITBMEjj5lKSEXBguDAW4DniWLB4MUgXE5 X-IronPort-AV: E=Sophos;i="4.89,743,1367985600"; d="scan'208";a="20997238" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 Jul 2013 10:04:42 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Jul 2013 09:58:23 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 10:04:41 -0400 From: "Romascanu, Dan (Dan)" To: ietfdbh , "sacm@ietf.org" Thread-Topic: [sacm] use cases versus requirements Thread-Index: Ac6Bn+SjZJU/sGdFQne0jP4cUc2TpgHnN8NA Date: Thu, 25 Jul 2013 14:04:40 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12881264@AZ-FFEXMB04.global.avaya.com> References: <00ff01ce81ab$602bb170$20831450$@comcast.net> In-Reply-To: <00ff01ce81ab$602bb170$20831450$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] use cases versus requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 14:04:53 -0000 Hi, Thanks for the effort invested until now into trying to sort out use cases = and requirements.=20 The document has already some good parts which I believe are very useful - = for example the terminology section.=20 Is my understanding correct that from 04 to 05 we started to transition fro= m the initial top-down ('theoretical') approach used in the initial version= s of the document to a bottom-up approach, collecting real-life use cases, = describing, sorting, consolidating them, and deriving the requirements from= here? If so should we expect to see the couple of use cases proposed durin= g the last week by Adam on the list by Adam be added to the use cases (toge= ther with other that will come)? If I am correct the efforts should be now = channeled towards adding use cases to section 3 making sure that all import= ant use cases are covered while keeping the list at a low and manageable si= ze, and in parallel fill in with content section 4 that covers requirements= .=20 What is the opinion of the WG participants - is the structure of section 4 = right or aproximatively right?=20 I would like to see the requirements in the requirement sections numbered! Regards, Dan =20 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > ietfdbh > Sent: Tuesday, July 16, 2013 1:34 AM > To: sacm@ietf.org > Subject: [sacm] use cases versus requirements >=20 > Hi, >=20 > I looked up the BOF summaries from November and March. > The summary from November says " The consensus was to start from > requirements and then develop an architecture to explain how the use > cases can be met. The group has a fairly good understanding of the > problem space, but needs to document this and present it more clearly > with the requirements, then the architecture. These steps need to > happen to progress the work." Are we paying enough attention to the > requirements stage? We don't have a requirements doc, and that might be > helpful. >=20 > The summary is unclear about which comes first - use cases or > requirements. >=20 > The -04- version of use cases had very high-level uses cases, and then > defined concepts and requirements from the three abstract use cases, in > a top-down approach that led to organizing the document by (theoretical) > requirements and then finding use cases as supporting examples of the > requirements. As I mentioned in my previous email, I think we should be > working in the IETF bottom-up approach, looking at multiple real-world > implementation/deployment use cases and deriving requirements from the > aggregation of use cases. >=20 > The -05- version of use cases shows the lack of clarity about how this > should be approached (and the lack of time as the deadline approached). >=20 > Comments welcome. >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From Adam.Montville@cisecurity.org Thu Jul 25 07:31:23 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FF321F9A4C for ; Thu, 25 Jul 2013 07:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Prkd1RtoYPA for ; Thu, 25 Jul 2013 07:31:18 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.109]) by ietfa.amsl.com (Postfix) with ESMTP id 289D521F99E3 for ; Thu, 25 Jul 2013 07:31:18 -0700 (PDT) Received: from [216.82.253.243:27461] by server-13.bemta-7.messagelabs.com id 19/FA-01054-4B631F15; Thu, 25 Jul 2013 14:31:16 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-12.tower-171.messagelabs.com!1374762674!317792!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 10731 invoked from network); 25 Jul 2013 14:31:14 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-12.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 25 Jul 2013 14:31:14 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 25 Jul 2013 10:30:55 -0400 From: Adam Montville To: "Romascanu, Dan (Dan)" , ietfdbh , "sacm@ietf.org" Thread-Topic: [sacm] use cases versus requirements Thread-Index: Ac6Bn+SjZJU/sGdFQne0jP4cUc2TpgHnN8NAAAGVkaA= Date: Thu, 25 Jul 2013 14:30:56 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6737845@CISEXCHANGE1.msisac.org.local> References: <00ff01ce81ab$602bb170$20831450$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12881264@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12881264@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] use cases versus requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 14:31:23 -0000 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Thursday, July 25, 2013 7:05 AM > To: ietfdbh; sacm@ietf.org > Subject: Re: [sacm] use cases versus requirements >=20 > Hi, >=20 > Thanks for the effort invested until now into trying to sort out use cas= es and > requirements. +1 >=20 > The document has already some good parts which I believe are very useful= - > for example the terminology section. >=20 > Is my understanding correct that from 04 to 05 we started to transition = from > the initial top-down ('theoretical') approach used in the initial versio= ns of the > document to a bottom-up approach, collecting real-life use cases, descri= bing, > sorting, consolidating them, and deriving the requirements from here? If= so > should we expect to see the couple of use cases proposed during the last= > week by Adam on the list by Adam be added to the use cases (together wit= h > other that will come)? If I am correct the efforts should be now channel= ed > towards adding use cases to section 3 making sure that all important use= > cases are covered while keeping the list at a low and manageable size, a= nd in > parallel fill in with content section 4 that covers requirements. +1=20 The use cases I presented need not be included if we believe we have a sui= table use case sampling already. If they are included, then they can be "= trimmed" to be less specific, if warranted. =20 I also believe we should understand that many of the use cases can be sati= sfied, in part, with existing specifications - not all of them, but many. = IMO, the value of the use cases at this point is to ensure that what we'r= e building meets the requirements from the driving needs of the enterprise= . >=20 > What is the opinion of the WG participants - is the structure of section= 4 right > or aproximatively right? I was reviewing the document yesterday evening and I like the structure my= self - just an opinion of one, though. >=20 > I would like to see the requirements in the requirement=20sections numbe= red! +1 >=20 > Regards, >=20 > Dan >=20 >=20 >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of ietfdbh > > Sent: Tuesday, July 16, 2013 1:34 AM > > To: sacm@ietf.org > > Subject: [sacm] use cases versus requirements > > > > Hi, > > > > I looked up the BOF summaries from November and March. > > The summary from November says " The consensus was to start from > > requirements and then develop an architecture to explain how the use > > cases can be met. The group has a fairly good understanding of the > > problem space, but needs to document this and present it more clearly > > with the requirements, then the architecture. These steps need to > > happen to progress the work." Are we paying enough attention to the > > requirements stage? We don't have a requirements doc, and that might > > be helpful. > > > > The summary is unclear about which comes first - use cases or > > requirements. > > > > The -04- version of use cases had very high-level uses cases, and then= > > defined concepts and requirements from the three abstract use cases, > > in a top-down approach that led to organizing the document by > > (theoretical) requirements and then finding use cases as supporting > > examples of the requirements. As I mentioned in my previous email, I > > think we should be working in the IETF bottom-up approach, looking at > > multiple real-world implementation/deployment use cases and deriving > > requirements from the aggregation of use cases. > > > > The -05- version of use cases shows the lack of clarity about how this= > > should be approached (and the lack of time as the deadline approached)= . > > > > Comments welcome. > > > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From Adam.Montville@cisecurity.org Thu Jul 25 07:38:09 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D9721F8F6D for ; Thu, 25 Jul 2013 07:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGnZEBGJGuzo for ; Thu, 25 Jul 2013 07:38:00 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.9]) by ietfa.amsl.com (Postfix) with ESMTP id 051A821F8C66 for ; Thu, 25 Jul 2013 07:37:59 -0700 (PDT) Received: from [216.82.250.19:21715] by server-9.bemta-12.messagelabs.com id BF/A8-01285-64831F15; Thu, 25 Jul 2013 14:37:58 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-16.tower-87.messagelabs.com!1374763077!13243184!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 5528 invoked from network); 25 Jul 2013 14:37:58 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-16.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 25 Jul 2013 14:37:58 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 25 Jul 2013 10:37:38 -0400 From: Adam Montville To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: Use Case Discussion: Vulnerable Endpoint Identification Thread-Index: Ac6Bnj6YfWpompnaTx+fZSs45OpjDgGE4lOAAGR2UfA= Date: Thu, 25 Jul 2013 14:37:39 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6737862@CISEXCHANGE1.msisac.org.local> References: <05BCCEB107AF88469B9F99783D47C1D671F8C0@CISEXCHANGE2.msisac.org.local> <96625bc3e1154d47bdae1fdee7c1ec1e@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <96625bc3e1154d47bdae1fdee7c1ec1e@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Use Case Discussion: Vulnerable Endpoint Identification X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 14:38:09 -0000 > -----Original Message----- > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > Sent: Tuesday, July 23, 2013 11:09 AM > To: Adam Montville; sacm@ietf.org > Subject: RE: Use Case Discussion: Vulnerable Endpoint Identification >=20 > Adam, >=20 > A few comments. >=20 > In general... if our current focus is on endpoint assessment, it seems l= ike > much of this goes way beyond our initial scope of focus. Things like kno= wing > what organizational units have endpoints and who owns these endpoints is= > important in the broader scope, but is not significant to our constraine= d area > of focus. There was a similar comment with respect to my inclusion of something as d= etailed as an event's time of occurrence. Strictly speaking, we don't car= e what time something happened, but what we should care about is that time= of change is important, so it's something we need to capture. It's my pe= rspective, and we need not take this perspective as a WG, that these detai= ls are important to consider when crafting the right architecture. Some o= f these elements are "out of scope" in the sense that we are not solving a= problem related to them, but they are not necessarily "out of scope" when= considering how we want to craft an architecture. >=20 > This raises the questions... should our use cases be scoped to only the > current area of focus for the working group, or should the use cases ide= ntify > the broader end goal for which our work will play a part? This, to me, will necessarily be a balancing act. We run some risk of mis= sing the boat if we constrain too much, and some risk of running aground i= f we broaden too much. =20 In general, I like the use cases we have so far, though some of them seem = to need fleshing out. I also believe that, if we're going to be harvestin= g information from the variety of sources represented in the 05 use case d= ocument, we ought to be considering what properties such sources should ha= ve, if any. For example, the MIB sources are relatively new to me, and I = know little about their reliability,=20but getting information from regist= ries and server configuration files is well-known in this space. >=20 > Other comments are inline. >=20 > Thanks, > Dave >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Monday, July 15, 2013 4:59 PM > > To: sacm@ietf.org > > Subject: [sacm] Use Case Discussion: Vulnerable Endpoint > > Identification > > > > And another... > > > > > > Use Case Name: Vulnerable Endpoint Identification > > > > Description: > > In this use case a zero-day exploit has been discovered in the wild, > > which is followed by a vulnerability identification entry and indicato= rs of > compromise. > > A security engineer is responsible for that portion of a situational > > response process that determines how exposed an organization is given > > the new state of the world. >=20 > This seems like two use cases in one. >=20 > Vulnerable Endpoint Identification: Typically vulnerability reports iden= tify an > executable or library that is vulnerable, or worst case the software tha= t is > vulnerable. This information is used to determine if an organization has= one > or more endpoints that have exposure to a vulnerability (i.e., what endp= oints > are vulnerable?). It is often necessary to know where you are running > vulnerable code and what configurations are in place on the endpoint and= > upstream devices (e.g., IDS, firewall) that may limit the exposure. All = of this > information, along with details on the severity and impact of a vulnerab= ility, is > necessary to prioritize remedies. >=20 > Compromised Endpoint Identification: Along with knowing if one or more > endpoints are vulnerable, it is also important to know if you have been > compromised. Indicators of compromise provide details that can be used t= o > identify malware (e.g., file hashes), identify malicious activity (e.g. = command > and control traffic), presence of unauthorized/malicious configuration i= tems, > and other indicators. While important, this goes beyond determining > organizational exposure. >=20 > > > > > > Actors: > > > > * System Administrator > > * Vulnerability Engineer > > * Security Engineer > > * System Owner > > * Information Owner > > > > > > Preconditions: > > > > * Organizational Security Policy exists > > * Security Policy specifies appropriate asset management capabiliti= es (i.e. > > categorization of endpoints) > > * Security Policy specifies endpoint configuration baseline for > > asset categorization > > * Security Policy specifies configuration history retention require= ments > > * The Organization associates owners who are individuals with endpo= ints > > * The Organization associates organizational units with endpoints > > > > Postconditions: > > > > * Appropriate individuals in the organization have a clear > > understanding of the organization's exposure to and potential impact o= f > the identified 0-day > > * Appropriate individuals are taking action to further assess or > > mitigate the organization's posture regarding this 0-day > > > > > > Primary Path: > > > > > > 1. [External] 0-day exploit discovery [1] > > > > 2. Vulnerability Identification (Vulnerability ID) issued and > > associated information published to an accessible content repository > > [2] >=20 > This applies to Vulnerable Endpoint Identification. >=20 > > 3. Indicators of Compromise (IoC) are identified and published to an= > > accessible content repository [3] >=20 > This applies to Compromised Endpoint Identification. >=20 > > 4. Security engineer provides the Vulnerability ID to the Asset > > Management System > > > > 5. The Asset Management System queries a configured Vulnerability > > Database to obtain a list of affected endpoint classes [4] > > > > 6. The Asset Management System returns a list of specific endpoints > > that can be classified according to the endpoint class list obtained > > in Step 5, which > > either: > > > > 7. > > a. Presently have affected software installed, or > > b. Have had affected software installed. >=20 > This supports both. Potentially compromised endpoints are those that are= > vulnerable or may have been vulnerable historically. >=20 > > > > 8. The Security Engineer exports the list of potentially affected > > endpoints > > > > 9. The Security Engineer initiates a vulnerability scan based on > > IoCs, published vulnerability information, and the potentially > > affected endpoint list. >=20 > Is a scan necessary for identification of vulnerable endpoints? If there= is > datastore that contains the current software inventory of endpoint devic= es, > wouldn't it be possible to check the vulnerability information against t= hat > data? Use of a data store seems to be the only effective way of doing t= his > for historically vulnerable software. >=20 > Vulnerability scanning has had mixed success in the past. There has bee= n > little consensus in what is the best methodology for detecting vulnerabl= e > software using scans. Is the software vulnerable if the software is ins= talled? > Is the endpoint vulnerable if the software is uninstalled and a vulnerab= le > library or other component is still present? >=20 > > 10. The Vulnerability Scanner derives a set of vulnerability checks = (i.e. > > assessments) to perform on each listed endpoint based on information > > associated with the provided Vulnerability ID and IoCs. >=20 > Again, I am not sure vulnerability checks are the best approach to ident= ify > vulnerable endpoints. This is getting into architecture and implementat= ion > details. It might be better for the endpoint to send file lists with has= hes > which get stored is a data store. Deltas can be used to reduce the over= all > volume. We need some discussion around the different approaches that ca= n > be used here. Do we support one approach? Multiple? >=20 > File lists with hashes can be used to identify compromised endpoints for= file > indicators. Checks or configuration setting publication are probably the= best > way to deal with some indicator types that relate to configuration items= . >=20 > > 11. The Vulnerability Scanner executes the check on each of the > > potentially affected hosts which will return results effectively > > equivalent to "is vulnerable," "is not vulnerable," "not checked," or = "error" > [5]. >=20 > What about "compromised" or "is not compromised"? >=20 > > 12. The Security Engineer reviews the report then generates three > > additional reports: >=20 > I thought we are striving for automation. Why not automate the addition= al > report generation? >=20 > > 13. > > a. The first report provides summary information for the > > Information Security Manager and/or higher levels of organizational > > management as appropriate (i.e. Chief Information Security Officer) > > b. The second report is a list of all potentially effected > > endpoints for which no definitive answer could be obtained by the > Vulnerability Scanner (i.e. > > those endpoints for which neither an "is vulnerable" nor "is not vulne= rable" > > result is available) >=20 > s/effected/affected/ >=20 > See above about alternate methods vs. using a vulnerability scanner. Wha= t > about unreachable endpoints? >=20 > > c. The third report is a list of all effected endpoints (i.e. > > those endpoints for which the checks resulted in "is vulnerable"). >=20 > s/effected/affected/ >=20 > > 14. The Security Engineer sends the first report to responsible > > Information Security Manager(s) using relationships tracked by the > > Asset Management System > > > > 15. The Security Engineer sends the second report to responsible > > Vulnerability Engineer(s) using relationships tracked by the Asset > > Management System > > > > 16. The Security Engineer sends the third report to responsible > > System > > Administrator(s) using relationships tracked by the Asset Management > > System > > > > 17. The Security Engineer issues an alert to affected System Owners,= > > Information Owners, and System Administrators using relationships > > tracked by the Asset Management System >=20 > Why can't 14-17 be automated alerts sent by the system implementing SACM= > specifications? >=20 > > A Note On Alternative Paths, Preconditions, and Postconditions: > > There are likely to be many points of optimization and optional paths > > pertaining to this Use Case. For example, there may be greater > > degrees of interoperability between tools in a given organization, > > which would advance the state of automation in the "primary path" > description herein provided. > > > > > > As with alternative paths, pre-/post-conditions can vary widely. > > Consider that this description likely represents an organization on > > the mature side of managing information security. Most organizations > > are unlikely to have separate roles for Security Engineer and Vulnerab= ility > Engineer, for example. > > > > > > -------------- > > [1] The "[External]" notation is used to indicate that, while this > > step is included in the primary path, it is out of the organization's > > locus of control (i.e. the step is provided for additional context in > > the path through the use case rather than being placed in the pre- > conditions). > > > > > > [2] An "accessible" content repository may be internal or external. > > An internal content repository may be a replication of an external > > content repository. > > > > > > [3] Often, an indicator of compromise involves assessing the state of > > some observable object on the endpoint. For example, an indicator of > > compromise might be that a particular file path exists, a particular > > setting is configured in a specific manner, a set of settings are > > configured in a specific manner, and/or specific log entries exist. > > > > [4] The Vulnerability Database may be combined with the content > > repository, but is being called out separately here to assure that the= > > reader knows which type of data is being queried. > > > > [5] It is likely that additional result types will be required to > > convey different reasons a result may not be available. > > > > This message and attachments may contain confidential information. If= > > it appears that this message was sent to you by mistake, any > > retention, dissemination, distribution or copying of this message and > > attachments is strictly prohibited. Please notify the sender > > immediately and permanently delete the message and any attachments. > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From gunnar.engelbach@threatguard.com Thu Jul 25 09:18:40 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45A521F99B0 for ; Thu, 25 Jul 2013 09:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a0PfJq+I5Pq for ; Thu, 25 Jul 2013 09:18:34 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 533D521F99AF for ; Thu, 25 Jul 2013 09:18:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=UTA3kNT9n+q6scmJHbVjCup3KDpGdL6d+H8l04TIMziNhvYnqFPDh18k5FrP43D7/A5NTZUsevWBVNWMnCsFHpjwLiQ2CI4HMxUrq5Tf2I0fP1Rt8Vn7GLEkV7lDsMWn; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 23939 invoked from network); 25 Jul 2013 09:16:56 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 25 Jul 2013 09:16:56 -0700 Message-ID: <51F14FDE.5050101@ThreatGuard.com> Date: Thu, 25 Jul 2013 12:18:38 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Montville References: <05BCCEB107AF88469B9F99783D47C1D671F8C0@CISEXCHANGE2.msisac.org.local> <96625bc3e1154d47bdae1fdee7c1ec1e@BLUPR09MB038.namprd09.prod.outlook.com> <05BCCEB107AF88469B9F99783D47C1D6737862@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6737862@CISEXCHANGE1.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Use Case Discussion: Vulnerable Endpoint Identification X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:18:41 -0000 On 7/25/2013 10:37 AM, Adam Montville wrote: > > >> -----Original Message----- >> From: Waltermire, David A. [mailto:david.waltermire@nist.gov] >> Sent: Tuesday, July 23, 2013 11:09 AM >> To: Adam Montville; sacm@ietf.org >> Subject: RE: Use Case Discussion: Vulnerable Endpoint Identification >> >> Adam, >> >> A few comments. >> >> In general... if our current focus is on endpoint assessment, it seems like >> much of this goes way beyond our initial scope of focus. Things like knowing >> what organizational units have endpoints and who owns these endpoints is >> important in the broader scope, but is not significant to our constrained area >> of focus. > > There was a similar comment with respect to my inclusion of something as detailed as an event's time of occurrence. Strictly speaking, we don't care what time something happened, but what we should care about is that time of change is important, so it's something we need to capture. It's my perspective, and we need not take this perspective as a WG, that these details are important to consider when crafting the right architecture. Some of these elements are "out of scope" in the sense that we are not solving a problem related to them, but they are not necessarily "out of scope" when considering how we want to craft an architecture. +1 The inclusion of that level of detail isn't necessary to understand the picture being painted by the use case, but it does point out information that needs to be captured that might not otherwise be apparent. > >> >> This raises the questions... should our use cases be scoped to only the >> current area of focus for the working group, or should the use cases identify >> the broader end goal for which our work will play a part? > > This, to me, will necessarily be a balancing act. We run some risk of missing the boat if we constrain too much, and some risk of running aground if we broaden too much. > > In general, I like the use cases we have so far, though some of them seem to need fleshing out. I also believe that, if we're going to be harvesting information from the variety of sources represented in the 05 use case document, we ought to be considering what properties such sources should have, if any. For example, the MIB sources are relatively new to me, and I know little about their reliability, but getting information from registries and server configuration files is well-known in this space. > >> >> Other comments are inline. >> >> Thanks, >> Dave >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>> Of Adam Montville >>> Sent: Monday, July 15, 2013 4:59 PM >>> To: sacm@ietf.org >>> Subject: [sacm] Use Case Discussion: Vulnerable Endpoint >>> Identification >>> >>> And another... >>> >>> >>> Use Case Name: Vulnerable Endpoint Identification >>> >>> Description: >>> In this use case a zero-day exploit has been discovered in the wild, >>> which is followed by a vulnerability identification entry and indicators of >> compromise. >>> A security engineer is responsible for that portion of a situational >>> response process that determines how exposed an organization is given >>> the new state of the world. >> >> This seems like two use cases in one. >> >> Vulnerable Endpoint Identification: Typically vulnerability reports identify an >> executable or library that is vulnerable, or worst case the software that is >> vulnerable. This information is used to determine if an organization has one >> or more endpoints that have exposure to a vulnerability (i.e., what endpoints >> are vulnerable?). It is often necessary to know where you are running >> vulnerable code and what configurations are in place on the endpoint and >> upstream devices (e.g., IDS, firewall) that may limit the exposure. All of this >> information, along with details on the severity and impact of a vulnerability, is >> necessary to prioritize remedies. >> >> Compromised Endpoint Identification: Along with knowing if one or more >> endpoints are vulnerable, it is also important to know if you have been >> compromised. Indicators of compromise provide details that can be used to >> identify malware (e.g., file hashes), identify malicious activity (e.g. command >> and control traffic), presence of unauthorized/malicious configuration items, >> and other indicators. While important, this goes beyond determining >> organizational exposure. >> >>> >>> >>> Actors: >>> >>> * System Administrator >>> * Vulnerability Engineer >>> * Security Engineer >>> * System Owner >>> * Information Owner >>> >>> >>> Preconditions: >>> >>> * Organizational Security Policy exists >>> * Security Policy specifies appropriate asset management capabilities (i.e. >>> categorization of endpoints) >>> * Security Policy specifies endpoint configuration baseline for >>> asset categorization >>> * Security Policy specifies configuration history retention requirements >>> * The Organization associates owners who are individuals with endpoints >>> * The Organization associates organizational units with endpoints >>> >>> Postconditions: >>> >>> * Appropriate individuals in the organization have a clear >>> understanding of the organization's exposure to and potential impact of >> the identified 0-day >>> * Appropriate individuals are taking action to further assess or >>> mitigate the organization's posture regarding this 0-day >>> >>> >>> Primary Path: >>> >>> >>> 1. [External] 0-day exploit discovery [1] >>> >>> 2. Vulnerability Identification (Vulnerability ID) issued and >>> associated information published to an accessible content repository >>> [2] >> >> This applies to Vulnerable Endpoint Identification. >> >>> 3. Indicators of Compromise (IoC) are identified and published to an >>> accessible content repository [3] >> >> This applies to Compromised Endpoint Identification. >> >>> 4. Security engineer provides the Vulnerability ID to the Asset >>> Management System >>> >>> 5. The Asset Management System queries a configured Vulnerability >>> Database to obtain a list of affected endpoint classes [4] >>> >>> 6. The Asset Management System returns a list of specific endpoints >>> that can be classified according to the endpoint class list obtained >>> in Step 5, which >>> either: >>> >>> 7. >>> a. Presently have affected software installed, or >>> b. Have had affected software installed. >> >> This supports both. Potentially compromised endpoints are those that are >> vulnerable or may have been vulnerable historically. >> >>> >>> 8. The Security Engineer exports the list of potentially affected >>> endpoints >>> >>> 9. The Security Engineer initiates a vulnerability scan based on >>> IoCs, published vulnerability information, and the potentially >>> affected endpoint list. >> >> Is a scan necessary for identification of vulnerable endpoints? If there is >> datastore that contains the current software inventory of endpoint devices, >> wouldn't it be possible to check the vulnerability information against that >> data? Use of a data store seems to be the only effective way of doing this >> for historically vulnerable software. >> >> Vulnerability scanning has had mixed success in the past. There has been >> little consensus in what is the best methodology for detecting vulnerable >> software using scans. Is the software vulnerable if the software is installed? >> Is the endpoint vulnerable if the software is uninstalled and a vulnerable >> library or other component is still present? >> >>> 10. The Vulnerability Scanner derives a set of vulnerability checks (i.e. >>> assessments) to perform on each listed endpoint based on information >>> associated with the provided Vulnerability ID and IoCs. >> >> Again, I am not sure vulnerability checks are the best approach to identify >> vulnerable endpoints. This is getting into architecture and implementation >> details. It might be better for the endpoint to send file lists with hashes >> which get stored is a data store. Deltas can be used to reduce the overall >> volume. We need some discussion around the different approaches that can >> be used here. Do we support one approach? Multiple? >> >> File lists with hashes can be used to identify compromised endpoints for file >> indicators. Checks or configuration setting publication are probably the best >> way to deal with some indicator types that relate to configuration items. >> >>> 11. The Vulnerability Scanner executes the check on each of the >>> potentially affected hosts which will return results effectively >>> equivalent to "is vulnerable," "is not vulnerable," "not checked," or "error" >> [5]. >> >> What about "compromised" or "is not compromised"? >> >>> 12. The Security Engineer reviews the report then generates three >>> additional reports: >> >> I thought we are striving for automation. Why not automate the additional >> report generation? >> >>> 13. >>> a. The first report provides summary information for the >>> Information Security Manager and/or higher levels of organizational >>> management as appropriate (i.e. Chief Information Security Officer) >>> b. The second report is a list of all potentially effected >>> endpoints for which no definitive answer could be obtained by the >> Vulnerability Scanner (i.e. >>> those endpoints for which neither an "is vulnerable" nor "is not vulnerable" >>> result is available) >> >> s/effected/affected/ >> >> See above about alternate methods vs. using a vulnerability scanner. What >> about unreachable endpoints? >> >>> c. The third report is a list of all effected endpoints (i.e. >>> those endpoints for which the checks resulted in "is vulnerable"). >> >> s/effected/affected/ >> >>> 14. The Security Engineer sends the first report to responsible >>> Information Security Manager(s) using relationships tracked by the >>> Asset Management System >>> >>> 15. The Security Engineer sends the second report to responsible >>> Vulnerability Engineer(s) using relationships tracked by the Asset >>> Management System >>> >>> 16. The Security Engineer sends the third report to responsible >>> System >>> Administrator(s) using relationships tracked by the Asset Management >>> System >>> >>> 17. The Security Engineer issues an alert to affected System Owners, >>> Information Owners, and System Administrators using relationships >>> tracked by the Asset Management System >> >> Why can't 14-17 be automated alerts sent by the system implementing SACM >> specifications? >> >>> A Note On Alternative Paths, Preconditions, and Postconditions: >>> There are likely to be many points of optimization and optional paths >>> pertaining to this Use Case. For example, there may be greater >>> degrees of interoperability between tools in a given organization, >>> which would advance the state of automation in the "primary path" >> description herein provided. >>> >>> >>> As with alternative paths, pre-/post-conditions can vary widely. >>> Consider that this description likely represents an organization on >>> the mature side of managing information security. Most organizations >>> are unlikely to have separate roles for Security Engineer and Vulnerability >> Engineer, for example. >>> >>> >>> -------------- >>> [1] The "[External]" notation is used to indicate that, while this >>> step is included in the primary path, it is out of the organization's >>> locus of control (i.e. the step is provided for additional context in >>> the path through the use case rather than being placed in the pre- >> conditions). >>> >>> >>> [2] An "accessible" content repository may be internal or external. >>> An internal content repository may be a replication of an external >>> content repository. >>> >>> >>> [3] Often, an indicator of compromise involves assessing the state of >>> some observable object on the endpoint. For example, an indicator of >>> compromise might be that a particular file path exists, a particular >>> setting is configured in a specific manner, a set of settings are >>> configured in a specific manner, and/or specific log entries exist. >>> >>> [4] The Vulnerability Database may be combined with the content >>> repository, but is being called out separately here to assure that the >>> reader knows which type of data is being queried. >>> >>> [5] It is likely that additional result types will be required to >>> convey different reasons a result may not be available. >>> >>> This message and attachments may contain confidential information. If >>> it appears that this message was sent to you by mistake, any >>> retention, dissemination, distribution or copying of this message and >>> attachments is strictly prohibited. Please notify the sender >>> immediately and permanently delete the message and any attachments. >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >> >> ... > > This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From ietfdbh@comcast.net Thu Jul 25 09:23:56 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC6121F85B4 for ; Thu, 25 Jul 2013 09:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.944 X-Spam-Level: X-Spam-Status: No, score=-98.944 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_03_06=0.274, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_53=0.6, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-Q6ainj5muZ for ; Thu, 25 Jul 2013 09:23:48 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by ietfa.amsl.com (Postfix) with ESMTP id 3F42A21F85B3 for ; Thu, 25 Jul 2013 09:23:48 -0700 (PDT) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta10.emeryville.ca.mail.comcast.net with comcast id 4dDQ1m0011wfjNsAAgPnZa; Thu, 25 Jul 2013 16:23:47 +0000 Received: from [10.0.4.96] ([89.246.150.136]) by omta23.emeryville.ca.mail.comcast.net with comcast id 4gPD1m00Y2wpE7M8jgPLDH; Thu, 25 Jul 2013 16:23:42 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Thu, 25 Jul 2013 18:23:12 -0400 From: David Harrington To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Message-ID: Thread-Topic: [sacm] use cases versus requirements In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12881264@AZ-FFEXMB04.global.avaya.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374769428; bh=EXt73uLKpJvmVDehBByN5vqZcYfnVOPIccXmw1kDMko=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=UAmT8hU0mZ0CHe9CBkizRT4Wwt3Ob5kMJ9bpWRQRrjZ+TYmm25QyCGpUmwFzwgTNy ZxdgGd5JikxJ+9y1jqLa7JT8iqmAoxKrk1Ef8mACA6QcYplKHcCv5T3ej7g1pBLkQK C1tOohImCs6ikMDwv3lD3rAF9+8XLwY6NRv2w6+LY7zobx/bsQj0saOy0eZOPG31hi S8dB6skwFBn+kEFD7DWvNULiuHFPiFTc4zAJwrm3GrTUWSlZ8ztwoUZI6ejMksUgds kr5hJ73OGNAez6+JKBS1SwUdOviOXXnJtow8GS8nlVHPw4ocmYqnNvYjys3dtHPTt8 yde48L2/vf3ug== Subject: Re: [sacm] use cases versus requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:23:56 -0000 Hi Dan, I published -05- as a partial update. I gathered all the use cases I think I knew about at the time. IIRC I put Adam's in, rewritten to the informal format, but might have not done so (I'm not looking at the doc right now). I did find Adam's use case to be quite complex, so I may not have put it in yet. There have been a number of use cases discussed since -05-. I expect to capture them in -06-. No guarantees of when that will get published. I started reorg'ing the doc, but haven't finished. It unclear whether the WG wants each UC to have a description+functions+requirements (that would lead to a LOT of duplicate text, which I think would obscure the information badly). An alternative would be to list all the use cases in 1 section, then summarize the functions in a section, then derive the requirements in a third section. Another alternative would be to organize by general use case (asset, config, change, vulnerability), and within each of those sections, have subsections for use cases, functions, and requirements, so there would liekly be some duplication between the asset mgmt and the config mgmt, but we'd eliminate a ot of the duplication between asset uc1 and asset uc2, and so on. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 7/25/13 10:04 AM, "Romascanu, Dan (Dan)" wrote: >Hi, > >Thanks for the effort invested until now into trying to sort out use >cases and requirements. > >The document has already some good parts which I believe are very useful >- for example the terminology section. > >Is my understanding correct that from 04 to 05 we started to transition >from the initial top-down ('theoretical') approach used in the initial >versions of the document to a bottom-up approach, collecting real-life >use cases, describing, sorting, consolidating them, and deriving the >requirements from here? If so should we expect to see the couple of use >cases proposed during the last week by Adam on the list by Adam be added >to the use cases (together with other that will come)? If I am correct >the efforts should be now channeled towards adding use cases to section 3 >making sure that all important use cases are covered while keeping the >list at a low and manageable size, and in parallel fill in with content >section 4 that covers requirements. > >What is the opinion of the WG participants - is the structure of section >4 right or aproximatively right? > >I would like to see the requirements in the requirement sections numbered! > >Regards, > >Dan > > > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> ietfdbh >> Sent: Tuesday, July 16, 2013 1:34 AM >> To: sacm@ietf.org >> Subject: [sacm] use cases versus requirements >> >> Hi, >> >> I looked up the BOF summaries from November and March. >> The summary from November says " The consensus was to start from >> requirements and then develop an architecture to explain how the use >> cases can be met. The group has a fairly good understanding of the >> problem space, but needs to document this and present it more clearly >> with the requirements, then the architecture. These steps need to >> happen to progress the work." Are we paying enough attention to the >> requirements stage? We don't have a requirements doc, and that might be >> helpful. >> >> The summary is unclear about which comes first - use cases or >> requirements. >> >> The -04- version of use cases had very high-level uses cases, and then >> defined concepts and requirements from the three abstract use cases, in >> a top-down approach that led to organizing the document by (theoretical) >> requirements and then finding use cases as supporting examples of the >> requirements. As I mentioned in my previous email, I think we should be >> working in the IETF bottom-up approach, looking at multiple real-world >> implementation/deployment use cases and deriving requirements from the >> aggregation of use cases. >> >> The -05- version of use cases shows the lack of clarity about how this >> should be approached (and the lack of time as the deadline approached). >> >> Comments welcome. >> >> David Harrington >> ietfdbh@comcast.net >> +1-603-828-1401 >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm From Adam.Montville@cisecurity.org Thu Jul 25 09:33:11 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025FA21F8618 for ; Thu, 25 Jul 2013 09:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.05 X-Spam-Level: X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1enetqRw3A9 for ; Thu, 25 Jul 2013 09:33:06 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.112]) by ietfa.amsl.com (Postfix) with ESMTP id 248B521F8947 for ; Thu, 25 Jul 2013 09:33:03 -0700 (PDT) Received: from [216.82.253.227:15512] by server-16.bemta-7.messagelabs.com id E3/91-14165-E3351F15; Thu, 25 Jul 2013 16:33:02 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-4.tower-170.messagelabs.com!1374769981!15988247!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 16255 invoked from network); 25 Jul 2013 16:33:02 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-4.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 25 Jul 2013 16:33:02 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 25 Jul 2013 12:32:42 -0400 From: Adam Montville To: Rainer Enders , "sacm@ietf.org" Thread-Topic: [sacm] Appropriate Level for Use Cases Thread-Index: Ac6Dy7kkNLNKfcfOQDiaN5MVEkQ9HQAJq2iAAVhP8kA= Date: Thu, 25 Jul 2013 16:32:43 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D67379F9@CISEXCHANGE1.msisac.org.local> References: <05BCCEB107AF88469B9F99783D47C1D6732431@CISEXCHANGE1.msisac.org.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Appropriate Level for Use Cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:33:11 -0000 Rainer,=20 Thanks for your perspective on use cases, it's good to hear. Sorry for th= e delay in my response. With respect to industry participation in standards, there is a reasonably= sized group of security software vendors already invested in security aut= omation standards to date. Moving forward, I agree that getting the word = out will continue to be important. =20 IMHO, most of us listening to and contributing to this effort should be ac= ting as ambassadors on behalf of the effort. If you're involved and you s= ee an opportunity to promote the work we're doing - and, most important, g= et more good people involved - then you ought to be doing that. I try to = do this at every opportunity. If I'm on a panel, talking to customers, or= just talking shop with a peer, I'm evaluating our effort's viability and = applicability. In effect, I evangelize (use of that word probably makes s= ome people cringe) the benefit security automation can bring, and I raise = its challenges. Adam=20 > -----Original Message----- > From: Rainer Enders [mailto:Rainer.Enders@ncp-e.com] > Sent: Thursday, July 18, 2013 9:08 AM > To: Adam Montville; sacm@ietf.org > Subject: Re: [sacm] Appropriate Level for Use Cases >=20 > Hello Adam, >=20 >=20 > I agree with your thinking and I found your presentation of use cases > refreshing and promising. With my background as a research engineer it > appears, at least to me, that at times researchers and scientists tend t= o > overanalyze problems. Having said that I often look at use cases and won= der > if the work that they are intending to support is worth the effort becau= se > they do not offer significant substantiation and differentiation. > We have a large number of standards and if you have a good knowledge > base of such standards you often can imagine simplistic use cases could = easily > be addressed by existing standards and wonder what the value add is of t= he > work that is being proposed. So in that sense use cases are a critical e= lement. > Another related thought I have on this subject is that the lack of=20bro= ad > industry participation in standardization efforts is a limiting factor i= n the sense > that there is a difference between practical issues and theoretical issu= es. > Maybe a way to address this is to take discussions on standardization ef= forts > into more public forums (trade shows, industry events)? >=20 > Regards, > Rainer >=20 > On 7/18/13 8:49 AM, "Adam Montville" > wrote: >=20 > >Greetings all, > > > >I'd like to start a discussion here on what we, as a community, believe= > >is the appropriate descriptive level for what we are calling a "use > >case." From my background - biased by computer science, electrical and= > >computer engineering, and years of working with software development > >groups - a "use case" is something that looks a lot like the two I sent= > >earlier this week ([1] and [2]). > > > >At that level of detail, we have a better understanding of who relying > >parties are on the capability being described and what pieces of data > >and/or pre-requisites are=20otherwise needed for the capability to be > >successful, which is one of the reasons I like that level of descriptio= n. > > > > > >To me, it makes sense to get what we are calling use cases to an > >appropriate level of detail to act as representatives of requirements. > >Requirements can be derived from the use cases, and from non-use-case > >sources. Then, once requirements are better known, we can move on to > >architectures. > > > >Additionally, David Harrington has asked whether we're paying enough > >attention to requirements [3], and I agree that we may not be at this > >time. But, I would also ask whether we ought to be just yet, at least > >until a good set of appropriately described use cases exists. > > > >All that said, I think much of this work can be done in parallel or in > >quick iterations, but I also think that, if parallel/iterative > >development of use cases, requirements, and architecture is going to be= > >successful, we need to discuss more here - on the list. :-) > > > >That's my take on it anyway. I guess the bottom line is that we have > >an October milestone to have an initial I-D submission to IESG for the > >architecture, and there are two general steps that need to complete > >before we can feel comfortable with the architectural direction - use > >cases and requirements. > > > >Thoughts? > > > >Adam > > > > > >[1] http://www.ietf.org/mail-archive/web/sacm/current/msg01282.html > >[2] http://www.ietf.org/mail-archive/web/sacm/current/msg01284.html > >[3] http://www.ietf.org/mail-archive/web/sacm/current/msg01288.html > > > > > >This message and attachments may contain confidential information. If > >it appears that this message was sent to you by mistake, any retention,= > >dissemination, distribution or copying of this message and attachments > >is strictly prohibited. Please notify the sender immediately and > >permanently delete the message and any attachments. > >_______________________________________________ > >sacm mailing list > >sacm@ietf.org > >https://www.ietf.org/mailman/listinfo/sacm >=20 > ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From prvs=0918e75551=rainer.enders@ncp-e.com Thu Jul 25 09:52:18 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DC821F9956 for ; Thu, 25 Jul 2013 09:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnGI+dlt6NcO for ; Thu, 25 Jul 2013 09:52:13 -0700 (PDT) Received: from mail.ncp.de (mail.remote-access.de [62.153.165.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1898B21F972C for ; Thu, 25 Jul 2013 09:52:12 -0700 (PDT) Received: from viruswall.ncp.de (viruswall.ncp.de [62.153.165.41]) by mail.ncp.de (Postfix) with ESMTPS id 9C1733AE430 for ; Thu, 25 Jul 2013 19:02:50 +0200 (CEST) Received: from [172.16.11.201] (port=22481 helo=ex07.ncp.local) by viruswall.ncp.de with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) (envelope-from ) id 1V2Olr-0003JT-1d; Thu, 25 Jul 2013 18:52:07 +0200 Received: from ex07.ncp.local ([172.16.11.201]) by ex07.ncp.local ([172.16.11.201]) with mapi; Thu, 25 Jul 2013 18:52:07 +0200 X-CTCH-RefID: str=0001.0A0C0209.51F157B7.0100,ss=1,re=0.000,fgs=0 From: Rainer Enders To: Adam Montville , "sacm@ietf.org" Date: Thu, 25 Jul 2013 18:51:52 +0200 Thread-Topic: [sacm] Appropriate Level for Use Cases Thread-Index: Ac6JV0uaFk+PLfUcRsaSC3mYx6rMEQ== Message-ID: In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D67379F9@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Appropriate Level for Use Cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:52:18 -0000 Hello Adam, I will be doing that next week again when delivering a presentation at the BriForum in Chicago. I see myself very much as an evangelist as well. Ambassador sounds just too political to me 8) I don't mean to hijack this forum or enter into a more detailed discussion about standards participation here. Just to clarify my point of view with broader participation I meant not just vendors and government which appears to prevail the scene. There are many other groups and organizations that could contribute to standardization efforts. But as I said no need to discuss this further here. Rainer=20 On 7/25/13 9:32 AM, "Adam Montville" wrote: >Rainer,=20 > >Thanks for your perspective on use cases, it's good to hear. Sorry for >the delay in my response. > >With respect to industry participation in standards, there is a >reasonably sized group of security software vendors already invested in >security automation standards to date. Moving forward, I agree that >getting the word out will continue to be important. > >IMHO, most of us listening to and contributing to this effort should be >acting as ambassadors on behalf of the effort. If you're involved and >you see an opportunity to promote the work we're doing - and, most >important, get more good people involved - then you ought to be doing >that. I try to do this at every opportunity. If I'm on a panel, talking >to customers, or just talking shop with a peer, I'm evaluating our >effort's viability and applicability. In effect, I evangelize (use of >that word probably makes some people cringe) the benefit security >automation can bring, and I raise its challenges. > >Adam=20 > >> -----Original Message----- >> From: Rainer Enders [mailto:Rainer.Enders@ncp-e.com] >> Sent: Thursday, July 18, 2013 9:08 AM >> To: Adam Montville; sacm@ietf.org >> Subject: Re: [sacm] Appropriate Level for Use Cases >>=20 >> Hello Adam, >>=20 >>=20 >> I agree with your thinking and I found your presentation of use cases >> refreshing and promising. With my background as a research engineer it >> appears, at least to me, that at times researchers and scientists tend >>to >> overanalyze problems. Having said that I often look at use cases and >>wonder >> if the work that they are intending to support is worth the effort >>because >> they do not offer significant substantiation and differentiation. >> We have a large number of standards and if you have a good knowledge >> base of such standards you often can imagine simplistic use cases could >>easily >> be addressed by existing standards and wonder what the value add is of >>the >> work that is being proposed. So in that sense use cases are a critical >>element. >> Another related thought I have on this subject is that the lack of broad >> industry participation in standardization efforts is a limiting factor >>in the sense >> that there is a difference between practical issues and theoretical >>issues. >> Maybe a way to address this is to take discussions on standardization >>efforts >> into more public forums (trade shows, industry events)? >>=20 >> Regards, >> Rainer >>=20 >> On 7/18/13 8:49 AM, "Adam Montville" >> wrote: >>=20 >> >Greetings all, >> > >> >I'd like to start a discussion here on what we, as a community, believe >> >is the appropriate descriptive level for what we are calling a "use >> >case." From my background - biased by computer science, electrical and >> >computer engineering, and years of working with software development >> >groups - a "use case" is something that looks a lot like the two I sent >> >earlier this week ([1] and [2]). >> > >> >At that level of detail, we have a better understanding of who relying >> >parties are on the capability being described and what pieces of data >> >and/or pre-requisites are otherwise needed for the capability to be >> >successful, which is one of the reasons I like that level of >>description. >> > >> > >> >To me, it makes sense to get what we are calling use cases to an >> >appropriate level of detail to act as representatives of requirements. >> >Requirements can be derived from the use cases, and from non-use-case >> >sources. Then, once requirements are better known, we can move on to >> >architectures. >> > >> >Additionally, David Harrington has asked whether we're paying enough >> >attention to requirements [3], and I agree that we may not be at this >> >time. But, I would also ask whether we ought to be just yet, at least >> >until a good set of appropriately described use cases exists. >> > >> >All that said, I think much of this work can be done in parallel or in >> >quick iterations, but I also think that, if parallel/iterative >> >development of use cases, requirements, and architecture is going to be >> >successful, we need to discuss more here - on the list. :-) >> > >> >That's my take on it anyway. I guess the bottom line is that we have >> >an October milestone to have an initial I-D submission to IESG for the >> >architecture, and there are two general steps that need to complete >> >before we can feel comfortable with the architectural direction - use >> >cases and requirements. >> > >> >Thoughts? >> > >> >Adam >> > >> > >> >[1] http://www.ietf.org/mail-archive/web/sacm/current/msg01282.html >> >[2] http://www.ietf.org/mail-archive/web/sacm/current/msg01284.html >> >[3] http://www.ietf.org/mail-archive/web/sacm/current/msg01288.html >> > >> > >> >This message and attachments may contain confidential information. If >> >it appears that this message was sent to you by mistake, any retention, >> >dissemination, distribution or copying of this message and attachments >> >is strictly prohibited. Please notify the sender immediately and >> >permanently delete the message and any attachments. >> >_______________________________________________ >> >sacm mailing list >> >sacm@ietf.org >> >https://www.ietf.org/mailman/listinfo/sacm >>=20 >> ... > >This message and attachments may contain confidential information. If it >appears that this message was sent to you by mistake, any retention, >dissemination, distribution or copying of this message and attachments is >strictly prohibited. Please notify the sender immediately and >permanently delete the message and any attachments. From emwienh@nsa.gov Thu Jul 25 10:03:03 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAD121F8CB0 for ; Thu, 25 Jul 2013 10:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxLXRnOceJpV for ; Thu, 25 Jul 2013 10:02:56 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2A621F9130 for ; Thu, 25 Jul 2013 10:02:45 -0700 (PDT) X-TM-IMSS-Message-ID: <99fd9db40021e173@nsa.gov> Received: from MSHT-GH1-UEA01.corp.nsa.gov ([10.215.227.18]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 99fd9db40021e173 ; Thu, 25 Jul 2013 13:01:45 -0400 Received: from MSMR-GH1-UEA06.corp.nsa.gov ([10.215.225.2]) by MSHT-GH1-UEA01.corp.nsa.gov ([10.215.227.18]) with mapi id 14.02.0342.003; Thu, 25 Jul 2013 13:02:43 -0400 From: "Wienholt, Edward" To: 'Jerome Athias' , "sacm@ietf.org" Thread-Topic: [sacm] XORCISM eXtensible Open Research on Cyber Information Security Models Thread-Index: AQHOiTfckmaUS5AEk0229soo38/JMZl1nXPw Date: Thu, 25 Jul 2013 17:02:42 +0000 Message-ID: References: <2D0355FA-CE08-40DD-8D3C-2B1021FCB675@gmail.com> In-Reply-To: <2D0355FA-CE08-40DD-8D3C-2B1021FCB675@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.215.224.46] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0226_01CE8937.3EDE0F70" MIME-Version: 1.0 Subject: Re: [sacm] XORCISM eXtensible Open Research on Cyber Information Security Models X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 17:03:03 -0000 ------=_NextPart_000_0226_01CE8937.3EDE0F70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, Is this a valid website? The mcaf.ee address hints that it may be a malicious site and that this is a phishing email. Edward Wienholt I411 Cyber Security Methods & Technologies Office Computer Network Defense Research and Technology (CND R&T) Team Phone: 443-634-0270 Fax 410-854-4681 emwienh@nsa.gov -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Jerome Athias Sent: Thursday, July 25, 2013 9:04 AM To: sacm@ietf.org Subject: [sacm] XORCISM eXtensible Open Research on Cyber Information Security Models Hi, I would appreciate any feedback on this research. http://mcaf.ee/31d9q Thank you Best regards Jerome Athias _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_0226_01CE8937.3EDE0F70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISgTCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEsjCCA5qgAwIBAgIDJrMsMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIxMTI5MDAwMDAwWhcN MTUxMDIzMjM1OTU5WjB+MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDT1NEMSswKQYDVQQDEyJXSUVOSE9M VC5FRFdBUkQuTUlDSEFFTC4xMDQyMTExNjc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAgS0pV88Ptw74iIHD+KFTpy3YozGmfvxZSeop4Z9aXXRelbDfR7Oa81kpwz254YceqfQ5QGFy u/dij7HGj4d9D/wRqJk2uzn4bto/su/moOKYQIk+UQzj3xWf8dDTV4LApN7BhghYWU+GsyYfs4ZQ OkyW2VQL4VG26lOgB/syex9+XUWk2/8K/RqtcYQilw8lz+9Dd/Gm6gm62UbzDXf+eq044zPd5eSE h3sM+cUGu8afjFAPGOwRJ8SXDPOXS7xl/n28HWhrz2JA4jCdn4wUZSxeCj4Z6HvIXpDFRaBIsNM+ k95MqdEhm3lCfl+r2GRkO6OYoZmiv3XTP/hWaxCq4wIDAQABo4IBWDCCAVQwHwYDVR0jBBgwFoAU uEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2NybC5kaXNhLm1p bC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgUgMCMGA1UdIAQcMBowCwYJYIZI AWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUC/kjqyG/TWCTcnRn+VAn70sLh90waAYIKwYB BQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24vRE9ERU1BSUxD QV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMBoGA1UdEQQTMBGBD0VN V0lFTkhATlNBLkdPVjAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMA0GCSqGSIb3DQEBBQUA A4IBAQAiUDUSEjnrS3ZiTgdbKQdVBrb+tB9kMN0X6U9CZwSx2tWxW/yDkmwkNDfSv3JPjJMCltMK HKMtXWG8un/BjFwPjPf35jABymKUhbuh7S1/ObDszr6uV22ag2nRs2uYN2Bcrtxgz3oZflcBtTt9 YkNvjAbgVdCtzrwf/nMTeEzcJ/6t7Tqr1ZjCIAImfUADqvOWZBvyBgehvx/hscFpDCTaEC9XPMFo 1tKSIf+31Dgp3aJlPYs/Qm2g+fPnKmQDym37MKwBjtvDUrtTeoIDyeZ5zShOmnBVmHsBS1Vos6Wt /re3QQwBxWEKsee3Ri3LzP0npNmFPVKypVC8HFkC4uCoMIIE/TCCA+WgAwIBAgIDJrMpMA0GCSqG SIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNV BAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIxMTI5 MDAwMDAwWhcNMTUxMDIzMjM1OTU5WjB+MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zl cm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDT1NEMSswKQYDVQQD EyJXSUVOSE9MVC5FRFdBUkQuTUlDSEFFTC4xMDQyMTExNjc0MIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAtUuzEwSppOAbDHEl4IduQkdqIMKVsFWob4irmpl5lSia/jdyiejmfZlsBlHV eEjQA9XYm/adEzMTjU+xPR19iGfwm4bUQP92JZ1nnzKlDeFPthqAK9hScWIBSRfNjPZjG9gEyw3G xY/rhGguIsGsxdwUwnZc3DhmqhARvvGs9jaB+G/ABP+89Nfof++sK6ulk8WKYN4r+3AL3afJgs+1 H0AEEQ1i4uZ1anbq5FvHn1Exkr5rdzaDdDTK2g6PEYBrHCaqWkU3o6N1a82PARiB+VxXAAB3FgKC wj/l7ho75+LIoloOyE0QnlG7SxymepGIpjw9JyQXD6h43E1PrWauiQIDAQABo4IBozCCAZ8wHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUS4zbYbocnhZNiPT2uyC5/e8F Dn0waAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMDoGA1Ud EQQzMDGBD0VNV0lFTkhATlNBLkdPVqAeBgorBgEEAYI3FAIDoBAMDjEwNDIxMTE2NzRAbWlsMBsG A1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUH AwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4IBAQB4D/t/Cqa9Micqhir2OXN8G4Oo/YfNP6s1 kZYfe7qA3xWXG0HSuWys0GMblI0efXyPdMiTa9BA3MNCGgO4AYHC+8XulC14hA2yUr6qudPGs5dJ laxOIBkq7wiKgynQS3vvJJIQSRgJ9SPsgiNWSQ8ZkGcqNAUFGWE1gDDAXDD/OpXHrgpUP3jWimJp CxZyAkIOamrUoBSj6/Rao8v7QNNGBUoFzQpBHoTr3rojV2s5ln3lzuDDn8u1ybmkU10onxSncPSf Vpecp8lk3VLpaNg4Re+f9AJsqWWvLy5rMvb/ZPfvsME7v6KV0E01b6LC9pn4tjmoF1ofyEhDOXQF XkXTMIIFUjCCBDqgAwIBAgICAbgwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNV BAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMT DURvRCBSb290IENBIDIwHhcNMTEwOTA4MTYwMjE0WhcNMTcwOTA4MTYwMjE0WjBdMQswCQYDVQQG EwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BL STEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTI5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkmIvQcIgABYGVWSfvaeIFW6Cm0jBhXe9AqsM2fErYIEBuj51cI4Spqc4hJCz6UCAEtxqylHN rS2GEMxEvA7FWDgZshQyJUFUWFxDDshscw/DDBgYFgSaUj2BonHOPDIAn3FVuvjONnceIbcolOc9 Pqb2wHoxYJEol3ciUPLGk26yG8VBxvmhN/sQv9pWpvtSTV+/78SWdyjlMv/o4RjMQ1IYrI13mnJM 6J0DXrCi7+Td0ufmp6ZSreGYCJZKQ8xzPUuijYnv3IJMuEqAJGUrHpGC9QT2ch9XGEAX8DlRto/z iTtn91hOSrza+Q7BwAy98whx+IMPyS6AlfSFDs6uqQIDAQABo4ICHDCCAhgwDgYDVR0PAQH/BAQD AgGGMB8GA1UdIwQYMBaAFEl0uwxeunr+AlTve6DGlcYJgHCWMB0GA1UdDgQWBBS4Q4NkIXrucIHe pd4MYCiHeK5eeDASBgNVHRMBAf8ECDAGAQH/AgEAMAwGA1UdJAQFMAOAAQAwZgYDVR0gBF8wXTAL BglghkgBZQIBCwUwCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELETALBglghkgBZQIBCxIwCwYJYIZI AWUCAQsTMAwGCmCGSAFlAwIBAxowDAYKYIZIAWUDAgEDGzA3BgNVHR8EMDAuMCygKqAohiZodHRw Oi8vY3JsLmRpc2EubWlsL2NybC9ET0RST09UQ0EyLmNybDCCAQEGCCsGAQUFBwEBBIH0MIHxMDoG CCsGAQUFBzAChi5odHRwOi8vY3JsLmRpc2EubWlsL2lzc3VlZHRvL0RPRFJPT1RDQTJfSVQucDdj MCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDCBkAYIKwYBBQUHMAKGgYNsZGFwOi8v Y3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIlMmNvdSUzZFBLSSUyY291 JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2Nyb3NzQ2VydGlmaWNhdGVQ YWlyO2JpbmFyeTANBgkqhkiG9w0BAQUFAAOCAQEALGsseTXb8B4ch3ur4ehpajeL23pPVWBplS9T ncbKQ7bUN5HWA11+WrG4HfeegdOuUFQwpG9LLrsUGxeqXBDTlHoxOZakVHn16VYuVcMbFuqqAsjP UfcygSLGNDqpzZqqSJPH6fseMn5xxHbwRVQSHVXqvVwyhzquk5pumSJfqFE17rJTYF/2T0W4FoQd ZVXNFcoQAR+p0pynV5Gj1+ewhj0t9Ik62Ml3cFDGbO/y65j4EKo92shcKa3OuHNJTKGSu+btzbqC GmMhGWX0Bhm/g6pz5dMbsZj/Rd/7Scxz6OLnB5YAMel/2SQI58pEekgGw0LYP/l5h6U3khaphCCS YzGCAzIwggMuAgEBMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDJrMp MAkGBSsOAwIaBQCgggGjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDcyNTE3MDI0MVowIwYJKoZIhvcNAQkEMRYEFCt7p1Ethzm5ooLKJMn8KcHJ6SNUMFgGCSqG SIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMHMGCSsGAQQBgjcQBDFmMGQwXTELMAkGA1UEBhMC VVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kx GDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDJrMsMHUGCyqGSIb3DQEJEAILMWagZDBdMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsT A1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTI5AgMmsywwDQYJKoZIhvcNAQEBBQAEggEAbQbO 0N+4GDgkT1vHnI5/Jf0ceLiFouCL1FlXfVAzeaizhByL1ex8zXqH0PMNYzeB9uxN8WXAS5nyIRaP oCOPwwDs46TFB3fkvkMdTfb+uJ+ZJviFJbCeq5QGZK/r83y7uQFmmz7hYahfuI3vM9nCmsrlFlRb btPxBRr5uSgxXzxQnT7VAihprO+BXwp9Z+BI2xAoFPv9COkfMfPkToM7c7SaYgO1Xlxrbs9evTVn kJTQ0yzrMCUl9IFy7Sds890YjcVGngtSC/sSvQk2M/InbL0ePOUpw73NRYrC/lF6SC85hEN6tecP TyelQLroyavNFjNK2TqbY2d6ALy5fkrtZQAAAAAAAA== ------=_NextPart_000_0226_01CE8937.3EDE0F70-- From Adam.Montville@cisecurity.org Thu Jul 25 10:04:26 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCE921F8419 for ; Thu, 25 Jul 2013 10:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT8-bn28bGSx for ; Thu, 25 Jul 2013 10:04:22 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.199]) by ietfa.amsl.com (Postfix) with ESMTP id CA37521F8CB0 for ; Thu, 25 Jul 2013 10:04:21 -0700 (PDT) Received: from [216.82.241.211:33633] by server-7.bemta-8.messagelabs.com id B3/9D-18080-49A51F15; Thu, 25 Jul 2013 17:04:20 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-2.tower-85.messagelabs.com!1374771859!18277904!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 1817 invoked from network); 25 Jul 2013 17:04:19 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-2.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 25 Jul 2013 17:04:19 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 25 Jul 2013 13:04:00 -0400 From: Adam Montville To: Sean Turner , "sacm@ietf.org" Thread-Topic: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt Thread-Index: AQHOflbaeQpXtrNVV0OhXxAJ+XuCypl1swmQ Date: Thu, 25 Jul 2013 17:04:01 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6737A4F@CISEXCHANGE1.msisac.org.local> References: <20130711165015.29939.87432.idtracker@ietfa.amsl.com> <51DEE295.3050403@ieca.com> In-Reply-To: <51DEE295.3050403@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 17:04:26 -0000 Being the transcriber of NISTS Asset Identification standard to an I-D for= mat (now expired), I have some questions about this proposal. First, howe= ver, I like the way this reads and flows and I enjoyed reading it, much li= ke I enjoyed reading the alternate architecture document. It seems that draft-handt-sacm-asset-identifiers-00 is squarely focused on= instance-level identity, identification, and identifiers. I believe, tha= t we have several levels of "identification" requirements. We do want ins= tance-level identification, and I believe OIDs, as proposed, could be a go= od solution. I believe we also want class-level identification, for which= we have been considering CPE. For example, I may have several OIDs, one for each of a Windows Server 200= 8 instance, RHEL 6 instance, Windows Server 2012 instance, and Solaris 9 i= nstance. Now, I want to find all the assets in the "Windows" class, which= would be the set of two OIDs representing the WS2008 and WS2012 instances= . We could leave it up to implementers to provide this type of functional= ity, but would it not be useful to have some standardized way to represent= that class? An honest question: How would this proposal handle class-level identificat= ion? Or, do we collectively believe there is no such need? Adam =20 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Thursday, July 11, 2013 9:51 AM > To: sacm@ietf.org > Subject: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.t= xt >=20 > More food for thought. >=20 > spt >=20 > -------- Original Message -------- > Subject: I-D Action: draft-handt-sacm-asset-identifiers-00.txt > Date: Thu, 11 Jul 2013 09:50:15 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >=20 >=20 > =09Title : sacm: Asset Identifier > =09Author(s) : Russ Housley > Sean Turner > =09Filename =20 : draft-handt-sacm-asset-identifiers-00.txt > =09Pages : 7 > =09Date : 2013-07-11 >=20 > Abstract: > This document examines the asset identifiers available for sacm and > it proposes that OIDs (Object Identifiers) be selected as the asset > identifier format. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-handt-sacm-asset-identifiers >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-handt-sacm-asset-identifiers-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From athiasjerome@gmail.com Thu Jul 25 10:13:23 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD3221F8DDD for ; Thu, 25 Jul 2013 10:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8BemJxMLEtS for ; Thu, 25 Jul 2013 10:13:22 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9970221F8DA3 for ; Thu, 25 Jul 2013 10:13:22 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w16so34340pde.9 for ; Thu, 25 Jul 2013 10:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=4Bq3Eoz+7+ESUkfwzgOqZdGVHLrLmFJacbZlL8tT53A=; b=vHrkBEgQHuupLfanJbRK33XEdFMu2wkmahL6WaedALmLF9PdD+Q3Bb2I/7z3pL2+EW Qbo3aYVX9yRFNzLAPXBXyrAMoZKLOH2R0Bk/o/NPMDE96x/S/YxONbYknehexR2+81P9 qfs2m4tVqfD6X0cvGcs+s3y865MdSgNEchipEyvgnQRsJqXkLVABElVIMBGMQW3jpOlH Y8Xcu9YD6sWAtAz9ME86KwSt4OU0KYCIYn2eaub5fjVWopuSjjo+LQ0BUK8EWJzSDtdM ZkdIE53kimeaEKz6+4f0Oo4QCBIaocYvleo32zKanpcF+4MjCfyljYs4jIpimvGVlPqE J07g== X-Received: by 10.68.58.97 with SMTP id p1mr49775189pbq.144.1374772402262; Thu, 25 Jul 2013 10:13:22 -0700 (PDT) Received: from [192.168.1.114] ([91.73.38.83]) by mx.google.com with ESMTPSA id iu7sm8391640pbc.8.2013.07.25.10.13.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 10:13:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jerome Athias In-Reply-To: Date: Thu, 25 Jul 2013 21:13:16 +0400 Content-Transfer-Encoding: 7bit Message-Id: References: <2D0355FA-CE08-40DD-8D3C-2B1021FCB675@gmail.com> To: "Wienholt, Edward" X-Mailer: Apple Mail (2.1508) Cc: "sacm@ietf.org" Subject: Re: [sacm] XORCISM eXtensible Open Research on Cyber Information Security Models X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 17:13:23 -0000 It is a Secure Short URL Service The full URL is http://frhack.org/research/xorcism.php Best regards On Jul 25, 2013, at 9:02 PM, "Wienholt, Edward" wrote: > All, > > Is this a valid website? The mcaf.ee address hints that it may be a > malicious site and that this is a phishing email. > > Edward Wienholt > I411 Cyber Security Methods & Technologies Office > Computer Network Defense Research and Technology (CND R&T) Team > Phone: 443-634-0270 > Fax 410-854-4681 > emwienh@nsa.gov > > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Jerome Athias > Sent: Thursday, July 25, 2013 9:04 AM > To: sacm@ietf.org > Subject: [sacm] XORCISM eXtensible Open Research on Cyber Information > Security Models > > Hi, > > I would appreciate any feedback on this research. > http://mcaf.ee/31d9q > > Thank you > Best regards > > Jerome Athias > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From Adam.Montville@cisecurity.org Thu Jul 25 10:37:23 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E5F21F92A5 for ; Thu, 25 Jul 2013 10:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U55lKni7gCy for ; Thu, 25 Jul 2013 10:37:18 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.8]) by ietfa.amsl.com (Postfix) with ESMTP id DC73D21F9034 for ; Thu, 25 Jul 2013 10:37:17 -0700 (PDT) Received: from [216.82.250.179:21924] by server-8.bemta-12.messagelabs.com id 49/9A-31440-B4261F15; Thu, 25 Jul 2013 17:37:15 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-7.tower-210.messagelabs.com!1374773834!8995823!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 5552 invoked from network); 25 Jul 2013 17:37:15 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-7.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 25 Jul 2013 17:37:15 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 25 Jul 2013 13:36:55 -0400 From: Adam Montville To: Sean Turner , "sacm@ietf.org" Thread-Topic: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt Thread-Index: AQHOflbaeQpXtrNVV0OhXxAJ+XuCypl1swmQgAALEVA= Date: Thu, 25 Jul 2013 17:36:56 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6737A73@CISEXCHANGE1.msisac.org.local> References: <20130711165015.29939.87432.idtracker@ietfa.amsl.com> <51DEE295.3050403@ieca.com> <05BCCEB107AF88469B9F99783D47C1D6737A4F@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6737A4F@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 17:37:23 -0000 I may have answered my own question actually digging into it. So, if I'm = understanding this right, it seems like we'd be seeing arcs that would hav= e OIDs that are named, which would have some node that acts as a class of = the instances found below... Maybe I'm still wrong. More digging. > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Thursday, July 25, 2013 10:04 AM > To: Sean Turner; sacm@ietf.org > Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-= > 00.txt >=20 > Being the transcriber of NISTS Asset Identification standard to an I-D f= ormat > (now expired), I have some questions about this proposal. First, howeve= r, I > like the way this reads and flows and I enjoyed reading it, much like I = enjoyed > reading the alternate architecture document. >=20 > It seems that draft-handt-sacm-asset-identifiers-00 is squarely focused = on > instance-level identity, identification, and identifiers. I believe, th= at we have > several levels of "identification" requirements. We do want instance-le= vel > identification, and I believe OIDs, as proposed, could be a good solutio= n. I > believe we also want class-level identification, for which we have been > considering CPE. >=20 > For example, I may have several OIDs, one for each of a Windows Server > 2008 instance, RHEL 6 instance, Windows Server 2012 instance, and Solari= s 9 > instance. Now, I want to find all the assets in the "Windows" class, wh= ich > would be the set of two OIDs representing the WS2008 and WS2012 > instances. We could leave it up to implementers to provide this type of= > functionality, but would it not be useful to have some standardized way = to > represent that class? >=20 > An honest question: How would this proposal handle class-level > identification? Or, do we collectively believe there is no such need? >=20 > Adam >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Sean Turner > > Sent: Thursday, July 11, 2013 9:51 AM > > To: sacm@ietf.org > > Subject: [sacm] Fwd: I-D Action: > > draft-handt-sacm-asset-identifiers-00.txt > > > > More food for thought. > > > > spt > > > > -------- Original Message -------- > > Subject: I-D Action: draft-handt-sacm-asset-identifiers-00.txt > > Date: Thu, 11 Jul 2013 09:50:15 -0700 > > From: internet-drafts@ietf.org > > Reply-To: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > =09Title : sacm: Asset Identifier > > =09Author(s) : Russ Housley > > Sean Turner > > =09Filename : draft-handt-sacm-asset-identifiers-00.txt > > =09Pages : 7 > > =09Date : 2013-07-11 > > > > Abstract: > > This document examines the asset identifiers available for sacm an= d > > it proposes that OIDs (Object Identifiers) be selected as the asse= t > > identifier format. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-handt-sacm-asset-identifiers > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-handt-sacm-asset-identifiers-00 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > > ... >=20 > This message and attachments may contain confidential information. If i= t > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments i= s > strictly prohibited. Please notify the sender immediately and permanent= ly > delete the message and any attachments. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From gunnar.engelbach@threatguard.com Thu Jul 25 10:52:23 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F3521F8FF8 for ; Thu, 25 Jul 2013 10:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uyn9XjgylYkf for ; Thu, 25 Jul 2013 10:52:11 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6D81E21F842B for ; Thu, 25 Jul 2013 10:52:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=dKA0nYuI2ZK3kaSVp82Dr42uAGn1RWa2OhYaxqy7ccPeY8UQZ46JMQXUL4FobpPRvmruJjGD+JmJqLBjyJTLGIq56UI1+9XYwFFt52texlt/xjmCU4i9X3XUcngM13WP; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 26780 invoked from network); 25 Jul 2013 10:50:27 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 25 Jul 2013 10:50:26 -0700 Message-ID: <51F165C8.7070404@ThreatGuard.com> Date: Thu, 25 Jul 2013 13:52:08 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Montville References: <20130711165015.29939.87432.idtracker@ietfa.amsl.com> <51DEE295.3050403@ieca.com> <05BCCEB107AF88469B9F99783D47C1D6737A4F@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6737A4F@CISEXCHANGE1.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sean Turner , "sacm@ietf.org" Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 17:52:23 -0000 On 7/25/2013 1:04 PM, Adam Montville wrote: > Being the transcriber of NISTS Asset Identification standard to an I-D format (now expired), I have some questions about this proposal. First, however, I like the way this reads and flows and I enjoyed reading it, much like I enjoyed reading the alternate architecture document. > > It seems that draft-handt-sacm-asset-identifiers-00 is squarely focused on instance-level identity, identification, and identifiers. I believe, that we have several levels of "identification" requirements. We do want instance-level identification, and I believe OIDs, as proposed, could be a good solution. I believe we also want class-level identification, for which we have been considering CPE. > > For example, I may have several OIDs, one for each of a Windows Server 2008 instance, RHEL 6 instance, Windows Server 2012 instance, and Solaris 9 instance. Now, I want to find all the assets in the "Windows" class, which would be the set of two OIDs representing the WS2008 and WS2012 instances. We could leave it up to implementers to provide this type of functionality, but would it not be useful to have some standardized way to represent that class? > > An honest question: How would this propsal handle class-level identification? Or, do we collectively believe there is no such need? There is definitely a need for a class-level ID. In fact, from a SACM perspective, I'd say it's more important than an instance-level ID. --gun > > Adam > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Sean Turner >> Sent: Thursday, July 11, 2013 9:51 AM >> To: sacm@ietf.org >> Subject: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt >> >> More food for thought. >> >> spt >> >> -------- Original Message -------- >> Subject: I-D Action: draft-handt-sacm-asset-identifiers-00.txt >> Date: Thu, 11 Jul 2013 09:50:15 -0700 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : sacm: Asset Identifier >> Author(s) : Russ Housley >> Sean Turner >> Filename : draft-handt-sacm-asset-identifiers-00.txt >> Pages : 7 >> Date : 2013-07-11 >> >> Abstract: >> This document examines the asset identifiers available for sacm and >> it proposes that OIDs (Object Identifiers) be selected as the asset >> identifier format. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-handt-sacm-asset-identifiers >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-handt-sacm-asset-identifiers-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> >> ... > > This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From dromasca@avaya.com Fri Jul 26 00:26:09 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5241821F852D for ; Fri, 26 Jul 2013 00:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.379 X-Spam-Level: X-Spam-Status: No, score=-103.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1AqRTnue6Zc for ; Fri, 26 Jul 2013 00:26:03 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 53E1A21F84EF for ; Fri, 26 Jul 2013 00:26:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosZABgk8lHGmAcV/2dsb2JhbABRCYJlITVQqSAXBpQCAwGBFRZ0giQBAQEBAwEBAQ8oNBcEAgEIDQQBAgEBAQsUCQcnCxQDAQUIAgQBEggBEgeHbgELnHubfBeOMxJMOywHBQaDDG4DmQiFHYVkhSODFIIq X-IronPort-AV: E=Sophos;i="4.89,749,1367985600"; d="scan'208";a="17867997" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Jul 2013 03:26:00 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Jul 2013 03:23:22 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Fri, 26 Jul 2013 03:25:58 -0400 From: "Romascanu, Dan (Dan)" To: Adam Montville , Sean Turner , "sacm@ietf.org" Thread-Topic: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt Thread-Index: AQHOflbaeQpXtrNVV0OhXxAJ+XuCypl1swmQgAALEVCAAOeS0A== Date: Fri, 26 Jul 2013 07:25:58 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12881D69@AZ-FFEXMB04.global.avaya.com> References: <20130711165015.29939.87432.idtracker@ietfa.amsl.com> <51DEE295.3050403@ieca.com> <05BCCEB107AF88469B9F99783D47C1D6737A4F@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D6737A73@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6737A73@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 07:26:09 -0000 OIDs are basically a tree structure. One can design the tree so that OIDs b= elonging to the same class are grouped under the same node.=20 Would this be sufficient?=20 Regards, Dan > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Thursday, July 25, 2013 8:37 PM > To: Sean Turner; sacm@ietf.org > Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers- > 00.txt >=20 > I may have answered my own question actually digging into it. So, if > I'm understanding this right, it seems like we'd be seeing arcs that > would have OIDs that are named, which would have some node that acts as > a class of the instances found below... Maybe I'm still wrong. More > digging. >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Thursday, July 25, 2013 10:04 AM > > To: Sean Turner; sacm@ietf.org > > Subject: Re: [sacm] Fwd: I-D Action: > > draft-handt-sacm-asset-identifiers- > > 00.txt > > > > Being the transcriber of NISTS Asset Identification standard to an I-D > > format (now expired), I have some questions about this proposal. > > First, however, I like the way this reads and flows and I enjoyed > > reading it, much like I enjoyed reading the alternate architecture > document. > > > > It seems that draft-handt-sacm-asset-identifiers-00 is squarely > > focused on instance-level identity, identification, and identifiers. > > I believe, that we have several levels of "identification" > > requirements. We do want instance-level identification, and I believe > > OIDs, as proposed, could be a good solution. I believe we also want > > class-level identification, for which we have been considering CPE. > > > > For example, I may have several OIDs, one for each of a Windows Server > > 2008 instance, RHEL 6 instance, Windows Server 2012 instance, and > > Solaris 9 instance. Now, I want to find all the assets in the > > "Windows" class, which would be the set of two OIDs representing the > > WS2008 and WS2012 instances. We could leave it up to implementers to > > provide this type of functionality, but would it not be useful to have > > some standardized way to represent that class? > > > > An honest question: How would this proposal handle class-level > > identification? Or, do we collectively believe there is no such need? > > > > Adam > > > > > -----Original Message----- > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > > Of Sean Turner > > > Sent: Thursday, July 11, 2013 9:51 AM > > > To: sacm@ietf.org > > > Subject: [sacm] Fwd: I-D Action: > > > draft-handt-sacm-asset-identifiers-00.txt > > > > > > More food for thought. > > > > > > spt > > > > > > -------- Original Message -------- > > > Subject: I-D Action: draft-handt-sacm-asset-identifiers-00.txt > > > Date: Thu, 11 Jul 2013 09:50:15 -0700 > > > From: internet-drafts@ietf.org > > > Reply-To: internet-drafts@ietf.org > > > To: i-d-announce@ietf.org > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > > > > Title : sacm: Asset Identifier > > > Author(s) : Russ Housley > > > Sean Turner > > > Filename : draft-handt-sacm-asset-identifiers-00.txt > > > Pages : 7 > > > Date : 2013-07-11 > > > > > > Abstract: > > > This document examines the asset identifiers available for sacm > and > > > it proposes that OIDs (Object Identifiers) be selected as the > asset > > > identifier format. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-handt-sacm-asset-identifiers > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-handt-sacm-asset-identifiers-00 > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > ... > > > > This message and attachments may contain confidential information. If > > it appears that this message was sent to you by mistake, any > > retention, dissemination, distribution or copying of this message and > > attachments is strictly prohibited. Please notify the sender > > immediately and permanently delete the message and any attachments. > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > > ... >=20 > This message and attachments may contain confidential information. If > it appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments > is strictly prohibited. Please notify the sender immediately and > permanently delete the message and any attachments. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From turners@ieca.com Fri Jul 26 03:17:20 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6569921F91CA for ; Fri, 26 Jul 2013 03:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b-yhKhursqx for ; Fri, 26 Jul 2013 03:17:15 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.125.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEDD21F85B8 for ; Fri, 26 Jul 2013 03:17:15 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 3AA9CEF0EDAC1; Fri, 26 Jul 2013 05:17:14 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 2EF53EF0EDA9A for ; Fri, 26 Jul 2013 05:17:14 -0500 (CDT) Received: from [198.180.150.142] (port=49258 helo=eb-ef.conference.fu-berlin.de) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1V2f5F-0005am-L8; Fri, 26 Jul 2013 05:17:13 -0500 Message-ID: <51F24CA8.5060200@ieca.com> Date: Fri, 26 Jul 2013 12:17:12 +0200 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Montville References: <20130711165015.29939.87432.idtracker@ietfa.amsl.com> <51DEE295.3050403@ieca.com> <05BCCEB107AF88469B9F99783D47C1D6737A4F@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D6737A73@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA12881D69@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12881D69@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (eb-ef.conference.fu-berlin.de) [198.180.150.142]:49258 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "Romascanu, Dan \(Dan\)" , "sacm@ietf.org" Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 10:17:20 -0000 Dan beat me to it. It's a tree structure that may or may not have meaning at each "node". It depends on what we're looking for. spt On 7/26/13 9:25 AM, Romascanu, Dan (Dan) wrote: > OIDs are basically a tree structure. One can design the tree so that OIDs belonging to the same class are grouped under the same node. > > Would this be sufficient? > > Regards, > > Dan > > > > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Adam Montville >> Sent: Thursday, July 25, 2013 8:37 PM >> To: Sean Turner; sacm@ietf.org >> Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers- >> 00.txt >> >> I may have answered my own question actually digging into it. So, if >> I'm understanding this right, it seems like we'd be seeing arcs that >> would have OIDs that are named, which would have some node that acts as >> a class of the instances found below... Maybe I'm still wrong. More >> digging. >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>> Of Adam Montville >>> Sent: Thursday, July 25, 2013 10:04 AM >>> To: Sean Turner; sacm@ietf.org >>> Subject: Re: [sacm] Fwd: I-D Action: >>> draft-handt-sacm-asset-identifiers- >>> 00.txt >>> >>> Being the transcriber of NISTS Asset Identification standard to an I-D >>> format (now expired), I have some questions about this proposal. >>> First, however, I like the way this reads and flows and I enjoyed >>> reading it, much like I enjoyed reading the alternate architecture >> document. >>> >>> It seems that draft-handt-sacm-asset-identifiers-00 is squarely >>> focused on instance-level identity, identification, and identifiers. >>> I believe, that we have several levels of "identification" >>> requirements. We do want instance-level identification, and I believe >>> OIDs, as proposed, could be a good solution. I believe we also want >>> class-level identification, for which we have been considering CPE. >>> >>> For example, I may have several OIDs, one for each of a Windows Server >>> 2008 instance, RHEL 6 instance, Windows Server 2012 instance, and >>> Solaris 9 instance. Now, I want to find all the assets in the >>> "Windows" class, which would be the set of two OIDs representing the >>> WS2008 and WS2012 instances. We could leave it up to implementers to >>> provide this type of functionality, but would it not be useful to have >>> some standardized way to represent that class? >>> >>> An honest question: How would this proposal handle class-level >>> identification? Or, do we collectively believe there is no such need? >>> >>> Adam >>> >>>> -----Original Message----- >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>>> Of Sean Turner >>>> Sent: Thursday, July 11, 2013 9:51 AM >>>> To: sacm@ietf.org >>>> Subject: [sacm] Fwd: I-D Action: >>>> draft-handt-sacm-asset-identifiers-00.txt >>>> >>>> More food for thought. >>>> >>>> spt >>>> >>>> -------- Original Message -------- >>>> Subject: I-D Action: draft-handt-sacm-asset-identifiers-00.txt >>>> Date: Thu, 11 Jul 2013 09:50:15 -0700 >>>> From: internet-drafts@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>> >>>> >>>> Title : sacm: Asset Identifier >>>> Author(s) : Russ Housley >>>> Sean Turner >>>> Filename : draft-handt-sacm-asset-identifiers-00.txt >>>> Pages : 7 >>>> Date : 2013-07-11 >>>> >>>> Abstract: >>>> This document examines the asset identifiers available for sacm >> and >>>> it proposes that OIDs (Object Identifiers) be selected as the >> asset >>>> identifier format. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-handt-sacm-asset-identifiers >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-handt-sacm-asset-identifiers-00 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>>> >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>>> >>>> ... >>> >>> This message and attachments may contain confidential information. If >>> it appears that this message was sent to you by mistake, any >>> retention, dissemination, distribution or copying of this message and >>> attachments is strictly prohibited. Please notify the sender >>> immediately and permanently delete the message and any attachments. >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>> >>> ... >> >> This message and attachments may contain confidential information. If >> it appears that this message was sent to you by mistake, any retention, >> dissemination, distribution or copying of this message and attachments >> is strictly prohibited. Please notify the sender immediately and >> permanently delete the message and any attachments. >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From ietfdbh@comcast.net Sat Jul 27 13:51:34 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0234A11E80F9 for ; Sat, 27 Jul 2013 13:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.163 X-Spam-Level: X-Spam-Status: No, score=-100.163 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_03_06=0.274, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b3ntPAQHCwY for ; Sat, 27 Jul 2013 13:51:28 -0700 (PDT) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:80]) by ietfa.amsl.com (Postfix) with ESMTP id 3A67511E80F7 for ; Sat, 27 Jul 2013 13:51:24 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta08.emeryville.ca.mail.comcast.net with comcast id 5Yoj1m0021afHeLA8YrPqT; Sat, 27 Jul 2013 20:51:23 +0000 Received: from [130.129.70.183] ([130.129.70.183]) by omta17.emeryville.ca.mail.comcast.net with comcast id 5Yr31m00F3xFRL28dYr7Cc; Sat, 27 Jul 2013 20:51:21 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Sat, 27 Jul 2013 22:51:01 -0400 From: David Harrington To: "Waltermire, David A." , Gunnar Engelbach Message-ID: Thread-Topic: [sacm] Use Case Discussion: Suspicious Endpoint Behavior In-Reply-To: <1130fe7ac042403d84991ff1f66db777@BLUPR09MB038.namprd09.prod.outlook.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374958283; bh=CwDhqG/LjFe3jNumz6UXQJzay8EhhVi1SS+x3su/47I=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=R1FYRmem6WCbomDnGOGU3Dh3QjcqVpuG6Sdfu3uT2SQbZQoEEn0aSWckDuoyWa3Ti hb1rGx68gjVsYVPFtW0EdnCTBvKWTuwytfdAYf5jae1lpfFQiCyFJK9ORQ6nPYVqs7 7hed7+hf8dpmDbuxdbQbyoa6aa+wr4NzaQAURs3HvRl83NzY5ljclgK0N9tX8w1uQt az5f4r7CJdEfA0dx9ol4Iv5KmanfqN9OYw47QL9Y3KhVVyl9jzEVqHObVrnQozkjQb yQDFA5oH2w6Mr4GSXHqfl9/NjL3yUzXECB3lvgqNR8hfSmfSTlOsnc6nTAs7UTtc5q iMfJqrf9mppBA== Cc: Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] Use Case Discussion: Suspicious Endpoint Behavior X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 20:51:34 -0000 On 7/23/13 5:20 PM, "Waltermire, David A." wrote: > >> I definitely think leveraging a CMDB when available is a net positive >>and >> should be supported, but it also creates other problems and should not >>be >> *required*. > >None of what we do will be required; it will all be voluntary. They key >is to enable the endpoint to publish changes based on events. How that >published data gets processed and persisted is a downstream concern. The >architecture should allow for a variety of solutions that handle the info >in various ways providing organizations and vendors with some flexibility >in deployed architectures. What we want is a reasonable degree of >interoperability with regards to the individual components. See RFC 3365 "Strong Security Requirements for Internet Engineering Task Force Standard Protocols" To claim compliance to the standards, implementers MUST implement the "required" aspects of the standard. But it is up to the deployer/user/operator whether to use each feature. So a significant portion of what we do should be "required to implement", otherwise it isn't really a standard, and implementations will likely not interoperate. > >-- >David Harrington >Ietfdbh@comcast.net >+1-603-828-1401 > > From Adam.Montville@cisecurity.org Mon Jul 29 00:45:57 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8387621F999E for ; Mon, 29 Jul 2013 00:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.142 X-Spam-Level: X-Spam-Status: No, score=-3.142 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QptOey10kDOE for ; Mon, 29 Jul 2013 00:45:51 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.110]) by ietfa.amsl.com (Postfix) with ESMTP id B077721F99DA for ; Mon, 29 Jul 2013 00:45:46 -0700 (PDT) Received: from [216.82.253.227:57849] by server-14.bemta-7.messagelabs.com id AF/48-13364-9AD16F15; Mon, 29 Jul 2013 07:45:45 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-13.tower-170.messagelabs.com!1375083944!19687267!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 13899 invoked from network); 29 Jul 2013 07:45:45 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-13.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 29 Jul 2013 07:45:45 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Mon, 29 Jul 2013 03:45:36 -0400 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Are you in Berlin? Thread-Index: Ac6MLqnWCGhLK3PrRGe9OiCOmFxJ8A== Date: Mon, 29 Jul 2013 07:45:19 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6738E58@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] Are you in Berlin? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 07:45:57 -0000 Let me know. It would be good to get together before Friday's meeting. Adam This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From bakerj@mitre.org Mon Jul 29 05:00:05 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657AE21F9C05 for ; Mon, 29 Jul 2013 05:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSh8+Qz8YYG7 for ; Mon, 29 Jul 2013 04:59:58 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A7CC421F9BA2 for ; Mon, 29 Jul 2013 04:59:57 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2AB3F1F0817; Mon, 29 Jul 2013 07:59:57 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 16F1B1F0584; Mon, 29 Jul 2013 07:59:57 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.165]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0342.003; Mon, 29 Jul 2013 07:59:56 -0400 From: "Baker, Jon" To: Sean Turner , Adam Montville Thread-Topic: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt Thread-Index: AQHOielSwf7rGRl9UEGPCH4tOIlvY5l7kNrw Date: Mon, 29 Jul 2013 11:59:55 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651304D24C26@IMCMBX03.MITRE.ORG> References: <20130711165015.29939.87432.idtracker@ietfa.amsl.com> <51DEE295.3050403@ieca.com> <05BCCEB107AF88469B9F99783D47C1D6737A4F@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D6737A73@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA12881D69@AZ-FFEXMB04.global.avaya.com> <51F24CA8.5060200@ieca.com> In-Reply-To: <51F24CA8.5060200@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Romascanu, Dan \(Dan\)" , "sacm@ietf.org" Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:00:05 -0000 Quick comment on the draft. I found the following text in the CPE section: " Another major issue with CPE is process by which one is obtained; an application needs to be submitted to NVD (National Vulnerability Database), which is run by the USG (United States Government). This simple fact likely renders CPE, as it is currently specified and operated, as unsatisfactory as the basis for sacm because there will be some non-US entity unwilling or unable to submit an application." CPE 2.3 allows for multiple CPE dictionaries to be maintained. NIST operate= s the Official CPE dictionary at this time, but we certainly envisioned ven= dors operating their own CPE dictionaries. For CPE, there are outstanding q= uestions of how best to manage cpe names. To be clear, CPE should not be considered an Asset Identifier. It was not d= esigned for that purpose. Thanks, Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Sean Turner >Sent: Friday, July 26, 2013 6:17 AM >To: Adam Montville >Cc: Romascanu, Dan (Dan); sacm@ietf.org >Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers-00= .txt > >Dan beat me to it. It's a tree structure that may or may not have >meaning at each "node". It depends on what we're looking for. > >spt > >On 7/26/13 9:25 AM, Romascanu, Dan (Dan) wrote: >> OIDs are basically a tree structure. One can design the tree so that OID= s >belonging to the same class are grouped under the same node. >> >> Would this be sufficient? >> >> Regards, >> >> Dan >> >> >> >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >Of >>> Adam Montville >>> Sent: Thursday, July 25, 2013 8:37 PM >>> To: Sean Turner; sacm@ietf.org >>> Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-asset-identifiers= - >>> 00.txt >>> >>> I may have answered my own question actually digging into it. So, if >>> I'm understanding this right, it seems like we'd be seeing arcs that >>> would have OIDs that are named, which would have some node that acts >as >>> a class of the instances found below... Maybe I'm still wrong. More >>> digging. >>> >>>> -----Original Message----- >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>>> Of Adam Montville >>>> Sent: Thursday, July 25, 2013 10:04 AM >>>> To: Sean Turner; sacm@ietf.org >>>> Subject: Re: [sacm] Fwd: I-D Action: >>>> draft-handt-sacm-asset-identifiers- >>>> 00.txt >>>> >>>> Being the transcriber of NISTS Asset Identification standard to an I-D >>>> format (now expired), I have some questions about this proposal. >>>> First, however, I like the way this reads and flows and I enjoyed >>>> reading it, much like I enjoyed reading the alternate architecture >>> document. >>>> >>>> It seems that draft-handt-sacm-asset-identifiers-00 is squarely >>>> focused on instance-level identity, identification, and identifiers. >>>> I believe, that we have several levels of "identification" >>>> requirements. We do want instance-level identification, and I believe >>>> OIDs, as proposed, could be a good solution. I believe we also want >>>> class-level identification, for which we have been considering CPE. >>>> >>>> For example, I may have several OIDs, one for each of a Windows Server >>>> 2008 instance, RHEL 6 instance, Windows Server 2012 instance, and >>>> Solaris 9 instance. Now, I want to find all the assets in the >>>> "Windows" class, which would be the set of two OIDs representing the >>>> WS2008 and WS2012 instances. We could leave it up to implementers to >>>> provide this type of functionality, but would it not be useful to have >>>> some standardized way to represent that class? >>>> >>>> An honest question: How would this proposal handle class-level >>>> identification? Or, do we collectively believe there is no such need? >>>> >>>> Adam >>>> >>>>> -----Original Message----- >>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>>>> Of Sean Turner >>>>> Sent: Thursday, July 11, 2013 9:51 AM >>>>> To: sacm@ietf.org >>>>> Subject: [sacm] Fwd: I-D Action: >>>>> draft-handt-sacm-asset-identifiers-00.txt >>>>> >>>>> More food for thought. >>>>> >>>>> spt >>>>> >>>>> -------- Original Message -------- >>>>> Subject: I-D Action: draft-handt-sacm-asset-identifiers-00.txt >>>>> Date: Thu, 11 Jul 2013 09:50:15 -0700 >>>>> From: internet-drafts@ietf.org >>>>> Reply-To: internet-drafts@ietf.org >>>>> To: i-d-announce@ietf.org >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>>> >>>>> >>>>> Title : sacm: Asset Identifier >>>>> Author(s) : Russ Housley >>>>> Sean Turner >>>>> Filename : draft-handt-sacm-asset-identifiers-00.txt >>>>> Pages : 7 >>>>> Date : 2013-07-11 >>>>> >>>>> Abstract: >>>>> This document examines the asset identifiers available for sacm >>> and >>>>> it proposes that OIDs (Object Identifiers) be selected as the >>> asset >>>>> identifier format. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-handt-sacm-asset-identifiers >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-handt-sacm-asset-identifiers-00 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> sacm mailing list >>>>> sacm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>> >>>>> ... >>>> >>>> This message and attachments may contain confidential information. If >>>> it appears that this message was sent to you by mistake, any >>>> retention, dissemination, distribution or copying of this message and >>>> attachments is strictly prohibited. Please notify the sender >>>> immediately and permanently delete the message and any attachments. >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>>> >>>> ... >>> >>> This message and attachments may contain confidential information. If >>> it appears that this message was sent to you by mistake, any retention, >>> dissemination, distribution or copying of this message and attachments >>> is strictly prohibited. Please notify the sender immediately and >>> permanently delete the message and any attachments. >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From Adam.Montville@cisecurity.org Mon Jul 29 11:13:57 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D589F21F87BB for ; Mon, 29 Jul 2013 11:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJSF82lfHzrS for ; Mon, 29 Jul 2013 11:13:50 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.8]) by ietfa.amsl.com (Postfix) with ESMTP id 783A621F9D35 for ; Mon, 29 Jul 2013 11:13:48 -0700 (PDT) Received: from [216.82.250.179:42005] by server-8.bemta-12.messagelabs.com id F0/42-31440-AD0B6F15; Mon, 29 Jul 2013 18:13:46 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-11.tower-210.messagelabs.com!1375121625!9032966!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 12730 invoked from network); 29 Jul 2013 18:13:46 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-11.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 29 Jul 2013 18:13:46 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Mon, 29 Jul 2013 14:13:36 -0400 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Note Taker and Jabber Scribe Thread-Index: Ac6MhqPDBCSRM6JESSK8KigDkkuMpA== Date: Mon, 29 Jul 2013 18:13:20 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6739961@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] Note Taker and Jabber Scribe X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 18:13:58 -0000 Chris has graciously volunteered to take notes during our meeting this Fri= day. =20 Who can be a jabber scribe? Adam This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From dromasca@avaya.com Mon Jul 29 21:55:48 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E6421F9E5B for ; Mon, 29 Jul 2013 21:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.38 X-Spam-Level: X-Spam-Status: No, score=-103.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do9LALB0LtNd for ; Mon, 29 Jul 2013 21:55:42 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 34EB421F9E54 for ; Mon, 29 Jul 2013 21:55:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAING91GHCzI1/2dsb2JhbABbgmUhNVC+DYEfFnSCJAEBAQEDAQEBDyg0FwQCAQgNBAQBAQsUCQcnCxQJCAEBBAESCBqHbgELnGacBhMEj004BoMSbwOeJYsGgxSCKg X-IronPort-AV: E=Sophos;i="4.89,775,1367985600"; d="scan'208";a="21522392" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 30 Jul 2013 00:55:40 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 30 Jul 2013 00:49:10 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Tue, 30 Jul 2013 06:55:38 +0200 From: "Romascanu, Dan (Dan)" To: Adam Montville , "sacm@ietf.org" Thread-Topic: Note Taker and Jabber Scribe Thread-Index: Ac6MhqPDBCSRM6JESSK8KigDkkuMpAAWiyqA Date: Tue, 30 Jul 2013 04:55:38 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1288D3B1@AZ-FFEXMB04.global.avaya.com> References: <05BCCEB107AF88469B9F99783D47C1D6739961@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6739961@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Note Taker and Jabber Scribe X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 04:55:48 -0000 It would be good to have two note takers, so that they back-up each other i= n case one of them presents or speaks at the mike. So please, keep on volun= teering.=20 Regards, Dan > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Monday, July 29, 2013 9:13 PM > To: sacm@ietf.org > Subject: [sacm] Note Taker and Jabber Scribe >=20 > Chris has graciously volunteered to take notes during our meeting this > Friday. >=20 > Who can be a jabber scribe? >=20 > Adam >=20 > This message and attachments may contain confidential information. If > it appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments > is strictly prohibited. Please notify the sender immediately and > permanently delete the message and any attachments. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From Adam.Montville@cisecurity.org Mon Jul 29 23:52:15 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFC721F9F9C for ; Mon, 29 Jul 2013 23:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlRgkI1c0EoK for ; Mon, 29 Jul 2013 23:52:10 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.13]) by ietfa.amsl.com (Postfix) with ESMTP id 214EE21F9F7F for ; Mon, 29 Jul 2013 23:52:10 -0700 (PDT) Received: from [216.82.250.19:43369] by server-13.bemta-12.messagelabs.com id 6D/BC-06194-39267F15; Tue, 30 Jul 2013 06:52:03 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-16.tower-87.messagelabs.com!1375167121!14125034!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 29333 invoked from network); 30 Jul 2013 06:52:02 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-16.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 30 Jul 2013 06:52:02 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Tue, 30 Jul 2013 02:51:52 -0400 From: Adam Montville To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: Note Taker and Jabber Scribe Thread-Index: Ac6MhqPDBCSRM6JESSK8KigDkkuMpAAWiyqAAAQSxCA= Date: Tue, 30 Jul 2013 06:51:34 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6739D3C@CISEXCHANGE1.msisac.org.local> References: <05BCCEB107AF88469B9F99783D47C1D6739961@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA1288D3B1@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1288D3B1@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Note Taker and Jabber Scribe X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 06:52:15 -0000 So far we can thank Chris Ignacio for volunteering to take notes and Jon B= aker for volunteering to be Jabber scribe... =20 We need just one more note taker... Anyone? Adam > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Monday, July 29, 2013 9:55 PM > To: Adam Montville; sacm@ietf.org > Subject: RE: Note Taker and Jabber Scribe >=20 > It would be good to have two note takers, so that they back-up each othe= r in > case one of them presents or speaks at the mike. So please, keep on > volunteering. >=20 > Regards, >=20 > Dan >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Monday, July 29, 2013 9:13 PM > > To: sacm@ietf.org > > Subject: [sacm] Note Taker and Jabber Scribe > > > > Chris has graciously volunteered to take notes during our meeting this= > > Friday. > > > > Who can be a jabber scribe? > > > > Adam > > > > This message and attachments may contain confidential information. If= > > it appears that this message was sent to you by mistake, any > > retention, dissemination, distribution or copying of this message and > > attachments is strictly prohibited. Please notify the sender > > immediately and permanently delete the message and any attachments. > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From dromasca@avaya.com Wed Jul 31 01:47:30 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2453221F9C90 for ; Wed, 31 Jul 2013 01:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.387 X-Spam-Level: X-Spam-Status: No, score=-103.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLNrfA2V7xlI for ; Wed, 31 Jul 2013 01:47:22 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id AEE5C21E811D for ; Wed, 31 Jul 2013 01:39:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAHjM+FHGmAcV/2dsb2JhbABbgmUhgQW+HIEXFnSCJgEBAxJ5ARUVViYBBBsah24BmAWERJwMj02DUHEDiHKVM4sGgxSCKg X-IronPort-AV: E=Sophos;i="4.89,785,1367985600"; d="scan'208";a="18385019" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 31 Jul 2013 04:39:26 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 Jul 2013 04:36:30 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0146.000; Wed, 31 Jul 2013 04:39:25 -0400 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: SACM at IETF-87 Thread-Index: Ac6NyXSy0vNP+4AmQzKrx5qyJPuXjQ== Date: Wed, 31 Jul 2013 08:39:23 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128900D5@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] SACM at IETF-87 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 08:47:30 -0000 This is a reminder that:=20 - the SACM meeting is scheduled for Friday 8/2 - we need slides in advance from all presenters - we are still in need of one volunteer for notes taking and jabber - we shall meet tomorrow morning (Thursday 8/1) at breakfast for a welcome = session for newcomers. Meeting place at 8AM at the entry of the breakfast p= lace of the InterContinental hotel (LA Caf=E9) Regards, Adam and Dan From Adam.Montville@cisecurity.org Wed Jul 31 07:05:36 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D5B21E8129 for ; Wed, 31 Jul 2013 07:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.78 X-Spam-Level: X-Spam-Status: No, score=-2.78 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG7w9UFJJ1QH for ; Wed, 31 Jul 2013 07:05:30 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.198]) by ietfa.amsl.com (Postfix) with ESMTP id 466F011E8172 for ; Wed, 31 Jul 2013 07:05:19 -0700 (PDT) Received: from [216.82.241.211:18161] by server-6.bemta-8.messagelabs.com id A6/A9-27210-49919F15; Wed, 31 Jul 2013 14:05:08 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-6.tower-85.messagelabs.com!1375279508!36213909!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 382 invoked from network); 31 Jul 2013 14:05:08 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-6.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 31 Jul 2013 14:05:08 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Wed, 31 Jul 2013 10:04:55 -0400 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Updated sacm Agenda Thread-Index: Ac6N9p1QDIUTprlwQMKIvSFcwdVEAQ== Date: Wed, 31 Jul 2013 14:04:38 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D673AC41@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] Updated sacm Agenda X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:05:36 -0000 Please note that the sacm agenda has been updated. See: http://www.ietf.org/proceedings/87/agenda/agenda-87-sacm This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From shanna@juniper.net Wed Jul 31 07:13:41 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B57711E81B5 for ; Wed, 31 Jul 2013 07:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.466 X-Spam-Level: X-Spam-Status: No, score=-100.466 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSrOdWBXSsrs for ; Wed, 31 Jul 2013 07:13:33 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 72C5711E818B for ; Wed, 31 Jul 2013 07:13:32 -0700 (PDT) Received: from mail101-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 14:13:31 +0000 Received: from mail101-va3 (localhost [127.0.0.1]) by mail101-va3-R.bigfish.com (Postfix) with ESMTP id 45BAA3A00CB for ; Wed, 31 Jul 2013 14:13:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz9371Ic85fh1454I604I4015I13e6Kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1d7338h1de098h1033IL17326ah30d1K18c673h1c8fb4h1de096h8275bh8275dh1de097hz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail101-va3: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=shanna@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail101-va3 (localhost.localdomain [127.0.0.1]) by mail101-va3 (MessageSwitch) id 1375280006515893_12908; Wed, 31 Jul 2013 14:13:26 +0000 (UTC) Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.249]) by mail101-va3.bigfish.com (Postfix) with ESMTP id 6F1BE4A00DD for ; Wed, 31 Jul 2013 14:13:26 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.50) by VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 14:13:20 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 31 Jul 2013 07:13:19 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Wed, 31 Jul 2013 07:13:19 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.206) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 31 Jul 2013 07:26:16 -0700 Received: from mail78-am1-R.bigfish.com (10.3.201.231) by AM1EHSOBE021.bigfish.com (10.3.207.143) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 14:13:16 +0000 Received: from mail78-am1 (localhost [127.0.0.1]) by mail78-am1-R.bigfish.com (Postfix) with ESMTP id AD4504400F6 for ; Wed, 31 Jul 2013 14:13:16 +0000 (UTC) Received: from mail78-am1 (localhost.localdomain [127.0.0.1]) by mail78-am1 (MessageSwitch) id 1375279993288988_21287; Wed, 31 Jul 2013 14:13:13 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.228]) by mail78-am1.bigfish.com (Postfix) with ESMTP id 3FDCA4A004E; Wed, 31 Jul 2013 14:13:13 +0000 (UTC) Received: from SN2PRD0510HT004.namprd05.prod.outlook.com (157.56.234.117) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 14:13:12 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.38]) by SN2PRD0510HT004.namprd05.prod.outlook.com ([10.255.116.39]) with mapi id 14.16.0341.000; Wed, 31 Jul 2013 14:13:10 +0000 From: Stephen Hanna To: "Romascanu, Dan (Dan)" , David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] Use Cases Style Thread-Index: Ac6GQp344HxcyhkLR3e12+XSKp8ZmgC+OvBQAAjRrIA= Date: Wed, 31 Jul 2013 14:13:09 +0000 Message-ID: References: <005701ce8649$b5dd8010$21988030$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12881204@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12881204@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_F1DFC16DCAA7D3468651A5A776D5796E1AACF8ACSN2PRD0510MB372_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%AVAYA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%COMCAST.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] Use Cases Style X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:13:41 -0000 --_000_F1DFC16DCAA7D3468651A5A776D5796E1AACF8ACSN2PRD0510MB372_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I should have responded to this thread earlier. I have been waiting to find= enough time to write a long response as Dan did. However, it seems that I = won't find that time before the SACM WG meeting so I'll just say: I also favor the IETF approach to use case style: a brief summary of the pr= oblem to be solved. In my view, providing a detailed walkthrough of the solution tends to restr= ict the architectural options. We're not ready for that yet. Instead, we sh= ould focus our use cases on the problem to be solved. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, July 25, 2013 9:41 AM To: David Harrington; sacm@ietf.org Subject: Re: [sacm] Use Cases Style Hi, I am certainly culturally biased in this dispute for the very simple and ob= vious reason that I have spent too much time in the IETF and too little to = zero time in other security-oriented organizations, so I am familiar with t= he 'IETF approach' while the 'usability.gov approach' seems strange to me. I do have however one question that seems to me to go beyond the 'style' is= sues. The usability.gov examples include definition and actions (procedures= ) executed by actors who are I believe what we call in IETF terms 'human op= erators' using the network and the systems. It is very seldom that the IETF= defines anything that deals with human operators actions in standards-trac= k documents. At most we may make operational recommendations, never beyond = the BCP level. Maybe this discussion is useful to clarify the use cases, but I do not see = how the 'actors' actions fit into the current WG charter. Am I mistaken? Do= I miss something important? Thanks and Regards, Dan From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of David Harrington Sent: Sunday, July 21, 2013 10:37 PM To: sacm@ietf.org Subject: [sacm] Use Cases Style Hi, There has been some debate about the amount of detail and the formality of = the format used in our use cases document. I have argued for IETF-style use cases; Adam has argued for a systems engin= eering style, recommending the Martin Fowler format. The IETF approach: I recommended that people look at other IETF Use Case documents to see what= is "normal" for IETF use case documents. Knowing that everybody is busy, I assumed few if any would actually do so. So to move the discussion forward, I searched for RFCs with "Use Case" in t= he title. Then I looked at each, and copied a quote from the text about the purpose = of each document (where available) I then copied in a sample use case from each document. I was planning to make these into a PowerPoint presentation (I expected tha= t would be very hard to do, given the space limitations of a slide). So I chose short examples. Feel free to look at longer examples if you want. My samples of IETF use cases are in the attached file. The usability.gov approach (http://www.usability.gov/how-to-and-tools/metho= ds/use-cases.html) Elements of a Use Case Depending on how in depth and complex you want or need to get, use cases de= scribe a combination of the following elements: *Actor - anyone or anything that performs a behavior (who is using the syst= em) *Stakeholder - someone or something with vested interests in the behavior o= f the system under discussion (SUD) *Primary Actor - stakeholder who initiates an interaction with the system t= o achieve a goal *Preconditions - what must be true or happen before and after the use case = runs. *Triggers - this is the event that causes the use case to be initiated. *Main success scenarios [Basic Flow] - use case in which nothing goes wrong= . *Alternative paths [Alternative Flow] - these paths are a variation on the = main theme. These exceptions are what happen when things go wrong at the sy= stem level. How To Write a Use Case Write the steps in a use case in an easy-to-understand narrative. Kenworthy= (1997) outlines the following steps: 1. Identify who is going to be using the website. 2. Pick one of those users. 3. Define what that user wants to do on the site. Each thing the use = does on the site becomes a use case. 4. For each use case, decide on the normal course of events when that= user is using the site. 5. Describe the basic course in the description for the use case. Des= cribe it in terms of what the user does and what the system does in respons= e that the user should be aware of. 6. When the basic course is described, consider alternate courses of = events and add those to "extend" the use case. 7. Look for commonalities among the use cases. Extract these and note= them as common course use cases. 8. Repeat the steps 2 through 7 for all other users. Middleweight Laundry Use Case Use Case 1: Do laundry Actor: Housekeeper Basic Flow: On Wednesdays, the housekeeper reports to the laundry room. Sh= e sorts the laundry that is there. Then she washes each load. She dries e= ach load. She folds the items that need folding. She throws away any laund= ry item that is irrevocably shrunken, soiled or scorched. Alternative Flow 1: If she notices that something is wrinkled, she irons it= and then hangs it on a hanger. Alternative Flow 2: If she notices that something is still dirty, she rewas= hes it. Alternative Flow 3: If she notices that something shrank, she throws it out= . Adam's example use case: Use Case Name: Suspicious Endpoint Behavior Description: This Use Case describes the collaboration between specific participants in = an information security system specific to detecting a connection attempt t= o a known-bad Internet host by a botnet zombie that has made its way onto a= n organization's Information Technology systems. The primary human actor i= s the Security Operations Center Analyst, and the primary software actor is= the configuration assessment tool. Note, however, the dependencies on oth= er tools, such as asset management, intrusion detection, and messaging. Actors: * Security Operations Center (SOC) Analyst, * Information Security Officer, * System Owner * Organizational Unit Leader Preconditions: * Organizational Security Policy Exists * Security Policy specifies appropriate asset management capabilities (i= .e. categorization of endpoints) * Security Policy specifies endpoint configuration baseline for asset ca= tegorization * The Organization keeps a list of known-bad Internet hosts * The Organization associates owners who are individuals with endpoints * The Organization associates organizational units with endpoints Postconditions: * Endpoint configuration has been assessed [1] * Results have been conveyed to scan requester Primary Path: 1. At 03:46 UTC an organization's Network Intrusion Detection System (NID= S) sees an IP packet with a destination IPv6 address existing on a blacklis= t of known botnet command and control (C2) servers. 2. The NIDS sends an alert to the SOC Analyst. 3. The SOC Analyst uses the information captured in the alert (IP packet = and reason for the flag) to look up the endpoint in the organization's asse= t inventory system and discovers that the endpoint is a Windows Server 2008= R2 Member Server playing the role of a File Server 4. The SOC Analyst also verifies that the IPv6 address cited by the NIDS = is, in fact, on the blacklist for known C2 servers. 5. At this point, the SOC Analyst switches over to the organization's con= figuration assessment tool 6. The SOC Analyst locates the offending endpoint in the configuration as= sessment tool's endpoint catalog [2] 7. The SOC Analyst then initiates an immediate and complete endpoint asse= ssment to determine if the endpoint has experienced any configuration drift= [3]. 8. The configuration assessment tool: 9. a. Performs a preliminary asset inventory scan on the offending endpoin= t, which results in a list of installed software [4][5] b. Performs a comparison between the last known asset inventory and the= present asset inventory and notes any differences c. Searches it's local content repository for appropriate configuration= baselines for the operating system of the offending endpoint and for each = installed piece of software d. Upon aggregating the set of applicable configuration baselines, the = configuration assessment tool then connects to and queries the organization= 's configuration content repository for newer baselines that may exist. e. If a new baseline exists, then it is returned by the configuration c= ontent repository. 10. The configuration management tool, having the set of updated baseline= s, initiates a scan against the offending host, which yields a result set. 11. The configuration management tool displays scan results to the SOC An= alyst, which show that three new pieces of software have been installed on = the offending endpoint where one piece of software is not on the authorized= software list, and that several configuration items were out of compliance= with the organization's established baselines. 12. The SOC Analyst reviews the information for accuracy and to plan next= steps before sending the report to the responsible Information Security Of= ficer, accountable System Owner, and the Organizational Unit Leader. A Note On Alternative Paths, Preconditions, and Postconditions: There are likely to be many points of optimization and optional paths. For= example, a configuration assessment tool might provide a "quick glance" lo= ok at the most recent scan history for the offending endpoint. A SOC Analy= st might then elect not to run a new scan (i.e. the offending endpoint is k= nown to be out of compliance, so why run a new scan?). Another point might= be that the offending endpoint is, at present, not authorized to be on the= network, in which case it is very likely not to exist in the configuration= assessment tool's endpoint catalog. As with alternative paths, pre-/post-conditions can vary widely. Consider = that this description likely represents an organization on the mature side = of managing information security. Many organizations do not have a Securit= y Operations Center, nor do they necessarily monitor their network. It may= be the case that a log management process has detected the blacklisted con= nection attempt through audit trail monitoring. Or, it may be the case th= at a shared indicator of compromise has been used to detect the offending e= ndpoint. ------------------- [1] I am assuming at this point that "configuration assessment" has been de= fined and will be understood by the reader. What I consider to be "assessm= ent" is that the baseline has been obtained, send to the scanning implement= ation, endpoint configuration item values have been harvested, endpoint con= figuration item values have been compared against baseline, and results sto= red/forwarded as appropriate for the use case. [2] An "endpoint catalog" is intended to convey nothing more than the notio= n that configuration assessment tools are likely to have some method of lis= ting, enumerating, or aggregating endpoints under configuration management. [3] It may not be necessary to specify what we mean by "complete" or the or= der in which scanning operations take place. In this particular scenario, = I thought it might be useful to illustrate that "scan levels" exist on a co= ntinuum. [4] Remember that the configuration assessment tool has knowledge of the of= fending endpoint so running a preliminary inventory scan is reasonable at t= his point. [5] The mechanism of scan could be agent-based or remote, so details of how= a scan happens are omitted here. A more granular partition of the process= is required for further details. This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissemi= nation, distribution or copying of this message and attachments is strictly= prohibited. Please notify the sender immediately and permanently delete t= he message and any attachments. My Comments: Executive Summary: The IETF format is what most IETF readers will expect. This format has the = drawback of not being formal, and is not necessarily very complete. If we t= o derive requirements from this freehand format, it can be more difficult. = But it is easily readable, so reviewers of our work can understand what we = are trying to accomplish. Use cases of this form help to identify the natur= e of the stakeholders involved in our WG. Operators vs vendors, service pro= viders vs enterprises, managed-device implementers vs management applicatio= n developers, and so on. This can help to categorize requirements that exis= t for some stakeholders but not all stakeholders. I think the formal approach recommended in usability.gov would be more work= for the editors to lay out the use cases in this formal format, and the AS= CII text required for RFCs makes this much harder than, say Word or HTML fo= rmats. Usability.gov step 2 says "pick one of the users" to document as the actor.= Each thing the user wants to do becomes a use case, and each possible alte= rnative action becomes a use case. Adam's example for Actor includes multiple roles, and then describes a rath= er complex use case , including footnotes. Part of my concern is that we have WG contributors coming from multiple ven= dors, with possibly multiple products, representing customers from multiple= industry segments. To fully detail each possible alternative would make it close to impossible= to actually finish this document in a reasonable amount of time. I suspect Adam combined a number of use cases together in his example, to s= implify things. However, I cannot figure out how to create English sentences from his examp= le because he has multiple actors and multiple preconditions and multiple p= ostconditions, and what seems to be a lot of irrelevant details in the Prim= ary Path. Is the fact that this happens at 3:46 UTC an important detail in = our design? Or is it an irrelevant detail? Or is it important for some use = cases (such as trying to establish behavior anomalies based on when a user = normally works, or when an attack normally happens?) but not others? I think the formal approach is over the top for our needs. The IETF approach seems more appropriate at this point in our work process. David Harrington dbharrington@comcast.net +1-603-828-1401 --_000_F1DFC16DCAA7D3468651A5A776D5796E1AACF8ACSN2PRD0510MB372_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I should have responde= d to this thread earlier. I have been waiting to find enough time to write = a long response as Dan did. However, it seems that I won’t find that = time before the SACM WG meeting so I’ll just say:

 

I also favor the IETF = approach to use case style: a brief summary of the problem to be solved.

 

In my view, providing = a detailed walkthrough of the solution tends to restrict the architectural = options. We’re not ready for that yet. Instead, we should focus our u= se cases on the problem to be solved.

 

Thanks,

 

Steve

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, July 25, 2013 9:41 AM
To: David Harrington; sacm@ietf.org=
Subject: Re: [sacm] Use Cases Style

 

Hi,<= /p>

 

I am certainly cultura= lly biased in this dispute for the very simple and obvious reason that I ha= ve spent too much time in the IETF and too little to zero time in other sec= urity-oriented organizations, so I am familiar with the ‘IETF approach’ while the ‘usab= ility.gov approach’ seems strange to me= .

 

I do have however one = question that seems to me to go beyond the ‘style’ issues. The = usability.gov examples include definition and actions (procedures) executed= by actors who are I believe what we call in IETF terms ‘human operators’ using the network and the systems. It = is very seldom that the IETF defines anything that deals with human operato= rs actions in standards-track documents. At most we may make operational re= commendations, never beyond the BCP level.

 

Maybe this discussion = is useful to clarify the use cases, but I do not see how the ‘actors&= #8217; actions fit into the current WG charter. Am I mistaken? Do I miss so= mething important?

 

Thanks and Regards,

 

Dan<= /p>

 

 

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington
Sent: Sunday, July 21, 2013 10:37 PM
To: sacm@ietf.org
Subject: [sacm] Use Cases Style

 

Hi,

 

There has been some debate about the amount of de= tail and the formality of the format used in our use cases document.

I have argued for IETF-style use cases; Adam has = argued for a systems engineering style, recommending the Martin Fowler form= at.

 

The IETF approach:

 

I recommended that people look at other IETF Use = Case documents to see what is "normal" for IETF use case document= s.

Knowing that everybody is busy, I assumed few if = any would actually do so.

So to move the discussion forward, I searched for= RFCs with "Use Case" in the title.

Then  I looked at each, and copied a quote f= rom the text about the purpose of each document (where available)

 

I then copied in a sample use case from each docu= ment.

I was planning to make these into a PowerPoint pr= esentation (I expected that would be very hard to do, given the space limit= ations of a slide).

So I chose short examples.

Feel free to look at longer examples if you want.=

 

My samples of IETF use cases are in the attached = file.

The usability.gov approach (http://www.usability.gov/how-to-and-tools= /methods/use-cases.html)

 

Elements of a Use Case

 

Depending on how in depth and complex you want or= need to get, use cases describe a combination of the following elements:

•Actor – anyone or anything that perf= orms a behavior (who is using the system)

•Stakeholder – someone or something w= ith vested interests in the behavior of the system under discussion (SUD)

•Primary Actor – stakeholder who init= iates an interaction with the system to achieve a goal

•Preconditions – what must be true or= happen before and after the use case runs.

•Triggers – this is the event that ca= uses the use case to be initiated.

•Main success scenarios [Basic Flow] –= ; use case in which nothing goes wrong.

•Alternative paths [Alternative Flow] ̵= 1; these paths are a variation on the main theme. These exceptions are what= happen when things go wrong at the system level.

 

How To Write a Use Case

 

Write the steps in a use case in an easy-to-understa= nd narrative. Kenworthy (1997) outlines the following steps:

1.     &= nbsp; Identify who is going to be using the website.=

2.     &= nbsp; Pick one of those users.

3.     &= nbsp; Define what that user wants to do on the site. Each= thing the use does on the site becomes a use case.

4.     &= nbsp; For each use case, decide on the normal course of e= vents when that user is using the site.

5.     &= nbsp; Describe the basic course in the description for th= e use case. Describe it in terms of what the user does and what the system = does in response that the user should be aware of.

6.     &= nbsp; When the basic course is described, consider altern= ate courses of events and add those to "extend" the use case.

7.     &= nbsp; Look for commonalities among the use cases. Extract= these and note them as common course use cases.

8.     &= nbsp; Repeat the steps 2 through 7 for all other users.

 

Middleweight Laundry Use Case

 

Use Case 1: Do laundry

Actor: Housekeeper

Basic Flow: On Wednesdays, the housekeeper report= s to the laundry room.  She sorts the laundry that is there.  The= n she washes each load.  She dries each load. She folds the items that= need folding.  She throws away any laundry item that is irrevocably shrunken, soiled or scorched.

Alternative Flow 1: If she notices that something= is wrinkled, she irons it and then hangs it on a hanger.

Alternative Flow 2: If she notices that something= is still dirty, she rewashes it.

Alternative Flow 3: If she notices that something= shrank, she throws it out.

 

Adam's example use case:

Use Case Name: Suspicious Endpoint Behavior<= /o:p>

 

Description:

This Use Case describes the collaboration between= specific participants in an information security system specific to detect= ing a connection attempt to a known-bad Internet host by a botnet zombie th= at has made its way onto an organization's Information Technology systems.  The primary human actor is the Secur= ity Operations Center Analyst, and the primary software actor is the config= uration assessment tool.  Note, however, the dependencies on other too= ls, such as asset management, intrusion detection, and messaging.

 

 

Actors:

 

   * Security Operations Center (SOC) A= nalyst,

   * Information Security Officer,=

   * System Owner

   * Organizational Unit Leader

 

Preconditions:

 

 

   * Organizational Security Policy Exi= sts

   * Security Policy specifies appropri= ate asset management capabilities (i.e. categorization of endpoints)

   * Security Policy specifies endpoint= configuration baseline for asset categorization

   * The Organization keeps a list of k= nown-bad Internet hosts

   * The Organization associates owners= who are individuals with endpoints

   * The Organization associates organi= zational units with endpoints

 

Postconditions:

 

   * Endpoint configuration has been as= sessed [1]

   * Results have been conveyed to scan= requester

 

Primary Path:

 

  1. At 03:46 UTC an organization's Network = Intrusion Detection System (NIDS) sees an IP packet with a destination IPv6= address existing on a blacklist of known botnet command and control (C2) s= ervers.

 

  2. The NIDS sends an alert to the SOC Anal= yst.

 

  3. The SOC Analyst uses the information ca= ptured in the alert (IP packet and reason for the flag) to look up the endp= oint in the organization's asset inventory system and discovers that the en= dpoint is a Windows Server 2008 R2 Member Server playing the role of a File Server

 

  4. The SOC Analyst also verifies that the = IPv6 address cited by the NIDS is, in fact, on the blacklist for known C2 s= ervers.

 

  5. At this point, the SOC Analyst switches= over to the organization's configuration assessment tool

 

  6. The SOC Analyst locates the offending e= ndpoint in the configuration assessment tool's endpoint catalog [2]

 

  7. The SOC Analyst then initiates an immed= iate and complete endpoint assessment to determine if the endpoint has expe= rienced any configuration drift [3].

 

  8. The configuration assessment tool:=

 

  9.

    a. Performs a preliminary= asset inventory scan on the offending endpoint, which results in a list of= installed software [4][5]

    b. Performs a comparison betwe= en the last known asset inventory and the present asset inventory and notes= any differences

    c. Searches it's local content= repository for appropriate configuration baselines for the operating syste= m of the offending endpoint and for each installed piece of software

    d. Upon aggregating the set of= applicable configuration baselines, the configuration assessment tool then= connects to and queries the organization's configuration content repositor= y for newer baselines that may exist.

    e. If a new baseline exists, t= hen it is returned by the configuration content repository.

 

  10. The configuration management tool, hav= ing the set of updated baselines, initiates a scan against the offending ho= st, which yields a result set.

 

  11. The configuration management tool disp= lays scan results to the SOC Analyst, which show that three new pieces of s= oftware have been installed on the offending endpoint where one piece of so= ftware is not on the authorized software list, and that several configuration items were out of compliance with the= organization's established baselines.

 

  12. The SOC Analyst reviews the informatio= n for accuracy and to plan next steps before sending the report to the resp= onsible Information Security Officer, accountable System Owner, and the Org= anizational Unit Leader.

 

 

A Note On Alternative Paths, Preconditions, and P= ostconditions:

There are likely to be many points of optimizatio= n and optional paths.  For example, a configuration assessment tool mi= ght provide a "quick glance" look at the most recent scan history= for the offending endpoint.  A SOC Analyst might then elect not to run a new scan (i.e. the offending endpoint is known to = be out of compliance, so why run a new scan?).  Another point might be= that the offending endpoint is, at present, not authorized to be on the ne= twork, in which case it is very likely not to exist in the configuration assessment tool's endpoint catalog.=

 

 

As with alternative paths, pre-/post-conditions c= an vary widely.  Consider that this description likely represents an o= rganization on the mature side of managing information security.  Many= organizations do not have a Security Operations Center, nor do they necessarily monitor their network.  It may be the= case that a log management process has detected the blacklisted connection= attempt  through audit trail monitoring.  Or, it may be the case= that a shared indicator of compromise has been used to detect the offending endpoint.

 

 

-------------------

[1] I am assuming at this point that "config= uration assessment" has been defined and will be understood by the rea= der.  What I consider to be "assessment" is that the baselin= e has been obtained, send to the scanning implementation, endpoint configuration item values have been harvested, endpoint configuration item= values have been compared against baseline, and results stored/forwarded a= s appropriate for the use case.

 

 

[2] An "endpoint catalog" is intended t= o convey nothing more than the notion that configuration assessment tools a= re likely to have some method of listing, enumerating, or aggregating endpo= ints under configuration management.

 

 

[3] It may not be necessary to specify what we me= an by "complete" or the order in which scanning operations take p= lace.  In this particular scenario, I thought it might be useful to il= lustrate that "scan levels" exist on a continuum. 

 

 

[4] Remember that the configuration assessment to= ol has knowledge of the offending endpoint so running a preliminary invento= ry scan is reasonable at this point.

 

 

[5] The mechanism of scan could be agent-based or= remote, so details of how a scan happens are omitted here.  A more gr= anular partition of the process is required for further details.=

 

This message and attachments may contain confiden= tial information.  If it appears that this message was sent to you by = mistake, any retention, dissemination, distribution or copying of this mess= age and attachments is strictly prohibited.  Please notify the sender immediately and permanently delete the message an= d any attachments.

 

My Comments:

Executive Summary:

The IETF format is what most IETF readers will expec= t. This format has the drawback of not being formal, and is not necessarily= very complete. If we to derive requirements from this freehand format, it = can be more difficult. But it is easily readable, so reviewers of our work can understand what we are trying to ac= complish. Use cases of this form help to identify the nature of the stakeho= lders involved in our WG. Operators vs vendors, service providers vs enterp= rises, managed-device implementers vs management application developers, and so on. This can help to categori= ze requirements that exist for some stakeholders but not all stakeholders.<= o:p>

 

I think the formal approach recommended in usability= .gov would be more work for the editors to lay out the use cases in this fo= rmal format, and the ASCII text required for RFCs makes this much harder th= an, say Word or HTML formats.

Usability.gov step 2 says “pick one of the use= rs” to document as the actor. Each thing the user wants to do becomes= a use case, and each possible alternative action becomes a use case.<= /o:p>

Adam’s example for Actor includes multiple rol= es, and then describes a rather complex use case , including footnotes.

 

Part of my concern is that we have WG contributors c= oming from multiple vendors, with possibly multiple products, representing = customers from multiple industry segments.

To fully detail each possible alternative would make= it close to impossible to actually finish this document in a reasonable am= ount of time.

I suspect Adam combined a number of use cases togeth= er in his example, to simplify things.

However, I cannot figure out how to create English s= entences from his example because he has multiple actors and multiple preco= nditions and multiple postconditions, and what seems to be a lot of irrelev= ant details in the Primary Path. Is the fact that this happens at 3:46 UTC an important detail in our design? = Or is it an irrelevant detail? Or is it important for some use cases (such = as trying to establish behavior anomalies based on when a user normally wor= ks, or when an attack normally happens?) but not others?

 

I think the formal approach is over the top for our = needs.

The IETF approach seems more appropriate at this poi= nt in our work process.

 

 

David Harrington

dbhar= rington@comcast.net

+1-603-828-1401

 

--_000_F1DFC16DCAA7D3468651A5A776D5796E1AACF8ACSN2PRD0510MB372_-- From inacio@cert.org Wed Jul 31 11:57:19 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8230D11E810B for ; Wed, 31 Jul 2013 11:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWD61HMpkdCL for ; Wed, 31 Jul 2013 11:57:15 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1220F11E80E9 for ; Wed, 31 Jul 2013 11:57:09 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r6VIv9WR029345 for ; Wed, 31 Jul 2013 14:57:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1375297029; bh=i42GprhP6vAocn9oVADUTvvHFdGaaSIEyDRP5LuP/Fo=; h=From:To:Subject:Date:Message-ID:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=TtVnQBcXvCt6wvIZ3519Rvu0OtXLp+qh03DIL5BjKjMUePWo4TJKE6RvVgJ+Xukvh lPEPyd+onzmzaaM3IfZCQNk8Q4vG06i9c204EBzAAk1ckAfVykN1Ns5Hqj8iPJzyup G5HqYCDBI/WGbXIREumxYZUfV03GNFMrVlwiebAA= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r6VIv9Wx031618 for ; Wed, 31 Jul 2013 14:57:09 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 14:57:08 -0400 From: Chris Inacio To: "sacm@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 comments Thread-Index: AQHOjh/BDH7WKqJPk0SCym8hNOZljw== Date: Wed, 31 Jul 2013 18:57:08 +0000 Message-ID: <4AE532C8B0B4B548AF47570D250D817414205186@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.100.125] Content-Type: text/plain; charset="Windows-1252" Content-ID: <654DFA4D88396F4B86FCBA615305D9FB@sei.cmu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 comments X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 18:57:19 -0000 I think the architecture draft would be helped TREMENDOUSLY by defining som= e terminology and using it to describe the intents of the architecture. By= having everything be defined as "DF #", it isn't very descriptive. It doe= sn't have to be named in any form that implies using any particular solutio= n (obviously, that would be bad) but by defining an architecture, you are e= ffectively splitting the problem into (hopefully) manageable components wit= h defined tasks. Maybe splitting terminology out of the use-case doc and into a separate doc= so that everything can use it (and for easier reference in the future.) Additionally, since we are the IETF, maybe we want to call the DF's protoco= ls - it's kind of our bread and butter. :) Second general comment, I understand the goal of the document/architecture = being such that an we could use a passive/active separate evaluator to crea= te information about a - but I think that's hard to discern from the= architecture. Second, from the architecture, it's hard to discern that th= e goal is to evaluate a . I'm using , the charter uses endpoin= t. Can we identify what that is - because I'm not so sure. Does that incl= ude a manageable network switch? A printer? A laptop? What if the printe= r runs Windows? RFC5209 (NEA requirements) defines endpoint as: Endpoint - Any computing device that can be connected to a network. Such devices normally are associated with a particular link layer address before joining the network and potentially an IP address once on the network. This includes: laptops, desktops, servers, cell phones, or any device that may have an IP address. Is that the intended scope for SACM? (It's copied into the use cases, and = references 5209 there, that way.) The Controller: The controller receives data collection tasks? From whom, where? In the LMAP working group, derived from the IPPM working group (mostly well= aligned to the broadband forum) the terminology in use is Instructions and= Reports. From that paragraph, I would be, I imagine the controller as an = intelligent MEDIATOR (stealing terminology from IPFIX) which can be inline = to sensors and understands the sensor & evaluator infrastructure such that = it can take complex tasks and allocate them appropriately - and then combin= e the results? Is that the intention? If I turn that into reality, then I might have something like: And passive asset/vulnerability device at the border, and IDS at the border= , a active scanner inside the appropriate network segment, some host based = agents able to send back configuration status, and the software configurati= on system. (Product wise, if it helps people, think: passive inventory:Te= nnable PVS, active scanner: Nmap/metasploit, host agents: McAfee ePolicy Or= chestrator/End Point Protection, software config management: Windows AD.) At some central console (no idea where / if that fits into the architecture= ) I send a task (n=E9e Instruction) to the Controller. The Controller, usi= ng something akin to a compiler, breaks the Instruction down into sub-Instr= uctions and sends those to the passive asset/vuln detector, active vuln sca= nner, host based config agent, and software config management system. Pres= umably, because this is about security, and we're not very trusting folks, = the Controller asks as MANY as possible the same question. Then the Controller receives the Reports, presumably it detects discrepanci= es. I'm nervous about what level of detail we dictate about the Controller, esp= ecially with respect to the Data Store. That's really an implementors choi= ce I think. Not that we don't acknowledge its existence, but I'm not sure = how detailed describing the iteration with data store should be. We need d= escribe the Controllers function, not how it gets it done. Can a Controller task another Controller? Or can a Controller pretend its = a sensor? Is there a trust system involved? Is the trust transitive? Content Repository: What are the security requirements for the Content Repository? Everything = accesses it, including potentially compromised endpoints. Is that really n= ecessary? It seems almost as if the glueing together of the system is via = the Content Repository.=20 I'm not really clear, what the Content Repository really is. Is it a big O= racle system (or Postgres, CouchDB, MonetDB, MongoDB, or =85 for anyone who= has their favorite DB system) with 3 extra protocols on top that aren't SQ= L? -- Chris Inacio inacio@cert.org From inacio@cert.org Wed Jul 31 12:22:58 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB95421F9935 for ; Wed, 31 Jul 2013 12:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTINrWVquy0n for ; Wed, 31 Jul 2013 12:22:54 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 401CE21F9F8F for ; Wed, 31 Jul 2013 12:22:23 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r6VJMNRJ030295 for ; Wed, 31 Jul 2013 15:22:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1375298543; bh=57C9SYnuZ3JxOa0SPyXm5S6JqN8UsXLuAJO9+K7l1mQ=; h=From:To:Subject:Date:Message-ID:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=ILOerS57vrQDf6JcVCfxODGLwMkvMIkGQJOUM3g7jIsKroXuB4FKfKygaLhz3ERTi 0jawrorazmYkmjodRkeS4WtWjIGUUwGBt0nJXMfwN9vzlahI1hIKuygtSpoFXu3tOK ElBtuhvWk3zhU9TxjsibMVojl0yzQ64hCqpScupU= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r6VJMMLa001984 for ; Wed, 31 Jul 2013 15:22:23 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 15:22:22 -0400 From: Chris Inacio To: "sacm@ietf.org" Thread-Topic: comments for draft-handt-sacm-alternate-architecture-01 Thread-Index: AQHOjiNH9f0+SbqN+EerSaMN8JnQMQ== Date: Wed, 31 Jul 2013 19:22:21 +0000 Message-ID: <4AE532C8B0B4B548AF47570D250D8174142053CB@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.100.125] Content-Type: text/plain; charset="Windows-1252" Content-ID: <31618DF0AE63B94D883E6A5216BFBAFF@sei.cmu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] comments for draft-handt-sacm-alternate-architecture-01 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 19:22:59 -0000 I really like the concreteness of the architecture, its easy to think about= . But I feel like this alternative isn't complete enough. From my comment= s in the review of the draft-waltermire-sacm-architecture-00 architecture, = I really feel like more than just BPD's (which I think is code for IDS/IPS)= should be considered to complete the situational awareness (SA) picture. I believe that we need to include passive asset devices, active vuln scan c= apability, and machine config management (Windows AD, Red Hat Satellite Ser= ver, Puppet, CFEngine, MDM systems, =85). I don't think that is covered in= your model. So after we've done all of this evaluation - what are the protocols used to= reconfigure the network to isolate a compromised / at risk machine? Is th= at all NETCONF? -- Chris Inacio inacio@cert.org From inacio@cert.org Wed Jul 31 15:09:33 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACF911E811B for ; Wed, 31 Jul 2013 15:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLxpOboq9eqm for ; Wed, 31 Jul 2013 15:09:29 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD2A11E80E6 for ; Wed, 31 Jul 2013 15:09:29 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r6VM9S3R002768 for ; Wed, 31 Jul 2013 18:09:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1375308568; bh=0TmtUJTo4dphq++RNPppqpkBQr4Jtu2BzwYU2nMb5us=; h=From:To:Subject:Date:Message-ID:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=mRE46OODGxQvJt4gHzBBHJmJwCKylTuQeOjVf1WdbYhzU8lmjOzua65G9qAUHHVur f53Xn5LwFrA0Sb1pS4Z6AoocFjOzPwxRt1h73LWi7BuVZErP8iCDO9HhEjeFg9mUI+ lcG6tZYQJf3b6RCMdNboulwSqezQhxakIVew1jeY= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r6VM9S4H018353 for ; Wed, 31 Jul 2013 18:09:28 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 18:09:28 -0400 From: Chris Inacio To: "sacm@ietf.org" Thread-Topic: comments on draft-waltermire-sacm-use-cases-05 Thread-Index: AQHOjjqfNIe9Y1K/g0uKHDeCZjagzw== Date: Wed, 31 Jul 2013 22:09:26 +0000 Message-ID: <4AE532C8B0B4B548AF47570D250D8174142067DC@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.100.125] Content-Type: text/plain; charset="us-ascii" Content-ID: <8FDC1597F204A84C984B61649822004F@sei.cmu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] comments on draft-waltermire-sacm-use-cases-05 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 22:09:33 -0000 At a minimum we need to caveat network scanning using PING to say that with= an IPv6 network, that isn't a practical method. Endpoint / Asset : we should either discuss or acknowledge virtual machines= (read virtual assets?) and how they should be handled here. The ability to assess non-software vulnerabilities (section 4.4) seems very= challenging. The rest of the draft had to many "todo"'s still to do more meaningful revi= ew. -- Chris Inacio inacio@cert.org From shanna@juniper.net Wed Jul 31 18:37:58 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5B721F8A64 for ; Wed, 31 Jul 2013 18:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.467 X-Spam-Level: X-Spam-Status: No, score=-100.467 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb-9c8+mOAoU for ; Wed, 31 Jul 2013 18:37:52 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 12A3B21F9C38 for ; Wed, 31 Jul 2013 18:37:50 -0700 (PDT) Received: from mail37-am1-R.bigfish.com (10.3.201.226) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Aug 2013 01:37:48 +0000 Received: from mail37-am1 (localhost [127.0.0.1]) by mail37-am1-R.bigfish.com (Postfix) with ESMTP id 39709E005F for ; Thu, 1 Aug 2013 01:37:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz9371I542I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail37-am1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=shanna@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail37-am1 (localhost.localdomain [127.0.0.1]) by mail37-am1 (MessageSwitch) id 1375321064823245_31307; Thu, 1 Aug 2013 01:37:44 +0000 (UTC) Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.249]) by mail37-am1.bigfish.com (Postfix) with ESMTP id BB06A1000E5 for ; Thu, 1 Aug 2013 01:37:44 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.52) by AM1EHSMHS020.bigfish.com (10.3.207.158) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 1 Aug 2013 01:37:44 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 31 Jul 2013 18:37:37 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Wed, 31 Jul 2013 18:37:37 -0700 Received: from DB8EHSOBE038.bigfish.com (213.199.154.187) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 31 Jul 2013 18:41:42 -0700 Received: from mail147-db8-R.bigfish.com (10.174.8.237) by DB8EHSOBE038.bigfish.com (10.174.4.101) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Aug 2013 01:37:35 +0000 Received: from mail147-db8 (localhost [127.0.0.1]) by mail147-db8-R.bigfish.com (Postfix) with ESMTP id 3D1AC38008C for ; Thu, 1 Aug 2013 01:37:35 +0000 (UTC) Received: from mail147-db8 (localhost.localdomain [127.0.0.1]) by mail147-db8 (MessageSwitch) id 1375321052926198_19388; Thu, 1 Aug 2013 01:37:32 +0000 (UTC) Received: from DB8EHSMHS008.bigfish.com (unknown [10.174.8.249]) by mail147-db8.bigfish.com (Postfix) with ESMTP id D3B1F100045; Thu, 1 Aug 2013 01:37:32 +0000 (UTC) Received: from SN2PRD0510HT005.namprd05.prod.outlook.com (157.56.234.117) by DB8EHSMHS008.bigfish.com (10.174.4.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 1 Aug 2013 01:37:32 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.38]) by SN2PRD0510HT005.namprd05.prod.outlook.com ([10.255.116.40]) with mapi id 14.16.0341.000; Thu, 1 Aug 2013 01:37:30 +0000 From: Stephen Hanna To: Chris Inacio , "sacm@ietf.org" Thread-Topic: comments on draft-waltermire-sacm-use-cases-05 Thread-Index: AQHOjjqfNIe9Y1K/g0uKHDeCZjagz5l/jivw Date: Thu, 1 Aug 2013 01:37:29 +0000 Message-ID: References: <4AE532C8B0B4B548AF47570D250D8174142067DC@marathon> In-Reply-To: <4AE532C8B0B4B548AF47570D250D8174142067DC@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CERT.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] comments on draft-waltermire-sacm-use-cases-05 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 01:37:58 -0000 Chris, I hope you won't mind if I piggyback with a few comments of my own on this document and on your very good comments. > Endpoint / Asset : we should either discuss or acknowledge virtual > machines (read virtual assets?) and how they should be handled here. I agree. Virtual machines were intended to be included in the RFC 5209 definition of endpoint. However, that's not entirely clear from the text of that definition. It was explained obliquely later in RFC 5209. I suggest that we append the following sentence to the second paragraph in the endpoint definition in draft-waltermire-use-cases: Virtual devices (e.g. VM images) are also considered to be endpoints. > At a minimum we need to caveat network scanning using PING > to say that with an IPv6 network, that isn't a practical method. In my view, the use case document should not spend much space talking about HOW the use cases can be met (e.g. doing asset discovery through ping or by monitoring MIBs) and instead focus on describing WHAT the use cases are, by which I mean "what problems we're trying to solve". We need to maintain our focus on defining the problem and should not stray into solving the problem yet. If you want to have side conversations on ways to solve the problem, that's fine and good. But those ideas should not end up in the use case document. I realize this may result in a rather short use case document. Don't worry. The charter calls for the use cases to eventually be combined with the requirements and architecture into a single document. This will make the document plenty long enough. And short is good. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Chris Inacio > Sent: Wednesday, July 31, 2013 6:09 PM > To: sacm@ietf.org > Subject: [sacm] comments on draft-waltermire-sacm-use-cases-05 >=20 >=20 >=20 > At a minimum we need to caveat network scanning using PING to say that > with an IPv6 network, that isn't a practical method. >=20 > Endpoint / Asset : we should either discuss or acknowledge virtual > machines (read virtual assets?) and how they should be handled here. >=20 > The ability to assess non-software vulnerabilities (section 4.4) seems > very challenging. >=20 > The rest of the draft had to many "todo"'s still to do more meaningful > review. >=20 >=20 > -- > Chris Inacio > inacio@cert.org >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From Adam.Montville@cisecurity.org Wed Jul 31 22:10:58 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F57621F9CAF for ; Wed, 31 Jul 2013 22:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBaKStRx9yuT for ; Wed, 31 Jul 2013 22:10:54 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.17]) by ietfa.amsl.com (Postfix) with ESMTP id BC14C21F9CAE for ; Wed, 31 Jul 2013 22:10:53 -0700 (PDT) Received: from [216.82.250.19:36575] by server-17.bemta-12.messagelabs.com id B7/97-24487-9DDE9F15; Thu, 01 Aug 2013 05:10:49 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-8.tower-87.messagelabs.com!1375333848!14596447!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 15063 invoked from network); 1 Aug 2013 05:10:49 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-8.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 1 Aug 2013 05:10:49 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 1 Aug 2013 01:10:46 -0400 From: Adam Montville To: Stephen Hanna , Chris Inacio , "sacm@ietf.org" Thread-Topic: comments on draft-waltermire-sacm-use-cases-05 Thread-Index: AQHOjjqfNIe9Y1K/g0uKHDeCZjagz5l/jivwgAA+0eA= Date: Thu, 1 Aug 2013 05:10:45 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D673B2CF@CISEXCHANGE1.msisac.org.local> References: <4AE532C8B0B4B548AF47570D250D8174142067DC@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] comments on draft-waltermire-sacm-use-cases-05 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 05:10:58 -0000 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Wednesday, July 31, 2013 6:38 PM > To: Chris Inacio; sacm@ietf.org > Subject: Re: [sacm] comments on draft-waltermire-sacm-use-cases-05 >=20 > Chris, >=20 > I hope you won't mind if I piggyback with a few comments of my own on th= is > document and on your very good comments. >=20 > > Endpoint / Asset : we should either discuss or acknowledge virtual > > machines (read virtual assets?) and how they should be handled here. >=20 > I agree. Virtual machines were intended to be included in the RFC 5209 > definition of endpoint. However, that's not entirely clear from the text= of > that definition. It was explained obliquely later in RFC 5209. I suggest= that we > append the following sentence to the second paragraph in the endpoint > definition in draft-waltermire-use-cases: >=20 > Virtual devices (e.g. VM images) are also considered to be endpoints. Is this really needed? To me, a VM can have an IP address, and that's cov= ered. I guess it doesn't matter either way, but if examples start becomin= g the spirit of the definition, then we're going to have a long list of th= ings as technologies evolve. Toasters? >=20 > > At a minimum we need to caveat network scanning using PING to say that= > > with an IPv6 network, that isn't a practical method. >=20 > In my view, the use case document should not spend much space talking > about HOW the use cases can be met (e.g. > doing asset discovery through ping or by monitoring MIBs) and instead fo= cus > on describing WHAT the use cases are, by which I mean "what problems > we're trying to solve". +1, a lot. =20 >=20 > We need to maintain our focus on defining the problem and should not str= ay > into solving the problem yet. If you want to have side conversations on = ways > to solve the problem, that's fine and good. But those ideas should not e= nd up > in the use case document. +1. A bit of context for those who are reading and saying, "but, we have = working examples today!" We do have working examples outside the context = of IETF, but we do not have proper use cases yet documented. I suspect, b= ut we will prove it out in this WG, that the requirements and architecture= derived from these use cases will largely match the technologies we have = available to us today, but that we will need to step from where we are to = a better solution over time. >=20 > I realize this may result in a rather short use case document. Don't wor= ry. The > charter calls for the use cases to eventually be combined with the > requirements and architecture into a single document. This will make the= > document plenty long enough. And short is good. I prefer "concise and representative is good." Whether it's short or long= doesn't matter as much to me, as long as we have a body of use cases that= represents the problems we want to solve and are concise in their descrip= tion. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Chris Inacio > > Sent: Wednesday, July 31, 2013 6:09 PM > > To: sacm@ietf.org > > Subject: [sacm] comments on draft-waltermire-sacm-use-cases-05 > > > > > > > > At a minimum we need to caveat network scanning using PING to say that= > > with an IPv6 network, that isn't a practical method. > > > > Endpoint / Asset : we should either discuss or acknowledge virtual > > machines (read virtual assets?) and how they should be handled here. > > > > The ability to assess non-software vulnerabilities (section 4.4) seems= > > very challenging. > > > > The rest of the draft had to many "todo"'s still to do more meaningful= > > review. > > > > > > -- > > Chris Inacio > > inacio@cert.org > > > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... This message and attachments may=20contain confidential information. If i= t appears that this message was sent to you by mistake, any retention, dis= semination, distribution or copying of this message and attachments is str= ictly prohibited. Please notify the sender immediately and permanently de= lete the message and any attachments.