From vbhatia@tnsi.com Thu Mar 1 14:58:31 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0738121E8218 for ; Thu, 1 Mar 2012 14:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.559, 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 DMkMjZX5e4-B for ; Thu, 1 Mar 2012 14:58:30 -0800 (PST) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED99521E8217 for ; Thu, 1 Mar 2012 14:58:29 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAEj+T0+sEQfn/2dsb2JhbABDtROBfQEBAQMBAQEBNzQLBQcEAgEIEQQBAQEeCQcnCxQJCAIEDgUIhgiBcRC5BASKBoMFEAEFBAYGAgYDAwIKAg0JAwkZhE0IPgQGMQEOCgYBGAGCTWMEiE+ffIE+ X-IronPort-AV: E=Sophos;i="4.73,513,1325462400"; d="scan'208";a="953586" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 01 Mar 2012 22:58:28 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 1 Mar 2012 17:58:28 -0500 From: "Bhatia, Vikas" To: "Hollenbeck, Scott" Date: Thu, 1 Mar 2012 17:58:26 -0500 Thread-Topic: [drinks] TLS Client CertificateRequest? Thread-Index: AQHM5nH2W6gwl4O9eEqyXBtiou8dHZYzSJ7QgB6RDRCAALdsIIADPnHQ Message-ID: References: <831693C2CDA2E849A7D7A712B24E257F0D595A08@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <3D35AFB9-D8E1-4AF7-B483-F6DE35FEE6F2@softarmor.com> <831693C2CDA2E849A7D7A712B24E257F0D598DB4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D5B50AB@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D5B50AB@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] TLS Client CertificateRequest? X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 22:58:31 -0000 Thanks Scott, The text looks good imo. I just have couple minor comments: > The TLS handshake protocol requires certificate-based server > authentication for all key exchange methods defined in RFC 5246 except > DH_anon. I would suggest to not have the above line in the text. The reason is that = this is well-established in RFC 5246 and would be redundant here. > increased if the server supports client-initiated renegotiation. This > risk can be mitigated by disabling client-initiated renegotiation on the > server and by ensuring that other means (such as firewall access control > lists) are used to restrict unauthenticated client access to servers. I am not sure if it is a requirement for all TLS servers to provide ability= to turn off client initiated renegotiation, so I will just do a little mod= ification as follows: "This risk can be mitigated by disabling client-initiated renegotiation on = the server and/or by ensuring that other means (such as firewall access control lists) are used to restrict unauthenticated client access to servers." Thanks, Vikas > -----Original Message----- > From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] > Sent: Tuesday, February 28, 2012 11:06 AM > To: Bhatia, Vikas; Dean Willis > Cc: drinks@ietf.org > Subject: RE: [drinks] TLS Client CertificateRequest? > > Proposed text for section 10.2: > > Sections 5 and 10.1 describe requirements for HTTPS support using TLS. > The TLS handshake protocol requires certificate-based server > authentication for all key exchange methods defined in RFC 5246 except > DH_anon. Non-anonymous TLS servers can optionally request a certificate > from a TLS client; that option is not a requirement for this protocol. > This presents a denial of service risk in which unauthenticated clients > can consume server CPU resources by creating TLS sessions. The risk is > increased if the server supports client-initiated renegotiation. This > risk can be mitigated by disabling client-initiated renegotiation on the > server and by ensuring that other means (such as firewall access control > lists) are used to restrict unauthenticated client access to servers. > > I'm open to wordsmithing. > > Scott > > > -----Original Message----- > > From: Bhatia, Vikas [mailto:vbhatia@tnsi.com] > > Sent: Tuesday, February 28, 2012 9:49 AM > > To: Hollenbeck, Scott; Dean Willis > > Cc: drinks@ietf.org > > Subject: RE: [drinks] TLS Client CertificateRequest? > > > > Hello Scott, > > > > Please provide the text that you would like to suggest pertaining to > > this aspect of Security Considerations. > > > > Thanks, > > Vikas > > > > > > > > > -----Original Message----- > > > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On > > Behalf > > > Of Hollenbeck, Scott > > > Sent: Wednesday, February 08, 2012 1:34 PM > > > To: Dean Willis > > > Cc: drinks@ietf.org > > > Subject: Re: [drinks] TLS Client CertificateRequest? > > > > > > > -----Original Message----- > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > Sent: Wednesday, February 08, 2012 9:57 AM > > > > To: Hollenbeck, Scott > > > > Cc: drinks@ietf.org > > > > Subject: Re: [drinks] TLS Client CertificateRequest? > > > > > > > > > > > > On Feb 1, 2012, at 12:29 PM, Hollenbeck, Scott wrote: > > > > > > > > > > Sections 5 and 10.1 of the protocol draft include text that > > > describes > > > > how these requirements will be met. I see MUSTs for HTTPS, but no > > > > mention of a need for the server to request a certificate from a > > > > client. Are servers required to send a TLS CertificateRequest > > message > > > > as part of the handshake protocol? The means is there, but it > > doesn't > > > > appear that the protocol includes a requirement for a server to > > > > authenticate a client at the TLS level. > > > > > > > > > > > > Nope. Basic or Digest authentication over HTTPS is considered good > > > > enough. There's no requirement for the client to have or present a > > > > cert. > > > > > > If that's the case, there's a risk of malicious clients consuming > > > server-side resources to the point of denying service to legitimate > > > clients. The risk should be identified in the security > considerations > > > section, perhaps as an additional paragraph in section 10.2. I'll > > > suggest text if it helps. > > > > > > Scott > > > _______________________________________________ > > > drinks mailing list > > > drinks@ietf.org > > > https://www.ietf.org/mailman/listinfo/drinks > > > > This e-mail message is for the sole use of the intended > recipient(s)and > > may > > contain confidential and privileged information of Transaction Network > > Services. > > Any unauthorised review, use, disclosure or distribution is > prohibited. > > If you > > are not the intended recipient, please contact the sender by reply e- > > mail and destroy all copies of the original message. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From mickaelmarrache@gmail.com Fri Mar 2 02:38:21 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636E421F8BA6 for ; Fri, 2 Mar 2012 02:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 xvwF3bHe7uDT for ; Fri, 2 Mar 2012 02:38:20 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8E721F8BA0 for ; Fri, 2 Mar 2012 02:38:19 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so979476wgb.13 for ; Fri, 02 Mar 2012 02:38:18 -0800 (PST) Received-SPF: pass (google.com: domain of mickaelmarrache@gmail.com designates 10.180.103.135 as permitted sender) client-ip=10.180.103.135; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mickaelmarrache@gmail.com designates 10.180.103.135 as permitted sender) smtp.mail=mickaelmarrache@gmail.com; dkim=pass header.i=mickaelmarrache@gmail.com Received: from mr.google.com ([10.180.103.135]) by 10.180.103.135 with SMTP id fw7mr3105282wib.2.1330684698353 (num_hops = 1); Fri, 02 Mar 2012 02:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=0ioU7Up6lGWnomsI/NbGZZlTxqCahe8CrLywryKrbic=; b=we0F6CBpIuHyemtTUU6C4nQnEL9jIc8dEynAPm0Io+Ec/OTsrV5vrcUj53uNlEqhWK XIp2mPrbtPgKQzJ0hdO62Yud/+j9LLN2coqIZ6ijDOop7A+FK0wwpfLz0q+CrW3LLC2K 0RbURbDePmVQzpgOpy10OqcdsEspLyOHJZWNCsrL/Tf4CK8+oMZbbfR6aps+8W+XsaRj afTDC3MeiRZMrOaNFJcyNJ3BCnDbBG3SVdFzet1886V0GTtU1voRrQJ6Meb69adsp+4l y20Iaa5wIjatKnTvJYZxMgeGrCgDs+8k3Y/O34O/Uebu2t5n5BaCBNnItTRCmmzSzRYL Cxkg== MIME-Version: 1.0 Received: by 10.180.103.135 with SMTP id fw7mr2475240wib.2.1330684698240; Fri, 02 Mar 2012 02:38:18 -0800 (PST) Received: by 10.216.71.10 with HTTP; Fri, 2 Mar 2012 02:38:16 -0800 (PST) Date: Fri, 2 Mar 2012 12:38:16 +0200 Message-ID: From: Mickael Marrache To: drinks@ietf.org Content-Type: multipart/mixed; boundary=f46d04430452bf26f704ba402cfe Subject: [drinks] SPPF changes proposal X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 10:38:21 -0000 --f46d04430452bf26f704ba402cfe Content-Type: multipart/alternative; boundary=f46d04430452bf26f204ba402cfc --f46d04430452bf26f204ba402cfc Content-Type: text/plain; charset=ISO-8859-1 Hi DRINKS, Following the conversation we had today, I would like to speak about the issue raised by David concerning the data model. Please, let's take a look at the figure present in the joined SPPF-user ENUM.jpg file. To meet the requirements deduced from the user ENUM use case, a direct association between the TN and route record types has been added. In this case, we have each TN associated to a route record directly. But, since peering is defined at the route group level, there is no easy possibility to share these direct associations. So, one solution is to include these route records in a dummy (since the included route records have not common routes) destination group DG-1. Then, we also create a dummy (since it doesn't contain any route) route group RG-1 and associate it to DG-1. Then, the route group may be offered to a peering organization. The aforementioned solution disturbs me in two points. First, since the destination group DG-1 and the route group RG-1 are not used for their primary reason (a destination group allows grouping of public identifiers that share a common set of routes, and a route group is generally used to group route records that may correspond to a same "destination" - that's why we share them as a block), it reveals a potential design issue. That's what I have qualified them as dummy before. That's the first impression I had when I heard this solution. The second point I want to raise concerns the complexity added by this solution. In this case, when an originating SSP wants to know the routes records associated to TN 1 for example, we directly see that there is a route record associated to it (RR 1). But, we don't know if this route record is accessible by the originating SSP. So, we need to get the enclosing destination group DG-1 and then the route group RG-1. We then check in its list of peering organizations if the originating SSP exists. Then, the route record RR 1 (obtained from the telephone number) is returned if the SSP is authorized. You will note that this processing is not the regular one described by SPPF. In general, we get the destination group associated to the queried public identifier, then the route group, and then the associated route records if authorized. Why do we need to use a different processing for the same kind of problem? After all, we just want to get the route records associated to the telephone number TN-1 in a user ENUM scenario (it's a banal scenario among many of them), as we want to get the route records associated to another public identifier in a regular scenario. That's what we have here: two symptoms that reveal a design issue. Now, let's take a look at the UML class diagram present in the joined ProposedModel-SPPF.jpg file. By using the abstraction defined by the abstract types PubIdentElement and RouteElement, it allows defining a many to many relationship between public identifier elements (i.e. single PI or destination group) and route elements (i.e. single route record or route group). This relationship is represented by the class-association RoutingAssoc. This association links zero or more public identifier elements to zero or more route elements. Also, to solve the scalability issue raised by Ken in the case one registrant organization has to offer a huge number of associations (previously route groups), we may use the same grouping concept for routing associations, represented by the AssocGroup type. Thus, we define a ShareableElement type that represents the basic entity that may be shared by a registrant organization. This model gives the possibility to define 4 combinations of associations: - Public identifier - Route record (solving user ENUM issue plus the possibility to link a single RN/TNP/TNR to a route record) - Public identifier - Route group (same as previous but with more than one route record) - Destination group - Route record - Destination group - Route group (regular scenario) I don't think it's a big amount of change. The point here is to introduce an abstraction, and to use an intermediary type between the public identifier element and the route element. This intermediary type should be used for peering. After all, the valuable information that is shared is an association between public identifiers and routes, thus using a dedicated type for this association should be the solution. Also, I still think the peering aspect of this protocol should be defined in a separated protocol that would support much more use cases than a simple offer/accept model. I think we should have two standards, each one focusing on a specific aspect of the problem, so we can decouple the two problems. Then, the users would have the choice to use the routing provisioning protocol or the peering protocol or both. Maybe I'm missing something here, so if you see any issue (e.g. concerning scalability) caused by this data model, please let me know. I would be happy to hear your comments on these propositions. Thanks Mickael --f46d04430452bf26f204ba402cfc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi DRINKS,

Following the conversation we had today,= I would like to speak about the issue raised by David concerning the data = model.

Please, let's take a look at the figure present in the jo= ined SPPF-user ENUM.jpg file.

To meet the requirements deduced from the user ENUM use case, a direct=20 association between the TN and route record types has been added. In=20 this case, we have each TN associated to a route record directly. But,=20 since peering is defined at the route group level, there is no easy=20 possibility to share these direct associations. So, one solution is to=20 include these route records in a dummy (since the included route records have not common routes) destination group DG-1. Then, we also create a=20 dummy (since it doesn't contain any route) route group RG-1 and=20 associate it to DG-1. Then, the route group may be offered to a peering=20 organization.

The aforementioned solution disturbs me in two points. First, since=20 the destination group DG-1 and the route group RG-1 are not used for=20 their primary reason (a destination group allows grouping of public=20 identifiers that share a common set of routes, and a route group is=20 generally used to group route records that may correspond to a same=20 "destination" - that's why we share them as a block), it reve= als a=20 potential design issue. That's what I have qualified them as dummy=20 before. That's the first impression I had when I heard this solution.= =20 The second point I want to raise concerns the complexity added by this=20 solution. In this case, when an originating SSP wants to know the routes records associated to TN 1 for example, we directly see that there is a route record associated to it (RR 1). But, we don't know if this route= =20 record is accessible by the originating SSP. So, we need to get the=20 enclosing destination group DG-1 and then the route group RG-1. We then=20 check in its list of peering organizations if the originating SSP=20 exists. Then, the route record RR 1 (obtained from the telephone number) is returned if the SSP is authorized. You will note that this=20 processing is not the regular one described by SPPF. In general, we get=20 the destination group associated to the queried public identifier, then=20 the route group, and then the associated route records if authorized.=20 Why do we need to use a different processing for the same kind of=20 problem? After all, we just want to get the route records associated to=20 the telephone number TN-1 in a user ENUM scenario (it's a banal scenari= o among many of them), as we want to get the route records associated to=20 another public identifier in a regular scenario. That's what we have=20 here: two symptoms that reveal a design issue.

Now, let's take a look at the UML class diagram present in the join= ed ProposedModel-SPPF.jpg file.

By using the abstraction defined by the abstract types PubIdentElement and RouteElement, it allows defining a many to many relationship between=20 public identifier elements (i.e. single PI or destination group) and=20 route elements (i.e. single route record or route group). This=20 relationship is represented by the class-association RoutingAssoc. This=20 association links zero or more public identifier elements to zero or=20 more route elements. Also, to solve the scalability issue raised by Ken=20 in the case one registrant organization has to offer a huge number of=20 associations (previously route groups), we may use the same grouping=20 concept for routing associations, represented by the AssocGroup type.=20 Thus, we define a ShareableElement type that represents the basic entity that may be shared by a registrant organization.

This model gives the possibility to define 4 combinations of associatio= ns:
  • Public identifier - Route record (solving user ENUM issue pl= us the possibility to link a single RN/TNP/TNR to a route record)
  • Public identifier - Route group (same as previous but with more than one ro= ute record)
  • Destination group - Route record
  • Destinatio= n group - Route group (regular scenario)

I don't think it&#= 39;s a big amount of change. The point here is to introduce an abstraction,= and to use an intermediary type between the public identifier element and = the route element. This intermediary type should be used for peering. After= all, the valuable information that is shared is an association between pub= lic identifiers and routes, thus using a dedicated type for this associatio= n should be the solution.

Also, I still think the peering aspect of this protocol should be de= fined in a separated protocol that would support much more use cases than a= simple offer/accept model. I think we should have two standards, each one = focusing on a specific aspect of the problem, so we can decouple the two pr= oblems. Then, the users would have the choice to use the routing provisioni= ng protocol or the peering protocol or both.

Maybe I'm missing something here, so if you see any issue (e.g. = concerning scalability) caused by this data model, please let me know. I wo= uld be happy to hear your comments on these propositions.

Thanks

Mickael

--f46d04430452bf26f204ba402cfc-- --f46d04430452bf26f704ba402cfe Content-Type: image/jpeg; name="SPPF-user ENUM.JPG" Content-Disposition: attachment; filename="SPPF-user ENUM.JPG" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzb2tljq0 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAFAAbIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK ztT1ux0po453d7mUExW0EZklkx1wi849T0HciodQv7me7bS9KZBdAAz3DruS2U9Mj+JyOi9up4wG saZpFrpayNFvluJiDPczNulmI6Fm9uwGAOgAFAGdv8T6n80S2mjW56CdPtNwR7hWCIfxej/hFUn5 1HWtZvWPX/TWt1+m2DYMfXPvmugooA5//hCtC6m3uS3ZzfTlx9G35H50f8IlbQ82Gp6zZP2KahJK B9EmLp/47XQUUAc/5XijTvmS6s9XhH/LOWL7POR7OpKE+2xR7jtb07X7S/uTZuk9nfhSxtLtNkmB 1K9VcD1QsPetWqmo6ZaarbCC7i3qrB0YEq8bDoyMOVYeoINAFuisS2u7rSbqKw1Sc3EMzbLW+ZQp Zu0cuOA/owADdMA43bdABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVma5qUmn2aJaos l/dOILSJujSEE5P+yoBZvZT3xWnXP2//ABMfG95M3MWl26W8Y9JZfnkP/fAhwf8AaagDT0rTY9K0 +O1jdpGHzSzP9+aQ8s7e5OT/APWq7RRQBU1S9/s3Sby+8vzPs0DzbN2N21ScZ7dK56y8YTpIy65p 9vYp/Zx1JJLa7a4URLjcHzGhVvmGOCDzzxW/rFnJqGiX9lEVWS4t5IkLnABZSBn25rl4fAFvbW8l haR2tpp1/pjWeow2y7A0uAFmQAYLcuCSAT8uc4xSV7v+u/8AwP61Hpp/XVf8E19N1TXr2W3muNBg trCfkE3+64jUglS8ewKO2QsjYz3rU1G5uLSyeW1s2u5hwsQkVB9WY9FHU4BOOgJ4rlE8N6tea3pN 5qenaEbjT5QTq0Lt9pmRVdQuwx/IDuyR5jAc9a3ZNLl022vJNISS5u7ggmPUNTnMfU52lvM2dTwq gHgemCWzsKO+pPoGqnXPD2n6qYPIN3bpN5W/ds3DOM4GfrgVo1g+DtP1PSPDFlpmqRWiTWcSQK1r O0qyKqgbjuRNp68c/Wt6rlbmdtgRDd2kF/aS2l1GJIJVKOh7g1l6DdzqZ9Hv5DJfWO3963WeE58u X6nBDf7St2xW1XP67/oOt6Jqy8DzzYzn1jm4X/yKsX/fRqQOgooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAK5/wAMfNdeIZT959Vfd/wGONB+iiugrn9E/wBF8S+IrFuDJPFfRj/YkiWP/wBD hf8AOgDoKKKKACiiigAooooAKKKKACuf8a8eF5nH3o57aVf95Z42H6gV0Fc/4t/f2mnacvL3uo26 AeqxuJn/APHIm/OgDoKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACsDXgdMv7TxCoPlWy tBegf8+7EEv/AMAYBv8AdL/jv0jKrqVYAqRggjgigABDAEEEHkEUtc/aP/wjUkWnXLf8StmEdlcM f9T6QufTsjd+FPOC3QUAFFFFABRRRQAUUUUAFc/Z/wDE58TSakObLTle0tj2kmJHmuPZdoQH18yp r+9m1C6k0nS5dki4F3dryLZT/CvYykdB/CDuPYNp2dnBp9lDZ2sYjghQJGg7ADAoAnooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKAI54IbmB4LiJJYZFKvHIoZWB6gg9RWH9i1XQv+QUP 7QsB/wAuVxNiWIekUjZyPRHxjswAAroKKAMa08U6VcTrazT/AGG+P/LnejyZT/ug8OPdSR71s1Bd 2drfwNBeW0NxC3WOaMOp/A8Vjf8ACG6TF/x4tfacOyWN7LFGPpGG2f8AjtAHQUVxWs6TfaVNp0y+ JNa+wSXK29yDLGSgk+VGDGPP+sKKcnoxPatX/hD9Pl/4/bvVL4d0uNQlKH6oGCn8QaALd/4k0jTp /s017G94fu2kGZZ2+ka5Y/XGB3qpjWtc+WWN9G089VEgN3KPTK5WIe4LN/umtWw0vT9Kg8nTrG2t Iv7lvEqD8gKt0AV7KxtdOtUtbOBIYU6Igxz3J9STySeSasUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUVmalrtlpkqW7mSe8kG6O0tkMkr j12joP8AabC+pql53iq/5htdP0mM9DdFrqX8UQqo/B2oA6Ciuf8A7C1mX5p/F2oo3dbW2tkT8nid v/HqP+Ecv1/1Xi7XE9fltXz/AN9QH9KAOgorn/sXim05g1ewv1H/ACzvLQxu3/bSNsD/AL9mlHiV rEhdf0+TSx0+07xLbH6ygDZ9XVaAN+ikBDAEEEHkEUtABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQBU1TTodX0q60+4z5VzE0bFeCuR1HoR1B9RVTw3qE2paHBJdgC9hLW92o7TRkq+PYkZHsRWt XPRf8SnxrNDyLbWIvPT0FxEArj6tHsP/AGzagDoaKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKydX1CeO4ttLsCov7wOyyMMrBGuN0hHfB ZQB3LDtmvN/H3xol8GeJ10+00+x1W0aIMXiu8Mj5wyNgEAjg49GFdT4N1O/1rXr/AFHVdKbS7ybT rNktGl8xo4i8+CTgYJIJIxxxmgDqNN0q10qJ1t1ZpJDummkbdJM395mPJP6DoMDinahqmn6Rbfad Svrayt9wXzbmZY1yegyxAzVuuV8brcvHoS2c0UNwdWi8uSaIyIp2v1UMpP5ik3t6r8WHf5mu/iPQ 49KTVX1nTl06RtqXbXSCJjkjAfOCcg9+xq3Y39nqdol3YXcF3bSZ2TQSCRGwcHDDg8givNZI7tY0 t1lgg1z/AISdGuXeFnh3mI7XWPcp2MgU43Z3bvmOM11HhBAkeuwX4jGoC/dr8AYicsi7XRT0RkCn BJ53ZJ6007pv+tk/1/roPRpf1u/8jorW/s75p1tLuC4NvIYphFIH8tx1VsHhh6HmpyAwIIBB4INc N4G1bQZ9e8SWWk6hpsifa42t4LSZCPKW3hXKKp+6CMccDGK7qm1sHU52WNfCjJNbgjRZJFSWDPFo WIAdPSPJAZei/eGMEHoqzPEiwN4X1dbr/j3NlMJf93Yc/pU+kNO+i2DXX/HwbeMy/wC9tGf1pAXK KKKACiiigAooooAKKKKACiiigAooooAKKKKACsTxTaTz6N9qs0L32nyLeWyr1dkzlB/voXT/AIHW 3RQBBZ3cF/Y295bOJILiNZY3H8SsMg/kanrnfDX/ABLrvUtAbIWzl8+1B728pLKB7K4kT6KPWuio AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAopHdY0Z3YKqjJYnA ArAfxdZ3EjQ6Lb3GszA4JslBhU/7UzERj3AYn2oA6CqOp6zpujRLJqN9BbBzhBI+Gc+ir1Y+wBNZ f2DxJqvN/qMWlW5HNvpo8yX6GZxj/vlAf9qr2meHdK0mVp7W0X7U4w91Kxlncf7UjksfpmgCj/be sangaNozxQn/AJe9UzAuPVYh+8P0YJ9aP+EWa/w3iDVLnU/W2X9xbfTy1OWHs7PXRUUAYl54R0G+ l0p5tMt8aVIZbSNECpGxGPujjHQ49QD2p+r2Vwt5baxYJ5l3ao0bwZA+0QtglATwGBAZSeMgjgMS NiigCrp+pWmqW32i0l3oCVYEFWRh1VlPKsO4ODVqsrUNAt725+2wTT2OoYC/arVtrMB0DqQVcD0Y HHbFVDP4o04fvbaw1aIf8tIHNtL/AN8NuU/Xev09ADoKytQ8SaXptz9kluDLeYz9kto2mmwehKIC QPc4HvWZZXN/4vtUuAtzpWkuPuh1Fxc+4dGISM9mU7m6gqMbt7T9MsdKtvs9haxW0WdxWNcbiepP qT3J5NAGT/bms3H/AB5+FrtR2e9uYYQfwVnYfioo+2+LjyNB0YL6NrEgb8hbEfrXQUUAcbrM3iPU IIrO78NM1g8ga6FlexyvIgIPl4k8sYYjDcn5cgDJ42LXxVpk1zHaXDzafeSHalvfRGFnPopb5X/4 CTW1UV1a297bSW13BFPBIMPFKgdWHoQeDQBLRXPmwuvDo87SzNc6cvMmnuxkeMesLE54/wCeZyD0 Xb0O3a3UF7axXVtKssEqh0dTkMD0NAEtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHO+If+JZ qula8MiOKT7Hd4/54zEAMf8AdkEZz2BauiqtqNjBqmm3VhcqWguYmikA67WGDj35rP8AC99Pe6HG l426/tHa0uzjGZYztLfRhhx7MKANmiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKiu bm3s7d7i6nighQZeSVwqqPcngUAS0Vzv/CVfb/l0DTbnVOwuP9RbfXzWHzD3QPR/Y2tanzrGstBC f+XTSswjHo0x/eH6rs+lAF7U/EWlaRIsN5eKLlxlLaIGSZ/92NQWP4CqP9oeI9U40/TYtLgPS51I 75MeohQ/+hOpHpWnpmi6bo8bpp1lDb7zmRkX5pD6s3Vj7kk1foA55fCNpcuJdbubjWZRztvGHkqf aFQE/Egn3rfRFjRURQqKMKqjAAp1FABRRRQAUUUUAFFU9S1bT9HtxPqN7BaxE4VpXC7j6D1PsOay f7e1TUvl0TRZvLP/AC96lm2jx6hCDI34qoPrQBd8ReIbDwto8mq6mZVs4mVZHjjL7NxwCQOcZIH4 1xl78S/C/izTDpOh6s811ezQW0iCCWMpFJMkch3FQB8rEA56kY5Ira1TwXP4j0q6tPEGtXNyJ4mQ QWo+z28ZI4O1SWbBwcOzDgcVl+GvhbZeGPBM+lWsiNq04SaS+Zes6MHj99iuo4789zQB6AiJFGsc ahEUBVVRgADoBTj0NUdJ1JdTs95jMNzGfLubdj80MmASp/PIPQggjgir1JgeW+DLq8l1HQneXWIJ biO4e4k1C+eeG+QZ4iQyOEYNtbkIdobAIzg8GXV5LqWgu8usQS3KXD3EmoXzzw3yDPESGRwjBtrc hDtDYBGcegRaBpcNtYW8drtj0+TzbX52zG2GBIOcnIZhg8HNEWgaZDb2EEdrtj0+TzbX52zG2GBI OcnIZhg8HNC0sD1v/X9epieN7YNZGSDUNRj1aZDBplva3jwgz8kMVUgOBwW37lCoeBznqog4hQSs GkCjcQOCe9ZOpeFtL1XU01G5F6l2kXkCW21Ce3OzOdv7t1HXn8vStaGJYII4kLlUUKC7l2IHqxJJ PuTmmtge/wDX9f15j65/w9/o2q6/pyf6iC8E0KjogljV2X/v4ZG/4EK2b29t9PtJLq6k8uFBycEk knAAA5JJIAA5JIArO8PWVxBBd317H5V5qNwbmWIkHyhtVETjjIREzjjdu9aANiiiigAooooAKKKK ACiiigAooooAKKKKACiiigArnf8AkE+N8dLbWovwFzEv82i/9E10VY3iixnvdDkeyXdf2jrd2g9Z YzuC/RhlD7MaANmiq2nX8Gqaba6hatut7mJZoz6qwyP51ZoAKKydQ8QWtldGyhSW+1HAIs7VQzgH oXJIWMe7ED0zVX+zda1b5tU1BrC3P/Lnpr4bHo85Ab/vgJj1PWgC9qXiDStJkWG9vY0uHGUt1y8z j/ZjXLN+Aqj/AG5q97/yC/D02w9JtSmFqp+igPJ+DItaWm6Pp2kRsmn2cVvvOXZF+aQ+rN1Y+5JN XqAOf+weJ7v/AI+dbtLFD/BYWe5x/wADlLA/98Cj/hFml/4/PEOuXPr/AKUIM/8AflUroKxrvxXo tpcNbfbPtF0n3rezje5lX6pGGI/EUAQf8IZo5++2qSH1l1e7cj8WkNH/AAhWhD7tvcoe5S+nUt7k h+T9aP8AhJbyTm18K65OnZyLeH/x2WVW/Sj+39XT/WeD9Wb/AK5XFo2PrmYfpmgA/wCEO05OYbvW YT22axdED6KZCv6Uf8I9qMPNp4q1ZMdEnSCZfxzHu/8AHqP+Ew0+H/kIWupad6vd2UgjX6yKCg/F q2bS9tdQt1uLK5huYG+7LDIHU/QjigDGz4ts+o0jVFHcGSzfH0/eAn8vwo/4SuG141jTr/SiOsk8 XmQ/XzYyyqP94rWtqGp2OlWxudQvILWEHG+aQIM+gz1PtWP/AMJDf6j8uhaNPMh/5e7/ADawj3AI MjfgmD/eoA3LS8tr+2S5s7iG4gcZSWFw6sPYjg1mX/ijSrG5NmJnur4f8udnGZpR/vKudo92wPes KT4e/wBozT3eo6vcW93cDEg0dRZxn/eHzGQ/75I9hV2wjvfCVqLU6XBc6YvIn0u3Ecie7wD73+8m Sf7goAn83xRqv+qhttDtz/FPi4uSP91T5aH33P8ASpbbwlpiXCXV952q3iHcs+oP5pQ+qLgIn/AF FalhqFnqlqt1Y3MdxCSRvjbOCOoPoR3B5FWaACiiigAooooAKKKzdT1/StHZEvrxI5pP9XAoLyyf 7sags34A0AaVISFBJIAHJJrnv7T8Q6pxpmlJp0B/5etUOW+qwIcn/gTIfalHhK3uyJNdvLnWX/55 XJC24+kK4Q/8CDH3oAWXxfYSyvBpEVxrNwpwVsFDxqfRpSRGv0LZ9qabTxNquftd9Bo9uf8AljYj zpyPeVxtH0CE+jVvxRRwRLFFGscaDCogwAPQCn0AZOneGtJ0u4N1Da+ZesMNd3Dmadv+2jktj2Bx 7VrUUUAFFFFAGXqOjLd3C3tpO1lqSLtW5jGdy9dsi9HXk8HkZOCDzVP+2tV035NX0eaVB/y96Ypn Qj1MX+sU+wD/AFroKKAMJPGnhl9wbXLGF1G5o7iYQuB7q+CPypn9q6zqv/IH09LW3PS81JWXcPVI QQ5H+8U/Gm6dGniW4XWLpFksoZW/s6FhlSFOPPPqTglfRcEck10VAHP/APCN3dzzqXiLVJ89Y7d1 tYx9PLAcfi5PvR/wheiH/WR3s3vNqNxJn3+aQ8+9SXvi/RdO1CWyup7hJICgmcWczRRb8bd8oQoo 5HJYY70Xvi/RdP1CWyuZ7hJISgmkWzmaKLfjbvlCFFHI5LDHegCtL4E0WR4pFbUo5oW3xSLqVwfL bBG4BnK5wSMkd6l/srX7D5rDXvtij/ljqkCt+AkjCkfVg9amo6na6VbCe6MpVmCKsMDzO5POFRAW bgE8DgAnoKdp2o2mrWEN9YzCW3mGUfaVPoQQcEEHIIIyCMGgChZ6/m6jsdVs5NNvZDtjDsHhmPpH IOCf9khW77cVs1BeWdtf2slrdwRzwSDDRyLkGsvSbma01KbQryVpWiiE1pPIctNDnBDHuyHAJ7hk J5JoA26KKKACiiigAooooAKKKKACiiigAooooAKragb1dPuDpyQPehCYVnJCFuwYjnFWagvLy30+ 0kurqURwxjLMefYAAckk4AA5JOBQB4V8MvEHin/hZV/pPiWdtOs9Otbm6exJEUMO6QEn3UeYSCSQ BjBxXrnn6j4h/wCPN5NO0s/8vJXFxcD/AKZgj92p/vEbj2A4ao4dDj1rVotc1exSN4k2Wtsyjcqb gwMpH3myAQvKqRnluR0lAFXT9NtNLtRb2UCxR5LNySzserMx5Zj3JJJq1RRQAVV1C/g02za5uGO0 EKqqMs7HgKo7sTwBVqufP/Ew8cmOTmHSrRJo17GaYyKW+qpGQP8Aro34AB/ZF7rf73XJXhtz93Tb aYqgH/TV1wZD6qCE7YbrWzaWdrYW629nbQ20CfdihQIo+gHFT1z/AIzN9B4Y1DUNP1W6sJ7K1muF 8hImEhVCQGEiNxkdsH3pSdlccVzOyOgorz7VL3xJpA0MWOq3WpSTJLd3EVxDBunREQmJdiIBkFiD 13YySOK3/DmuNrWq6s0VwJrBBbva4UDCvEGPOMnJPem9G12/r+vQlO6T7nRVi33hexuZpLqzaXTL 9xzd2JEbsf8AbGNsn0cH2xVTSrvVB411XT76/W5gSzguIo0gWNYizyrgdWPCLnLHnJGAcDpaBvR2 OR0HSrPS9VSDVbWOXWSpMGpTO0zXKjrsZyTGw6mMHGORkA466sbxTavc+HbuSE7bu1X7Vav/AHZY /mX8CRg+oJHetKxukvrC2u4xhJ4llUezAH+tAE9FFFAGRf6Ek901/YTtYakQAZ41ysoHQSpkBx+T DswosdYk+1rp2qwra6gQfL2nMVyB1MbHqcdVPzD3GGOvVa+sLXUrRra7hEsTEHGSCpHIYEcqQeQR yD0oAs0VyD+LrTw9qB0XU7w3txwLY2y+bPJk4VJEX7r+jHCt14ORV3zvE+q/6m2t9Etj/HckXFwR /uKdin3LP9KAN6e4htYHnuJo4YUGXkkYKqj1JPSsH/hK0vsroGn3OrHtOg8q2+vmtww/3A/0qSDw jpvnpc6iZtWu0OVm1B/M2n1WPAjQ/wC6oreoA53+yNc1TnVtY+yQn/l00rMfHo0zfOfqojrS0zQ9 L0ZXGn2UUDScySAZkkPq7n5mPuSa0KKACiiigAooooAKKKiubq3srd7i6niggjGXklcKqj1JPAoA lornf+EqN/8ALoGmXOqZ6XB/cW3181x8w90V6P7F1rVOdZ1loISObTSswr9GmP7w/Vdn0oAt6zr+ m6Yptp9QEV7Kh8mGFDNOTjgrEoLNg+2K8c8GeO/ih4n8T3GheTYILRmS9uLi0Zfs+Mjsw+YkcD19 ga9r0zRdM0aNk06xht95y7IvzSH1ZurH3JJqxb2VraSXElvbxxPcSebMyKAZHwBuPqcAflQBleDW jbwToflpsVLGFCh6oVQKVPuCCD7ityufcSeGrqe4jhkm0i5kaaZYl3NayMcs4UcsjHJOMkMScEE7 du3uYLy3juLaaOaCQbkkjYMrD1BHWgDz7XdD1W6v/Fd1CbyS2b7Ox07yl8rUI1jG9A23fkgFRtYD OMg8im6zo2p3114ovbcXzWjrbudNMCrHfxiMb48lQ4YjK/KwweCDyK9IqjqOs6bpEavqN/b2oY4X zZApY+ijqT7CklYCprt6IdIjdZdVtVmZQJtPsvPmiGM8xmNzg4wfkOM9uoreCLe4tfC8MNxbNARN M0fmIUkkQyMVkkViSruDuYHGCTwOgd/wlkU3/Hjo2tXg9VsWhB+hm2Aj3HFH/CQat1Hg7Wdo6gz2 e78B5+P1FPuHY6Cufvv3njvRlj+/DZXTykdkZoQAfqwyP9w+lRXPi6WztpJbnwx4gRlUkRx2yTsx 9B5TuP6Unhe+0++uLu6/tG2uNXudpuIUYhoEXOyPYwDgLk8kDJZjgZwADpqKKKACiiigAooooAKK KKACiiigAooooAbLLHDE8srqkaKWZ2OAoHUk+lYlhFJrl3Fq90jJZx/NYW7jB5H+ucdmIPyg/dB5 5JCsvv8Aifaw2kDnT7Mq9+e0rkbkh+mMO3sVHIY10FABRRRQAUUUUAFc/e/8SnxVDqj8Wl/AllcO ekTozNET6AmSRSfUoO9dBUc8EVzBJBPGksMilHRxkMp4II7igCSqmqafFq2k3mnTs6w3cDwO0ZAY KylSRkEZwfSsrydY0L5bNH1bTh0geUC5hHorNxIPQMVI/vN2lt/FuiTzC3lvBZ3R6W98ht5D9FkA LfUZFJq6sxptO6LTaNbNfabdl5fM0+N44hkYYMADu4/2R0xVbQfC+n+HLnU5rAzAahP57xOwKRtj ogxwvU4561Jf60Y7gWOmW/27UGUPsD7Y4lPRpHwdoPYAFj2BGSKv/CPXWo/PrmrXE+f+XWydrWAe 3yne3vubB/ujpT63FbSxUk0+w0PxHLrmoeLriGSdBG8F3JaxxNGpYqv+rDYUued2fUmrf/CdeEeo 8UaMV7sL6MqPqc4FXbHw3oemEmx0ewt2PJaK3RWJ9SQMk+5rToDrc5PWvEel61pL6VomrWN5eakD bR/ZrhJPLVuHkO0nhVyfc4HU11EEKW9vHBEMRxqEUegAwKq32iaTqildQ0yyuweouLdJP5g1m/8A CLJZfPoeoXemMOkQkM1v9DE5IA/3Ch96AOgqrf6lY6VbG51C8gtIAceZPIEXPpk965ee78SSapHp up3tvpEEuEivLKHzPtDf3Q8mVib/AGWVs5+Vjg1tWHhjStPuReCBrm+H/L5duZpvwZslR7Lge1AF X/hIr7Ufl0LRp50PAu77NrB9QGBkb8Ewf71H/CO32o/NruszzoetpY5tYPoSpMjfi+D/AHa6KigD Pj0LSYNKfTINOtobGQENDFGEU+/GOe+eueaq6bdz2V6NG1GUyS7S9pct/wAvMY6hv+mi5GfUfMO4 Xaqhq+mLqll5SyGG4jYS286jJhlH3WHr6EdwSDwaAL9FZ2i6m2p2JeaMQ3cLmC6hBz5cq9QD3ByG B7qwPetGgAooooAKKqahqdhpNqbnUbyC1hHG+aQKCfQZ6n2rI/4SHUNSyuhaNPKh6Xd/m1h+oBBk b8EAP96gDoqxr/xTpVjdNZiZ7u/XrZ2cZmlH+8q52j3bA96rf8I3ealzr2sXFyh62lnm1g+h2kyN /wACcg+lbNjp1lpdsttYWkFrAvSOCMIv5CgDG8zxRqv+qhttDtj/ABTYuLk/8BU+Wh/4E/0qW28J aZHcJdXwm1S8TlbjUH80qfVF4RP+AKtbtFABRRRQAUUUUAFYlx4ZtjcSXem3FxpV3Id0klmVCyn1 eNgUY++N3uKuavrWm6DZi81W8itLYuI/NlOFDHoCe1c5rHi7RdY0tdP0TXrG5ub+eK1ItbpGkjjk cK7AA5BCbyD64oAksJfEuryz266naDTY2Kf2lb2pSaUjqI1ZmXjoXxjIOF7jc07QNN0uRpre2Bun GJLqYmSaT/ekbLH6ZwO1XoIYra3jggjWOKJQiIowFUDAA/CpD0oAKK828IeItV1LUdJVtYvryS4S Z722vbNII441yA8DCJDJhtinDOMMc44o8IeItV1LUtJVtYvryS5SZ722vbNII441yA8DCJDJhtin DOMMc44oWtgelz0mqOpaNp2roq39nFOU5jdlw8Z9VYcqfcEGub8Ya/qVpdW1vpFwsIt7m1+3SGMM SssyosQyCMkFmJ6gBf72a7Khaq4PQ54/2j4cG955tS0lfvmX5ri2HrkD96g75+YYJy/Qb8ciTRJL E6vG4DK6nIYHoQe4p1c/4c/0O/1jRl/1FpcLLbj+7HKu/b9A/mAegwO1AHQUUUUAFFFFABRRRQAU UUUAFZ+t6mNI0i4vRH5siALDEDgyysQqIP8AeYgfjWhXP33/ABM/GFjYHmDTovt8w9ZGLRwg+3Er fVVPagDQ0TTDpWmR27yedcMTLczYx5srHLt9Mngdhgdq0KKKACiiigAooooAKKKKACsfxRcx2vh6 5le1hunO2KGGZQyPK7BIwQe25lrYrD8XQyyeHZJoUaR7SeC92KMlhDKkjADuSEIA9cUAWPD+hWXh 3SY7CyijRQS8rpGE82Q/ecgcZJ7DgDAHAFaMpkETmJVeQKdiu20E9gTg4Hvg/SiGaK5gjnhdZIpF Do6nIZSMgin0AcdB4r13z9ZF3oenRw6QCblotTeRmPkiUbAYFzwQOSMc9e8uneNkv9M024NiYbq5 vlsri2MwJt3ZS2c4+YFdrDgZDA8dKnfw9dt/wlmJIP8AicAfZ/mPy/6Osfz8ccqemePyrOvPBt82 s+H7+zubeNbUwjUonJxN5SkIycfeG5hzjII9BSV76/3f+COW2nn+Wn4nSatdarbLGNK023vHIZna 5u/s6IBjjIRyWOePlxwckcAv0PVY9c0Kx1WKJ4ku4FmEb9V3DODWb4rs9d1G3gtNJWza0kJ+2rNd vbvInGEV1jfAPIY4zjoQTka+nLPHp0CXFrbWsiLt8i2kMkaAcAKxVcjGP4RTWzE+hJd2kF9aSWt1 EssMg2uh7/4H37Vl+HLueSG80+7laW6025Ns8rdZV2q8bH3KOuf9oNW1XP8Ahv8A0q+1zVF/1F3e 7IG/vJFGsZb8XWTB7jBoA6CiiigAoorP1PXNM0ZUOoXsUDSHEcZOZJD6Ig+Zj7AGgDPv/wDiTeI7 XUl4tdQZbO7HZZP+WMn4nMZ9dyf3a6CuS1SbVvFWl3Gn2GkvZWs6bftupExsp7PHEMvuBwRv2YIq HQtGTxLotvfeIru51GVwVms5GCW0cqMUdPKTAcBlYfPuoA1Z/F2nee9tpqz6vdodrQ6egkCH0aQk RofZmBqPyPE+q/6+6t9Ftz/yztQLi4I95HGxT7BW9mregghtoUhgiSKJBhUjUKqj0AHSpKAMjT/D Gladc/a0tzcX2MG8u3M034O5JUewwPateiigAooooAKKKKACisnUfEulabcfZZbky3pGRaWyNNMf fYgJA9zge9U/tPibVf8Aj1s7fRrc/wDLW9InnI9o0O1fqXPutAG/LNHBE8s0iRxoMs7sAFHqSelY P/CWw3p2aDZXOsN086ABLcfWZsKR/ubj7U6Lwjp7zJcao8+sXKHcsmoOHVT6rGAI1PuFB963wABg DAoA4fxN4T1zxj4bvtP1bUba1SaI+XZ2UYZfMHKb5ZBlgGAPyqnSsPwp8J4/CXg92hWK48Sloroz fwl4nEiwqeyErtJ75z2AHqlFAFXT7+DU7GK7tydjj7rDDIw4KsOzA5BHYirVY97pNzFdyajo86QX cmDNBLkwXOBgFgOVbAA3rzgDIYAAV/8AhK7ey+TXbW40mQdZJlL259xMo2Af720+1AEtt4WsbW20 iGKW4B0qRngk3DcdwZWVuMEEMeMDoPSi28LWNpbaRDFLcA6VIzwSbhuO4MGVuMEEMeMDoPStS0vb S/iEtndQ3EZ6PDIHH5ip6AOe13wP4c8ROZdQ0ize5aSORrn7NGZW2MCFLFSSpC7SPTIrfREijWON VRFAVVUYAA6ACmzTw20RlnlSKMdXdgoH4msRvF+mTMYtKE2rz5wFsE8xM+hl4jX8WFHSwG3PPFbW 8k88ixwxqXd3OAqjkkn0rH8OQSyHUNXuI2ik1KfzEjcYZIVUJGCOxIXeR2LkdqSHTL7VJo7nXGjW ONg8Wn27lolYHIaRiAZGB5AwFB7EgGt2gAooooAKKKKACiiigAooooAK5/wz/pVxrWqNybm/khQ+ iQHyQPpuR2/4Ea3pHEcbyN0UEn8Kw/BSFfBWju/+sntUuJP9+QeY36saAN6iiigAooooAKKKKACi iigAooooAwGgu/Drs9jbtd6SxLNaRD97bE9TGP4k77Oo5254UaWm6vp+rxNJY3STbDtkQZDxn0dT hlPsQDV2szUvD2k6tKs15ZRvcIMJcJmOZB6LIpDL+BoA06z9T1zTdI8sXt0sckn+rhVS8sn+6igs 34A1zbabqT6udP0TxJqscNuR9sknMVwkWQCI1LoWMhBB5bCggkHIB6TTNEsNJ3taw/v5f9dcSEvL KfVnPJ/kO2KAM/8At3Vrr/kH+Grsofuy30yWyn8MtIPxQGjzfGD/APLlocP/AG+TS4/8hLmugooA 5LU18aXVusAstJFuzf6R9m1CRZnTuqExAKT0JznGcYOCLMHiKHS7eO31HRL/AEmCJQiN5IlgVRwP miLBB/vba6SigCvDfWlxZC9huoJLRl3idJAUK+u7pisY+Lba7JTQrS51l848y2AW3H1mbCH/AICW PtUOs+CNL1G5W/t7W2ivkfzcSRB4Jm9ZIujH/aGGGBz2rX0rUlv4ZI2h+z3Vu3l3FsTkxNjIwe6k YIPcHscgAGb/AGb4h1TnUtVTToD/AMu2ljLEejTuMn/gKofetDTNA0rR2d7GzSOaT/WTsS8sn+9I xLN+JNaVFABXP6H/AKJ4g1/TR9wTR30Y9FmUg/nJHIfxroK5+X9x8QrUjpeaVMG+sMse3/0e360A dBRRRQAUUVh3PizTIrl7SzM2p3qHDW+np5rKfR2+4n/A2WgDcqvfahZ6ZatdX93Ba26/elmkCKPx NYuzxRqv35LfQ7Y9osXNzj/eI8tD+En1qzZeFtLs7pb14nvL9el3euZpV/3S33B7KAPagCt/wkl1 qHy6Do9xdqel1dZtbf6gsC7D3VCD60f2BqWpc65rUzxnraadm2i+hYEyN/30AfSuiooAqadpWn6T b+Rp1lBaxE5Kwxhdx9Tjqfc81boooAKKKKACiiigAooooAxrvwn4evZTNPo1iZz/AMtlhVJP++xg /rUH/CFaD0FrOF/uLeTBD/wEPj9K6CigDDh8G+G4JRKNFspJR92SaISsv0LZI/CttVVFCqoVQMAA YAFLRQAUUUUAFFFFABRRRQAUUUUAFFFFAFHWXaPQ9QkX7y20hH1Cmo/DqLH4Z0mNfurZwgfQIKuX cX2iynh/56Rsn5jFZfg+Xz/BWhS920+An6+WuaANqiiigAooooAKKKKACiiigAooooAKR22IzYJw M4A5NLRQBg+C13eD9Mu3Iae+gW9ncHO6SUeYxz6ZbA9gBW9XP+H/APiTu3h6f5RCWawY9JbfOQo/ 2kztI64CnvXQUAcRrGjQyePdJg+26wkF7BdzTxRavdRoWQxbcBZAFA3NwuBzWHJrOpaQniK5uNQu XsLye8tIHkmJNnPGreXsP8IYDHXhlXHLGvSZdPtZtRttQki3XVsjxxPuI2q+3cMZwc7V6+lU7rwz o99pN9pVzZLLZX8jS3MTO3zsxyTnOQcgHgjHaocXay7Nfe/8irrT1/zGKsl34Qg3G9lke0jZhazC OaT5QSFckYLdM7geeoPNZ3geedrfVbW4ku1e2vmVLW9maae2jKqyo8hLbyclgQzABgMnFbtzpNnd 6WunSo4tlCKojleNl24KkOpDAjA5BzVbTLXRtFhkhs5Y0Mjl5XluTLJI3TLu7FmOAByTgADoK1bX M33M0rRS7GtXP3f+i+OtNkj4+22c8M4H8XllGjY/7u6Qf9tK39y7d24bcZznjFYOmg6xrza4B/oU EDW1i3/PUMytJKP9klIwp9FYjhgako36KKR3WNGd2CqoyWY4AFAC1z+pfL430Bh1NveIfofKP81F D+LrS5dotFtrnWZQcE2ajyVPvMxEfHcAk+1YN1Z69q/jfS4tQvYtNRbC6l8vTTvkUb4F2tK6/wAW TyqKRtPJzkAHYalrOm6PEsmo3sFsHOEWR8NIfRV6sfYAmsv+2tY1PjRtGeGI/wDL3qmYF+qxAeY3 0YJ9avaZ4e0rSZWntLRftLjD3MrGWZ/96RiWP4mtSgDnf+EWa/8Am1/VLnUs9bdf3Ft9PLU5Yezs 9blraW1jbJbWlvFbwIMJFEgRVHsBwKmooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACuf8AB/7nR57A8NY3tzb49EErNH/5DZK6Cuftv+Jf43vYDxFq dsl0nvLFiOT/AMcMP/fJoA6CiiigAoorkdRsV1fx41lc3eox20emLKsdrfzW43mVhuPluuTj1zSv ql/W1/0Do3/W9jrqK86sr+/1W8sPDt1qd21ust8HuoJfKmvFt5EVE3rgg/P8xUqTsPIBIrZ0LVrX T7PUlktPEEAtZ0WS3vC1/MhZQRtMbSuVIIPJOOelPS1+4a7HWUVyOtSTHxB4Wv4L/UEgu7zyzasW hTYYJWO6PCsSSFOHztK8Bec9dTsDCiiikAUUUUAVNR0211S28i7jLKGDoysVeNh0ZWHKsPUVleZ4 h0f5XhGuWg+68RSG6Uf7QYiN/qCn+6a6Cs/XNTOkaPPeJH5so2xwxk48yV2CRrntl2UZ96AMz/hM rKSf7FbWWoyaqV3Cwe0eJ8dNxZgEC/7W7HYZOAX/ANm69qfzajq39nxH/l10wAnHo0zrk/VVStDS dMGnW7GSTz7yYh7m4I5lfH6KOgHYcVdldo4ndY2lZVJCJjLH0GSBn6kCgDC/4Qjw7Jzd6auoH11G R7s/+RS1WB4S8NgADw9pIA6AWUf+FZ0HjUyz6hHL4d1i2XTgTdyStbFYv3fmAfLMScqR90Hrzjmr Nj4w06/0rTb+KK5VL+5FosboA8UnOQ4zxjaemexGQc0f8D8dgem4y48A+FLmGSL+wbKBJAQ/2RPs 5YH1Me0mnjQ9V04A6Rrczxr0tNSHnxkegk4kH1LNj0Pez4k8R2XhbR5NTvlmeNDhYoFDSSHBJCgk DgBieRgAmtWNxLEki5wyhhn3oA5Ntd8Q3eqDSPsVjo9yy5We6kadZsdfJVQofHuysOpXFXl8I2dw 4l1q4uNZlByBesDCp9oVAj47Egn3rW1Cwt9TtGtrlSUJBVlOGRhyGU9QwPINU9Av57u2uba9YNfW E5trhlGA5ADK+O25HRsDoSR2oA1URY0VEUKqjAUDAArAsf8ASvHOsXHVLW1t7RfZyXkf/wAdeKt5 3WNGd2CooJZicAD1rD8IIz6H/aMqlZdTme+YMMEK5/dg+4jEa/hQBvUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVh+KLeb+z4tStY2ku9 MlF3GiDLSKARIg9S0bOB77T2rcooAjt7iG7torm3kWSGVBJG6nIZSMgj6ipK5/Sf+JLq02iP8trM WuNOJ6BScyRfVWJYD+6wA+4a6CgArI1Lwzpuq3631x9sS5WLyfMtb+e3JTOcHy3XPJ71r0UWAyrj w1o9xpdvpxsUjtrZg1uICYWgYfxI6EMh5PIIJyfU1NpejWWjxypaLMTM++SSe4knkc4AGXkZmOAA AM8VfooAxtW8LaXrd7Dd3v24zQHMRh1G4hVDgjcFjdQGwxGcZwcVsAbVAGcAY5OaWigAooooAKKK KACsDxiCmhx3ZGY7K9trqb0ESTIzsf8AdXLf8BrfproksbRyKHRgVZWGQQeoNADgQRkHIornUnm8 LKILiOWbRU4iuVy72q9kkHUoOgcZwPvdCx3ba6t722S5tZ4p4JBlJYnDKw9QRwaAOXk0bUG/4TXF v/yEgPsnzr+8/wBGVPXj5gRzj8qy7jwtq1trXh+4sLZGtHlt5dUj3qphlijKiUc/NkHacZPyqfWv QaKSVnf0/Abd1Z+f4nGeOvDet61aXkul3tt/yDpraOzmti5d3HJV/NVVYgBQWBxz6mup06O5h022 ivJI5LlIwJGijKKTjspZsfmatUjusaM7sFRRlmY4AHqaa0VhPX+vT/IWuf8AD/7/AFrxFfJ/qJLx YY2HRzHEiufwfcn/AAClbV5ddJttBfNsfll1QYMaDuIs8SP7/dHckjadS3gs9H0xYo9kFpbRkks3 CqOSzE/iST7k0AZfigm9itdBjJ36m5SbHVbZcGY/QghM+sgreACqFUAADAA7Vh6BFJeT3OvXMbJJ eAJbRuMGK2X7gI7MxJc9/mAP3a3aACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigCjq2mLqlj5PmGGdGEtvOoy0Mg+6w/kR3BIPBNM 0jU2vopIbmMQahbEJdQA5Ck9GU90bkqfqDgggaNZmqabJcSxX1i6Q6jbgiN3ztkU9Y3x/CfXqCAR 3BANOiqOmanHqMcimN4LqE7bi2k+/E39QezDgjpV6gAooooAKKKKACiiigAooooAKKKKACsS58La fLcvdWjXGm3ch3PNYSmLe3qyco592U1t0UAc/wD2f4ot+LfX7K5X0vdPy3/fUboP/Hfyo/4rAd9D PviYV0FFAHP/AGPxXPxLrOmWy/8ATtp7s/8A308hH/jtOTwnaTOsmrXV3q8gOQL2QGIH/rioWPjs SpPvW9RQAgAVQqgAAYAHasC5/wCKj1D7EnOk2kn+lP2uJVPEQ9VU8v2yAvPzAS3d3Pq9xLpumSNH EjbLu9Q48v1jjPd+xP8AB9eK1bW1gsrWK1toligiUIiKOFAoAmooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDN1PSRe yR3VvO1pqEIxFcoM8f3XX+ND3U/UEHBENjrZ+1Jp2qxLZ6i2di7sx3GO8THr7qfmHpjBOxVe+sLX UrR7W9t454GxlHGRkdCPQjqCORQBYorn/K1vQ+LbdrGnr0hkkC3UY9FdjtkHsxU+rMav6brmn6qz x20+LmMfvbaVTHNF/vI2CPrjB7E0AaNFFFABRRRQAUUUUAFFFFABRRRQAUUdBk1hS+JY7mVrbQ7Z tVnU7WkicLbxH0eXkZHdV3MPSgDZuLiG0t5Li5mjhhjUs8kjBVUDqSTwBWH5954j+W0aax0k/euc FJrkekfdE/2/vH+HHDVJb6FLdXEd5rtwt7cRsGigRStvAR0KoSdzD+82T6BelblAEVrawWVrHbW0 SxQxrtRFGABUtFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVQ1LRdN1hUF/aRzNGcxycrJGfVHGGU+4Iq /RQBz/8AZmvab/yDNWS8gHS21RSzD2WZcMPqyufej/hI7uz41fQdQt8dZrRPtkR+nljzPzQV0FFA GRZ+KtBv5TDb6taGcDJgeQJKPqjYYflWvVe80+y1GIRX1pb3MYOdk8YcfkRWP/wg/hpP+PfSILP/ AK8i1t/6LK/5J9aAOgorn/8AhD9PX/V32uIe5/tq7f8A9CkNH/CI2v8A0FNc/wDBrP8A/FUAdBUU 9zBaxGW4mjhjHV5GCj8zWJ/whmkHiSTVZl/uT6xdyKf+AtKR+lSweDvDVtKJY9B07zh/y1a2Vn/7 6IJ/WgCM+NNDditldSak44xp0D3Qz6FowVH4kUn9oeI9Q4sdHh0+I9JtSmDP9RFETn8XU+1b4AVQ qgAAYAHaloA5/wD4Rdb479evptVP/Puw8q2Ht5S8MP8AfL1uxRRwRLFDGscaDCogwFHoAKfRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QB//2Q== --f46d04430452bf26f704ba402cfe Content-Type: image/jpeg; name="ProposedModel-SPPF.jpg" Content-Disposition: attachment; filename="ProposedModel-SPPF.jpg" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzb2tr081 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAJgAt0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+/iii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK/j4+HXjvxXJ+zr4E+MnxP8A2m/2sLNH +Cvhj4m/EPxRcftlftWaTptqreBrHxT4t1+ew0b4wWmm6bYwA6hqMlnpWn21jZwK0NjZwwRxQL/Y PX8VUHgjXviZ/wAE6Ifhx4Vit7jxP8QP2Ko/BHhuC8uY7K0m17xX8CxoOjxXV5L+6tLeTUL+3Se5 k/dwRM0r/Khr9N8Pklg+IakacalWnPK/ZJxUm26Wby5E/itOUIXSau4x6pW+D4yb+tZLB1JU6c1j 1Uak4pJVMtXO+l4KUmm07Xfdns3wq+LnhP44aTqWt/Cb9rr9pvxzYaLqCaVrf9i/txftdPe6HqU1 pBqFvY65pVx8abfVdGubzTrq11Oxi1OytXvtMurXUbMT2VzBPJ1PjbxHd/Dzwvq3jLxb+0R+2NYe HdEjt5dTvLP9r/8AbS124gjury2sIXTStA+LmqavdA3V3Asn2SwnMETPcz+XbQzTR/i9pP7Dv7UT /D/xn4Z8QeCvC/iDw/4/8bfCO41Pwx45+JOk+PfHlgngT4D+Mvhtq3iuPxXc6HpPhqHQG1+58BWf hPwxff8ACZ3fw/8ADek61rnhXSh4uTRZotHXv2K/2stQ8P8AiXTNP0rRr/XvGf7I3wq+FvjjxX45 8e6Pr2vT/EjwN4G+CmmSWnw08R2djbeJvDmg3/ibwp4qvvGGleLNR1vw/q2t2dz470W+g1jxhc2N p9ZHHYz2N5ZVN1eWesaVSMedOooP2Tg5KL5KTcfa81pNNxcUn848Jhva2WZJUuaGjqQcuX91zLnV RRurzSap2vCNlJNuP7FePPF1t8L/AApq/jn4iftTftQ+C/CGhRRS6r4h8Rftz/tZaZplp9ouIrOz gNxc/G9BNe6hfXFtp+l6fbiW+1TUrq107T7e5vbq3gk838H/ALRXw0+IDeEE8E/ti/tR+J5PHXjT xD8OvDsWkftn/tn3cz+OPCvhDWvH2veGdZgT4ueb4W1Ow8HeH9T1/wArxSmjLc2SWf2N7ibVdKiv fgDxN+xn8ar7UtT8Taf8OPB2ofEzwZ+1/pX7Tk3xI1f4u6sG/aR8MeF/i34v8V+CPhrf6DJoWo2f w9uvCPw58QaV4Y0CfUoLvQfDGteHLSx0SKbQ9X1LV7XF+JP7Fnxp+J/xK8SfH3xz8HvBni1PiB8d /CnjLX/2bD8Zr/QrS28BeAf2afHnwR0y+1b4i6RoVjY3fi7xH4g8TW/iG/0DT7K80RdL0zw7pOoa 7dhtUl0q6mLxilF08vjy81NShOjiG1Tcpe1qOrGkknTUIU3Rp0a03KftqUq1GmvaKGHw3LJTx0uZ Rm4yjVoxTmlT9nTVOVRtqd5VFVnVpRSpqlUVGpK8f0F+Kv7Ufwk+B13rNn8XP2yv2qPh++gSaDFq lz4k/bD/AG27LTIn8S2Grano622sf8LUfSdR8+x0PU5ro6be3Y0w26Q6obKe5tI5/Wfh/wCMIvip 4P0Xx98Pv2mv2s/E/g/xFFdTaLrtj+2l+2HFa6hFZX91pl1JCl58Zba5CxX9ldW5MkCbmhZk3Rsj t+J/w3/Zs+P3i74Lftxfs/Xd5rXjLx6n7O/7IvwPsPE3ip/EemeF9V+JHgHRPHOp+NPDmi+LPFtr AniKDwpYa/4bsbzxRaPc22tRXOlarNcGTUQqexftT/CTx34h/bA8VeH/AA82q33wj8UfAu//AGqP iVZb/Eb/AGT4s/BLwH8QPgx8NdI0O4tIYdGjXxnceMPAniafw8Lm9vr68+C9xfy2sEFxEbnOGPxP Iq88DT9lOUKUaSg41YVJ4nFUHz1uapCaorD0nVUKKaVdVE1GnadSwdDm9jDGTVSMXOVRzUoThGhh aqcadqcoOo61RU3Oq03RVO3NLmh+wH9neLv+i+fte/8Aia37XX/z7KP7O8Xf9F8/a9/8TW/a6/8A n2V+APwn/Yz/AGl/FHwW0DxJpnhHTfCXg/xnov7JHinxh8Eb/wCKlx4hufjRqHhD4e/E1fiX4/8A EF5418NXuiaRrHi7XvH/AMNdbvPAPi7S30/U/wDhWAs9dktrm00SBv24/Z78B6p8MPgh8Lvh/rV9 4l1DVfCngzRdIvpvGHiW18Y+JIZ4LZWbTtV8T2OnaVZazNpAcaVFeWWn29o1tZQpbebAkc0nbgsT PFNe0y+WGg6XtIzndxl7/LFR5qNJ2lBKa5lGaS1pqLhOXLiqEcOv3eNVeSmoOEWk4+4pNtxq1F7s vcfK5RbStNyUox/pC/Yf8TeIfGn7Fn7IPjHxdreqeJfFfiz9l74AeJvE/iPW7241LWtf8Q698KPC Wqa1rer6jdvLdX+qarqV1c31/e3MklxdXc8s8zvJIzH6hr5C/wCCfP8AyYR+xD/2aF+zV/6pnwXX 17X4TmsYxzTMoxSjGOPxkYxikoxisRUSSS0SS0SWiWiP1zLm5ZfgZSblKWDwrlJtttuhBttvVtvV t6thRRRXAdgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV/Fn+z3rX x8i+AfwPi0X4afCC/wBHi+EHw0j0m/1T44eM9I1O90xPBmirYXeo6Tafs963a6XfXNqIprvTrbWt Xt7K4eS2h1S/jiW7l/tMr+GbSLz9oK6/Z3/ZX8N/D3z/AAZ4b8QaR+zN4dvviH8Pbq28Z/EK18D6 v8PtM/4Tm91Xwf4s+E2s+EPA9np0imCz8WHXPFS2wSwv7m3057uWwh/UvDqvHD4PP5yofWP3+TJQ SqOV3DONuSpSS7XqTUFs2m1f8/41oyrYnJoRq+x/dZm3JuCVufLb354TbtvaEXJ66NJ2+rP7e/aO /wCiU/BL/wASA8d//Q0Uf29+0d/0Sn4Jf+JAeO//AKGivgPxl8Qf2wbj4heNfDnw/b476ZoCyano sWv+Ifh5puvXWn32g/tXfAP4f2Pijw+h/Zv8HfD2LSvEPwd1b4xeMdGstG8a/FxNV8BQQeKfFsXh LW9AnSb9UfD2lXOh6Fo+jXeu6x4nutK02z0+fxF4hOlnXdcltIEgfVNYOh6XomjtqV6UM942m6Rp tm07u0FnboRGv6Hh8wo4idSEMDGKpqN5z+sRhJyckox/2pyclyvnvFKN0rtuy+KrYOpQjCUsW5Op e0Yeyckkou8r4dJJ8y5dW3q7WPKv7e/aO/6JT8Ev/EgPHf8A9DRR/b37R3/RKfgl/wCJAeO//oaK 9torq9tT/wCgWh/4Fif/AJoOf2c/+f8AV+6h/wDKTxL+3v2jv+iU/BL/AMSA8d//AENFH9vftHf9 Ep+CX/iQHjv/AOhor22ij21P/oFof+BYn/5oD2c/+f8AV+6h/wDKTxL+3v2jv+iU/BL/AMSA8d// AENFH9vftHf9Ep+CX/iQHjv/AOhor22ij21P/oFof+BYn/5oD2c/+f8AV+6h/wDKT9xP+CfOP+GC f2IcZI/4ZC/ZrwSMEj/hTPgvGRk4Ptk49TX15XyF/wAE+f8Akwj9iH/s0L9mr/1TPguvr2v5wzb/ AJGuZ/8AYwxv/qTVP3DLf+RdgP8AsCwv/pimFFFFeedoUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAV/G38KPiV4C+FX7KX7Pvif4i+KtH8H6DJ8Ivg9pEGpa1ci2hutX1 DwJoo07SLJAHmvdW1OSJ4NM0y0imvtRuilpZQT3MsUT/ANklfxN/Cv4C+H/HfwU/ZW8VxanqWja1 oXh79mz4jak8t7retabrJ8A/D7SoNP0i30G912LQfD8lxHNHv1fStMS5WSJ5p4Lua5nkb9O8PnVW Cz90YwlU9vkySm2or93nGtlbmtp7vNC6v7yaSfwXGapvE5P7WUow9lmd3FJt+/lul3flv/Nyys7e 61dr3O6/aW+Atg+srqXxU8I6TH4ft7W81a71jUDpGn29lc+JNG8HNfR6nqUVrp95Zad4t8RaF4Z1 28srm5tvDuu6tYaVr0um3txHCaGn/tP/AAU1jxn8OPA2jeMrHVtX+Kdh8QLvwrLZtGLU3fw11fQN D8TaFq0VzLb6ppHiGLVNfWzt9KvdNjmNzpWsWt2bS7tre3u/A/En7Eeq+MPiJq/jvxP8adV1gT6n q1zoVre6F4g1DUdJ0fVP2kvg1+0PbeHbm91j4j6r4f8A7M8NR/BrR/hv4Xh8I+EfBEFt4YuodQ1y 28Q61p32q+9O8Pfsy3Hhb4q6b8VdI8dQtf2vj342+Jr7SdR8KPdWd34d+OEvw7utc0C0ntvE9hNY 61o138NNEfSvE0w1Gxe2vNUgvPCs0stpdWf3KqZk52dClGnz0lzXi5ODrR9q7e2suWjzJLVubUk3 bkfyThgVG6rVJTcKjtaSipKm/Zq7opu9W13orKzSvzL6uooor0ThCiiigAooooA/cP8A4J8/8mEf sQ/9mhfs1f8AqmfBdfXtfIX/AAT5/wCTCP2If+zQv2av/VM+C6+va/nfNv8Aka5n/wBjDG/+pNU/ a8t/5F2A/wCwLC/+mKYUUUV552hRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABX8PPhP43eJfAX7P8A+y54X8P+FpNF1Dxh4a/Z5+HWm/E7x/Z2k3wq0dvEvwqh8R3Wt3Fv pXivSvEOsmzttAuvDFhpFxP4Sh1PxtquhaQNet4LyO5m/uGr+P74A6JoviP9l74E6L4h0jS9e0a+ +CPwlW90nWtPtNU0y8WHwV4duYVurC+hntbgRXEMNxEJYnEc0UcqYkjVh+neH0Kk8Fn8adT2cnXy a0rJ3Xs84vHvHm25o+9HeOqPguM5Qjicnc4c8fZZnpe1nz5br2dv5ZXi9mfJ/iz4leLtIPxO+Iem /F2e4+I+i/Gv4C+CfAnw+8O+KLXVfhv8SNP8Z/DH9nHWta8IeF/Busrqb3mm+Lr7xn421bSfFWg/ ZPFOl2kh1ttcGlaXqcE3I69+2b8VPFI8U6X8OvEXw8tLfTPGH7HWv+H/AIgSeDdSsdHv/h38d/2n P+FQ67odxpOu+Mdb1HULRtO0+Fbjxrfab8PNUvNF1TxC2h+FfDOrWmgeJ4v0J8VRfCX4V28/xQ1v wvoWjXVj/wAI74aXxDoHgKbW/Fsra5qOj+CfDHh7SrXwloOqeLdUe/v7/RPDul6PpNpduyy2dpDb LbxAR1PAw+CfxE0DxPceDNA8HalpOq63eaV4/wBHm8G2+i6kPE9s0GqX+jfEXwjrejaZrmmeJoP7 Rs9WutI8Y6RaaykOpWWqSWoh1C1uJ/tJYau5ypwxsaUpxqydKMp+0fP7dU6i/eKStKouaUYL+BDl kmpJ/Kxr0VCM5YSU4wlSiqkox5E4Ojzwb5LSvGDspS/5fS5otNM8S+D/AO0T8SPib8Y/FnhWX4f2 dn8PNE8XfGDwSdWSfSrXV/D998I/GU3gq11vU57nxrcan4js/iJd6ff6tp+j2Pw+8OzeEdMu9Akm 1jxfYalLrFr9nVxei2fw9u/FPivWfD9j4Rm8a6Pd2nhHxrq+lWWknxNYXbaB4c8SWPhzxFqVrD/a ccn/AAjWreFNZttMv5+NJvtDvI4RbS2bntK78PCpCElUrOtJzm+d2SWtuVJJcqTTbjeXI24p8qjF claUJzThSVGKhFcqu29LqTberaaXMlHmSUmuZybKKKK3MQooooA/cP8A4J8/8mEfsQ/9mhfs1f8A qmfBdfXtfIX/AAT5/wCTCP2If+zQv2av/VM+C6+va/nfNv8Aka5n/wBjDG/+pNU/a8t/5F2A/wCw LC/+mKYUUUV552hRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABX8N3h 74Ba18Xf2f8A9lFbvxTL4m8G2el/sy+MPEPwx8aWfhFvAtv4X8K/D7TItestIj03wKPFGu3evtKs 17o/jTxRreg3hu762WPT9P8As1nF/cjX8Wf7Pfw08Z3/AMA/gff2n7Qnxf0S1vfhB8NLu20XS9F+ AcumaRb3PgzRZodL06XWvgfq+sS2NhG62lpJq2rapqb28UbX+o3t0ZbmX9S8OsPSxODz+nVqRhB1 8mb5nVtL3M491qlCfMmt4zXK/VK35/xtWqUMTk9SnBykqWZ2cVTvH38t1TqSjZ9pRfMu9m7+KQ/s beNvh/P4Xv8A4YaN4At00i0sZ/E2h2+v6poSeMr7wP8AtefCT4zfC+z1LVH8OahJdW/gz4R+FvGX gjwncalBdJ4Nj1Cy8JaHa2/hd1ktMH4//skfHb406b8V9SXQ/gtYa58ZTqZl0i+1Gx8R3Xw6vtB+ F+meBvhlrekeNPGHwe8SwRahcaodd1n4iap4V8F6F4x0q2h8F6H8PPF8Muhar4o1v7o/4VT47/6O X+Nv/gh/Zx/+h/o/4VT47/6OX+Nv/gh/Zx/+h/r7yWTYKVOVL61CNNxiuSPt4qLjGUFKLWEupOE6 ikr8sueUnHntJfIRzTFRmqnsJSmnJ80vZSbUnGXLK+Is0pQg4u3MuVLm5bp/FHjL9i7xpf6p8Ubz QNA+HVtF46/aE+H3xn8R3Gmv4Rt9W+Kfh/TP2aNN+E3iLwd4xi8b/CH4h+Fb6bTPi/p8nxksn8Ye GPGGma5qV9NqcUfhvxnL/wAJBZ/fHwZ8E3Pw4+FfgPwLeXerXtx4X8N6fpMkuua9a+J9SiFvGfLs ZtesfDfhCx1GHTI2TTrKWz8MaFaJY2ttBb6dbwxItc9/wqnx3/0cv8bf/BD+zj/9D/R/wqnx3/0c v8bf/BD+zj/9D/W1DLcLh6k6tPE0lKfPdNYhxXtKntJcqWFVry6Xt1d5OTeVbHYivCFOdCbUOWzT o3fJBU43bru9ore19bX5UkvbaK8S/wCFU+O/+jl/jb/4If2cf/of6P8AhVPjv/o5f42/+CH9nH/6 H+uv2NP/AKCqH/gOJ/8Amc5vaT/58Vfvof8Ay49torxL/hVPjv8A6OX+Nv8A4If2cf8A6H+j/hVP jv8A6OX+Nv8A4If2cf8A6H+j2NP/AKCqH/gOJ/8AmcPaT/58Vfvof/Lj+jD/AIJ8/wDJhH7EP/Zo X7NX/qmfBdfXtfIf/BPnn9gn9iE4Az+yF+zXwM4H/FmfBfAyScD3JPqTX15X84Zt/wAjXM/+xhjf /UmqfuGW/wDIuwH/AGBYX/0xTCiiivPO0KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAK/kS/Zo/wCTcP2f/wDsiXwp/wDUE0Gv67a/CvwR/wAEkvj34A8F+EPAmiftg/CG 40XwV4X0DwlpE+q/sg+M7jVJ9L8N6VaaNYTalcWn7Y1haT38lpZRPeTWtjZW8tw0jw2ltGywp+g8 D5xlWV0c3p5ljoYOWJq5ZOhz0MZWVRYeGZKtZ4TDYjlcHiKX8Tk5uf3Obllb4zizLMwzCpls8DhZ YlUIY6NblrYak4OtLBOnf6xXo83MqNT4Oa3L71rxv8p0V9p/8Ov/ANo7/o7v4Jf+Id+O/wD6NGj/ AIdf/tHf9Hd/BL/xDvx3/wDRo19x/rXwx/0O6H/hFnH/AM7T5P8A1cz7/oV1f/CrLf8A5uPiyivt P/h1/wDtHf8AR3fwS/8AEO/Hf/0aNfCPj74M/tG+CviX400+0+N/wS8Rfs//AAc8Z/Dz4b/H79oO 3/Zz8a2Ft8K/HHj/AE2/1G6gXwVP+1TNZ+J/CXwwh1b4U3Xxn8XJ490T/hXml/EptRl0TV4/A/jO PSerCZ9kWOnOnhc2oVZ04e0lH6rmkHyupClGMfa4CCnUqValOlSowcq1apONOlCc5KL58Tk+b4SM J4jLqtOM58kX9YwE9VCVSTkoYyTjCFOE6lSrLlp0oRlOpOMU2bdFfaf/AA6//aO/6O7+CX/iHfjv /wCjRo/4df8A7R3/AEd38Ev/ABDvx3/9GjXL/rXwx/0O6H/hFnH/AM7To/1cz7/oV1f/AAqy3/5u PiyivtP/AIdf/tHf9Hd/BL/xDvx3/wDRo0f8Ov8A9o7/AKO7+CX/AIh347/+jRo/1r4Y/wCh3Q/8 Is4/+dof6uZ9/wBCur/4VZb/APNx94f8E+f+TCP2If8As0L9mr/1TPguvr2vIv2fvhUvwJ+AvwR+ CCa6fFC/Bv4RfDb4VL4mbTBoreIl+Hng3RfCI11tHF/qo0k6uNHGoHTBqmpCwNx9lF/eeV9ok9dr 8SzGrTr5hjq9KXPSrYzE1acrSjzU6lec4S5ZJSV4yTtJKSvZpPQ/VcFTnRwWEo1Fy1KWFw9OpG6f LOFKEZK8W07STV02num0FFFFcZ1BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFfL37b/ibxD4K/Yt/a98ZeEdb1Pw14s8JfsvfH7xN4Y8R 6JeT6drOgeIdB+FHi3VdF1vSNQtXjubDU9K1K0tr6wvLeSOe1uoIp4nWRFYYf/DEPwZ/6HT9r3/x YN+3v/8ARK16FHC4b6tDFYrEV6UatevQpRw+Fp4mTlh6eGqVJVPaYvCKCaxVNQ5faOTU+bkSjzcl SvX9vKhh6NKo6dKlVqSrYidBJVp1oQUOTDYhya9hNy5uRK8Lc13y/XtFfIX/AAxD8Gf+h0/a9/8A Fg37e/8A9ErR/wAMQ/Bn/odP2vf/ABYN+3v/APRK0/ZZT/0G5j/4bMN/89/X+npPtMw/6BcF/wCF 9f8A+d3r/T0+vaK+Qv8AhiH4M/8AQ6fte/8Aiwb9vf8A+iVo/wCGIfgz/wBDp+17/wCLBv29/wD6 JWj2WU/9BuY/+GzDf/Pf1/p6HtMw/wCgXBf+F9f/AOd3r/T0+vaK+Qv+GIfgz/0On7Xv/iwb9vf/ AOiVo/4Yh+DP/Q6fte/+LBv29/8A6JWj2WU/9BuY/wDhsw3/AM9/X+noe0zD/oFwX/hfX/8And6/ 09Pr2ivkL/hiH4M/9Dp+17/4sG/b3/8AolaP+GIfgz/0On7Xv/iwb9vf/wCiVo9llP8A0G5j/wCG zDf/AD39f6eh7TMP+gXBf+F9f/53ev8AT0+vaK+Qv+GIfgz/ANDp+17/AOLBv29//olaP+GIfgz/ ANDp+17/AOLBv29//olaPZZT/wBBuY/+GzDf/Pf1/p6HtMw/6BcF/wCF9f8A+d3r/T0+vaK+Qv8A hiH4M/8AQ6fte/8Aiwb9vf8A+iVo/wCGIfgz/wBDp+17/wCLBv29/wD6JWj2WU/9BuY/+GzDf/Pf 1/p6HtMw/wCgXBf+F9f/AOd3r/T0+vaK+Qv+GIfgz/0On7Xv/iwb9vf/AOiVo/4Yh+DP/Q6fte/+ LBv29/8A6JWj2WU/9BuY/wDhsw3/AM9/X+noe0zD/oFwX/hfX/8And6/09Pr2ivkL/hiH4M/9Dp+ 17/4sG/b3/8AolaP+GIfgz/0On7Xv/iwb9vf/wCiVo9llP8A0G5j/wCGzDf/AD39f6eh7TMP+gXB f+F9f/53ev8AT0+vaK+Qv+GIfgz/ANDp+17/AOLBv29//olaP+GIfgz/ANDp+17/AOLBv29//ola PZZT/wBBuY/+GzDf/Pf1/p6HtMw/6BcF/wCF9f8A+d3r/T0+vaK+Qv8AhiH4M/8AQ6fte/8Aiwb9 vf8A+iVo/wCGIfgz/wBDp+17/wCLBv29/wD6JWj2WU/9BuY/+GzDf/Pf1/p6HtMw/wCgXBf+F9f/ AOd3r/T0+vaK+Qv+GIfgz/0On7Xv/iwb9vf/AOiVo/4Yh+DP/Q6fte/+LBv29/8A6JWj2WU/9BuY /wDhsw3/AM9/X+noe0zD/oFwX/hfX/8And6/09JP22v2oNF/ZP8AgZfePLrXfA2g+MfF3iTQfhT8 JJ/iZrlv4Z+Hr/FPx091beHbzxz4jvbvTdP0XwT4VsbPWfHfjW8vNW0lm8I+FNctdNvhrVzplvce D/CL9on/AIJr/C34H6Z8Dbz9t39kbx/os+ia9Z/ETVvGv7SHwV1rUPix4i8d3Gpar8UvF3jtb7xr dRazqvxK8Sa74h17xPFdeda3E2tXVmka2KxQJ7p/wxD8Gf8AodP2vf8AxYN+3v8A/RK1jz/sAfs9 XOv6Z4rudY/aluPFGi6Prnh7R/Ek/wC3p+3VLr+k6B4nvfD2peJND0zWJP2jm1Gw0fxDqPhHwpf6 5plrcxWWrXvhjw9dX8FxPoumyW3rYfE8OU8FHCVqme831iWKq18LRwNF1qkKfJhIOnUxNZwjhuav yTjVclLE1qjUrU6cfOrUM7nipYinDKeX2McPTo16mLq+yhKaliZKcKFJSlXtDmi6ajahRinG9Scv Hf2EP2lfhFqfi7xx+xp4K+Pfw0+PSfBnw3Z+M/gl41+HfxA8L/Eh9a/Ztu9Sg0DQvDXjTXPCeva/ BF8QvglrM9l8ONdn1mTT9R8V+D7n4a+OHGpa14j8Utp36b18hf8ADEPwZ/6HT9r3/wAWDft7/wD0 StH/AAxD8Gf+h0/a9/8AFg37e/8A9ErXNmNXI8Zip4mjWzPDqrGEqsJ4HB13PEckVXrqUMfhoR+s VFKtKnGkoQnOSp8tNxhDfBU81w2HhQq08BW9m5KnKGKxNJRo816VLlng68pexg/ZxnKo5ShCLnef NJ/XtFfIX/DEPwZ/6HT9r3/xYN+3v/8ARK0f8MQ/Bn/odP2vf/Fg37e//wBErXF7LKf+g3Mf/DZh v/nv6/09Or2mYf8AQLgv/C+v/wDO71/p6fXtFfIX/DEPwZ/6HT9r3/xYN+3v/wDRK184/tT/ALLv gT4cfDLwx4h8GfEn9r3RtY1H9o79jrwFeXn/AA3x+3LqPneE/ip+1z8EPhh490r7Pqv7RN9ax/29 4G8YeItD+3RQJqWl/wBo/wBp6NeadrFpY6ha7YbB5ZisRh8NTx2OjUxFalQg55Zh1BTrVI04uTjm 0pKKlK8moydlom9DOticdQo1a88JhHCjSnVko46s5ONOLnJRTy+Kcmk7JtJu12k21+pdFfIX/DEP wZ/6HT9r3/xYN+3v/wDRK0f8MQ/Bn/odP2vf/Fg37e//ANErWPssp/6Dcx/8NmG/+e/r/T009pmH /QLgv/C+v/8AO71/p6fXtFfIX/DEPwZ/6HT9r3/xYN+3v/8ARK0f8MQ/Bn/odP2vf/Fg37e//wBE rR7LKf8AoNzH/wANmG/+e/r/AE9D2mYf9AuC/wDC+v8A/O71/p6fXtFfIX/DEPwZ/wCh0/a9/wDF g37e/wD9ErR/wxD8Gf8AodP2vf8AxYN+3v8A/RK0eyyn/oNzH/w2Yb/57+v9PQ9pmH/QLgv/AAvr /wDzu9f6en17RXyF/wAMQ/Bn/odP2vf/ABYN+3v/APRK0f8ADEPwZ/6HT9r3/wAWDft7/wD0StHs sp/6Dcx/8NmG/wDnv6/09D2mYf8AQLgv/C+v/wDO71/p6fXtFfIX/DEPwZ/6HT9r3/xYN+3v/wDR K0f8MQ/Bn/odP2vf/Fg37e//ANErR7LKf+g3Mf8Aw2Yb/wCe/r/T0PaZh/0C4L/wvr//ADu9f6en 17RXyF/wxD8Gf+h0/a9/8WDft7//AEStH/DEPwZ/6HT9r3/xYN+3v/8ARK0eyyn/AKDcx/8ADZhv /nv6/wBPQ9pmH/QLgv8Awvr/APzu9f6en17RXyF/wxD8Gf8AodP2vf8AxYN+3v8A/RK0f8MQ/Bn/ AKHT9r3/AMWDft7/AP0StHssp/6Dcx/8NmG/+e/r/T0PaZh/0C4L/wAL6/8A87vX+np9e0V8hf8A DEPwZ/6HT9r3/wAWDft7/wD0StH/AAxD8Gf+h0/a9/8AFg37e/8A9ErR7LKf+g3Mf/DZhv8A57+v 9PQ9pmH/AEC4L/wvr/8Azu9f6en17RXyF/wxD8Gf+h0/a9/8WDft7/8A0StH/DEPwZ/6HT9r3/xY N+3v/wDRK0eyyn/oNzH/AMNmG/8Anv6/09D2mYf9AuC/8L6//wA7vX+np9e0V8hf8MQ/Bn/odP2v f/Fg37e//wBErR/wxD8Gf+h0/a9/8WDft7//AEStHssp/wCg3Mf/AA2Yb/57+v8AT0PaZh/0C4L/ AML6/wD87vX+np9e0V8hf8MQ/Bn/AKHT9r3/AMWDft7/AP0Stcp8A/CUXws/az/aK+FPh3xd8Wtd 8B6f+zt+yT8QtL0X4qfG/wCMnxxm0fxd42+JX7aHhvxXqmia38afHfj/AF/RYtd0b4ceCLS/0rSt UtNHkfw9aXa6el7Ld3FxTwmCqUMVVw2LxVSeFowryp18DSoQnCWKw2FaVSnj8S1JSxMZJOnZxi/e TaEsRioVcPTr4fDwhXqSpKdLFVKsoyjQrV03CeDoJxaoyi2p3TcXZq9vuiiiivMO4KKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooA+Qv+Cg3/JhH7b3/AGaF+0r/AOqZ8aV9e18hf8FBv+TCP23v+zQv2lf/AFTPjSvr2vRq /wDIpwX/AGMc0/8AUbJzjh/yMMV/2B4H/wBP5iFFFFecdgUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRX80P8AwVct/gTbftkeLvF/7QekfDe+8G+Cv2Rf2a5bTVfi ZoOha9p2g3fiX44ftbaXLDo0euWOoNDqnia/tNA0uOx0mFtR8QX9vo2nQ297dx2EA+GfAfhj9hv4 n6qdF8A/C/4C+J9RXwZovxAaPT/g74ZFuvhTxB4l8YeD9Mv2v7nwlBp4uj4n8A+MNEv9FN0Nd0e+ 0O5i1jTbAS2rXH6Hl/A+ExmEwWIq57LD18ZhqWJWFWXUqsoxqw50oylmlGdRJXTl7GCupJLS58Xj eK8ThcTiqMMoValhq86DxDxtSnGTpyUW5RWAqxg22rR9pJ2cddbH9olFfyJf8M0fs4/9G/8AwS/8 NT4E/wDlDR/wzR+zj/0b/wDBL/w1PgT/AOUNeh/xDjDf9D6v/wCGen/89zi/14r/APQopf8Ahzn/ APO0/rtr5C/be/5Iz4L/AOzvf+CfP/re/wCzVX8zWv8Awr/Y/wDC/i3wH4G134MfBCw8VfE678Q2 PgbSm+Dnha4Ou3fhTQbjxPr8KXlr4Un0+waw0K0uL8nVbuxW6SJobNri5xCTQPhX+x/4o8W+PPA2 hfBj4IX/AIq+GN34esfHOlL8HPC1udCu/Feg2/ifQIXvLrwpBp9+1/oV3b34OlXd8tqkqw3jW9zm EbYPgTBYTG4XEf29UqSw2LoVPZf2XShKdSi44n2N/wC15OM5Uo8/wykqb9pyuKM8RxfisRhq9H+x 4QjWw9WPtP7QqSUYVOah7W39nRUoxqS5b8yTmuTmUj+yKiv4jvEurf8ABOnwh8SNU+EHiHwl+zjp /wATNF0i51zVfBY+Evhi81uy0y08K3XjaaeaCw8I3SCQ+FbO41qC0WRry6tVQWtvNNPBFJ7J4T+C H7Kfjnwt4a8a+Ffgd8ENW8MeMPD+jeKfDmqJ8IvB1qupaD4g0621bR9QW1vvDVrfWy3mn3dvcLb3 ltb3UIkEdxBDMrxryw8PsBUlKFPiOc5wcozjDKqMpQlBpSjKMc5bi4tpSTSabSdro3lxni4RjKeS RhGaUoylmFWMZRkm4uLeWJNSSbTV00m1sf2G0V/Il/wzR+zj/wBG/wDwS/8ADU+BP/lDR/wzR+zj /wBG/wDwS/8ADU+BP/lDWn/EOMN/0Pq//hnp/wDz3I/14r/9Cil/4c5//O0/rtor+Pk/Av8AZPXx CnhFvg7+zyPFcujS+I4vDB+Hvw2HiGTw9BfQ6ZPryaKdI/tJ9Gh1K4t9Pl1RbY2Md9PDaPOJ5Ujb 97/+CUllZaX+xD4E0nTLS107StH+Lf7W+jaTptjbxWmn6XpGkftf/HjTdK0rTrO3SO2sdN0zTrW2 sNPsbaOK1srK3gtbaKKCKONfC4h4Ro5Hl0cfSzSeNbx1DBSozwEcLyutQxdf2ntI4/FXcfqvK6bp xv7RS51y2l6+S8SVM2x0sHUy+OFthKuKVSOLlX5vZ1sPS5OSWEw9lL6xzKam7cluV811+i9FFFfE n1QUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV8heC/wDk/f8AaV/7NC/Yh/8AVzf8FBq+va+QvBf/ ACfv+0r/ANmhfsQ/+rm/4KDV6OC/3bOP+xdS/wDVtlZx4r+Pl3/YZP8A9V+OPr2iiivOOwKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooA+Qv+Cg3/JhH7b3/ZoX7Sv/AKpnxpX17XyF/wAFBv8Akwj9t7/s0L9pX/1TPjSv r2vRq/8AIpwX/YxzT/1Gyc44f8jDFf8AYHgf/T+YhRRRXnHYFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQB/Lz/wWV+G3/C2v2kviX4Fb4cj4nx6l+yz+x5qH/CP23xH u/hR4h0288O/tE/td+ItE8YeDfG1npmoNpni7wb4h0rSfEmixXE2l2V5Jp0lveX8kDvpepfipqn7 Dv7S3jTS9G8e/E3UrLxb+0H4K+E37PHh74f+Px8Q7yHW9D8R+Bv2rPij8QdebUNW0mx8KabrXifQ fgR4l8L+GdV8Y3eg7vEHiA+JBpE1wNW1K/v/AN/v+Cj9/wDEex/b213/AIV94V8E+JzL+yF+zj/a 48ZfEDXfAosQnxm/bC/s/wDs06J8NPiL/aput999sF0NG+w/Z7TyDqP2yb7B8i/29+0d/wBEp+CX /iQHjv8A+hor95ynKKWOyjKa9SUdcpwlLleIwtJWVBKM5Qm1UdSlKUpUJVG1Sbc6Sj7Sbn+RZnmd TC5lmNGEXZZhXqc3scRPX2ibipRvBQqKMY1YwS9oko1G+SKj+UFx+xD+074u8afGHUPFGg+FvDGi fFi90Gz8aW/gT4g3mhaV4sn0D9tT4bfFWHxhaPp88Xi9NQ/4UbaeMbW28VeINabx8uuSar4ftLfQ 9JHhmO49N8Wfsa/GTS/jp8QvFngPQre98P2/hTWtL+B2qL8SY/D/AId0DwrYfsuP8KvB/wAD/Hei xaZF8Rz4CHxFsU1bVLPwb410+0vH1LSviA+p2fjLS75W/RL+3v2jv+iU/BL/AMSA8d//AENFRnxJ +0SsyW7fC74HC4ljlmigP7QnjkTSQwNCk8qRH9mne8cL3FuksiqVjaeFXIMqBvQXD2HSj+8TlGpT qKbxmCcr05VZJXvblc605SSSbnaSaau+H+2qzb9zRwnHl+rYrltNUk3be6jRhFNtrl5k000l+OEP /BP347to2kx698HPCfjDwjofxh8feP7L4L3HxctPAumNpvjL9mvwV8ND9hPg/T5vC3hiEfFO01rx fL4P0s3eiNb6f9uu7/UdZ1A3V5p3v7Av7WUem6Ta+J9S0r4qWMV58AR8SNKTxlo+lXXxSn+Hv7JW nfCPUPEkh8WaDrmiapeeFfidaf2rp1v4vtrS41WLZ4wtrm38QafYQyfsB/b37R3/AESn4Jf+JAeO /wD6Giq3/CVftB/bP7P/AOFafAn7f9m+2fYf+Gh/G32z7J5vkfavs3/DNXnfZvO/c+fs8rzf3e7f xWX+rOFX/L1q81K/13BJuXJyWdmuaPKklCfNGKUlCMVUqqd/27iHb92naLj/ALtino5Kd1/LLmV3 KHLKTs5uThTcPzZ8DfseftBeFfjb8YvE9/a+PdW8O/Ef9n74XfDnS9bn+PtlNY6l4m8GfstX3ws1 m8+NPhcaZZv8UdZn8ZXEJ0jxQ9vYCy1Z73xZDZ20N1JbnB8A/sN/tCaF4n0e78U21ze3Wn/Bnw74 S0Lxd4d+JHh2wstAtdL/AGPNN+Dtz8I/EGh3vhufxBf+Ex8VtP1LxA1j4c16Hwtq15qWieP74w+I dO1G0l/U3+3v2jv+iU/BL/xIDx3/APQ0Uf29+0d/0Sn4Jf8AiQHjv/6GitVw7QXL+9uoV6mIinjM FbnqTdSSdmrx5m+W95xW09FaHnVZ83ufFRhRb+rYm/LThGEWtNJcsUna0ZatxbbPyv8Ahz/wTu+K Xg3VdF8RWkDaL4k8M6v+wf4x8O6rH8UPE2qx6V478KXdnp/7ZviYaRc69LpWp6l4x8OWVpYXn9p2 8sHi/SrX+x7IwW0jW71fh1+wN8a4PA2leDvHmkah9quPij+zHd/Fkp8XNP1Dwr8UNC8Ba/4x/wCF 0ePrJdE0Pwv4tTxF400TW44NU1PxVqU3i/xXolzpmh6j5cnh8S3P6tf29+0d/wBEp+CX/iQHjv8A +hoo/t79o7/olPwS/wDEgPHf/wBDRSjw3hY8nK4JQVVcqxeDUZ+1cnJzipWckpKCas/ZwhB3jGw3 nmIaldSbk6T5nh8TzR9koqPK7aJuHPJO655SmkpSufA/7Pv7FXjH4RftC/An4k6z4H0DW9F+H/w7 /aR+Flt4h/4Tq8u9f+Hmjav8dfH3i/4K3cNnqCyy+JtJX4Q+I4vh/Yaet7Ld+GodXuY7y3todGs/ N/rY/wCCWX/JmHhX/stv7Y//AK2Z8f6/B/8At79o7/olPwS/8SA8d/8A0NFfun/wSfk1GX9h/wAC y6xa2Vjq8vxf/a8k1Wx02/n1bTbLU3/bE+PTX9pp+q3Wm6NdanY212ZYbTUbnR9JuL23SO6m0vT5 JWtIfl+Nsvp5fwzCnS5OSeeZfK0atCo+aOWZlSu/Yu+saUW5TTbk2k+VRjH3+FcZPG59OdTm5o5T jI3dOtBWePwNTT2qto6jSUbKyTa5uaT/AEaooor8fP0sKKKKACiiigAooooAKKKKACiiigAooooA K+QvBf8Ayfv+0r/2aF+xD/6ub/goNX17XyF4L/5P3/aV/wCzQv2If/Vzf8FBq9HBf7tnH/Yupf8A q2ys48V/Hy7/ALDJ/wDqvxx9e0UUV5x2BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHyF/wUG/5MI/be/7NC/aV/8A VM+NK+va+Qv+Cg3/ACYR+29/2aF+0r/6pnxpX17Xo1f+RTgv+xjmn/qNk5xw/wCRhiv+wPA/+n8x CiiivOOwKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD+d7/gobL4 vj/4KAaivhay8N3VpJ+yz+y4vieXX9U1TT7m00H/AIXV+2SLybQYNO0jUotQ1cRGRra21C40yyaR ESW7VZWeL+fL4YfEj9rDxl8EPAvjbwZrHxs8Uab4s+EH7MfiL4teIfH3hHX9N1qPxNr2uSn4jXHw Rh8NfD+TVdZ8Oap4K+x3Osar8OPDXi67h8NXejeIPD10vxGn129m/ox/bu/5P38X/wDZoX7Mv/q5 v2za/NHw/wDtK/Ci0+Dl34n8GWENzZ+Af2eNK+Ms3gzwTpGqN4U8N+El+HVh418O+DrbxbbeHLDw Vouo3fhq50yTw14ZvJdI1yfw3PZa9a+GYdD/AHsf7ll1KM8pyWU8XPDxWU01yxk4ubeGw/vQs0m6 aUm4tTm1OShy6tfk+OqSjmWaKOGjXf8AaDbk4pqKVarpO6dlNtJNOEU4rm5tE/lvQNX/AGt2+IHw tsdX8ZeLV8KS2Xw/m0DxD/wqz4uyWF8t18bviLbePfD/AMRtAPwks79NYh+DkPw88KS+KfjDqHwy sEeb/hZ/hiDTteuPEL2XOHSf2s9I+Fnwh8Tpqnxi1v4s+IP2afiXqnjTWtT8K6JqfinwT8Ste+I3 7G1hp3hXSrJfB/kaAU8KaN8Q9Rh8NXWn3S6xPpPiPxFr0Gr6jp815bfcHi39rH4KeFYviRAviO78 QeIPhjoXj/Vta8MaHomsSX+o6n8NNCPiPxV4M0DVL+xsPDOreOLHRzBqkvha313+1bbRLmPxJe29 r4bSfV4b2g/tF+Cj4VufEPjzUPD/AIRnsfh9rvxZuYtD8SR/EPQrz4ZeH54YNQ8Y+G/E/hnTTZ+J 7G2lurS0u7HSbWXWIdQurS2h0+6g1LRrzU+z2GHfPTeY1HJQa541pWp2nSfNKbqSgqkXScIOUlVV OTi3Pl5jk9rXXLNYKCXNF8rpRTqLlqLljDkjNwkqilPlTpuaTtFS5T86viv8SPj94C8fa38Nb74j fEPRfA/gPW/il4xi8dauviCXXtJ+EmkQfs46zZfE3xNeeC/h34w1Px94T8MXHiP46+GLHR9csfCP h/XBA1pL4wuNc8F2k2j+pWHw3uo73TPDr/CPxQn7Stv+2XJ8SdU+Mq/DzU7bTW+Fz/H2fxzqfiOP 42CyPhi58P65+zLj4QxeBYPFU3iG1m1GDwPP4PtrfTJ5LP7esdR+CHxw1y4A0Pw18QtV+FGv3Mdj rPiDwJNqNn4e8Q2+q3uk6lc+B/FPiPQBpOoXem6/4VvtH1rUfBGqX40nXdBk0rVbm01OxFtH7TWk MB7SdWo8T7alN2o3ftVTp6KaptycYVYSgo0qsbzhaXNzNqMM5YzkhTgqHs6kEnU05Oedrxc0knKn NScp05WjK8bWSbn+K3iHx3+0J4I8Dfs+ad4z+K/xQ0nxRrHwa8R/Gz4+ar4iXVrXV/hZNo2qfBrS ZvEGs+H/AAD8MvE2oSeEPCnhi1+IVo3gLxBpvhLR/Eetarq+vaj4yu/FOnrd6V+1Ncp4j8B+BvGN 5oOo+LvBnhPxVqHhW9bUvDF94j8O6Prl54c1F3tpHv8AQbrU7O6n0e9eSztHa6097edntbZjIWgi K9XXVhcNPDyrc1aVWE1RjT55SlKKpU1CTk5NrmqSvOTSu225Sa5YwwxFeFeNO1ONOUXVc+VRUXzz 5opWSdoR91J6JJJK93IooorsOUK/XP8A4JZf8mYeFf8Astv7Y/8A62Z8f6/Iyv1z/wCCWX/JmHhX /stv7Y//AK2Z8f6+N4+/5J2n/wBjrAf+oObH1HB3/I6n/wBivF/+peXH6G0UUV+Mn6gFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFfIXgv/k/f9pX/s0L9iH/ANXN/wAFBq+va+QvBf8Ayfv+0r/2aF+x D/6ub/goNXo4L/ds4/7F1L/1bZWceK/j5d/2GT/9V+OPr2iiivOOwKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA+Qv +Cg3/JhH7b3/AGaF+0r/AOqZ8aV9e18hf8FBv+TCP23v+zQv2lf/AFTPjSvr2vRq/wDIpwX/AGMc 0/8AUbJzjh/yMMV/2B4H/wBP5iFFFFecdgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFAH873/BQ3wf4X8U/8FANRvPEWhadrF14X/ZZ/Zc1/w9cXsCyzaRrNn8av2yZb bULGThobiKSKJ1IO0vHGzKxRcfl5pn7E+l6d4R0vwTH8Qb610jSf2bk/Zye90PwzY6Fr/ifRY/hb p3wvtNU8f6ja6lJaeNLXRIbW98UeFtF1LS47jw5r+p3CWOvf2T5mnT/p1/wUY8R6t4e/b41kaZ4L 17xXHqX7KH7Mlpf3+lal4O0zS/CdqfjP+2Tv1/xRP4o8T6DfDQrVXea9bwtpnivXY7aCd7XQL2YQ W9x+NWiftk/EPVNG8N6Zrvjr9nr4e+LJNM+LWqePfGXjDRL6X4U+F9d+Gvhb4HeIrH4a6Dqnh/45 arp3je78U6Z8Z4fGGlfEDSPG0Ty+DfD2qrN8L7PxFp2taXpH7nl0sHHJ8neIptyeXYRKVnBNujho 8rqOVOMm24fakoxhJycYwk1+T4+OKlmeZ+wmlFYyu3F2m0lOtJtRUZyiklK+kXJyilzOUU/peb9m G2g1qy8TaF481fRvEWk/Gn4p/G/Rr46NpWo29n4h+J3w08TfDmXTZ7C7PlXumaLH4i/teHfJFPfP ZmyleBbkXVvxMf7EHg+WTQNQv/FmoQ6vB8Zb34u+Mo/DHh7QvC/hLxlbapJ8PtQ1r4cDwbbx3mn6 H4F8SeJfhF8LvGPiq0huL/U/Evinw7rGq6rqM8ni7Wkfx/Vf28PFdppbB9A8DaB41ufH+h6Za/Dj X7nUj4u07wJq37CejftMXes6hpJ1fS9WuZdH+K+o3XgC812PSbDR/wCzLJ9HlsLbxIsl+vYeGv2k fjENV8NaX408T/A6w1G4+CHw0+ODeH7Pwb4n0vXfipcfFTWPG1rY/B74RW+sfGCWWTxd4Tt/BNvp V/4mez8VnxLrnj/wa8fgDwrHIlhqnYquWVJOEacp/vJKS99QjUj7NNyU6kUpctOOluZxg4Wbkoz4 /Z4+CUnOMG4R5fhcnB8zXK4wleKlNrR2Upc2ylKP1N8GfhNf/B7Sr/wpa+M7nX/A9tf6tP4J8O3W h6fY3XhWx1rxLr3iW60+912Caa88Sm1k1qLStNu7iLT5ItL0y3OoJqeqz3eqS+0V+WPwz/aw+LXx LtfhP4s8QaNo4sm8RaT4qXSPh1r/AIPXUPFlvr/7Ln7UHjW8+G+r+FvB3xn+M97JBo+ueB/CmoaD r3iy58IT+KdZuYhD8P8ARdQ8G3M1x5Xo37ZHxRg8bat4vsPGfwm+I8nxI+Hn7Hem20vgZbUfDr4Q f8Jzo37aHxL1aPxFo3jf9oDwr4an8azf8IZ4d8HX2p6n8Vfhm3iKHWPAV0mitqdvo3hHWap5nhKV OjGnCsqcpyp04yUnJRhSVRWjOTm43cacIq8YpqTcafK3MsBiak6spypucYxnNprlbnU5HeUVyppX nJuzk7pKU7pftFRX5q6f+1b8eb7VtNmv9B+FPh/StHsf2MbfxjoEcV1411PWNX/at+NuufBe71Hw v458I/Eq68G6Zo/hT7FpnjTTbaG18eLrVtcXPhqTX7SUR+Ik+gv2NPHnj/4j/AfQfE3xP8ceF/Hn jVtd8WaXrGo+GPDMXhIaW+j+IL7ToNC13R4PEfiKGPX7KC3juLiVDo7tp95psdxpJuop9V1Xro46 lXqxpQjVTnTqVU5xUEo06ipO6lJTUnU54qPJzJ05uSiuRz56mEqUqcqs5U7RnCDUZOTcqkPaKzjF waUHGTlzW9+Ki5S5lH6oooorsOUK/XP/AIJZf8mYeFf+y2/tj/8ArZnx/r8jK/XP/gll/wAmYeFf +y2/tj/+tmfH+vjePv8Aknaf/Y6wH/qDmx9Rwd/yOp/9ivF/+peXH6G0UUV+Mn6gFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFfIXgv8A5P3/AGlf+zQv2If/AFc3/BQavr2vkLwX/wAn7/tK/wDZoX7E P/q5v+Cg1ejgv92zj/sXUv8A1bZWceK/j5d/2GT/APVfjj69ooorzjsCiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP kL/goN/yYR+29/2aF+0r/wCqZ8aV9e18hf8ABQb/AJMI/be/7NC/aV/9Uz40r69r0av/ACKcF/2M c0/9RsnOOH/IwxX/AGB4H/0/mIUUUV5x2BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAfzmf8FH/ABVrvhj9vbXTonw08bfEX7d+yF+zj9qHg2/+HFidG+y/Gb9sLyDq X/CwfiB4FEo1H7RN9j/sg6qU+wXf9oCx32P2z4zHjzxGLODTx+yl8WxYWswuLaxGofszizt5xI8o ngtv+F9+TDMJZJJBJGiuJJHcNudif0C/bu/5P38X/wDZoX7Mv/q5v2za+fK/ojIJwWR5QpYejUay 7Ce/N1uZ3oU3Z8laEdNErRWiV7u7f4rnUJPNsxarVIL65X92KpWVqktuanKXnq3q3ay0PCG+JHi5 7k3r/sufGNrw2/2Q3bav+zW1ybXc7/ZjOfj8ZTb75JH8nf5e6R225ZiR/iR4ulntLmT9lz4xyXNg JhY3D6t+zW89kLiMRTi0lb4/GS3E8SrFMIWQSRgI+5QBXu9Fev7Wl/0C4fe/xYnfv/vG55nJP/n/ AFe21Hbt/BPBofiL4rt2drf9lr4wwNJeTajI0Oq/s1RM+oXEbQ3F85T4+qWvJ4XeKa5YmeWN2R3Z WIMA8d+IhBc2o/ZR+LQtrzH2u2F/+zMILrbNJcD7TD/wvvy58TyyzDzVbE0kkg+d2Y/QFFL2tL/o Ew/34n/5oHyVP+git91Hpt/y5PB/+Fj+LdqJ/wAMt/GLYi2aIn9rfs17UTTpvtGnoi/8L9wq2Fx+ /s1AAtZv3sAR/mp9v8S/GNoJha/sv/GW2FxcS3dwLfWP2bIRPdTtunuZhH8fl824mYBpZn3SSMMu xNe60U/a0/8AoFodvixO3b/eBck/+git91H/AOUniX/C1vHf/RtHxt/8H37OP/0QFH/C1vHf/RtH xt/8H37OP/0QFe20Ue2p/wDQLQ/8CxP/AM0B7Of/AD/q/dQ/+UniX/C1vHf/AEbR8bf/AAffs4// AEQFfun/AMEn7qe+/Yf8C311pt7o11e/F/8Aa8u7nR9Sk06XUtJuLn9sT49TTaXqEuj3+raRLfaf I7Wl3JpWq6npj3EMjWGo3toYrqX8ma/XP/gll/yZh4V/7Lb+2P8A+tmfH+vivEGcZcOUuWlTp2zr A3cHVbf+w5to/aVai+5J+Z9VwZGUc7qXqTn/AMJeL0kqaS/2vLtVyQg/vbXkfobRRRX4qfqYUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAV8heC/8Ak/f9pX/s0L9iH/1c3/BQavr2vkLwX/yfv+0r/wBm hfsQ/wDq5v8AgoNXo4L/AHbOP+xdS/8AVtlZx4r+Pl3/AGGT/wDVfjj69ooorzjsCiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKAPkL/AIKDf8mEftvf9mhftK/+qZ8aV9e18hf8FBv+TCP23v8As0L9pX/1TPjSvr2vRq/8 inBf9jHNP/UbJzjh/wAjDFf9geB/9P5iFFFFecdgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFAH4G/8ABQLRfG2nftrav4ts/hL8dfGPhbXv2W/gL4d03xJ8L/gH8aPi 5oTeIPCvxZ/an1PxBol7q3wu8CeL7HStW0zTvGPhe/m07VZ7K7ez1uxuYIpYZGdflT+0fF3/AEQP 9r3/AMQp/a6/+cnX9TtFff4DjupgsFhcG8shV+q0KVBVFipU+eNKEYRk4fV58rcYq/vNX1VlofH4 zhGGLxeIxX16dP6xVnVcPq6nyucuZpS9tG6Tbs+VaWvezb/li/tHxd/0QP8Aa9/8Qp/a6/8AnJ0f 2j4u/wCiB/te/wDiFP7XX/zk6/qdorr/AOIiT/6FMP8Awtf/AMy+v9LXl/1Jh/0MZ/8AhKv/AJf6 /wBLX+WL+0fF3/RA/wBr3/xCn9rr/wCcnXEePfi7onwq0a38RfFHwL+0J8NfD93qUOjWmvfED9lb 9prwZot1rFzbXl7baRbar4k+Emm2M+qXNpp9/c22nxTveXENldSQwusEpX+tNmVFZ3ZURVLMzEKq qoyzMxwAoAJJJAAGTxXwN8OfDGiftjeMPEP7QHxB0W28R/ASLw94x+Ff7NPgzXrCGXSPFfgjxXY3 Xhf4sfH3U7GbzGul+MtgbnwZ8MZpthtvghbXPiHTWhh+NOv6fB24PjyNVVcRisrdPB4ZR9tKljV7 WpVq8yoYehz4XkdWq4zm+Z2hh6VerabpKE+XE8IezdOjQx/Pia7fs41MNanCnT5XWrVeXEc6p01K MVypuVarQptxU3OP4uf2j4u/6IH+17/4hT+11/8AOTo/tHxd/wBED/a9/wDEKf2uv/nJ1+6/7Kfi TXfCEvjH9lD4iaxeax49/Z9h0VPBviTWbk3OsfFH9nXxC1/B8HviHd3L29udS8QaNb6Nq/wn+I94 TPe3nj34fap4rvxbWPjbQPtP2NWWL48q4TETovK6dSK5J0qscbJRrUKsI1aFeCeFuo1qM4VIxlac FNRmlOMkaYfhCniKMKqx84Sd41Kbw0XKlVhJwq0pNV7OVOpGcG1eMrc0XKLTf8sX9o+Lv+iB/te/ +IU/tdf/ADk6P7R8Xf8ARA/2vf8AxCn9rr/5ydf1O0Vz/wDERJ/9CmH/AIWv/wCZfX+lrt/qTD/o Yz/8JV/8v9f6Wv8ALF/aPi7/AKIH+17/AOIU/tdf/OTr9pf+CZXh/wAS+Gf2OfBWn+LfCni7wTrN 58UP2ovEq+HPHfhTxF4G8V2mi+Mf2qfjV4u8MXmreE/FumaN4k0Q614Z1zSNbs7XWNKsbxtP1G0n e3RZlz98UV42fcXTzzL4YB4GGGjHGUcW6ixDrScqNDE0YwUXRppJrFSk3du8YpLdnqZPw3DKcZLG LFyrylhqmGUHRVNJVauHquV1Um208OklorSd9kFFFFfHH0wUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAV8heC/wDk/f8AaV/7NC/Yh/8AVzf8FBq+va+QvBf/ACfv+0r/ANmhfsQ/+rm/4KDV6OC/3bOP +xdS/wDVtlZx4r+Pl3/YZP8A9V+OPr2iiivOOwKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA+Qv+Cg3/JhH7b3/ZoX 7Sv/AKpnxpX17XyF/wAFBv8Akwj9t7/s0L9pX/1TPjSvr2vRq/8AIpwX/YxzT/1Gyc44f8jDFf8A YHgf/T+YhRRRXnHYFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfO37Qfxh8cfC yX4L+Hfhp8P/AAp8RPHnxv8Ai1d/Cvw3pfjn4jav8LPCOlzaZ8G/i98adU1vXPFegfDP4u6zFFHo Hwf1fStPsLDwRfte6xq2nLcXenWSXN3Hxf8Awmn7e/8A0bV+yF/4m98Zv/pfNH7Sv/JZv+CfP/Z3 vjT/ANYI/ber69r1pTw2Fw2Xt5fhcRPEYWpXq1a9THqbmsfjMOklh8bh6aiqdCCSVO7fM3Jtq3nR jXxFfGJYzEUYUMRCjTp0oYRx5XhMLXbbrYWtNyc607vntaySVrnyF/wmn7e//RtX7IX/AIm98Zv/ AKXzR/wmn7e//RtX7IX/AIm98Zv/AKXzX17RWX13Df8AQoy7/wAG5t/88/6u/K2n1Wv/ANDHG/8A gvL/AP5g/q78rfIX/Caft7/9G1fshf8Aib3xm/8ApfNH/Caft7/9G1fshf8Aib3xm/8ApfNfXtFH 13Df9CjLv/Bubf8Azz/q78rH1Wv/ANDHG/8AgvL/AP5g/q78rfIX/Caft7/9G1fshf8Aib3xm/8A pfNH/Caft7/9G1fshf8Aib3xm/8ApfNfXtFH13Df9CjLv/Bubf8Azz/q78rH1Wv/ANDHG/8AgvL/ AP5g/q78rfnN8efCv7dPx9+D3j/4M6r8Hf2evAGj/EbQZfDOt+KPhv8At2fEfTvGVpod7cW51rT9 KvPFP/BNXxdoUMPiDSo7vw7rH23w9ftJomq6lFaGzvpLa/tfnu8+BH/BW2x0PS9H8DfHfw54WTSr zwrbW1veftC/s66podp4R0nWdJ/t/wAP6Xomj/8ABDjwoNNvL/wfa6p4f8K6nHfS6Z4R1m70nxBe +G/Fel6NceEtZ/Z2iu3D599WpRo08oyadKNZ1408ThsRjIqrKNOMpJYvF17KUaVOMor3JJWcXdnL WyhV6jqzzHM41JU1Rc6FejhpOnGUpRi3hsNSvyynNxl8UXJ2a0t+P3hb9n3/AIKI6R8afh78cfGG seEvit4k+G2ieOPDWjaJ4y/bN8DeHPDWqeHviBY6fBr+heJz8HP+CMnwr8T67ow1XQ/DHiuw0q68 TDT7XxX4V8P6ubaU2csNx9if8Jp+3v8A9G1fshf+JvfGb/6XzX17RWWJziOLlTlXynK37GkqNKNK OPw9OFNVJ1eWNLD4+lTV6lWpNtRu5Tk23pbShlssOpqlmGP/AHk/aVJVJYStOc+SFPmlUrYOpNvk pwiryskkkkfIX/Caft7/APRtX7IX/ib3xm/+l80f8Jp+3v8A9G1fshf+JvfGb/6XzX17RXP9dw3/ AEKMu/8ABubf/PP+rvytt9Vr/wDQxxv/AILy/wD+YP6u/K3yF/wmn7e//RtX7IX/AIm98Zv/AKXz R/wmn7e//RtX7IX/AIm98Zv/AKXzX17RR9dw3/Qoy7/wbm3/AM8/6u/Kx9Vr/wDQxxv/AILy/wD+ YP6u/K3yF/wmn7e//RtX7IX/AIm98Zv/AKXzR/wmn7e//RtX7IX/AIm98Zv/AKXzX17RR9dw3/Qo y7/wbm3/AM8/6u/Kx9Vr/wDQxxv/AILy/wD+YP6u/K3yF/wmn7e//RtX7IX/AIm98Zv/AKXzR/wm n7e//RtX7IX/AIm98Zv/AKXzX17RR9dw3/Qoy7/wbm3/AM8/6u/Kx9Vr/wDQxxv/AILy/wD+YP6u /K3yF/wmn7e//RtX7IX/AIm98Zv/AKXzR/wmn7e//RtX7IX/AIm98Zv/AKXzX17RR9dw3/Qoy7/w bm3/AM8/6u/Kx9Vr/wDQxxv/AILy/wD+YP6u/K3yF/wmn7e//RtX7IX/AIm98Zv/AKXzW58F/jR8 V/FvxX+KXwZ+M3wt+Hvw58YfDn4e/B34nWt18MfjF4k+MPhrXvDXxh8SfG3wrp1vcaj4q+CXwO1T Rtc0bVPgdrsl7ZR6FrFhcWGsaTPBqy3C3lnB9Q18heC/+T9/2lf+zQv2If8A1c3/AAUGrenPC4nC 5k/7OwlCph8HTrUqtGpmDnCbzDAUJe7Xx1elJSpV6sWpU3bm5o2lGLWUoV6FfBf7bia0KuInSqU6 sMGoyisHiqq1pYSlUTVSlCScZrZp3i2j69ooorxz0gooooAKKKKACvkLwX/yfv8AtK/9mhfsQ/8A q5v+Cg1fXtfIXgv/AJP3/aV/7NC/Yh/9XN/wUGr0cF/u2cf9i6l/6tsrOPFfx8u/7DJ/+q/HH17R RRXnHYFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAfIX/BQb/kwj9t7/s0L9pX/ANUz40r69r5C/wCCg3/JhH7b3/Zo X7Sv/qmfGlfXtejV/wCRTgv+xjmn/qNk5xw/5GGK/wCwPA/+n8xCiiivOOwKKKKACiiigAooooAK KKKACiiigAooooAKKKKAPxP+Pn7cv7Wnhr9pH4//AAt+Fl/+zroHgn4PeM/BfgzSv+FgfBz4l+Pv FWry+IPgZ8I/izqOq6hrfhz9or4Y6RFGuo/Eu60my0+28MK0FlpUE89/dz3Mgi8y/wCG7v29/wDo b/2Qv/EZfjN/9GbXl/x4/wCTz/23/wDstvwx/wDWM/2Vq/lY/Zf/AGoP2lPhd4Q1H4leNvGnjHUb 7xP+z7qfiLwr/wALj+JnxL+MPw/8V3n/AA2Jo/wm8TfGHUdH1iawu/hm3wD8Dax9v8WfDzwfdSWv ijwi/wDwld54i0+2spJNP/Z6eEyLB4DJHXyjB1Xi8nwWKrVnhqU5KSwGBq16lSU4ScpVauI5venF OTcItzlCnL8vnic3xOMzZUcyxNNYfM8Th6VJV5xTi8ZiqdKEFGStGnToJPljKy96SUeea/r3/wCG 7v29/wDob/2Qv/EZfjN/9GbR/wAN3ft7/wDQ3/shf+Iy/Gb/AOjNr+cbU/8AgpF8Q/Bvg/xfrfij xT8FtX0nT9H/AG39F+FXxU0vQ9W0nwH8cfGPwG8LfBbWPg3qPhKM+N9esbm28U+IPGnxA8L6ppmi eKdZtfEV54RuBoOrWE1pcxrmaN+0X8Yta+KWpad43+K/hDxPLfftbfsR3Hhv4U6Np/jLwVrfgvwT 8Y/hl8Jtf1PVLGbQPiyL3xB4HtLjxTrGiTaN4p0bWvCOteL7DUPEmrWkklz/AGBY6OHDV4xhlGCl JyjGSeEwsVDnoyrxcnaTkpQg+V041FN6xbg+dwp56k5TzLFRioykn9YxEnLlqwoySWii1KcXL2jh yq6laV4n9Avjj9p/9tjx94m+DvivWPHX7LVtqPwR+I+qfE/wpDpn7NnxahstQ1/VvhF8U/gxc2fi GO6/a9vJ7vR08L/F3xJfwW+m3Ok3q6/Y6HdSahJp1tf6Vqfo/wDw3d+3v/0N/wCyF/4jL8Zv/oza /mM1T/goz+1D4J+HHgzxP40f4P30vxR+Dn7N/wAXdJ1nw98PNa09PAOm/Fb4ka34G8X6fdad4p+M Wk+HfGOo6ZoWiQ+JtPu9Y8b/AA00j+2dRn0QvJGukRalxfxB/bD/AGlPEEvwL+JNvqnivxmP2bPh p4R+Nn7Sh/ZUmtb/AOCXiS88eePLPWPFHgX4lanYfEHxH4fn0bwF+z14O8W3lpPpOo+O7WH4hayL xLuDSYGuoVUq8OShTi8ow8/Y0Y+zpvAYa9OjOvOpKCspXklOvinFXvBTXMpe4FOnnkZzazKtD2tV 881iq7U6saVOnGUr20bhRw3M7Wk46ON5P+qf/hu79vf/AKG/9kL/AMRl+M3/ANGbR/w3d+3v/wBD f+yF/wCIy/Gb/wCjNr+dHx7/AMFBvixolz+0Jb6N46/Z/dPhv8SNFm0TUrFPBWvaBb/A++174iWH m6L4lvf2kPDWj+KP2hJNL8EvNqPwX+IUnwX1VbzTfEd34RbxVp8mlQrNf/8ABQ740r42vv8AhGNJ 8DeM7mHxTf8AhTSP2YofAPi7w98f9d8F237MS/HDTf2gbj7V431bU/DnhfXfFk9h4etvCtz4A1Sx tNK1BNETxtqXia1n1OqcOGE0nlWD1nGC/wBhwzu3OpT0STlKzpNuMVKck1ywk20kp5+9sxxOkHPX FVlZRhTnq3ZR0qRXNNxgmpc0ktX/AEUf8N3ft7/9Df8Ashf+Iy/Gb/6M2v1L/Yg+N3jn9oj9m7wp 8UviTbeFLbxte+M/jZ4M13/hB9J1fQfCt3L8J/jn8SPhNaarpOia94k8X6vpMes6d4Is9WudPvPE +ttaXt7cwRX80CREfzGfsf8Axc1P42fBzTvHms/Fb4WfFrVNSuNMmv8AUvhH4fvPDvh/wjfap4M8 JeI774farBe+NvHUt74l8L3uu3Eeo3rahpVzHa3Wn6Zqnh/TdZ07Ujcf0Mf8Esv+TMPCv/Zbf2x/ /WzPj/Xi8YZfldLh6hjcFgcLhqlTM8HTVShSo05ujVweZTnTlKi3GSlKjSk1zStKC1Tvf1OGsbmF TOa2ExeLr14QwGJm4ValScVVp4nAwjNKqlJOMak43srqT3vc/Q2iiivy0/QAooooAKKKKACiiigA ooooAKKKKAPDf2nvihrXwQ/Zq/aG+NPhuw0vVPEXwh+Bvxa+KGg6ZraXcmi6jrXgDwD4g8V6XYav HYXVjfSaXeX2kwW9+lle2d21pJKtvdW8xSZPx0/4bu/b3/6G/wDZC/8AEZfjN/8ARm1+oH/BQb/k wj9t7/s0L9pX/wBUz40r8PK/T+B8sy7GZbiq2LwWGxNVY6VOM69GFVxpxoYeajHnUlFc05N2Sbvr dJW+C4sx+NwuNw1PDYqvQg8LzuNKpKmpSdaonKXK1d2jFK97JO1ru/0H/wAN3ft7/wDQ3/shf+Iy /Gb/AOjNo/4bu/b3/wChv/ZC/wDEZfjN/wDRm1/MtZ/thfFzTf2qvHfxgD/EPSvgJ8Qde+Pn7Pnw u1b4r6tPo/7Jtr4o+FvhbTofhL4y0nULTU3uILzx38U/hN8ZbDxV4hTRbaJfCXirQ3tdTuRp8rW/ oHgL/goL8WdW1H9niPW/Evwo1ey8b+Pdd+GPj/S/DfhXwvdeN9a+IsHibwpoOnaT8O9C0r9prXbH xV8JC2uaxZ/8L6+GepfFS30i/wBMtpvGPw60WDTddtZPchDhqTknlGDVqsqcX9Sw9pRU6MKdZc0Y t06ka0KkWk/cVRvWLT8mUs+iotZliXenGbX1qteMuWpKdOVnJKdOVKUJJtXk420nc/op/wCG7v29 /wDob/2Qv/EZfjN/9GbXnGl/tP8A7bGk/F3xx8Z7bx1+y0/ijx98OPhZ8MNYsJ/2bPi02gW2gfCL xN8YvFfhu80y1j/a9j1GHWL7Ufjd4rh1y4utVvLK5stP8PR2Gn6ZPaalc6t/PH4V/wCCk/x61rQd MvG1T4E6tpXirwF+z14r8c/FTRfBvjCHwH+xr4n+NvxeTwB4i+H/AMbob/4iA6zrHw+8OLeasYfE OrfCS+XV7C5u9ehg8Py26Ll/HL9o+60Hxd8XPFPxI+NXiLxjdeHfCnwB1H9n/wANfDb48+Pf2SfA 3xe+HfivwTo974z+L3wNs/BkvxGsPjj41vfi5d6ron/CBeMLrxRomi+EbMxya9cQ2qx3TU+HYUak 6OV4H2daEadZywuGhB0lKWISnywqTnHnwcXH2VOonWVOlJxm6iinHPJVYRqZhinOlJzpKNevOXtG oUXy3lCCfJiXze0nF+z9pUSlHlcv6d/+G7v29/8Aob/2Qv8AxGX4zf8A0ZtH/Dd37e//AEN/7IX/ AIjL8Zv/AKM2vwY8SftZ/HvQdMl8QeJPH/wG+Gngbxh+2d8X/wBnHQviJ4v8CeJ5fDnwf8BfCHVf jxGPFPxD1GX4j6Po+veKfiBqHw+8LeCdBWe+8B+F9Fuphf3d5rGp6/DpeneO/DH/AIKafGTxVc/D PRfHfhr4c+BfGnxL8c/sU6Xofgy+0XxLpms6/wDD/wCO3xA8Z+FviR4+8L6Vq/iZtTuNFl0rRvC2 r+FtRcanp/heHxZpNprdxrt1qem3FzTpcMwnCE8qwcHNNx5sDhrNKEaivZNrnhKDhzJKbm4xbnCt GCVTP5Rco5jiZKLSdsVX6y5Ha9r8soyU7X5FFylaE4Sn/ST/AMN3ft7/APQ3/shf+Iy/Gb/6M2uN +I3/AAUg/by+HPw98d/EKfWv2Rtcg8CeDPFHjObRIf2dfjJpEusReF9Evtbk0qLVX/a91VNMk1BL E2iag+l6ktk0wuWsLwRG3k/Ez9gz9tb4s/tKfELTfD/jDW/hH4r0PV/gLe/EvX7f4aeE/Efh/WPg 7470f4mp4DsvAXje81bx34uh1G98c6B9r8b6Ss+leE7qO002e40qz1bQLqz1NvvX9pf/AJNw/aA/ 7Il8Vv8A1BNer0Mtyrh7MPq9SnlOBdGrWhBqWEoRbi5QT1gnvFrWMuaLbjLlmpRXDjsxzrBe1pzz HFqpTpymmsRVaTUXbSTV7OPWNpLVc0ZJy/rtooor8BP2MK+QvBf/ACfv+0r/ANmhfsQ/+rm/4KDV 9e18heC/+T9/2lf+zQv2If8A1c3/AAUGr0cF/u2cf9i6l/6tsrOPFfx8u/7DJ/8Aqvxx9e0UUV5x 2BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFAHyF/wAFBv8Akwj9t7/s0L9pX/1TPjSvr2vkL/goN/yYR+29/wBmhftK /wDqmfGlfXtejV/5FOC/7GOaf+o2TnHD/kYYr/sDwP8A6fzEKKKK847AooooAKKKKACiiigAoooo AKKKKACiiigAooooA/lu/am+KHhrwT+3B+2xpWs6Z8RL26ufi/8ACzUY5fCPwh+LHxA01beX9jv9 mC1WOfWPAfgrxJpFrfCS0laTS7q+h1OG3e1u5rRLS9sprjyP/hoDwJ/0Afjb/wCI0ftHf/Opr6g+ PH/J5/7b/wD2W34Y/wDrGf7K1cZX9JZXKgspybmp1nL+xcmu414RTf8AZmE2i8PNr0cn6n4bmCq/ 2lmnLOml/amZ2TpSk1/t+I3arRT+5HiX/DQHgT/oA/G3/wARo/aO/wDnU0f8NAeBP+gD8bf/ABGj 9o7/AOdTXttFdvNhv+fNf/wop/8AzKclq/8Az8pf+CZ//Lz5I+KXiP4DfGbQ9K8P/EHwZ8ftRstB 8S6V4x8P3eifBD9rrwT4h8PeKtEW6j0rxB4f8WeB/AvhzxToWq2cN9e26Xmk6zZyva3l3aytJbXE 0T6nw58dfA/4S+DNE+Hvw88B/Gbw14P8PJerpWkW/wCzh+07e+S+p6leazql3c3+qfDO+1PUtR1X V9Rv9V1TU9TvbzUdS1K9u7++uri6uJZX+o6KjkwKqOssLUVVx5HV9tR9o4XT5HP6pzON4p8t7XSd tEXzYpwVJ14umpcyp+zqcilZrmUPrHKpWbV7Xs2r6niX/DQHgT/oA/G3/wARo/aO/wDnU0f8NAeB P+gD8bf/ABGj9o7/AOdTXttFXzYb/nzX/wDCin/8ykWr/wDPyl/4Jn/8vPEv+GgPAn/QB+Nv/iNH 7R3/AM6mv3T/AOCT9/Bq37D/AIF1W1jvYrXU/i/+15qNtFqWm6jo2pRW97+2J8erqGPUNH1i1sdX 0m+SOVVu9L1WxstT0+4Elpf2ltdwywp+TNfcv/BO743/ABN8H/suaV4d8PfsdftHfFTR9O+Nv7XP 2Px74C8T/sjad4T177X+118c764/sqz+J/7U/wAOPHMP9l3V1Po19/bngzRvM1LTryXTP7R0d9P1 W++Q46oxxPD9OGHUaclnGBnJ4rG4WjBxWCzWNozxCwsOa8k+VTlJxvJR5Yya+l4RquhnM51nKcXl mKilQwuIqzTeKy93caPt5ctk7ycVFOycrtJ/s3RXyF/w0r8Zv+kfP7Xv/hafsEf/AEb1H/DSvxm/ 6R8/te/+Fp+wR/8ARvV+Qf2Zif8An7l3/h3yn/5t8/z7M/S/r9D/AJ943/w3Zh/8y+f59mfXtFfI X/DSvxm/6R8/te/+Fp+wR/8ARvUf8NK/Gb/pHz+17/4Wn7BH/wBG9R/ZmJ/5+5d/4d8p/wDm3z/P sw+v0P8An3jf/DdmH/zL5/n2Z9e0V8hf8NK/Gb/pHz+17/4Wn7BH/wBG9R/w0r8Zv+kfP7Xv/haf sEf/AEb1H9mYn/n7l3/h3yn/AObfP8+zD6/Q/wCfeN/8N2Yf/Mvn+fZn17RXyF/w0r8Zv+kfP7Xv /hafsEf/AEb1H/DSvxm/6R8/te/+Fp+wR/8ARvUf2Zif+fuXf+HfKf8A5t8/z7MPr9D/AJ943/w3 Zh/8y+f59mfXtFfIX/DSvxm/6R8/te/+Fp+wR/8ARvUf8NK/Gb/pHz+17/4Wn7BH/wBG9R/ZmJ/5 +5d/4d8p/wDm3z/Psw+v0P8An3jf/DdmH/zL5/n2Z9e1kL4h0Btfl8KLrmjt4oh0eDxDN4bXU7I6 /FoFze3Gm22uS6OJzqMej3Go2l1YQam9sLKW9tri1jnaeGSNfln/AIaV+M3/AEj5/a9/8LT9gj/6 N6vJ/il4k1b4y2+lDx//AME0P2t9Q1fw7NNd+EfGOkfEP9h3wr8Q/A2oXCeVNqfgP4ieFv27NG8b eCtSmiHk3F74Z17S5ru3L2l209pJLA+lHK5uoliK+DhTaac6WaZPVnF20apzzGlGavo4+1ptJtqX uuLirj4qDdGliZzTVo1MBmVOMl1TnHBVHB63T9nNaWaWrj6z/wAFBhn9gn9t4cc/shftKDkgDn4M +NOpOAB7kgDvX853/DQHgT/oA/G3/wARo/aO/wDnU19V/tt/tb/tQfCL9n39oL4DeNP2fvjz8RPC XxW/Zn+P2h2GofFHWv2Rk+Pfwt8L6h8LfFulXvxF8VWX7OX7QnxPf4mfCvwi88KeIPFd98Jvhpc+ GtOglvfEfjzxz4jure0veBr9c4My2WWZXV+syo4mlisZUrYWvgcbQqU6lNUMPTm5csK04SU4uHLU hSd4uUPaU5Rm/wA44px0cdj6PsFVoVKGGjTr0sXha1OpCcqtScUuaVOMk4NSvCU0lJRlyTUorxL/ AIaA8Cf9AH42/wDiNH7R3/zqaP8AhoDwJ/0Afjb/AOI0ftHf/Opr22ivrubDf8+a/wD4UU//AJlP mbV/+flL/wAEz/8Al54l/wANAeBP+gD8bf8AxGj9o7/51NH/AA0B4E/6APxt/wDEaP2jv/nU17bR RzYb/nzX/wDCin/8yhav/wA/KX/gmf8A8vPEv+GgPAn/AEAfjb/4jR+0d/8AOpo/4aA8Cf8AQB+N v/iNH7R3/wA6mvbaKObDf8+a/wD4UU//AJlC1f8A5+Uv/BM//l58u/Drx78E/hP4K0D4d/D/AMEf Gvw94N8LWkljoOip+zt+1DqS6faS3VxevCt7rHw21DUp1NzdTyKbq8nZA4jRliSNF5X9oT44eDNX +Afxw0m00X4vxXWqfCD4l6dbS6p+z38fNE0yK4vfBmtW0Mmo61rXw0sNH0ixSSVWu9U1a/stMsLc SXd/d21rFLMn2ZXiX7S//JuH7QH/AGRL4rf+oJr1a4T6rCvhoQoVYRjVoxhFV6ahFKcVFKKw0Uox SSUVZWVlYzxH1iVKvKdWnJyp1ZSbpTcpNxk5Nyddtybu23fXV3P67aKKK/ls/oEK+QvBf/J+/wC0 r/2aF+xD/wCrm/4KDV9e18heC/8Ak/f9pX/s0L9iH/1c3/BQavRwX+7Zx/2LqX/q2ys48V/Hy7/s Mn/6r8cfXtFFFecdgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB8hf8FBv+TCP23v+zQv2lf8A1TPjSvr2vkL/AIKD f8mEftvf9mhftK/+qZ8aV9e16NX/AJFOC/7GOaf+o2TnHD/kYYr/ALA8D/6fzEKKKK847AooooAK KKKACiiigAooooAKKKKACiiigAooooA/lu/am+L3wn+H/wC3B+2xo/jz4ofDvwTq918X/hZqlrpX i7xr4a8N6lc6ZN+x3+zBaQ6jBY6zqdldTWMt3ZXtrHdxxNbvcWl1Cshkt5VTyP8A4aX/AGcf+jgP gl/4dbwJ/wDL6vqD48f8nn/tv/8AZbfhj/6xn+ytXGV/SWVyoLKcm5qdZy/sXJruNeEU3/ZmE2i8 PNr0cn6n4bmCq/2lmnLOml/amZ2TpSk1/t+I3arRT+5HiX/DS/7OP/RwHwS/8Ot4E/8Al9R/w0v+ zj/0cB8Ev/DreBP/AJfV7bRXbzYb/nzX/wDCin/8ynJav/z8pf8Agmf/AMvPEv8Ahpf9nH/o4D4J f+HW8Cf/AC+o/wCGl/2cf+jgPgl/4dbwJ/8AL6vbaKObDf8APmv/AOFFP/5lC1f/AJ+Uv/BM/wD5 eeJf8NL/ALOP/RwHwS/8Ot4E/wDl9R/w0v8As4/9HAfBL/w63gT/AOX1e20Uc2G/581//Cin/wDM oWr/APPyl/4Jn/8ALzxL/hpf9nH/AKOA+CX/AIdbwJ/8vq/dP/gk/qWnaz+w/wCBdY0e/stW0jVv i/8AteappWq6bdQX2m6npmoftifHq7sNR0++tZJbW9sb20miurS7tpZbe5t5Y5oZHjdWP5M1+uf/ AASy/wCTMPCv/Zbf2x//AFsz4/18V4guk+HKXs4VIv8AtrA356saia+o5tso0qdvVt+h9VwYqizu pzyhJf2Xi7csJQd/reXbt1J39LL1P0Noor5r8d/tB33gj9pX4E/s/SfDTWr3SvjboPxG1a2+Kkni Hw7aeH9J1P4faFNr1z4YsvDkNxqHizV9WNnDDcavealp3hjw/p9prWhNoes+K9RbxHpfhn8VP1M+ lKK+a/2vPjzr/wCzN+zv8Tfjd4Y+GGv/ABi1vwF4evdasvh/4bN7DqGsNbW8s0s1xqNtpOq2mi6N pUMb6r4g1zWjp2j6Volnf3dxqUc8drbXXsfw88VXfjnwF4M8Z3/hvW/Bt94r8L6F4ivPCPiWx1DT PEXhe61jTba/uPD+u6fqun6VqNlq+jyzvp+o213p1nNFd28yNCoAyAdjRRRQAUUUUAFFeYfGv4qa P8D/AIRfEr4w6/peta7pPw08FeIvGd3oPhu1jvfEXiAaDplxfwaBoFrPNbW02ta5cww6VpS3l1Z2 IvryBr69s7QTXMXnvwE+OniD4oa98Xfh38Q/AmkfDf4s/BLxH4W0bxn4a8NeN7j4j+E7vS/HXgnR fHXhDxL4Y8Y3vg34e6lqWn31lql/oWo22q+C9BvdO8T+GNftbeLU9FXR9f1cA+ka8P8Aij4c+OHj LV9P8M+A/HHh34UfD6400TeLPH+l2X/CUfGK4vJLqeKTw94D0XxDosvw88GKlmlpd/8ACf8AiRPi RNK11e6Ra/DrS7i2s/FTeWeHf2ofFWuftkfET9lyf4F+PdN8KeCfBPg3xZp/xzn03xF/wg+u3HiT SdW1C60lZ28LpY2kou7NtI0DVG1WTwtrt/4d8daXb+Jx4u8NzeDz9h1rRquhUVSMKc5RT5fa041Y RbVub2dRSpza1sqkJxT15bpNZ1aaqwcHKpGLa5vZzlTk0nfl54NTin1cJRk1pzWbT/PD9rT4L/Dr 4O/8E+v28bTwLoBttT8Rfsm/tH6j4v8AF2r32oeJfH3j3WYvgp40gj1vx3451+51HxV4w1eOE/Zr W713Vb06fYrDpmmJZaZbWtlD+EP/AA0v+zj/ANHAfBL/AMOt4E/+X1f0Yf8ABQb/AJMI/be/7NC/ aV/9Uz40r8PK/X+AK3tcsx1XFOtXqTzGTc3WtNtYXCr35VKdVy0UVH4eVRtqrJfm3GVL2eNwdOgq VGEcEkoKleKTr1n7qhOmo6tt73bvve/iX/DS/wCzj/0cB8Ev/DreBP8A5fUf8NL/ALOP/RwHwS/8 Ot4E/wDl9XttFfd82G/581//AAop/wDzKfH2r/8APyl/4Jn/APLzxL/hpf8AZx/6OA+CX/h1vAn/ AMvqP+Gl/wBnH/o4D4Jf+HW8Cf8Ay+r22ijmw3/Pmv8A+FFP/wCZQtX/AOflL/wTP/5eeJf8NL/s 4/8ARwHwS/8ADreBP/l9R/w0v+zj/wBHAfBL/wAOt4E/+X1e20Uc2G/581//AAop/wDzKFq//Pyl /wCCZ/8Ay88S/wCGl/2cf+jgPgl/4dbwJ/8AL6vIP2hP2hPgHrfwD+OGi6L8cPhBq+sav8IPiXpe k6TpfxL8GX+p6pqd/wCDNatLDTtOsLTWpbq9vr26litrS0topbi5uJY4YY3kdVP2ZXiX7S//ACbh +0B/2RL4rf8AqCa9W+GlhvrOHtSrp+3pWbxFNpP2kbXX1ZXXldX7oyrqt7GtepSt7Kpe1GaduR7P 2zt62fof120UUV/LJ/QQV8heC/8Ak/f9pX/s0L9iH/1c3/BQavr2vkLwX/yfv+0r/wBmhfsQ/wDq 5v8AgoNXo4L/AHbOP+xdS/8AVtlZx4r+Pl3/AGGT/wDVfjj69ooorzjsCiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA PkL/AIKDf8mEftvf9mhftK/+qZ8aV9e18hf8FBv+TCP23v8As0L9pX/1TPjSvr2vRq/8inBf9jHN P/UbJzjh/wAjDFf9geB/9P5iFFFFecdgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfzZfHj/ AJPP/bf/AOy2/DH/ANYz/ZWrjK/fTx9+x5+yR8VvFep+PPij+y1+zn8SfHGtixXWfGfj74I/DPxh 4r1ddM0+10jTV1PxF4h8Majq9+NP0qwsdMsRd3kotNPs7Wyt/LtreGJOO/4d8/sEf9GQ/shf+I1f Bn/5i6/VMHx5llDBYDDVMJjnUwuAwOEm4Rw8oSnhMJRw0pxcq8Jcs3ScopxTSaT1uz89xXCGOrYv F14YnCKGIxmLxMVJ1lKMcRiKleMZJUpLmiqnK7NptXTs9Pw8or9w/wDh3z+wR/0ZD+yF/wCI1fBn /wCYuj/h3z+wR/0ZD+yF/wCI1fBn/wCYuun/AIiBlP8A0CZj/wCAYb/5p9f6emH+pmYf9BOC/wDA q/8A8o9f6en4eUV+0Pi//gnx+xo3hPxOvgP9iX9iKHxwfD+sjwbL4t/Zj+FV14Vj8VHTrn/hH38S 22keFbHVrjQF1b7IdYh0y8tdQk08XCWdxDcGORfPPgJ+y1/wT5+OXw00fxvF+wV+yb4W8QxXWp+F /iF4D1X9m/4Kya58OfiV4VvZdF8deA9bMXgsJJeeHdftbu2tdQhH2HX9HbTPEmjyXOiazpt3cbLj nLZUJ4mODzB0qdWFGo1HC80J1IylTco/Wb8tRU6qjJXXNTcZOLlHmzfCWNVaNB4rBqpOnKpBN17T jCUI1OV+ws5Qc4txdnaSauubl/KGiv3D/wCHfP7BH/RkP7IX/iNXwZ/+Yuj/AId8/sEf9GQ/shf+ I1fBn/5i6x/4iBlP/QJmP/gGG/8Amn1/p6af6mZh/wBBOC/8Cr//ACj1/p6fh5X65/8ABLL/AJMw 8K/9lt/bH/8AWzPj/XqH/Dvn9gj/AKMh/ZC/8Rq+DP8A8xdfR/gT4f8AgP4W+FNJ8B/DLwT4R+HX gfQReLofgzwJ4b0bwj4U0VdR1C71fUF0nw74fstP0jThf6rf32p3gs7OEXWoXt3ez77m5mlf5/ib ivBZ1lcMBhsPiqdRY/D4tzrqjGHJRw+MouC9nVqScpSxSaukkoPq0l7OQ8O4rKsfLF16+HqQeDrY ZQpOo5c1Wthaqk3OnBKMVQkurbknpqddXy/8Uv2cNR+JXx9+Bfx2h+L/AIx8It8CP7e/sXwHo/h/ wHf+HPEP/CYxHTPG39u6jrvhvUvEqf8ACSeGo7Pw/wD8SrWLD+x4rRdS0j7Lqk091J9QUV8EfYHm ngDwV4x8JMh8U/GLxr8UkXwP4E8Msvi7QPhjozSeJ/Cx8Sf8JT8R2f4eeA/BQHiL4mDWNGHiXRUR PBWiHwlpR8DeGfCw1HxCNX9LoooAKKKKACiiigDzL40/Cnw78dfhH8S/gz4svte0rw38UfBHiXwL rGr+Fb+DSvFGjWfiXSrrS31rw1qV1Z6laWHiHR2uV1PRLy803UbO31O1tZbvT762SW1m8E8F/so+ KvBV98TfFOn/ALUHxjm+JHxf/wCEhuvHfj2Xwp8AWu7vWW+Gnhb4ZfDHU9I0O4+Dt1oOjW3wXs/D Eni3wdoEFlLoPiDxr4p8Xah8SNP8a6Lqdj4e0r7IooAigjeKGGKSeW5eOKON7mcQrNcOiBWnmW2h t7dZZSDJIIIIIQ7ERQxptRZaKKAPkL/goN/yYR+29/2aF+0r/wCqZ8aV+Hlf01a/oGheK9C1rwv4 o0XSfEnhnxJpOpaB4i8O6/ptnrGha/oWsWc2navoutaRqMNzp+q6Tqun3NxY6lpt9bz2d9ZzzWt1 DLBK6N8sf8O+f2CP+jIf2Qv/ABGr4M//ADF19xwxxRg8kwdfC4rD4mrKpinXjOgqUlaVKlTcZKpV ptNeyumuZPmtpbX5TP8AIMTm2Jo16FahTVOh7KUarqJ3VSc01yQmmmp21tZrrfT8PKK/cP8A4d8/ sEf9GQ/shf8AiNXwZ/8AmLo/4d8/sEf9GQ/shf8AiNXwZ/8AmLr6X/iIGU/9AmY/+AYb/wCafX+n p4P+pmYf9BOC/wDAq/8A8o9f6en4eUV+4f8Aw75/YI/6Mh/ZC/8AEavgz/8AMXR/w75/YI/6Mh/Z C/8AEavgz/8AMXR/xEDKf+gTMf8AwDDf/NPr/T0P9TMw/wCgnBf+BV//AJR6/wBPT8PKK/cP/h3z +wR/0ZD+yF/4jV8Gf/mLo/4d8/sEf9GQ/shf+I1fBn/5i6P+IgZT/wBAmY/+AYb/AOafX+nof6mZ h/0E4L/wKv8A/KPX+np+HleJftL/APJuH7QH/ZEvit/6gmvV/Rh/w75/YI/6Mh/ZC/8AEavgz/8A MXSr/wAE+/2CkZXT9iL9kNWUhlZf2bPgyrKynIZSPBYIIIBBBBBGRV0vETKqVWnU+p5hL2c4T5eX DK/JJStf6w7Xs1eztvYmfBWYThOH1rBLnhKN713bmVr29ir2u9Lq9t1fT68ooor8fP0sK+QvBf8A yfv+0r/2aF+xD/6ub/goNX17XyF4L/5P3/aV/wCzQv2If/Vzf8FBq9HBf7tnH/Yupf8Aq2ys48V/ Hy7/ALDJ/wDqvxx9e0UUV5x2BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHyF/wUG/5MI/be/7NC/aV/8AVM+NK+va +Qv+Cg3/ACYR+29/2aF+0r/6pnxpX17Xo1f+RTgv+xjmn/qNk5xw/wCRhiv+wPA/+n8xCiiivOOw KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK+efGuofCH9my78W/GjVdG1PQYvi 545+GWhfE7xPpLX13oFprd4bH4b+E/HvjHTJtTTSPD+n20M/hrwr4q8cWGnJdJo1n4Zl8VTy6B4X hvtG+hqwPFfhbw7458MeIvBfi/RrDxF4U8XaHqvhrxNoGqQLc6brWg65Yz6Zq+lX9u3yzWeoWFzP a3EZxvilcZBORvh6sadRKq6rw1VwhiqdGfJOrQVSFSUE37ralThUpqopQVWFOUovlMa0JTg3TVNV 4KUsPOrDnjTquEoKTWkknGUoTcHGTpznFNXN+ivHfgv4X1T4WeBvCfwl8W/EsfEbxJ4b07XLfw/r WsrDZeM9a+Huha6bDwrP4ihk1K+uvEeveGvDOo+E/DvjPxtFHaQeJfEmdeudO0i416PT09iqK0I0 6tSEKiq04zmqdaMZwjWhGTjGrGNSMZxjNLmSlFSV7SSaaLpylOnCU4OnNxi503KMpU5uKk4SlBuL cb2bi2nunZoKKKKzLCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACvkLwX/AMn7/tK/9mhfsQ/+rm/4KDV9e18heC/+T9/2lf8As0L9iH/1c3/BQavRwX+7Zx/2 LqX/AKtsrOPFfx8u/wCwyf8A6r8cfXtFFFecdgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUV+cX/BSn4vfF34T+AfgFB8HPiRq/wr1n 4l/tFQ/D/wAReK/D/h74f+I9bTwrbfAP4+/EiTT9NtPiX4N8eeF7aS88RfDzw2Lm9l8OXN6unx3l rZz2j3TTr3ZbgKuaY7D4ChOlTq4iUoxqV3ONKHLCVSUpulTq1ElGD+CnOTdkkcmOxlPL8JWxlaNS dOhGLlCkoOpLmnGCUFOdOF3KS+KcVa7ufo7RX82X/C9/2z/+j3/jb/4bH9jP/wChWqpJ+0P+2BFf Wuly/t2/GKPU721vb2y06T4dfsWpfXdnpsllDqN3a2jfssi4uLWwm1PTYr24ijeK1k1CyjneNruA SfZPw6zVb5nkq2WtXM927Jf8irq9F5nzH+u2Xf8AQBmn/gvAdN/+Zgf0sUV/NfL8fP2y4Y5Jpv24 /jVFDEjyyyy/DP8AYyjjijjUs8kjt+yuFREUFndiFVQSSACagsP2hv2wdUsbPU9M/bs+Meo6bqNp b3+n6hYfDn9i68sb+xvIUuLS8s7u3/ZZkgurS6gkjnt7iCR4Z4XSWJ2RlYn/ABDrNf8AoZ5L/wCD cz/+dXmg/wBdsvtf6hmltr+zwFr9v+Rgfs1/wUG/5MI/be/7NC/aV/8AVM+NK+va/mD+IXjv9qP4 qeAfHHww8e/tlfG3XvA3xH8IeJfAXjPQ/wDhX/7Iul/2z4T8YaLe+HvEWlf2no37MWnaxp39o6Pq N5Z/btK1Cx1K0877RY3lrdRxTp0Gp/tGfteaLZyajrH7ePxe0nT4pLaKW+1P4efsV2FnFLeXMNla RyXV1+y1FAkl1eXFvaWyM4ae5nhgiDSyojdVTgHMngcPhv7SydTo4rG4icnUzJQ5MRRwFOCT/sy/ NF4Wo53ikk4NSk3JRwhxjgFiq1b6jmbjVoYajGKhgXPno1MVOV19ftZqvBRs221K6Vk3/S5RX82X /C9/2z/+j3/jb/4bH9jP/wChWo/4Xv8Atn/9Hv8Axt/8Nj+xn/8AQrVy/wDEOs1/6GeS/wDgzM// AJ1G/wDrtl3/AEA5p/4LwH/zwP6TaK/my/4Xv+2f/wBHv/G3/wANj+xn/wDQrUf8L3/bP/6Pf+Nv /hsf2M//AKFaj/iHWa/9DPJf/BmZ/wDzqD/XbLv+gHNP/BeA/wDngf0m0V86/sgfEDxV8WP2S/2X fin461CPVvG3xL/Z1+CfxA8Y6rDZWWmxan4q8ZfDTwz4j8Q6hFp2mwWunWEd5q+pXlyllYWttZWq yCC1ghgjjjX6Kr4XEUJ4bEV8NUcXUw9arQm4NuLnSnKnJxbUW4uUXytxTatdJ6H1tCrGvRo14KSh WpU6sFJJSUakFOKkk2lJKSuk2k9m9wooorE1CiivCPDf7TPwP8XfFTVPgv4d8dQ6j8QdJm8U2bWS 6F4otvDur6r4Em0m28f+HvCfj680S38AeNvFPw8vNb02w+IfhTwf4n13xJ4D1GabT/F2l6Ne2V9B bAHu9FeJ/GL9oz4MfAGfwPb/ABf8cWXgl/iRr0nhbwQ2oafrV1D4i8TrHA9v4b0+fTNNvoZPEWqy XVva6BoJddY8R3khtNCstRuIbmOH2ygAooooAKKKKACiiigAooooAKKKKAPmH9pn4YeKvEmmeE/i 58JbO3n+PXwG1LUPF3w3tJ7qLTrbx3omo2sNn8RvgpreoTfuLfQPiz4btV0u2u70vp/hrx9pfgHx 9PBcTeDLaF/pDS72TUdM07UJbC+0qW/sbS9k0vVFtk1PTZLq3jnew1FLO5vbRL6zaQ292treXdst xHIILmeILK96vlHxZ488VfBv9ofw2PF+t3Wp/A39oN9F8D+Grq+EPk/Cb49aba3EWh+H3uo4Y3i8 HfHHQ4BY6M19KY9H+KvhuDR4Jru9+LGl2Wnd9L2uNowwi9m54SniKuH5ub21SneNarhKctYOMP8A aMVSpyUW6ksRGnKdWtCnLjqezwtSWIfOo4ipRp1rW9lCdnSp4ia+JOX7nD1JrmSiqLmo06Upx+rq KKK4DsCiiigAooooAKKKKACiiigAooooAKKKKACiiuQ+IPj3wh8K/AnjP4m/EDW7fw14F+HvhbXv GnjHxBdxXdxb6L4Z8MaXdazrmqS21hb3d/dLZabZ3NwLWwtLq+umjFvZ2txcyRQuAdfRXjfwb+PH w/8AjpaeL5fBR8Wafqnw/wDE8Pg7xz4U8feA/GXw18aeFdfvPDHh7xrplrq/hTx3omga3Fbax4R8 WeHPEGlalDaT6ZeWmp/Zkuxqmn6tYafwei/th/AnXv2o/GP7HOn+IdcPx28EeEtD8aax4euPB3im 30qTRda086s01h4ik0oaRcwaTpd14fuNQ1d7iHw5cXvijTPDmh61rPivTPFug+GgD6gooooAKKKK ACivl79uDxN4h8F/sWftfeMfCOt6p4a8V+E/2Xvj/wCJvDHiPRL2403WtA8Q6D8KPFuqaLrekaja PFdWGqaVqVrbX1he20kdxa3cEU8LpJGrD+cjxv8AEHQPhmukv8SP2wf2gvh+uvXE1pobeN/+Cgn7 TXhRdZu7cQm4tdJOvfHywGo3EAubczQ2ZmkiFxCXVfNj3fV5Fww86wlfGSx9PB06Nf2Fp0XUvJQp zcm3VpRiv3sYx1k5SunbS/z2b58sqxFHDLCTxM6tL2vuVFCy55Rsl7Oo5P3JN7JJLe7t/WxRX8r8 Vl4pmjjmh/aA/a6lhlRJYpYv22f2uJI5Y5FDJJG6/G0q6OpDI6kqykEEgg0ktp4ogUPP+0D+1zCj SQwq8v7bX7W8ama4mS3t4gz/ABtAMk9xLFBDGDulmkSJAzuqn3v+Idz/AOhvD/wif/zV6/09PH/1 2h/0Lp/+FS8v+nHr+HfT+qGvkLwX/wAn7/tK/wDZoX7EP/q5v+Cg1fgZrVzqvhvSNT8QeIv2kv2q tB0HRLC61TWdb1r9uX9rDS9I0jTLGF7m91HU9SvvjjBZWFhZ28ck91eXU0VvbwxvLNIiKzDzDwb4 0+GHjTxQviD4eftZfGTxb4w8baFPov8AwkXgr9vT9o3xBrninw58Kb8X8uhy69oXx1vLvV9L+Hup fFx9QTR5bye38M3XxGu76G1s5PE93NedFHgZYenjKM83p8+MwsKEF9UScWsdg8Rzcrxd5J/V3TVv tzj5oyqcXOtPDVI5bU5cNXlVm1iLpp4XEUWrrD2TXtud3suWL76f1/0V/LF/Z3i7/ovn7Xv/AImt +11/8+yj+zvF3/RfP2vf/E1v2uv/AJ9lYf8AEO5/9DaH/hE//mr1/p6af67Q/wChdP8A8Kl/8o9f 6en9TtFfyxf2d4u/6L5+17/4mt+11/8APsry34za78Q/CHwU+K3jzwj+0Z+1rb654X+Fvjrxd4Y1 UftmftUaxaQatovhLVNZ0XUPsOp/GPUNH1S3ivLa2ufsuoWd7pt9Evk3dtc2sskT1Dw4q1Jwpxze nzVJRhHmwUkryairtYltJN6tJu3R3sKXHFOEZTeWz5YRcnbExbsld2vQSbsnZNq9lqru39d9FFFf mZ92FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABX5 Rf8ABWL/AJFH9kH/ALO9k/8AWRf2tq/V2vyH/wCCwmq3+ifDj9k7VNM8Na34wvrX9r2PyPDnhyfw 5a61qXn/ALKH7V1tKLKfxb4g8LeHozZwzSX9x/aOvWAa0tLhLQ3V+1rZXP0nCCb4jyxK13UrpXai rvC11rKTUUu7bSS1bSPC4ldsjx7d7KFF6Jt6Ymjskm2+ySbfRH8c3gf9mz9pP4VeFfjJ+1J4H0PW /AfxL0T4xftDRab4V8D/AA88Rah8ZfjP4P8AHX7ZGmaw+r+P9K1i3v7Pxj4b8OfCPRtVv/hbpOje GdR1C90zxEmp2GpQvYWFrdv+I/jT9r/xX4l1H4vJpn7WHhy98KeKP+ChumfAzVvBv7NV7d+Kl8D6 hp37Nut/s3eEPEfhDxD8JNa1bR/B3j3xNoV7Z/2trfha38XXUWm6xY6vreiabpnijU9D/aH/AIWt 47/6No+Nv/g+/Zx/+iAo/wCFreO/+jaPjb/4Pv2cf/ogK/X/APVyUaapUcc6MOWi5KOMoWnWo1Iz VdqOJgozlyxjNQUb8kZ83PzOX5ss7i5upVwiqyvVUXLD1bxpVYcjpXlQk5Ri3KUXLmtzSjblsl+L Op2X7Z2mX/xvtPEvhr42eBtF+NXxA8R6p8Tr/wCEXwjuviHqGteNR+wt8CNI8KeH9AjPg/x9BZ/C 3X/jJYeOvC3iLxZpGkPo8Oo6NBpeo+LfDttPdalXp/7P2tftt+G9f+BXw6dPiB4A8CeCfgn+zfpO m+FPEHwm8ZXnhLXvC1l+yroE3xH0TU9S0r9nfxNY+Gfinofxgt9RsbeXx98evhzcabceHrPwofAe pw64JtY/Vf8A4Wt47/6No+Nv/g+/Zx/+iAo/4Wt47/6No+Nv/g+/Zx/+iAqocP1YVFUjmE1aq6lv rtBNxlNznSbjiIr2cpv2jUYxTq+/NTVoqZZzTnBweChrSVO6w1WycYqMaiUqEm5xiuS8pNqn7sHB rmf5JeJNI/bW1n4Z+DIPiL8T/wBqfU7K68Of8E7fj74o1Lwh8GvDtr8QvAvi/Wfiz4hsP2iPh7ou i+Dvg1e3niKHwB4Y0/wp411fwFf+EvEnjDRNY0DStS8QRX+k63r2ka940PgL46muv28NQuvhd4p1 Hx941/aZv9b8Afaf2R/ivb/EDxH8N2/aU+A/imPxVpf7RRtI/AeqeErnSdG8QaifhjpehWWswx2N 14liuYtK068tZv3S/wCFreO/+jaPjb/4Pv2cf/ogKP8Aha3jv/o2j42/+D79nH/6ICpnw458vPi1 UtTnTvWxlKrL3414uSlLF/FFV/d5lKK5EpKS5VFwzvkvyYb2d5xlalhp04+7KhJRcY4fZuj71nFv mdnF3cvy08QfEb/goPcaj8eDo+pfFHQ/EOmeKPGFhoXhiH4Qa74k0mz8O237Unw28P8Aw28SfCjU 7n9mTRfh1qFvbfAq88TX3inTbr42/GfV/E9nqmo+I7vRtCPhW9bR86XxH/wUo8G3HxCuPD3ib41f EefQ/HP7bHw18B6L44+E3w8g0zWvCHgX4XXHjD9nT4o3useHfhV4be98QeIPH0i+GND1hJU8F+M7 aGy0G08LXeoJe3Gofq5/wtbx3/0bR8bf/B9+zj/9EBR/wtbx3/0bR8bf/B9+zj/9EBWryLESabzS umuWzjmFKKtGo5tuP1lwcpK0ZPlUXa/IrtELN6KXKsBRcXzXUsHOTvKEY6S9gpqMWnKK5rxv8TaT Pza8M6z+2143sPAPhuy+Jnxw8O+HPE3xD+LcGseM5/g7c23xJ8I+GPD/AOz5ofifwvpHivUviz+y n8FtKntdW+M0d/aaPr+j/Cixs9RsdcvPAmjeLNU1bRYr/SfRf2D7b47SfF/4u+K/jxqfx4TxB8Rf hL+zV43TRPG3w/8A+Ea+GI8Raj8D/hyvxJh0q+s/h5oWlaD4w8IePhrXhmTwN/wklprFlZvq8use HdTu7F9ZsfuD/ha3jv8A6No+Nv8A4Pv2cf8A6ICj/ha3jv8A6No+Nv8A4Pv2cf8A6ICrpZLWhVo1 Z411ZUajqck8bSdOX7j2Cj7N4qSiledRNX96bTvFJGdTM6c6dWnHCxpqpBQ5o4WamrVlVvzrDptv lhB7e7G6s22/6MP+CfP/ACYR+xD/ANmhfs1f+qZ8F19e18h/8E+eP2Cf2IRkHH7IX7NfIzg/8WZ8 F8jIBwfcA+oFfXlfgmbf8jXM/wDsYY3/ANSap+w5b/yLsB/2BYX/ANMUwooorzztCvyj0H9mr9qH wr468G6nY+D/AIMat4f/AGff2h/24f2kvhzcj4s+KPCV98Yda/av8c/GvxB4U8D+ItNsfg94gtvh 7YeEfDX7QHi2Lxrr88/jZ9c8deDPCepaTpbaf4j1XUfC36uUUAeA+I/gx4K+OjWt5+0X8DfhP4jv vAvjDxdF8OP7Smg+JanwdeXlpFY6tfS694L8M/2JdeMrPStF1Pxd8O1h8SeHLPVdG0Pzte8U3Gha Vqdp79RRQAUUUUAFFFFABRRRQAUUUUAFFFFABVW8sbHUYVttQs7W/t0ubK8WC8t4bqFbzTbyDUdO ulinR0FzYaha2t9ZThRLa3ltBdQPHPDG62qKabTTTaad01o01s0+jQNJppq6ejT2a7M8J+DXxjuf iJq3xQ8DeLdBt/BnxR+EXjW90DxV4Uh1F9UtbvwnrM93qvws+Ivh+/ntNPn1Pwv8QfBotrtLv7DF HpPjLS/G/geWS41LwbqMze7V43428IeAPDPi6f8AaW1i31+18R/Dr4V+NPD+s3fhi11fVbrxD8Ph PZeMrzR9S8J6FZahqfjW/wBC1DQJ9R8EWFjY3uuadqOs+IbHw7C0nivVbPUPR/C3ifw9428M+HfG fhLWLDxD4V8W6HpPiXw1r+lzrdaZrega7YQano+rafcp8lxZajp91b3drMvyyQTI44NdWJjSny4j DUalOhNQjUi4ydKjiuW9WjSqylNzg2vbUozk6kKU1Tm6kqcqs+eg6kb0a9SE6sXJwknFVKlDm/d1 J00o8slf2dRxXJKcXOKgpqnHdooorkOgKKKKACiiigAooooAKKKKACiiigArw/8AaY+FWr/HH9nv 40fCDw7rtl4X8S/EX4a+L/CvhjxJqdh/auk6D4o1TRruDw3q+saVjdqui6frhsLrWNMiaKfUNMiu rOC4tppo7iP3CigD4G8B/Cn9qrwd4t+Ofxlh0P8AZ2g+Kfx61SK81XwvJ8QfidrngzwZpnwx+Bae Dfgxo1n4uX4Y+GtV8XHW/itBd678RNUl8C+Dp/D/AIH8UXOl6Ba+K9Z8L2F1rv2dp/gvwrZ+IdS8 cR+EvDVh448RWOg2niTxJYabZNrOqR+HLbVrfRLS9137DaajqlvocPiDXbTSJbtY3t7PVL6KKG2i u5YK6uigAooooAKKK8Z+IXx38BfCbxLoeifEqTWPBmg+I4LZNL+J2t6W8Pwpj166v5dPg8JeIPHM Ms+meCvEN3J9jbSR43HhzRvEk+qWOkeF9Y1rxB9r0i00pUatefs6NOdWo02qdOLlOSiry5YK8pNJ OTUU2opytZNrOpVp0Y89WcacLpOc2oxTk7Lmk9IpuyTk0rtK92k/KP8AgoN/yYR+29/2aF+0r/6p nxpX8cv/AAUf/Zf+NP7SXjf9nVfhFDptinhHwj+1Ta634s1zQfBnivQtA1fxn8KtK0rwRpmreHPG U/2e6tvGGuWMnh06tp9ldXvhoXL65bz6deWdlex/2M/8FBGWT9gf9txldWR/2Qf2k2VwdyFW+DHj QhwVzuUgggrnI5GeK/nQ/wCFreO/+jaPjb/4Pv2cf/ogK/U+B8DDMchx+GqS5acszjKTVenQn+7p 4KtFQnUlF6ypJScPeino4ycZH5/xZi5YLNsFXhHmmsDNRTpTrQ/eSxFJuUYxknaNRuKl7ra1Ukmj 8w/h98Nv2v8ARfGXwD0rRvAvx58B6D4Z1D9j3TdHs5fjJ4Zm+DHw0/Z98D/B/wAPaV8f/ht8QfB2 leO4bXxn8Rr7xhYeKtKsvEcngPxdqGoyzeDb/wAP+IPDGk217KnmHiP4J/trfFb4baboHxN8E/tK mL4b/Bf9kzR9W8PwfHjw/bat8TPjH8I/2nIvEvxV8Z+HL7QfjKLXWNX1P4Xyy6vo/iTxbq3h/U9U 1rw94bumnTU9E8NXC/sX/wALW8d/9G0fG3/wffs4/wD0QFH/AAtbx3/0bR8bf/B9+zj/APRAV9fL h2MoOEsXUcJKspQ+uYBRarRUbONuVqnZez00iowfNCMYr5pZ3KMlNYampRdJxl9WxbknSlzaSvf3 9efXVuUlaUnJ/kJ8Y/gH+298SdG/ay8NXf8Awu26sPF/w3/aG8P/AA38E3mv6F4g+H3jLwD4q+GI 0T4N+Bdd1nxB+03qGi6D4+8Nas1lJqut6L8E7fxNrXiyDW28S/E7xN4b1V9absvFPwP/AGpm+Hnw +vfgb4U+JHhj4jeEPhF+0d4Zutb8caL+z98NvFaa1418XfsqXUUGiaf8E9a8OeEPtviLwR4L8e6P 4N159S0XxINV0KO48QeJfD0v9k60n6k/8LW8d/8ARtHxt/8AB9+zj/8ARAUf8LW8d/8ARtHxt/8A B9+zj/8ARAU/9Xad6r+tVL1oqMpfX8LzR5ayrRlB8/uSjJaNLS7kkpSlKQs7mvZ/7PTtSbcY/VK/ K70/ZNSXL70XHdSbvom3GMYr8wNf+BH7YniP4b29rpXj79qfTrjSvhx+2X4p8MabJ8Rrn4b+KdP+ IV3pXwbl/Zz8Aa5qFn+0P8avE3jPQofFeleP73w3qXjf4o61rMdlearo+u3el+FbuK11bF8TfBj9 vrSbe80Gz8U/H7xB8OX8c+BvEevy2fxObxD8Tri41v8AZqgtfF8nhy/0z48fArxSvg7Qv2gLi4ur rwVoPxX8KeHbC9Fjd6H4W13wRY6npT/qz/wtbx3/ANG0fG3/AMH37OP/ANEBR/wtbx3/ANG0fG3/ AMH37OP/ANEBTlw9CX/MTUjf2afLmGGs406ap8jTqNunJJOUL2bVlZaCjnU0kvYQlbnavhK9+adT 2nOrQVpxd1GdrpN3uz889M+A/wC1xd+NPDPiLWfiN+0VfwyfFj4EeDvEvm/FVfBmj3vwSm/Y78Oe Gvjh4xn+Hnhvx/rXhnw34qv/AI2JqOoXE3h7VNb1jw542hm1z4e6tM0174l1f0D4L/DvxR8J/wDg mD4n+HPjXwp8QfBvi7wd+zl8StA8R6N8RfGFr41vv7Y0v4capZX114b1Oy8aeOLSz8ETTwOvhbSL fUNLisrCPcmgaaJ/3/2Z/wALW8d/9G0fG3/wffs4/wD0QFeQftCfEvxnf/AP44WF3+z38X9Etb34 QfEu0uda1TWvgHLpmkW9z4M1qGbVNRi0X44avrEtjYRu13dx6TpOqam9vFIthp17dGK2l7suyeOG x+HxEaqnJVpaVMZhamletQnO15uo2vYwUbSu1pJSdrceMzOVfCVaMqfLH2cbcmHr0/4NKrCN0oqF n7STk3HR6rlVz+0yiiiv5pP3YKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACvyi/4Kxf8ij+yD/2d7J/6yL+1tX6u1+Q//BYTxBYeFvhx+ydr2pwa3dWN h+17GZ4PDnhrxH4w1qT7V+yh+1dZRfYvDnhLStb8Q6kVmuY3uBp2l3Rs7Rbi/u/IsLS6uYfpOEE5 cR5ZGKbk6ldJJNtt4Wukklq23oktWzwuJWlkePbaSUKLbbskliaN229El1Z+e9FeJf8ADQHgT/oA /G3/AMRo/aO/+dTR/wANAeBP+gD8bf8AxGj9o7/51Nfvf1XE/wDQPX/8E1P/AJE/H/b0P+f1L/wZ D/M9torxL/hoDwJ/0Afjb/4jR+0d/wDOpo/4aA8Cf9AH42/+I0ftHf8AzqaPquJ/6B6//gmp/wDI h7eh/wA/qX/gyH+Z7bRXiX/DQHgT/oA/G3/xGj9o7/51NH/DQHgT/oA/G3/xGj9o7/51NH1XE/8A QPX/APBNT/5EPb0P+f1L/wAGQ/zPbaK8S/4aA8Cf9AH42/8AiNH7R3/zqaP+GgPAn/QB+Nv/AIjR +0d/86mj6rif+gev/wCCan/yIe3of8/qX/gyH+Z7bRXiX/DQHgT/AKAPxt/8Ro/aO/8AnU0f8NAe BP8AoA/G3/xGj9o7/wCdTR9VxP8A0D1//BNT/wCRD29D/n9S/wDBkP8AM/Yv9hnxd+2xbfsT/seW 3hT9n39lrWvC9v8Astfs+weG9Y8Q/th/Frwxr+raBF8JfCMej6nrnhvTf2GvF2neHtYv9OW2utT0 Ow8V+J7LSb2WewtfEOtQW8epXP1L/wAJp+3v/wBG1fshf+JvfGb/AOl80v8AwT5GP2Cf2IRxx+yF +zWOCCOPgz4L6EZBHuCQe1fXlfgGa4zDLNMyTynL5NY/GJydTNLyaxFS7fLmUY3drvlSV27JKyX7 Jl2GrPL8C1mGMing8K1FQwFkvYU9FzYFystldt23bep8hf8ACaft7/8ARtX7IX/ib3xm/wDpfNH/ AAmn7e//AEbV+yF/4m98Zv8A6XzX17RXB9dw3/Qoy7/wbm3/AM8/6u/K3Z9Vr/8AQxxv/gvL/wD5 g/q78rfIX/Caft7/APRtX7IX/ib3xm/+l80f8Jp+3v8A9G1fshf+JvfGb/6XzX17RR9dw3/Qoy7/ AMG5t/8APP8Aq78rH1Wv/wBDHG/+C8v/APmD+rvyt8hf8Jp+3v8A9G1fshf+JvfGb/6XzR/wmn7e /wD0bV+yF/4m98Zv/pfNfXtFH13Df9CjLv8Awbm3/wA8/wCrvysfVa//AEMcb/4Ly/8A+YP6u/K3 yF/wmn7e/wD0bV+yF/4m98Zv/pfNH/Caft7/APRtX7IX/ib3xm/+l819e0UfXcN/0KMu/wDBubf/ ADz/AKu/Kx9Vr/8AQxxv/gvL/wD5g/q78rfIX/Caft7/APRtX7IX/ib3xm/+l80f8Jp+3v8A9G1f shf+JvfGb/6XzX17RR9dw3/Qoy7/AMG5t/8APP8Aq78rH1Wv/wBDHG/+C8v/APmD+rvyt8hf8Jp+ 3v8A9G1fshf+JvfGb/6XzR/wmn7e/wD0bV+yF/4m98Zv/pfNfXtFH13Df9CjLv8Awbm3/wA8/wCr vysfVa//AEMcb/4Ly/8A+YP6u/K3yF/wmn7e/wD0bV+yF/4m98Zv/pfNH/Caft7/APRtX7IX/ib3 xm/+l819e0UfXcN/0KMu/wDBubf/ADz/AKu/Kx9Vr/8AQxxv/gvL/wD5g/q78rfIX/Caft7/APRt X7IX/ib3xm/+l80f8Jp+3v8A9G1fshf+JvfGb/6XzX17RR9dw3/Qoy7/AMG5t/8APP8Aq78rH1Wv /wBDHG/+C8v/APmD+rvyt8hf8Jp+3v8A9G1fshf+JvfGb/6XzR/wmn7e/wD0bV+yF/4m98Zv/pfN fXtFH13Df9CjLv8Awbm3/wA8/wCrvysfVa//AEMcb/4Ly/8A+YP6u/K3yF/wmn7e/wD0bV+yF/4m 98Zv/pfNeH/BHwb+3r8DrTxx4W0H4G/shXvw01fxxq/jH4ceCZP2x/jNaN8KrHxT5ereKfBWlawn 7Bk8eq+EJPGlxr3iTwnph0jSj4NsNel8JWUt7oGlaHBpv6W0VrDM6cKVWjHKsu9lX9m6sHPNJKUq UuanNc2ZNwqQvOMakOWap1atPm9nVqRlEsBOVSnVlmGMdSlzqE1DAJqNRJTi7YFc0J8sXKErwc4Q nbnp05R+Qv8AhNP29/8Ao2r9kL/xN74zf/S+aP8AhNP29/8Ao2r9kL/xN74zf/S+a+vaKy+u4b/o UZd/4Nzb/wCef9Xfla/qtf8A6GON/wDBeX//ADB/V35W+Qv+E0/b3/6Nq/ZC/wDE3vjN/wDS+aP+ E0/b3/6Nq/ZC/wDE3vjN/wDS+a+vaKPruG/6FGXf+Dc2/wDnn/V35WPqtf8A6GON/wDBeX//ADB/ V35W+Qv+E0/b3/6Nq/ZC/wDE3vjN/wDS+aP+E0/b3/6Nq/ZC/wDE3vjN/wDS+a+vaKPruG/6FGXf +Dc2/wDnn/V35WPqtf8A6GON/wDBeX//ADB/V35W+Qv+E0/b3/6Nq/ZC/wDE3vjN/wDS+aP+E0/b 3/6Nq/ZC/wDE3vjN/wDS+a+vaKPruG/6FGXf+Dc2/wDnn/V35WPqtf8A6GON/wDBeX//ADB/V35W +Qv+E0/b3/6Nq/ZC/wDE3vjN/wDS+aP+E0/b3/6Nq/ZC/wDE3vjN/wDS+a+vaKPruG/6FGXf+Dc2 /wDnn/V35WPqtf8A6GON/wDBeX//ADB/V35W+Qv+E0/b3/6Nq/ZC/wDE3vjN/wDS+aP+E0/b3/6N q/ZC/wDE3vjN/wDS+a+vaKPruG/6FGXf+Dc2/wDnn/V35WPqtf8A6GON/wDBeX//ADB/V35W+Qv+ E0/b3/6Nq/ZC/wDE3vjN/wDS+aP+E0/b3/6Nq/ZC/wDE3vjN/wDS+a+vaKPruG/6FGXf+Dc2/wDn n/V35WPqtf8A6GON/wDBeX//ADB/V35W+Qv+E0/b3/6Nq/ZC/wDE3vjN/wDS+aP+E0/b3/6Nq/ZC /wDE3vjN/wDS+a+vaKPruG/6FGXf+Dc2/wDnn/V35WPqtf8A6GON/wDBeX//ADB/V35W+Qv+E0/b 3/6Nq/ZC/wDE3vjN/wDS+aP+E0/b3/6Nq/ZC/wDE3vjN/wDS+a+vaKPruG/6FGXf+Dc2/wDnn/V3 5WPqtf8A6GON/wDBeX//ADB/V35W+Qv+E0/b3/6Nq/ZC/wDE3vjN/wDS+aq33ib9unVLG80zU/2X v2ONR03UbW4sdQ0++/bW+MN3Y31jdwvb3dneWlx/wT2kgurW6gkkguLeeN4ZoXeORGRmU/Y9eH/F H4B+EvjNq+nv8SNb8a+IfAljpos7r4NJ4hGj/CnxNem5uJptU8eaHoVlpmtfEOG5tpotOuPBvjnx F4g+GktvZWt2fA41gXGqXGtDGYF1I+2y3A0aa951KbzarUVtUqdP+16UZTb25qtKK1bmrJGdXDYp Qfs8bi6s3ZKE1l1OFna7nP8As6bUUr35ac5O9lHqv56/2pfiL+1N4d+A37UngP8AZj+FPwP1T4FH 4AftBaB8ffCXwu/aY+Jfxx+A/wAFvCQ+FXjO18V6n8LvEfjL9lf4I+D/AAH468MIJUb4JfDf4seK NJspoTZ3fwQ8MXOqT+L7WSv2y/bu0bSPD3/BPT9s3QtA0vTdC0TSf2N/2jdO0rR9IsbbTNK0vT7X 4K+Mobay0/TrGGG1srO2iVY4La1gjhhjVUijVQBX88H/AAtbx3/0bR8bf/B9+zj/APRAV+v8I42n muXV50MHh8GqONnTnOWJlLEYqToYeXtsTWxVdutV3jFxvKFNQhUnVajOX5txLhZ4DGUI1sTWxLq4 WMowVGKo4dRq1Y+zoU8PSSpwfxSTtGU7yhCmm4r22ivEv+FreO/+jaPjb/4Pv2cf/ogKP+FreO/+ jaPjb/4Pv2cf/ogK+q+r1P5qH/hVhv8A5cfOe2h2q/8Agiv/APKz22ivEv8Aha3jv/o2j42/+D79 nH/6ICj/AIWt47/6No+Nv/g+/Zx/+iAo+r1P5qH/AIVYb/5cHtodqv8A4Ir/APys9torxL/ha3jv /o2j42/+D79nH/6ICj/ha3jv/o2j42/+D79nH/6ICj6vU/mof+FWG/8Alwe2h2q/+CK//wArPba8 S/aX/wCTcP2gP+yJfFb/ANQTXqP+FreO/wDo2j42/wDg+/Zx/wDogK8g/aE+JfjO/wDgH8cLC7/Z 7+L+iWt78IPiXaXOtaprXwDl0zSLe58Ga1DNqmoxaL8cNX1iWxsI3a7u49J0nVNTe3ikWw069ujF bS74bD1FicO+ahpXpPTE4ZvSpHZKq235JNvoZV60HRrK1XWlUWtGsl8D3bp2Xq9D+0yiiiv5ZP6C CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAr8ov8A grF/yKP7IP8A2d7J/wCsi/tbV+rtfkR/wWD8SeHfCHw4/ZP8SeLNe0Xwv4d0v9ryJtT1/wARapY6 JounLefso/tW6daNfapqU9tY2gutQvLSxtjcTxie8ura1i3TzxI30nCCcuI8sjFNydSukkm228LX SSS1bb0SWrZ4XErSyPHttJKFFtvRJLEUW230SWrfRH57UV4l/wANL/s4/wDRwHwS/wDDreBP/l9R /wANL/s4/wDRwHwS/wDDreBP/l9X739VxP8A0D1//BNT/wCRPx/29D/n9S/8GQ/zPbaK8S/4aX/Z x/6OA+CX/h1vAn/y+o/4aX/Zx/6OA+CX/h1vAn/y+o+q4n/oHr/+Can/AMiHt6H/AD+pf+DIf5nt tFeJr+0t+zkzBV+P/wAE2ZiFVV+KvgUszE4AAGvZJJ4AHJPApP8Ahpf9nH/o4D4Jf+HW8Cf/AC+o +q4n/oHr/wDgmp/8iHt6H/P6l/4Mh/me20V4l/w0v+zj/wBHAfBL/wAOt4E/+X1H/DS/7OP/AEcB 8Ev/AA63gT/5fUfVcT/0D1//AATU/wDkQ9vQ/wCf1L/wZD/M9torxL/hpf8AZx/6OA+CX/h1vAn/ AMvqP+Gl/wBnH/o4D4Jf+HW8Cf8Ay+o+q4n/AKB6/wD4Jqf/ACIe3of8/qX/AIMh/mf0Yf8ABPn/ AJMI/Yh/7NC/Zq/9Uz4Lr69r5D/4J9qyfsFfsRI6lWX9kP8AZsVlYFWVl+DPgsFWBwQQQQQQCCMG vryv5wzb/ka5n/2MMb/6k1T9wy3/AJF2A/7AsL/6YphRRRXnnaFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH yF/wUG/5MI/be/7NC/aV/wDVM+NK/Dyv3c/bk8O+IPGH7FP7YPhLwnomreJvFPin9lv9oHw74a8N 6Bp13q+u+IPEGt/CbxbpmjaJouk2EVxfapq2rajdW1hpunWUE13e3lxDbW0Uk0qI34Df2j4u/wCi B/te/wDiFP7XX/zk6/W/D+cFlWLi5xUlmE5OLklJRlh8Motq97Nxkk9m00tUz854yhN4/CtRk19U Suotq6rVbq6Vrq6uvNd0btFYX9o+Lv8Aogf7Xv8A4hT+11/85Oj+0fF3/RA/2vf/ABCn9rr/AOcn X3ftIfzw/wDAl/n5r7z4/wBnP+Sf/gL/AMvNfebtFYX9o+Lv+iB/te/+IU/tdf8Azk64mz+Lmi6j 461X4Xaf4E/aFv8A4m6DpKa/rvw5sv2Vv2m7rx7ougy/2X5Wuav4Og+EcniLTNHm/tvRhDql7psF jMdV04Rzsby3ElR9/mcPfUIuc+X3uSCcU5ytflinKKcnZJyir3aFJOPKpJxc5KEOZW5ptNqMb25p NJtRV20m7WPU6Kwv7R8Xf9ED/a9/8Qp/a6/+cnR/aPi7/ogf7Xv/AIhT+11/85Op9pD+eH/gS/z8 194/Zz/kn/4C/wDLzX3m7XiX7S//ACbh+0B/2RL4rf8AqCa9XqH9o+Lv+iB/te/+IU/tdf8Azk68 v+OGmfEjxn8Fvi/4P8N/s7/teaj4i8V/C/x/4a0DT2/Yz/ausVvta13wnq2l6XZte6j8G7TT7MXN 9dQQm6vru1s7cP511cQwI8i7YerSjiKEpVKcYxrUm5OcUklOLbbbsklq29EjOtTqOjVSpzbdOaSU JNtuLSSSV222rJb3Xc/rtooor+Yz96CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAoorw344/HG3+Clv8OIIPhx8Qvix4q+LHxCk+GfgXwL8M5Ph1a+IdW8Q2vw6+IXxV1GWX Ufir8Qvhh4K03TNN8FfDDxdqVzc6l4utJ5p7S107TrS+v763t21o0amIqRpUoqU5KTXNOFOKjCEq k5zqVJQp04QhGU5znKMIQjKUpJJszq1YUYOpUbjFOK0jKUnKclCEYwgpTnOc5RhCEYuUpSUYptpH uVFfIX/DSvxm/wCkfP7Xv/hafsEf/RvUf8NK/Gb/AKR8/te/+Fp+wR/9G9XZ/ZmJ/wCfuXf+HfKf /m3z/Pszm+v0P+feN/8ADdmH/wAy+f59mfXtFfIX/DSvxm/6R8/te/8AhafsEf8A0b1H/DSvxm/6 R8/te/8AhafsEf8A0b1H9mYn/n7l3/h3yn/5t8/z7MPr9D/n3jf/AA3Zh/8AMvn+fZn17RXyF/w0 r8Zv+kfP7Xv/AIWn7BH/ANG9R/w0r8Zv+kfP7Xv/AIWn7BH/ANG9R/ZmJ/5+5d/4d8p/+bfP8+zD 6/Q/5943/wAN2Yf/ADL5/n2Z9e0V8hf8NK/Gb/pHz+17/wCFp+wR/wDRvUf8NK/Gb/pHz+17/wCF p+wR/wDRvUf2Zif+fuXf+HfKf/m3z/Psw+v0P+feN/8ADdmH/wAy+f59mfXtFfIX/DSvxm/6R8/t e/8AhafsEf8A0b1YHiv9of8AaI1Pwt4l07wh+wv+1h4V8WahoGs2XhfxPqWsfsEeKNO8OeIrvTrm DRNev/DX/DeWif8ACQ2Wj6lJbahdaH/bWkf2tBbyWH9qWH2j7XE45ViJSinXy2CbSc5ZvlfLFNpO UlHFylaN7vljKVk7RbVhPMKKTapY6TSbUVl2PTk7aJc2GjFN7LmlFX3aSbWf8RLOx/a5+Mt18Dpr Wz1v9nL4D61omt/tBLcwPeaL8VPjJbxaf4n8AfAK5jlA07V/CvgK0udE+K3xfsJFu7S/1i5+Fngi 6F3Yz/EXRIdb9lu9vvhD4j8Xfsa+Kbu5uD8JtLtvFv7Pus6jM0tz4x/Zj1jUJNO8NaSbue7nuNT8 Q/AbXA/wi8UnZ9oj8LQ/CXxXrEh1D4hKD+fHgDUP+CqnwK+D0fgH4T/s/r4m1fw7oviHUNKm+In7 P/7PWnXvxF+Iuryaj4g1XxN8TvHul/8ABbzxJqEGtfEPxtf3mu+PPGWneCtcuYL/AFrVNW03wnfL Fa6G/T61c/8ABRnxr8T/AIG/Efxv8CfGkdx8FvHb+JIZ/h1+zv8AsmeEPFviDwbr2nvoXxH+Gb+J fFH/AAWs+I+j2Hhz4gaA8Md8934O1waX4j0Pwh4wsbJtc8JaPLD9VUy2i6FbALO8heWRpT+qJZlB Vvr1CHPDHTpezTjUxs5yw9X2knClhaypKdZ5fRcfn6eOqqrTxbyrN1j5Tg8S3gZey+qVpRhPCRqc 75oYWEVWp8qUp4ilKo40li6ql+21FfIX/DSvxm/6R8/te/8AhafsEf8A0b1H/DSvxm/6R8/te/8A hafsEf8A0b1fKf2Zif8An7l3/h3yn/5t8/z7M+h+v0P+feN/8N2Yf/Mvn+fZn17RXyF/w0r8Zv8A pHz+17/4Wn7BH/0b1H/DSvxm/wCkfP7Xv/hafsEf/RvUf2Zif+fuXf8Ah3yn/wCbfP8APsw+v0P+ feN/8N2Yf/Mvn+fZn17RXyF/w0r8Zv8ApHz+17/4Wn7BH/0b1H/DSvxm/wCkfP7Xv/hafsEf/RvU f2Zif+fuXf8Ah3yn/wCbfP8APsw+v0P+feN/8N2Yf/Mvn+fZn17RXyF/w0r8Zv8ApHz+17/4Wn7B H/0b1H/DSvxm/wCkfP7Xv/hafsEf/RvUf2Zif+fuXf8Ah3yn/wCbfP8APsw+v0P+feN/8N2Yf/Mv n+fZn17RXy98PP2ltS8XfFfSfg544/Z3+OXwK8WeJPh746+JnhWf4oaj+z7rWjeJvD3w28SfDTwt 4yisLz4I/Hr4xXNhqek6l8XPBDrbeIrHRINQtdQupdNu7uTTr2GH6hrlxGGq4aUY1VD34KpCVOrR r05wcpQ5oVaE6lKaU4ThLlm+WcJwlaUWl0Ua9OvGUqbl7suScZ06lKpCXLGfLOnVhCpBuE4TSlFX jKMleMk2UUUVgahRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFfAHwj/aC/bS+Nnwo+GPxm8GfsxfsvWng/4ufD3wX8TvClr4n/AG0fivpviW28 NePfDem+KtCt/EOnaV+wfr+l2GuQ6Xq1rHq1lpuu61YWt+txBZ6tqNvHHeTehf8ACaft7/8ARtX7 IX/ib3xm/wDpfNenUyjGUqk6VSeAhUpzlTqQlm+UqUJwlyyi19d0cZJp9mn2ZwQzLDVIQqU44yUK kYzhJZdmFpQmlKMk/quzTTXl6M+vaK+Qv+E0/b3/AOjav2Qv/E3vjN/9L5o/4TT9vf8A6Nq/ZC/8 Te+M3/0vmp/szE/8/cu/8O+U/wDzb5/n2ZX1+h/z7xv/AIbsw/8AmXz/AD7M+vaK+Qv+E0/b3/6N q/ZC/wDE3vjN/wDS+aP+E0/b3/6Nq/ZC/wDE3vjN/wDS+aP7MxP/AD9y7/w75T/82+f59mH1+h/z 7xv/AIbsw/8AmXz/AD7M+vaK+Qv+E0/b3/6Nq/ZC/wDE3vjN/wDS+aP+E0/b3/6Nq/ZC/wDE3vjN /wDS+aP7MxP/AD9y7/w75T/82+f59mH1+h/z7xv/AIbsw/8AmXz/AD7M+vaK+Qv+E0/b3/6Nq/ZC /wDE3vjN/wDS+aP+E0/b3/6Nq/ZC/wDE3vjN/wDS+aP7MxP/AD9y7/w75T/82+f59mH1+h/z7xv/ AIbsw/8AmXz/AD7M9e+O/wAYNK+Bfwu8R/ETUdMuvEWoWP8AZ2i+DfBemy+TrfxD+IvirUrTw38P fh1oEnkXSxaz448Yapo/hyyvJ7d7DSjqD6xqz22kaff3cHyZ/wAMkeOvDfwc8OeNvDms6Jqn7bHh Pxrr37Qt/wDEO5MltoPxB+L/AI0sbS2+J3wr1W7nQ31l8FPGng2w034I+HbKcXE/gXwV4S+FviW3 gvvFHw10O6Hn3x/+EP7evx5174ReJovCfwh+EOsfBfxF4h8XeFZPhj+2xLqen33ibX/Ds/hSLXfE Gg/Gf/gk38XvD9/qvhvQdR8Q2PhXULXStPu9G/4SnXriOaW6msZ7DgYPgx/wV8XX9Tubn9oTR5fC 8uj6HBo+jwftHfs92+v2Gv2974hk8SanqfiWT/gh3c6dq2j6tp1z4UtdD0O18KaLe+Hr3RfEN/f+ IfE8HifTdN8I/QYHASoYSi6GbZFhsROrKtjaeLzGlL20ISdCjgWsN9ZpVMLOjUrVsRGVWEMRGu6N WnzYWk5+Pi8XGtiaiq5dm1ejGnGlhp4fBVI+ylNQq1MXeu6FSFeNWNKnRcacpUXRdSnLlrVFH9Q/ g38V/DXxu+G/hr4leFodUsLDXoLyDUNA1+0/s7xN4P8AE+iahd6D4w8DeLdLLynSvFvgnxTpur+F fE+miWZLLW9JvoIbi5gWK4l9Or8q/wBn74Qft6fATXfi74kfwn8IPi7qvxo8SaD4w8Ut8Tf2130v TbDxRougQ+F7rXvDug/Bj/gk18IdA0/VfFGiaf4ftfFt9daXqFxrUvhnRb15Ib8anc6l9L/8Jp+3 v/0bV+yF/wCJvfGb/wCl815GNynkxVWODxOXVcNeMqUv7Wy1WU4RnKneriqVSaozlKiqs6VJ1VT9 r7OmpckfRwuY82HpPE0MbTr2aqR/s7Gu7jJxU2qdCpCLqRUajpxqVFTcnT558jk/r2ivkL/hNP29 /wDo2r9kL/xN74zf/S+aP+E0/b3/AOjav2Qv/E3vjN/9L5rm/szE/wDP3Lv/AA75T/8ANvn+fZm/ 1+h/z7xv/huzD/5l8/z7M+vaK+Qv+E0/b3/6Nq/ZC/8AE3vjN/8AS+aP+E0/b3/6Nq/ZC/8AE3vj N/8AS+aP7MxP/P3Lv/DvlP8A82+f59mH1+h/z7xv/huzD/5l8/z7M+vaK+Qv+E0/b3/6Nq/ZC/8A E3vjN/8AS+a9j+AXxUh+OvwJ+Cvxut9El8NW/wAY/hL8OPipB4cmv11WbQIfiF4O0bxdFokuppaW CajLpSautjJfpY2S3jwG4W0thIIUyrYDEUKXt5vDzpKpCk5YfG4PFctSpGpOEZxw1etKHPGlUcXN JPkkk7qxpSxdGtU9lH20ajhKoo1sNicO5Qg4RnKLr0aalyupTUlFtrmV0etUUUVxnSFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV8hftK/8lm/4J8/9ne+NP8A1gj9t6vr2vkL9pX/AJLN /wAE+f8As73xp/6wR+29XoZZ/vNX/sX5t/6qsacWP/gU/wDsNy3/ANWOFPr2iiivPO0KKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooA+QvGn/J+/7NX/AGaF+29/6ub/AIJ819e18heN P+T9/wBmr/s0L9t7/wBXN/wT5r69r0Mb/u2U/wDYvq/+rXMziwv8fMv+w2n/AOq7ABRRRXnnaFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUV8c/tS/to+Df2Vte+G vhXXPhl8W/ij4k+KOkfEHxBoWkfCqD4ZGXT9E+Gl78P9O8S6lrd58UPif8MNKgjF/wDEzwra2Ftp 1/qmoXbXF5KbOG2spZq6sHgsVmGJp4TB0ZV8RVVR06UXGLkqVOdao7zlGKUKVOc5OUklGLdzDE4q hg6E8Tiaio0Kbgp1JKTSdScaUFaKlJuVScYpJPWSPsaivyi/4exeEf8Ao0H9r3/v5+yL/wDRbUf8 PYvCP/RoP7Xv/fz9kX/6Lava/wBUeIv+hbP/AMKMJ/8ANHn+fZnlf6yZL/0HQ/8ABOI/+U+f59mf q7RX5Rf8PYvCP/RoP7Xv/fz9kX/6Laj/AIexeEf+jQf2vf8Av5+yL/8ARbUf6o8Rf9C2f/hRhP8A 5o8/z7MP9ZMl/wCg6H/gnEf/ACnz/Psz6g/4J8/8mEfsQ/8AZoX7NX/qmfBdfXtfhZ+y3/wUSsPg j+zL+zp8GPFf7Jn7UuoeKPhF8CfhF8MPEl/4evP2UrvQL7X/AAD8P/D3hTWLzQ7rUv2ptJ1G50e5 1HSbmbTLi/0rTL2ayeCS60+znaS2j92/4exeEf8Ao0H9r3/v5+yL/wDRbV25lwrn9XMcfVp5e506 uNxVSnOOIwnLOE685Qkn9Y2lGSa8n5M5cBxBk9LA4OnUxsYzp4TDwnF0cReM40YRlF/ud07p+j7M /V2ivyi/4exeEf8Ao0H9r3/v5+yL/wDRbUf8PYvCP/RoP7Xv/fz9kX/6LauL/VHiL/oWz/8ACjCf /NHn+fZnV/rJkv8A0HQ/8E4j/wCU+f59mfq7RXwd+zn+374H/aL+K7/Byz+DXxy+FXiuT4eeKviZ plx8UIPg3JouteHvBfiTwF4W8RQ2F58LfjN8T7q31Sy1L4leFXS21ix0u3u7S5upbS7mkspoR941 4+OwGMy2v9WxtCVCtyRqKEpQleE78slKnKcGm4yWknZpp2aaPTwmMw2Ope3wtWNalzOHNFSjaUbN xcZxjJNJp2aWjTWjQUUUVxnSFFFFABRRRQAUUUUAFFFFABRRRQAV8hf8E+f+TCP2If8As0L9mr/1 TPguvr2vkL/gnz/yYR+xD/2aF+zV/wCqZ8F16FL/AJFWN/7GGWf+o2bHFU/5GOF/7Asf/wCn8tPr 2iiivPO0KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAr5C/aV/5LN/wT5/7O98af+sEf tvV9e18hftK/8lm/4J8/9ne+NP8A1gj9t6vQyz/eav8A2L82/wDVVjTix/8AAp/9huW/+rHCn17R RRXnnaFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfIXjT/AJP3/Zq/7NC/be/9 XN/wT5r69r5C8af8n7/s1f8AZoX7b3/q5v8AgnzX17XoY3/dsp/7F9X/ANWuZnFhf4+Zf9htP/1X YAKKKK887QooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACvxS/wCC oH/Jx/7If/ZEv2xP/U7/AGLq/a2vxS/4Kgf8nH/sh/8AZEv2xP8A1O/2Lq+t4G/5KfAf9eM1/wDV Pjz5ziz/AJEGM/6+5f8A+rLBnxZX5I+Pv28PjP4V/bf1P9m/w/4a+Hnirw5bfGH4Y/DjSvB48KeN dE+IPiDw94u+AUfxh8YeKNN+L2r+MbX4NReIPCdxFeLpvw/1bStK1rxNpLwizuYhaX2sL+t1eD61 +zL8D/EPi7U/HmseB0vPF2r/ABO+G/xkvta/4SHxXbzn4k/CTw7D4S8A+JbWG112G0059G8Mw/2H daXp1va6J4g024vrbxJpurx6jfi5/XsbRxVaNBYWuqEoYiFSq22uejGFRSpJqM1eU3BrnjKCtzSh NL2cvzXCVcPSlWeJpOrGdCUKaSi+Sq5wcZu7i7Ripp8soyd7KUL88fhXwr/wVO8M2Pwd+FHj74uf CXxX4Z8XfETwh4l+IV14V0LxH8LXFv8AD/wxruk+HbvxXoC6/wDEvTrnxPdX+ratLYaN4A8PvrHx F1FvDniW+HhqHTIdGutZ8/8ADv8AwUx8daT8fPi94U+JOnfD26+E3wn1P9s3UfFcPhjwV498L+P/ AAh8Of2X9cg0zw/4rtvFPi/xde/D74s6l4yubuz8Pax4f8G22hXPhfV7qDV9bk0fR5Uhr700r9ib 9nLQLTw5Z+G/C3jTwsPCMfiW08OXvhT42/HPwvrGlaJ4v1HSNX8Q+ELfXvD/AMSNN1tvAN9q+hab q0Xw8m1CXwPp+qRXGoab4fs7y/1Ca61NT/Y4/Zs1qWebVvhhZai914i+Nviq6+1+IPF86XOs/tG6 dcaV8aHuI38QGOfTvHFpcZudClRtC0i8tdM1Lw7pukalpGl3dn5/1XO2qV8bh+al7B/b/eOEaare 0cKMFJVJKo1Fwtyuy9nKSnS7FiMpTqf7LWtU9t/L7ilKTpKHNVk4uC5U2p3vq+eMXCp4r4b/AOCg /g/xodF0LwV8IviT4z+JWt+MfFXhO1+HPhTxH8E9ellg8GeAvCvxI8Q+I7L4h6b8WLj4SappFj4f 8a+HNOkh0/x5PqyeLru68NT6dDPYXNytDxZ/wUl+FPgl/E154h+G3xetPC1hZ/tFy+BfGA0rwhLp fxVv/wBleXULX4waZ4R0qPxm3iyzewvdL1KDw5f+J/D2h6X4mTTb6WxvEK2cV97tqH7H3wJ1bQ/D +g6tpnxH1WPwpres694a1zU/j58fdQ8caDceIvDNr4O1/StJ+I158TpvH9j4S1rw3ZW2mar4Gt/E sfgu/SL7RdaBLePJcPlXn7Dn7Lmo6h4y1HUPhlJfP47sfifp+tWN546+JFzoWnRfGrUI9V+LFz4J 8NTeL38PfDXVfiDfxfaPFGt/DrS/C2s6oZbqOe/MN5dxzbOlnPK1HEYTm93llJPlslDm54rD3bb9 rdxnFSboyjGnGFSnWzVTKrpyo4nl15lG1225W5ZOvol+7snGTS9pFublCpT+bviZ+3j4yXxX8N/A Pgz4N/EXwL4gf9oX9lv4cfGPUPH1r8O7rT/AumfHXxXaXFt4MuU0bx9rFzdeLNe+H7Rau2o+GrPx BpnhRta0/TdXvrHX2nt9P/UOvnXxd+yf8BfHXxLtfi74m8F39547tfEXw88Xm/svHXxD0PRr/wAV /Ce++3/DnxLrfg3QvFemeC/EGv8AhKQva6Vq+ueH9Rv10ia40Ke4m0W4n0+T6KrrwtLFwniJYmtG rGUkqHK/hpxdRJyiqdOMZyg4OfK5pzUmpKPLFc2IqYacKKw9KVOUYt1brRzlGF1GTqTlKEZKfJzc rUHFNOXNJ/Qf7CP/ACfv4Q/7NC/aa/8AVzfsZV+/tfgF+wj/AMn7+EP+zQv2mv8A1c37GVfv7X5T x7/yO6X/AGL6H/p7En6Hwd/yKqv/AGG1v/TOHCiiiviT6sKKKKACiiigAooooA/C3/grb4M8H+Pv jx+yB4f8deFPDXjTQYvhJ+13rMWieLdC0vxHpEer2XjL9j2ys9Vj03WLW8sk1K0stU1O0tr5YRdQ Wuo39vFKkV5cJJ+cn/DNH7OP/Rv/AMEv/DU+BP8A5Q1+oH/BUD/k4/8AZD/7Il+2J/6nf7F1fFlf v3CNatT4XySNOtVhH2OOfLCpOKu84zK7tFpXfc/HeJKVOfEGaudOEn7XCK8oRk7f2bgtLtNnwR8T tc/4J1fBn4gaJ8MPih4K+APgzxl4g0nRdesbPVvgnpI0e20TxF4gv/Cui6trvi228D3HhDwvp+oe IdMvdJhu/Euu6TALqECR0SWF5Pa/D3wT/ZL8WRatN4Y+D37PfiCLQvEGs+FNak0j4c/DvUF0nxN4 eu2sNd0DUTbaLJ9j1fSLxGttQ0+fy7m1lAWaNSRn42/bJ/Yd+Jn7Qfxp1/4r+FNc0RLDTvgl8GvC mg+BfEHi/wAR6N4K+JXif4dftBa78VNf8G/F3QNF0a/h1v4f6z4Xu7ey02V55bmw8VS2l+tpHb2M 00vgPjD/AIJs/FGbWfGlt4a8EfB6LwDqvx++OHxJvfDvh/xdoXhm6+JXhf4s2upnwHLrVt4w/Z2+ J/hXwx4o+Bcmo6rB4advDniK7juvF+uaz4S8TeFNQ0u2n1neeb55Sr106FetQjO1F06uIjUlFylG 8mnWjKyi6kmow920YxlOcIyxjluU1KVFqtSpVZQbqqdOjKEZqMJcqT9k1dy5FeUlzJtyUYzcfuDx 3q3/AATw+Gvj6H4YeMPAnwFsPHLQaRdX+h6f8D9M8R/8I3aa/dQWei3fjXUvDXgXV9H8CWeqTXMD WN34z1DQbe4tZY72OQ2TC4r6G/4Zo/Zx/wCjf/gl/wCGp8Cf/KGvz3179kf9q3wePGPhr4PeJNIk 0v4geO/2f/H1t8UdQ/aB+Ifg74qeCr74c+APhd8LfiL4b8dXfhf4YRQ/Hjwr4j8MeB9U1PQf7buf DgXxBr2p3994cs5ntHi5/wATf8E9vGNh4e8N3eifDr4OfE/VNT+L37VPjj40/D/x9408S6P4V+JL fFLxF8RW+A/jS+1eXwf4wgv9c+C/hnxHZ2WheHL/AMM21h4fm8R+Ib3wxqemaxZRahqNLN85Uqql RxE4xbatVxNPlj7b2UUppV/rMvZyjXk6VOCjTUkoyqp0oy8tyxqny1qMXJJNuFCfNL2XtG3G9JUI qadFe0nO9RpuUadpv9KP+GaP2cf+jf8A4Jf+Gp8Cf/KGj/hmj9nH/o3/AOCX/hqfAn/yhr8uvC/7 Bv7VXhnxV8I9N1TxP8NvGnhnwh8Uv2Gvit4x+I95458Waf4u1O8/Zq+E8Hwt+IHh+z8GyeAry11F dfuUk8S6Dql94y09bi1/0XU7KHUJ3aLpv+CYf7MPxW+Fp8IfFnxX4Q8OfCXwzr/7K3w38B6n4J0f X/FN94m+Ifj618Tat4pX4m/E3w34h8K+G/8AhEvF2geFb+w8Gw6U194mmt47rUdOsb/T9B0zS7OW qWdZnOvRozw2MpKq6ynOWJqv2caTiubSn7OUZKcXf2sV9mDqTtFqpleBhRq1Y4jDVHTVJxjGjTXt HUUny6z54tOMlb2cpaXnGEdT9H/+GaP2cf8Ao3/4Jf8AhqfAn/yhr8kf+Cpfgrwb8Jv+FF/8Kr8J eGPhp/b/APws7+3f+Ff6DpXg3+2v7K/4V7/Zf9r/APCOWmm/2l/Zv9paj9g+2ed9j+33v2fy/tU/ mfu3X4l/8Fi/+bdP+6u/+8wr7Dh6tWqZxg4VK1WpB/WLwnUnKLtha7V4ybTs0mrrRpNao+bzilTh l2IlCnCEl7G0owjGSvXpJ2aSaum09dm0f6GlFFFfyMf0eFFFFABRRRQAUUUUAFFFFABRRX86Hw5/ 4KQft5fEb4e+BPiFBrX7I2hweO/BnhfxnDok37Ovxk1eXR4vFGiWOtx6VLqqfte6Umpyael8LR9Q TS9NW9aE3K2FmJRbx+7k3D2Pz2OKng5YeEcHLDxrPEVJw97Equ6SgoU6jlph6rk7JKy1vJI8nNM6 weUyw8cUq0pYlVpU1RhGelB0VUcnKcErOvTtq29dND+i+ivwC/4bu/b3/wChv/ZC/wDEZfjN/wDR m0f8N3ft7/8AQ3/shf8AiMvxm/8Aoza9r/UHOv8An9l3/g+v/wDMv9Wflfyv9cMq/wCfeN/8E0v/ AJf/AFZ+V/39r5C/aV/5LN/wT5/7O98af+sEftvV+X//AA3d+3v/ANDf+yF/4jL8Zv8A6M2vOPHH 7T/7bHj7xN8HfFeseOv2WrbUfgj8R9U+J/hSHTP2bPi1DZahr+rfCL4p/Bi5s/EMd1+17eT3ejp4 X+LviS/gt9NudJvV1+x0O6k1CTTra/0rU+vBcD5vQrTnUrZeoywmPoq1au3z4jAYjD01ZYXZ1KsU 30V3stefFcV5bWpQhCnjLrE4Oq70qSXJQxlCtU/5f7qFOVl1at1R/SJRX4Bf8N3ft7/9Df8Ashf+ Iy/Gb/6M2j/hu79vf/ob/wBkL/xGX4zf/Rm1yf6g51/z+y7/AMH1/wD5l/qz8r9H+uGVf8+8b/4J pf8Ay/8Aqz8r/v7RX4Bf8N3ft7/9Df8Ashf+Iy/Gb/6M2j/hu79vf/ob/wBkL/xGX4zf/Rm0f6g5 1/z+y7/wfX/+Zf6s/K5/rhlX/PvG/wDgml/8v/qz8r/v7RXyb+xB8bvHP7RH7N3hT4pfEm28KW3j a98Z/GzwZrv/AAg+k6voPhW7l+E/xz+JHwmtNV0nRNe8SeL9X0mPWdO8EWerXOn3nifW2tL29uYI r+aBIiPrKvkMZhauBxeKwVflVfB4ivhayg+aPtcPVlSqcsrLmjzwfK7K6s7H0mGxFPF4bD4qlzey xNCliKXMuWXs61ONSHMru0uWSuruz0uFFFFc5uFFFFABRRRQAUUUUAFFFFABRX86Hw5/4KQft5fE b4e+BPiFBrX7I2hweO/BnhfxnDok37Ovxk1eXR4vFGiWOtx6VLqqfte6Umpyael8LR9QTS9NW9aE 3K2FmJRbx9l/w3d+3v8A9Df+yF/4jL8Zv/oza+4l4f55CUoSq5fGUJOMl7es7Si7NXWGadndXTad nZtWv8nHjLKZRjKMMY4ySkn7GmrppNOzrprR9VfyP39or8Av+G7v29/+hv8A2Qv/ABGX4zf/AEZt H/Dd37e//Q3/ALIX/iMvxm/+jNpf6g51/wA/su/8H1//AJl/qz8rv/XDKv8An3jf/BNL/wCX/wBW flf9QPGn/J+/7NX/AGaF+29/6ub/AIJ819e1/N3qn7T/AO2xq3xd8D/Ge58dfstJ4o8A/Dj4p/DD R7CD9mz4tLoFzoHxd8TfB3xX4kvNTtZP2vZNRm1ix1H4I+FIdDuLXVbOytrLUPEMd/p+pz3em3Ok +j/8N3ft7/8AQ3/shf8AiMvxm/8Aoza68TwPm9Wjl8IVsv5sPhJ0at61dJTlj8biEk/quq9nXpu6 68y3WvPQ4ry2nVxk5U8ZaviYVadqVJvkWDwlF3/f6PnpT07JPqj9/aK/AL/hu79vf/ob/wBkL/xG X4zf/Rm0f8N3ft7/APQ3/shf+Iy/Gb/6M2uT/UHOv+f2Xf8Ag+v/APMv9Wflfo/1wyr/AJ943/wT S/8Al/8AVn5X/f2iv50PiN/wUg/by+HPw98d/EKfWv2Rtcg8CeDPFHjObRIf2dfjJpEusReF9Evt bk0qLVX/AGvdVTTJNQSxNomoPpepLZNMLlrC8ERt5P6L68XOeHsfkUcLPGSw8o4yWIjRdCpOfvYZ UHVU1OnTcbLE0rOzUruz0Z6uV51g82eIjhVWjLDKjKoq0Iw0r+1VNxcZzT1o1E9U1ZaWaYUUUV4R 6wUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV+FX/BW7wP4K8f/Hz9j3RfHng/ wv420e2+EH7X+qW+k+LvD+k+JNMg1ODxn+xxaQajDYazaXtrFfQ2t9e20V2kS3EdveXUKSCO4lV/ 3Vr8N/8AgrH4b0Hxf8dP2UvDnifSrPW9C1P4Iftfpf6XqEQmtLpbf4h/sUXcAmjJG7yrm3gnjOQV liRgcqK+u4FlOHE+AlTbU40M2cWpOHvf2PmFveim469Um1vZ7HznFsYyyDGRmrxdXLlJOKlp/aeD v7raT7pNpN9Vufit4l1L/gnv4R1zxP4b174cfBW21jwdrWm+GfENta/s/Q6tFZ+KtasdL1LRvCUF 9o/w+v7DVPF2sWWtaVPpPhXSbq+8Q6mL6BLHTZ5CyL51aeOP2PLrV/FPh9/2VfhtYa54e+Mfwz+F 1lp2p/Cz4cWE/iTRPih8TLT4VaT8R9JguNDS+j0HS/Fa6/p2uaTqFjaa5pl/oJtLy1t49X0m6uPp a3/Zb8LWFxdNpmt3+nWEv7Q/g/8AaCs9Lt7GzW10298HfD3wf8PbDwhagFcaI9h4PtrtbkqLuBrl 7ZQ6QpI+T42/ZD8HeNdV+HmvT+JfEOk678PvjzefGy31PTFtUk1yy1L4g6b8TNS+GmsQSK8E/hG/ 8W+GvBWryy+WdVh1DwfpdzZ3Vss17BcfsE8Xnj5nGva0pcsI1al5RcnGN5zqyV4xaqXUI8zg4tJT tD8zhh8pVlKle6jzScI+61GMpWjGnHSUlKGspcsZKSbcW3wV1qf/AAT8sGmhv/hb8JbC/TWdB0G2 0W//AGbLqy8R6xqPizTfF+reEf8AhGvDV18NIvEHirT/ABjZ+AfGQ8H6z4b03VdH8V3nh3UtN8PX +palEto79H1L/gnp4g0vUtY0LwD8CdXsNO0/wxqaNp3wM067uddtfGOrP4e8Ojwbp8PgR9Q8eXd/ 4oim8Hyad4Ktdf1HT/Glvc+DdStbPxRbXGkxv+Hf7DuleCfHPh34gap8T/Eni7xDoGt/C3WLjUdT 0q1TVfFVz8K/Bnx68IWGreMdZuL/AFLUdf8AF3ipvj3rmveM/EsssI1HVNIs4tL0vRdOmWytLXjH 9hrwX4ws/BsN54p1FrvwD4J8H+FPDkmoaNp+q6cb3wf44XxrBq2s6Q89tDqtpqqyah4e1TRmmt8a TqU1xp2o2GtW9jqlrKx2fODk3FT/AHn7v29S7tb2T51iHFXTbkrPWDjzRUlKLeFyfm5Vzctoe/7K DV2v3i5XQTsmrJ3WjTtKzT9V8K/BL9lDxvoGneKPC3wS+Bmr6JqiTm1u4vhN4LgkSezup7DUdPv7 K88OW9/pWsaRqVreaTrmiapa2er6HrFlfaPq9lZanZXdrD0P/DNH7OP/AEb/APBL/wANT4E/+UNd d8L/AAFYfDHwNovgrTotDit9KfV7mT/hHPDdl4R0ea/13W9S8Qard2ugafNcwWT3up6reXl5JJd3 t7qF9Pc6lqV9e6jeXV1N39ehTxWMcIOpXrRqOEXOMa1RxU2lzJPneildLV6dWcU6GGU5qFKm4KUl BunC7jd8rfurVqzei16I8S/4Zo/Zx/6N/wDgl/4anwJ/8oaP+GaP2cf+jf8A4Jf+Gp8Cf/KGvbaK v61if+giv/4Oqf8AyRPsKH/Pml/4Lh/kem/8E4Php8OPh1+3toQ+H3w/8E+BRrP7IX7Rx1ceDfCu heGBqp074zfse/2edSGiWFj9uNj9vvvsf2rzfsv2y78jZ9om3/0VXl5Z6dZ3eoahdW1hYWFtPeX1 9eTxWtnZ2drE89zdXdzO6Q29tbwo8088zpFDEjySOqKSP5UdI/aO8e/suftIeD/iV8OvgV4s+P2v XH7N37QPhefw94XvtP0uz8H6Tq/xb/ZIub74keNdV1OW3s9N8D+Fv7NiTWbu5u9MskuNS06PVdd8 NaPJqPiTSf0p8Ga148+OGl+H/iZ8b/2Uv2qP2sdN1ZLTxB4V0jQ/Gn/BPax/ZWsgkq3FjqXgv4V6 H+3z4l0DxulpdwpeaP4p+Lfir4veJNIv45Lrwzr+gwuLKL8y4zyevi8xo5lisVQo4WeEpUYTq4vC LFV6tOrX5oU6WJxWHjHkUoXliK1FOneVBVnTlBfe8LZjSw+Bq4KhQrVa8cTUqyjTw+JdClTnToKM p1KGHrN8zUrRo06rUrKq6SnGT/X/AEvVNM1zTNO1vRNRsNY0bWLCz1TSNX0u8t9Q0zVNM1C3ju7D UdOv7SSa1vrC+tZormzvLaWW3ubeWOaGR43Vjfr4W8Nan+3p8TtS8ba3pFp8IP2TfAmneJrHQvhv 8OPjv8Covjp8UtX8LWngfwdd6l4x8R+J/wBn79u7R/htosN9481Dxp4f0Hwrp6Xuo2fh3w1pWsap eC41z7DZdZ/whf7e/wD0cr+yF/4hD8Zv/pg1fATy+hCXLPNctpytGTgpY3E8nPGM1CVfCYGvhqk4 KXLN0as4KcZRTurH2MMZVnFSjl+NnG7Sm44WhzcsnFyVLE4ulXhGTTlFVacJuNnbVX+vaK+Qv+EL /b3/AOjlf2Qv/EIfjN/9MGo/4Qv9vf8A6OV/ZC/8Qh+M3/0wap+pYb/ob5d/4Kzb/wCdn9Wflevr Vf8A6F2N/wDBmX//ADf/AFZ+V/r2ivkL/hC/29/+jlf2Qv8AxCH4zf8A0waj/hC/29/+jlf2Qv8A xCH4zf8A0waj6lhv+hvl3/grNv8A52f1Z+Vz61X/AOhdjf8AwZl//wA3/wBWflf69or5C/4Qv9vf /o5X9kL/AMQh+M3/ANMGo/4Qv9vf/o5X9kL/AMQh+M3/ANMGo+pYb/ob5d/4Kzb/AOdn9Wflc+tV /wDoXY3/AMGZf/8AN/8AVn5X/Of/AIK3WnjW9+Pn7HsXgPxB4X8N6wvwg/a/kuL/AMXeD9W8baZL pg8Z/scLPaQ6To3jjwBdQX0l09lNFqL61c28Nvb3Vs+lzyXkV3Y/nP8A2D+0d/0Vb4Jf+I/+O/8A 6Jevr3/gotoH7Vem/Hf9mZPG/wAV/wBnzxpr9x8GP2qT4Sn8K/s+fEf4Y6PpFtD4+/Y//wCEkj8R 2ur/ALTXxcvfEc+pRy6SdEl0y88LR6I9hqIv4dfXV7ZtE/CD4033xt8D6LZ28njH4tHxt8VPi9+1 9qbaFf8Axa1vwdB4d+HPgH4g/E+w+DfiTwpLY6hZy6X4a8KeFvF3gTxmfDNlJFYfEO0g8PaD4uuv 7FttJj0r9myDG/2dwzk0IKji6UcNjJfWKeHUqcnLOcbBRi8Tho4hyVSrGDjKlF+7OVNTik5fmGcY X67n2Zym6mGnKthY+xnWanHlyvCycpKhXlRScKbkpRqS1cYycW3b9DZB8c4RemX43fs+xDTdTsNF 1EyfA/xgg0/WdVXTH0vSb0t+06Psup6kmt6M9hYT+XdXi6vpjW8Ugv7Qy6v9g/tHf9FW+CX/AIj/ AOO//ol6/OHx78FfiV4iv/Evxf8AgzpWu+N/D3xr+N37IMPiqO7WXTLzxp8IfB+jfsneLPB3xwt4 PFFzZ6v/AGl4C13wz490TxFZ6q6axJ4d8WeJ77Vo573wZp9u/S6hYftaeJ/iB4mg03TfjL4F8DeL PHfwsXxHZW/i7xRf3/h6Kz/aZ0uy8ff8I14o13WLi30/Srv4N6he6nct8KdJ8P8AgSLwxNb2Nm2t 6/4b1XVY/U/tnEKUoywUWlzckqeFoTjUjzVuScJ/VlBxlGFJy966dSXKpwgpy85ZZRlGLjimm1Hm U8RVjKEnGlzRlH2zknGU6iWlmoR5uSU2o/fP9g/tHf8ARVvgl/4j/wCO/wD6Jej+wf2jv+irfBL/ AMR/8d//AES9fDXiXwT+1r4S0i4t/h/4p+MfiG41fSPjhpPiC58V69L4ludN8H+A/wBrP4N+H/hm 3hqOW50qe28a63+yje/F+/0nWdHvbHx74+1VLfW9Q8RXfjOx0HUrL7e/Z00/xpp3wxsY/HHiHW/E OoT634judJbxJ4f8T+H9e0bw3JrF0ui+HtTXxvr3iPxprD6TbxtFaeIPFmpzeINV017KbUpbudTq N70UMzrVqvsnhY0rUo1XOeFwnJ76jKMIv2ScpRUkqll7kvdd78xjVwNKnT9osQ6l6kqajGviOZ8r acn77UYtr3Ltc8dVbYn/ALB/aO/6Kt8Ev/Ef/Hf/ANEvR/YP7R3/AEVb4Jf+I/8Ajv8A+iXr22iu z6xU/lof+EuG/wDlJy+xh3q/+D6//wAsPEv7B/aO/wCirfBL/wAR/wDHf/0S9fkH/wAFWLD4i2P/ AAob/hYfinwV4o83/haP9j/8IZ4B1zwH9h2f8K7/ALQ/tL+3PiT8R/7V+1b7L7H9l/sb7D9nuvP/ ALR+2Q/Yf3pr8S/+Cxf/ADbp/wB1d/8AeYV7XDtac84wcWqST+saxoUIS0wtd6ShTjJarWzV1dO6 bT8zOKcY5diWnUbXsfiq1ZLWvSWsZTcX807PVan+hpRRRX8jH9IBRRRQAUUUUAFFFFABRRRQAV/n F+KPFf7V2t/Ef9mT4P8A7Nvi34j6Zqdp/wAE6fgp8T/D2keG9a+GWl/DrTvGh8daJ4Sv/FPxhsPi CxvfEXghPCc1xZ3ei+DdP1vxTPqEGlHTbC3i+23qf6OlfxQ/s9/Gr9mvRPg38D7jWvi18DtI8caR 8Dvhp4S1afVPHngKw8V6XDYeFtFe/wDDOoy3eqxavZR2WrxSvd6LctEttqUUjTWyXSMR+l8A4Ktj 8DntGlPEU7YvI5zlhudVeSMM4uoygm4tu1pNNJpO17W+E4wxdPB4rKatSFGd8PmsYRr8rp8znlmr jJrmSV7pNXva9rnxF+0v+354xvvAvxa+GXg7V/B2jeN08M/8FHtG1G78G+KtU0n4ifD6T9l7xHb+ HPhTr0cul63Pq/hfUfFel3b6rqWoz2SNNdLDf+G1sreM28vnfxZ/bO+NPiu71qxu/FHhPHwssf2r oW8a/s1+P/G9p8JPirYWX7B+q/HDwillr9vq0WpT+Ivh94hv7SC/u7PVJJdJ1mz03XNLXRry6Frb /rDJ8U/2MZtQ1LVpfiP+zDLqmsx30OsalJ4v+FL6hqsWp262mpRaleNqJub6PULRVtb5LqSVbu3V YZxJGAtEfxT/AGMIrMadF8Rv2YY9PEmsyiwj8X/ClLMS+IrGXTPEEgtV1EQeZrumzTafrL7N2p2M stpemeCR4z9xVyPOKspuWJxCU3h/dWFq25MO01Fq9r1Jp1JyWqk3DWnKSfydPNcspxglh6LcVV1d enfmq6OV7X9yH7uMdmrTbU4pn5wftIftq/GW5+Dv7XF34K8YfDL4aSfBLW/h/wCBfCuj6f4g1Kb9 oi41xPEH7Per6x4/ubHUryfS28Ba7pPxF1rQ7eyOhTXctg+navc+I7oalPpcXD/F79v74u+F/jVp XxHn1DwFN4M+G3hj9v1bT4E+DvHfiOx8WNJ8D/E/hP4d6Lq37R2hz3raNCr6ppGoeMvDmoDSLIeF /DOpax9me7nmuNRH6taj8V/2NNXu9Sv9W+JX7MmqX+sWNrpmr3uo+MvhXe3eq6bZXFpeWWnalc3O oyzX1jaXen2F1a2l08tvb3FlaTxRpLbQsjl+LX7G6arfa6nxM/ZmTXNTF4upayvjP4WLquoLqMC2 uoLfaiNSF3di+tUW2vBcTSC6gVYZ98YCh1ckzipOclicTC7o8tsNVai6OKq14T5LqD9ycaUqdlCS inPmUYxFTzXLYRjF4ejK3tL/AL+mm1Vw9OjOPNbmXvQlUU/ii5NR5eaTfwZrX7dP7UcHhD7Vofg7 9n+517RPB37T/wAQdZ1y/wBV1i98OeJfCH7PXhL4D+NYLzw7ofgfx140m8Oa14hT4q694Qk8PeIf Gd/LBPoum+OP7Qh0u8g8MajzQ/ak/aC8UfErWbfxD418BWnhc/tffsfaH4A8BeFbzxDoHjPwv4H+ NHgL4X+K00/xPe6PrOkz+OfCEtn43lPiRPEGnzafrPjR9WsrRbXw3Z6JpOn/AKKaf8VP2MdJsTpm lfEf9mHTNNaz1jTm0/T/ABh8KrOxOn+IhZL4gsTaW2oxwGz11dM01dYtjH5GpjT7IXqTi0g8uU/F z9jg36aqfid+zOdUi/sjy9SPjT4Wm/j/AOEfZG0DZeHUvtCf2G0UbaRtkH9mtGhsvIKKRUsmzaTX NiMW0pQfI6NXltGhKm4vljDnTqSVS9RS5nFOV5pSSjmmXR2oYdPlkuZVKd7urCakuZy5fci4e7ay k1FqLcX+OXwT/at+PXwd8K658S/iH4gb4meJvEXwu+LXjiGPW/iL8ULzwTa61eftreB/2fdM1bU/ DXjDxhqPhfwloHg86xqWorp3gy38J6PpngPSbfT4bjTNR1DxHrl394fA/wDas/aR+LHxg+HXww1H wf8ABrQLC88I/EP4g+NvEkWqX2sy+IvBPgX4o2/w9stT8CWHhTxn4u0jw3rHimHW9Fvn8O+JvE/i CXwrcWGtQX2o6q1xZRQfUMXxi/Y+gikgh+Kf7NcME2l6pocsMXjf4XxxS6Jrl4+o61o8kaamEfS9 Y1CSS+1TT2BtNQvJHuruGadmcv0X4zfsheG/sf8AwjvxW/Zu0H+zrC70rT/7F8dfDHS/sGmX+of2 tfadZ/YdUg+y2F7qv/Ezu7ODZb3Gof6bNG9z+8ow+SZpQdKPt8W6VONJTgqFROpOEoOrKUnGUn7V Rab5k466y55Cr5rgKyqS9jh1UnKo4zdWLUIyi1CMYpxilTbulytPRaKKR/QJ/wAEsv8AkzDwr/2W 39sf/wBbM+P9fobX5y/8En9S07Wf2H/AusaPf2WraRq3xf8A2vNU0rVdNuoL7TdT0zUP2xPj1d2G o6ffWsktre2N7aTRXVpd20stvc28sc0MjxurH9Gq/E+JU1xHn6as1nWapp7p/Xq+jP1bI2nkmTtO 6eV5e01s19Uo6hRRRXinqBRRRQAUUUUAFFFFABRWTda/oVjq+k+H73WtJs9e16DU7rQ9EutRs7fV 9atdEWzbWbnSdNlmS91GDSF1CwbU5rOGaOwW+szdNELmEvrU2mkm00pK8W00pK7jdd1zRlG60umt 0xJp3SabTs0nezsnZ9nZp2fRp7NH8iX7NH/JuH7P/wD2RL4U/wDqCaDXttfGf7Pf7QnwD0T4B/A/ Rda+OHwg0jWNI+EHw00vVtJ1T4l+DLDU9L1Ow8GaLaX+najYXetRXVlfWV1FLbXdpcxRXFtcRSQz RpIjKPX/APhpf9nH/o4D4Jf+HW8Cf/L6v6lxOGxLxOIaw9dp16rTVKo006krNPl1TP5+oV6Ko0b1 qX8Kn/y8h/IvM/J39oL9ob4l+Af2hv2tdQ8G/tD+JI/id8Lfih+yh4V+An7Kb694IvvDnxc074le F/hFJ458NRfDfUtCvPHOvTau3iLxDdnXPBer6Tqnh+4aTUor63itJwfSvDv/AAUF+O/jTRfjR4h8 K/DT4W3Fj4XtvGx8F6bqHjDw7p3iLw5qXgf4/eGfgzdaJ400XVfifpN74w17VdE1jW/GNjpFtB8K seJdA074W219qeteMdC1sfeK/GD9j1PE0njRPil+zUvjGVBHL4sXxv8AC9fE0iCyTTQkmujUxqjo NOjjsArXRAso0tceQqxijdfE79iu9n125vfiF+y7d3PihI4/E1xdeLPhPcT+IkhuYL2FNdll1B5N XSK8tba7jXUGuAlzbQTqBLDG6/P/ANi5sqtWcMRioQqTryVONCs1H2tWtUpzUqntVGVONVUXCMI0 3GlTmoqcEey80y6UKUZUKEpU4UI87q01f2dOjCpFxp+zbjOVOVVSlKU+apUi24ybPzO8W/tyfHzW dM+PPjLwT8YPhTH8PYf2Zf2UPiR4FXTPhzqlp488I/8AC1viHqvgb4u/FnR/DniHVdS1C+0jwVY6 P468R6xpniSDxTonh+08P/D8QXFzFJ4tvfEfZeBf2nPiD4f8Za/8HPgN4+m+OHiPUvj18Kfhpp/j n4/fFrwp8WfAbeG/HXwi+PXj608beGdc+Cfhnw1qem3uqaZ8INM17VfBep3epWUc+qR6Vpa+FP7Q udTt/wBFLb41/sj2d5aahafFr9nK1v7DQY/CtjfW3jz4ZwXll4YidJYvDlpcxaqs1toMUkaSR6PC 6aejojrbhlBGfonxU/Yx8MiJfDfxH/Zh8Prb6iurwLonjD4VaUIdWWwvNKXU4hYajbiPUV0vUdQ0 1b1NtyLC+vLMS/Z7qeNyOS5sqlObxGKdnL2lqOId4ynWnKNNVJ1FC6qwgr8zhHD00nJNKmPNMucJ xVCgrpcn72ikpRhQjFzcIQc7OlOTa5eZ1ptpNNy+YP2dv22viT8Wf2g9O+GGv6f8FtV8K+Jb39qb Sbe0+GWveINV+JHwvvP2cfi3aeAdOvfjFpl9Pdabotl8RdH1G0u9Hhiisng1QW/kXWoW+qJbaf8A p5Xx/wDDLxh+xX8IrPULbwT8XvgJYXWq67408Qalrc3xN+HM/iK+ufHnjjX/AIha1aXmu/2rHqV5 pkHiDxHf/wBl2V1PNHYWMdnaIX+zLIfU/wDhpf8AZx/6OA+CX/h1vAn/AMvq7sHgcypUbYqNetVb Um1RqWhenBSgnyLmXtFOadklz8kUoxijkxWLwVSrfDulSpqPLb2sLzanJqbXNaL5HGLSb+HmbcpN h+0v/wAm4ftAf9kS+K3/AKgmvV/XbX8Wf7Qn7QnwD1v4B/HDRdF+OHwg1fWNX+EHxL0vSdJ0v4l+ DL/U9U1O/wDBmtWlhp2nWFprUt1e317dSxW1paW0Utxc3EscMMbyOqn+0yvgfEqnUp4bIFUpzpt1 85aU4yi2vZ5RqlJK6PseBZwnWzhwnGaVLLE3GSkk+fMtHZsKKKK/KT9DCiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACvw2/wCCsmrX+hfHT9lHVdL8Ma54zv7T4Iftem38NeG7jw1a 63qZl+Iv7FEEi2M/jDxD4U8ORtaxSyXs/wDaWv6erW1tMls1xeNb2lx+5NfhV/wVu8Qat4b+Pn7H t/o3gfxR4/upfhB+1/aPovhG78FWWp21vJ4z/Y4mfVJpfHnjDwTo7WMElvFaSx2+rT6mbi+tWg06 a1S9ubP67gWLnxPgIxai5UM2Sk5Qjyt5PmGvNU9xW3vL3e6a0PnOLZKOQYyTXMlVy5tJSldf2ng9 LQ95368uttmtz8G/E37avxB0jx74z0W2j+GNs3hr4ieLPh3/AMKe1Oylu/jDplvov7KWpftDW3j7 xBq2g/FHUNEOg6b4hsh4I12w0bwrfaTcpHeXuk+PGlSCOfIb9qT4xeGvFXg6y8Y6t8JtP1j4o/DL 9m3XW8d3GlePtH+FPwqtvi34h+OmozP4k8Iax8XrjT9bks7TwNpvgbT/ABNZ654A1Txb4u8S+HX1 SSz0mz0vwxa/VvhnUbvwhrHjbX9B/ZP+NFpq/wAQ/Esni3xXfSeI/wBni8n1DWpvD3hnwvNJG95+ 0LO1lZy6R4R0GJ9MsjBpxuLR7sWwubieSTq5viP4tuY5obj9lv4xTxXEEdtcRTat+zXLHPbQtI0V vMj/AB9ZZYImllaOJw0aNLIVUF2J/XllePbcpY+lf2lSUYqvh5RUJOyi39Zi+bl+1FQ5G37NRfvP 80ePwiSjHCTt7OnGT9jVUnOPK3JfuJacyeknLn09pzLQ+GfEP7WHxt8T+AvjxfaXP8LIdB+E37K3 xm+KWs63o+kfEK1vfiLq/hHxx+0/8LfD+rfDnX9B+J2jXvgXwl4vT4MeHviJouu2eq+LNY07SNYk sPD/AIg1OTUdK8a6P1WoftV/En4R+If2k/FXxF1/wt44+GHws/aMm8DX/hnRfCVzpXj34feCvEXw H8OeLfhe0d5Z+KNRi1eDxp8TdW8N/D3TH1bwzDdar4k8T6rq9lq4057Dw14e+vD8R/Fphktz+y38 Yjby2iWEsB1b9mswy2MaypHZSRf8L92PaRpPMiWzKYVWaVVQCRweZ8WaxfeOLAab4l/ZP+M1/aHx D4L8UzIniL9neye71n4e+KNJ8ZeEZr+ax/aFt5tQttK8Q6Hpt4NPvXnsLqOBrS7tp7OeaCRvK8co qUcfSdWKUk5YiioSnGFZRU4rFO9NynS5ovmVqcpJKpPniLMMI24ywk1Sk2pKNGrzRhKVFycZewTU 0oVOWS5XecU7whyv3rwc/iqXwh4Vk8dxaNB43k8N6G/jKDw6lynh+HxU+mWreIYtCS9u7+8TRo9X N4mmJd397crZCAT3dzKHmfpK8S/4Wt47/wCjaPjb/wCD79nH/wCiAo/4Wt47/wCjaPjb/wCD79nH /wCiAr0VhqiSXPRdkld4rDNuytdv2ure7fVnC68G2+WortuyoV0lfol7PRLoe20V4l/wtbx3/wBG 0fG3/wAH37OP/wBEBR/wtbx3/wBG0fG3/wAH37OP/wBEBT+r1P5qH/hVhv8A5cL20O1X/wAEV/8A 5WfeH7CP/J+/hD/s0L9pr/1c37GVfq94n/Zc8MJ4g1bx/wDBXxLr37PHxM1m8k1TXde+HEWnnwZ4 61STb5t38U/hHqsFz8PfHt5fLHHa3/iyTSdH+KEOnK9n4e+Inh4uJ1/Gv/gnB4q13xP+3toR1v4a eNvh19h/ZC/aO+yjxlf/AA4vjrP2r4zfse+edN/4V98QPHQiGnfZ4ftn9rnSi/2+0/s8X2y++x/0 Z1+P8cV8Rg8+h7KqouWXYeNSMZU61GrD2+Il7OrD95Qr072bp1I1IXVpRurL9L4SpUcTlE/aQ5rY 6tKEmp06tOXsqC56cvcq0p9pwcJW2dmZujxavBpGlQ+IL7TdT16HTbGLW9S0fSrrQtI1DV47WJNS vtK0S91nxFe6Ppt3eia4sdKu/EGu3Wn2skVpcazqcsL3s+lXzh8dvjP47+H3iH4WfDv4SfDXw/8A FD4o/Fe/8XyaTpPjX4har8K/A2heFfAPh4a14p8S+JfG+h/Db4tavaMl7qHhjw5omlWHgXUpNV1n xLatc3mlabZX1/DvfAz436Z8fP2dPhZ+0N4T0S90/Tviv8JPCvxS0jwvq0ss2paS/inwtaeIl8Ma rcaFY6zJPqGk3V02i6hc6Hp2sCe6tZptJtNSR7aOf4Fu7bdrttuySWuuiSSS7JJJbJJH2KVkkr2S S1bb07tttvu223u3c9xor5D/AGMv2gvit+0d8NvFHjL4u/AXW/2evEGh/E/x/wCB7Dwhr99qN/fa no3hTxFe6VZ6+k13oOkWrQSmCTS2nsrm9+3X2l32oXNl4alul8Oad9eUhhRX5+ftgeMli+LnwL+F fij4/eJP2b/hd4w+F/7TfxC8RePfCutad4M1PUfGfwmsfhLH4M8PyePdXs7rT9HsNJ8O+PPiN8VL vQGaH/hKv+FYxQ6pHqXhLTfFGj6j137NXx2vPjV+yl8A5/F3xN8E+Ff2m/iv+zx8MrnxVo5vfDye I/DPxz8Zfs9+E/it4ksH+HsOo6dfx6x4fsfFNt49uPB8cFhdQeErix1QxWmi3dtfEA+1aK+Uv2O/ hH+0H8F/hbrnhP8AaT/aAb9o/wAd3vxM8d+JdH8cyeHT4cl0rwNrepRS+F/CUsBvLs3cmmQw3OpM 6LbWmj/2z/wiumpe6X4estX1L6toA/Cr/grdd+NbL4+fsey+A/D/AIX8Saw3wg/a/juLDxd4w1bw TpkWmHxn+xw093Dq2jeB/H91PfR3SWUMWnPottbzW9xdXL6pBJZxWl9+Z+tJ8b/Eltb2fiL4G/s9 a/aWl7b6la2utfG3xdqttbajab/sl/bwX37MM8UN7a+ZJ9nuo1WeHe/lyLubP6sf8FQP+Tj/ANkP /siX7Yn/AKnf7F1fFlfvvCU4LhbJIzoUqt6GOu6jrXf/AAsZlo1CrCNl/hv3bPx3iSM3xBmko1qk P3uEsoKno/7NwOqcqcpX+Z4l/b37R3/RKfgl/wCJAeO//oaKP7e/aO/6JT8Ev/EgPHf/ANDRXttF fRe2p/8AQLQ/8CxP/wA0Hiezn/z/AKv3UP8A5SeJf29+0d/0Sn4Jf+JAeO//AKGij+3v2jv+iU/B L/xIDx3/APQ0V7bRR7an/wBAtD/wLE//ADQHs5/8/wCr91D/AOUniX9vftHf9Ep+CX/iQHjv/wCh oo/t79o7/olPwS/8SA8d/wD0NFe20Ue2p/8AQLQ/8CxP/wA0B7Of/P8Aq/dQ/wDlJ4l/b37R3/RK fgl/4kB47/8AoaK/IP8A4KsX/wARb7/hQ3/Cw/C3grwv5X/C0f7H/wCEM8fa548+3b/+Fd/2h/aX 9ufDb4cf2V9l2WX2P7L/AGz9u+0XXn/2d9jh+3fvTX4l/wDBYv8A5t0/7q7/AO8wr2uHakJZxg0q FKDf1j3ouu5K2FrvRTrTjqlZ3i9G7WdmvMziEll2Jbq1JJex92SpJP8Af0t+WnGWm+jWu91of6Gl FFFfyMf0gFFFFABRRRQAUUUUAFFFFABX8iX7NH/JuH7P/wD2RL4U/wDqCaDX9dtfxZ/s9/tCfAPR PgH8D9F1r44fCDSNY0j4QfDTS9W0nVPiX4MsNT0vU7DwZotpf6dqNhd61FdWV9ZXUUttd2lzFFcW 1xFJDNGkiMo/VvDWnUqYbP1TpzqNV8mbUIyk0vZ5xq1FOyPzzjqcIVsn55xhelmduaSjf38t2u1c +zKK8S/4aX/Zx/6OA+CX/h1vAn/y+o/4aX/Zx/6OA+CX/h1vAn/y+r9J+q4n/oHr/wDgmp/8ifC+ 3of8/qX/AIMh/me20V4l/wANL/s4/wDRwHwS/wDDreBP/l9R/wANL/s4/wDRwHwS/wDDreBP/l9R 9VxP/QPX/wDBNT/5EPb0P+f1L/wZD/M9torxL/hpf9nH/o4D4Jf+HW8Cf/L6j/hpf9nH/o4D4Jf+ HW8Cf/L6j6rif+gev/4Jqf8AyIe3of8AP6l/4Mh/me20V4l/w0v+zj/0cB8Ev/DreBP/AJfUf8NL /s4/9HAfBL/w63gT/wCX1H1XE/8AQPX/APBNT/5EPb0P+f1L/wAGQ/zP1S/4J3ftT/DL4cfsuaV4 M8Q+GP2jtR1jRvjb+1z9svPAX7HX7XPxU8Jzf2j+118c9Vt/7K8e/DD4IeMPA2veXa30EV9/YfiL Uf7L1JLzRtT+yaxp2oWNr9vf8NvfBn/oS/2vf/FfP7e//wBDVXkX/BJ/UtO1n9h/wLrGj39lq2ka t8X/ANrzVNK1XTbqC+03U9M1D9sT49XdhqOn31rJLa3tje2k0V1aXdtLLb3NvLHNDI8bqx/Rqvwn iKplkeIM9VTB4+VRZxmaqSjmOHpxc1jaym405ZXUlCLldxhKpNxTSc5NNv8AXslhjnk2UunicIoP LMA4KWCrTkoPC0XFOccfBTaW8lCKk9VGK0PkL/ht74M/9CX+17/4r5/b3/8AoaqP+G3vgz/0Jf7X v/ivn9vf/wChqr69orx/a5T/ANAWY/8Ahzw3/wA6PX+lr6Xs8w/6CsF/4QV//nj6/wBLX5C/4be+ DP8A0Jf7Xv8A4r5/b3/+hqo/4be+DP8A0Jf7Xv8A4r5/b3/+hqr69oo9rlP/AEBZj/4c8N/86PX+ lqezzD/oKwX/AIQV/wD54+v9LX5C/wCG3vgz/wBCX+17/wCK+f29/wD6Gqj/AIbe+DP/AEJf7Xv/ AIr5/b3/APoaq+vaKPa5T/0BZj/4c8N/86PX+lqezzD/AKCsF/4QV/8A54+v9LX5C/4be+DP/Ql/ te/+K+f29/8A6Gqj/ht74M/9CX+17/4r5/b3/wDoaq+vaKPa5T/0BZj/AOHPDf8Azo9f6Wp7PMP+ grBf+EFf/wCePr/S1+APiV+0R+yt8YNAj8NfEb4RftXeJdNtb2HVdKml/wCCfv8AwUD07XPDeuWq utj4k8IeJ9H/AGdNP8S+DfFOm+Y76V4p8K6vo/iHSpGMunalaynfXzL4i/4KFaZ+yba2Oo+NZf2o fjN8CLjWtI8O2+ufEn9i/wDa0+GHxu8C3eu3sWnaRY3PjLxt8A/Afwq+MWjrPLHb241nU/AHxPgs bZ5JNQ+Mfii82N+oPxUtvjbqVvo2j/BvU/hx4VOpTXqeKfHfjuy1/wAU6h4WsI0tvsZ8I/DvSG0L TvFesal5l9GL/wAQ+PvDml+F57WxvptA8cwXVzo9vyHw/wD2Z/AHg7xLa/EbxPe+I/jJ8YreG4hi +L3xcvrPxN4t0mO9QJf2ngXTLPTtJ8D/AAn0e/VUW/0H4T+E/BOj6mY0uNWs9QvvMvJPWwmLyWjh 0sZQx2Iw8ueVPLv7RoVanPe3tFV/sqmsvVSUHzVaFaWImo0/a4Wth5Jy87EYfNKlb/ZquFo1oqKl jfqVanDlsnyOn/aE3jHFPSnVpqjHmmoYilWi7fyLfCn9ofw34V+Bf7M3gfwdp5+JvxO1/wAB/Cjw TZeBtD1vRtIlsNVi+CWo/EC9m8RazrVzb2GjWkHhfwL4ie32re3V3rK6dpf2WCC5vNR07zj9n/8A buvPG3hz4L+D/EuhtqvxR8YfCzw5rnibVLjV/CGl38fizUvgxqfxivNW/wCFfaVfJqNx4Bs9J0yP RdY8Z6N5Wg2njfVtM8IWC3E9w13B2Hw78c/speM/2c/2evCnxK+MHwwstV8FfDr4Z31vBD8brHwD 4x8H+LtP+GieFNSa11fw14y8OeLPDmsRaVrfiPwzq9vBf2U8um6rrGialFJa3l5aycL4e8FfspeD viVJ4m8G/tW/B3wr8Ppb3wzef8K90T4oaZZXUVj4W+HWifDa08GLrUPxbTwtfeA7/StBtb7VLDXv hzrXjGa9uryC08d2OmQ6LYaN+2Zjgs6eYTqUIVJUXi6sZQjSkl7CU1JycZws5pwcfaKrN8tROnTh afN+VYLE5WsHGFWUFV9hTcZSqJ/vYxcbKUZK0WpKXI6cVeHv1J3ilrfCv9tLxprF34K0D4j6R4N0 jxhpXwL+Lfj34qaRHq+k+E9JudY0HXf2Y5PhL4w0LxD4q8S/2b4c+H3jnwT8b7/V9RbWrm+udM16 11Xwva3Goax4OvbPVOlsv2/tE1jRZdZ8NfCLxl4sXQdB8Z+JvG6eHvEngWS30fRvh58VNU+Evii4 8O32r67o8Pi+WbWNKm1rwxDGujjWNAdX1OXw9rGNHbo9cX/gn74kvLDUtY8f/AK51TS/hrpnwh03 V4vjRodjrFh8PdD8T+H/ABroOhWer2HjS11K2n8P+LvC2geJfD+uw3SeItC1vTo9S0nVrO6muZZl 0lv2BtEg1i3sPid8FT/wkOheIPDmvXN/8fLPV9R1nS/Ffim58beJBqmqat49vtSvtR1rxXe3eu6h rdzdya1cX1xM76hsdkPNHLs9i3FOThytKUqNSVRyUacYNqWHcU/ck6jTalKpKShFpG8sblMve5Up c13FVIKCTlKUkuWvGTXvJQWjioxi5SVzD8Sft++EPB93e+HPEvw88Taf4/8ADuqfEW28YeC49b8M Xl1p2n/DWw+HOuamPDOoQagYPG3ifxFoHxY8E3nhDwvpMMJ1PUpta0bUtW0WbS7efU/vqGVZ4Yp0 EipNGkqLNDNbzBZFDqJbe4SK4gkAIEkM8Uc0TZSVEdWUfFes6h+wvrmr6l4hm+MXwr0rxDq+va14 j1PxB4S/aSm8Da9e6n4j0XwZ4e8QJPrPgz4j6DqT6RrWk/DvwPBqnh37UPD19P4W0bULnS5NRs0u 69r/AOGl/wBnH/o4D4Jf+HW8Cf8Ay+rrw+DzSM631iE6kG4qgoYeopRik1J1GqcU5ydm+Vcqd+VR WhzVsTgJRp+xlGE7SdXmqwcXJ2sqd5yfLHVLmfNa13J6nttFeJf8NL/s4/8ARwHwS/8ADreBP/l9 R/w0v+zj/wBHAfBL/wAOt4E/+X1dX1XE/wDQPX/8E1P/AJE5/b0P+f1L/wAGQ/zD9pf/AJNw/aA/ 7Il8Vv8A1BNer+u2v4s/2hP2hPgHrfwD+OGi6L8cPhBq+sav8IPiXpek6TpfxL8GX+p6pqd/4M1q 0sNO06wtNalur2+vbqWK2tLS2iluLm4ljhhjeR1U/wBplfm3iVTqU8NkCqU5026+ctKcZRbXs8o1 SkldH3XAs4TrZw4TjNKllibjJSSfPmWjs2FFFFflJ+hhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABX4pf8FQP+Tj/ANkP/siX7Yn/AKnf7F1ftbX5Lf8ABR34K/Hn4h/Ff9m3x78H fgx4o+Mek+B/h5+0b4Q8XWnhLxX8IvDWqaFqPxE8Sfs26z4VuZovi18SvhrZ6hYX1t8M/FUU0mjX 2p3NlcW9ot3aRRXsM1fU8F1qGH4kwNXEV6GGoxo5lGVbE1qWHowdTKsbTpqdatOFOHPUnCnDmkua coxV5SSfz/FFKrWyPF06FKrXqupgXGlQpVK1WShmGFnNxp0oynLlhGU5csXaMZSeibPzoors/wDh RH7Z/wD0ZB8bf/DnfsZ//RU0f8KI/bP/AOjIPjb/AOHO/Yz/APoqa/Y/7Syr/ocZL/4ecs/+az8x +oZj/wBCzNP/AA2Y/wD+ZzjKK7P/AIUR+2f/ANGQfG3/AMOd+xn/APRU1yHxA8CftQfCzwN4u+JP j/8AY7+MnhrwR4E8Oax4s8V69d/Er9j2eDSdA0Gxn1LVL1rWx/aiur+8eG0t5WhsdPtLvUL6by7S wtLm7mhgkqGPy2pONOnm2TznOUYQhDN8tlOc5NRjGMY4puUpNpRik220krsmWCx8IynPLszhCMXK UpZbjoxjGKvKUpPDpKKSbbbSSV3oR0Vk/CvRf2jPjX4ZufF3w2/Y++OWuaPYeI/EfhDVotQ8Yfsr +EvEPh/xV4S1W40bxD4b8U+DvGf7SPh7xj4T17TL63Jm0fxNoOk6k1lcWGqRWsmmalp93c+k/wDC iP2z/wDoyD42/wDhzv2M/wD6KmnUx2XUak6VbNMopVacnCpSq5tltOpTnF2lGcJ4pShJPRxkk09G hQweOqwjUp5fmVSnOKlCcMuxs4Ti9VKMo0HGUWtU02n0OMors/8AhRH7Z/8A0ZB8bf8Aw537Gf8A 9FTR/wAKI/bP/wCjIPjb/wCHO/Yz/wDoqaj+0sq/6HGS/wDh5yz/AOay/qGY/wDQszT/AMNmP/8A mc9Q/YR/5P38If8AZoX7TX/q5v2Mq/f2vxM/Yb+A37SXhr9rjTvij8Uv2fPGvwf8D6D+zn8Z/AJ1 nxl41+BPiBtU8V+PPiZ+zj4h0LTNN034T/F/4laqoGkfDTxTd3t9qljpmn25gs7dLqa5vI4R+2df knHFfD4jOac8NiMNiqccDQg6mFxFHE0lNVcRJx9rQnUpuSUotxUm1dXSP0fhOjWoZZONehXw85Yu rJQxFGpQqOLp0YqXs6sYTUW4ySbjZ2dro+ffjh+z5Y/GjU/ht4osfiX8TPg54/8AhPrPiXVPB3xD +FMvw/k8Q29l4y8J6l4R8U+G9S0r4p/D74oeBtX8P6zaXun6rLDf+EJtSste8N+HtS0vU7A2l1Df UPhb+zfafBnw18NvAXw/+Lfxa0j4Z/Cez+HOg+DvhzPL8M9T0G38E/Df4T3Xwrs/AmpazqPwyufH er6B4kkfTPiP4p1LUPGE3jO4+I2gabe6N4r0Pwrda94R1r6Ror44+nCiiigDl/FngfwX4+0+20nx 14Q8L+NNKstRt9Ys9M8WeH9J8R6faatZxzxWmqW1lrFpeW0Go2sV1cxW99FGlzBHcTpFKqyyBpz4 R8KHV018+GPDx16PVZNcTWzoumnV01uXw/F4Tl1hNSNt9sXVZfC0MPhqTUBMLt/D8UWjNMdOjW2H Q0UAFFFFAH5Lf8FHfgr8efiH8V/2bfHvwd+DHij4x6T4H+Hn7RvhDxdaeEvFfwi8NapoWo/ETxJ+ zbrPhW5mi+LXxK+GtnqFhfW3wz8VRTSaNfanc2Vxb2i3dpFFewzV8N/8KI/bP/6Mg+Nv/hzv2M// AKKmv6TaK+yyzjbMcry/C5dRwOV1qOEjVhTqYinjnWkq2Jr4qXtHRzChTdqlecY8tKPuKKfNJOT+ Yx/CuBzDGYjHVcXj6VXEypynCjPCKknSoUsPHkVXB1Zq8KMXK9SXvOTVk1FfzZf8KI/bP/6Mg+Nv /hzv2M//AKKmj/hRH7Z//RkHxt/8Od+xn/8ARU1/SbRXd/xEXNf+hZkv/gvM/wD56nJ/qTl3/Qdm n/gzAf8AzvP5sv8AhRH7Z/8A0ZB8bf8Aw537Gf8A9FTR/wAKI/bP/wCjIPjb/wCHO/Yz/wDoqa/p Noo/4iLmv/QsyX/wXmf/AM9Q/wBScu/6Ds0/8GYD/wCd5/Nl/wAKI/bP/wCjIPjb/wCHO/Yz/wDo qaP+FEftn/8ARkHxt/8ADnfsZ/8A0VNf0m0Uf8RFzX/oWZL/AOC8z/8AnqH+pOXf9B2af+DMB/8A O8/my/4UR+2f/wBGQfG3/wAOd+xn/wDRU1+en7eX/BM3/gon+1T/AMKq/wCEB/ZC8Y6B/wAIH/wn P9rf8Jt8Xv2WLD7X/wAJR/wh/wBg/sz/AIR74/eJ/N8j/hHbz7b9s+w+X51p9n+075/s/wDaxRXT hPE/O8FiKeJoZbkaq0ufkcqOZyS54SpyvF5rZ+7OXo9ehjiOAcqxNGdCrjs1dOfLzJVcDFvlnGa1 WX3XvRV/IKKKK/Nj7gKKKKACiiigAooooAKKKKACv5Ev2aP+TcP2f/8AsiXwp/8AUE0Gv67a/kS/ Zo/5Nw/Z/wD+yJfCn/1BNBr9T8OP92z7/r/k3/pvOD8+44/j5R/16zP/ANLy09tooor9FPiAoooo AKKKKACiiigD9c/+CWX/ACZh4V/7Lb+2P/62Z8f6/Q2vzy/4JZf8mYeFf+y2/tj/APrZnx/r9Da/ AeJP+Siz/wD7HWa/+p1c/ZMj/wCRLk//AGK8v/8AUSifGt9+2f4U0744J8I7r4b/ABHi8Mf8Lq07 9nCf43SHwPD8OLf44ax8Ibb40aT4Paxn8Zx+P5tLvvD99p3hSLxdbeDJtDPxN1Sw8FpLI/2/U7Dc /bC/ar0/9kL4ceFfiJqPwr+J3xej8VfFbwB8Lbfw18KNIs9d8TW93441OS1j1JdHlvYNS1WTyrWf TPD+j6JZajea94z1LwxoF7J4e0TVdV8X+HfOtd/Yy8Rat8Yta8cwfGO0t/hvffHm1/aj0j4aah8N /wC29X0T446X8CdO+CmiTp45vPHSWNz8L9Ov9KtPi5/wgsXgWx8Sv8TBLPb/ABIs/Cjr4XT6r+Hv hz4i6LYajbfE34g6L8SbueTwpPpl5pvgCDwNHpcuk+CPCWk+JC9nF4k8SR3yeIPiDo3if4g6WXkg uPDNr4qt/CKXOr2/huz1m88U9Q7PQtVTXdD0bXI7O809NZ0rTtVSw1D7J9vsU1G0hvFs77+z7u/s PtlsJhDc/Yr+9tPOR/s13cw7Jn1aKKACq17e2unWd3qF9OltZWFrcXt5cykiO3tbWJ57ieQgEhIo o3kcgEhVOAas1S1LT7PV9Ov9K1CH7RYanZXWn31v5ksXn2d7BJbXMPmwPFNF5sMrp5kMkcqbt0bo 4DAA+TP2cP2w/D37RGuDw7/wrD4lfCfVdZ+D/wAO/wBoPwBafEr/AIQZbjx/8Gfifea7p/h7xTpl t4N8aeLbnRdX0q60OFfGXhHxPDo+ueFk8T+EVuo57nVru10vu/F/7ROi+DP2ivhD+znqPgbx/car 8ZfDHjfxF4e+IlpZeHx8ONPuvAthNquo+F9Tv7vxHa+JJ/EdxpltPfpBovhjVtO0+2k046zqemya xpkdz4D8C/2Nfib8Gr/whrt5+0LpfjTxR4C+GHwJ/Z58N6/efBqDT7qb9nv4N67qmra3oPiIT/Eb WptT+LXxZg1G1tvGnxQ0q68PeF7S78P+HtU8PfCTS5LW/t9T6PxR+zd8e/FXxi/ZK+LOp/H/AOGl 1N+zjoOs2HjSxvP2eteOqfFrXvHOi2/hf4l+INO1bSv2gdG0f4cR654fs7V/Cmjp4T8Z2/hHxG17 qt/ceLdHntfDNiAfcFFFFAH8iX7NH/JuH7P/AP2RL4U/+oJoNe214l+zR/ybh+z/AP8AZEvhT/6g mg17bX9P4r/ecR/1/rf+nJH4FQ/gUf8Ar1T/APSIhRRRWBqFFFFABRRRQB4l+0v/AMm4ftAf9kS+ K3/qCa9X9dtfyJftL/8AJuH7QH/ZEvit/wCoJr1f121+deI/+7ZD/wBf85/9N5Ofb8D/AMfN/wDr 1ln/AKXmQUUUV+WH6CFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFfC/hL4+ftZ/FOLxd4i+FP7O v7O2oeA9C+LXxv8AhXouqfEL9rb4leCfF2sTfA74yeO/gtret6p4U8N/sYfEfRtCi1rX/AGqarpV haeN/ELR6Pd6e13dxXr3Npb9WHwdfFRqTpexUKUqcJzr4rC4WCnVVR04qWKrUYylJUqjUYuTShJt JK5z1sTSoShCp7RzqKcoQpUK9eTjTcFOTjQp1HGMXUppykkrySufdFFfIX/Caft7/wDRtX7IX/ib 3xm/+l80f8Jp+3v/ANG1fshf+JvfGb/6XzW/9mYn/n7l3/h3yn/5t8/z7My+v0P+feN/8N2Yf/Mv n+fZn17RXyF/wmn7e/8A0bV+yF/4m98Zv/pfNH/Caft7/wDRtX7IX/ib3xm/+l80f2Zif+fuXf8A h3yn/wCbfP8APsw+v0P+feN/8N2Yf/Mvn+fZn17RXyF/wmn7e/8A0bV+yF/4m98Zv/pfNH/Caft7 /wDRtX7IX/ib3xm/+l80f2Zif+fuXf8Ah3yn/wCbfP8APsw+v0P+feN/8N2Yf/Mvn+fZn17RXyF/ wmn7e/8A0bV+yF/4m98Zv/pfNH/Caft7/wDRtX7IX/ib3xm/+l80f2Zif+fuXf8Ah3yn/wCbfP8A Psw+v0P+feN/8N2Yf/Mvn+fZn17Xwj8UsftNftG6D+z3bobv4Ofs76h4N+MX7RrvBONP8XfE4va+ Kv2evgg1wl/HBfWWi3Fra/Hv4maTc6dPEtvpfwS02aW60fxrr9gOx/4TT9vf/o2r9kL/AMTe+M3/ ANL5r45b9kT45xeIPHHibR/2cfAvhDUviR448R/Enxpb/D3/AILUf8FK/hvoGteOPFl0t34g8Qnw p4B/Zx8N+FtPutQkjgi8nStHsbO0srSx02ytrbT7GztYPTyvBxw1SvWxGIw9OuqDjgqmHx+SYj2O IqSjCWIlGrm+FcZ0aEqrw0oSc6eJdKunF0LS4cfiZV4UqVGjWqUnVjLFQrYTNKPtKMFzRoxcMtrq UalX2ft4zSjOhGpRaaqtw+lPjCZf2WfjKn7T2nG4i+CHxVuPDfgn9q/SYp7SLSvBmtRC08N/DP8A aiMV0Iltbfw5D/Z3wz+Nt7DdQLJ8NpvB3jjVAdP+Ds6Xn3fX8/v7On7OX7Q3xu/ZN+BPibxn8MZv irY/F39nf4Ya74r1jx1/wWs/4Ka+GJ/iRaePvhroeoa7qfjH4a6F8HfEngrw9N4wh1a6uvEPgfRt V17wtpL6jeaDp2oappNvDcz/AKP+C5f21/h74O8J+AfCf7L/AOyVp/hXwP4Z0Hwf4asLv9vL4+a5 d2Xh/wANaXa6Lo1pc61r37A+p67rFxbadZW0M2qa1qWoatqEiNd6jfXd5NNcSb5tlsEqWHhiqFfH YKdXBYitVxmTYanWw+HcaeGf/I4r1XVocs6CdSnTvhYYaDjTnQmp45djpPnrSw9WlhMXCniqNKnh szrzpVq6566/5FtKkqdVyjVfJOdq8q81Kcaq5PuOivkL/hNP29/+jav2Qv8AxN74zf8A0vmj/hNP 29/+jav2Qv8AxN74zf8A0vmvF/szE/8AP3Lv/DvlP/zb5/n2Z6n1+h/z7xv/AIbsw/8AmXz/AD7M +vaK+Qv+E0/b3/6Nq/ZC/wDE3vjN/wDS+aP+E0/b3/6Nq/ZC/wDE3vjN/wDS+aP7MxP/AD9y7/w7 5T/82+f59mH1+h/z7xv/AIbsw/8AmXz/AD7M+vaK+Qv+E0/b3/6Nq/ZC/wDE3vjN/wDS+aP+E0/b 3/6Nq/ZC/wDE3vjN/wDS+aP7MxP/AD9y7/w75T/82+f59mH1+h/z7xv/AIbsw/8AmXz/AD7M+vaK +Qv+E0/b3/6Nq/ZC/wDE3vjN/wDS+aP+E0/b3/6Nq/ZC/wDE3vjN/wDS+aP7MxP/AD9y7/w75T/8 2+f59mH1+h/z7xv/AIbsw/8AmXz/AD7M+vaK+Qv+E0/b3/6Nq/ZC/wDE3vjN/wDS+a3Pgv8AGj4r +Lfiv8Uvgz8Zvhb8Pfhz4w+HPw9+DvxOtbr4Y/GLxJ8YfDWveGvjD4k+NvhXTre41HxV8Evgdqmj a5o2qfA7XZL2yj0LWLC4sNY0meDVluFvLOCZ5bioUq1e+EnTw8I1Kvscxy/EThCdWlQjL2VDFVKs l7WtSg3GEuXmvK0VJpxx1CdSnStiYzrSlCn7XBYyjGUo051XH2lXDwpxfs6c5JSkr8rSvKyPqGii iuA7AooooAKKKKACiiigAooooAKKKKACiiigAooooAKK8N+Lf7Rfwv8AgnrPhLw342f4hah4l8c6 Z4r1zwx4Z+GPwV+NPxw8S3+h+B7rwnYeLNduPD/wU+H/AMQdY0nQ9Cv/AB14O0+91nWbLT9MF/4k 0myjupLq7jhPmn/Db3wZ/wChL/a9/wDFfP7e/wD9DVXbSy3Ma9OFajl+NrUaik6dWlha9SnUUZyp ycJwpuMlGpGUJOLdpxlF+8mly1MdgqU5UquMwtOpBpTp1MRShODlGM4qUJTUotwnCSTSvGUZLSSb +vaK+Qv+G3vgz/0Jf7Xv/ivn9vf/AOhqo/4be+DP/Ql/te/+K+f29/8A6GqtP7Izb/oWZj/4RYn/ AOVea+8j+0cv/wCg/Bf+FVD/AOWea+8+vaK+Qv8Aht74M/8AQl/te/8Aivn9vf8A+hqo/wCG3vgz /wBCX+17/wCK+f29/wD6Gqj+yM2/6FmY/wDhFif/AJV5r7w/tHL/APoPwX/hVQ/+Wea+8+va+Q2/ 4J9/sFOzO/7EX7IbMxLMzfs2fBlmZmOSzE+CySSSSSSSScmk/wCG3vgz/wBCX+17/wCK+f29/wD6 Gqj/AIbe+DP/AEJf7Xv/AIr5/b3/APoaq6MPg+IMLz/VcLnOG9py8/1ehjaPPy35Of2cY83LzPlv e3M7Wu741sTk+I5fb4jLK/Jfk9tVwtXl5uW/Lzyly81o3ta9o32Qf8O+f2CP+jIf2Qv/ABGr4M// ADF0f8O+f2CP+jIf2Qv/ABGr4M//ADF0f8NvfBn/AKEv9r3/AMV8/t7/AP0NVH/Db3wZ/wChL/a9 /wDFfP7e/wD9DVXR/wAZX/1UP/mS8v8Agfh5GP8Axj3/AFJv/LHy/wCB+HkH/Dvn9gj/AKMh/ZC/ 8Rq+DP8A8xdfljqn/BOb9nP9tc/E/wCNfwX+AX7Pnwh8EeALa98I/sbP4Z+Efwt0bwN8YfiF4H8X aZ4h8SfHP4paL4W8KLpvxG+DHjbxV4Rs/hJ4J8LeKj4o0DU/hZB48+IWnaQJviV4fm0z6e/bQ/ad 1P4sfBG++GnwC8I/H+DUfG/iHRfD/wAT/wDhPP2MP+Cjvw4e/wDglefaz8SvDvgvxr4W/Yi+LF74 a8aeMtMjg8GWevz+CtQXw9oniDXvEGlzWviXStCkryvwr/wUm+Mel6B4J8O/Cr9hvT9c8B6XrGq/ CyGT4d6N/wAFLH8I/DC1+Gll4o8N6lp2qwH/AIJCaa1vp/hDxV4Hb4SX3hzwjYeIvE3hvxrd2Ola t4a0zRNG8W634Y+iyulxfQwrx2EnmU8bOt7KKxmLlRhhKFJRqzc6WOr0o1KuOUXh6cLSUsNTxVPk nLEU/Z+Nj6nDdXELC144KOFjSU5PDYeNWWJq1GqcFGphaVSUKeE5oVpyvFqtPDTUoxoTU/pn9nn9 mP8A4J6ftA/CTwv8S7H9gr9kzwvqt+NT0Lxz4F1L9nD4PTa18NviZ4R1S88L/Ej4b67JcfDzS5p9 W8DeNNJ1rw5cX/8AZtna6zHYQ65pkT6TqVhPL7X/AMO+f2CP+jIf2Qv/ABGr4M//ADF18G/s9ftH +NvCX7R/xm+JXj74K/ET4Z/CX40eFtA17xR4I+Gn7Nf/AAVE+Meqz/H7ws+m+GYPiHpNt4p/4J2f Azw54VsPGfwzgtNC+IiwQa5qWua14B8Aapa/Y5ZfE9xqP3l/w298Gf8AoS/2vf8AxXz+3v8A/Q1V 5mZ0OJKGMnHDTz2VCpGnWpwpV8diVh/bQjOWFlXpTqQqyw026PtVJ+1UI1WoOfJHtwNXJKuGg68c pVWDlTlOdLCUHW9nLljiFSnCEqarxUKvs3FezcnTTkoKTP8Ah3z+wR/0ZD+yF/4jV8Gf/mLo/wCH fP7BH/RkP7IX/iNXwZ/+Yuj/AIbe+DP/AEJf7Xv/AIr5/b3/APoaqP8Aht74M/8AQl/te/8Aivn9 vf8A+hqrg/4yv/qof/Ml5f8AA/DyOz/jHv8AqTf+WPl/wPw8j6P8CfD/AMB/C3wppPgP4ZeCfCPw 68D6CLxdD8GeBPDejeEfCmirqOoXer6guk+HfD9lp+kacL/Vb++1O8FnZwi61C9u72ffc3M0r9dX yF/w298Gf+hL/a9/8V8/t7//AENVH/Db3wZ/6Ev9r3/xXz+3v/8AQ1VwzyvOKk5VKmXZnOc5Oc5z wmKlOc5PmlKUpU25Sk3dybbbd222dccflsIxhDG4GMIxUYxjicPGMYpJRjGKmkopWSSSSVktLH17 RXyF/wANvfBn/oS/2vf/ABXz+3v/APQ1Uf8ADb3wZ/6Ev9r3/wAV8/t7/wD0NVT/AGRm3/QszH/w ixP/AMq8194/7Ry//oPwX/hVQ/8AlnmvvPr2ivkL/ht74M/9CX+17/4r5/b3/wDoaqx9D/b/AP2e vE9lPqXhvR/2pfEOnW2seIfD1zf6H+wX+3Vq1lb6/wCEdf1Pwp4r0Oe6sP2cbiCLWPDHijRdY8N+ IdMkkW90XX9J1PR9SgttRsLq2if9jZu4uSyrMnFOMXL6jiuVSkm4pv2Vk5KLcVu0m1sw/tLLrpf2 hgrtNpfWqF2lyptL2l2k5RTfTmj3R9q0V8hf8NvfBn/oS/2vf/FfP7e//wBDVR/w298Gf+hL/a9/ 8V8/t7//AENVL+yM2/6FmY/+EWJ/+Vea+8P7Ry//AKD8F/4VUP8A5Z5r7z69or5C/wCG3vgz/wBC X+17/wCK+f29/wD6Gqj/AIbe+DP/AEJf7Xv/AIr5/b3/APoaqP7Izb/oWZj/AOEWJ/8AlXmvvD+0 cv8A+g/Bf+FVD/5Z5r7z69or5C/4be+DP/Ql/te/+K+f29//AKGqj/ht74M/9CX+17/4r5/b3/8A oaqP7Izb/oWZj/4RYn/5V5r7w/tHL/8AoPwX/hVQ/wDlnmvvFb/gn3+wU7M7/sRfshszEszN+zZ8 GWZmY5LMT4LJJJJJJJJJyaT/AId8/sEf9GQ/shf+I1fBn/5i6P8Aht74M/8AQl/te/8Aivn9vf8A +hqo/wCG3vgz/wBCX+17/wCK+f29/wD6GqvQ/wCMr/6qH/zJeX/A/DyOP/jHv+pN/wCWPl/wPw8g /wCHfP7BH/RkP7IX/iNXwZ/+Yuj/AId8/sEf9GQ/shf+I1fBn/5i67T4a/tTfCP4q+OI/hv4cj+L Wg+Nrjwpr3jfT9C+K/7On7RHwKm1rwt4W1fwroPibV/Dt18bfhZ8PtP8RxeH9W8c+D7PWbfQbvUb zTH8SaRJeW0MF7FK30TXLXx+e4Wap4nGZvh6jipqFfEYylNwbaUlGpOMnFuLSklZuLSeh0UsJlNe PPQw2XVoJ8vPSo4apFSST5eaEWrpOLte6TT7HyF/w75/YI/6Mh/ZC/8AEavgz/8AMXR/w75/YI/6 Mh/ZC/8AEavgz/8AMXX17RWP9r5t/wBDPMf/AAtxP/y3yX3Gn9nZf/0AYL/wlof/ACvyX3HyF/w7 5/YI/wCjIf2Qv/Eavgz/APMXR/w75/YI/wCjIf2Qv/Eavgz/APMXX17RR/a+bf8AQzzH/wALcT/8 t8l9wf2dl/8A0AYL/wAJaH/yvyX3HyGv/BPv9gpGV0/Yi/ZDVlIZWX9mz4MqyspyGUjwWCCCAQQQ QRkV9eUUVzV8Xi8VyfWsViMT7Pm5Pb1qlbk5uXm5PaSly83LHmta/LG+yN6OGw+H5vq9CjQ57c/s aUKXNy35ebkjHm5bu172u7bsKKKK5zYKKKKACiiigAooooAKKKKACivk39t/43eOf2d/2bvFfxS+ G1t4UufG1l4z+CfgzQv+E40nV9e8K2kvxY+Ofw3+E13quraJoPiTwhq+rR6Np3je81a20+z8T6I1 3e2VtBLfwwPKT+Wn/Dd37e//AEN/7IX/AIjL8Zv/AKM2vpMp4WzLOcJLG4SeFhQjiKmFvXq1ISdW lToVZ2jClU91QxFN3bV22knY8PMuIMDleJjhcRHESqyowxH7qnGUVTqVKtON5SqQ1cqNTRJ2STe6 R+/tFfgF/wAN3ft7/wDQ3/shf+Iy/Gb/AOjNo/4bu/b3/wChv/ZC/wDEZfjN/wDRm16f+oOdf8/s u/8AB9f/AOZf6s/K/B/rhlX/AD7xv/gml/8AL/6s/K/7+18hfsQ/8kZ8af8AZ3v/AAUG/wDW9/2l a/L/AP4bu/b3/wChv/ZC/wDEZfjN/wDRm15x8LP2n/22PhF4Z1Twp4b8dfstX2nat8R/jF8T7mbX P2bPi1c3qa/8bvi744+M/iuzgksP2vdMgXR9P8UePtYsPD1vJbSXtpoFtplrqWoatqMN1qt51w4H zeOAxOHdbL/aVcXgq0F7avbkoUcfCo2/qtk1LE07LquZrbXnlxXlrxlCsqeM5KeGxVKX7qlfnrVc FOFl7fVWo1Lvo0u6P6RKK/AL/hu79vf/AKG/9kL/AMRl+M3/ANGbR/w3d+3v/wBDf+yF/wCIy/Gb /wCjNrk/1Bzr/n9l3/g+v/8AMv8AVn5X6P8AXDKv+feN/wDBNL/5f/Vn5X/f2ivwC/4bu/b3/wCh v/ZC/wDEZfjN/wDRm16b8BP25f2tPEv7SPwA+FvxTv8A9nXX/BPxh8Z+NPBmq/8ACv8A4OfEvwD4 q0iXw/8AAz4ufFnTtV0/W/Ef7RXxO0iWNtR+GlrpN7p9z4YZp7LVZ54L+0ntoxLjiOB85w+HxGJn UwMoYXDYjFVIwr1XN0sNRnXq8qlh4xclTpzaTkuZqyd2r60eLMrr1qFCMMXGeIrUcPBypU1H2lep ClT5nGtJpOc0m0nZXex+2FFFfmd+3r+1T8dvgL8QvgN8Pfgg/wAJNPn+J3gz45eM/Eet/FXwF4x+ IMVtF8Ktb+BeiaXpWiaV4R+K/wAJ3s5NTf4t393f6hf6pqiouj2dtb2EZuZrhPncsy3EZtjqOX4V 01XrRrSg6snCmo4ehVxNRykoyatSozaSi22kkrs9rH46hl2FqYzEc/saTpRl7OKlNutWp0IJRbin epUje7SSu+h+mNFfgF/w3d+3v/0N/wCyF/4jL8Zv/ozaP+G7v29/+hv/AGQv/EZfjN/9GbX1H+oO df8AP7Lv/B9f/wCZf6s/K/gf64ZV/wA+8b/4Jpf/AC/+rPyv+/tFfgF/w3d+3v8A9Df+yF/4jL8Z v/ozaP8Ahu79vf8A6G/9kL/xGX4zf/Rm0f6g51/z+y7/AMH1/wD5l/qz8rn+uGVf8+8b/wCCaX/y /wDqz8r/AKgf8E+f+TCP2If+zQv2av8A1TPguvr2v5u/g7+0/wDtsfBH4RfCz4MeFPHX7LWoeF/h F8OPA/ww8N3/AIh/Zs+LV3r99oHgHwzpfhTR7zXLrTf2vdJ0651i507SbabU7iw0rTLKa9eeS10+ zgaO2j9H/wCG7v29/wDob/2Qv/EZfjN/9GbXXj+B83xGPxuIp1svdOvi8TWpt1q6bhVrTnFtfVbp 8slddGmu1+fB8V5bQweEo1KeMU6OGoUp2pUmlOnShCVn7fVXTs+qXpf9/aK/AL/hu79vf/ob/wBk L/xGX4zf/Rm0f8N3ft7/APQ3/shf+Iy/Gb/6M2uT/UHOv+f2Xf8Ag+v/APMv9Wflfo/1wyr/AJ94 3/wTS/8Al/8AVn5X/f2ivyO/Y4/bH/aV+K37Stt8FvjTc/A3WfDus/A34ofFDTNT+F/wv8ffDrWt M1r4dePvgf4UjsL+TxX8cPi1Y6tperWPxavbh0t7LRruyu9GtWW6uobqaGP9ca+bzXKsVk+KWExb pOo6UK0ZUZucHCblFWcoQkmpQlFpxWqurppv3MuzHD5nh3icN7RQVSVJqrFRmpxUZNNKUk1acWmp Na23TSKK8N/ae+KGtfBD9mr9ob40+G7DS9U8RfCH4G/Fr4oaDpmtpdyaLqOteAPAPiDxXpdhq8dh dWN9Jpd5faTBb36WV7Z3bWkkq291bzFJk/HT/hu79vf/AKG/9kL/AMRl+M3/ANGbXblHDWY51Qq4 jCSw0KVKr7GTr1ZwbqKEJtRUKVV2jGcW2+VO9ldp25cyz3BZVVp0cSq8p1KftEqVOMko8zgnJyqQ 1bjKyV9E72ur/v7RX4Bf8N3ft7/9Df8Ashf+Iy/Gb/6M2j/hu79vf/ob/wBkL/xGX4zf/Rm16/8A qDnX/P7Lv/B9f/5l/qz8r+b/AK4ZV/z7xv8A4Jpf/L/6s/K/7+18heC/+T9/2lf+zQv2If8A1c3/ AAUGr8v/APhu79vf/ob/ANkL/wARl+M3/wBGbXnGl/tP/tsaT8XfHHxntvHX7LT+KPH3w4+Fnww1 iwn/AGbPi02gW2gfCLxN8YvFfhu80y1j/a9j1GHWL7Ufjd4rh1y4utVvLK5stP8AD0dhp+mT2mpX OrdeG4IzelRzCnOtgObE4OFGlatXa544/A4h8z+q6L2dCo76+8kuqOevxZllSrg5Rp4y1HESqVL0 qStF4TE0U1+/1fPVgrLpd7LX+kSivwC/4bu/b3/6G/8AZC/8Rl+M3/0ZtH/Dd37e/wD0N/7IX/iM vxm/+jNrk/1Bzr/n9l3/AIPr/wDzL/Vn5X6P9cMq/wCfeN/8E0v/AJf/AFZ+V/39or8Av+G7v29/ +hv/AGQv/EZfjN/9GbXG/Eb/AIKQft5fDn4e+O/iFPrX7I2uQeBPBnijxnNokP7Ovxk0iXWIvC+i X2tyaVFqr/te6qmmSaglibRNQfS9SWyaYXLWF4IjbyOPh/nk5RhGrl8pTkoxj9YrK8pNJK7wySu3 a7aXd2FLjLKYxcpQxijFOUn7Gm7JK7dlXbdlfZN6Oyel/wCi+iiivhz6wKKKKACiiigAooooAKKK KACiiigD5C8af8n7/s1f9mhftvf+rm/4J819e18heNP+T9/2av8As0L9t7/1c3/BPmvr2vQxv+7Z T/2L6v8A6tczOLC/x8y/7Daf/quwAUUUV552hRRRQAUUUUAFFFFABXyF+xD/AMkZ8af9ne/8FBv/ AFvf9pWvr2vkL9iH/kjPjT/s73/goN/63v8AtK16FL/kVY3/ALGGWf8AqNmxxVP+Rjhf+wLH/wDp /LT69ooorzztCiiigAooooAKKKKACvkL9iH/AJIz40/7O9/4KDf+t7/tK19e18hfsQ/8kZ8af9ne /wDBQb/1vf8AaVr0KX/Iqxv/AGMMs/8AUbNjiqf8jHC/9gWP/wDT+Wn17RRRXnnaFFFFABRRRQAU UUUAfIXjT/k/f9mr/s0L9t7/ANXN/wAE+a+va+QvGn/J+/7NX/ZoX7b3/q5v+CfNfXtehjf92yn/ ALF9X/1a5mcWF/j5l/2G0/8A1XYAKKKK887QooooAKKKKACiiigAooooAKKKKACiiigAooooA/PL /gqb/wAmYeKv+y2/scf+tmfACvyMr9Zv+CsF/BpP7D/jrVbqO9ltdM+L/wCyHqNzFpum6jrOpS29 l+2J8BbqaPT9H0e1vtX1a+eOJltNL0qxvdT1C4MdpYWlzdzRQv8AhZ/w0B4E/wCgD8bf/EaP2jv/ AJ1NftXh9Sq1OHKrp0qlRLOscm4QlJJ/Ucp0fKnb5n5ZxnUpwzunzzhC+V4S3NKMb/7XmO12rntt fi7+3d8T/j18Jf2gviD8U/hx4y8cXHw2+En7KPw6uvin8KtF1XWZNMn8KfFvx3+0T4N1v4teGtCt L+K3tPiL8MNZ8O/D/wAVrr2nWg12fwX4f8RaVFdlDb20n6a/8NAeBP8AoA/G3/xGj9o7/wCdTR/w 0B4E/wCgD8bf/EaP2jv/AJ1NfVY3LMXiqSpwjisPKM/aRqQo1W1OMZqF0uXmipyjOUG+WpGLpyVp Nr57CY/D4aq6knQrRceSUJ1IJOLnBzs2pWlKClCMkrwcudaxs/xG8K/te/GJfiT+zn8WLy9+POpf BD4LeFf2T/g/8b/Ff2+6uPgbr2vfFz4RxXHxl8d/FC/m1Rb/AFjx14J8W/F74Jtp8z6Vq8tpqXhr xgl5eW15eiGfsv2ffAv7RfxR+FXxH+Nfiv4vfHHSPhla/Dn9qYTXqftN/FafX/G/xO8IfGzxMPht rvg3RNI1yyl+E/h34a+G/BOt+ENc02w1y2sfHSatZfa/Dl1a2yX9n+w//DQHgT/oA/G3/wARo/aO /wDnU0f8NAeBP+gD8bf/ABGj9o7/AOdTXnU+HcYp81etjK8P30vZ/VqkF7Wq6UU3Lmm/ZQpUYU1T VpSXPzVHGpUhLulneG5UqVLDUpfuo86rwl+7pqba5eWK9pKpUnP2juovktT56cJr+fn4sa5+0B4e +GXwM1H4cfFT9ovWb3WP+Cb0X7UXj7xHP+098Yzq/g/xrqGqfBuDxF8Y08P3ur61a/ErSfBFjrOq apJ8INW1DQfCE2k3Gs3NvJDKk1rff0u6Df2uq6Houp2OrW2v2Wo6Tp1/Z67Ztbtaa1a3lnDcW+rW rWhNq1tqMMiXkDWxNuYplMJMe015R/w0B4E/6APxt/8AEaP2jv8A51NH/DQHgT/oA/G3/wARo/aO /wDnU114HJsVg6ladsTVjWhQioPD1IxpujBxco6yu6l7y5k5XSSlypI5cXmeHxUKUf3FN0pVZOar Qk5qrKMrS0VuTltG1lZvS+p7bXZ/Af8A5PP/AGIP+y2/E7/1jP8Aapr5f/4aA8Cf9AH42/8AiNH7 R3/zqa9c/ZZ+KHhrxt+3B+xPpWjaZ8RLK6tvi/8AFPUZJfF3wh+LHw/01reL9jv9p+1aODWPHngr w3pF1fGS7iaPS7W+m1Oa3S6u4bR7SyvZrfTNMPXhlOcylQrRislzluUqc0kv7MxerbikvmTl9alL MsrUatNt5pliSU4tt/X8Pokndn9SNfil/wAFQP8Ak4/9kP8A7Il+2J/6nf7F1ftbX4Vf8FbvGGk+ Cfj5+x7q2s2nii9tZ/hB+1/pyReEfA/jXx/qa3E3jP8AY4uUkm0XwH4f8SaxbWIjs5Vl1S4sItMg uHtbSe7jur6yhuPxvgSMpcUZfGMXKToZqlGKbbf9j4/RJXbfofp3FzUeH8a5NRSq5fdtpJf8KWD3 b0R8qUV4l/w0B4E/6APxt/8AEaP2jv8A51NH/DQHgT/oA/G3/wARo/aO/wDnU1+4/VcT/wBA9f8A 8E1P/kT8m9vQ/wCf1L/wZD/M9tr8Xf27vif8evhL+0F8Qfin8OPGXji4+G3wk/ZR+HV18U/hVouq 6zJpk/hT4t+O/wBonwbrfxa8NaFaX8VvafEX4Yaz4d+H/itde060Guz+C/D/AIi0qK7KG3tpP01/ 4aA8Cf8AQB+Nv/iNH7R3/wA6mj/hoDwJ/wBAH42/+I0ftHf/ADqa5MblmLxVJU4RxWHlGftI1IUa ranGM1C6XLzRU5RnKDfLUjF05K0m104TH4fDVXUk6FaLjyShOpBJxc4Odm1K0pQUoRkleDlzrWNn +Uf7H/xf8XXX7RXwQ0rxj8Z9U+Od58X/AIUeBL620TR/jj4+j8S/AC/8J/ss+FdT8aaZ8b/gFLK/ gnXPD/j3xa134k8O/F7UbdfFd1438Q2NhNqVxBJBHcfuTXiX/DQHgT/oA/G3/wARo/aO/wDnU0f8 NAeBP+gD8bf/ABGj9o7/AOdTSwWV4zCUp05RxFfmqyqKTw9WLipRgnFuTqTn76lJSnNtKSpxUacI RTxePw2JqQnF0aXLTjTcVWhJScXK0kkoRj7rjHljFJuPPK85Sk/baK8S/wCGgPAn/QB+Nv8A4jR+ 0d/86mj/AIaA8Cf9AH42/wDiNH7R3/zqa7PquJ/6B6//AIJqf/InL7eh/wA/qX/gyH+Z94fsI/8A J+/hD/s0L9pr/wBXN+xlX7+1/OZ/wTg+IGheOv29tCOiWHjax/sr9kL9o4XX/CZfDT4j/Doy/bvj N+x75H9mj4g+FfDB1kJ9jm+2HSBfDTt9p/aH2X7fY/aP6M6/GPECMoZ5TjOMoSWX4e8ZJxkr1sS1 dNJq6aa02aZ+o8GyjLKakoyUovG1rOLTTtSoJ2aunZpr1PkL/goN/wAmEftvf9mhftK/+qZ8aV+H lfuJ/wAFBhn9gn9t4cc/shftKDkgDn4M+NOpOAB7kgDvX853/DQHgT/oA/G3/wARo/aO/wDnU19R 4eUqlTKcZ7OnOpy5jPm5ISna+Gw1r8qdr2dr72dtmeBxrUhDMMJzzhC+DVuaSje1ere12r2ur+p7 bRXiX/DQHgT/AKAPxt/8Ro/aO/8AnU0f8NAeBP8AoA/G3/xGj9o7/wCdTX3/ANVxP/QPX/8ABNT/ AORPjfb0P+f1L/wZD/M+fP2l/i2nwd/ab/ZI8ReM/iHL8OPglf8Ahv8AaW0r4g6trniOfw58Nbvx MPDvw51T4e2Pi+4ubq28OTa466b4tfwVFq5a/lul1i00EPd3k8E/4jXvxT/aysPCPwg8Sa/8Uvj1 ok+jfsz/AAX+KfjPxrL8ZvHthc/D7w74/wD25fidoqfGTxH8KZ5rnw98abGX4RXXh2w1fQfGEti1 l4Ejsb9pJ4NAi06L+jz/AIaA8Cf9AH42/wDiNH7R3/zqaP8AhoDwJ/0Afjb/AOI0ftHf/OprxsZk OOxVWpUVXF0Yzc5QhHDVXySnRwtP4vaRuoywsakOWNOcHUquM4zcZx9TDZvhcPCEHSw9VxUFKUq9 NcyhVr1NFyNpyjiJQlzSnGShT5ouKlCXkP7FnirxP4r8P/tES+KPEWueI5tC/bM/ai8K6JNruq32 rS6R4Y8P/E3UrLQfDumy389w9loeiWSrZaRpVu0djplmkdpZQQW8aRr9l14l/wANAeBP+gD8bf8A xGj9o7/51NH/AA0B4E/6APxt/wDEaP2jv/nU16lDA4qjRp0nRxFRwjyubo1E5avVpqVvvZ59bF0K tSdRVKMFJ3UVVg0tErXVu19ke214l+0v/wAm4ftAf9kS+K3/AKgmvUf8NAeBP+gD8bf/ABGj9o7/ AOdTXkH7Qnxw8Gav8A/jhpNpovxfiutU+EHxL062l1T9nv4+aJpkVxe+DNatoZNR1rWvhpYaPpFi kkqtd6pq1/ZaZYW4ku7+7trWKWZOzDYbErE4dvD10lXpNt0qiSSqRu2+XRI5q9ai6NZKtSbdKokl Uhdvkei1P7TKKKK/lk/oIKKKKACiiigAooooAKK+Rpv+CgP7BtvLLBP+21+yNBPBI8M0M37SPwbj lhljYpJFLG/jNXjkjdSjo6hkYFWAIIqP/h4N+wR/0e9+yF/4kr8Gf/m0r0P7IzX/AKFmYf8AhFif L/p15r70cf8AaOX/APQfg/8Awqof/J+a+8+vaK+Qv+Hg37BH/R737IX/AIkr8Gf/AJtKP+Hg37BH /R737IX/AIkr8Gf/AJtKf9kZt/0LMx/8IsT/APKvNfeL+0cv/wCg/Bf+FVD/AOWea+8PGn/J+/7N X/ZoX7b3/q5v+CfNfXtfk74u/bl/Ynuf22P2ffFdt+2H+y1ceF9F/Za/bD8Pax4kg/aC+EsugaTr /if4tfsM6l4b0PU9Yj8XNp1hrHiHTvCPiu/0PTLq5ivdWsvDHiG6sILiDRdSktvqX/h4N+wR/wBH vfshf+JK/Bn/AObSu/GZTmjw+VJZbmDccBUUksHiW03mmYySf7vRuMouz1tKL2aOPC5hgFXzFvHY NKWMg4t4milJf2fgI3Xv6rmTV1pdNbo+vaK+Qv8Ah4N+wR/0e9+yF/4kr8Gf/m0o/wCHg37BH/R7 37IX/iSvwZ/+bSuD+yM2/wChZmP/AIRYn/5V5r7zs/tHL/8AoPwX/hVQ/wDlnmvvPr2ivkL/AIeD fsEf9Hvfshf+JK/Bn/5tK+qdE1vRfE2i6R4k8N6vpfiDw74g0uw1vQde0S/tNV0XW9F1W0iv9L1f SNUsJbix1LS9SsbiC9sL+ynmtLy0miuLeWSGRHbnr4LGYVRlicJicNGbahKvQq0VJpJtRdSEVJpN NpXaTTNqOKw2IclQxFCu4pOSo1adRxT2clCUrJ9G9zUorlPHHjzwN8MfCureOviT4z8KfD3wToEd tNrvjHxx4i0jwn4V0WK8vbbTbSXVvEOvXlhpGmx3Wo3lnYWz3l5Cs97d21rEWnnijf5t/wCHg37B H/R737IX/iSvwZ/+bSnQwONxUXPDYPFYiEZcjnQw9atFTSTcXKnCSUkpRfK3e0k7aoVXF4WhJQr4 nD0ZtcyjVrU6cnFtpSUZyi2m01dK101uj69or5C/4eDfsEf9Hvfshf8AiSvwZ/8Am0o/4eDfsEf9 Hvfshf8AiSvwZ/8Am0rf+yM2/wChZmP/AIRYn/5V5r7zL+0cv/6D8F/4VUP/AJZ5r7z69r5C/Yh/ 5Iz40/7O9/4KDf8Are/7StH/AA8G/YI/6Pe/ZC/8SV+DP/zaV8tfsefty/sT+GPhL4u03xJ+2H+y 14e1G5/al/bm8Q21hrn7QXwl0m9uNA8XftsftBeK/CmuQWt/4ut55dH8T+F9a0fxJ4e1OONrLWtA 1bTNY02e506/tbmXvp5Tmn9l4yP9m5hzPH5a0vqeJu0sPmqbS9ndpOUU3snKN91fjnmGA/tDCy+v YPlWDxyb+s0bJyr5c4pvnsm0m0t2k7bH6xUV8hf8PBv2CP8Ao979kL/xJX4M/wDzaUf8PBv2CP8A o979kL/xJX4M/wDzaVwf2Rm3/QszH/wixP8A8q81952f2jl//Qfgv/Cqh/8ALPNfefXtFfIX/Dwb 9gj/AKPe/ZC/8SV+DP8A82ldn8P/ANr/APZL+LHirT/Avws/ai/Z1+JfjbVo72bSvB3w/wDjZ8NP GXirU4tNsp9S1GXT/D3hzxNqWr3kdhp1rdX969tZyLa2VtPdTmOCGSRYnleZ04SqVMux1OnCLnOc 8JiIwhCKvKUpSpqMYxWrk2klq3YqOPwM5RhDG4Sc5tRjGOJoylKUmlGMYqbcm20kkm22ktz6Korz z4mfF34UfBbw9D4u+MfxP+Hnwm8KXGqW2iW/if4meNfDfgPw9PrV5b3d3Z6RDrXinU9K02XVLq1s L65trBLlrue3sruaKJo7aZk8F/4eDfsEf9Hvfshf+JK/Bn/5tKijl+PxMPaYfBYuvTu4+0o4atVh zK1488ISjdXV1e6ur7l1cZhKEuStisPRnZPkq16VOVns+Wck7Po7WZ9e0V8hf8PBv2CP+j3v2Qv/ ABJX4M//ADaUf8PBv2CP+j3v2Qv/ABJX4M//ADaVt/ZGbf8AQszH/wAIsT/8q8195l/aOX/9B+C/ 8KqH/wAs81959e18hfsQ/wDJGfGn/Z3v/BQb/wBb3/aVo/4eDfsEf9Hvfshf+JK/Bn/5tK+Wv2PP 25f2J/DHwl8Xab4k/bD/AGWvD2o3P7Uv7c3iG2sNc/aC+Euk3txoHi79tj9oLxX4U1yC1v8Axdbz y6P4n8L61o/iTw9qccbWWtaBq2maxps9zp1/a3MvfTynNP7Lxkf7NzDmePy1pfU8TdpYfNU2l7O7 ScopvZOUb7q/HPMMB/aGFl9ewfKsHjk39Zo2TlXy5xTfPZNpNpbtJ22P1ior5C/4eDfsEf8AR737 IX/iSvwZ/wDm0o/4eDfsEf8AR737IX/iSvwZ/wDm0rg/sjNv+hZmP/hFif8A5V5r7zs/tHL/APoP wX/hVQ/+Wea+8+vaK+Qv+Hg37BH/AEe9+yF/4kr8Gf8A5tK7P4f/ALX/AOyX8WPFWn+BfhZ+1F+z r8S/G2rR3s2leDvh/wDGz4aeMvFWpxabZT6lqMun+HvDnibUtXvI7DTrW6v717azkW1srae6nMcE MkixPK8zpwlUqZdjqdOEXOc54TERhCEVeUpSlTUYxitXJtJLVuxUcfgZyjCGNwk5zajGMcTRlKUp NKMYxU25NtpJJNttJbn0VRXy94m/bg/Ys8F+Idb8I+Mf2vv2XvCfivw1ql7oniPwx4m+P/wo0HxD oGtabcPaajpGt6Lqni211LStUsLqKS2vbC/toLu1uI3hnijkRlGH/wAPBv2CP+j3v2Qv/Elfgz/8 2lOOVZpKKlHLcfKMkpRlHB4hxlFpNNNU2mmmmmtGmmtxPMMBFuMsdg4yi2nF4mimmnZppzumno09 Uz69or5C/wCHg37BH/R737IX/iSvwZ/+bSj/AIeDfsEf9Hvfshf+JK/Bn/5tKr+yM2/6FmY/+EWJ /wDlXmvvF/aOX/8AQfgv/Cqh/wDLPNfeHjT/AJP3/Zq/7NC/be/9XN/wT5r69r8nfF37cv7E9z+2 x+z74rtv2w/2Wrjwvov7LX7Yfh7WPEkH7QXwll0DSdf8T/Fr9hnUvDeh6nrEfi5tOsNY8Q6d4R8V 3+h6ZdXMV7q1l4Y8Q3VhBcQaLqUlt9S/8PBv2CP+j3v2Qv8AxJX4M/8AzaV34zKc0eHypLLcwbjg Kiklg8S2m80zGST/AHejcZRdnraUXs0ceFzDAKvmLeOwaUsZBxbxNFKS/s/ARuvf1XMmrrS6a3R9 e0V8hf8ADwb9gj/o979kL/xJX4M//NpR/wAPBv2CP+j3v2Qv/Elfgz/82lcH9kZt/wBCzMf/AAix P/yrzX3nZ/aOX/8AQfgv/Cqh/wDLPNfefXtFfIX/AA8G/YI/6Pe/ZC/8SV+DP/zaV9U6Jrei+JtF 0jxJ4b1fS/EHh3xBpdhreg69ol/aarout6LqtpFf6Xq+kapYS3FjqWl6lY3EF7YX9lPNaXlpNFcW 8skMiO3PXwWMwqjLE4TE4aM21CVehVoqTSTai6kIqTSabSu0mmbUcVhsQ5KhiKFdxSclRq06jins 5KEpWT6N7mpRRRXMbhRRRQAUUUUAFFFFABRRRQAUUUUAfnL/AMFYNQg0n9h/x1qt1Hey2umfGD9k LULmLTNM1LWtSkgs/wBsX4CXM0en6Po9pf6vq168cbLaaZpVjealfzmO1sbS4upYoX/nU8Y/tZNo 2ra4/hb4e3mueEPAfh34XeLfiVqXjG88WfCjxro2hfFPx54y8DaWPC3w48Z/DmHUfEesaXJ4G1bW r3S/EereAV1HTrrR4/Dt7rN3qCwxf0cf8FTf+TMPFX/Zbf2OP/WzPgBX4A/E+6/Zl0z4jeEtV+Km n/DyT4m20fhZvDWra74et9W8QaXbN44tNM8B3F5qUenXjaNZR/EbWox4Fu9dns7S38XTale+GZY9 VtNVuLf9d4KdVcNTdOvToJZ3j+aVRRW+AypL3p80Uk7ScXC80nFVKd+Zfm3FPs3nkFOjUqv+ysI0 oNvRYzMG7xjyy1V0pKdotpuMrWfzVq37YPxg8S/DWXVvBfwe8J6P4i8ZfDP9oH4keBp9Q+MF276V 4F+BVzoHhTxJ4o1mNvg7f2EXjCbxd408LyeDfA8I1jRdb0iW5vfEvjHwrPazaQ2V4V/b21w+CvEO sS/CLxh4z0z4a/DnxBfeKvHNrp3jnTLHUfGnw/8AgAnxh8RT63qq/CZPhV4Y8L65qdrceCdO1Ow+ I+seI18U6poQj+Hq6RqRurL7h1z4G/BnxLo+geHvEHws8AaxoPhWe/uPDmi6h4U0W50rRn1aYz6v HYWElmbWC11ic+bq9ksX2PVZFR9QguWjQrDcfAX4J3d7qOo3Hwo+H8t7q/h6Xwrqk7eFNGDah4en 8MJ4Jm0y7UWgjngk8FxReDmeRGm/4RSKLw35v9jRpZL9M8PmfNGUcbH4YRlzQhZ2gvaOMI0VFN1U 2m1JuDUU4cr5/AVfAcrTwsvim1yzkmrz9xOTqOTtTsmrqKneXLK65el+Heu+KvE3g7RPEHjPw1o/ hDXNYtjqL+HtE8UXHjG10/T7t2n0lLjXbjw14UE2qyaY9pLrFna6XNp+m6o93p+naxr1lbQaze9r UcMMNvDFb28UcFvBGkMEEMaxQwwxKEiiiiQKkccaKqJGihUUBVAAAqSvUimoxUpOTUUnJpJyaVnJ qKjFNvVqMUtdElocEmnJtJRTbair2SvolzOTsvNt92wooopiCuz+A/8Ayef+xB/2W34nf+sZ/tU1 xldn8B/+Tz/2IP8AstvxO/8AWM/2qa48y/5FWcf9iXOf/VXizqwH/Ixyz/saZZ/6n4c/pNr8Nv8A grJ4hsPCnx0/ZR1/VLfXLqw0/wCCH7XrXEHhvwx4l8Z63ILj4i/sUWkf2Hw14P0nXfEepsstxG86 6bpV21rbLNe3Iis7a4ni/cmvxS/4Kgf8nH/sh/8AZEv2xP8A1O/2Lq/H+B7/AOs2Bs0n9Xzazauk /wCx8ws2k4tpPdJq+11ufpnFdv7Bxd02vbZddJ2bX9pYO6TaaTts7O3Z7H4G6V+2D4m8FeL/AIx6 r8QPD19rnwdtvjV4z8LeE9einutG+IXhW08G/sb6T+0zdeGpvhVqXgvQ7ltNk0Pwj41f7f4g8X2X jO28aa7beHdR8KW+nW76pZ9hrX7XfxA8LLPZeKfgr4d0vVdP0f4YeOPEeq2fxT8Q+IPh34F+GHxR 0j4s3Gl+MvH3irRPgzeeJfDy6T4g+EGu+Hdde2+H+r+DNJGraJr2qePbDRW1W50v6ntvB3wm1/U9 ans9A8DazqukeO73XvEhtLPRtQutO+I+ofDmHwXqGoa9HCsrWviy++FniG28P3h1FE1K58G61bW0 yvpmoQ+b57B8E/2WLK8Pwog+Hfwat9SvNNHjST4dJpHhZNTv/DunRy+DhrVz4V2fbb/wjZRazL4V b7RYz+G4I9UfQ2jVLw2sn6z7LHxT5cbBp1Krg5KGnO/cptypzclGd1FKSlGKcOad4un+c+0wcmub CzuqdNSUXLXlSUqnu1IJOUFdvlcZSalyxs+f5W8U/tH/ALUdxBfXvhfwd4Ce68H/ALYvjj4a2fhX wtf6r4k134t/Cj4bfCf4rfETxD4Na213w/o8Phf4h67Z+E9ITwjrej6re2N34pktdO1Kz0/RIb6T XKegft8fYfhvB8RVXQPizoOufGb4v2FjJod74o0/xRY/B3SPj5N8OfBHijTPD3hT4VeK9Hl0mz0G /wBPgm174keJfhlpd5qlpb6bd+I5dW1G7lsvubTPDXwatPiTr1ppOg+ELX4no2h/FbX0tNLtoNe8 /W7Dxn8PtF8bXMiQIHvdQ06Dxv4aGpxu15JbS6tb3TbL0mfkfD/wW/Zh8Y6VHe+H/hT8J9Z0XRfF fxH0tPs/gnQjp9p4tsfiZrbfEi2e0l02OCS9tvixous6lqRkhkjXxdpza3aN9ugtr0R9Xx6cnTx0 HOUasUqn7xRcZ0VGUYqKjeKVSNWLi+WUoJS5nOc69thGoqphJKMXTbcFyOSlCo5RcnLmtJ8sqbUl dKba5VCMfnTVP23fH2m+HPE3jdfgLolz4L8P+Gf2l/H634+MckWt3HgP9lD4gN4B+J15daG3wvaC z8V6xPPpmpfD3w3a6xqmla3DdXdv4n8W+CnsY5b72D4ZftO6j8S/ivrngSx+E3jG08Had4l+LXg6 z+JK6P49l0VfEPwd8Z33gXXY9f1LUPhvo3w5srDXtc0TxFH4Wm8K/FDxxqdx/Zkdrr+j+HdTnu9P 033C4+E3wyutIvdAn8BeE5ND1LRfiB4cv9IOh2A0670H4rarHrnxK0ea0WAQPp3jrWYYtU8UWhTy dZvo0ub1ZZVDVNpHwt+HGgeLdV8d6H4I8MaR4x1z7WdY8R6do9lZ6rqMmoSW82oz3V1BEjS3Ooy2 ltLqF03+kX0kMcl1LMwzW8KOPjODli4zpr2XPF0qabtFe25XGkrKcr8qeqi17ycXzYyq4OUJKOGl Cf7zkkpza1l+75lKo9Yx3a0bv7rTTj3lFFFd5xn0H+wj/wAn7+EP+zQv2mv/AFc37GVfv7X4BfsI /wDJ+/hD/s0L9pr/ANXN+xlX7+1+O8e/8jul/wBi+h/6exJ+m8Hf8iqr/wBhtb/0zhz5C/4KDf8A JhH7b3/ZoX7Sv/qmfGlfy8/Gj9re1+G+taF4P8G/DL4g+P8Axvrd/wCPIU0i8+Hnxx8PaW1h8ObK wl8QXuj6l4e+CvxC1bxTHd6jregadoGqeG/DWpeCtSGoT311400y3hshqn9Q3/BQb/kwj9t7/s0L 9pX/ANUz40r8BvG/w28A/Em106y8e+D/AA/4tt9HvX1LSF13TLa/k0nUJLWexlvdMnmQz6fczWN1 c2U81pLC89pcT20peCV42+h4GjXlkuMWHqQpVP7SnaU4c6t9XwjaW6TcbpNwmk2nbQ8fi2VGOZ4R 1oSqQ+paxjLld3VrpN7NpSs7KUb2tc+MtT/be8RWsGu6na/AzVYtKh+KvhL4J+F9O1rWfGrfEK/+ Inif4Y+D/jDdWni74c+A/hD8RNc8KaN4d8E+INct9YutHl8beIIvF3hxNE/4RZdK1SbxJpP2F8Kv G998R/h94Z8aap4P8R+AdS1uznfUfCPizTNV0jWtHvrG+u9Mu0ey13StB1wabd3FlJf6Dd6zoHh/ VdS0G60zUdR0DQ7u7m0q0xvEfw3+CNv4c1DQfFPg74c2PhXxZ4s8M3d7pmr6VoGnaNrPjlv+Ed8K +DbhILiO3tZvFTPo3hXQfDMluBqzXGn6Lp+lkzxWkY9D0HQNE8L6PYeH/DmlWOiaJpcAttP0vTba O1s7SHc0jLFDEqqGkleSaaQgyTzySzzPJNI7t9rQhi41ZOviIVafI7QUIRlGUptxvywi3FQXLFuW ut1JrnfydaeHlTj7KhKnPmV5OUpRcYwSklzSfvOb5mraaWaT5Vr0UUV2HMFFFFABXiX7S/8Aybh+ 0B/2RL4rf+oJr1e214l+0v8A8m4ftAf9kS+K3/qCa9W+F/3nD/8AX+j/AOnImVf+BW/69VP/AEiR /XbRRRX8wH76FFFFABRRRQAUUUUAfyJfs0f8m4fs/wD/AGRL4U/+oJoNe214l+zR/wAm4fs//wDZ EvhT/wCoJoNe21/T+K/3nEf9f63/AKckfgVD+BR/69U//SIhXI+PPF8PgHwjrfi+48P+LvFUOh20 Vy/h/wAB+HL/AMXeLtTEt1BaiDRPDmmK99qlyjXAmlht1JitYp7hyIoXYddRXPJNxkovlk01GVr8 ra0drq9nra6vtc2TSabV0mm1e11fVX1tdaXs7bn59+C/+Cl/7NPjK4+D8bJ8UvCNh8ePGOqeBfhd 4g8b/DLxFoHhrxPrukTW2nXZtddKXWnDTV8R32n+EW1TzjZW3ii+ttLvpbQmWaL7K+HPxE8NfFPw w3i7wlLeTaKPE3jvwmJb60eynbVfh1468R/DzxFtt5GZxajxF4W1VbGZtpurIW90Y4vO8tPzU0H/ AIJotf8AwY/Z5+CvxK8X6Jrfh/4UeAf2ofBviq70O31ayvtQvvjr4lsfEvhHxJ4SuJGgm0vV/AGp afY6xbXdxJFNFren2N3ZN+63D7R/ZE+DXjT4A/s/eDPhd8RvGWnfELx3pGq/EPXvFnjXStPn0qw8 R654/wDiZ4x+IV/qMOnXLPLaM83ipo54SzILiOUxHySleVgauaSqqONo040nh4z9pBKMo13Swkp0 ZxVSekalTERhKN1L2UlLl5YOp6GLp5eqblhKk3UVeUOSbclKip4hRqxl7OGsoQouUW1yuorJ3kof SlFFFesecFfuH/wT5/5MI/Yh/wCzQv2av/VM+C6/Dyv3D/4J8/8AJhH7EP8A2aF+zV/6pnwXXwfi D/yKsH/2MIf+o2JPr+DP+Rjif+wKf/p+geX/APBU3/kzDxV/2W39jj/1sz4AV+Rlfrn/AMFTf+TM PFX/AGW39jj/ANbM+AFfkZXVwD/yTtT/ALHWP/8AUHKTDjH/AJHUP+xXhP8A1LzEKKKK+yPlz4C8 Rf8ABRz4J+Etd+LmheJfAX7RGit8DtFk8Q/EnVtQ+CHi220PQNGni1uTw7qEupSII2g8bNoGoQ+C mZE/4SGUQ/ZcRyGROt8Vft7/ALPfhnQdC8RWuoeMPGln4r8MfBbxV4RtPAHg3VvFmr+KrT4++K/F 3gv4d6Zomkaev2+fxBd+IvBOuafq2h3ENrf6RcRw211ELx5baHjvjL+x34o+Jt5+2lc6f4w0DTF/ ag+HnwH8G+HlvLPUZW8MXfwjl8Xyaneaz5CkXVtqw8R24sVsd0sJt5vtCjKbvn/WP+CXmoyfFH4g 6x4f+J40j4QeI/jF+zf8RPBPw80+68U+F9a+G/hz4ZfFLx78Xvij4U8I+MPB2paLrHhqLxN40+If iTVvAr+G7rSpvCkmpyJDe2strHeXHhVaueQlJU6VGtGTrRjJwUHBqpi1Rm17ZqUJUqWHlOy51OvG 0XHnUPYp08pkoudWrTklSco8zkp3hhXVin7JOM4zqV1G75XGlLVS5ef9N/hH8W/BHxv8CaX8Rfh9 f3t74f1K81zSZYdW0jU/D2u6L4g8La5qPhjxV4a8ReH9atbLVtE8QeGvEmkapomsabfWsUkF7Yym Jp7V7e5m9KrhPhp8M/BHwf8ABmk/D74daIPD/hPRX1Kax05tR1bWblrvWdUvdb1jUNQ1nXr/AFTX NY1TVdY1G+1PUtV1jUr7Ub+9u57i6upZHLV3de1S9p7Kn7Zwdbkh7V07qm6nKufk5ve5Oa/Lza2t fU8qp7P2k/Zc/suaXs/aW5+S75efl93mtbmtpe9tArs/gP8A8nn/ALEH/Zbfid/6xn+1TXGV2fwH /wCTz/2IP+y2/E7/ANYz/aprmzL/AJFWcf8AYlzn/wBVeLN8B/yMcs/7GmWf+p+HPvD/AIKxf8ij +yD/ANneyf8ArIv7W1fm5X6R/wDBWL/kUf2Qf+zvZP8A1kX9ravzcrwuDP8AkncF/jxf/qXWPW4o /wCR3i/8OG/9RqQU13EaO7BiqKzkIjyOQoJISONWkkYgfKiKzscKqliAXUV9SfPn523P/BTf9n/S dB+KfibxT4P/AGgfBWh/BjUfDuhfEXUPF/wU8VaLF4f8S+KNS8EWWj+FrlJVklXxHNp/xA0DxQ+k vHHcR+Fft2skGO1Ecvofjr9vD4F+CNafw5DF8QPHuvy+M/BfgbRdH+F/gjUvHl/4q1fx78JdR+Nv h+48KwaJJL/bWlSfD3S7vV7i/tyFRlWOGOdC0q8vq37HGq6tqvx0vLrxR4fvbD4wfthfs+/tJJpV /o9zNbWvhj4QWnwJs9e8HarHI80N9feIIfhTrKWkwhOniPVrCG9j2fazF8laD/wSHtLPVG8Pa/8A FCTWfg9Y/tDr8R/DPhqzbxHoPjDw78JNJ+A/xF+Efgn4b2Xi7R9VtLpNS8CzeMdEtND1VCttL4U8 K2dnqcN7NcXNrN4FSrnsJRjTo0KqlPldRxjT9nFV68FOSVWV41KPsKl4xbpyUvcn7Tlp+xTp5PKL lUq1abjBSUE5T526VCTin7ONpQqutCzklUVrShyXn+t/wu+Jvgv4zfDzwh8U/h3qz654I8daJaeI PDeqy6fqOkzXenXYbYbnS9XtLHVNOuoZEkt7qx1Cztru1uIpYJ4UkQiu9rw39mj4aeJvgz8A/hT8 JfGGreHdf1/4b+D9N8FXGu+FtI/sHR9asvDgfS9F1ZdIEcUdjqeo6Jbadd69DbxpaHXptTksx9le Gvcq9qhKpKjRlWio1ZUqcqsUuVRqOCc4pc07JSurc8rbc0t35dVQjVqRpScqcak1Tk3dygpNQk3y xu3Gzvyxv/KtkV2fwH/5PP8A2IP+y2/E7/1jP9qmuMrs/gP/AMnn/sQf9lt+J3/rGf7VNYZl/wAi rOP+xLnP/qrxZtgP+Rjln/Y0yz/1Pw55fp3/ACN3x8/7O9/bW/8AWuvjZW7WFp3/ACN3x8/7O9/b W/8AWuvjZW7XTT/h0/8ABH/0lHPP45f4pfmwrzT4x/Frwf8AAn4X+Nfi94/m1G38G+AdEn1/X5dI 0251jVPsUMkUPl2Gl2gNxe3U088UMMEWC7yDcyqGYel187/tZ/BbU/2iv2cfi38EdG1qy8O6p8R/ C0nh+z1rUVvWstOle+srszz/ANnFb5V2WrIr2jLPG7rJGwK5E4h1Y0K8qEVKvGjUdGL2lVUJOnF6 rRzsnqtHuty6KpyrUo1pONKVWmqslvGm5pTktHqo3a0evR7Hkcv/AAUQ/Zs07RNA1nxRqXjnwJLq /wAcdK/Z51XQfHvw+8TeEPEXgX4k614ah8Y6fbeP9M1qztT4Y0Kfwze6VrP/AAklzNLpC2Ws6dK1 yA119l+n/hx8UfCvxUtvGN14Ukv5IvA3xF8afC7Xvt9m1kyeKvAWqvo3iCO1VpJPtNgl4hFpeAqt zFiQRpyo/PzSv+Cbeg2U2pfD3U9T0DxB+zvdfHf4o/FK28F63HrureNX8J/GL9mPxX8EvFfg3WvG Gr3epX/iC90LxTr8Gs+C/Eer3l5rWleE7ax0JtSMnhzQwn0V+xJ+zf4u/Zb+Dd/8N/HPxEj+KfiS /wDiN468a3njX+zpdMvNXh8Tamk1lNrEMs0wl16WztobjXLqDy7W41We7e1iWDYW8/CVc0lXUMXQ pRo8tROpT0tOmqSV71G5RqynJ05RhG6pzc4U7wi+3E08uVJyw1WpKqnBqE9pRm5doJRlTUV7SLk1 epBQlPlmz6+ooor1TzQr9w/+CfP/ACYR+xD/ANmhfs1f+qZ8F1+HlfuH/wAE+f8Akwj9iH/s0L9m r/1TPguvg/EH/kVYP/sYQ/8AUbEn1/Bn/IxxP/YFP/0/QPr2iiivyM/SQooooAKKKKACiiigAooo oAKKKKAPzl/4KwR6lL+w/wCOotHu7Kw1eT4wfshR6Vfanp8+rabZ6k/7YvwEWxu9Q0q11PRbrU7K 3ujFNd6fbaxpM95AkltDqdhJIt1F/LN8Yv2ZvjD4z+Jnijx1cIni7WtQ8E/skaTHq/hrxBrXgXwX qupfDP8Aa01X4j+OoIfhn4g+J/iiysl8PfDVNF1O1fVrvVIbvWH1e58MTQa7reqae39U3/BU3/kz DxV/2W39jj/1sz4AV+Evjb4/fDH4e654i8P+J9T12G78HeC7T4heM7vSfBPjTxJo3g7whqEniRNP 1rxTrfh3QNV0vQra8i8G+LbuP+0LqF4bLw9eXN2tvHc6UdQ/W+DaOHrcNTWIn7OKzrMUm6ijG8st yyDdp3hzRjKUoy5eaPLe/KpJ/nHFFWtTz2HsIc8v7LwbaUHKVo47HSs3G0+VyjGLjzcsr2tzNM/K jx+/7T/w407xn4h+I1h4r+Gngnx/4k+BmlR6FL8Ymn8Or4h0/wAXfFPxJ8QNOk8deJP2ntS1K30D XPCMPhTw5q/jC88d/s02XjCK30bRZPCaS2Nv4L8UfTv7NGmfE248S/Bfxfp0/wAZ/H3w9vfhvF4W 8W+Mvir4zsLrS7LVfD+l+J7W+8W+EE0z9ovx3d+JV8ZeLLLTba7GteEviRpPiHS7jQ/HHg/40XPh 7RNFj1v6ym/aI+FieOp/hvaanr+ueMLLX73w7qWleFfBHjTxaNIudNsPBd7qGo6xeeGdB1az0rQL Gf4geF9IvNfv57fSrXWp9Z06e6jk8JeLm0LrPhn8UvB/xd8Pf8Jb4EudW1Hw1LdS2+na1qHhzxBo FjrkMQX/AImegSa9pumnWdHkcvDDqlgs9nJNDNGsu6MivpaGCw8cQuXGyqum240nOm6ilCr7aafL aLhzVGpQjSjyKcOWUGrvwauKryoy5sKqamlzVFGapuM6fsoNX15uWCcZOpLmcZcyktF6HRRRXsHm BRRRQAV2fwH/AOTz/wBiD/stvxO/9Yz/AGqa4yuz+A//ACef+xB/2W34nf8ArGf7VNceZf8AIqzj /sS5z/6q8WdWA/5GOWf9jTLP/U/Dn9Jtfht/wVkt/Et18dP2UYPB+raHoXiOT4Ifte/2bqviTw9f +K9EtGX4i/sUPcm+0DS/E/gy/wBQWWzW4ggW38S6Ybe6lhu5GuoreSyuf3Jr8Uv+CoH/ACcf+yH/ ANkS/bE/9Tv9i6vx/gdX4mwKd7PD5snZuL1yfMFo000+zTTW6aZ+mcVu2Q4tq11Wy56pNaZlg900 013TTT2asfzafE3RP2hbD44WvhPxTp3xY+JFj8RLv9pXxDoHh34U/FgfDC31DS9E+En7ImieGPEV gmo/F3w+PC3hrSPibB46uNI8IXnjW41nRJ9cvtcgtNbE11d6l1vhf4F/tcW/jzwT8dfFCeCNT+Jf hnxH8MfhzrMdzMlz4p1z4SaX4FPwv8eavB4gtfE2n+GIvC154+8Z+N/2nYvC9xpa+Jb1dH8P+HZL J/ElvbaI/wBCeJf20/AHhfUPiXp994N+KtxJ8Mv2hfhl+zzqUmnfDD4i38Wqa58TNF+HmsWfiDRp LbwjJHqumaanjwwfYtJfU9S1v+z9IuNChvoPHngVtd9y+DXxBvvib4R1jxHqGn2mmz6b8Vvjv8Po 7azkmkhksfhL8cPiH8KtM1B2nJcXerab4MtNUv41PkxX15cRW4WBIgP1KlhcHVxFSMcZWq1PaSxE YRmv3LpSjRvKSi3N060ajgqknFOU1yS96Uvz6eIxVKhByw1KnBwjRlOUH+9VROrZR5lGCnScFNwi pO0XzK6jH8x/CHwE/aTsBJ4mvvh/8Y7bVb/4cfso+DfjRaap8dfD+o+PPi9q/gH4g+NNc+Olx8OP Fcfxu1WPwl4b8RR+KtP1m30268VfC6HXdLtvFOhvoelTa29nqvtn7Kn7PPxM8H+Pk17x/p3xM8K+ CvD+l/EfWfAXhDWfjPqevQWXirx3+1P+1N43N3470vw58Q/Eml+OfGD/AAi+Ivw+/tXxD4pvPF0V zfX0wl1jUPEOkS3Fj+kNFdFLK8PSqUqinWm6SlyqbpOLcqntW5ctKLvzpSSi4x5kptOd5PCpmFap CpBwpRVRxbcFU5lywVNKLlUkkuT3W2nLlbjzctooooor0jhCiiigD6D/AGEf+T9/CH/ZoX7TX/q5 v2Mq/f2vwC/YR/5P38If9mhftNf+rm/Yyr9/a/HePf8Akd0v+xfQ/wDT2JP03g7/AJFVX/sNrf8A pnDnyF/wUG/5MI/be/7NC/aV/wDVM+NK/l9+LulftJaf4x8E+KfDTXPxH8M2Or/FDTrzwX8MDYfD TU9P0TxR4L1G28C6h4xl8f8Axhi8OeO5PDHiG10+K61nS/7C1GyvNQXWND8FGMXa2H9Qf/BQbj9g n9t44Bx+yF+0pwc4P/FmfGnBwQcH2IPoRX853/CqfHf/AEcv8bf/AAQ/s4//AEP9fS8A4eGIyfGR nX+r8uZuUZJ1U240MJNWUKVWMknFKSqRs1L3dbteHxjWlRzLCyjRVa+CcXFqDSTq14681SnJP3m0 4STutXbR/EPw4+Af7TmmaRo/iDxbrHxKn8f2XjH9ibTnhu/jbqeoaLD8O/BnhT9nGX9pJ20SLxtN 4Yur7V/F/gfx2PEt5cWNzr/jKOO/XTJtT03xRef2z+pdeJf8Kp8d/wDRy/xt/wDBD+zj/wDQ/wBH /CqfHf8A0cv8bf8AwQ/s4/8A0P8AX3eHwFDDKShjIS5t3UWIbb56k7trCxu/3ji2/sxgvs3fyFbF 1q7Tnh5Ll2UPYpJckIW1rvS0E7fzSk+p7bRXiX/CqfHf/Ry/xt/8EP7OP/0P9H/CqfHf/Ry/xt/8 EP7OP/0P9dPsaf8A0FUP/AcT/wDM5h7Sf/Pir99D/wCXHttFeJf8Kp8d/wDRy/xt/wDBD+zj/wDQ /wBH/CqfHf8A0cv8bf8AwQ/s4/8A0P8AR7Gn/wBBVD/wHE//ADOHtJ/8+Kv30P8A5ce214l+0v8A 8m4ftAf9kS+K3/qCa9R/wqnx3/0cv8bf/BD+zj/9D/XkH7Qnw08Z2HwD+OF/d/tCfF/W7Wy+EHxL u7nRdU0X4BxaZq9vbeDNamm0vUZdF+B+kaxFY38aNaXcmk6tpeppbyyNYajZXQiuYt8NSprE4d/W aDtXpaKOJu/3kdFfDpXfm0u7RlXqT9jW/c1V+6qat0bL3Hq7Vm/uTfkf2mUUUV/LJ/QQUUUUAFFF FABRRRQB/FV8BrL44Wv7P3wNvLT4q/BfQ9AuPhT8KLbRrbX/AIL+Lr++tYdV8MeHrDQNJvtai/aG 0Gy1bV5pruw0tbm10fSU1fVJkFlpNm11DYp7R/YP7R3/AEVb4Jf+I/8Ajv8A+iXr471X4T/E74pf sg/ATTtPuT4p8NaNoX7Enj3RPh/4BufEfww+Jc0fw68Z/BPxf40Z/ikvxp8K+G9YZvCGieM7zw7o t5o3hKO08QP4Z1C28QW+v+HtO1eTvvhP8Kfjn4U+K3h/xfrF78QJdH1z4pftSzeOrPxF8V77xXod p8Mtd8V3+r/AOztPCmo+MdZ0bT/sNkmn/wBmjwzpa61oC3eq2Gpz2VnqWpW9z/TWLzDEwzDEUVg4 Sp+20qrDYeXx4mdKTbVCUfcXLVd6nP7NynNQaSl+D4bBUJYKjU+syVT2etN1qq+GhCpG160Ze8+a mrQcedRjFyTbX0N/YP7R3/RVvgl/4j/47/8Aol6P7B/aO/6Kt8Ev/Ef/AB3/APRL17bRWv1ip/LQ /wDCXDf/ACky9jDvV/8AB9f/AOWHiX9g/tHf9FW+CX/iP/jv/wCiXo/sH9o7/oq3wS/8R/8AHf8A 9EvXttFH1ip/LQ/8JcN/8pD2MO9X/wAH1/8A5YeJf2D+0d/0Vb4Jf+I/+O//AKJej+wf2jv+irfB L/xH/wAd/wD0S9e20UfWKn8tD/wlw3/ykPYw71f/AAfX/wDlh4l/YP7R3/RVvgl/4j/47/8Aol6/ ox/4J84/4YJ/YhxkD/hkL9mvAJyQP+FM+C8ZOBk++Bn0Ffh3X7h/8E+f+TCP2If+zQv2av8A1TPg uvgPESpKplWC5lTVswjbkpUqe+GxG/s4Q5ttOa9tbWu7/Y8FQUMxxVnN3wUr81Sc9q9DbnlK2+tr X0vsjyL/AIKwR6jL+w/46i0e6srHV5fi/wDshx6VfalYT6tptlqb/tifAVbC71DSrXUtGutTsba7 MU13p1trGk3F7bpJaw6pp8kq3cP4Rpp37QUl5PpyfGH4EvqFrbWl7dWKfAbxs15bWd/LewWN3Paj 9pozw217Ppuow2k8iLFcy2F7HC7vaziP93P+CsEepS/sP+OotHu7Kw1eT4wfshR6Vfanp8+rabZ6 k/7YvwEWxu9Q0q11PRbrU7K3ujFNd6fbaxpM95AkltDqdhJIt1F/LX8UfgR8fLnx98dfF+gS+MdX 8cfEz9nz4FeCtI+Ifwy+Ieu/CvwjaeJvAXxg+LGpeL9J03wLrvxw1bUPB1+3w+8Y+FZ9E1bTRqen tqEfjy/tNZ8P614q1XT9dfA2LrYXhubpYdV1LO8xc70qVVpRyzLJJRUqVWfNOcYwSUVC8rymnZM4 sw9KvncfaV3RayrBKNqk4XcsfjotyanThyxjKU2+Zz92yi0219D+NPGfxC+G76RH8RP2mv2V/AUn iCW4g0FPGnwt1vws+tzWkllDdQ6QuuftT2LalLbS6lp0VxHZiZ4ZL+ySQK11AJO6/sH9o7/oq3wS /wDEf/Hf/wBEvXyZD+zH8WfEfj7xZ4X1rxd4+8K/B2S2/aM8F+HtePinw38RPE0nwt+Kui/sqyw+ E49U+Jb+P/EkEWteJ/DPxlvdPvdVt76+8ODS4bQ/YdFvPDdhc4HiL9n/AOPuiaF4ju/Bc/xIup5f 2jL+IeE5vix4q8R2eofswaR4J8RaP4G8NeFvDE/7Q3wi0LSbGx8ZX/h/XNS08fEXwL4jv9IsNYt9 ck8SWMi+Dtc+s/tTHKVRvAQlCMuWHLhcOpNxjHnavQbnBzlaEuSneCbUZyTivnPqGEagljJKUlzS 5q9XlScrRT/epRmo3coqVRKVk5Ri1I+l9Q8YfE/SfFp8C6p+0F+z1p3ipdN0DVpNLvvgP47tfJtP FfiFvCfhSOe+n/aVTToNQ8VeJEm0XwxpE14mreIr+1vIdGsr02V2Ye7/ALB/aO/6Kt8Ev/Ef/Hf/ ANEvXw74e/Zy+P8AoHjObx5DqfxP1jxFqdj+whpGta/rnxKi0jVdf0D4XfFfxHrfxs07xF4U034p +J/Cj3OmeBRoNjeF9X8R3HiQ6j4nXTfEPiXVfGPjq+176R/ZM8IfG3wha/EC3+Ni+J7ifUNR8M33 w5ude8d2HjQeHPhk+iMugfCnVZrPUp5L/wCInwzvxrFn8QfH09nfL8R7nWNG1qDxx4tS1az8M3Qz PF1KkYVcHGkqjqtS+p0OWnGEqiiqsnR5eecYRas+X31yuSabmrgcNCEp08VKbgqd4/Wat6kpRpuT px9qpcsZTktU5e6+ZRcWeo/2D+0d/wBFW+CX/iP/AI7/APol6P7B/aO/6Kt8Ev8AxH/x3/8ARL17 bRXf9Yqfy0P/AAlw3/yk4/Yw71f/AAfX/wDlh4l/YP7R3/RVvgl/4j/47/8Aol69c/ZZ0z4sWX7c H7E8vjzxr8O/EmkN8X/inHa2PhH4X+JfBOpQ6mf2O/2n2hu59V1n4vfEC1ubFLRL2GTTo9HtbiW4 uLW6XVIY7SW0vdGuz+A//J5/7EH/AGW34nf+sZ/tU1xZpXnLKc5i40Unkucp8uHoQf8AyLMXtKNN SXqmmdeX0orMsradS6zTLHrWqyX+/wCH3UptP0aaPtX/AILCQeI7r4cfsnQeEtV0TRPEMn7Xsf8A Z2qeI/D9/wCKdGtSv7KH7Vz3f23QdM8S+D76/E9gt1bW4g8R6b9lu5re9lN5DbSWF3+RX9g/tHf9 FW+CX/iP/jv/AOiXr9fv+CvUWsT/AA8/ZSh8P32m6Zrkv7WN2mk6jrOlXWu6VZX7fsg/tbi2udR0 ay1nw7eapZwy7XnsbbXdImuYw0UeoWrMJV/ne8WfCD4+m9/aH8ZXMPiL4h+LfEXir4O6F8O9L0f4 oeO/A/gT/hXx8OfBO0+Leu+Evhjpvx58H6fpFxF4k8O+Ltan8LeIfiP4a1DxXbaZc6BceLrvRPE+ pQeIfmeEMXWw3DeBVLDqtepjW26NKpblrYqdrulWq+97NQjFQ5XOcUnzSs/d4kw9OvnmM9pWdJqG FSXtKkL3pYeGyqU6eim5yk5cyjCTtZafUf8AYP7R3/RVvgl/4j/47/8Aol6P7B/aO/6Kt8Ev/Ef/ AB3/APRL18CeBvgb+12dDttc8X6h8S4fHPhSy/Z9j8EQN8Zr220uNNG/bM+OXiL4pw6z4btPi34t 8Pa1eJ+zBq/w10bUG8aa146uNT8Pzr4MtPFHinV7PW0rw34bax8cPi3afESL4d+PPiN4g8b6zq3h TxFr3hl/Ho161uPAGl/GvVdQ8YWF7Z6d+1N4ab4f/ELVfDfiHwr4dtvC+tad+yfqGseAfAOt6Bot hHBba94R0D3XndePslLAcs61OdSFOWFwyn7iknTcXh0/auUUuRX92pTlduageQsqov2jjjFKNKcI Smq9Zx9/lfOmqz/dqMpPmdvehONkouR+tv8AYP7R3/RVvgl/4j/47/8Aol6P7B/aO/6Kt8Ev/Ef/ AB3/APRL1a+AOh+MPDfwn8MaP48vPE174nt7jxPNeHxemmLrthZX/i7XtR0LQ5jpPxD+LME2n+Hd Au9M0DQ7q9+JPjPXbvQtN0268Ta9eeIptUYex16dPFVZwhOVOjByhGThLC4Xmg5JNxl+53i3Z+aO CeHpxnOKnUmoylFTjXr8skm0pL95tJK68meJf2D+0d/0Vb4Jf+I/+O//AKJej+wf2jv+irfBL/xH /wAd/wD0S9e20Vf1ip/LQ/8ACXDf/KSfYw71f/B9f/5YeJf2D+0d/wBFW+CX/iP/AI7/APol69c/ ZZ0z4sWX7cH7E8vjzxr8O/EmkN8X/inHa2PhH4X+JfBOpQ6mf2O/2n2hu59V1n4vfEC1ubFLRL2G TTo9HtbiW4uLW6XVIY7SW0vdGuz+A/8Ayef+xB/2W34nf+sZ/tU1xZpXnLKc5i40Unkucp8uHoQf /Isxe0o01JeqaZ15fSisyytp1LrNMsetarJf7/h91KbT9Gmj5e1LSfjVdfEf9oifwj8QPhdofh5/ 2vf2zf7P0vxJ8H/FnirWrUp+1f8AGRLz7Zr2mfHHwdY3wnv1urm2EHhzTvstpNBZSm8mtpL+6X+w f2jv+irfBL/xH/x3/wDRL15P8dPh98avH3iD426J4Y8WW8fgq/8A+ChfxqudU0LwWPEvw4+Ilj4J 0j/goL431L4oSah8VtP+KViNQ0i+8HWPiuGfQ/DvhTw9r1zZ39tYWGp3d7asdT4j4d/Bj40+D/i3 4b8T/wBp/Eefw5D8dfixp2tweJvjN4i8ZaKv7O0nwr1a0+GNrD4a8R+N9dsfMj+Itj4XuobmDS/+ E8trlr+71i6j03UNZN1MMwxFN0aUcGpU1GhD2rw+HlpKSpubaoz5lFWnJzqKfK25qLWreDoTVSo8 S4zvVl7P2taKvFc6jrVhZybcYqEHHmSUW09Po/8AsH9o7/oq3wS/8R/8d/8A0S9H9g/tHf8ARVvg l/4j/wCO/wD6JevbaK7/AKxU/lof+EuG/wDlJx+xh3q/+D6//wAsPEv7B/aO/wCirfBL/wAR/wDH f/0S9H9g/tHf9FW+CX/iP/jv/wCiXr22ij6xU/lof+EuG/8AlIexh3q/+D6//wAsPEv7B/aO/wCi rfBL/wAR/wDHf/0S9H9g/tHf9FW+CX/iP/jv/wCiXr22ij6xU/lof+EuG/8AlIexh3q/+D6//wAs PEv7B/aO/wCirfBL/wAR/wDHf/0S9f0Y/wDBPnH/AAwT+xDjIH/DIX7NeATkgf8ACmfBeMnAyffA z6Cvw7r9w/8Agnz/AMmEfsQ/9mhfs1f+qZ8F18B4iVJVMqwXMqatmEbclKlT3w2I39nCHNtpzXtr a13f7HgqChmOKs5u+ClfmqTntXobc8pW31ta+l9kfXtFFFfj5+mBRRRQAUUUUAFFFFABRRRQAUUU UAfnL/wVg0zTda/Yf8daPrGn2WraRq3xg/ZC0zVdK1O0gv8ATdT02/8A2xfgJa32n6hY3UctreWV 5ayy213aXMUkFxBJJDNG8bsp/APXP2UfhPrnibwjrD6dHo/hfwV4e8V+F9G+GHhrwv8ADbw54FOi eOvD3jHw34y0u5uNH8CWnj06L4ltfGt9qWr+GLXxxa+FLvxFpWgeI30L+2dN+2T/AL+/8FX7i5tP 2IPHN3ZWE2q3lr8Yf2Qri00u3mtba41K5h/bF+AksFhBcX01tY2815KqW8U15cW9rE8iyXE0UKvI v8xPxk+Of7Rnh3XPihrHhTRbPw5pPws+CXwW8f6h8Otb8NaR4r1a61X4nfEz48eAvFGuaj4w0fxl ZaNb+Hvhz4U8CaL8TdS0yxuWkvrTSms73XfD9rc6kJv1rgyeHhw3KVelKr/wtY+SUYOTtSwGVV3d 3jFqKpup7Nybm4rlhOSSPzniiNaedxjSqRp/8JeEXvTsr1MZj6KsrNpydRQ57JRUnecVc9k8B/sm eF/hnL8Pr7wV8SfitpOueCdL8R6LrviS7v8AwH4h134raZ4t8fxfErxBB8S7vxN8PtZiuJ7/AMUN qko1PwZb+CtXtLLXtTsrK/to49IOl+kfCn4L6R8J9Q8e6tYeJfEniXVPiPr9v4m8SXeu2HgPRoZN ZhtDa3OowaT8OvBPgTQjqerszXmu65e6Xe+INbu/JbUtWuYLOwgtfzs8R/tc/G/TrT4aaZa+Mvhf HD4qvfibf6b8QbXxN8Idc0jU/D/hDxX8INH0m8+JGuDxrpfw90HTNN03xp4/XxxL8L9V8V+JILvw 54T1q10DR7e+1jwxL9X/AAA+Nvjn4i/Fj4reC/FVxoy+GPBbaw/wy1ux0u6sJvi/4cHxF8XeHtS8 Z2rXYjhisfhzdaDp/wAM76DSkeHXNYS4+I3m/wDCIePvh1Gv1GHxGBdWnTo0qsJRcFTTUlCLnh01 aPtHFWopRlPl5XJxipSnUhz/AD9eji1SnUq1ISjJSc2rOcoxrNfFyJtOo+aMFK6im3GMYS5fseii ivWPNCiiigArs/gP/wAnn/sQf9lt+J3/AKxn+1TXGV2fwH/5PP8A2IP+y2/E7/1jP9qmuPMv+RVn H/Ylzn/1V4s6sB/yMcs/7GmWf+p+HP6Ta/A3/gslqPwlsvjD+yXafGu++HVp4E1z4P8A7XGk3Vr8 Urrw1B4S1jUU8e/sZaxp+m3EHix00fUL1W0mTVLOzkWadW0x72CMGyaWL98q/FL/AIKgf8nH/sh/ 9kS/bE/9Tv8AYur8h4FUHxPgFUi5wdDNlKKaXNF5PmCavKM1qtNYyXkfpfFrksgxjhLlkquXOMmm 7NZng2nZSi9OlpJ31ufhDrGl/scahB46stI/am8C+DdN8Z/EH4Q/FOw0nwn8UfgPZaV8P/HPwU0v 4a6H4P1bwLYajoWq29rZyaJ8JfBGk6n4c8SJ4m8L/ZNOnOkaLo9xeTzt7N8Pfix+yx8NdA1Dw7oX 7RPwlu7LUfHHxO8fzy6t8XPh1PdJrPxX+JXiz4peIraJ7PUrCFdMsvEHjHU7PRYXge6ttGgsLe+v dRvYrjULr6lor9rhRwFObqQw1aM3GUW1iYfDKbqSSX1ayTnJydkui2SS/KZVMXOKhKvTlFOMrOjL eMFTi/419IRUfx3bb8S/4aX/AGcf+jgPgl/4dbwJ/wDL6j/hpf8AZx/6OA+CX/h1vAn/AMvq9tor bmw3/Pmv/wCFFP8A+ZTO1f8A5+Uv/BM//l54l/w0v+zj/wBHAfBL/wAOt4E/+X1H/DS/7OP/AEcB 8Ev/AA63gT/5fV7bRRzYb/nzX/8ACin/APMoWr/8/KX/AIJn/wDLzxL/AIaX/Zx/6OA+CX/h1vAn /wAvqP8Ahpf9nH/o4D4Jf+HW8Cf/AC+r22ijmw3/AD5r/wDhRT/+ZQtX/wCflL/wTP8A+Xnpv/BO D4l/Dj4i/t7aEfh98QPBPjoaN+yF+0cNXPg3xVoXicaUdR+M37Hv9njUjol/ffYTffYL77H9q8r7 V9ju/I3/AGebZ/RnX4BfsI/8n7+EP+zQv2mv/VzfsZV+/tfjHiA4vPKbgpRj/Z+HspSU5L99ib3k owT1u17qsrLW13+o8G8yympzNOX12tdxi4p/uqFrJyk1pb7Tu9dNl8hf8FBv+TCP23v+zQv2lf8A 1TPjSvw8r+iP9oH4VL8dvgL8bvgg+unwuvxk+EXxJ+FTeJl0wa03h1fiH4N1rwiddXRzf6UNWOkD WDqA0w6ppovzb/ZTf2fm/aI/yv8A+HX/AO0d/wBHd/BL/wAQ78d//Ro16PBmd5RluXYmhmOPhg6s 8bKtCM8Pja3PTlQoQ5lLC4XERVpU5JqbjLZpNO5xcU5VmWPxmHq4LBzxNOGG9nOUa2Fpcs1VqSs1 iMRRk7xkmnFSW6bTPiyivtP/AIdf/tHf9Hd/BL/xDvx3/wDRo0f8Ov8A9o7/AKO7+CX/AIh347/+ jRr7D/Wvhj/od0P/AAizj/52nzP+rmff9Cur/wCFWW//ADcfFlFfaf8Aw6//AGjv+ju/gl/4h347 /wDo0aP+HX/7R3/R3fwS/wDEO/Hf/wBGjR/rXwx/0O6H/hFnH/ztD/VzPv8AoV1f/CrLf/m4+LKK +0/+HX/7R3/R3fwS/wDEO/Hf/wBGjR/w6/8A2jv+ju/gl/4h347/APo0aP8AWvhj/od0P/CLOP8A 52h/q5n3/Qrq/wDhVlv/AM3HxZXiX7S//JuH7QH/AGRL4rf+oJr1fqB/w6//AGjv+ju/gl/4h347 /wDo0a5jxv8A8Ekvj34/8F+L/Amt/tg/CG30Xxr4X1/wlq8+lfsg+M7fVINL8SaVd6NfzabcXf7Y 1/aQX8dpeyvZzXVje28VwsbzWlzGrQvrQ4u4Xp1qNSWd0OWFWnOVsDnDdozTdl/ZursiKvDefzp1 ILKqt5QnFXxeW2vKLSv/ALb3Z+6lFFFfgJ+xBRRRQAUUUUAFFFFAH8Zvwo+KfhD4bfsufAHUNdu7 i9vpfhL8D9C0vwzoFv8A2z4r13X/ABJ4S8NaboGi6Rods4uJbzU7y5iVZ7k2mmWNoLjVdWv9P0iy vb+266P9pn4bt4ms/DM1r43sZH8Q+DvBWtazqfgnX9N8P+D/AIg/EHRtH17wZ8PvF2pX1rB/ZHi3 XtO8ReHGhsxDcWVld+JfDGnarqFhqHibw/bal8r/AA/1P9kbxV8BPgfb+I/i/wDBzwD8TNB+HfwP v38aaT42+E2kfFDwv4s8BeHPC01lDdXPiWPV1kudLutKGj6joPijR9UsDZrcaZe6Z8irD18S/skf 8JXH4o1D9rXwvrMN54o8B/EHxd4X1P4zfBs+GPH/AMUfht4b8O+GfCfxL8UQWOnWOrW/iSxtvBvg vUZdL8J6x4X8EXGteENA1CTwjutJY5/6ax2HzV4zEexwsnTeIm1J0qkk4udW7b91p39m3yxklTcn BynZH4PhK2X/AFal7SulP2MbpVIK0lGlZJapq3tLXkrzUVNRhdvsIv22vhtPo/gXx3/YXjvT/hf4 68F6h4u0nxJq/gjxRZ+INUhuPF/7O/hDwdP4a8FRaXc+IPEeieJ9Q/aA06GDVdOtZHmuNCuho9pr FpcQ3bYfin9tLw5beL/hzpekJd+GfCtxY/HjxP8AGXX/ABv4C8W3V58O9D/Z3Tw4PHGgahY6Veaf b6LqzjxJFqH/AAk8194h0nTtLtrC6t9C1+HxPpNxFg3ej/sSXvgr4Q+Apf2jfh+NC+CngLwj8OvC JT41fDMX1zoPgrxl8E/HGjTa5cGVlvNSOsfAXwXFeXFpDp8E9hd+IIUtIpr6yudMj1Hw9+wtrOo+ Kr7W/j98NtXg8a2Xx70vxFpN18bfh9Dpt7pf7R9p4LsPiPpynT76y1C3gay8C6Tb6HLBqEd5pq3O pPJdXks1tJacEsHnrulSWqw8k/Y1o2mnTliI3inJUnyzjFaztOT5r8vL1xxOUJpub3rr+LTl7rUl Rdno5rmUm9I3ik42vf65+HXxc8NfEm88RaPp2m+KvDfiTwrFoN7rnhXxv4cvvC/iOz0bxXb3t14W 146bfAs2k6/FpmrRWkok+02mpaPrWh6xa6Zrujapplp6lXx38NvHv7MXw7vvEmvXP7VvgP4g+L/F lv4d03WvGnjz4vfCKbxBcaD4Qtr+Dwv4djj8Jw+EtCh0rRZtZ8Q6lC0eiDUrzVvEet6hquo6hcXa tD6v/wANL/s4/wDRwHwS/wDDreBP/l9XoUcNjnTi62GrKpeV0qM17vPLkvbmXNycvPyycefm5Xax x1a+F537KtTcLRtepHflXPa7T5efm5bpPltfW57bRXiX/DS/7OP/AEcB8Ev/AA63gT/5fUf8NL/s 4/8ARwHwS/8ADreBP/l9Wn1XE/8AQPX/APBNT/5Ez9vQ/wCf1L/wZD/M9tr9w/8Agnz/AMmEfsQ/ 9mhfs1f+qZ8F1/Of/wANL/s4/wDRwHwS/wDDreBP/l9X9GP/AAT5BH7BP7EIIII/ZC/ZrBB4II+D PgvII7EV8B4iUqtPKsF7SnUp82YR5eeEoXthsRe3Mle11e2113PseCqkJ5jiuScJ2wUr8slK169C 17N2vZ2v2Z5X/wAFUpY4f2LPF000iRQxfGr9jqWWWV1jjijj/bK+ALvJI7EKiIoLO7EKqgkkAE1+ DfiX9ov4Y+Fda8RaVqN/q9zp3gnwfceOviB4w0bQdT1vwV4A8OxaVr2uQXXizxDpcN1b2M19pPhj Xb+G2tY72W1t7O2fVRpw1vw9/a/7o/8ABWyXQrf9hP4i3HimXSYPDEHxW/ZKn8Rza+9nHoMOgQ/t f/AeTWJtbk1Erp8ekRactzJqcl+y2SWSztdEQCQj+abWbP8AYm1S+8ZpZftB/Crwt4K+JXga5+H3 xL+FvhH4ofBzQvAPjrQbjQvFvh1JNUggtn8T6LqNvpvjHUlF14M8UeF0vZbTSn1aDURZlJr4FpY2 pw5N4Sj7S2eY5TfJOdr4DKuXSNko83Lzu7kqfO4QlNRTXF08LDO4fWanJfKsJyrmjG/+2Y+7u7tt R5uVW5XPl5mo3Z6xfftc/DbTWtdOv/DfxXtvGF/4l0bwvYfDlvht4hl+IN7d+JvA3jv4ieF9Rh8M wRS3I0TX/DPw18ayw6pNJFDo+o+HtY0jxQNB1LRtZttOybn9sf4ceHUv4vG1j4k0u80rV/irLrUm heHdb8S6L4Z8A/DP43eL/gzcfEDxRrVnYR2mj6Q154Zg1XVbdjPfafBfXEltbajY6beX0XAeH2/Z H0rxX4a8fa7+1j4S8fePvDHizS/FVp4y8Y/GX4OnWL1NB+GPxM+FXh/wzqMHhex8MaLJ4b0TQ/i/ 8QNXtYbTSbPWLrxTr9zrWrazqReS3kydc8PfsQ+IbP4gWOo/tIeAjb/EnwX8UPAniAQfGv4YRNFo vxa+J/iX4teJpdMbcxtr+28S+KtSttGnn+1Q2ujRWdrd21/dxS38/wBX9VzuzksPaX7xQhKhUSte m6bqOLl77SnGahLli7tc148vzvt8q5knVvH3HKUasb3fMqihdfDH3ZRcouUtnbW/W+Bf2w7XV7nx 7N4m8O+J7hrT4l/Gbwn4D8DeDPhj4z1DxjL4N+APiOHwl8Q/H2tX93eGy1nTYdTv9Emlg07RtAut I1DX9J8EWFt4v8UXlqLj7J8O+IdF8W+H9C8V+G9SttY8O+JtG0zxDoGr2bF7TVdF1qyg1LStStXZ VZra+sbmC6gZlUtFKpKgnA+Db7TP2Py0d74a/a18OeBPEMev/HDWf+Eq8J/Gz4QLrj2H7Q/i6z8c fE/wsV8Q2PiHR00HUvEmk+H7/S7iHSIvE2gyeHNIk0rxHbTrfTX30H4Z+On7Kvg7w34f8IeGfjf8 DNI8N+FdE0rw34f0m2+K/glrfS9D0Owt9M0nToGn8RSzNDZWFrb20RmlklKRKZJHfLHbDYTNItxx FCpKKjG0lSqc0ptRcuj2m6iatGKiqShdc1sq+IwDUXQqwUm3eLqQsoptR7bxUHe7bl7Ryt7t/oii vEv+Gl/2cf8Ao4D4Jf8Ah1vAn/y+o/4aX/Zx/wCjgPgl/wCHW8Cf/L6uv6rif+gev/4Jqf8AyJze 3of8/qX/AIMh/me212fwH/5PP/Yg/wCy2/E7/wBYz/apr5f/AOGl/wBnH/o4D4Jf+HW8Cf8Ay+r1 z9ln4vfCf4gftwfsT6P4D+KHw78bava/F/4p6pdaV4R8a+GvEmpW2mQ/sd/tP2k2oz2Ojane3UNj Fd3tlayXckS26XF3awtIJLiJX4s0w9eGU5zKVCtGKyXOW5SpzSS/szF6tuKS+Z15fWpSzLK1GrTb eaZYklOLbf1/D6JJ3Z+mH/BWiaG38GfsjXFxLHBbwftc3E0880ixQwwxfsh/tbvLLLK5VI440Vnk kdgqKCzEAE1+MXiH9pX4Y+GdV8b2OoSeKLjSfhxY20/jfxlo/hHXdc8G6Bqt94Us/HGmeFZ9a0m0 uzd+KNV8JaroWsabpmm216l23ibwpo8dz/wkHinQNJ1H9e/+Cymq+DdF+FX7LWofELUvDOk+Cx+1 m9l4hvfGV5pVh4XFlqv7Jn7WGkraazc63JFpItdSub2DTRBfP5V5PdxWYSSS4SN/5/tf079jHXZP iFZRftNeAvD3gz4n2tkfF3w48M/GD4Q6T4MuPEGkeCdB+HugeL9MRbabxHoeu+HvDHhPwjbaRZ6P 4jsvCkN74U0LVLjw1c6jaPczfM8IUsdPhvAywdD2tquMUm4TlFP6xiGk3GyS53T57NyUHJxi5cp7 vElTCQz3GLFVeT3MM4pSjFtexoJvW7fuKpy6KLmo3klc9qsf2r/hrfeLfDvw9XR/iPB8RPEGv6v4 dl8CzeAtafxD4butCh+Hep6tqHikWqXOlaT4fs/DPxR8IeLT4j/tO40WbRru7tLa9m8SWFzoCYfh D9sH4d61bfDO01+w8SaP4h8c+A/gH4v1ttO8O65rXg7wTfftGTSaL8NdD1vxfDYQ2cc/iTxnC3hP SZPIDPfXen3N/Fp9jJeXNlwvhC6/ZF8K/EGz+K95+1P4H8Y/EWEeNhqHinxR8Xvg5Hc67/wnGkfC /wAP3o1LTfCtl4X0K2i0fQ/hD4P07QrTQtK0ayttusahf22o6vrN9qMmRpWj/sSaRp1nplv+0b8P 5ILLRf2WtCjkn+NXwzaaS0/ZD8br4/8AhbJK0UsUZub7XECeMHjiji1awzb6bDosv+kV9H9Vzu6f sHa9W0ZUKifIqcJUefluvayqqUKrhL2cYybgm+Vnie3yq1nV1tTvJVY253UkqvKml7kabUqfMueU kuZq8ovS+Gn7bmgav4M1vxl8QtK8R2Cx+KfjXqMWheG/hj4x/tDwH8Hfg/49v/A2peOfHUt1f6nN q1tayWIvNV1DRNL0u8uNSbXfDfh3wfrFx4L17UW+8YZobiGK4t5Y57eeNJoJ4ZFlhmhlUPFLFKhZ JI5EZXSRGKupDKSCDX5yX/hH9iq40ltH0v8Aao8K+Gba/wBI+LXhbxRNoPxr+EC3njLwT8aviBqv xK8a+DNdudWsdWe00r/hItb1VNC1bwuPDnjHQNOvrq307xPFNc3F1L9XQ/tI/s128MVvb/Hv4HQW 8EaQwQQ/FLwFFDDDEoSKKKJNdVI440VUSNFCooCqAABWuFwmaRTjiaFSXLCklONKpec+W9Vt6u3P snGKX2U42tnicRl8mpYerCN51LxlUhZQuvZpba8t76tvRyfM2e40V4l/w0v+zj/0cB8Ev/DreBP/ AJfUf8NL/s4/9HAfBL/w63gT/wCX1df1XE/9A9f/AME1P/kTm9vQ/wCf1L/wZD/M9trs/gP/AMnn /sQf9lt+J3/rGf7VNfL/APw0v+zj/wBHAfBL/wAOt4E/+X1eufss/F74T/ED9uD9ifR/AfxQ+Hfj bV7X4v8AxT1S60rwj418NeJNSttMh/Y7/aftJtRnsdG1O9uobGK7vbK1ku5Ilt0uLu1haQSXESvx Zph68MpzmUqFaMVkuctylTmkl/ZmL1bcUl8zry+tSlmWVqNWm280yxJKcW2/r+H0STuzy7xf8U/C Hw21n4/ahrt3cXt9L+2h+15oWl+GdAt/7Z8V67r/AIk/bI+Mum6Bouk6HbOLiW81O8uYlWe5Nppl jaC41XVr/T9Isr2/tudj/aZ+G7eJrPwzNa+N7GR/EPg7wVrWs6n4J1/TfD/g/wCIPxB0bR9e8GfD 7xdqV9awf2R4t17TvEXhxobMQ3FlZXfiXwxp2q6hYah4m8P22pea/Fb/AIZY1T4kftEab43+J/wp +F/xV0f9tf8Aao8Rp4sh8V/C3w38V/Dms+Hv2v8A4reIPDF5M/i231Np4ZLCHT1TTfE2i6rpGo6D dpE9hNazW8ichEv7JH/CVx+KNQ/a18L6zDeeKPAfxB8XeF9T+M3wbPhjx/8AFH4beG/Dvhnwn8S/ FEFjp1jq1v4ksbbwb4L1GXS/CeseF/BFxrXhDQNQk8I7rSWOeVQzRxpOjhnKlKNJxl7Kck4OMndy 916v2bfLGSVNycHKdkP2uXpzVWslUTqJx54pqSlGytqtF7S13FuaipqMbt9hF+218Np9H8C+O/7C 8d6f8L/HXgvUPF2k+JNX8EeKLPxBqkNx4v8A2d/CHg6fw14Ki0u58QeI9E8T6h+0Bp0MGq6dayPN caFdDR7TWLS4hu2w/FP7aXhy28X/AA50vSEu/DPhW4sfjx4n+Muv+N/AXi26vPh3of7O6eHB440D ULHSrzT7fRdWceJItQ/4Sea+8Q6Tp2l21hdW+ha/D4n0m4iwbvR/2JL3wV8IfAUv7Rvw/GhfBTwF 4R+HXhEp8avhmL650HwV4y+CfjjRptcuDKy3mpHWPgL4LivLi0h0+Cewu/EEKWkU19ZXOmR6j4e/ YW1nUfFV9rfx++G2rweNbL496X4i0m6+Nvw+h0290v8AaPtPBdh8R9OU6ffWWoW8DWXgXSbfQ5YN QjvNNW51J5Lq8lmtpLTKWDz13SpLVYeSfsa0bTTpyxEbxTkqT5ZxitZ2nJ81+Xl0jicoTTc3vXX8 WnL3WpKi7PRzXMpN6RvFJxte/wBc/Dr4ueGviTeeItH07TfFXhvxJ4Vi0G91zwr438OX3hfxHZ6N 4rt7268La8dNvgWbSdfi0zVorSUSfabTUtH1rQ9YtdM13RtU0y09Sr47+G3j39mL4d33iTXrn9q3 wH8QfF/iy38O6brXjTx58XvhFN4guNB8IW1/B4X8Oxx+E4fCWhQ6Vos2s+IdShaPRBqV5q3iPW9Q 1XUdQuLtWh9X/wCGl/2cf+jgPgl/4dbwJ/8AL6vQo4bHOnF1sNWVS8rpUZr3eeXJe3Mubk5eflk4 8/Nyu1jjq18Lzv2Vam4Wja9SO/Kue12ny8/Ny3SfLa+tz22ivEv+Gl/2cf8Ao4D4Jf8Ah1vAn/y+ o/4aX/Zx/wCjgPgl/wCHW8Cf/L6tPquJ/wCgev8A+Can/wAiZ+3of8/qX/gyH+Z7bX7h/wDBPn/k wj9iH/s0L9mr/wBUz4Lr+c//AIaX/Zx/6OA+CX/h1vAn/wAvq/ox/wCCfII/YJ/YhBBBH7IX7NYI PBBHwZ8F5BHYivgPESlVp5VgvaU6lPmzCPLzwlC9sNiL25kr2ur22uu59jwVUhPMcVyThO2Clflk pWvXoWvZu17O1+zPryiiivx8/TAooooAKKKKACiiigAooooAKKKKAPzy/wCCpv8AyZh4q/7Lb+xx /wCtmfACvxd1f4g+AvD+tQeHNf8AG/hDQ/ENzp0+sW2g6v4l0bTdauNJtrPWtRudUg0u9vYL6XTr fT/DfiK+nvY4GtorPQdaupJVg0u+eD9lv+Cr9kmp/sQeOdNlnvbWPUPjD+yFZSXOnXlxp2oW6Xf7 YvwEgeew1C0kiurG9hWQyWt5bSx3FtOsc8MiSIrD+bH4o/sbr4+f4sm28VzLP4y+EHwQ+H3hPX/E 15rHiTxdpup/CX4t/Fz4q6xBrvie8uG1yfwp47bx34f8K63badqUV8/h/TtStcBItMRf1/gideHD k3QpRqv+2sxbUp8vw5dlclHb7coxpqV7Rck2mkz814rhRlncPbVHTX9l4NJqPNvjsdFvr8EZSm4p XkoNJptHp3xEtP2WPiDb+GvH3j7xd8PbrS9Z0DVtA0bxKnxTTw54e8d+DbzWNLsdb8K6vdaF4q0j RPiZ4GuNeu9L0/UvCfiP/hJPCz6nqiWNxpn2jWJYbv1rwD8RtE+Iv/Caf2Ja6ra/8IJ4/wDEfw51 f+1YLSD7Trfhj7H9vutN+yX1952lTfbovsc919ju5NsnnWNvhd/55+K/2V/imfGPgzTfCugeABce KfhF+2XpfxH8VeM9X+IXxJ0HSte+M9x+zd4YsNQtNf1+WDWn8Zavo3hjVtQFnHpej6NrGg6L4u0G ZbXUNYvPFdx9nfs8/Bm7+B/hjxZ4ZuvEB8Sx638Qdd8WWGpTCX+0Dp2pafomn2sWsSyBVuNXK6S0 +oXMKiCaectGAMivp8PUxEsRNSwsKULQ9rVjGzqzdCnOLvJRlLllOULNNwcXFybvb5+tCjGhFrES qSs3Tpt39mvayg1ZNxjeMFJ6rmumkra++0UUV6RwhRRRQAV2fwH/AOTz/wBiD/stvxO/9Yz/AGqa 4yuz+A//ACef+xB/2W34nf8ArGf7VNceZf8AIqzj/sS5z/6q8WdWA/5GOWf9jTLP/U/Dn9Jtfil/ wVA/5OP/AGQ/+yJftif+p3+xdX7W15F8Vf2fvgL8dl0JPjf8EfhF8ZF8LnU28Mr8Vfht4N+Ia+HW 1oWA1htCHi7RdYGkHVhpWljUzp4tzfjTbAXXm/Y7fy/w7h3M6WT5vhcxr06lWlRhjIThS5faP6zg sThU488oxfJKuptOSvGLSd2j9ZzrAVMzy2vgqU4U6lWeGlGdTm5F7DFUMQ0+VOXvRpOKaTs2m1Y/ ncor9w/+HfP7BH/RkP7IX/iNXwZ/+Yuj/h3z+wR/0ZD+yF/4jV8Gf/mLr9C/4iBlP/QJmP8A4Bhv /mn1/p6fF/6mZh/0E4L/AMCr/wDyj1/p6fh5RX7h/wDDvn9gj/oyH9kL/wARq+DP/wAxdH/Dvn9g j/oyH9kL/wARq+DP/wAxdH/EQMp/6BMx/wDAMN/80+v9PQ/1MzD/AKCcF/4FX/8AlHr/AE9Pw8or 9w/+HfP7BH/RkP7IX/iNXwZ/+Yuj/h3z+wR/0ZD+yF/4jV8Gf/mLo/4iBlP/AECZj/4Bhv8A5p9f 6eh/qZmH/QTgv/Aq/wD8o9f6en4eUV+4f/Dvn9gj/oyH9kL/AMRq+DP/AMxdH/Dvn9gj/oyH9kL/ AMRq+DP/AMxdH/EQMp/6BMx/8Aw3/wA0+v8AT0P9TMw/6CcF/wCBV/8A5R6/09Py/wD2Ef8Ak/fw h/2aF+01/wCrm/Yyr9/a8K+F/wCy7+zN8EddvfFHwX/Z2+BXwh8TalpM2gaj4i+F/wAI/AHgDXb/ AEK4vLHUbjRb3V/Cnh/SdQutJn1DTNNvptNnuJLOW80+xunhae0t3j91r4LiXN6GdZjHF4elVpU4 4alQUa3IpuUJ1ZuVoSnFK9Sy95t2u7XsvsMiy2rlWClhq1SnUnKvOs3S5uRKUKcFFOcYtv8Ad3b5 VvbpdlFFFfPnshRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfyJfs0f8m4fs/wD/AGRL 4U/+oJoNe214l+zR/wAm4fs//wDZEvhT/wCoJoNe21/T+K/3nEf9f63/AKckfgVD+BR/69U//SIh RRRWBqFFFFABRRRQAV+4f/BPn/kwj9iH/s0L9mr/ANUz4Lr8PK/cP/gnz/yYR+xD/wBmhfs1f+qZ 8F18H4g/8irB/wDYwh/6jYk+v4M/5GOJ/wCwKf8A6foHl/8AwVN/5Mw8Vf8AZbf2OP8A1sz4AV+R lfrn/wAFTf8AkzDxV/2W39jj/wBbM+AFfkZXVwD/AMk7U/7HWP8A/UHKTDjH/kdQ/wCxXhP/AFLz EKKKK+yPlwooooAKKKKACuz+A/8Ayef+xB/2W34nf+sZ/tU1xldn8B/+Tz/2IP8AstvxO/8AWM/2 qa48y/5FWcf9iXOf/VXizqwH/Ixyz/saZZ/6n4c+8P8AgrF/yKP7IP8A2d7J/wCsi/tbV+blfpH/ AMFYv+RR/ZB/7O9k/wDWRf2tq/NyvC4M/wCSdwX+PF/+pdY9bij/AJHeL/w4b/1GpBRRRX1J8+FF FFABRRRQAV2fwH/5PP8A2IP+y2/E7/1jP9qmuMrs/gP/AMnn/sQf9lt+J3/rGf7VNceZf8irOP8A sS5z/wCqvFnVgP8AkY5Z/wBjTLP/AFPw55fp3/I3fHz/ALO9/bW/9a6+NlbtYWnf8jd8fP8As739 tb/1rr42Vu100/4dP/BH/wBJRzz+OX+KX5sKKKKskKKKKACiiigAr9w/+CfP/JhH7EP/AGaF+zV/ 6pnwXX4eV+4f/BPn/kwj9iH/ALNC/Zq/9Uz4Lr4PxB/5FWD/AOxhD/1GxJ9fwZ/yMcT/ANgU/wD0 /QPr2iiivyM/SQooooAKKKKACiiigAooooAKKKKAPzl/4KwahBpP7D/jrVbqO9ltdM+MH7IWoXMW maZqWtalJBZ/ti/AS5mj0/R9HtL/AFfVr1442W00zSrG81K/nMdrY2lxdSxQv/Lz8bf2tvjH4Tu/ j5qHwy8EeC73wl8N/wBlvw98a/Dc/wATY/iZ4A8YR+IdQ8ZfFHwzqA1zwLrfgPTdZbTjF4EmlstF vpfDdxOtjYahBrs+n+Kt3h/+ob/grBfwaT+w/wCOtVuo72W10z4v/sh6jcxabpuo6zqUtvZftifA W6mj0/R9Htb7V9WvnjiZbTS9Ksb3U9QuDHaWFpc3c0UL/wA+Hifxd+z541vb7UfF3wm+IXiS/wBU 8Kap4F1O81r9kv4/ajc6l4M1pbhdU8LahNc/CKR73QbwXl6JNLuTLaL9v1Dy4kN/eed+wcEYXG4n hmosJKpBrOswTlTpyk05ZdlcY3kozSUXJT5XC8nFWlE/NOK6+FoZ7TeJjGV8rwdlOcYppY3Ht+63 BttJx5ueyUtYyOl+B/i/xp4n8WftI6b40mtFuPBHxm8J+GNJ0bTrwappPhiyv/2Xv2cfHWsaDo+t SaJ4dv8AXNMj8a+NPFeo2mr6to+n6jeLqReSw02AW+mWX0JXzZ4Y+JvwZ8FwX9t4T8A/Fnw/Bqlx pt5qSaX+y7+0Va/2hd6P4Z0DwZpd1etH8KA9zcWHhPwr4b8PW08zPLHpOh6ZZBvJtIlXpv8AhoDw J/0Afjb/AOI0ftHf/Opr7ujg8ZCFp0a8pc9WV/ZVHpOrOcY3cF8MZKOiSVrJJWR8jVxOGnK8KlKM eSnG3PBawpxhKVlJ/FKLlq29btt3Z7bRXiX/AA0B4E/6APxt/wDEaP2jv/nU0f8ADQHgT/oA/G3/ AMRo/aO/+dTWn1XE/wDQPX/8E1P/AJEz9vQ/5/Uv/BkP8z22ivEv+GgPAn/QB+Nv/iNH7R3/AM6m j/hoDwJ/0Afjb/4jR+0d/wDOpo+q4n/oHr/+Can/AMiHt6H/AD+pf+DIf5nttdn8B/8Ak8/9iD/s tvxO/wDWM/2qa+X/APhoDwJ/0Afjb/4jR+0d/wDOpr1z9ln4oeGvG37cH7E+laNpnxEsrq2+L/xT 1GSXxd8Ifix8P9Na3i/Y7/aftWjg1jx54K8N6RdXxku4mj0u1vptTmt0uruG0e0sr2a34s0w9eGU 5zKVCtGKyXOW5SpzSS/szF6tuKS+Z15fWpSzLK1GrTbeaZYklOLbf1/D6JJ3Z/UjRRRX82n7kFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB8ht/ wT7/AGCnZnf9iL9kNmYlmZv2bPgyzMzHJZifBZJJJJJJJJOTSf8ADvn9gj/oyH9kL/xGr4M//MXX 17RXo/2vm3/QzzH/AMLcT/8ALfJfccf9nZf/ANAGD/8ACWh/8h5L7j5C/wCHfP7BH/RkP7IX/iNX wZ/+Yuj/AId8/sEf9GQ/shf+I1fBn/5i6+vaKP7Xzb/oZ5j/AOFuJ/8AlvkvuF/Z2X/9AGC/8JaH /wAr8l9x8hf8O+f2CP8AoyH9kL/xGr4M/wDzF0f8O+f2CP8AoyH9kL/xGr4M/wDzF19e0Uf2vm3/ AEM8x/8AC3E//LfJfcH9nZf/ANAGC/8ACWh/8r8l9x8hf8O+f2CP+jIf2Qv/ABGr4M//ADF0f8O+ f2CP+jIf2Qv/ABGr4M//ADF19e0Uf2vm3/QzzH/wtxP/AMt8l9wf2dl//QBgv/CWh/8AK/JfcfIX /Dvn9gj/AKMh/ZC/8Rq+DP8A8xdfU+gaBoXhTQtF8L+F9F0nw34Z8N6TpugeHfDugabZ6PoWgaFo 9nDp2kaLoukadDbafpWk6Vp9tb2Om6bY28FnY2cENrawxQRIi61Fc9fG4zFKMcTi8TiIwbcI169W sotqzcVUnJRbWjas7aG1HC4bDtuhh6FBySUnRo06bklsm4Ri2l0TOR8d/D/wH8UvCmreA/ib4J8I /EXwPrws11zwZ478N6N4u8Ka0unahaavp66t4d8QWWoaRqIsNVsLHU7MXlnMLXULK0vYNlzbQyp8 4f8ADvn9gj/oyH9kL/xGr4M//MXX17RToY7G4WDp4bGYrDwcnNwoYitRg5tRTk405xTk1GKcmr2j FXskKrhMLXkp18Nh601FRUqtGnUkoptqKlOMmopttJO123uz5C/4d8/sEf8ARkP7IX/iNXwZ/wDm Lo/4d8/sEf8ARkP7IX/iNXwZ/wDmLr69orf+182/6GeY/wDhbif/AJb5L7jL+zsv/wCgDBf+EtD/ AOV+S+4+Qv8Ah3z+wR/0ZD+yF/4jV8Gf/mLo/wCHfP7BH/RkP7IX/iNXwZ/+Yuvr2ij+182/6GeY /wDhbif/AJb5L7g/s7L/APoAwX/hLQ/+V+S+4+Qv+HfP7BH/AEZD+yF/4jV8Gf8A5i6P+HfP7BH/ AEZD+yF/4jV8Gf8A5i6+vaKP7Xzb/oZ5j/4W4n/5b5L7g/s7L/8AoAwX/hLQ/wDlfkvuPkL/AId8 /sEf9GQ/shf+I1fBn/5i67HwD+x5+yR8KfFemePPhd+y1+zn8NvHGiC+XRvGfgH4I/DPwf4r0hdT 0+70jUl0zxF4e8Madq9gNQ0q/vtMvhaXkQu9PvLuyuPMtriaJ/oyionmmZ1ISp1Mxx06c4yhOE8X iJQnCS5ZQlGVRxlGUdJRaaa0asVHAYGEozhgsJCcGpRlHDUYyjKLTjKMlBOLTSaaaaaTWx518Tvg /wDCT42eH7Xwn8Zvhb8Ofi54WstWt9fsvDXxO8EeGfHvh+0120tL6wtNatdG8VaZq2nW+rWtjqmp 2VvqUVsl5DaajfW0cyw3dwkng/8Aw75/YI/6Mh/ZC/8AEavgz/8AMXX17RUUcwx+GgqWHxuLoU03 JU6OJrUoKTs21CE4xu2k27Xdlcqrg8JWnz1sLhq07Jc9WhSqTstlzTi3ZdFfQ+Qv+HfP7BH/AEZD +yF/4jV8Gf8A5i6P+HfP7BH/AEZD+yF/4jV8Gf8A5i6+vaK2/tfNv+hnmP8A4W4n/wCW+S+4z/s7 L/8AoAwX/hLQ/wDlfkvuPkL/AId8/sEf9GQ/shf+I1fBn/5i6P8Ah3z+wR/0ZD+yF/4jV8Gf/mLr 69oo/tfNv+hnmP8A4W4n/wCW+S+4P7Oy/wD6AMF/4S0P/lfkvuPkL/h3z+wR/wBGQ/shf+I1fBn/ AOYuj/h3z+wR/wBGQ/shf+I1fBn/AOYuvr2ij+182/6GeY/+FuJ/+W+S+4P7Oy//AKAMF/4S0P8A 5X5L7j5C/wCHfP7BH/RkP7IX/iNXwZ/+Yuux8A/sefskfCnxXpnjz4Xfstfs5/Dbxxogvl0bxn4B +CPwz8H+K9IXU9Pu9I1JdM8ReHvDGnavYDUNKv77TL4Wl5ELvT7y7srjzLa4mif6MoqJ5pmdSEqd TMcdOnOMoThPF4iUJwkuWUJRlUcZRlHSUWmmtGrFRwGBhKM4YLCQnBqUZRw1GMoyi04yjJQTi00m mmmmk1sfLfiL9hv9inxh4g1vxZ4t/Y+/Zb8UeKfE2rajr/iTxL4i/Z++E2t+IPEGu6vdzX+ra1re s6n4SutR1bVtUvrie91HUr+5uLy9u5prm5mlmkd2xv8Ah3z+wR/0ZD+yF/4jV8Gf/mLr69oqo5tm kUoxzLMIxikoxjjMQlFJJJJKpZJJJJLRJK2wnl+Ak3KWBwbk2228NRbbbu224Xbb1betz5C/4d8/ sEf9GQ/shf8AiNXwZ/8AmLo/4d8/sEf9GQ/shf8AiNXwZ/8AmLr69op/2vm3/QzzH/wtxP8A8t8l 9wv7Oy//AKAMF/4S0P8A5X5L7j5C/wCHfP7BH/RkP7IX/iNXwZ/+Yuj/AId8/sEf9GQ/shf+I1fB n/5i6+vaKP7Xzb/oZ5j/AOFuJ/8AlvkvuD+zsv8A+gDBf+EtD/5X5L7j5C/4d8/sEf8ARkP7IX/i NXwZ/wDmLo/4d8/sEf8ARkP7IX/iNXwZ/wDmLr69oo/tfNv+hnmP/hbif/lvkvuD+zsv/wCgDBf+ EtD/AOV+S+4+Qv8Ah3z+wR/0ZD+yF/4jV8Gf/mLr6n0DQNC8KaFovhfwvouk+G/DPhvSdN0Dw74d 0DTbPR9C0DQtHs4dO0jRdF0jTobbT9K0nStPtrex03TbG3gs7GzghtbWGKCJEXWornr43GYpRjic XicRGDbhGvXq1lFtWbiqk5KLa0bVnbQ2o4XDYdt0MPQoOSSk6NGnTcktk3CMW0uiYUUUVzG4UUUU AFFFFABRRRQAUUUUAFFFFAH55f8ABU3/AJMw8Vf9lt/Y4/8AWzPgBX5GV+xH/BTXw/4l8Tfsc+Nd P8JeFPF3jbWbP4ofsu+JW8OeBPCniLxz4ru9F8HftU/BXxd4nvNJ8J+EtM1nxJrZ0Xwzoer63eWu j6VfXi6fp13Olu6wtj8Wv7R8Xf8ARA/2vf8AxCn9rr/5ydfsnAVSC4fqRc4KSznGycXJKSjLBZUo yave0nGSTtZuLS1TPzHjCE3nNOShJxeWYVJqLabWLzC6TStdc0brdcyvujdorC/tHxd/0QP9r3/x Cn9rr/5ydH9o+Lv+iB/te/8AiFP7XX/zk6+y9pD+eH/gS/z81958v7Of8k//AAF/5ea+83aKwv7R 8Xf9ED/a9/8AEKf2uv8A5ydH9o+Lv+iB/te/+IU/tdf/ADk6PaQ/nh/4Ev8APzX3h7Of8k//AAF/ 5ea+83aKwv7R8Xf9ED/a9/8AEKf2uv8A5ydH9o+Lv+iB/te/+IU/tdf/ADk6PaQ/nh/4Ev8APzX3 h7Of8k//AAF/5ea+83a7P4D/APJ5/wCxB/2W34nf+sZ/tU15f/aPi7/ogf7Xv/iFP7XX/wA5OvV/ 2aNH8eeIv2xv2RNQh+C37RmgaN4O+KHxJ8S+KfEfj79mn4//AAy8KaBotz+yt+0T4RtLzU/FnxF+ G3hbw3am98TeKvD2iWNrJqovL3UNWtYLS3mZn2cWZ1KayrOL1IK+TZvFXnFXlLLcVGKWurlKUYxW 7bSV20deAp1HmOWWhN2zPLZP3ZaRjjsPKTemyjq3slq9D+kaiiiv52P2sKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/9k= --f46d04430452bf26f704ba402cfe-- From shollenbeck@verisign.com Fri Mar 2 04:41:29 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F73021F8B8B for ; Fri, 2 Mar 2012 04:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 TFNcXq9d4AXY for ; Fri, 2 Mar 2012 04:41:19 -0800 (PST) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id 217A921F8B99 for ; Fri, 2 Mar 2012 04:41:15 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKT1C/67Cmk0Mj7TnLB+p5ehArDXVYXVqi@postini.com; Fri, 02 Mar 2012 04:41:18 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q22CfEfJ003935; Fri, 2 Mar 2012 07:41:15 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.245]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Mar 2012 07:41:14 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Fri, 2 Mar 2012 07:41:14 -0500 From: "Hollenbeck, Scott" To: "Bhatia, Vikas" Thread-Topic: [drinks] TLS Client CertificateRequest? Thread-Index: AQHM5nH2W6gwl4O9eEqyXBtiou8dHZYzSJ7QgB6RDRCAALdsIIADPnHQgAFEkHA= Date: Fri, 2 Mar 2012 12:41:13 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D5B86F1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D595A08@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <3D35AFB9-D8E1-4AF7-B483-F6DE35FEE6F2@softarmor.com> <831693C2CDA2E849A7D7A712B24E257F0D598DB4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D5B50AB@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Mar 2012 12:41:14.0804 (UTC) FILETIME=[C17C3F40:01CCF871] Cc: "drinks@ietf.org" Subject: Re: [drinks] TLS Client CertificateRequest? X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 12:41:29 -0000 > -----Original Message----- > From: Bhatia, Vikas [mailto:vbhatia@tnsi.com] > Sent: Thursday, March 01, 2012 5:58 PM > To: Hollenbeck, Scott > Cc: drinks@ietf.org > Subject: RE: [drinks] TLS Client CertificateRequest? >=20 > Thanks Scott, The text looks good imo. I just have couple minor > comments: >=20 >=20 > > The TLS handshake protocol requires certificate-based server > > authentication for all key exchange methods defined in RFC 5246 > except > > DH_anon. >=20 > I would suggest to not have the above line in the text. The reason is > that this is well-established in RFC 5246 and would be redundant here. I included it because I thought the context would be helpful, but I'm Ok wi= th striking it. > > increased if the server supports client-initiated renegotiation. This > > risk can be mitigated by disabling client-initiated renegotiation on > the > > server and by ensuring that other means (such as firewall access > control > > lists) are used to restrict unauthenticated client access to servers. >=20 > I am not sure if it is a requirement for all TLS servers to provide > ability to turn off client initiated renegotiation, so I will just do a > little modification as follows: >=20 > "This risk can be mitigated by disabling client-initiated renegotiation > on the > server and/or by ensuring that other means (such as firewall access > control > lists) are used to restrict unauthenticated client access to servers." I'm less comfortable with this change. Renegotiation is optional, but if it= 's supported your "and/or" change (the "or" part in particular) suggests th= at there may be no risk in leaving it enabled. That's not the case. A clien= t that can renegotiate at will presents a denial of service risk. Scott From kcartwright@tnsi.com Fri Mar 2 07:31:54 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0327A21F8671 for ; Fri, 2 Mar 2012 07:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 ZTiDEPlyX2FJ for ; Fri, 2 Mar 2012 07:31:47 -0800 (PST) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0262821F866C for ; Fri, 2 Mar 2012 07:31:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAGHnUE+sEQfn/2dsb2JhbABDgkWyeoF9AQEFGhNFFwIBCBEEAQEhAQYHMhQJCAEBBAESCBPCV4oNhHRjBIhQoAGBPg X-IronPort-AV: E=Sophos;i="4.73,518,1325462400"; d="scan'208,217";a="957146" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 02 Mar 2012 15:31:44 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 2 Mar 2012 10:31:44 -0500 From: "Cartwright, Ken" To: Mickael Marrache , "drinks@ietf.org" Date: Fri, 2 Mar 2012 10:31:41 -0500 Thread-Topic: [drinks] SPPF changes proposal Thread-Index: Acz4YK3imiZPYiFHR8KA9dCeS3rehgAI/HBA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B4254E341B54864B92D28BC2138A9DC3031432EAB2TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] SPPF changes proposal X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:31:54 -0000 --_000_B4254E341B54864B92D28BC2138A9DC3031432EAB2TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mickael, There are misunderstandings about the data model and about the resolution p= rocess. "To meet the requirements deduced from the user ENUM use case, a direct ass= ociation between the TN and route record types has been added" KJC: Nothing has been "added", the data model has been this way for at lea= st two years now. "So, one solution is to include these route records in a dummy (since the i= ncluded route records have not common routes) destination group DG-1. Then,= we also create a dummy (since it doesn't contain any route) route group RG= -1 and associate it to DG-1. Then, the route group may be offered to a peer= ing organization." KJC: The Destination Group and the Route Group you refer to as "Dummys", ar= e not "Dummys" they are an integral and expected part of the data structure= . "First, since the destination group DG-1 and the route group RG-1 are not u= sed for their primary reason (a destination group allows grouping of public= identifiers that share a common set of routes, and a route group is genera= lly used to group route records that may correspond to a same "destination"= - that's why we share them as a block), it reveals a potential design issu= e." KJC: The Route Group you refer to as "not contain any route rec" is not ac= curate. It may or may not contain Route Recs. It is up to the registrant = and registrar to decide whether they wish to have route recs on a given rou= te group, regardless of whether they have also decided to have Route Recs d= irectly associated with a PI (i.e. in the user ENUM case, where some PIs wi= ll/may have Route Recs that contain info that is specific to that PI). The= model allows both, depending on the Registrar's Registrant's need. KJC: The Destination Group and Route Groups involved here _do_ in fact ser= ve the purpose that they are designed to serve. They allow the peering vis= ibility of large numbers of public identities and their routing information= to be controlled at an aggregate with just a few number of API calls, as a= pposed to millions (one per PI or Route Rec). They allow the Destination G= roup to be associated or disassociated to from one or more Route Group obje= cts in a single command as the need arises, they allow the Route Group to b= e offered/accepted in a single command, rather than one per route rec (whic= h there would be millions of in the User ENUM case) or one per PI. They Ro= ute Group allows further control of the visibility based on source-based ro= uting, and other routing selection algorithms that, at this time, would be = vendor specific since they are not in the protocol (e.g. time-of-day, cost,= etc). "In this case, when an originating SSP wants to know the routes records ass= ociated to TN 1 for example...." KJC: The second paragraph in your note attempts to describe part of the re= solution process, I've included the first part of your statement above. It= basically says that the resolution process is somehow different if Route R= ecs are directly associated with the PI than if they are associated with th= e Route Group. This is not accurate. First off, SPPP does not attempt to = define how resolution servers must evaluate the data that SPP provisions. = Doing so would be folly, since TN resolution logic is much too involved, an= d often situation specific, including looking at data sources that do not e= ven come in over SPPP (e.g. portability data, etc, etc). However, the basi= c logic involves (1) using the lookup key (e.g. a TN) and the source of the= query to get the Destination Groups that contain that lookup key that are = visible to that source based on the Route Groups that that source has accep= ted (or auto-accepted), (2) collecting the Route Recs that are on the Route= Group(s) if any and/or the PI if any, (3) evaluating the Route Recs based = on their priority (and other vendor specific resolution logic, which the pr= otocol does not attempt to specify), then sending the collected Route Recs = out in the resolution response. Notice that there are not two different fl= ows. KJC: But from a bigger picture perspective, when the proposal was brought = up yesterday, it was brought up under the guise that "the current data mode= l is broken and it a hack in this area, so we need to do X, Y and Z". This= is simply not accurate, as I've described above. Secondly, the proposed a= lternative simply does not work in terms of scalability for the User ENUM u= se case. The proposal would result in millions of Route Recs (since in the= user enum case the Route Recs contain PI specific data) having to be offer= ed and accepted. So even the primary target use case of the proposal just = does not work well. So given that the current model is not "broken" and is= not a "hack" and given that the new proposal does not scale for the user e= num use case, why add in the additional complexity that results from the ne= w proposal? Ken ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Mickael Marrache Sent: Friday, March 02, 2012 5:38 AM To: drinks@ietf.org Subject: [drinks] SPPF changes proposal Hi DRINKS, Following the conversation we had today, I would like to speak about the is= sue raised by David concerning the data model. Please, let's take a look at the figure present in the joined SPPF-user ENU= M.jpg file. To meet the requirements deduced from the user ENUM use case, a direct asso= ciation between the TN and route record types has been added. In this case,= we have each TN associated to a route record directly. But, since peering = is defined at the route group level, there is no easy possibility to share = these direct associations. So, one solution is to include these route recor= ds in a dummy (since the included route records have not common routes) des= tination group DG-1. Then, we also create a dummy (since it doesn't contain= any route) route group RG-1 and associate it to DG-1. Then, the route grou= p may be offered to a peering organization. The aforementioned solution disturbs me in two points. First, since the des= tination group DG-1 and the route group RG-1 are not used for their primary= reason (a destination group allows grouping of public identifiers that sha= re a common set of routes, and a route group is generally used to group rou= te records that may correspond to a same "destination" - that's why we shar= e them as a block), it reveals a potential design issue. That's what I have= qualified them as dummy before. That's the first impression I had when I h= eard this solution. The second point I want to raise concerns the complexit= y added by this solution. In this case, when an originating SSP wants to kn= ow the routes records associated to TN 1 for example, we directly see that = there is a route record associated to it (RR 1). But, we don't know if this= route record is accessible by the originating SSP. So, we need to get the = enclosing destination group DG-1 and then the route group RG-1. We then che= ck in its list of peering organizations if the originating SSP exists. Then= , the route record RR 1 (obtained from the telephone number) is returned if= the SSP is authorized. You will note that this processing is not the regul= ar one described by SPPF. In general, we get the destination group associat= ed to the queried public identifier, then the route group, and then the ass= ociated route records if authorized. Why do we need to use a different proc= essing for the same kind of problem? After all, we just want to get the rou= te records associated to the telephone number TN-1 in a user ENUM scenario = (it's a banal scenario among many of them), as we want to get the route rec= ords associated to another public identifier in a regular scenario. That's = what we have here: two symptoms that reveal a design issue. Now, let's take a look at the UML class diagram present in the joined Propo= sedModel-SPPF.jpg file. By using the abstraction defined by the abstract types PubIdentElement and = RouteElement, it allows defining a many to many relationship between public= identifier elements (i.e. single PI or destination group) and route elemen= ts (i.e. single route record or route group). This relationship is represen= ted by the class-association RoutingAssoc. This association links zero or m= ore public identifier elements to zero or more route elements. Also, to sol= ve the scalability issue raised by Ken in the case one registrant organizat= ion has to offer a huge number of associations (previously route groups), w= e may use the same grouping concept for routing associations, represented b= y the AssocGroup type. Thus, we define a ShareableElement type that represe= nts the basic entity that may be shared by a registrant organization. This model gives the possibility to define 4 combinations of associations: * Public identifier - Route record (solving user ENUM issue plus the pos= sibility to link a single RN/TNP/TNR to a route record) * Public identifier - Route group (same as previous but with more than o= ne route record) * Destination group - Route record * Destination group - Route group (regular scenario) I don't think it's a big amount of change. The point here is to introduce a= n abstraction, and to use an intermediary type between the public identifie= r element and the route element. This intermediary type should be used for = peering. After all, the valuable information that is shared is an associati= on between public identifiers and routes, thus using a dedicated type for t= his association should be the solution. Also, I still think the peering aspect of this protocol should be defined i= n a separated protocol that would support much more use cases than a simple= offer/accept model. I think we should have two standards, each one focusin= g on a specific aspect of the problem, so we can decouple the two problems.= Then, the users would have the choice to use the routing provisioning prot= ocol or the peering protocol or both. Maybe I'm missing something here, so if you see any issue (e.g. concerning = scalability) caused by this data model, please let me know. I would be happ= y to hear your comments on these propositions. Thanks Mickael ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_B4254E341B54864B92D28BC2138A9DC3031432EAB2TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mickael,

 

There are misunderstandings about the = data model and about the resolution process.  

 

“To meet the requi= rements deduced from the user ENUM use case, a direct association between t= he TN and route record types has been added”

KJC:  Nothing has been “add= ed”, the data model has been this way for at least two years now.

 

“So, one solution = is to include these route records in a dummy (since the included route reco= rds have not common routes) destination group DG-1. Then, we also create a dummy (since it doesn't con= tain any route) route group RG-1 and associate it to DG-1. Then, the route = group may be offered to a peering organization.”

 

KJC: The Destination Group and the Rou= te Group you refer to as “Dummys”, are not “Dummys”= they are an integral and expected part of the data structure.

 

“First, since the destination group DG-1 and the route group = RG-1 are not used for their primary reason (a destination group allows grou= ping of public identifiers that share a common set of routes, and a route group is generally used to group= route records that may correspond to a same "destination" - that= 's why we share them as a block), it reveals a potential design issue.̶= 1;

 

KJC:  The Route Group you refer t= o as “not contain any route rec” is not accurate.  It may = or may not contain Route Recs.  It is up to the registrant and registrar to decide whether they wish to have route rec= s on a given route group, regardless of whether they have also decided to h= ave Route Recs directly associated with a PI (i.e. in the user ENUM case, w= here some PIs will/may have Route Recs that contain info that is specific to that PI).  The model allow= s both, depending on the Registrar’s Registrant’s need.

 

KJC:  The Destination Group and R= oute Groups involved here _do_ in fact serve the purpose that they are designed to serve.  They allow the peering visibility o= f large numbers of public identities and their routing information to be co= ntrolled at an aggregate with just a few number of API calls, as apposed to= millions (one per PI or Route Rec).  They allow the Destination Group to be associated or disassociated t= o from one or more Route Group objects in a single command as the need aris= es, they allow the Route Group to be offered/accepted in a single command, = rather than one per route rec (which there would be millions of in the User ENUM case) or one per PI.  The= y Route Group allows further control of the visibility based on source-base= d routing, and other routing selection algorithms that, at this time, would= be vendor specific since they are not in the protocol (e.g. time-of-day, cost, etc).

 

“In this case, whe= n an originating SSP wants to know the routes records associated to TN 1 fo= r example….”

 

KJC:  The second paragraph in you= r note attempts to describe part of the resolution process, I’ve incl= uded the first part of your statement above.  It basically says that the resolution process is somehow diff= erent if Route Recs are directly associated with the PI than if they are as= sociated with the Route Group.  This is not accurate.  First off,= SPPP does not attempt to define how resolution servers must evaluate the data that SPP provisions.  Doing so would b= e folly, since TN resolution logic is much too involved, and often situatio= n specific, including looking at data sources that do not even come in over= SPPP (e.g. portability data, etc, etc).  However, the basic logic involves (1) using the lookup key (e.g. a TN) and= the source of the query to get the Destination Groups that contain that lo= okup key that are visible to that source based on the Route Groups that tha= t source has accepted (or auto-accepted), (2) collecting the Route Recs that are on the Route Group(s) if any and/or= the PI if any, (3) evaluating the Route Recs based on their priority (and = other vendor specific resolution logic, which the protocol does not attempt= to specify), then sending the collected Route Recs out in the resolution response.  Notice that there are not= two different flows.

 

 

KJC:  But from a bigger picture p= erspective, when the proposal was brought up yesterday, it was brought up u= nder the guise that “the current data model is broken and it a hack in this area, so we need to do = X, Y and Z”.  This is simply not accurate, as I’ve describ= ed above.  Secondly, the proposed alternative simply does not work in = terms of scalability for the User ENUM use case.  The proposal would result in millions of Route Recs (since in the user enum ca= se the Route Recs contain PI specific data) having to be offered and accept= ed.  So even the primary target use case of the proposal just does not= work well.  So given that the current model is not “broken” and is not a “hack” and give= n that the new proposal does not scale for the user enum use case, why add = in the additional complexity that results from the new proposal?=

 

Ken

 

From: drin= ks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Mickael Marrach= e
Sent: Friday, March 02, 2012= 5:38 AM
To: drinks@ietf.org
Subject: [drinks] SPPF chang= es proposal

 

Hi DRINKS,

Following the conversation we had today, I would like to speak about the is= sue raised by David concerning the data model.

Please, let's take a look at the figure present in the joined SPPF-user ENU= M.jpg file.

To meet the requirements deduced from the user ENUM use case, a direct asso= ciation between the TN and route record types has been added. In this case,= we have each TN associated to a route record directly. But, since peering = is defined at the route group level, there is no easy possibility to share these direct associations. So, one s= olution is to include these route records in a dummy (since the included ro= ute records have not common routes) destination group DG-1. Then, we also c= reate a dummy (since it doesn't contain any route) route group RG-1 and associate it to DG-1. Then, the ro= ute group may be offered to a peering organization.

The aforementioned solution disturbs me in two points. First, since the des= tination group DG-1 and the route group RG-1 are not used for their primary= reason (a destination group allows grouping of public identifiers that sha= re a common set of routes, and a route group is generally used to group route records that may correspond t= o a same "destination" - that's why we share them as a block), it= reveals a potential design issue. That's what I have qualified them as dum= my before. That's the first impression I had when I heard this solution. The second point I want to raise concerns the = complexity added by this solution. In this case, when an originating SSP wa= nts to know the routes records associated to TN 1 for example, we directly = see that there is a route record associated to it (RR 1). But, we don't know if this route record is access= ible by the originating SSP. So, we need to get the enclosing destination g= roup DG-1 and then the route group RG-1. We then check in its list of peeri= ng organizations if the originating SSP exists. Then, the route record RR 1 (obtained from the telephone numbe= r) is returned if the SSP is authorized. You will note that this processing= is not the regular one described by SPPF. In general, we get the destinati= on group associated to the queried public identifier, then the route group, and then the associated route rec= ords if authorized. Why do we need to use a different processing for the sa= me kind of problem? After all, we just want to get the route records associ= ated to the telephone number TN-1 in a user ENUM scenario (it's a banal scenario among many of them), as we = want to get the route records associated to another public identifier in a = regular scenario. That's what we have here: two symptoms that reveal a desi= gn issue.

Now, let's take a look at the UML class diagram present in the joined Propo= sedModel-SPPF.jpg file.

By using the abstraction defined by the abstract types PubIdentElement and = RouteElement, it allows defining a many to many relationship between public= identifier elements (i.e. single PI or destination group) and route elemen= ts (i.e. single route record or route group). This relationship is represented by the class-association Ro= utingAssoc. This association links zero or more public identifier elements = to zero or more route elements. Also, to solve the scalability issue raised= by Ken in the case one registrant organization has to offer a huge number of associations (previously route = groups), we may use the same grouping concept for routing associations, rep= resented by the AssocGroup type. Thus, we define a ShareableElement type th= at represents the basic entity that may be shared by a registrant organization.

This model gives the possibility to define 4 combinations of associations:<= o:p>

  • = Public identifier - Route record (solving user ENUM issue plus the possibil= ity to link a single RN/TNP/TNR to a route record)
  • = Public identifier - Route group (same as previous but with more than one ro= ute record)
  • = Destination group - Route record
  • = Destination group - Route group (regular scenario)

I don't think it's a big amount of change. The point here is to introduc= e an abstraction, and to use an intermediary type between the public identi= fier element and the route element. This intermediary type should be used for peering. After all, the valuable info= rmation that is shared is an association between public identifiers and rou= tes, thus using a dedicated type for this association should be the solutio= n.

Also, I still think the peering aspect of this protocol should be define= d in a separated protocol that would support much more use cases than a sim= ple offer/accept model. I think we should have two standards, each one focusing on a specific aspect of the problem,= so we can decouple the two problems. Then, the users would have the choice= to use the routing provisioning protocol or the peering protocol or both.<= o:p>

Maybe I'm missing something here, so if you see any issue (e.g. concerni= ng scalability) caused by this data model, please let me know. I would be h= appy to hear your comments on these propositions.<= /p>

Thanks

Mickael


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_B4254E341B54864B92D28BC2138A9DC3031432EAB2TNSMAILNAwin2_-- From mickaelmarrache@gmail.com Sat Mar 3 09:55:04 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEED21F867B for ; Sat, 3 Mar 2012 09:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 tU-9+DAF5zCT for ; Sat, 3 Mar 2012 09:55:02 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23D0921F8673 for ; Sat, 3 Mar 2012 09:55:01 -0800 (PST) Received: by wicr5 with SMTP id r5so835442wic.31 for ; Sat, 03 Mar 2012 09:55:01 -0800 (PST) Received-SPF: pass (google.com: domain of mickaelmarrache@gmail.com designates 10.216.134.200 as permitted sender) client-ip=10.216.134.200; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mickaelmarrache@gmail.com designates 10.216.134.200 as permitted sender) smtp.mail=mickaelmarrache@gmail.com; dkim=pass header.i=mickaelmarrache@gmail.com Received: from mr.google.com ([10.216.134.200]) by 10.216.134.200 with SMTP id s50mr1396357wei.116.1330797301177 (num_hops = 1); Sat, 03 Mar 2012 09:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gjjjzfXu2dXTuM+YTwpitpDYn0HdnPCw8nZkhHIO9Zo=; b=NSTNDRZanWWXFWGOj1lM/tLW5/6qttKfoxTIksLmuJ3sNhZlGd0YLUn4dhKqspWGc9 rg8wZNzhNGZ8yHi1Op3DQrKywiuG/c0ORPSofs/GPi7n8pJeJjod6MAG1U7rNZhqQbPW 6GIqIXUzW66MfzGbiT32xNeLxCNyjSxMZlk2zrZeMncBcaM79DE7orbmFe7kECs24kYh zVTc9BG3kS09qZlFeb9fb1db1rsPPMkLHifNCnODhrGXo+16R1tKB2RoPHsermGtKsbG 3q3mdyOocq+QJf7idUPT1W89U2Nh8GfNZr/5UiIhOwuMxsxnME0UwrH9QiL1cHoGYX0u t0cQ== MIME-Version: 1.0 Received: by 10.216.134.200 with SMTP id s50mr1142428wei.116.1330797301064; Sat, 03 Mar 2012 09:55:01 -0800 (PST) Received: by 10.216.46.209 with HTTP; Sat, 3 Mar 2012 09:55:00 -0800 (PST) In-Reply-To: References: Date: Sat, 3 Mar 2012 19:55:00 +0200 Message-ID: From: Mickael Marrache To: "Cartwright, Ken" , drinks@ietf.org Content-Type: multipart/alternative; boundary=0016e6dee8e665e52204ba5a6466 Subject: Re: [drinks] SPPF changes proposal X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 17:55:04 -0000 --0016e6dee8e665e52204ba5a6466 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ken, =93To meet the requirements deduced from the user ENUM use case, a direct > association between the TN and route record types has been added=94 > > KJC: Nothing has been =93added=94, the data model has been this way for = at > least two years now. > You're right. Sorry for saying something I didn't check. > =93So, one solution is to include these route records in a dummy (since t= he > included route records have not common routes) destination group DG-1. > Then, we also create a dummy (since it doesn't contain any route) route > group RG-1 and associate it to DG-1. Then, the route group may be offered > to a peering organization.=94 > > > > KJC: The Destination Group and the Route Group you refer to as =93Dummys= =94, > are not =93Dummys=94 they are an integral and expected part of the data > structure. > > > > =93First, since the destination group DG-1 and the route group RG-1 are n= ot > used for their primary reason (a destination group allows grouping of > public identifiers that share a common set of routes, and a route group i= s > generally used to group route records that may correspond to a same > "destination" - that's why we share them as a block), it reveals a > potential design issue.=94 > > > > KJC: The Route Group you refer to as =93not contain any route rec=94 is = not > accurate. It may or may not contain Route Recs. It is up to the > registrant and registrar to decide whether they wish to have route recs o= n > a given route group, regardless of whether they have also decided to have > Route Recs directly associated with a PI (i.e. in the user ENUM case, whe= re > some PIs will/may have Route Recs that contain info that is specific to > that PI). The model allows both, depending on the Registrar=92s Registra= nt=92s > need. > So, the route group may or may not contain route records. If it doesn't contain route records, I understand that it is only used to share the route records directly associated to the PIs. In this case, do you agree that it is not a *real *route group (i.e. a construct that allows regrouping route records that correspond to a same destination)? If it does contain route records, I understand that it plays two roles: it allows sharing the route records directly associated to the PIs as previously, and it allows sharing the route records that correspond to a same destination. KJC: The Destination Group and Route Groups involved here _*do*_ in fact > serve the purpose that they are designed to serve. They allow the peerin= g > visibility of large numbers of public identities and their routing > information to be controlled at an aggregate with just a few number of AP= I > calls, as apposed to millions (one per PI or Route Rec). They allow the > Destination Group to be associated or disassociated to from one or more > Route Group objects in a single command as the need arises, they allow th= e > Route Group to be offered/accepted in a single command, rather than one p= er > route rec (which there would be millions of in the User ENUM case) or one > per PI. They Route Group allows further control of the visibility based = on > source-based routing, and other routing selection algorithms that, at thi= s > time, would be vendor specific since they are not in the protocol (e.g. > time-of-day, cost, etc). > In the proposed model, this property is still true. It also allows the peering visibility of a large number of public identifiers and their routing information also using an aggregate (you will note that we didn't remove the destination and route groups constructs) with a few number of API calls. And I disagree when you say that the proposed model requires offering to be done per route in the user ENUM case. When a huge number of PIs are associated to route records directly (though a RoutingAssoc element), you are not forced to offer each one of these associations, you simply need to regroup them in an association group and to share this association group, I don't see here any scalability issue. Also, source based routing is also present in the proposed data model, in the ShareableElement type. =93In this case, when an originating SSP wants to know the routes records > associated to TN 1 for example=85.=94 > > > > KJC: The second paragraph in your note attempts to describe part of the > resolution process, I=92ve included the first part of your statement abov= e. > It basically says that the resolution process is somehow different if Rou= te > Recs are directly associated with the PI than if they are associated with > the Route Group. This is not accurate. First off, SPPP does not attempt > to define how resolution servers must evaluate the data that SPP > provisions. Doing so would be folly, since TN resolution logic is much t= oo > involved, and often situation specific, including looking at data sources > that do not even come in over SPPP (e.g. portability data, etc, etc). > However, the basic logic involves (1) using the lookup key (e.g. a TN) an= d > the source of the query to get the Destination Groups that contain that > lookup key that are visible to that source based on the Route Groups that > that source has accepted (or auto-accepted), (2) collecting the Route Rec= s > that are on the Route Group(s) if any and/or the PI if any, (3) evaluatin= g > the Route Recs based on their priority (and other vendor specific > resolution logic, which the protocol does not attempt to specify), then > sending the collected Route Recs out in the resolution response. Notice > that there are not two different flows. > My comment for this point is related to the fact that a route group plays the two roles mentioned previously. Playing what I call the basic role (regrouping route records corresponding to the same destination) and the disturbing role (allowing offer for route records directly associated to PIs) is simply not intuitive. And, that's why David qualified this role as a hack. It's not a derision for the current model, it is simply the fact that there is something that is at the wrong place. Also, I didn't get an answer concerning the possibility to associate a single TNR, TNP or RN directly to one or more route records. Would we add also a direct association from RN, TNR or TNP to route record? KJC: But from a bigger picture perspective, when the proposal was brought > up yesterday, it was brought up under the guise that =93the current data > model is broken and it a hack in this area, so we need to do X, Y and Z= =94. > This is simply not accurate, as I=92ve described above. Secondly, the > proposed alternative simply does not work in terms of scalability for the > User ENUM use case. The proposal would result in millions of Route Recs > (since in the user enum case the Route Recs contain PI specific data) > having to be offered and accepted. So even the primary target use case o= f > the proposal just does not work well. So given that the current model is > not =93broken=94 and is not a =93hack=94 and given that the new proposal = does not > scale for the user enum use case, why add in the additional complexity th= at > results from the new proposal? > At this point, I still don't understand why the proposed model is not accurate. I don't understand why millions of route records have to been offered and accepted? I think grouping associations solves this problem. Please, can you illustrate by a scenario or diagram (especially for the User ENUM use case)? I just want to precise that my comments are not intended to create conflicts in any manner especially when I see that it's late to raise such propositions and that the draft will become soon a RFC. I'm just trying to add my efforts to this framework/protocol. Thanks Mickael --0016e6dee8e665e52204ba5a6466 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable --0016e6dee8e665e52204ba5a6466-- From alexander.mayrhofer@nic.at Tue Mar 6 07:36:20 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A526221F8975 for ; Tue, 6 Mar 2012 07:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.064 X-Spam-Level: X-Spam-Status: No, score=-9.064 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 hv9Cj5rKPycM for ; Tue, 6 Mar 2012 07:36:19 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2E221F87A0 for ; Tue, 6 Mar 2012 07:36:18 -0800 (PST) Received: from nics-mail.sbg.nic.at ([10.17.175.2]) by mail.sbg.nic.at with XWall v3.47 ; Tue, 6 Mar 2012 16:36:17 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CCFBAE.DE59268B" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 6 Mar 2012 16:36:13 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B722472@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRINKS design team minutes (DRAFT) from 2012-02-29 Thread-Index: Acz7rrnIJYePKWvMSZ+ryWJWJKIskQ== From: "Alexander Mayrhofer" To: X-XWALL-BCKS: auto Subject: [drinks] DRINKS design team minutes (DRAFT) from 2012-02-29 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 15:36:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFBAE.DE59268B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please finde attached the draft minutes from the design team call from Feb 29. Sorry for the very late posting of the minutes. Alex ------_=_NextPart_001_01CCFBAE.DE59268B Content-Type: text/plain; name="drinks-call-2012-02-29.txt" Content-Transfer-Encoding: base64 Content-Description: drinks-call-2012-02-29.txt Content-Disposition: attachment; filename="drinks-call-2012-02-29.txt" RFJJTktTIERlc2lnbiBUZWFtIG1lZXRpbmcNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN CjIwMTItMDItMjkNCg0KUGFydGljaXBhbnRzDQotLS0tLS0tLS0tLS0NCg0KIC0gZGVhbg0KIC0g YWxleA0KIC0gc3VtYW50aA0KIC0gbWFuanVsDQogLSB2aWthcw0KIC0gamVyZW15DQogLSBEYXZp ZA0KDQpSZXZpZXcgb2YgQWN0aW9uIEl0ZW0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGUg bGlzdCBvZiBhY3Rpb24gaXRlbXMgd2FzIHJldmlld2VkIC0gbnVtYmVyaW5nIGFjY29yZGluZyB0 byB0aGUgbnVtYmVyaW5nDQpmcm9tIHRoZSBsYXN0IG1pbnV0ZXM6DQoNCkFJLTEgc3RpbGwgb3Bl bg0KQUktMiANCkFJLTMgc2VudCBvdXQgYSBwcm9wb3NhbCAtIHRoaXMgd2lsbCBiZSBkaXNjdXNz ZWQgbGF0ZXIgb24gdGhlIGNhbGwNCkFJLTQgc2VudCBwcm9wb3NhbCAtIGl0IHdhcyBxdWlja2x5 IGRpc2N1c3NlZCByaWdodCBhd2EgDQpBSS01IG9wZW4sIGJ1dCB3aWxsIGJlIGRvbmUgYnkgYSBk b2N1bWVudCBlZGl0DQpBSS02IHdpbGwgYmUgZG9uZSBpbiBhIGRvY3VtZW50IGVkaXQgLSBWaWth cyANCkFJLTcgZG9jdW1lbnQgZWRpdCwgbm8gbmVlZCB0byBkaXNjdXNzDQpBSS04IG5vIHByb2dy ZXNzIHlldA0KQUktOSByZWxhdGVkIHRvIEFJLTQsIGFzc2lnbmVkIHRvIFZpa2FzIHRvIGltcGxl bWVudA0KQUktMTAgLSBjbG9zZWQsIGNvdmVyZWQgaW4gQUktMTMNCg0KKGRpc2N1c3Npb24gYXJv dW5kIGJhdGNoaW5nIGFuZCBhdG9taWNpdHkgb2YgcmVxdWVzdHMsIHN1bWFudGggY2xhcmlmaWVz DQp0aGF0IHdlIGhhdmUgImFsbCBvciBub3RoaW5nIiBvcGVyYXRpb25zIG9ubHkpLiB3ZSBkb24n dCBjdXJyZW50bHkgaGF2ZSANCmEgcHJvcG9zYWwgb24gdGhlIHRhYmxlIGZvciBub2N0aWZpY2F0 aW9uIGV0Yy4gDQoNClRoZSBxdWVzdGlvbiBvZiAiYmF0Y2hpbmcgbGltaXRzIiB3YXMgZGlzY3Vz c2VkLA0KYW5kIHdoZXRoZXIgdGhleSBuZWVkIHRvIGJlIGNvbnZleWVkIGluIHRoZSBwcm90b2Nv bC4gDQoNClRoZXJlIHdhcyBhbiBhZ3JlZW1lbnQgdG8gbm90IGRvICJwZW5kaW5nIiByZXF1ZXN0 cyBhbmQgDQpoZW5jZSBhbHNvIG5vIG5vdGlmaWNhdGlvbnMuDQoNCkFJLTExIGluIHByb2dyZXNz IC0gVExTIG5lZ290aWF0aW9uIGRpc2N1c3Npb24sIERvUyBvcHBvcnR1bml0eS0gIGRpc2N1c3Np b24gd2hldGhlciBvciBub3QgdG8gYWRkIFNjb3R0J3MgcHJvcG9zYWwgdG8gdGhlIG5leHQgcmV2 aXNpb24uIE9ubHkgdG8gDQpyZXF1aXJlIGNlcnRpZmljYXRlcyB3aGVuIHRoZSBvcGVyYXRpb24g dGFrZXMgcGxhY2Ugb3ZlciB0aGUgcHVibGljIGludGVybmV0Pw0KU2NvdHQgZG9lc24ndCByZXF1 ZXN0IHRoYXQgY2xpZW50IGNlcnRzIGFyZSByZXF1aXJlZCwgYnV0IHRoZSByaXNrIA0Kc2hvdWxk IGJlIG5vdGVkIGluIHRoZSBkb2MuIE5lZWQgdG8gZGlzY3VzcyBTY290dCdzIHByb3Bvc2FsIGZ1 cnRoZXINCg0KQUktMTIgZ2V0IGFuIGV4cGVydCByZXZpZXcgb24gdGhlIG5leHQgcmV2aXNpb24N CkFJLTEzYSBpcyBpbiB0aGUgcmVzcG9uc2UsIHJldHVybiBhbiBlcnJvciB3aXRoIHRoZSBtYXhp bXVtLiANCkFJLTEzYiBXZSBuZWVkIGFsc28gdG8gYWRkcmVzcyB0aGUgInJpc2siIG9mIERvUyBp biB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuIChKZXJlbXkpDQoNClNPQVAgZG9jdW1lbnQN Ci0tLS0tLS0tLS0tLS0NCg0KQUktMTNjIHB1cmVseSBlZGl0b3JpYWwgdGhpbmcNCkFJLTE0IGVk aXRvcmlhbCB0aGluZw0KQUktMTUgZWRpdG9yaWFsIHRoaW5nDQpBSS0xNiAtIGRpc2N1c3Npb24g Zm9sbG93czoNCg0KRGF2aWQgbm90ZXMgdGhhdCBwZWVyaW5nIHdvdWxkIGJlIGEgZnVuY3Rpb24g b2YgdGhlIGxvb2t1cCBwcm90b2NvbCwgYW5kIG5vdCB0aGUgcHJvdmlzaW9uaW5nIHByb3RvY29s LiBNYW5qdWwgYW5kIEFsZXggZGlzYWdyZWUuIERhdmlkIG5vdGVzIHRoYXQgaGUgDQpoYXMgZm91 bmQgbG90cyBvZiB1c2UgY2FzZXMgdGhhdCBkaWRuJ3Qgd29yayB3aXRoIHRoZSBleGlzdGluZyBv ZmZlciAvIGFjY2VwdCBwcm90b2NvbC4gDQoNClN1bWFudGggZGVzY3JpYmVkIHRoZSBvcHRpb25z IHRha2VuIGxhc3QgdGltZSwgYW5kIHRoYXQgdGhlIHRlYW0gYWdyZWVkIHRvIGtlZXAgdGhlIGN1 cnJlbnQgbWVjaGFuaXNtLiANCg0KRGF2aWQgYXNrcyB3aGV0aGVyIGFueWJvZHkgaXMgdXNpbmcg dGhlIHBlZXJpbmcgdXNlIGNhc2UgYXMgaXQgc3RhbmRzLCBhbmQgbWFuanVsIG1lbnRpb25zIHRo YXQgdGhleSBhcmUgdXNpbmcgaXQgYXMgaXQgc3RhbmRzLg0KDQpEZWFuIG1lbnRpb25zIHRoZSBh Y3RvcnMgYXJlIGVudGlyZWx5IGRpZmZlcmVudCBmcm9tIGFueSBvdGhlciBvZiB0aGUgDQpvdGhl ciBwcm92aXNpb25pbmcgY2FzZXMsIHdoaWNoIG1ha2VzIHRoZSBwZWVyaW5nIGNhc2UgImxvb2sg ZGlmZmVyZW50Ig0KDQpTdW1hbnRoOiBXZSBvYnZpb3VzbHkgbmVlZCBtb3JlIGRpc2N1c3Npb25z IC0gdGFrZSB0aGlzIGJhY2sgdG8gdGhlIG1haWxpbmcgbGlzdC4NCg0KQUktMTcgLSBhbGV4IHBy b3Bvc2VkIGNoYW5nZSB0byBsaXN0DQpBSS0xOCAtIGRhdmlkIHdpbGwgYWRkcmVzcyB0aGlzIG5l eHQgd2Vlaw0KQUktMTkgLSBUaGVyZSBpcyBhbHJlYWR5IHNvbWUgdGV4dCwgdGhpcyBpcyBlZGl0 b3JpYWwuDQoNCkFsZXggbm90ZXMgdGhhdCBBSS0xNiBpcyB0aGUgcmVhbGx5IGxhcmdlc3Qgb25l LCBEYXZpZCBub3RlcyB0aGF0IEFJLTQgaXMgYWxzbyBhIGJpZyBpdGVtIHRoYXQncyBvcGVuIC0g ZGF2aWQgYWxzbyBub3RlcyB0aGF0IHRoZSB3ZSBoYXZlIG9ubHkgInNwdXJpb3VzIGF0dHJpYnV0 ZXMiIGluIHRoZSBwcm90b2NvbCBjdXJyZW50bHksIGFuZCB0aGlua3MgdGhhdCB3ZSB3b3VsZCBu ZWVkIGdlbmVyaWMgImF0dHJpYnV0ZSBkZWZpbml0aW9ucyIuIA0KDQpWaWthcyBzYXlzIHdlIHBy b2JhYmx5IG5lZWQgYSBkZWRpY2F0ZSBjYWxsIGZvciBBSS00LCBhbmQgcHJvYmFibHkgb3RoZXIg aXRlbXMgYXMgd2VsbC4gDQoNCk5leHQgY2FsbCB3aWxsIGJlIGRvbmUgdG9tb3Jyb3cuIFZpa2Fz IG5vdGVzIHRoYXQgdGhlcmUgYXJlIHByb2JhYmx5IGVub3VnaCB0aGluZ3Mgb24gdGhlIHBsYXRl IGZvciB0aGUgZG9jdW1lbnQgb24gdGhlIDEwdGguIA0KDQpTdW1hbnRoIHdpbGwgc2V0IHVwIHRo ZSBicmlkZ2UgZm9yIHRvbW9ycm93cyBjYWxsLCBBbGV4IHdpbGwgZ2V0IG91dCB0aGUgbWludXRl cyB0b2RheS4gDQoNCmNhbGwgY29uY2x1ZGVzIGF0IDU6MTIgDQoNCg0KDQoNCg0K ------_=_NextPart_001_01CCFBAE.DE59268B-- From alexander.mayrhofer@nic.at Tue Mar 6 07:54:19 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339A821F893A for ; Tue, 6 Mar 2012 07:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.083 X-Spam-Level: X-Spam-Status: No, score=-9.083 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 5uwIuuwAkPee for ; Tue, 6 Mar 2012 07:54:18 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFD321F8997 for ; Tue, 6 Mar 2012 07:54:16 -0800 (PST) Received: from nics-mail.sbg.nic.at ([10.17.175.2]) by mail.sbg.nic.at with XWall v3.47 ; Tue, 6 Mar 2012 16:54:16 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CCFBB1.61EA44E5" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 6 Mar 2012 16:54:13 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B72247B@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRAFT minutes of the DRINKS design team call on 2012-03-01 Thread-Index: Acz7sN/6DmeGGneYR3e1RNDRhqq73Q== From: "Alexander Mayrhofer" To: X-XWALL-BCKS: auto Subject: [drinks] DRAFT minutes of the DRINKS design team call on 2012-03-01 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 15:54:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFBB1.61EA44E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, please find the draft minutes from the second DRINKS design team call last week. Again, sorry for the delay in posting the minutes. If you have additional notes from the meeting, please feel free to send them to me so that i can include them. thanks, Alex ------_=_NextPart_001_01CCFBB1.61EA44E5 Content-Type: text/plain; name="drinks-call-2012-03-01.txt" Content-Transfer-Encoding: base64 Content-Description: drinks-call-2012-03-01.txt Content-Disposition: attachment; filename="drinks-call-2012-03-01.txt" RFJJTktTIERlc2lnbiBUZWFtIENhbGwNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCjIwMTIt MDMtMDENCg0KUGFydGljaXBhbnRzDQotLS0tLS0tLS0tLS0NCg0KLSBkYXZpZA0KLSBzdW1hbnRo DQotIGFsZXgNCi0gdmlrYXMNCi0ga2VuDQotIHN1bWFudGgNCg0KVGhlIGRpc2N1c3Npb24gZnJv bSB5ZXN0ZXJkYXkgd2FzIGNvbnRpbnVlZCBhcyBmb2xsb3dzOg0KDQpBSS00IC0gbG9uZyBkaXNj dXNzaW9uIGFib3V0IHJlbGF0aW9ucywgYW5kIHdoZXRoZXIgZGlyZWN0IHJ0ZSAtIHBpIHJlbGF0 aW9uIA0KYWRkcyBhbnl0aGluZy4gDQoNClF1ZXN0aW9uIG9uIHdoZXRoZXIgdGhpcyBpcyBqdXN0 IGEgcHJvYmxlbSBvZiBpbXBsZW1lbnRpbmcgdGhlIGNlcnRhaW4gdXNlIGNhc2UgdGhhdCBkYXZp ZCBwcm9wb3NlZCwgKHJlYWQ6IHdoZXRoZXIgaXQncyB1bmNsZWFyKQ0KDQpJbnRlcm5hdGlvbmFs aXphdGlvbjogQWxleCBoYXMgc2VudCBzb21lIHRleHQsIFZpa2FzIGlzIGNvbmNlcm5lZCBhYm91 dCB0aGUgTkZDIGFuZCBDaGFyYWN0ZXIgY2F0ZWdvcmllcyBkZXNjcmlwdGlvbi4gQWxleCB3aWxs IHJlLWV2YWx1YXRlIHRoZSByZXNwZWN0aXZlIA0KdGV4dC4NCg0KU3VtYW50aCBzYXlzIHRoYXQg Y29uc3RyYWluaW5nIGl0IHdvdWxkIGhlbHAgaW50ZXJvcGVyYWJpbGl0eS4NCg0KQWxleCByZW1p bmRzIHRoYXQgdGhlIE5GQyBjYW1lIGZyb20gQVBQcyBhcmVhIGRpc2N1c3Npb25zIHRoZW1zZWx2 ZXMuDQoNClRoZXJlIGlzIGRpc2N1c3Npb24gd2hldGhlciB0aGUgbGlzdCBvZiBpZGVudGlmaWVy cyB3b3VsZCBuZWVkIHRvIGJlIA0KaW5jbHVkZWQgaW4gdGhlIHJlc3BlY3RpdmUgc2VjdGlvbi4N Cg0KS2VuIG1lbnRpb25zIHRoYXQgdGhlIGxpbWl0YXRpb24gb2YgY2hhcmFjdGVyIGNsYXNzZXMg aXMgcHJvYmFibHkgbm90IA0KbmVlZGVkLCBzaW5jZSB0aGUgWE1MIHRva2VuIHR5cGUgcmVzdHJp Y3RzIHRoZSB2YWxpZCBjaGFyYWN0ZXJzIGFscmVhZHkuDQpBbGV4IHdpbGwgaW52ZXN0aWdhdGUu DQoNClRoZXJlIHdhcyBjb250aW51ZWQgZGlzY3Vzc2lvbiBhYm91dCB0aGUgb2ZmZXIvYWNjZXB0 IG1lY2hhbmlzbSwNCg0KZGF2aWQgYWdhaW4gc2F5cyB0aGF0IGl0IGRvZXNuJ3Qgc29sdmUgYWxs IHByb2JsZW1zIC0gb3RoZXJzIGFzazogZG9lcyBpdCBoYXJtPyANCg0Kc3llZCBzYXlzIHdlIGNv dWxkIGFsc28gaGF2ZSAtIGFmdGVyIGFkZGl0aW9uYWwgdXNlIGNhc2VzIC0gYSBzZWNvbmQgdmVy c2lvbiBvZiB0aGUgcHJvdG9jb2wsIG9uY2Ugd2UgZ290IHRoYXQgdmVyc2lvbiBvdXQgb2YgdGhl IGRvb3IuDQoNCkRhdmlkIGlzIG9rIHdpdGggbGVhdmluZyB0aGUgb2ZmZXIvYWNjZXB0IG1vZGVs LCBidXQgdGhpbmtzIGl0J3Mgd3JvbmcuIA0KDQpEYXZpZCBwcmVzZW50cyBoaXMga2V5L3ZhbHVl IGlkZWEgcXVpY2tseS4gQWxleCBub3RlcyB0aGF0IHRoZSBzZW1hbnRpY3MgYXJlIGltcG9zc2li bGUgdG8gZGVmaW5lIHdpdGggc3VjaCBhbiBvcGVuIG1lY2hhbmlzbS4gdmlrYXMgc2F5cyBhdCBs ZWFzdCB0aGUgDQoibGlzdCIgb2YgYXR0cmlidXRlcyBvbiBhbiBvYmplY3QgbmVlZHMgdG8gYmUg ZGVmaW5lZC4NCg0KQ2FsbCBjb25jbHVkZXMNCg0KDQo= ------_=_NextPart_001_01CCFBB1.61EA44E5-- From sumanth@cablelabs.com Tue Mar 6 13:05:57 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C267E21E801C for ; Tue, 6 Mar 2012 13:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 f-uIhjL5pB-y for ; Tue, 6 Mar 2012 13:05:57 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0043321E80BF for ; Tue, 6 Mar 2012 13:05:56 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q26L5tru013312 for ; Tue, 6 Mar 2012 14:05:55 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 06 Mar 2012 14:05:56 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 6 Mar 2012 14:05:56 -0700 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Tue, 6 Mar 2012 14:05:54 -0700 Thread-Topic: New Proposal for Telephone-Related Queries Thread-Index: Acz73NeRw0KFhqCiQC6Sc8ZMGZmuIQ== Message-ID: <76AC5FEF83F1E64491446437EA81A61F8F2BCBA51F@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] FW: New Proposal for Telephone-Related Queries X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 21:05:57 -0000 For those not subscribed to the DISPATCH mailing list... - S -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Peterson, Jon Sent: Monday, March 05, 2012 3:05 PM To: 'dispatch@ietf.org' Subject: Re: [dispatch] New Proposal for Telephone-Related Queries Oops, sorry, my mailer did not like the URL I submitted. The correct URL fo= r the draft is: https://datatracker.ietf.org/doc/draft-peterson-terq/ -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time To: dispatch@ietf.org Subject: [dispatch] New Proposal for Telephone-Related Queries I have a proposal to bounce off the group. Basically, this is a re-examinat= ion of some of the problems we've previously considered in the telephony-sp= ecific cluster of work surrounding ENUM, DRINKS and SPEERMINT. Through disc= ussions in the past couple years, it's become clear that we would need to s= ignificantly extend ENUM to get it to handle all of the sorts of sources, s= ubjects, and attributes that people want to factor into queries about telep= hone number routing and administration. Most of these discussions have gott= en wrapped around the axle on questions of the underlying syntax and semant= ics of the DNS, which were a good match for the original vision of a public= , user-driven ENUM, but don't seem to be such a good match for the uses peo= ple actually want to make of these protocols, in federated, service-provide= r-driven environments like those envisioned in SPEERMINT and provisioned in= DRINKS. While the discussion may have died down a bit, the requirements th= at motivated th e discussion definitely aren't going away. Rather than continue to debate the applicability of the DNS and the probity= of various extensions to it, we might make more progress if we work toward= s agreement on the semantics of queries for telephone-related data independ= ently of any underlying protocols. In other words, focus on what kinds of q= uestions about telephone numbers we want to be able to ask, and what kinds = of information needs to go into the answers, and incorporate all this into = an abstract data model. So for example, we know that we want to be able to = express the source of a request in a query. What do we mean by source? I ca= n think of a bunch of different kinds of source: the logical originator of = the query (the administrative entity asking), the logical identity of any i= ntermediary or aggregator forwarding the query, or even the point at the ne= twork from which the call originates (the originating trunk group, SBC or w= hat have you). All three of those concepts of source seem important when it= comes to answe ring questions about telephone numbers, so a data model wo= uld treat those as separate elements which can vary independently - then we= can then try to figure out what's mandatory or optional, etc. We follow th= is same method for all the elements of queries and responses. Figure out wh= at the attributes are of telephone numbers that we care about, sort them in= to buckets of routing data and administrative data, and so on. Once we have an agreement on the data model, then people can map the model = to whatever underlying protocol they'd like - or just build it into a web A= PI, or what have you. Those proposals could advance as separate documents. = Having that flexibility would make it a lot easier to figure out what we re= ally want the questions and answers to be, rather than thinking about what = they realistically can be within the constraints of some existing underlyin= g protocol. That's the idea. I'm not going to present a proposed charter for work or an= ything like that in Paris, but I am interested in hearing if people think t= his is a promising approach, and if so, perhaps we'd put a charter on the a= genda for Vancouver. I have however submitted a -00 draft for this time whi= ch gives a high-level proposal for a data model and at least enumerates wha= t some of the elements might be that would be populated in queries and resp= onses. This is a pretty broad sketch, but it should convey the basic idea. = You can check it out here: https://exchcas.va.neustar.com/owa/thoughts about the direction or the spec= ifics of the data model are welcome. Thanks! Jon Peterson NeuStar, Inc. =20 From kcartwright@tnsi.com Tue Mar 6 14:54:52 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4423E21E8034 for ; Tue, 6 Mar 2012 14:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.076 X-Spam-Level: X-Spam-Status: No, score=-1.076 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 DL1VyapZ6vxv for ; Tue, 6 Mar 2012 14:54:45 -0800 (PST) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE7F821E8014 for ; Tue, 6 Mar 2012 14:54:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAHWUVk+sEQfn/2dsb2JhbABDgkWzRIF9AQEFLVwCAQgRBAEBIQEGByERFAkIAQEEARIIE8FFiTtvhWNjBIhSmA2EdoMBgT4 X-IronPort-AV: E=Sophos;i="4.73,542,1325462400"; d="scan'208,217";a="967539" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 06 Mar 2012 22:54:42 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 6 Mar 2012 17:54:42 -0500 From: "Cartwright, Ken" To: Mickael Marrache , "drinks@ietf.org" Date: Tue, 6 Mar 2012 17:54:47 -0500 Thread-Topic: [drinks] SPPF changes proposal Thread-Index: Acz5ZsN8UBWydZF5RgeTrNBFqrUTfACgo/dQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B4254E341B54864B92D28BC2138A9DC303145DAEB3TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] SPPF changes proposal X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:54:54 -0000 --_000_B4254E341B54864B92D28BC2138A9DC303145DAEB3TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mickael, 1) Maybe if you could provide/describe a new use case that the current mode= l does not support then the need for the proposal would be clearer. 2) In the current model the Route Recs associated to a Route Group are inte= nded to be applicableTo/appropriateFor multiple/many PIs. A Route Rec dire= ctly associated to a PI is intended to be applicableTo/appropriateFor just = that PI (e.g. contain PI specific info such as in user ENUM). Given that, = why would we also want the PIs that are directly associated to a PI to be p= art of a named group, so that they could be easily associated to multiple/m= any PIs. 3) And in regards to your statement... "Also, I didn't get an answer concer= ning the possibility to associate a single TNR, TNP or RN directly to one o= r more route records. Would we add also a direct association from RN, TNR o= r TNP to route record?" Sorry, but I guess I missed that question in your = original email. I'm not fully clear on the question, but I think it may be= answered by understanding point 2 above. Ken ________________________________ From: Mickael Marrache [mailto:mickaelmarrache@gmail.com] Sent: Saturday, March 03, 2012 12:55 PM To: Cartwright, Ken; drinks@ietf.org Subject: Re: [drinks] SPPF changes proposal Hi Ken, "To meet the requirements deduced from the user ENUM use case, a direct ass= ociation between the TN and route record types has been added" KJC: Nothing has been "added", the data model has been this way for at lea= st two years now. You're right. Sorry for saying something I didn't check. "So, one solution is to include these route records in a dummy (since the i= ncluded route records have not common routes) destination group DG-1. Then,= we also create a dummy (since it doesn't contain any route) route group RG= -1 and associate it to DG-1. Then, the route group may be offered to a peer= ing organization." KJC: The Destination Group and the Route Group you refer to as "Dummys", ar= e not "Dummys" they are an integral and expected part of the data structure= . "First, since the destination group DG-1 and the route group RG-1 are not u= sed for their primary reason (a destination group allows grouping of public= identifiers that share a common set of routes, and a route group is genera= lly used to group route records that may correspond to a same "destination"= - that's why we share them as a block), it reveals a potential design issu= e." KJC: The Route Group you refer to as "not contain any route rec" is not ac= curate. It may or may not contain Route Recs. It is up to the registrant = and registrar to decide whether they wish to have route recs on a given rou= te group, regardless of whether they have also decided to have Route Recs d= irectly associated with a PI (i.e. in the user ENUM case, where some PIs wi= ll/may have Route Recs that contain info that is specific to that PI). The= model allows both, depending on the Registrar's Registrant's need. So, the route group may or may not contain route records. If it doesn't contain route records, I understand that it is only used to s= hare the route records directly associated to the PIs. In this case, do you= agree that it is not a real route group (i.e. a construct that allows regr= ouping route records that correspond to a same destination)? If it does contain route records, I understand that it plays two roles: it = allows sharing the route records directly associated to the PIs as previous= ly, and it allows sharing the route records that correspond to a same desti= nation. KJC: The Destination Group and Route Groups involved here _do_ in fact ser= ve the purpose that they are designed to serve. They allow the peering vis= ibility of large numbers of public identities and their routing information= to be controlled at an aggregate with just a few number of API calls, as a= pposed to millions (one per PI or Route Rec). They allow the Destination G= roup to be associated or disassociated to from one or more Route Group obje= cts in a single command as the need arises, they allow the Route Group to b= e offered/accepted in a single command, rather than one per route rec (whic= h there would be millions of in the User ENUM case) or one per PI. They Ro= ute Group allows further control of the visibility based on source-based ro= uting, and other routing selection algorithms that, at this time, would be = vendor specific since they are not in the protocol (e.g. time-of-day, cost,= etc). In the proposed model, this property is still true. It also allows the peer= ing visibility of a large number of public identifiers and their routing in= formation also using an aggregate (you will note that we didn't remove the = destination and route groups constructs) with a few number of API calls. An= d I disagree when you say that the proposed model requires offering to be d= one per route in the user ENUM case. When a huge number of PIs are associat= ed to route records directly (though a RoutingAssoc element), you are not f= orced to offer each one of these associations, you simply need to regroup t= hem in an association group and to share this association group, I don't se= e here any scalability issue. Also, source based routing is also present in the proposed data model, in t= he ShareableElement type. "In this case, when an originating SSP wants to know the routes records ass= ociated to TN 1 for example...." KJC: The second paragraph in your note attempts to describe part of the re= solution process, I've included the first part of your statement above. It= basically says that the resolution process is somehow different if Route R= ecs are directly associated with the PI than if they are associated with th= e Route Group. This is not accurate. First off, SPPP does not attempt to = define how resolution servers must evaluate the data that SPP provisions. = Doing so would be folly, since TN resolution logic is much too involved, an= d often situation specific, including looking at data sources that do not e= ven come in over SPPP (e.g. portability data, etc, etc). However, the basi= c logic involves (1) using the lookup key (e.g. a TN) and the source of the= query to get the Destination Groups that contain that lookup key that are = visible to that source based on the Route Groups that that source has accep= ted (or auto-accepted), (2) collecting the Route Recs that are on the Route= Group(s) if any and/or the PI if any, (3) evaluating the Route Recs based = on their priority (and other vendor specific resolution logic, which the pr= otocol does not attempt to specify), then sending the collected Route Recs = out in the resolution response. Notice that there are not two different fl= ows. My comment for this point is related to the fact that a route group plays t= he two roles mentioned previously. Playing what I call the basic role (regr= ouping route records corresponding to the same destination) and the disturb= ing role (allowing offer for route records directly associated to PIs) is s= imply not intuitive. And, that's why David qualified this role as a hack. I= t's not a derision for the current model, it is simply the fact that there = is something that is at the wrong place. Also, I didn't get an answer concerning the possibility to associate a sing= le TNR, TNP or RN directly to one or more route records. Would we add also = a direct association from RN, TNR or TNP to route record? KJC: But from a bigger picture perspective, when the proposal was brought = up yesterday, it was brought up under the guise that "the current data mode= l is broken and it a hack in this area, so we need to do X, Y and Z". This= is simply not accurate, as I've described above. Secondly, the proposed a= lternative simply does not work in terms of scalability for the User ENUM u= se case. The proposal would result in millions of Route Recs (since in the= user enum case the Route Recs contain PI specific data) having to be offer= ed and accepted. So even the primary target use case of the proposal just = does not work well. So given that the current model is not "broken" and is= not a "hack" and given that the new proposal does not scale for the user e= num use case, why add in the additional complexity that results from the ne= w proposal? At this point, I still don't understand why the proposed model is not accur= ate. I don't understand why millions of route records have to been offered = and accepted? I think grouping associations solves this problem. Please, ca= n you illustrate by a scenario or diagram (especially for the User ENUM use= case)? I just want to precise that my comments are not intended to create conflict= s in any manner especially when I see that it's late to raise such proposit= ions and that the draft will become soon a RFC. I'm just trying to add my e= fforts to this framework/protocol. Thanks Mickael ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_B4254E341B54864B92D28BC2138A9DC303145DAEB3TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mickael,

 

1) Maybe if you could provide/describe= a new use case that the current model does not support then the need for t= he proposal would be clearer.

 

2) In the current model the Route Recs= associated to a Route Group are intended to be applicableTo/appropriateFor= multiple/many PIs.  A Route Rec directly associated to a PI is intended to be applicable= To/appropriateFor just that PI (e.g. contain PI specific info such as in us= er ENUM).  Given that, why would we also want the PIs that are directl= y associated to a PI to be part of a named group, so that they could be easily associated to multiple/many PIs.<= /o:p>

 

3) And in regards to your statement… “Also, I didn't get an answer concerning the possibility to associate a single TN= R, TNP or RN directly to one or more route records. Would we add also a dir= ect association from RN, TNR or TNP to route record?”  Sorry, but I guess I missed that question in = your original email.  I’m not fully clear on the question, but I= think it may be answered by understanding point 2 above.

Ken

 

From: Mick= ael Marrache [mailto:mickaelmarrache@gmail.com]
Sent: Saturday, March 03, 20= 12 12:55 PM
To: Cartwright, Ken; drinks@ietf.org
Subject: Re: [drinks] SPPF c= hanges proposal

 

Hi Ken,

“To meet the requirements deduced from the = user ENUM use case, a direct association between the TN and route record types has been added&= #8221;

KJC:  Nothing has been “added”, the data model= has been this way for at least two years now.


You're right. Sorry for saying something I didn't check.  <= /span>

 

“So, one solution is to include these route= records in a dummy (since the included route records have not common routes) destination grou= p DG-1. Then, we also create a dummy (since it doesn't contain any route) r= oute group RG-1 and associate it to DG-1. Then, the route group may be offe= red to a peering organization.”

 

KJC: The Destination Group and the Route Group you refer to as = “Dummys”, are not “Dummys” they are an integral and expected part of the dat= a structure.

 

“First, since the destination group DG-1 and the route group= RG-1 are not used for their primary reason (a destination group allows grouping of public identifiers that share a common set of rou= tes, and a route group is generally used to group route records that may co= rrespond to a same "destination" - that's why we share them as a = block), it reveals a potential design issue.”

 

KJC:  The Route Group you refer to as “not contain a= ny route rec” is not accurate.  It may or may not contain Route Recs.  It is up to the registrant and= registrar to decide whether they wish to have route recs on a given route = group, regardless of whether they have also decided to have Route Recs dire= ctly associated with a PI (i.e. in the user ENUM case, where some PIs will/may have Route Recs that contain info = that is specific to that PI).  The model allows both, depending on the= Registrar’s Registrant’s need.

 

So, the route group may or may not contain route records.

If it doesn't contain route records, I understand that it is o= nly used to share the route records directly associated to the PIs. In this case, do y= ou agree that it is not a real route group (i.e. a co= nstruct that allows regrouping route records that correspond to a same dest= ination)?

If it does contain route records, I understand that it plays t= wo roles: it allows sharing the route records directly associated to the PIs as prev= iously, and it allows sharing the route records that correspond to a same d= estination.

 

 

KJC:  The Destination Group and Route Groups involved here= _do_ in fact serve the purpose that they are designed to serve.  They allo= w the peering visibility of large numbers of public identities and their ro= uting information to be controlled at an aggregate with just a few number o= f API calls, as apposed to millions (one per PI or Route Rec).  They allow the Destination Group to be associa= ted or disassociated to from one or more Route Group objects in a single co= mmand as the need arises, they allow the Route Group to be offered/accepted= in a single command, rather than one per route rec (which there would be millions of in the User ENUM case) or = one per PI.  They Route Group allows further control of the visibility= based on source-based routing, and other routing selection algorithms that= , at this time, would be vendor specific since they are not in the protocol (e.g. time-of-day, cost, etc).

 

In the proposed model, this property is still true. It also al= lows the peering visibility of a large number of public identifiers and their routing infor= mation also using an aggregate (you will note that we didn't remove the des= tination and route groups constructs) with a few number of API calls. And I= disagree when you say that the proposed model requires offering to be done per route in the user ENUM cas= e. When a huge number of PIs are associated to route records directly (thou= gh a RoutingAssoc element), you are not forced to offer each one of these a= ssociations, you simply need to regroup them in an association group and to share this association group, = I don't see here any scalability issue.

Also, source based routing is also present in the proposed dat= a model, in the ShareableElement type.

 

 

“In this case, when an originating SSP want= s to know the routes records associated to TN 1 for example….”

 

KJC:  The second paragraph in your note attempts to descri= be part of the resolution process, I’ve included the first part of your statement above. = It basically says that the resolution process is somehow different if Rout= e Recs are directly associated with the PI than if they are associated with= the Route Group.  This is not accurate.  First off, SPPP does not attempt to define how resolution servers must evaluate = the data that SPP provisions.  Doing so would be folly, since TN resol= ution logic is much too involved, and often situation specific, including l= ooking at data sources that do not even come in over SPPP (e.g. portability data, etc, etc).  However, the ba= sic logic involves (1) using the lookup key (e.g. a TN) and the source of t= he query to get the Destination Groups that contain that lookup key that ar= e visible to that source based on the Route Groups that that source has accepted (or auto-accepted), (2) collect= ing the Route Recs that are on the Route Group(s) if any and/or the PI if a= ny, (3) evaluating the Route Recs based on their priority (and other vendor= specific resolution logic, which the protocol does not attempt to specify), then sending the collected Rout= e Recs out in the resolution response.  Notice that there are not two = different flows.

 

My comment for this point is related to the fact that a route = group plays the two roles mentioned previously. Playing what I call the basic role (re= grouping route records corresponding to the same destination) and the distu= rbing role (allowing offer for route records directly associated to PIs) is= simply not intuitive. And, that's why David qualified this role as a hack. It's not a derision for the curre= nt model, it is simply the fact that there is something that is at the wron= g place.

Also, I didn't get an answer concerning the possibility to ass= ociate a single TNR, TNP or RN directly to one or more route records. Would we add also a = direct association from RN, TNR or TNP to route record?<= /o:p>

 

 

KJC:  But from a bigger picture perspective, when the prop= osal was brought up yesterday, it was brought up under the guise that “the current da= ta model is broken and it a hack in this area, so we need to do X, Y and Z&= #8221;.  This is simply not accurate, as I’ve described above.&n= bsp; Secondly, the proposed alternative simply does not work in terms of scalability for the User ENUM use case.  The proposal wou= ld result in millions of Route Recs (since in the user enum case the Route = Recs contain PI specific data) having to be offered and accepted.  So = even the primary target use case of the proposal just does not work well.  So given that the current model is not R= 20;broken” and is not a “hack” and given that the new pro= posal does not scale for the user enum use case, why add in the additional = complexity that results from the new proposal?

 

At this point, I still don't understa= nd why the proposed model is not accurate. I don't understand why millions = of route records have to been offered and accepted? I think grouping associations solves this pr= oblem. Please, can you illustrate by a scenario or diagram (especially for = the User ENUM use case)?


I just want to precise that my comments are not intended to create conflict= s in any manner especially when I see that it's late to raise such proposit= ions and that the draft will become soon a RFC. I'm just trying to add my e= fforts to this framework/protocol.

Thanks

Mickael


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_B4254E341B54864B92D28BC2138A9DC303145DAEB3TNSMAILNAwin2_-- From kcartwright@tnsi.com Tue Mar 6 15:26:36 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3081A21F8631 for ; Tue, 6 Mar 2012 15:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.75 X-Spam-Level: X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_20=-0.74, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 FYf6lE6b0lPq for ; Tue, 6 Mar 2012 15:26:30 -0800 (PST) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5110021F862A for ; Tue, 6 Mar 2012 15:26:29 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAN+cVk+sEQfn/2dsb2JhbABDglKzRIF9AQEFLVwCAQgRBAEBIQEGByERFAkIAQEEARIIE8AAiTtvhWNjBIhSmA2EdoMBgT4 X-IronPort-AV: E=Sophos;i="4.73,542,1325462400"; d="scan'208,217";a="967639" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 06 Mar 2012 23:26:27 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 6 Mar 2012 18:26:27 -0500 From: "Cartwright, Ken" To: "Cartwright, Ken" , Mickael Marrache , "drinks@ietf.org" Date: Tue, 6 Mar 2012 18:26:27 -0500 Thread-Topic: [drinks] SPPF changes proposal Thread-Index: Acz5ZsN8UBWydZF5RgeTrNBFqrUTfACgo/dQAAEk7zA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B4254E341B54864B92D28BC2138A9DC303145DAED2TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] SPPF changes proposal X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 23:26:36 -0000 --_000_B4254E341B54864B92D28BC2138A9DC303145DAED2TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, typo in item 2, it should read 2) In the current model the Route Recs associated to a Route Group are inte= nded to be applicableTo/appropriateFor multiple/many PIs. A Route Rec dire= ctly associated to a PI is intended to be applicableTo/appropriateFor just = that PI (e.g. contain PI specific info such as in user ENUM). Given that, = why would we also want the Route Recs that are directly associated to a PI = to be part of a named group, so that they could be easily associated to mul= tiple/many PIs. ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Cartwright, Ken Sent: Tuesday, March 06, 2012 5:55 PM To: Mickael Marrache; drinks@ietf.org Subject: Re: [drinks] SPPF changes proposal Hi Mickael, 1) Maybe if you could provide/describe a new use case that the current mode= l does not support then the need for the proposal would be clearer. 2) In the current model the Route Recs associated to a Route Group are inte= nded to be applicableTo/appropriateFor multiple/many PIs. A Route Rec dire= ctly associated to a PI is intended to be applicableTo/appropriateFor just = that PI (e.g. contain PI specific info such as in user ENUM). Given that, = why would we also want the PIs that are directly associated to a PI to be p= art of a named group, so that they could be easily associated to multiple/m= any PIs. 3) And in regards to your statement... "Also, I didn't get an answer concer= ning the possibility to associate a single TNR, TNP or RN directly to one o= r more route records. Would we add also a direct association from RN, TNR o= r TNP to route record?" Sorry, but I guess I missed that question in your = original email. I'm not fully clear on the question, but I think it may be= answered by understanding point 2 above. Ken ________________________________ From: Mickael Marrache [mailto:mickaelmarrache@gmail.com] Sent: Saturday, March 03, 2012 12:55 PM To: Cartwright, Ken; drinks@ietf.org Subject: Re: [drinks] SPPF changes proposal Hi Ken, "To meet the requirements deduced from the user ENUM use case, a direct ass= ociation between the TN and route record types has been added" KJC: Nothing has been "added", the data model has been this way for at lea= st two years now. You're right. Sorry for saying something I didn't check. "So, one solution is to include these route records in a dummy (since the i= ncluded route records have not common routes) destination group DG-1. Then,= we also create a dummy (since it doesn't contain any route) route group RG= -1 and associate it to DG-1. Then, the route group may be offered to a peer= ing organization." KJC: The Destination Group and the Route Group you refer to as "Dummys", ar= e not "Dummys" they are an integral and expected part of the data structure= . "First, since the destination group DG-1 and the route group RG-1 are not u= sed for their primary reason (a destination group allows grouping of public= identifiers that share a common set of routes, and a route group is genera= lly used to group route records that may correspond to a same "destination"= - that's why we share them as a block), it reveals a potential design issu= e." KJC: The Route Group you refer to as "not contain any route rec" is not ac= curate. It may or may not contain Route Recs. It is up to the registrant = and registrar to decide whether they wish to have route recs on a given rou= te group, regardless of whether they have also decided to have Route Recs d= irectly associated with a PI (i.e. in the user ENUM case, where some PIs wi= ll/may have Route Recs that contain info that is specific to that PI). The= model allows both, depending on the Registrar's Registrant's need. So, the route group may or may not contain route records. If it doesn't contain route records, I understand that it is only used to s= hare the route records directly associated to the PIs. In this case, do you= agree that it is not a real route group (i.e. a construct that allows regr= ouping route records that correspond to a same destination)? If it does contain route records, I understand that it plays two roles: it = allows sharing the route records directly associated to the PIs as previous= ly, and it allows sharing the route records that correspond to a same desti= nation. KJC: The Destination Group and Route Groups involved here _do_ in fact ser= ve the purpose that they are designed to serve. They allow the peering vis= ibility of large numbers of public identities and their routing information= to be controlled at an aggregate with just a few number of API calls, as a= pposed to millions (one per PI or Route Rec). They allow the Destination G= roup to be associated or disassociated to from one or more Route Group obje= cts in a single command as the need arises, they allow the Route Group to b= e offered/accepted in a single command, rather than one per route rec (whic= h there would be millions of in the User ENUM case) or one per PI. They Ro= ute Group allows further control of the visibility based on source-based ro= uting, and other routing selection algorithms that, at this time, would be = vendor specific since they are not in the protocol (e.g. time-of-day, cost,= etc). In the proposed model, this property is still true. It also allows the peer= ing visibility of a large number of public identifiers and their routing in= formation also using an aggregate (you will note that we didn't remove the = destination and route groups constructs) with a few number of API calls. An= d I disagree when you say that the proposed model requires offering to be d= one per route in the user ENUM case. When a huge number of PIs are associat= ed to route records directly (though a RoutingAssoc element), you are not f= orced to offer each one of these associations, you simply need to regroup t= hem in an association group and to share this association group, I don't se= e here any scalability issue. Also, source based routing is also present in the proposed data model, in t= he ShareableElement type. "In this case, when an originating SSP wants to know the routes records ass= ociated to TN 1 for example...." KJC: The second paragraph in your note attempts to describe part of the re= solution process, I've included the first part of your statement above. It= basically says that the resolution process is somehow different if Route R= ecs are directly associated with the PI than if they are associated with th= e Route Group. This is not accurate. First off, SPPP does not attempt to = define how resolution servers must evaluate the data that SPP provisions. = Doing so would be folly, since TN resolution logic is much too involved, an= d often situation specific, including looking at data sources that do not e= ven come in over SPPP (e.g. portability data, etc, etc). However, the basi= c logic involves (1) using the lookup key (e.g. a TN) and the source of the= query to get the Destination Groups that contain that lookup key that are = visible to that source based on the Route Groups that that source has accep= ted (or auto-accepted), (2) collecting the Route Recs that are on the Route= Group(s) if any and/or the PI if any, (3) evaluating the Route Recs based = on their priority (and other vendor specific resolution logic, which the pr= otocol does not attempt to specify), then sending the collected Route Recs = out in the resolution response. Notice that there are not two different fl= ows. My comment for this point is related to the fact that a route group plays t= he two roles mentioned previously. Playing what I call the basic role (regr= ouping route records corresponding to the same destination) and the disturb= ing role (allowing offer for route records directly associated to PIs) is s= imply not intuitive. And, that's why David qualified this role as a hack. I= t's not a derision for the current model, it is simply the fact that there = is something that is at the wrong place. Also, I didn't get an answer concerning the possibility to associate a sing= le TNR, TNP or RN directly to one or more route records. Would we add also = a direct association from RN, TNR or TNP to route record? KJC: But from a bigger picture perspective, when the proposal was brought = up yesterday, it was brought up under the guise that "the current data mode= l is broken and it a hack in this area, so we need to do X, Y and Z". This= is simply not accurate, as I've described above. Secondly, the proposed a= lternative simply does not work in terms of scalability for the User ENUM u= se case. The proposal would result in millions of Route Recs (since in the= user enum case the Route Recs contain PI specific data) having to be offer= ed and accepted. So even the primary target use case of the proposal just = does not work well. So given that the current model is not "broken" and is= not a "hack" and given that the new proposal does not scale for the user e= num use case, why add in the additional complexity that results from the ne= w proposal? At this point, I still don't understand why the proposed model is not accur= ate. I don't understand why millions of route records have to been offered = and accepted? I think grouping associations solves this problem. Please, ca= n you illustrate by a scenario or diagram (especially for the User ENUM use= case)? I just want to precise that my comments are not intended to create conflict= s in any manner especially when I see that it's late to raise such proposit= ions and that the draft will become soon a RFC. I'm just trying to add my e= fforts to this framework/protocol. Thanks Mickael ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_B4254E341B54864B92D28BC2138A9DC303145DAED2TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry, typo in item 2, it should read

2) In the current model the Route Recs= associated to a Route Group are intended to be applicableTo/appropriateFor= multiple/many PIs.  A Route Rec directly associated to a PI is intended to be applicable= To/appropriateFor just that PI (e.g. contain PI specific info such as in us= er ENUM).  Given that, why would we also want the Route Recs that are = directly associated to a PI to be part of a named group, so that they could be easily associated to multiple/many PI= s.

 

From: drin= ks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Cartwright, Ken=
Sent: Tuesday, March 06, 201= 2 5:55 PM
To: Mickael Marrache; drinks@ietf.org
Subject: Re: [drinks] SPPF c= hanges proposal

 

Hi Mickael,

 

1) Maybe if you could provide/describe= a new use case that the current model does not support then the need for t= he proposal would be clearer.

 

2) In the current model the Route Recs= associated to a Route Group are intended to be applicableTo/appropriateFor= multiple/many PIs.  A Route Rec directly associated to a PI is intended to be applicable= To/appropriateFor just that PI (e.g. contain PI specific info such as in us= er ENUM).  Given that, why would we also want the PIs that are directl= y associated to a PI to be part of a named group, so that they could be easily associated to multiple/many PIs.<= /o:p>

 

3) And in regards to your statement… “Also, I didn't get an answer concerning the possibility to associate a single TN= R, TNP or RN directly to one or more route records. Would we add also a dir= ect association from RN, TNR or TNP to route record?”  Sorry, but I guess I missed that question in your original emai= l.  I’m not fully clear on the question, but I think it may be a= nswered by understanding point 2 above.

Ken

 

From: Mick= ael Marrache [mailto:mickaelmarrache@gmail.com]
Sent: Saturday, March 03, 20= 12 12:55 PM
To: Cartwright, Ken; drinks@ietf.org
Subject: Re: [drinks] SPPF c= hanges proposal

 

Hi Ken,

“To meet the requirements deduced from the = user ENUM use case, a direct association between the TN and route record types has been added&= #8221;

KJC:  Nothing has been “added”, the data model= has been this way for at least two years now.


You're right. Sorry for saying something I didn't check.  <= /span>

 

“So, one solution is to include these route= records in a dummy (since the included route records have not common routes) destination grou= p DG-1. Then, we also create a dummy (since it doesn't contain any route) r= oute group RG-1 and associate it to DG-1. Then, the route group may be offe= red to a peering organization.”

 

KJC: The Destination Group and the Route Group you refer to as = “Dummys”, are not “Dummys” they are an integral and expected part of the dat= a structure.

 

“First, since the destination group DG-1 and the route group= RG-1 are not used for their primary reason (a destination group allows grouping of public identifiers that share a common set of rou= tes, and a route group is generally used to group route records that may co= rrespond to a same "destination" - that's why we share them as a = block), it reveals a potential design issue.”

 

KJC:  The Route Group you refer to as “not contain a= ny route rec” is not accurate.  It may or may not contain Route Recs.  It is up to the registrant and= registrar to decide whether they wish to have route recs on a given route = group, regardless of whether they have also decided to have Route Recs dire= ctly associated with a PI (i.e. in the user ENUM case, where some PIs will/may have Route Recs that contain info = that is specific to that PI).  The model allows both, depending on the= Registrar’s Registrant’s need.

 

So, the route group may or may not contain route records.

If it doesn't contain route records, I understand that it is o= nly used to share the route records directly associated to the PIs. In this case, do y= ou agree that it is not a real route group (i.e. a co= nstruct that allows regrouping route records that correspond to a same dest= ination)?

If it does contain route records, I understand that it plays t= wo roles: it allows sharing the route records directly associated to the PIs as prev= iously, and it allows sharing the route records that correspond to a same d= estination.

 

 

KJC:  The Destination Group and Route Groups involved here= _do_ in fact serve the purpose that they are designed to serve.  They allo= w the peering visibility of large numbers of public identities and their ro= uting information to be controlled at an aggregate with just a few number o= f API calls, as apposed to millions (one per PI or Route Rec).  They allow the Destination Group to be associa= ted or disassociated to from one or more Route Group objects in a single co= mmand as the need arises, they allow the Route Group to be offered/accepted= in a single command, rather than one per route rec (which there would be millions of in the User ENUM case) or = one per PI.  They Route Group allows further control of the visibility= based on source-based routing, and other routing selection algorithms that= , at this time, would be vendor specific since they are not in the protocol (e.g. time-of-day, cost, etc).

 

In the proposed model, this property is still true. It also al= lows the peering visibility of a large number of public identifiers and their routing infor= mation also using an aggregate (you will note that we didn't remove the des= tination and route groups constructs) with a few number of API calls. And I= disagree when you say that the proposed model requires offering to be done per route in the user ENUM cas= e. When a huge number of PIs are associated to route records directly (thou= gh a RoutingAssoc element), you are not forced to offer each one of these a= ssociations, you simply need to regroup them in an association group and to share this association group, = I don't see here any scalability issue.

Also, source based routing is also present in the proposed dat= a model, in the ShareableElement type.

 

 

“In this case, when an originating SSP want= s to know the routes records associated to TN 1 for example….”

 

KJC:  The second paragraph in your note attempts to descri= be part of the resolution process, I’ve included the first part of your statement above. = It basically says that the resolution process is somehow different if Rout= e Recs are directly associated with the PI than if they are associated with= the Route Group.  This is not accurate.  First off, SPPP does not attempt to define how resolution servers must evaluate = the data that SPP provisions.  Doing so would be folly, since TN resol= ution logic is much too involved, and often situation specific, including l= ooking at data sources that do not even come in over SPPP (e.g. portability data, etc, etc).  However, the ba= sic logic involves (1) using the lookup key (e.g. a TN) and the source of t= he query to get the Destination Groups that contain that lookup key that ar= e visible to that source based on the Route Groups that that source has accepted (or auto-accepted), (2) collect= ing the Route Recs that are on the Route Group(s) if any and/or the PI if a= ny, (3) evaluating the Route Recs based on their priority (and other vendor= specific resolution logic, which the protocol does not attempt to specify), then sending the collected Rout= e Recs out in the resolution response.  Notice that there are not two = different flows.

 

My comment for this point is related to the fact that a route = group plays the two roles mentioned previously. Playing what I call the basic role (re= grouping route records corresponding to the same destination) and the distu= rbing role (allowing offer for route records directly associated to PIs) is= simply not intuitive. And, that's why David qualified this role as a hack. It's not a derision for the curre= nt model, it is simply the fact that there is something that is at the wron= g place.

Also, I didn't get an answer concerning the possibility to ass= ociate a single TNR, TNP or RN directly to one or more route records. Would we add also a = direct association from RN, TNR or TNP to route record?<= /o:p>

 

 

KJC:  But from a bigger picture perspective, when the prop= osal was brought up yesterday, it was brought up under the guise that “the current da= ta model is broken and it a hack in this area, so we need to do X, Y and Z&= #8221;.  This is simply not accurate, as I’ve described above.&n= bsp; Secondly, the proposed alternative simply does not work in terms of scalability for the User ENUM use case.  The proposal wou= ld result in millions of Route Recs (since in the user enum case the Route = Recs contain PI specific data) having to be offered and accepted.  So = even the primary target use case of the proposal just does not work well.  So given that the current model is not R= 20;broken” and is not a “hack” and given that the new pro= posal does not scale for the user enum use case, why add in the additional = complexity that results from the new proposal?

 

At this point, I still don't understa= nd why the proposed model is not accurate. I don't understand why millions = of route records have to been offered and accepted? I think grouping associations solves this pr= oblem. Please, can you illustrate by a scenario or diagram (especially for = the User ENUM use case)?


I just want to precise that my comments are not intended to create conflict= s in any manner especially when I see that it's late to raise such proposit= ions and that the draft will become soon a RFC. I'm just trying to add my e= fforts to this framework/protocol.

Thanks

Mickael

 

This e-mail message is for the sole use of the intended recipie= nt(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_B4254E341B54864B92D28BC2138A9DC303145DAED2TNSMAILNAwin2_-- From mickaelmarrache@gmail.com Thu Mar 8 05:50:23 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C530F21F84B9 for ; Thu, 8 Mar 2012 05:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 wiSGRHzX15pH for ; Thu, 8 Mar 2012 05:50:21 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2051821F84AF for ; Thu, 8 Mar 2012 05:50:20 -0800 (PST) Received: by werb10 with SMTP id b10so422944wer.31 for ; Thu, 08 Mar 2012 05:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VkBna7m47w217vwDhLIegxsTBH+7qmI3vacMKycj83Q=; b=GoFBiShQlmDN8kW2ypaoY9O6mUU9Do97P5u2F+Lbq13rOrRuwfih4qm8TS3lMcmmRC g3nEceMgK9rdcjf8tWRedmyGfECW3Po8ivbBalhdAbgr4E3F8fVT1fGMHYEakBnbWBD4 Vfl+apr+JwmeKMfquWL1mYXeOugr/UMjn0xNtneN8mSxbg41uPdTw57DEJI81kj4Mb7e FaGFK88pl1eZ5jV3qGasUraS4TPPwyZEvlniHCot8Ch1VIEsTCIyhNd+RnVa7FqThJn+ uod3wuSV0zin3ANftpjF/qlpus0rhwHRPM6igx3YAZ9WxpDjY/uWhhA3a6EVs5rsY7S2 FADQ== MIME-Version: 1.0 Received: by 10.180.92.71 with SMTP id ck7mr15388855wib.3.1331214620104; Thu, 08 Mar 2012 05:50:20 -0800 (PST) Received: by 10.216.46.209 with HTTP; Thu, 8 Mar 2012 05:50:19 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Mar 2012 15:50:19 +0200 Message-ID: From: Mickael Marrache To: "Cartwright, Ken" , drinks@ietf.org Content-Type: multipart/alternative; boundary=f46d043c80708d18ee04babb8e22 Subject: Re: [drinks] SPPF changes proposal X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 13:50:23 -0000 --f46d043c80708d18ee04babb8e22 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ken, 1) Maybe if you could provide/describe a new use case that the current > model does not support then the need for the proposal would be clearer. > As I understood from a previous response (not this one), the User ENUM scenario consists of a set of subscribers of a certain SSP. Each of the subscriber provides a certain route specific to it that is then associated to its telephone number. So, the registrant SSP adds the concerned PIs, the route records and the associations between them. Then, to share the route records associated to these PIs, the registrant SSP groups the PIs in a DG, creates a RG, associates the DG to the RG and shares the RG to a peering organization. Optionally, the RG may have route records associated to it. What is the meaning of these routes? If the routes corresponding to each PI are shared, the peering organization can establish sessions directly to these PIs? Do you mean these are general routes that may be used to establish sessions to these PIs through the registrant SSP network? Is there any case where a SSP would be interested to share only one PI to another SSP ? If yes, the current model requires creating a DG and a RG to enable peering of the single PI. I'm just thinking about the way of finding a generic model that is not built for specific needs, and I think the proposed model is not so different that the current one, the main change concerns introduction of an abstraction layer to deal with single elements and groups of elements as a single unit. 2) In the current model the Route Recs associated to a Route Group are > intended to be applicableTo/appropriateFor multiple/many PIs. A Route Re= c > directly associated to a PI is intended to be applicableTo/appropriateFor > just that PI (e.g. contain PI specific info such as in user ENUM). Given > that, why would we also want the Route Recs that are directly associated = to > a PI to be part of a named group, so that they could be easily associated > to multiple/many PIs. > The proposed model doesn't force you to group route records directly associated to a PI. You may associate the PI with each route record separately. Then, if a registrant SSP wants to share these route records to a peering organization, it may group them in an association group and share this group. 3) And in regards to your statement=85 =93Also, I didn't get an answer > concerning the possibility to associate a single TNR, TNP or RN directly = to > one or more route records. Would we add also a direct association from RN= , > TNR or TNP to route record?=94 Sorry, but I guess I missed that question > in your original email. I=92m not fully clear on the question, but I thi= nk > it may be answered by understanding point 2 above. > This is the same scenario as for the TN but this is not supported by the current draft since the list of directly associated route records is defined in the TN type and not in the PubIdType. What I mean is that we may have a single RN, TNR or TNP associated to one or more PIs directly. And in this case, why also to use grouping elements when they are not necessary? Mickael On Wed, Mar 7, 2012 at 1:26 AM, Cartwright, Ken wrote= : > ** > > Sorry, typo in item 2, it should read **** > > 2) In the current model the Route Recs associated to a Route Group are > intended to be applicableTo/appropriateFor multiple/many PIs. A Route Re= c > directly associated to a PI is intended to be applicableTo/appropriateFor > just that PI (e.g. contain PI specific info such as in user ENUM). Given > that, why would we also want the Route Recs that are directly associated = to > a PI to be part of a named group, so that they could be easily associated > to multiple/many PIs.**** > > ** ** > ------------------------------ > > *From:* drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] *On > Behalf Of *Cartwright, Ken > *Sent:* Tuesday, March 06, 2012 5:55 PM > *To:* Mickael Marrache; ** drinks@ietf.org > ** > *Subject:* Re: [drinks] SPPF changes proposal > **** > > ** ** > > Hi Mickael,**** > > ** ** > > 1) Maybe if you could provide/describe a new use case that the current > model does not support then the need for the proposal would be clearer.**= * > * > > ** ** > > 2) In the current model the Route Recs associated to a Route Group are > intended to be applicableTo/appropriateFor multiple/many PIs. A Route Re= c > directly associated to a PI is intended to be applicableTo/appropriateFor > just that PI (e.g. contain PI specific info such as in user ENUM). Given > that, why would we also want the PIs that are directly associated to a PI > to be part of a named group, so that they could be easily associated to > multiple/many PIs.**** > > ** ** > > 3) And in regards to your statement=85 =93Also, I didn't get an answer > concerning the possibility to associate a single TNR, TNP or RN directly = to > one or more route records. Would we add also a direct association from RN= , > TNR or TNP to route record?=94 Sorry, but I guess I missed that question > in your original email. I=92m not fully clear on the question, but I thi= nk > it may be answered by understanding point 2 above.**** > > Ken* ***** > > ** ** > ------------------------------ > > *From:* Mickael Marrache [mailto:mickaelmarrache@gmail.com] > *Sent:* Saturday, March 03, 2012 12:55 PM > *To:* Cartwright, Ken; ** drinks@ietf.org** > *Subject:* Re: [drinks] SPPF changes proposal**** > > ** ** > > Hi Ken,**** > > =93To meet the requirements deduced from the user ENUM use case, a direct > association between the TN and route record types has been added=94**** > > KJC: Nothing has been =93added=94, the data model has been this way for = at > least two years now.**** > > > You're right. Sorry for saying something I didn't check. **** > > **** > > =93So, one solution is to include these route records in a dummy (since t= he > included route records have not common routes) destination group DG-1. > Then, we also create a dummy (since it doesn't contain any route) route > group RG-1 and associate it to DG-1. Then, the route group may be offered > to a peering organization.=94**** > > **** > > KJC: The Destination Group and the Route Group you refer to as =93Dummys= =94, > are not =93Dummys=94 they are an integral and expected part of the data > structure.**** > > **** > > =93First, since the destination group DG-1 and the route group RG-1 are n= ot > used for their primary reason (a destination group allows grouping of > public identifiers that share a common set of routes, and a route group i= s > generally used to group route records that may correspond to a same > "destination" - that's why we share them as a block), it reveals a > potential design issue.=94**** > > **** > > KJC: The Route Group you refer to as =93not contain any route rec=94 is = not > accurate. It may or may not contain Route Recs. It is up to the > registrant and registrar to decide whether they wish to have route recs o= n > a given route group, regardless of whether they have also decided to have > Route Recs directly associated with a PI (i.e. in the user ENUM case, whe= re > some PIs will/may have Route Recs that contain info that is specific to > that PI). The model allows both, depending on the Registrar=92s Registra= nt=92s > need.**** > > **** > > So, the route group may or may not contain route records.**** > > If it doesn't contain route records, I understand that it is only used to > share the route records directly associated to the PIs. In this case, do > you agree that it is not a *real *route group (i.e. a construct that > allows regrouping route records that correspond to a same destination)?**= * > * > > If it does contain route records, I understand that it plays two roles: i= t > allows sharing the route records directly associated to the PIs as > previously, and it allows sharing the route records that correspond to a > same destination.**** > > ** ** > > ** ** > > KJC: The Destination Group and Route Groups involved here _*do*_ in fact > serve the purpose that they are designed to serve. They allow the peerin= g > visibility of large numbers of public identities and their routing > information to be controlled at an aggregate with just a few number of AP= I > calls, as apposed to millions (one per PI or Route Rec). They allow the > Destination Group to be associated or disassociated to from one or more > Route Group objects in a single command as the need arises, they allow th= e > Route Group to be offered/accepted in a single command, rather than one p= er > route rec (which there would be millions of in the User ENUM case) or one > per PI. They Route Group allows further control of the visibility based = on > source-based routing, and other routing selection algorithms that, at thi= s > time, would be vendor specific since they are not in the protocol (e.g. > time-of-day, cost, etc).**** > > ** ** > > In the proposed model, this property is still true. It also allows the > peering visibility of a large number of public identifiers and their > routing information also using an aggregate (you will note that we didn't > remove the destination and route groups constructs) with a few number of > API calls. And I disagree when you say that the proposed model requires > offering to be done per route in the user ENUM case. When a huge number o= f > PIs are associated to route records directly (though a RoutingAssoc > element), you are not forced to offer each one of these associations, you > simply need to regroup them in an association group and to share this > association group, I don't see here any scalability issue.**** > > Also, source based routing is also present in the proposed data model, in > the ShareableElement type.**** > > ** ** > > ** ** > > =93In this case, when an originating SSP wants to know the routes records > associated to TN 1 for example=85.=94**** > > **** > > KJC: The second paragraph in your note attempts to describe part of the > resolution process, I=92ve included the first part of your statement abov= e. > It basically says that the resolution process is somehow different if Rou= te > Recs are directly associated with the PI than if they are associated with > the Route Group. This is not accurate. First off, SPPP does not attempt > to define how resolution servers must evaluate the data that SPP > provisions. Doing so would be folly, since TN resolution logic is much t= oo > involved, and often situation specific, including looking at data sources > that do not even come in over SPPP (e.g. portability data, etc, etc). > However, the basic logic involves (1) using the lookup key (e.g. a TN) an= d > the source of the query to get the Destination Groups that contain that > lookup key that are visible to that source based on the Route Groups that > that source has accepted (or auto-accepted), (2) collecting the Route Rec= s > that are on the Route Group(s) if any and/or the PI if any, (3) evaluatin= g > the Route Recs based on their priority (and other vendor specific > resolution logic, which the protocol does not attempt to specify), then > sending the collected Route Recs out in the resolution response. Notice > that there are not two different flows.**** > > **** > > My comment for this point is related to the fact that a route group plays > the two roles mentioned previously. Playing what I call the basic role > (regrouping route records corresponding to the same destination) and the > disturbing role (allowing offer for route records directly associated to > PIs) is simply not intuitive. And, that's why David qualified this role a= s > a hack. It's not a derision for the current model, it is simply the fact > that there is something that is at the wrong place.**** > > Also, I didn't get an answer concerning the possibility to associate a > single TNR, TNP or RN directly to one or more route records. Would we add > also a direct association from RN, TNR or TNP to route record?**** > > **** > > ** ** > > KJC: But from a bigger picture perspective, when the proposal was brough= t > up yesterday, it was brought up under the guise that =93the current data > model is broken and it a hack in this area, so we need to do X, Y and Z= =94. > This is simply not accurate, as I=92ve described above. Secondly, the > proposed alternative simply does not work in terms of scalability for the > User ENUM use case. The proposal would result in millions of Route Recs > (since in the user enum case the Route Recs contain PI specific data) > having to be offered and accepted. So even the primary target use case o= f > the proposal just does not work well. So given that the current model is > not =93broken=94 and is not a =93hack=94 and given that the new proposal = does not > scale for the user enum use case, why add in the additional complexity th= at > results from the new proposal?**** > > **** > > At this point, I still don't understand why the proposed model is not > accurate. I don't understand why millions of route records have to been > offered and accepted? I think grouping associations solves this problem. > Please, can you illustrate by a scenario or diagram (especially for the > User ENUM use case)? > > > I just want to precise that my comments are not intended to create > conflicts in any manner especially when I see that it's late to raise suc= h > propositions and that the draft will become soon a RFC. I'm just trying t= o > add my efforts to this framework/protocol. > > Thanks > > Mickael**** > > ** ** > ------------------------------ > > This e-mail message is for the sole use of the intended recipient(s)and m= ay > contain confidential and privileged information of Transaction Network > Services. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f > you > are not the intended recipient, please contact the sender by reply e-mail > and destroy all copies of the original message.**** > > ------------------------------ > This e-mail message is for the sole use of the intended recipient(s)and m= ay > contain confidential and privileged information of Transaction Network > Services. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f > you > are not the intended recipient, please contact the sender by reply e-mail > and destroy all copies of the original message. > > --f46d043c80708d18ee04babb8e22 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Ken,

1) Maybe if you could provide/describe a new use case that the current=20 model does not support then the need for the proposal would be clearer.

As I understood from a previous= response (not this one), the User ENUM scenario consists of a set of subsc= ribers of a certain SSP. Each of the subscriber provides a certain route sp= ecific to it that is then associated to its telephone number. So, the regis= trant SSP adds the concerned PIs, the route records and the associations be= tween them. Then, to share the route records associated to these PIs, the r= egistrant SSP groups the PIs in a DG, creates a RG, associates the DG to th= e RG and shares the RG to a peering organization. Optionally, the RG may ha= ve route records associated to it. What is the meaning of these routes? If = the routes corresponding to each PI are shared, the peering organization ca= n establish sessions directly to these PIs? Do you mean these are general r= outes that may be used to establish sessions to these PIs through the regis= trant SSP network?

Is there any case where a SSP would be interested to share only one PI = to another SSP ?
If yes, the current model requires creating a DG and a = RG to enable peering of the single PI. I'm just thinking about the way = of finding a generic model that is not built for specific needs, and I thin= k the proposed model is not so different that the current one, the main cha= nge concerns introduction of an abstraction layer to deal with single eleme= nts and groups of elements as a single unit.


2) In the current model the Route Recs associated to a Route Group are=20 intended to be applicableTo/appropriateFor multiple/many PIs. =A0A Route Rec directly associated to a PI is intended to be=20 applicableTo/appropriateFor just that PI (e.g. contain PI specific info=20 such as in user ENUM). =A0Given that, why would we also want the Route=20 Recs that are directly associated to a PI to be part of a named group, so that they could be easily associated to multiple/many PIs.

The prop= osed model doesn't force you to group route records directly associated= to a PI. You may associate the PI with each route record separately. Then,= if a registrant SSP wants to share these route records to a peering organi= zation, it may group them in an association group and share this group.


3) And in regards to your statement=85 =93Also, I didn't get an answer concerning the possibility to associate a singl= e TNR, TNP or RN directly to one or more route records. Would we add also a direct association from RN, TNR or TNP to route record?=94=A0 Sorry, but I guess I missed that question in your original email. =A0I=92m not=20 fully clear on the question, but I think it may be answered by=20 understanding point 2 above.


This is the same scenario as for t= he TN but this is not supported by the current draft since the list of dire= ctly associated route records is defined in the TN type and not in the PubI= dType. What I mean is that we may have a single RN, TNR or TNP associated t= o one or more PIs directly. And in this case, why also to use grouping elem= ents when they are not necessary?

Mickael




On Wed, Mar 7, 2012 at 1:26 AM, Cartwright, = Ken <kcartwrig= ht@tnsi.com> wrote:

Sorry, typo in item 2, it sho= uld read

2) In the current model the R= oute Recs associated to a Route Group are intended to be applicableTo/appro= priateFor multiple/many PIs. =A0A Route Rec directly associated to a PI is intended to be applicableTo/= appropriateFor just that PI (e.g. contain PI specific info such as in user = ENUM). =A0Given that, why would we also want the Route Recs that are direct= ly associated to a PI to be part of a named group, so that they could be easily associated to multiple/many PI= s.

=A0

From: drinks-bounces@ietf.org<= /a> [mailto:dr= inks-bounces@ietf.org] On Behalf Of Cartwright, Ken=
Sent: Tuesday, March 06, 201= 2 5:55 PM
To: Mickael Marrache; drinks@ietf.org


Subject: Re: [drinks] SPPF c= hanges proposal

=A0

Hi Mickael,

=A0

1) Maybe if you could provide= /describe a new use case that the current model does not support then the n= eed for the proposal would be clearer.

=A0

2) In the current model the R= oute Recs associated to a Route Group are intended to be applicableTo/appro= priateFor multiple/many PIs. =A0A Route Rec directly associated to a PI is intended to be applicableTo/= appropriateFor just that PI (e.g. contain PI specific info such as in user = ENUM). =A0Given that, why would we also want the PIs that are directly asso= ciated to a PI to be part of a named group, so that they could be easily associated to multiple/many PIs.

=A0

3) And in regards to your sta= tement=85 =93Also, I didn't get an answer concerning the possibility to associate a singl= e TNR, TNP or RN directly to one or more route records. Would we add also a= direct association from RN, TNR or TNP to route record?=94=A0 Sorry, but I guess I missed that quest= ion in your original email. =A0I=92m not fully clear on the question, but I= think it may be answered by understanding point 2 above.

Ken

=A0

From: Mickael Ma= rrache [mailto:mickaelmarrache@gmail.com]
Sent: Saturday, March 03, 20= 12 12:55 PM
To: Cartwright, Ken; drinks@ietf.org=
Subject: Re: [drinks] SPPF c= hanges proposal

=A0

Hi Ken,

=93To meet the = requirements deduced from the user ENUM use case, a direct association between the TN and route record types has been added= =94

KJC:=A0 Nothing has been =93a= dded=94, the data model has been this way for at least two years now.


You're right. Sorry for saying something I didn't check.=A0 =

=A0

=93So, one solu= tion is to include these route records in a dummy (since the included route records have not common routes) destination grou= p DG-1. Then, we also create a dummy (since it doesn't contain any rout= e) route group RG-1 and associate it to DG-1. Then, the route group may be = offered to a peering organization.=94

=A0

KJC: The Destination Group an= d the Route Group you refer to as =93Dummys=94, are not =93Dummys=94 they are an integral and expected part of the data struct= ure.

=A0

=93First, since the destination group DG-1 and the r= oute group RG-1 are not used for their primary reason (a destination group allows grouping of public identifiers that share a common set of rou= tes, and a route group is generally used to group route records that may co= rrespond to a same "destination" - that's why we share them a= s a block), it reveals a potential design issue.=94

=A0

KJC:=A0 The Route Group you r= efer to as =93not contain any route rec=94 is not accurate.=A0 It may or may not contain Route Recs.=A0 It is up to the registrant and re= gistrar to decide whether they wish to have route recs on a given route gro= up, regardless of whether they have also decided to have Route Recs directl= y associated with a PI (i.e. in the user ENUM case, where some PIs will/may have Route Recs that contain info = that is specific to that PI).=A0 The model allows both, depending on the Re= gistrar=92s Registrant=92s need.

=A0

So, the route group may or may not cont= ain route records.

If it doesn't contain route records= , I understand that it is only used to share the route records directly associated to the PIs. In this case, do y= ou agree that it is not a real route group (i.e. a co= nstruct that allows regrouping route records that correspond to a same dest= ination)?

If it does contain route records, I und= erstand that it plays two roles: it allows sharing the route records directly associated to the PIs as prev= iously, and it allows sharing the route records that correspond to a same d= estination.

=A0

=A0

KJC:=A0 The Destination Group= and Route Groups involved here _do_ in fact serve the purpose that they are designed to serve. =A0They allow t= he peering visibility of large numbers of public identities and their routi= ng information to be controlled at an aggregate with just a few number of A= PI calls, as apposed to millions (one per PI or Route Rec). =A0They allow the Destination Group to be associated= or disassociated to from one or more Route Group objects in a single comma= nd as the need arises, they allow the Route Group to be offered/accepted in= a single command, rather than one per route rec (which there would be millions of in the User ENUM case) or = one per PI. =A0They Route Group allows further control of the visibility ba= sed on source-based routing, and other routing selection algorithms that, a= t this time, would be vendor specific since they are not in the protocol (e.g. time-of-day, cost, etc).

=A0

In the proposed model, this property is= still true. It also allows the peering visibility of a large number of public identifiers and their routing infor= mation also using an aggregate (you will note that we didn't remove the= destination and route groups constructs) with a few number of API calls. A= nd I disagree when you say that the proposed model requires offering to be done per route in the user ENUM cas= e. When a huge number of PIs are associated to route records directly (thou= gh a RoutingAssoc element), you are not forced to offer each one of these a= ssociations, you simply need to regroup them in an association group and to share this association group, = I don't see here any scalability issue.

Also, source based routing is also pres= ent in the proposed data model, in the ShareableElement type.

=A0

=A0

=93In this case= , when an originating SSP wants to know the routes records associated to TN 1 for example=85.=94

=A0

KJC:=A0 The second paragraph = in your note attempts to describe part of the resolution process, I=92ve included the first part of your statement above.=A0 It bas= ically says that the resolution process is somehow different if Route Recs = are directly associated with the PI than if they are associated with the Ro= ute Group. =A0This is not accurate.=A0 First off, SPPP does not attempt to define how resolution servers must evaluate = the data that SPP provisions. =A0Doing so would be folly, since TN resoluti= on logic is much too involved, and often situation specific, including look= ing at data sources that do not even come in over SPPP (e.g. portability data, etc, etc).=A0 However, the basic= logic involves (1) using the lookup key (e.g. a TN) and the source of the = query to get the Destination Groups that contain that lookup key that are v= isible to that source based on the Route Groups that that source has accepted (or auto-accepted), (2) collect= ing the Route Recs that are on the Route Group(s) if any and/or the PI if a= ny, (3) evaluating the Route Recs based on their priority (and other vendor= specific resolution logic, which the protocol does not attempt to specify), then sending the collected Rout= e Recs out in the resolution response.=A0 Notice that there are not two dif= ferent flows.

=A0

My comment for this point is related to= the fact that a route group plays the two roles mentioned previously. Playing what I call the basic role (re= grouping route records corresponding to the same destination) and the distu= rbing role (allowing offer for route records directly associated to PIs) is= simply not intuitive. And, that's why David qualified this role as a hack. It's not a derision for the c= urrent model, it is simply the fact that there is something that is at the = wrong place.

Also, I didn't get an answer concer= ning the possibility to associate a single TNR, TNP or RN directly to one or more route records. Would we add also a = direct association from RN, TNR or TNP to route record?

=A0

=A0

KJC:=A0 But from a bigger pic= ture perspective, when the proposal was brought up yesterday, it was brought up under the guise that =93the current data m= odel is broken and it a hack in this area, so we need to do X, Y and Z=94. = =A0This is simply not accurate, as I=92ve described above.=A0 Secondly, the= proposed alternative simply does not work in terms of scalability for the User ENUM use case. =A0The proposal would = result in millions of Route Recs (since in the user enum case the Route Rec= s contain PI specific data) having to be offered and accepted.=A0 So even t= he primary target use case of the proposal just does not work well.=A0 So given that the current model is not =93brok= en=94 and is not a =93hack=94 and given that the new proposal does not scal= e for the user enum use case, why add in the additional complexity that res= ults from the new proposal?

=A0

At this point, I still don't unders= tand why the proposed model is not accurate. I don't understand why mil= lions of route records have to been offered and accepted? I think grouping associations solves this pr= oblem. Please, can you illustrate by a scenario or diagram (especially for = the User ENUM use case)?


I just want to precise that my comments are not intended to create conflict= s in any manner especially when I see that it's late to raise such prop= ositions and that the draft will become soon a RFC. I'm just trying to = add my efforts to this framework/protocol.

Thanks

Mickael

=A0

This e-mail message is for the sole use of the intended recipie= nt(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.<= /p>


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

--f46d043c80708d18ee04babb8e22-- From internet-drafts@ietf.org Mon Mar 12 11:19:22 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4819D21F880B; Mon, 12 Mar 2012 11:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 jZOINZhMuJ-Q; Mon, 12 Mar 2012 11:19:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2BA21F87D7; Mon, 12 Mar 2012 11:19:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312181921.3512.35922.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 11:19:21 -0700 Cc: drinks@ietf.org Subject: [drinks] I-D Action: draft-ietf-drinks-spp-framework-01.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 18:19:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Data for Reachability of Inter/tra-Ne= tworK SIP Working Group of the IETF. Title : Session Peering Provisioning Framework (SPPF) Author(s) : Kenneth Cartwright Syed Wasim Ali Alexander Mayrhofer Vikas Bhatia Filename : draft-ietf-drinks-spp-framework-01.txt Pages : 59 Date : 2012-03-12 This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The framework is called the Session Peering Provisioning Framework (SPPF). The provisioned data is typically used by network elements for session peering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-spp-framework-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-drinks-spp-framework-01.txt From internet-drafts@ietf.org Mon Mar 12 11:23:25 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FED21F88D3; Mon, 12 Mar 2012 11:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 97qUFheof6o0; Mon, 12 Mar 2012 11:23:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316F321F88C8; Mon, 12 Mar 2012 11:23:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312182324.4961.96669.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 11:23:24 -0700 Cc: drinks@ietf.org Subject: [drinks] I-D Action: draft-ietf-drinks-spp-protocol-over-soap-01.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 18:23:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Data for Reachability of Inter/tra-Ne= tworK SIP Working Group of the IETF. Title : Session Peering Provisioning (SPP) Protocol over SOAP Author(s) : Kenneth Cartwright Vikas Bhatia Filename : draft-ietf-drinks-spp-protocol-over-soap-01.txt Pages : 91 Date : 2012-03-12 The Session Peering Provisioning Framework (SPPF) is an XML framework that exists to enable the provisioning of session establishment data into Session Data Registries or SIP Service Provider data stores. Sending XML data structures over Simple Object Access Protocol (SOAP) and HTTP(s) is a widely used, de-facto standard for messaging between elements of provisioning systems. Therefore the combination of SOAP and HTTP(s) as a transport protocol for SPPF is a natural fit. The obvious benefits include leveraging existing industry expertise, leveraging existing standards, and a higher probability that existing provisioning systems can be more easily integrated with this protocol. This document describes the specification for transporting SPPF XML structures over SOAP and HTTP(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-spp-protocol-over-soa= p-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-drinks-spp-protocol-over-soap= -01.txt From vbhatia@tnsi.com Mon Mar 12 11:43:57 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C21621F8976 for ; Mon, 12 Mar 2012 11:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.503, 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 QDbkawNvN-kZ for ; Mon, 12 Mar 2012 11:43:56 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0246B21F8945 for ; Mon, 12 Mar 2012 11:43:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAJFDXk+sEQfn/2dsb2JhbAA5CrZdggkBAQEEAQEBaAMXBgEIEQQBASguCxQHAQEFBAEEEwgBBYgHvAuKLAmFaWMEpW+Cf4FA X-IronPort-AV: E=Sophos;i="4.73,572,1325462400"; d="scan'208";a="983550" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 12 Mar 2012 18:43:54 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 12 Mar 2012 14:43:54 -0400 From: "Bhatia, Vikas" To: "drinks@ietf.org" Date: Mon, 12 Mar 2012 14:43:52 -0400 Thread-Topic: [drinks] I-D Action: draft-ietf-drinks-spp-framework-01.txt Thread-Index: Ac0AfK7ViWWYCL49QS2wkInJxZDSXwAALqVg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_B4254E341B54864B92D28BC2138A9DC303145DBA10TNSMAILNAwin2_" MIME-Version: 1.0 Subject: [drinks] FW: I-D Action: draft-ietf-drinks-spp-framework-01.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 18:43:57 -0000 --_002_B4254E341B54864B92D28BC2138A9DC303145DBA10TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, New versions of the draft documents for the SPP Framework and SPP Protocol = over SOAP have been submitted today. Following are the set of changes to the documents. Action Item (AI) numbers= are listed (wherever applicable). These AIs were identified in the last In= terim and subsequent weekly design meetings. =3D=3D=3DStart - List of Changes=3D=3D=3D SPP Framework document ---------------------- AI-1/ Addressed data model diagram inconsistencies - Diagram has been signi= ficantly revamped per the discussions and comments David's comments: * remove extensions * add missing arrows (TN and RR) * add [0..n] on relevant arrows Other changes: * Added the new URI type of Public Identifier (refer AI-3 below) * Added Egress Route into the diagram AI-3/ Non-numeric PI (URIPubIdType) and related text has been added. AI-5/ Removed priority from RteRec base type AI-6/ Also added "isInSvc" flag on RteRec base type AI-7/ Move up "ttl" field to base RteRec type SPP Protocol over SOAP document -------------------------------- AI-13a In the response, returned an error with the maximum (Response code 2= 001). AI-13c/ Removed definition of transaction id type as it is already listed i= n framework document. AI-14/ Expanded element name "dtlResult" to "detailResult" to make it consi= stent with element "overallResult". AI-15/ Defined a type "MsgType" to add max length to result message text. AI-19/ Clarifed attributes of ObjKeyType on how they identify uniqueness an= d added an example as well. -Corrected the numbering of Result Codes (like some result codes were start= ing with 2103 instead of 2100 etc). -Introduced an enumeration "ResultCodeValType" to define all the result cod= es. This ensures that server can only send one of the result codes defined = in the schema. In previous version(s), it was loosely defined to take in an= y integer. General ------- -Corrected some editorial nits (spell checks, consistent use of terminology= etc.). -Moved "ObjKeyTypeEnum" from framework to protocol document (thought protoc= ol document was an appropriate places for it since it is only used in the S= PP Protocol over SOAP schema). -A-11/ Review Security Cons section (All) - The change I did was to add the= text proposed by Scott in the SPP Protocol over SOAP document (and added S= cott's name to acknowledgements). =3D=3D=3DEnd - List of Changes=3D=3D=3D Thanks, Vikas -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org Sent: Monday, March 12, 2012 2:19 PM To: i-d-announce@ietf.org Cc: drinks@ietf.org Subject: [drinks] I-D Action: draft-ietf-drinks-spp-framework-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Data for Reachability of Inter/tra-Ne= tworK SIP Working Group of the IETF. Title : Session Peering Provisioning Framework (SPPF) Author(s) : Kenneth Cartwright Syed Wasim Ali Alexander Mayrhofer Vikas Bhatia Filename : draft-ietf-drinks-spp-framework-01.txt Pages : 59 Date : 2012-03-12 This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The framework is called the Session Peering Provisioning Framework (SPPF). The provisioned data is typically used by network elements for session peering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-spp-framework-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-drinks-spp-framework-01.txt _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_002_B4254E341B54864B92D28BC2138A9DC303145DBA10TNSMAILNAwin2_ Content-Type: message/rfc822 Received: from mail-hub-eur.win2k.corp.tnsi.com (172.17.208.65) by MAIL-HUB-NA.win2k.corp.tnsi.com (172.17.7.231) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 12 Mar 2012 14:24:07 -0400 Received: from relayeu.tnsi.com (172.17.102.26) by mail-hub-eur.win2k.corp.tnsi.com (172.17.208.65) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 12 Mar 2012 18:24:05 +0000 Received: from mail.ietf.org ([12.22.58.30]) by relayeu.tnsi.com with ESMTP; 12 Mar 2012 18:26:17 +0000 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3471D21E8014; Mon, 12 Mar 2012 11:23:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FED21F88D3; Mon, 12 Mar 2012 11:23:25 -0700 (PDT) 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 97qUFheof6o0; Mon, 12 Mar 2012 11:23:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316F321F88C8; Mon, 12 Mar 2012 11:23:24 -0700 (PDT) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" CC: "drinks@ietf.org" Sender: "drinks-bounces@ietf.org" Date: Mon, 12 Mar 2012 14:23:24 -0400 Subject: [drinks] I-D Action: draft-ietf-drinks-spp-protocol-over-soap-01.txt Thread-Topic: [drinks] I-D Action: draft-ietf-drinks-spp-protocol-over-soap-01.txt Thread-Index: Ac0AfU+lIddlNS41SqaWHEGjFk/8LQ== Message-ID: <20120312182324.4961.96669.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: mail-hub-eur.win2k.corp.tnsi.com X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-ironport-anti-spam-result: AkkCANY+Xk8MFjoekmdsb2JhbABBtWQiAQEBAQkLCwcSKYILBgEBNwYBAQQKGwMLAQIDAQIGAkAICAMBI0kFBIgECKt+hCoBhl8GjV+DIohYjHcBkyY x-ironport-anti-spam-filtered: true x-ironport-av: E=Sophos;i="4.73,572,1325462400"; d="scan'208";a="7095660" dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331576610; bh=C9C2fVFSHYYiK5l39gN4PO+ie+9G6np4pwyCVwbHQY0=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=SUlFXMmLmSwthmFz6UncKLVU4A/HP1d9oPv5dfvjrCGLqwADi458ISGOlE8ne37RG hSoktQd7lpagiRfRwG5KzDckgh63zr8zo/aGS8FDHeWoNYfjljC9e1jEq6kxeswqRn clLMICi2wB71WQF8gHhgf4g3Yzgf5wKxsYOjbx4I= x-virus-scanned: amavisd-new at amsl.com errors-to: drinks-bounces@ietf.org x-beenthere: drinks@ietf.org x-mailman-version: 2.1.12 list-id: IETF DRINKS WG x-spam-status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] delivered-to: drinks@ietfa.amsl.com x-spam-level: list-archive: list-post: x-original-to: drinks@ietfa.amsl.com x-spam-flag: NO x-spam-score: -102.581 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Data for Reachability of Inter/tra-Ne= tworK SIP Working Group of the IETF. Title : Session Peering Provisioning (SPP) Protocol over SOAP Author(s) : Kenneth Cartwright Vikas Bhatia Filename : draft-ietf-drinks-spp-protocol-over-soap-01.txt Pages : 91 Date : 2012-03-12 The Session Peering Provisioning Framework (SPPF) is an XML framework that exists to enable the provisioning of session establishment data into Session Data Registries or SIP Service Provider data stores. Sending XML data structures over Simple Object Access Protocol (SOAP) and HTTP(s) is a widely used, de-facto standard for messaging between elements of provisioning systems. Therefore the combination of SOAP and HTTP(s) as a transport protocol for SPPF is a natural fit. The obvious benefits include leveraging existing industry expertise, leveraging existing standards, and a higher probability that existing provisioning systems can be more easily integrated with this protocol. This document describes the specification for transporting SPPF XML structures over SOAP and HTTP(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-spp-protocol-over-soa= p-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-drinks-spp-protocol-over-soap= -01.txt _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks --_002_B4254E341B54864B92D28BC2138A9DC303145DBA10TNSMAILNAwin2_-- From shollenbeck@verisign.com Mon Mar 12 12:11:29 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7CE21E804D for ; Mon, 12 Mar 2012 12:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 EL24lG5qKo7l for ; Mon, 12 Mar 2012 12:11:29 -0700 (PDT) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3081F21F886E for ; Mon, 12 Mar 2012 12:11:19 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKT15KVtGk2Hx6VXqV7Vjms2pndrHxP4uv@postini.com; Mon, 12 Mar 2012 12:11:21 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2CJBDnG011036; Mon, 12 Mar 2012 15:11:13 -0400 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.245]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 15:11:13 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 12 Mar 2012 15:11:13 -0400 From: "Hollenbeck, Scott" To: "Bhatia, Vikas" , "drinks@ietf.org" Thread-Topic: [drinks] FW: I-D Action: draft-ietf-drinks-spp-framework-01.txt Thread-Index: Ac0AfK7ViWWYCL49QS2wkInJxZDSXwAALqVgAAGXWWA= Date: Mon, 12 Mar 2012 19:11:12 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D5BE4FE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2012 19:11:13.0629 (UTC) FILETIME=[E46718D0:01CD0083] Subject: Re: [drinks] FW: I-D Action: draft-ietf-drinks-spp-framework-01.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 19:11:29 -0000 > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On > Behalf Of Bhatia, Vikas > Sent: Monday, March 12, 2012 2:44 PM > To: drinks@ietf.org > Subject: [drinks] FW: I-D Action: draft-ietf-drinks-spp-framework- > 01.txt >=20 > Hi All, >=20 > New versions of the draft documents for the SPP Framework and SPP > Protocol over SOAP have been submitted today. >=20 > Following are the set of changes to the documents. Action Item (AI) > numbers are listed (wherever applicable). These AIs were identified in > the last Interim and subsequent weekly design meetings. My comments have been completely addressed - thanks! Scott From kcartwright@tnsi.com Wed Mar 14 08:04:46 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0DD21F8661 for ; Wed, 14 Mar 2012 08:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[AWL=-0.954, BAYES_00=-2.599, FB_IOW=3.333, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 lK7RR8z1ew8b for ; Wed, 14 Mar 2012 08:04:36 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACF521E8050 for ; Wed, 14 Mar 2012 08:04:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAM+yYE+sEQfn/2dsb2JhbAA9BoJFtG2CCQEBBRoBEkUXAgEIEQQBASEBBgchERQJCAEBBAESCBPESolKbwqFWGMEoQSEeoMCgUA X-IronPort-AV: E=Sophos;i="4.73,584,1325462400"; d="scan'208,217";a="989684" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 14 Mar 2012 15:04:27 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 14 Mar 2012 11:04:28 -0400 From: "Cartwright, Ken" To: Mickael Marrache , "drinks@ietf.org" Date: Wed, 14 Mar 2012 11:04:25 -0400 Thread-Topic: [drinks] SPPF changes proposal Thread-Index: Acz9Mmjh2E+drw4UQ5qgOO4e0VwXkgEuuKXQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B4254E341B54864B92D28BC2138A9DC30314ECCC9CTNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] SPPF changes proposal X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 15:04:46 -0000 --_000_B4254E341B54864B92D28BC2138A9DC30314ECCC9CTNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mickael, So is the new use case the "Want to be able to peer a single PI with a sing= le SSP, in high volume?, Iow want to support many many one-to-one relations= hips between PIs and peering SSPs". If so, then that is certainly not a us= e case that we ever worked toward, or documented in the use case document. = But the model certainly supports it in low volume. And as described furth= er below, this seems, from my point of view, to be a rare, low volume, and = maybe even just a theoretical use case. I tried to further answer some of your peering how-to and what-if inquiries= below. Thanks ________________________________ From: Mickael Marrache [mailto:mickaelmarrache@gmail.com] Sent: Thursday, March 08, 2012 8:50 AM To: Cartwright, Ken; drinks@ietf.org Subject: Re: [drinks] SPPF changes proposal Hi Ken, 1) Maybe if you could provide/describe a new use case that the current mode= l does not support then the need for the proposal would be clearer. As I understood from a previous response (not this one), the User ENUM scen= ario consists of a set of subscribers of a certain SSP. Each of the subscri= ber provides a certain route specific to it that is then associated to its = telephone number. So, the registrant SSP adds the concerned PIs, the route = records and the associations between them. KJC: The associations between them are attributes of the PI, so there is n= ot a separate step required to create the PI and its association to a Route= Rec, furthermore, the protocol specifically allows PIs and Route Recs to b= e created/modified/deleted in a single request/transaction if that is deeme= d appropriate by the provisioning client. So this can all happen at once. Then, to share the route records associated to these PIs, the registrant SS= P groups the PIs in a DG, creates a RG, associates the DG to the RG and sha= res the RG to a peering organization. KJC: Again, it depends. The flow can occur that way, but it is unlikely t= hat it will happen that way, as a multi-step process. More likely is that = the provisioning client will have created the DG(s) and the RG(s) at some p= revious time. And as new TNs are brought active they are just provisioned = in, "into" that DG. So it is effectively a one step process as new TNs are= brought active. Optionally, the RG may have route records associated to it. What is the mea= ning of these routes? KJC: I don't understand the question, it seems so basic that I must misund= erstand. If the routes corresponding to each PI are shared, the peering organization= can establish sessions directly to these PIs? Do you mean these are genera= l routes that may be used to establish sessions to these PIs through the re= gistrant SSP network? KJC: Maybe, maybe not. It all depends on who the registrant is and whethe= r they have a network, who the registrant is and whether they have a networ= k, etc, etc. You're asking about all the difference use cases of how calls= are routed using SIP and ENUM, and how other data about TNs is looked up a= nd used? Is there any case where a SSP would be interested to share only one PI to a= nother SSP ? KJC: That would certainly be quite unusual. If yes, the current model requires creating a DG and a RG to enable peering= of the single PI. KJC: I've never seen the need for that arise in the real world. And while= it is certainly theoretically possible, it is, by definition, a very an un= usual, low volume case. So the model supports it, if it were to arise. Bu= t even the proposed changes do not support that use case notably better tha= n the current model. The proposed model just adds another grouping mechani= sm and then proposes using that second grouping mechanism. I'm just thinking about the way of finding a generic model that is not buil= t for specific needs, and I think the proposed model is not so different th= at the current one, the main change concerns introduction of an abstraction= layer to deal with single elements and groups of elements as a single unit= . KJC: I don't agree with the characterizations in the above statement, "gen= eric", "specific needs". 2) In the current model the Route Recs associated to a Route Group are inte= nded to be applicableTo/appropriateFor multiple/many PIs. A Route Rec dire= ctly associated to a PI is intended to be applicableTo/appropriateFor just = that PI (e.g. contain PI specific info such as in user ENUM). Given that, = why would we also want the Route Recs that are directly associated to a PI = to be part of a named group, so that they could be easily associated to mul= tiple/many PIs. The proposed model doesn't force you to group route records directly associ= ated to a PI. You may associate the PI with each route record separately. T= hen, if a registrant SSP wants to share these route records to a peering or= ganization, it may group them in an association group and share this group. 3) And in regards to your statement... "Also, I didn't get an answer concer= ning the possibility to associate a single TNR, TNP or RN directly to one o= r more route records. Would we add also a direct association from RN, TNR o= r TNP to route record?" Sorry, but I guess I missed that question in your = original email. I'm not fully clear on the question, but I think it may be= answered by understanding point 2 above. This is the same scenario as for the TN but this is not supported by the cu= rrent draft since the list of directly associated route records is defined = in the TN type and not in the PubIdType. What I mean is that we may have a = single RN, TNR or TNP associated to one or more PIs directly. And in this c= ase, why also to use grouping elements when they are not necessary? KJC: I can't agree that the grouping mechanism is not necessary for RNs, T= NRs, or TNPs. Many hundreds and thousands for those things are often given= the same routes for one or more given SSPs. Mickael On Wed, Mar 7, 2012 at 1:26 AM, Cartwright, Ken > wrote: Sorry, typo in item 2, it should read 2) In the current model the Route Recs associated to a Route Group are inte= nded to be applicableTo/appropriateFor multiple/many PIs. A Route Rec dire= ctly associated to a PI is intended to be applicableTo/appropriateFor just = that PI (e.g. contain PI specific info such as in user ENUM). Given that, = why would we also want the Route Recs that are directly associated to a PI = to be part of a named group, so that they could be easily associated to mul= tiple/many PIs. ________________________________ From: drinks-bounces@ietf.org [mailto:drink= s-bounces@ietf.org] On Behalf Of Cartwright= , Ken Sent: Tuesday, March 06, 2012 5:55 PM To: Mickael Marrache; drinks@ietf.org Subject: Re: [drinks] SPPF changes proposal Hi Mickael, 1) Maybe if you could provide/describe a new use case that the current mode= l does not support then the need for the proposal would be clearer. 2) In the current model the Route Recs associated to a Route Group are inte= nded to be applicableTo/appropriateFor multiple/many PIs. A Route Rec dire= ctly associated to a PI is intended to be applicableTo/appropriateFor just = that PI (e.g. contain PI specific info such as in user ENUM). Given that, = why would we also want the PIs that are directly associated to a PI to be p= art of a named group, so that they could be easily associated to multiple/m= any PIs. 3) And in regards to your statement... "Also, I didn't get an answer concer= ning the possibility to associate a single TNR, TNP or RN directly to one o= r more route records. Would we add also a direct association from RN, TNR o= r TNP to route record?" Sorry, but I guess I missed that question in your = original email. I'm not fully clear on the question, but I think it may be= answered by understanding point 2 above. Ken ________________________________ From: Mickael Marrache [mailto:mickaelmarrache@gmail.com] Sent: Saturday, March 03, 2012 12:55 PM To: Cartwright, Ken; drinks@ietf.org Subject: Re: [drinks] SPPF changes proposal Hi Ken, "To meet the requirements deduced from the user ENUM use case, a direct ass= ociation between the TN and route record types has been added" KJC: Nothing has been "added", the data model has been this way for at lea= st two years now. You're right. Sorry for saying something I didn't check. "So, one solution is to include these route records in a dummy (since the i= ncluded route records have not common routes) destination group DG-1. Then,= we also create a dummy (since it doesn't contain any route) route group RG= -1 and associate it to DG-1. Then, the route group may be offered to a peer= ing organization." KJC: The Destination Group and the Route Group you refer to as "Dummys", ar= e not "Dummys" they are an integral and expected part of the data structure= . "First, since the destination group DG-1 and the route group RG-1 are not u= sed for their primary reason (a destination group allows grouping of public= identifiers that share a common set of routes, and a route group is genera= lly used to group route records that may correspond to a same "destination"= - that's why we share them as a block), it reveals a potential design issu= e." KJC: The Route Group you refer to as "not contain any route rec" is not ac= curate. It may or may not contain Route Recs. It is up to the registrant = and registrar to decide whether they wish to have route recs on a given rou= te group, regardless of whether they have also decided to have Route Recs d= irectly associated with a PI (i.e. in the user ENUM case, where some PIs wi= ll/may have Route Recs that contain info that is specific to that PI). The= model allows both, depending on the Registrar's Registrant's need. So, the route group may or may not contain route records. If it doesn't contain route records, I understand that it is only used to s= hare the route records directly associated to the PIs. In this case, do you= agree that it is not a real route group (i.e. a construct that allows regr= ouping route records that correspond to a same destination)? If it does contain route records, I understand that it plays two roles: it = allows sharing the route records directly associated to the PIs as previous= ly, and it allows sharing the route records that correspond to a same desti= nation. KJC: The Destination Group and Route Groups involved here _do_ in fact ser= ve the purpose that they are designed to serve. They allow the peering vis= ibility of large numbers of public identities and their routing information= to be controlled at an aggregate with just a few number of API calls, as a= pposed to millions (one per PI or Route Rec). They allow the Destination G= roup to be associated or disassociated to from one or more Route Group obje= cts in a single command as the need arises, they allow the Route Group to b= e offered/accepted in a single command, rather than one per route rec (whic= h there would be millions of in the User ENUM case) or one per PI. They Ro= ute Group allows further control of the visibility based on source-based ro= uting, and other routing selection algorithms that, at this time, would be = vendor specific since they are not in the protocol (e.g. time-of-day, cost,= etc). In the proposed model, this property is still true. It also allows the peer= ing visibility of a large number of public identifiers and their routing in= formation also using an aggregate (you will note that we didn't remove the = destination and route groups constructs) with a few number of API calls. An= d I disagree when you say that the proposed model requires offering to be d= one per route in the user ENUM case. When a huge number of PIs are associat= ed to route records directly (though a RoutingAssoc element), you are not f= orced to offer each one of these associations, you simply need to regroup t= hem in an association group and to share this association group, I don't se= e here any scalability issue. Also, source based routing is also present in the proposed data model, in t= he ShareableElement type. "In this case, when an originating SSP wants to know the routes records ass= ociated to TN 1 for example...." KJC: The second paragraph in your note attempts to describe part of the re= solution process, I've included the first part of your statement above. It= basically says that the resolution process is somehow different if Route R= ecs are directly associated with the PI than if they are associated with th= e Route Group. This is not accurate. First off, SPPP does not attempt to = define how resolution servers must evaluate the data that SPP provisions. = Doing so would be folly, since TN resolution logic is much too involved, an= d often situation specific, including looking at data sources that do not e= ven come in over SPPP (e.g. portability data, etc, etc). However, the basi= c logic involves (1) using the lookup key (e.g. a TN) and the source of the= query to get the Destination Groups that contain that lookup key that are = visible to that source based on the Route Groups that that source has accep= ted (or auto-accepted), (2) collecting the Route Recs that are on the Route= Group(s) if any and/or the PI if any, (3) evaluating the Route Recs based = on their priority (and other vendor specific resolution logic, which the pr= otocol does not attempt to specify), then sending the collected Route Recs = out in the resolution response. Notice that there are not two different fl= ows. My comment for this point is related to the fact that a route group plays t= he two roles mentioned previously. Playing what I call the basic role (regr= ouping route records corresponding to the same destination) and the disturb= ing role (allowing offer for route records directly associated to PIs) is s= imply not intuitive. And, that's why David qualified this role as a hack. I= t's not a derision for the current model, it is simply the fact that there = is something that is at the wrong place. Also, I didn't get an answer concerning the possibility to associate a sing= le TNR, TNP or RN directly to one or more route records. Would we add also = a direct association from RN, TNR or TNP to route record? KJC: But from a bigger picture perspective, when the proposal was brought = up yesterday, it was brought up under the guise that "the current data mode= l is broken and it a hack in this area, so we need to do X, Y and Z". This= is simply not accurate, as I've described above. Secondly, the proposed a= lternative simply does not work in terms of scalability for the User ENUM u= se case. The proposal would result in millions of Route Recs (since in the= user enum case the Route Recs contain PI specific data) having to be offer= ed and accepted. So even the primary target use case of the proposal just = does not work well. So given that the current model is not "broken" and is= not a "hack" and given that the new proposal does not scale for the user e= num use case, why add in the additional complexity that results from the ne= w proposal? At this point, I still don't understand why the proposed model is not accur= ate. I don't understand why millions of route records have to been offered = and accepted? I think grouping associations solves this problem. Please, ca= n you illustrate by a scenario or diagram (especially for the User ENUM use= case)? I just want to precise that my comments are not intended to create conflict= s in any manner especially when I see that it's late to raise such proposit= ions and that the draft will become soon a RFC. I'm just trying to add my e= fforts to this framework/protocol. Thanks Mickael ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_B4254E341B54864B92D28BC2138A9DC30314ECCC9CTNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_B4254E341B54864B92D28BC2138A9DC30314ECCC9CTNSMAILNAwin2_-- From alexander.mayrhofer@nic.at Thu Mar 22 01:04:00 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0242621F8587 for ; Thu, 22 Mar 2012 01:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.1 X-Spam-Level: X-Spam-Status: No, score=-9.1 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 623c3jvtCvdy for ; Thu, 22 Mar 2012 01:03:59 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id D86B621F856A for ; Thu, 22 Mar 2012 01:03:58 -0700 (PDT) Received: from nics-mail.sbg.nic.at ([10.17.175.2]) by mail.sbg.nic.at with XWall v3.47 ; Thu, 22 Mar 2012 09:03:57 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CD0802.54E3A870" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 22 Mar 2012 09:03:56 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B8352D1@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRAFT minutes of yesterday's DESIGN team call (2012-03-21) Thread-Index: Ac0IAh8g1+v1rl0PQTSaFDNNSqeITQ== From: "Alexander Mayrhofer" To: X-XWALL-BCKS: auto Subject: [drinks] DRAFT minutes of yesterday's DESIGN team call (2012-03-21) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 08:04:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0802.54E3A870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, please find attached the draft minutes of yesterday's design team meeting call. The design team will have a pre-meeting discussion round in Paris on Tue, Mar 29 at 6:30pm local time (location TDB). thanks, Alex ------_=_NextPart_001_01CD0802.54E3A870 Content-Type: text/plain; name="drinks-call-2012-03-21.txt" Content-Transfer-Encoding: base64 Content-Description: drinks-call-2012-03-21.txt Content-Disposition: attachment; filename="drinks-call-2012-03-21.txt" DQpEUklOS1MgZGVzaWduIHRlYW0gY2FsbA0KPT09PT09PT09PT09PT09PT09PT09PT0NCg0KTWFy IDIxIDIwMTIsIDEwYW0tMTFhbSBFU1QgKDNwbS00cG0gQ0VUKQ0KDQpQYXJ0aWNpcGFudHMNCi0t LS0tLS0tLS0tLQ0KDQpTdW1hbnRoDQpBbGV4DQpWaWthcyANCkRhdmlkDQoNCkFjdGlvbiBpdGVt IHJldmlldzoNCi0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhlIGdyb3VwIHJldmlld2VkIHdoZXRo ZXIgaW5kaXZpZHVhbCBhY3Rpb24gaXRlbXMgd2VyZSBhZGRyZXNzZWQgaW4gdGhlDQpsYXRlc3Qg cmV2aXNpb24gb2YgdGhlIGRvY3VtZW50cy4gVGhlIHN0YXR1cyBvZiB0aGUgaXRlbXMgaXMgYXMg Zm9sbG93czoNCg0KKGFsc28gc2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9kcmlua3MvY3VycmVudC9tc2cwMTExNC5odG1sLA0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL2RyaW5rcy9jdXJyZW50L21zZzAxMTM2Lmh0bWwpDQoNCkFJLTEgKEFkZHJl c3MgRGlhZ3JhbSBJbmNvbnNpc3RlbmNpZXMpOiBkb25lDQoNCkFJLTIgKEludmVzdGlnYXRlIFJv dXRlIGdyb3VwIG9mZmVyIGdlbmVyYWxpemF0aW9uKTogRGF2aWQgd2lsbCBtYWtlIGEgcHJvcG9z YWwNCg0KQUktMyAoUHJvcG9zZSB0ZXh0IGFib3V0IHN0cnVjdHVyZSBvZiBub24tbnVtZXJpYyBQ SSk6IHdhcyBpbmNvcnBvcmF0ZWQNCg0KQUktNCAoVE5UeXBlIHRvIFJ0ZVJlY1JlZlR5cGUgcG9p bnRlcjogcmVjb25zaWRlcik6IGNsb3NlZA0KDQpBSS01IChSZW1vdmUgcHJpb3JpdHkgZnJvbSBS dGVSZWNCYXNlVHlwZSk6IGRvbmUNCg0KQUktNiAoQWxzbyBhZGQgaXNpbnNlcnZpY2UgZmxhZyBv biBSdGVSZWNCYXNlVHlwZSk6IGRvbmUNCg0KQUktNyAoTW92ZSB1cCAidHRsIiBmaWVsZCB0byBi YXNlIHJvdXRlIHJlYyB0eXBlKTogZG9uZQ0KDQpBSS04IChSZWNvbnNpZGVyICJleHRlbnNpb24i IG9wdGlvbnMgd2l0aCBuZXcgaW5mbyk6IHNvbHZlZA0KDQpBSS05IChDb25zaWRlciBhZGRpbmcg InNlcnZpY2UiIGZpZWxkIHRvIEVncmVzcyBSb3V0ZSk6IHJld29yZCB0byAiZGlzY3VzcyByb3V0 ZSBydWxlIHRleHQiDQoNCkFJLTEwIChEaXNjdXNzIG9uIG1haWxpbmcgbGlzdCBob3cgcmVnaXN0 cnkgaGFuZGxlcyBiYXRjaGVzKTogY2xvc2VkDQoNCkFJLTExIChSZXZpZXcgU2VjdXJpdHkgQ29u cyBzZWN0aW9uKTogY2xvc2VkDQoNCkFJLTEyIChPcmdhbml6ZSBlYXJseSBleHBlcnQgcmV2aWV3 IG9mIFNlY3VyaXR5IENvbnMgc2VjdGlvbik6IHRvIGJlIGRvbmUNCg0KQUktMTNhIChFcnJvciBt ZXNzYWdlIGxlbmd0aCBsaW1pdGF0aW9uKTogZG9uZQ0KQUktMTNiIChEb1MgcmlzayBvZiBiYXRj aCBvcGVyYXRpb25zKTogIEplcmVteSB0byBwcm92aWRlIHRleHQNCkFJLTEzYyAoQ2xhcmlmeS9y ZW1vdmUgZGVmaW5pdGlvbiBvZiB0cmFuc2FjdGlvbiBpZCB0eXBlKTogZG9uZQ0KDQpBSS0xNCAo RXZhbHVhdGUgd2hldGhlciB0byBleHBhbmQgIkR0bCIgYW5kIG1ha2UgVHlwZSBuYW1lcyANCmNv bnNpc3RlbnQpOiBkb25lDQoNCkFJLTE1IChBZGQgbWF4IGxlbmd0aCB0byByZXN1bHQgY29kZS9t ZXNzYWdlIGRlZmluaXRpb24pOiBkb25lDQoNCkFJLTE2IChDbGFyaWZ5IGJlaGF2aW91ci9leHBp cmF0aW9uIG9mIG9mZmVycywgaW5jbHVkZSBhIGxpZmVjeWNsZQ0KRGlhZ3JhbT8pOiBvcGVuDQoN CkFJLTE3IChJbnRlcm5hdGlvbmFsaXphdGlvbi9Db21wYXJpc29uIE9wcyk6IG9wZW4gYXMgd2Vs bA0KDQpBSS0xOCAoRW5zdXJlIGludGVybmFsIGNvbnNpc3RlbmN5IG9uIHRlcm1pbm9sb2d5IGFu ZCBzdHJ1Y3R1cmUpOiBsb29rIGF0IHRoZSBsYXRlc3QgZG9jdW1lbnRzLCBhbmQgcmUtY2hlY2sN Cg0KQUktMTkgKENsYXJpZnkgdW5pcXVlbmVzcyBvZiBvYmplY3QtdHlwZSBuYW1lcyk6IGRvbmUN Cg0KDQpEYXZpZCBub3RlcyB0aHJlZSBvdGhlciBvcGVuIHRoaW5ncyBmcm9tIGhpcyBwZXJzcGVj dGl2ZToNCg0KIC0gb2ZmZXIgZ2VuZXJhbGl6YXRpb24sIA0KIC0gcm91dGUgcnVsZXMsIA0KIC0g YXR0cmlidXRlIHN0cnVjdHVyZQ0KDQpQYXJpcyBtZWV0aW5nDQotLS0tLS0tLS0tLS0tDQoNClRo ZXJlIHdpbGwgYmUgYSBwcmUtbWVldGluZyBkaXNjdXNzaW9uIHJvdW5kIHRha2luZyBwbGFjZSBv biBUdWUsIE1hciAyNywgDQo2OjMwcG0gbG9jYWwgdGltZSBQYXJpcy4gTG9jYXRpb24gVEJELiBT aW5jZSB0aGUgbWVldGluZyBzbG90IGlzIGp1c3Qgb25lDQpob3VyLCBvcGVuIGlzc3VlcyBzaG91 bGQgYmUgZGlzY3Vzc2VkIGJlZm9yZSBpbiBvcmRlciB0byBzYXZlIG1lZXRpbmcgdGltZS4NCg0K UHJlc2VudGF0aW9uczogU3llZCBtaWdodCBiZSB0aGUgY2FuZGlkYXRlIGZvciB0aGUgcHJlc2Vu dGF0aW9ucywgYWx0aG91Z2ggDQpWaWthcyB2b2x1bnRlZXJlZCB0byBkbyB0aGVtIHJlbW90ZWx5 IGFzIHdlbGwuDQoNCg== ------_=_NextPart_001_01CD0802.54E3A870-- From dean.willis@softarmor.com Wed Mar 28 06:47:26 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA3D21E8165 for ; Wed, 28 Mar 2012 06:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.723 X-Spam-Level: X-Spam-Status: No, score=-102.723 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 pPQk0rQfklLD for ; Wed, 28 Mar 2012 06:47:25 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37C4021E80CB for ; Wed, 28 Mar 2012 06:47:25 -0700 (PDT) Received: by ggmi1 with SMTP id i1so763378ggm.31 for ; Wed, 28 Mar 2012 06:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=Cw9TfmGqeE5k5+9ElyN5fXcq7noIra/lzf/q2LGk0y0=; b=PzqrQ94d0D9AWJt9rNUiXElNExFzI7RK6BioX/w6Qf5KGKIHtjGkaZNzLqpDqTNlbz lpsKMX7GEYE5LSProStmE7nMPoD8CnHGmx8XsmTBA28uHXHH/5kI92C8LMQWLAu9EdLQ +TI1sjJK+3H1ktbFR0YUHG2Bhz7WJmBbMLOfw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=Cw9TfmGqeE5k5+9ElyN5fXcq7noIra/lzf/q2LGk0y0=; b=TP+w4aribfUO06wxZCDq8TRoTQE3xQBdhWfbtPxUbiaOYvtX6U1q21zzLgeSfwZiJ9 h5EiKdlddPEIuhjY18XPn+v2kT/4/T/B+h2qTtm2b6eY0G0Qa0JfD0D85cQ8Oafz4SC6 WGSc7JTD++2XSvU2PZTlNe1ztRSG1t1r3EaC60hibrZDbGnDDlQB+t5hBc5NvBya7IRC HDIluBEkEAW/IGa3MGf5frP8ab33yMZchJh6sSqQwXJqmCaKxzvzAWURoNBGdXpPNkZk Nqm8OWNlk1BLQQzqefG4Tvr2IvcWDoqDh1oHjU1pCxISABVFtSWVddG96iHVz7L32DSe cSgQ== MIME-Version: 1.0 Received: by 10.68.194.39 with SMTP id ht7mr71785219pbc.31.1332942444412; Wed, 28 Mar 2012 06:47:24 -0700 (PDT) Received: by 10.68.9.104 with HTTP; Wed, 28 Mar 2012 06:47:24 -0700 (PDT) Date: Wed, 28 Mar 2012 15:47:24 +0200 Message-ID: From: Dean Willis To: drinks@ietf.org Content-Type: multipart/alternative; boundary=047d7b15aeb5e7c0b504bc4dd85b X-Gm-Message-State: ALoCoQm2waWzqarbrS2ltyy+STUVbX8gLtWE7cHuVSXhn90EKeR6OkpU4lX7ru+LJH3x86GMsdFO Subject: [drinks] Feedback on drafts X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:47:26 -0000 --047d7b15aeb5e7c0b504bc4dd85b Content-Type: text/plain; charset=ISO-8859-1 I reread our drafts earlier today and have a few nits. Framework doc 3.1 Def 1 has gibberish "comprises of" Def of "peering organization" is unsatisfying. Is it another registrant? Maybe the problem is in the definition of registrant, which doesn't say a rant isa/isnota organization. One has to dig into 5.1 for this to get clear. 4.4 "provisions" should be singular. With 4.5, relation between rar, rant, and auth is unclear. 4.7 near real time needs further explanation. Fast enough to do a lookup while completing a call? 4.8 data set should be plural 5.2.2 the para starting "A Route Group Offer". The "Refer" needs a "To". Check all instances of "refer" in doc as the style used is consistently inconsistent with US technical English. 6.5 RteGrpOfferKeyType has spelling error "specificaiton". 6.6 first sentence "paths" should be singular. SOAP Doc 5. Needs to tell us the product of authentication; that is the identity of the rar to be used with the unspecified rar/rant authorization table. 6.2.1.1 stop/rollback discussion should make reference to how we tell the requester which mechanism will be or was applied. 9. Are the example SSPs acting as registrars? Registrants? Security Considerations are in general weak. There is no discussion of actors, intent, or vectors. I remain perplexed by the peering model. All we have is a model of grant/accept for authorization to make records visible. There is a lot more to peering. --047d7b15aeb5e7c0b504bc4dd85b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I reread our drafts earlier tod= ay and have a few nits.


Framework d= oc

3.1 Def 1 has gibberish "comprises of"= ;

Def of "peering organization" is unsatisfying= . Is it another registrant? Maybe the problem is in the definition of regis= trant, which doesn't say a rant isa/isnota =A0organization. One has to = dig into 5.1 for this to get clear.

4.4 "provisions" should be singular.

With 4.5, relation between rar, rant, and auth is unclear.=

4.7 near real time needs further explanation. Fas= t enough to do a lookup while completing a call?

4.8 data set should be plural

= 5.2.2 the para starting "A Route Group Offer". The "Refer&qu= ot; needs a "To".=A0Check = all instances of "refer" in doc as the style used is consistently= inconsistent with US technical English.

6.5 =A0RteGrpOfferKeyType has spelling error = "specificaiton".

6.6 first sentence= "paths" should be singular.


SOAP Doc

5. Needs to tell us the product of authent= ication; that is the identity of the rar to be used with the unspecified ra= r/rant authorization table.

6.2.1.1 stop/rollback discussion should make = reference to how we tell the requester which mechanism will be or was appli= ed.

9. Are the example SSPs acting as registrars?= Registrants?

<= /span>
Security Considerations are in = general weak. There is no discussion of actors, intent, or vectors.<= /div>


I remain perplexed by the peering m= odel. All we have is a model of grant/accept for authorization to make reco= rds visible. There is a lot more to peering.
--047d7b15aeb5e7c0b504bc4dd85b-- From sumanth@cablelabs.com Wed Mar 28 12:07:07 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D2721E8217 for ; Wed, 28 Mar 2012 12:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 76yhYhZUo5jH for ; Wed, 28 Mar 2012 12:07:06 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA3321E80DF for ; Wed, 28 Mar 2012 12:07:03 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q2SJ72aM027454 for ; Wed, 28 Mar 2012 13:07:02 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 28 Mar 2012 13:07:02 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 28 Mar 2012 13:07:02 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Importance: high X-Priority: 1 Date: Wed, 28 Mar 2012 13:06:58 -0600 Thread-Topic: DRINKS WG meeting tomorrow -- Mar 29, Thu, from 3:20p-5:20p! Thread-Index: Ac0NFeaIKYDil24iTFCLXAeCjYRymQ== Message-ID: <76AC5FEF83F1E64491446437EA81A61F8F2BCBAC00@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F8F2BCBAC00srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] DRINKS WG meeting tomorrow -- Mar 29, Thu, from 3:20p-5:20p! X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 19:07:07 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F8F2BCBAC00srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We hope to see you all at the DRINKS WG meeting tomorrow afternoon from 3:2= 0p-5:20p (location: 212/213)! For those joining us remotely, the Meetecho l= ink is: http://www.meetecho.com/ietf83/drinks Also, we have posted a revised agenda (based on feedback), and uploaded the= slide decks that we have received so far. Link to the revised agenda: * http://tools.ietf.org/wg/drinks/agenda?item=3Dagenda-83-drinks.ht= ml Link to meeting materials: * https://datatracker.ietf.org/meeting/83/materials.html (search fo= r DRINKS) Specifically, two additions were made to the agenda: -- 5/ Open Items Discussion (45 mts) A) SPPF Batch DOS Considerations (Jeremy Barkan) B) Route Rule Type (David Schwartz) C) Route group offer generalization (David Schwartz) D) Others? 6/ Coin's (coin.nl) plans for using ENUM data for routing telecom= services between networks (10 mts; Theo van den Berg, Stefphen Mans) -- - Alex & Sumanth --_000_76AC5FEF83F1E64491446437EA81A61F8F2BCBAC00srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

We hope= to see you all at the DRINKS WG meeting tomorrow afternoon from 3:20p-5:20= p (location: 212/213)! For those joining us remotely, the Meetecho link is:=

http://www.meetecho.com/ietf83/drinks

 

 <= /p>

Also, we have posted a revised agenda (based on fee= dback), and uploaded the slide decks that we have received so far.

 

Li= nk to the revised agenda:

·     &nbs= p;   http://tools.ietf.org/wg= /drinks/agenda?item=3Dagenda-83-drinks.html

 

 

Link to meeting materials:

·  = ;       https://datatr= acker.ietf.org/meeting/83/materials.html (search for DRINKS)=

 

&nb= sp;

Specifically, two additions were made to = the agenda:

 

--

    = ;     5/ Open Items Discussion (45 mts)

<= p class=3DMsoNormal>         &= nbsp;   A) SPPF Batch DOS Considerations (Jeremy Barkan)

        =      B) Route Rule Type (David Schwartz)

=

         =     C) Route group offer generalization (David Schwartz)

        =      D) Others?

 

     &= nbsp;    6/ Coin's (coin.nl) plans for using ENUM data for r= outing telecom services between networks (10 mts; Theo van den Berg, Stefph= en Mans)

 

--

 

- Alex & Sumanth

<= o:p> 

= --_000_76AC5FEF83F1E64491446437EA81A61F8F2BCBAC00srvxchg_-- From ietf@meetecho.com Wed Mar 28 22:48:17 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8AB21E8015 for ; Wed, 28 Mar 2012 22:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 6kod4yANNqhs for ; Wed, 28 Mar 2012 22:48:16 -0700 (PDT) Received: from smtplq02.aruba.it (smtplqs-out28.aruba.it [62.149.158.68]) by ietfa.amsl.com (Postfix) with SMTP id 2C19E21E8048 for ; Wed, 28 Mar 2012 22:48:15 -0700 (PDT) Received: (qmail 16662 invoked by uid 89); 29 Mar 2012 05:48:13 -0000 Received: from unknown (HELO smtp1.aruba.it) (62.149.158.221) by smtplq02.aruba.it with SMTP; 29 Mar 2012 05:48:13 -0000 Received: (qmail 28719 invoked by uid 89); 29 Mar 2012 05:48:13 -0000 Received: from unknown (HELO ?192.168.0.40?) (alex@meetecho.com@78.192.151.119) by smtp1.ad.aruba.it with ESMTPA; 29 Mar 2012 05:48:13 -0000 Message-ID: <4F73F796.2070802@meetecho.com> Date: Thu, 29 Mar 2012 07:48:06 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: drinks@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: [drinks] Meetecho support for DRINKS WG meeting session X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 05:48:18 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Thursday's DRINKS WG meeting session. Access to the on-line session (including audio and video streams) will be available at: http://www.meetecho.com/ietf83/drinks The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room, if they want to, by either calling a landline phone number, or using our embedded VoIP applet (in this last case they are *strongly* advised to use a headset). A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf83/tutorials Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From sumanth@cablelabs.com Thu Mar 29 09:14:14 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC6B21E8238 for ; Thu, 29 Mar 2012 09:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 8yg8lQTV+jnA for ; Thu, 29 Mar 2012 09:14:14 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5F68E21F880D for ; Thu, 29 Mar 2012 09:14:14 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q2TGE9d4004689 for ; Thu, 29 Mar 2012 10:14:09 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 29 Mar 2012 10:14:09 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 29 Mar 2012 10:14:09 -0600 From: Sumanth Channabasappa To: "drinks@ietf.org" Date: Thu, 29 Mar 2012 10:14:09 -0600 Thread-Topic: Draft minutes Thread-Index: AQHNDcb43ucOb7deXECqXzr3DByIZw== Message-ID: <76AC5FEF83F1E64491446437EA81A61F8F2BCAD2CB@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Draft minutes X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:14:15 -0000 Folks, Thanks again to everyone who participated today (in-person or remotely)! Ou= r volunteer note-taker's (Brian Rosen - many thanks!) draft notes can be f= ound at: http://tools.ietf.org/wg/drinks/minutes=20 Please feel free to make corrections or changes directly. Alex and I will c= urate it in the upcoming days.=20 Also, sorry about the challenges with remote participation - not having a w= ired connection made for a bad connection.=20 - S=20

Hi Mickael,

 

So is the new use case the “Want= to be able to peer a single PI with a single SSP, in high volume?, Iow wan= t to support many many one-to-one relationships between PIs and peering SSPs”.  If so, then that = is certainly not a use case that we ever worked toward, or documented in th= e use case document.  But the model certainly supports it in low volum= e.  And as described further below, this seems, from my point of view, to be a rare, low volume, and maybe even just a the= oretical use case.

 

I tried to further answer some of your= peering how-to and what-if inquiries below.

 

Thanks

 

 

From: Mick= ael Marrache [mailto:mickaelmarrache@gmail.com]
Sent: Thursday, March 08, 20= 12 8:50 AM
To: Cartwright, Ken; drinks@ietf.org
Subject: Re: [drinks] SPPF c= hanges proposal

 

Hi Ken,

1) Maybe if you could provide/describe= a new use case that the current model does not support then the need for t= he proposal would be clearer.


As I understood from a previous response (not this one), the User ENUM scen= ario consists of a set of subscribers of a certain SSP. Each of the subscri= ber provides a certain route specific to it that is then associated to its = telephone number. So, the registrant SSP adds the concerned PIs, the route records and the associations between= them.

KJC:  The associations between them are attributes of the= PI, so there is not a separate step required to create the PI and its association to a Route Rec, furthermore, the protoco= l specifically allows PIs and Route Recs to be created/modified/deleted in = a single request/transaction if that is deemed appropriate by the provision= ing client.  So this can all happen at once.

Then, to share the ro= ute records associated to these PIs, the registrant SSP groups the PIs in a= DG, creates a RG, associates the DG to the RG and shares the RG to a peering organization.

KJC:  Again, it depends.  The flow can occur that wa= y, but it is unlikely that it will happen that way, as a multi-step process.  More likely is that the provisioning client wi= ll have created the DG(s) and the RG(s) at some previous time.  And as= new TNs are brought active they are just provisioned in, “into”= ; that DG.  So it is effectively a one step process as new TNs are brought active.

Optionally, the RG ma= y have route records associated to it. What is the meaning of these routes?=

KJC:  I don’t understand the question, it seems so = basic that I must misunderstand.

If the routes corresp= onding to each PI are shared, the peering organization can establish sessio= ns directly to these PIs? Do you mean these are general routes that may be used to establish sessions to these PIs thr= ough the registrant SSP network?

KJC:  Maybe, maybe not.  It all depends on who the r= egistrant is and whether they have a network, who the registrant is and whether they have a network, etc, etc.  You’r= e asking about all the difference use cases of how calls are routed using S= IP and ENUM, and how other data about TNs is looked up and used?=


Is there any case where a SSP would be interested to share only one PI to a= nother SSP ?

KJC:  That would certainly be quite unusual.

If yes, the current m= odel requires creating a DG and a RG to enable peering of the single PI.

KJC:  I’ve never seen the need for that arise in th= e real world.  And while it is certainly theoretically possible, it is, by definition, a very an unusual, low volume case.  = So the model supports it, if it were to arise.  But even the proposed = changes do not support that use case notably better than the current model.=  The proposed model just adds another grouping mechanism and then proposes using that second grouping mechanism.

I'm just thinking abo= ut the way of finding a generic model that is not built for specific needs,= and I think the proposed model is not so different that the current one, the main change concerns introduction of a= n abstraction layer to deal with single elements and groups of elements as = a single unit.

KJC:  I don’t agree with the characterizations in t= he above statement, “generic”, “specific needs”.

2) In the current model the Route Recs= associated to a Route Group are intended to be applicableTo/appropriateFor= multiple/many PIs.  A Route Rec directly associated to a PI is intended to be applicable= To/appropriateFor just that PI (e.g. contain PI specific info such as in us= er ENUM).  Given that, why would we also want the Route Recs that are = directly associated to a PI to be part of a named group, so that they could be easily associated to multiple/many PI= s.


The proposed model doesn't force you to group route records directly associ= ated to a PI. You may associate the PI with each route record separately. T= hen, if a registrant SSP wants to share these route records to a peering or= ganization, it may group them in an association group and share this group.

3) And in regards to your statement… “Also, I didn't get an answer concerning the possibility to associate a single TN= R, TNP or RN directly to one or more route records. Would we add also a dir= ect association from RN, TNR or TNP to route record?”  Sorry, but I guess I missed= that question in your original email.  I’m not fully clear on t= he question, but I think it may be answered by understanding point 2 above.


This is the same scenario as for the TN but this is not supported by the cu= rrent draft since the list of directly associated route records is defined = in the TN type and not in the PubIdType. What I mean is that we may have a = single RN, TNR or TNP associated to one or more PIs directly. And in this case, why also to use grouping el= ements when they are not necessary?

 

KJC:  I can’t a= gree that the grouping mechanism is not necessary for RNs, TNRs, or TNPs. &= nbsp;Many hundreds and thousands for those things are often given the same routes for one or more given SSPs.=


Mickael




On Wed, Mar 7, 2012 at 1:26 AM, Cartwright, Ken <kcartwright@tnsi.com> wrote:

Sorry, typo in item 2, it should read

2) In the current model the Route Recs associated to a Route Gr= oup are intended to be applicableTo/appropriateFor multiple/many PIs.  A Route Rec dir= ectly associated to a PI is intended to be applicableTo/appropriateFor just= that PI (e.g. contain PI specific info such as in user ENUM).  Given = that, why would we also want the Route Recs that are directly associated to a PI to be part of a named group, so that = they could be easily associated to multiple/many PIs.

 

From: drinks-bounces= @ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Cartwright, Ken=
Sent: Tuesday, March 06, 201= 2 5:55 PM
To: Mickael Marrache; drinks@ietf.org


Subject: Re: [drinks] SPPF c= hanges proposal

 

Hi Mickael,

 

1) Maybe if you could provide/describe a new use case that the = current model does not support then the need for the proposal would be clearer.

 

2) In the current model the Route Recs associated to a Route Gr= oup are intended to be applicableTo/appropriateFor multiple/many PIs.  A Route Rec dir= ectly associated to a PI is intended to be applicableTo/appropriateFor just= that PI (e.g. contain PI specific info such as in user ENUM).  Given = that, why would we also want the PIs that are directly associated to a PI to be part of a named group, so that they = could be easily associated to multiple/many PIs.

 

3) And in regards to your statement… “Also, I didn't get an answer concerning the possibility to associate a single TN= R, TNP or RN directly to one or more route records. Would we add also a dir= ect association from RN, TNR or TNP to route record?”  Sorry, but I guess I missed= that question in your original email.  I’m not fully clear on t= he question, but I think it may be answered by understanding point 2 above.

Ken

 

From: Mickael Marrache [mailto:mickaelmarrache@gmail.com]
Sent: Saturday, March 03, 20= 12 12:55 PM
To: Cartwright, Ken; drinks@ietf.org
Subject: Re: [drinks] SPPF c= hanges proposal

 

Hi Ken,

“To meet the requirements deduced from the = user ENUM use case, a direct association between the TN and route record types has been added&= #8221;

KJC:  Nothing has been “added”, the data model= has been this way for at least two years now.


You're right. Sorry for saying something I didn't check.  <= /span>

 

“So, one solution is to include these route= records in a dummy (since the included route records have not common routes) destination grou= p DG-1. Then, we also create a dummy (since it doesn't contain any route) r= oute group RG-1 and associate it to DG-1. Then, the route group may be offe= red to a peering organization.”

 

KJC: The Destination Group and the Route Group you refer to as = “Dummys”, are not “Dummys” they are an integral and expected part of the dat= a structure.

 

“First, since the destination group DG-1 and the route group= RG-1 are not used for their primary reason (a destination group allows grouping of public identifiers that share a common set of rou= tes, and a route group is generally used to group route records that may co= rrespond to a same "destination" - that's why we share them as a = block), it reveals a potential design issue.”

 

KJC:  The Route Group you refer to as “not contain a= ny route rec” is not accurate.  It may or may not contain Route Recs.  It is up to the registrant and= registrar to decide whether they wish to have route recs on a given route = group, regardless of whether they have also decided to have Route Recs dire= ctly associated with a PI (i.e. in the user ENUM case, where some PIs will/may have Route Recs that contain info = that is specific to that PI).  The model allows both, depending on the= Registrar’s Registrant’s need.

 

So, the route group may or may not contain route records.

If it doesn't contain route records, I understand that it is o= nly used to share the route records directly associated to the PIs. In this case, do y= ou agree that it is not a real route group (i.e. a co= nstruct that allows regrouping route records that correspond to a same dest= ination)?

If it does contain route records, I understand that it plays t= wo roles: it allows sharing the route records directly associated to the PIs as prev= iously, and it allows sharing the route records that correspond to a same d= estination.

 

 

KJC:  The Destination Group and Route Groups involved here= _do_ in fact serve the purpose that they are designed to serve.  They allo= w the peering visibility of large numbers of public identities and their ro= uting information to be controlled at an aggregate with just a few number o= f API calls, as apposed to millions (one per PI or Route Rec).  They allow the Destination Group to be associa= ted or disassociated to from one or more Route Group objects in a single co= mmand as the need arises, they allow the Route Group to be offered/accepted= in a single command, rather than one per route rec (which there would be millions of in the User ENUM case) or = one per PI.  They Route Group allows further control of the visibility= based on source-based routing, and other routing selection algorithms that= , at this time, would be vendor specific since they are not in the protocol (e.g. time-of-day, cost, etc).

 

In the proposed model, this property is still true. It also al= lows the peering visibility of a large number of public identifiers and their routing infor= mation also using an aggregate (you will note that we didn't remove the des= tination and route groups constructs) with a few number of API calls. And I= disagree when you say that the proposed model requires offering to be done per route in the user ENUM cas= e. When a huge number of PIs are associated to route records directly (thou= gh a RoutingAssoc element), you are not forced to offer each one of these a= ssociations, you simply need to regroup them in an association group and to share this association group, = I don't see here any scalability issue.

Also, source based routing is also present in the proposed dat= a model, in the ShareableElement type.

 

 

“In this case, when an originating SSP want= s to know the routes records associated to TN 1 for example….”

 

KJC:  The second paragraph in your note attempts to descri= be part of the resolution process, I’ve included the first part of your statement above. = It basically says that the resolution process is somehow different if Rout= e Recs are directly associated with the PI than if they are associated with= the Route Group.  This is not accurate.  First off, SPPP does not attempt to define how resolution servers must evaluate = the data that SPP provisions.  Doing so would be folly, since TN resol= ution logic is much too involved, and often situation specific, including l= ooking at data sources that do not even come in over SPPP (e.g. portability data, etc, etc).  However, the ba= sic logic involves (1) using the lookup key (e.g. a TN) and the source of t= he query to get the Destination Groups that contain that lookup key that ar= e visible to that source based on the Route Groups that that source has accepted (or auto-accepted), (2) collect= ing the Route Recs that are on the Route Group(s) if any and/or the PI if a= ny, (3) evaluating the Route Recs based on their priority (and other vendor= specific resolution logic, which the protocol does not attempt to specify), then sending the collected Rout= e Recs out in the resolution response.  Notice that there are not two = different flows.

 

My comment for this point is related to the fact that a route = group plays the two roles mentioned previously. Playing what I call the basic role (re= grouping route records corresponding to the same destination) and the distu= rbing role (allowing offer for route records directly associated to PIs) is= simply not intuitive. And, that's why David qualified this role as a hack. It's not a derision for the curre= nt model, it is simply the fact that there is something that is at the wron= g place.

Also, I didn't get an answer concerning the possibility to ass= ociate a single TNR, TNP or RN directly to one or more route records. Would we add also a = direct association from RN, TNR or TNP to route record?<= /o:p>

 

 

KJC:  But from a bigger picture perspective, when the prop= osal was brought up yesterday, it was brought up under the guise that “the current da= ta model is broken and it a hack in this area, so we need to do X, Y and Z&= #8221;.  This is simply not accurate, as I’ve described above.&n= bsp; Secondly, the proposed alternative simply does not work in terms of scalability for the User ENUM use case.  The proposal wou= ld result in millions of Route Recs (since in the user enum case the Route = Recs contain PI specific data) having to be offered and accepted.  So = even the primary target use case of the proposal just does not work well.  So given that the current model is not R= 20;broken” and is not a “hack” and given that the new pro= posal does not scale for the user enum use case, why add in the additional = complexity that results from the new proposal?

 

At this point, I still don't understand why the proposed model= is not accurate. I don't understand why millions of route records have to been offered and = accepted? I think grouping associations solves this problem. Please, can yo= u illustrate by a scenario or diagram (especially for the User ENUM use cas= e)?


I just want to precise that my comments are not intended to create conflict= s in any manner especially when I see that it's late to raise such proposit= ions and that the draft will become soon a RFC. I'm just trying to add my e= fforts to this framework/protocol.

Thanks

Mickael

 

This e-mail message is for the sole use of the intended recipie= nt(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 

This e-mail message is for the sole use of the intended recipie= nt(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 

Hi Ken,

=93To meet the = requirements deduced from the user ENUM use case, a direct association betw= een the TN and route record types has been added=94

KJC:=A0= Nothing has been =93added=94, the data model has been this way for at leas= t two years now.


You're right. Sorry for saying something I didn&#= 39;t check.=A0

=A0

=93So, one solution is to include these route records in a dummy (since the=20 included route records have not common routes) destination group DG-1. Then, we also create a dummy (since it doesn't= =20 contain any route) route group RG-1 and associate it to DG-1. Then, the=20 route group may be offered to a peering organization.=94

=A0

= KJC: The Destination Group and the Route Group you refer to as =93Dummys=94, ar= e not =93Dummys=94 they are an integral and expected part of the data structure.

=A0<= /p>

=93First, since the destination group DG-1 and the route group RG-1 are not used=20 for their primary reason (a destination group allows grouping of public=20 identifiers that share a common set of routes, and a route group is generally used to=20 group route records that may correspond to a same "destination" -= that's why we share them as a block), it reveals a potential design issue.=94

<= font color=3D"navy" face=3D"Arial">=A0

KJC:=A0 The Route Group you refer to as =93not contain any route rec=94 is not=20 accurate.=A0 It may or may not contain Route Recs.=A0 It is up to the registrant and registrar to decide whether they wish to have route=20 recs on a given route group, regardless of whether they have also=20 decided to have Route Recs directly associated with a PI (i.e. in the=20 user ENUM case, where some PIs will/may have Route Recs that contain info that is specific to that PI).=A0 The model allows= =20 both, depending on the Registrar=92s Registrant=92s need.

=

=A0

So, the route g= roup may or may not contain route records.

If it = doesn't contain route records, I understand that it is only used to sha= re the route records directly associated to the PIs. In this case, do you a= gree that it is not a real route group (i.e. a construct that allows= regrouping route records that correspond to a same destination)?

If it d= oes contain route records, I understand that it plays two roles: it allows = sharing the route records directly associated to the PIs as previously, and= it allows sharing the route records that correspond to a same destination.=



KJC:=A0 The Destination Group= and Route Groups involved here _do_ in fact serve the purpose that they are designed to serve. =A0They allow the peering visibility of= =20 large numbers of public identities and their routing information to be=20 controlled at an aggregate with just a few number of API calls, as=20 apposed to millions (one per PI or Route Rec). =A0They allow the Destination Group to be associated or disassociated to= =20 from one or more Route Group objects in a single command as the need=20 arises, they allow the Route Group to be offered/accepted in a single=20 command, rather than one per route rec (which there would be millions of in the User ENUM case) or one per PI. =A0They= =20 Route Group allows further control of the visibility based on=20 source-based routing, and other routing selection algorithms that, at=20 this time, would be vendor specific since they are not in the protocol (e.g. time-of-day, cost, etc).


In the proposed model, this pr= operty is still true. It also allows the peering visibility of a large numb= er of public identifiers and their routing information also using an aggreg= ate (you will note that we didn't remove the destination and route grou= ps constructs) with a few number of API calls. And I disagree when you say = that the proposed model requires offering to be done per route in the user = ENUM case. When a huge number of PIs are associated to route records direct= ly (though a RoutingAssoc element), you are not forced to offer each one of= these associations, you simply need to regroup them in an association grou= p and to share this association group, I don't see here any scalability= issue.

Also, s= ource based routing is also present in the proposed data model, in the Shar= eableElement type.



=93In this case, when an originating SSP= wants to know the routes records associated to TN 1 for example=85.=94

=A0

KJC:=A0 The second paragraph in your note attempts to describe part of the=20 resolution process, I=92ve included the first part of your statement above.=A0 It basically says that the resolution process is somehow=20 different if Route Recs are directly associated with the PI than if they are associated with the Route Group. =A0This is not accurate.=A0 First off= , SPPP does not attempt to define how resolution servers must evaluate the data that SPP provisions. =A0Doing so would be= =20 folly, since TN resolution logic is much too involved, and often=20 situation specific, including looking at data sources that do not even=20 come in over SPPP (e.g. portability data, etc, etc).=A0 However, the basic logic involves (1) using the lookup key (e.g. a TN)=20 and the source of the query to get the Destination Groups that contain=20 that lookup key that are visible to that source based on the Route=20 Groups that that source has accepted (or auto-accepted), (2) collecting the Route Recs that are on the Route Group(s) if any=20 and/or the PI if any, (3) evaluating the Route Recs based on their=20 priority (and other vendor specific resolution logic, which the protocol does not attempt to specify), then sending the collected Route Recs out in the resolution response.=A0 Notice that there are not=20 two different flows.

=A0

My comment for = this point is related to the fact that a route group plays the two roles me= ntioned previously. Playing what I call the basic role (regrouping route re= cords corresponding to the same destination) and the disturbing role (allow= ing offer for route records directly associated to PIs) is simply not intui= tive. And, that's why David qualified this role as a hack. It's not= a derision for the current model, it is simply the fact that there is some= thing that is at the wrong place.

Also,= I didn't get an answer concerning the possibility to associate a singl= e TNR, TNP or RN directly to one or more route records. Would we add also a= direct association from RN, TNR or TNP to route record?

=A0


KJC:=A0 But from a bigger picture perspective, when the proposal was brought up yesterday, it was brought up under the guise that =93the current data model is broken and it a hack in this area, so we need to=20 do X, Y and Z=94. =A0This is simply not accurate, as I=92ve described above= .=A0=20 Secondly, the proposed alternative simply does not work in terms of=20 scalability for the User ENUM use case. =A0The proposal would result in millions of Route Recs (since in the user enum case the Route Recs contain PI specific data) having to be offered and=20 accepted.=A0 So even the primary target use case of the proposal just does not work well.=A0 So given that the current model is not =93broken=94 and is not a =93hack=94 and given that the new= =20 proposal does not scale for the user enum use case, why add in the=20 additional complexity that results from the new proposal?

=

=A0

At this point, I still don&#= 39;t understand why the proposed model is not accurate. I don't underst= and why millions of route records have to been offered and accepted? I thin= k grouping associations solves this problem. Please, can you illustrate by = a scenario or diagram (especially for the User ENUM use case)?


I just want to precise that my comments are not intended to create = conflicts in any manner especially when I see that it's late to raise s= uch propositions and that the draft will become soon a RFC. I'm just tr= ying to add my efforts to this framework/protocol.

Thanks

Mickael